When implementing a complete SOA security solution, which includes Oracle API Gateway and Oracle SOA Suite, the best practice is to deploy the API Gateway into the DMZ as the first line of defense. Behind the inner firewall of the DMZ is where the Oracle SOA Suite typically resides, providing the last-mile of security. This secure layered approach allows only validated traffic to enter into a company’s inner network (for further details, see Oracle API Gateway Data Sheet).
Understanding the need for the layered security and the role that the Oracle API Gateway has in this architecture was not too difficult to comprehend. But, once I started to dig further into the Gateway and its capabilities, it soon became apparent that there was an overlap of functionality between the Gateway and SOA Suite. Within this article, I will point out some of these overlapping functionalities, along with consideration around what to use where.
For a good overview of the Oracle API Gateway functionality and components, see Aaron Dolan’s blog Your API’s First Line of Defense: Oracle API Gateway.
Throttling
Oracle Service Bus throttling provides the ability to throttle a business service, controlling the volume of traffic to an endpoint. It is based on the number of messages received, restricting the maximum concurrency for a business service. An in memory queue is utilized for throttling of messages either at the business service or group of business services level. Depending on the configuration of the queue size along with message expiration time, the messages will be delivered, but at a degraded performance level. Throttling is easily configured for a business service or group by checking/unchecking the throttling check box.
The Gateway throttling capability also limits the number of calls for a service, restricting the incoming connections. It has the capability to regulate traffic for a service, an operation or time of day. It is implemented within a throttling filter within a policy. Once the throttling limit is reached, the response is determined by the next step within the policy (i.e. an alert sending a notification of the event, set response code to 500). The throttling is time based, so the configuration requires specifying the number of messages per second that are allowed. Adding or removing throttling involves deployment of the policy with throttling.
Even though the functionality seems similar, the use cases are typically different. Within the Gateway, the throttling is utilized to prevent malicious attacks (i.e. DDoS) caused by flooding the network with messages. For OSB, the typical use case is not to guard against malicious attacks, but rather insulate the end point from being overwhelmed with a flood of messages, sending messages in a controlled trickle-like manner.
Protocol Translation
Protocol translation enables a client to send a message via a particular protocol which in turn is routed to the receiving system on a different protocol (FTP, HTTP, SOAP, REST, etc.). Of particular interest for mobile enablement is the translation from REST to SOAP to REST. Within Oracle SOA Suite 12c, a REST binding allows configuration of REST interactions within SOA composites and the Service Bus. A wizard within 12c allows for easy creation of a REST binding with the translation occurring in the integration wire or ‘translation on the wire’.
Within the Gateway, the translation occurs by creating a policy that has filters defined which translate the message from REST to SOAP to REST. Below is an example of a policy that can be used to perform this translation:
One of the Oracle SOA Suite strengths is protocol translation. It provides the ability for reuse (i.e. adapters), easy configuration and supportability. Given this, the suggested approach is to do all protocol translation within the Service Bus or SOA composites.
Message Transformation
Transformation is often necessary when the contents of a message need to be translated from one format to another. The Gateway and SOA Suite both have the ability to do these translations using XSLT. The Gateway has a filter that can be configured to import a predefined XSLT map for message translation within a policy:
Message transformation via XLST capability is available within both the Service Bus and SOA composites. The SOA Suite also offers XQuery as another means to do message translation within the Service Bus. Both XQuery and XSLT translation maps can be developed and tested within the Oracle JDeveloper 12c IDE.
Much like protocol transformation, message transformation is a strong suit of the Oracle SOA Suite. Because message transformation can often times be complex, sometimes requiring message enrichment, utilization of external business rules, etc. the recommended approach is to use SOA Suite for any message translations. Along with this, reuse of the various transformation artifacts can be achieved.
Endpoint Virtualization
Virtualization of an endpoint shields the client from direct access to an endpoint and provides endpoint abstraction.
The Gateway has the capability of mapping the path that the client accesses and the actual path which the web service resides, providing service virtualization. It can also be perceived by the client as a proxy server, the gateway can then determine the host and port to route the message to. The dynamic router filter within a policy is used for proxy functionality, while the static router filter is used for service virtualization.
Within the Service Bus, endpoints can be virtualized as well, insulating the client from service versioning, endpoint movements, need for message enrichment, and/or message transformation. The Service Bus business service allows for quick configuration changes when endpoints move, with the proxy containing any logic required for transformations, enrichment, etc.
For this particular functionality, I don’t envision this being an either/or choice, but rather use both technologies to achieve the highest level of endpoint virtualization.
Content Based Routing
Content based routing sends a message to target endpoint based on value(s) within the message content or message header. Content based routing within the Gateway can be implemented within a policy by extracting the content from the payload using XPath, then checking the value via switch filter:
Within SOA Suite, there are a couple of options available to implement this type of routing, the Service Bus and composite mediator. The Service Bus has the capability to implement dynamic routing based on an external routing table, dynamic routing with the endpoint set at run time, and static routing. The mediator within a composite can perform routing either by a static routing rule or using dynamic routing capability based on external routing logic defined in the Oracle Business Rules.
Given the need to query the payload for the content, as well as the robust capabilities that SOA Suite provides for content based routing (one to many routing scenarios, dynamic routing, configurable routing, etc.), content based routing would be better served in the SOA Suite, rather than the API Gateway.
API Management
The role of API management is to provide monitoring, security, and consistency for published APIs, ensuring that they are performant and scalable.
Within the Gateway, some of these API Management tenets are implemented as noted below:
- Monitoring of SLAs including response times, communication failures, HTTP status codes configured at the policy level.
- A policy can be configured to send an alert when the conditions of the SLA are breached for quality of service monitoring. Alerts can be sent to a destination such as syslog, email, twitter and can be configured to be sent from within any policy, like when a filter fails.
- Analytics and usage statistics can be gathered by configuring monitoring settings within a policy. This will store usage metrics data to a database, used by the API Gateway Analytics to produce reports, which include usage metrics (i.e. usage per client).
- API key client credential profiles allow the API service provider to track and control how the APIs are used. This includes metering API access.
- Security implemented as required
The Oracle SOA Suite has similar capabilities to the Gateway with regards to monitoring, auditing and reporting of services. But the Gateway provides the necessary management of APIs, enabling implementation of cloud, mobile and SOA services.
Hope this article has cleared up any ambiguities between similar functionalities found within the Oracle API Gateway and Oracle SOA Suite. Further details regarding the Gateway, see the Oracle API Gateway User Guide 11g Release 2 (11.1.2.3.0).