Thursday, March 19, 2015

SOA Software/Akana API Gateway

There is wide adoption of REStful services across enterprise. Initially we had exposed services on OSB even though the json support was not that great with OSB. There used to be lot of custom java codes that needs to be used to maintain these services. All oracle 11g products were fully focused on the XML , so the json support want great. The overhead of maintaining and converting the payload from xml to json and back was bit taxing on the service performance. Other issue we had was onboarding of App developers who are the real consumers for this API.Even though we had WIKI it had to kept updated based on the enhancements that happen during each sprint. In case the process is missed the Wiki will be outdated. The new App developers had to be helped to troubleshoot to resolve integration issues with services, and this steps are repeated for each App. There was no way they could interact with the developer and then use the knowledge base for the issues already documented. That’s when we started at exploring the option of onboarding a API Gateway which should help us in interaction with our consumers. SOA software or now rebranded AKana was chosen. I have been working extensively on SOA Software /Akana API Gateway for past 8 months. The tool had some initial hiccups to be molded into the client’s environment. But once it became stable, it has been really good. The more familiarity you get on the tool the easier it becomes to debug issues.
The architecture is sort made of 3 components. 


Community Manager - API Enablement Tool /App Developer Portal
Policy Manager: Database of run-time policies, access contracts, service definitions and related metadata•
Network Director: The proxy service that receives virtual service requests, queries Policy Manager for run-time instructions as to how to deal with the requests, then sends the requests to the physical service. The physical service responds, and Network Director applies any policies, and then sends the response.

The CM helps App developers to interact easily with the API developer using a Board and ticketing dash board.
 The policy manager helps in adding all the non-functional requirements.-API Security .traffic monitoring, throttling, QOS Management, caching.
Network director acts as the proxy or the gateway which internally uses the PM .


It really simplifies the virtualizing of service. There is a small process engine to do aggregation of services or orchestrating different services. The out of the box REST support,  json and Oauth 2.0 support helps in  exposing the RESTful  services in quick time and keep up to date the new standards.

Thursday, February 5, 2015

coherence adapter in osb 12c

Recently I started working with 12c , At weblogic level all looks same except for the new look and feel. Coherence adapters looked new, so I was trying it out in the osb. The only issue I faced was on how to assign the coherence key

You can use an insert operation to populate the jca.coherence.key value in the jca headers.
Rest of the steps are similar to how you do in BPEL which is well documented.






Log:
outbound: <con:endpoint name="BusinessService$HelloWorld$GetFromCache" xmlns:con="http://www.bea.com/wli/sb/context">
  <con:service>
    <con:operation>Get</con:operation>
  </con:service>
  <con:transport>
    <con:mode>request-response</con:mode>
    <con:qualityOfService>best-effort</con:qualityOfService>
    <con:request xsi:type="jca:JCARequestMetaDataXML" xmlns:jca="http://www.bea.com/wli/sb/transports/jca" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <tran:headers xsi:type="jca:JCARequestHeadersXML" xmlns:tran="http://www.bea.com/wli/sb/transports">
        <jca:SOAPAction>"Get"</jca:SOAPAction>
        <jca:Content-Type>text/xml</jca:Content-Type>
        <jca:jca.coherence.Key>4009</jca:jca.coherence.Key>
      </tran:headers>
    </con:request>
  </con:transport>
  <con:security>
    <con:doOutboundWss>true</con:doOutboundWss>
  </con:security>
</con:endpoint>>