Cook book on Oracle SOA Suite 11g Performance Tuning

Currently reading a cook book on Oracle SOA Suite 11g Performance Tuning by Matt Brasier, Nicholas Wright. Interesting read as it brings together all the performance tuning/monitoring options under one roof. You can get it @ http://bit.ly/12lrajU

Why do we need an API Gateway?

  I was recently evaluating multiple gateways which can serve different requirements like throttling, reporting, security, access control, response format conversion. The companies see an increasing value in opening up their services and sell the services provided by their applications, which till now was only consumed privately within the organization. Security becomes a pivotal issue when you start opening up services to multiple consumers. That’s where the more sophisticated open API management becomes important and API Gateways /Enterprise Gateways play critical role in fulfilling this requirements.

              Going forward, the traditional approach of B2B/EDI gateways will be replaced with more API based integration or the cloud based integration leveraging the API. EDI Gateways will be more for high volume data where as new cloud based REST or SOAP API’s will be more popular for real-time customer engagement  

One of the options is to custom build a solution which can perform these requirements on OSB platform.  Other option is to evaluate existing gateway products and see the pros and cons along with licensing costs/ROI. The first option of product will be Oracle API Gateway or Vordel’s API Gateway.  Both are the same. Oracle just licensed it to sell in their name. It actually meets all the requirements that Oracle was envisioning in the 2010 whitepaper .

Other option is APIGEE which also looked like a new PAAS (Platform as a service) solution which helps you in easily developing/maintain/hosting the REST based services.

I will write more on this topic in coming blogs.

References ::

http://www.soatothecloud.com/2012/04/vordel-api-gateway-video-demo.html

Vordel:: http://www.vordel.com/oracle/

APigee :: http://www.youtube.com/watch?feature=player_embedded&v=3W6JSgGoO_o

Behavior of OSB response Content-Type based on Request-Response message types/Trasport-Header

While designing a single proxy service which will return different formats- say for example json and xml, the response Content-Type plays a big role in browsers or consumer systems understanding the return structure. If the consumer receives the content –type populated as application/json then it can have the json parser interpret the data and if the response content-type is populated as application/xml , then consumer can have the xml parser in action.

For this test I choose the proxy service which has Request-Response message type as text, as the response can vary based on underlying service, as well as consumer requirement. When you design you need to support all the formats, so selecting TEXT type will be the best option.

The issue here is that response content-type will be text/plain by default. The solution is to have a Transport-Header which will overwrite the Content-Type as required. You can do it this way or have the Content-Type copied from the response header if underlying service has set it properly.

Proxy response - no transport header set

Response Metadata      

  -- Default behavior of the proxy

  

<con:metadata     xmlns:con="http://www.bea.com/wli/sb/test/config">           <tran:headers            xsi:type="http:HttpResponseHeaders" xmlns:http="http://www.bea.com/wli/sb/transports/http" xmlns:tran="http://www.bea.com/wli/sb/transports" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">                 <http:Content-Type>text/plain; charset=utf-8</http:Content-Type>                 </tran:headers>                 <tran:response-code          xmlns:tran="http://www.bea.com/wli/sb/transports">0</tran:response-code>                 <tran:encoding    xmlns:tran="http://www.bea.com/wli/sb/transports">utf-8</tran:encoding> </con:metadata>

Proxy response -transport header is set

 Response Metadata     

<con:metadata     xmlns:con="http://www.bea.com/wli/sb/test/config">                 <tran:headers      xsi:type="http:HttpResponseHeaders" xmlns:http="http://www.bea.com/wli/sb/transports/http" xmlns:tran="http://www.bea.com/wli/sb/transports" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">                 <http:Content-Type>application/json; charset=utf-8</http:Content-Type>                 </tran:headers>                 <tran:response-code          xmlns:tran="http://www.bea.com/wli/sb/transports">0</tran:response-code>                 <tran:encoding    xmlns:tran="http://www.bea.com/wli/sb/transports">utf-8</tran:encoding> </con:metadata>

How to do versioning with Oracle Business Rules

In one of my discussions on oracle business rules, one query that I got was on versioning, for example  a scenario in which clients major business rules are written in Oracle  business rules and  as per requirement it is modified at runtime using SOA composer. There were lot of transaction that happened in that period with new rules and later it was reverted back to old rules. How can we track the changes that went in so that it is easy for rolling back to previous versions, know how any versions/changes have been made on the initial business rules.

It is a valid query from the user perspective and oracle has the solution.

Runtime Versioning is supported in Oracle Business Rules using MDS. The rules dictionary is stored in MDS and if MDS has database as the backend instead file based repository then versioning is supported using MDS. Any changes made to dictionary are made visible to the application in MDS. The rule service engine (decision service) does this automatically.

There is also option of creating metadata labels for each release or each update which will be helpful (similar to tags in SVN). A metadata label is a means of selecting a particular version of each object from a metadata repository partition. This tag/label comprises of the document versions which were the latest versions at the time the label was created.
Labels that are created will be available till they are deleted explicitly using wlst commands. Automatic purging will not remove the labels. Same as versioning, labels are also supported only in database-based repositories. As a good deployment/promotion practice, you can create a label and then promote documents/rules associated with a metadata label. It will be easier to rollback to an earlier version in case you use create/promote label approach.

References

http://docs.oracle.com/cd/E21764_01/integration.1111/e10228/faq.htm#BGBEJGEI

Standards for designing RESTful API's

Good articles /videos explaining set of Standards for RESTful API's

https://github.com/WhiteHouse/api-standards


http://munich2012.drupal.org/program/sessions/designing-http-interfaces-and-restful-web-services.html