Restful Gateway Architecture in OSB

In one of my customer’s environment I was reviewing the existing OSB processes. One of their main concerns was Security, so they had implemented security mechanism in all the processes. As you know for SOAP services the OWSM policy feature can be leveraged to embed out of the box security implementations or else for custom implementations use custom OWSM policy and attach it to the process. The environment the customer was working on was 11.1.1.5 where only policies for SOAP services were supported by OWSM. Most of the OSB proxy services were RESTful in nature and all were having the security code scattered all over. That’s when I started looking at reusable and repeating functionalities/steps that need to be built into every service flow. I was able to find lot of repeating steps that had to be done in almost all the flows. As part of refactoring and redesigning I was looking at the Gateway architecture where the request comes in through the Gateway request pipeline and reply through the response pipeline.

As per the new flow we will be clubbing all the common calls into a gateway and internally routing the requests to different projects.

There will be a registry(XML file) which will be having details of all the exposed services in REST. It can be GET  or POST.

The registry will decide on routing the different services based on relative URI

https://<hostname>/GEOGateway/Employee/requestAddress?ID=121

The Gateway will use Employee/requestAddress to figure out which Project and which proxy service to invoke.

The rest of the query string à ID=121 will be passed to the respective proxy services.

Advantages

• Standardization of all the exposed URLs.
•     Request Validation happens in the gateway, only if it is successful it will be routed. A new project developer should only develop the flow, not worry about validation, test it completely then plug it in to gateway.
•   Easy to add/modify new security mechanism.
•   Enrichment/manipulation of request data like populating custom headers which can be useful in tracking the request flow as well as error handling.
•   Response can be converted/transformed from XML to JSON/or any other consumer specific format in response pipeline of Gateway. So tomorrow they want to use a different format we can have it added here instead of doing it in all processes
•  Gateway can also be leveraged to send back properly formatted Error Messages in case of errors suppressing the error stack trace and transforming to consumer understandable error messages.
•  Reduces development time for individual services.
•   Ease of testing

Impacts

• The exposed URLS will change so existing users will be affected.
•   No impact if this is taken care at design time at the beginning of the project.

Downside

If the gateway is down all services will be inaccessible. Central point of failure.

                Not a valid case since

•  the OSB will be always up and running
• Any changes to the Gateway will be tested in lower environments before promoting to PROD.

Implementation

        On the implementation side, all the proxies other than gateway need to be changed to local from http. More on how to handle the new custom headers

References:

http://www.oracle.com/technetwork/articles/soa/architecting-restful-services-083025.html