PaaS Community Blog

Registries: Use Cases for API Management and Microservices by Phil Wilkins

Microservices and new 3rd-generation API Management capabilities are very natural technical partners. A (micro)service provides the execution logic for a single capability and 3rd generation API Management provides the means to control the exposure of each service to the outside world, and potentially between the (micro)services as well. Luis Weir’s article, 3rd-Generation API Management, explains the evolution of the API Management capability, and what the 3rd generation offers that makes API Management mesh well with (micro)services. For this article, though, we are going to explore the role of registries in a (micro)services environment and ultimately their relationship to API Management. We aren’t going to dive deeply into any specific solution, although we will reference some of the better known options, and provide links to where you can dig in further.

You’ll note I have referred to microservices as (micro)services. This is very deliberate, and possibly contentious.Microservices are typically associated with certain technologies such as Docker and lightweight app containers such as Tomcat, but from my view point if you’re going to be a purist about microservices, then (as with SOA) you need to think about the design paradigm and the principles—NOT the technologies. It is with this view point we often have to work as, unless you’re fortunate to be working in a services organization that is very enlightened or just plain fortunate, the decisions and constraints you have to work with will mean you need to make some pragmatic decisions. An organization that has made heavy investment in WebLogic licensing isn’t likely to be comfortable in giving it up—but this doesn’t mean you can’t adopt a microservices approach, although certainly you need to mitigate risks that using WebLogic can create when adopting the architecture. Secondly, the concept of registries isn’t unique to microservices; in fact, some of these solutions have origins in solutions such as Big Data/Hadoop offerings, for example.

To underline my point, Gartner has started to talk about mini- or micro-apps as a flavor of microservices. The essence of this is the application of microservice principles but in a more pragmatic manner—not every organization needs hyperscaling and super elasticity like the poster children of microservices (e.g., Netflix and Uber). But we all do need the means to easily manage the addressing of services.

To understand the role of a registry, we need to step back and understand some of the ideas underpinning microservices. So let’s just recap: Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

How Capgemini can enable the new Oracle API Management platform by Mark Albon

As the tendency continues for organisations to adopt not one but multiple cloud vendors, information has never been more federated. Real time access to such assets via APIs has therefore become a priority for our customers. Oracle API Platform Cloud Service delivers a pure-play 3rd generation API solution capable of creating and managing APIs that run in any vendor’s cloud and/or on-premises –whilst keeping the entire platform operations and API lifecycle central in the Oracle Cloud.

This flexible architecture means that we can create robust solutions for our customers that really puts them in the driving sit when it comes to managing access to information via APIs –regardless of where they are. The incorporation of Apiary into the platform, only makes it better as developers also get the tools they need to ensure that those APIs are well designed, documented and are easy to consume. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

My first experience with Oracle API Platform Cloud Service – part 1 by Milco Numan

In the first part of this two part blog post, I will describe the use case for which we used Oracle API Platform Cloud Service (shortened to APIPCS from now on) as an outbound API Gateway, offering lookup services and centralizing outbound access. This part will also describe a simple Node.js microservice we deployed to Oracle’s Application Container Cloud Service to perform the translation of an internal identification into the API key required by the external API.

The second part of this blog will elaborate on the actual creation of the API definition in APIPCS, the invocation of the microservice using Groovy scripting and the testing of the external API using APIPCS.

Introduction

At a customer, for a proof of concept last year, I have been working with an exiting new Cloud Product from Oracle: API Platform Cloud Service, or APIPCS for short. In this blog, I will not go into architectural details on why you could, should or must use an API Manager of API Gateway. Nor will I be elaborating on all functionality or features of Oracle’s implementation of the product, since they’re perfectly capable of doing that themselves.

Basic Scenario

In the use case encountered at this specific customer, the requirement existed to not use the API Gateway as an inbound Gateway, but rather to use the API Management solution as an outbound gateway. The rationale for this setup is to provide a single outbound gateway through which REST services can be invoked where internal identifications can be translated into different kinds of external identifications, known to the outside world. The former may be thought of as (internal) applications, or perhaps even customer identifications stored in an internal system. The latter category then may relate to API-keys required by the external partner, or even OAuth2 tokens. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Everything you Should Know about the API Platform Groovy Policy by Ricardo Ferreira

Introduction

Developers using the API Platform Cloud Service often make use of the built-in policies that comes with the platform; to implement any logic that needs to be executed before delivering the actual message to the backend service. One common policy used is the Groovy policy, which allows API developers to write Groovy scripts that can be executed either within the request or the response pipeline. These scripts can be used to inspect and even modify the message content (payload, queries, headers) therefore a very powerful tool to have at their disposal.

Because Groovy is a programming language, there are no boundaries of what can be implemented other than what is supported by its specification. Moreover; Groovy will accept any code that is valid in Java, bringing even more powerfulness to your APIs. However, this power comes with a high price to be paid.

The biggest challenge with the Groovy policy is that you have no way to verify if the code written is correct until it is deployed into the gateways. During deployment; the Groovy script will be transformed into a Java class that uses the code written as part of its implementation. If something in the script is wrong, there will be compilation errors that will cause the deployment of the API to fail, as shown in Figure 1.

This whole situation can be quite frustrating if complex Groovy code is being used or if one API accesses multiple instances of the Groovy policy, each one carrying different scripts. Hours can be spent trying to troubleshoot the root-cause of the deployment issue, which is a situation that the Oracle A-Team has been experiencing quite often with different customers. Thus, this blog will discuss the most important details about the Groovy policy, its common pitfalls and which situations must be avoided to ensure a smooth API deployment.

The Basics: Groovy Policy Under-the-Hood

Given the simplicity of the Groovy policy UI, you may be thinking that its internal implementation is also quite simplistic. After all, how complex should be getting a script that contains Groovy code and executing it in a JVM right? the truth is that it is way more complex than what may appear, and properly understanding what happens under-the-hood may give you a better perspective about what to expect from this policy. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress