OSB Architecture: transports inside out
We have used both OSB and SOA Suite in our projects. Technically, the OSB is part of the SOA Suite. However, the use cases for both are very different. The OSB is a layer to virtualize your services. It offers validation, enrichment, transformation, routing and operation (VETRO) functionality. As Simone emphasized a couple of times, you are not supposed to program business logic in the OSB. You do that in SOA Suite. We discussed what a proper name is for the part of SOA Suite without OSB so you can point to that in your design guidelines. Unfortunately, we did not come up with a satisfying solution.The presentation discussed the high level architecture briefly, and the core components. This was a bit boring if you had any experience with OSB. I was very pleased when the presentation continued and the architecture of OSB was discussed in depth. The architecture of transports was explained as well as some functional differences between some transports and adapters. This was exactly the kind of information I would expect from a training like this :) Icing on the cake would have been if the lab would have included creating your own transport or something that showed the MDB that is deployed when you create a JMS transport. Unfortunately the lab was fairly basic and focussed on creating a message flow. It showed all the steps in detail, like many of the hands-on labs that I have attended at Oracle OpenWorld. Fortunately the other labs during this training were formulated as a specific problem to solve, with little or no hints for the solution. This way you really think about it, instead of just following the steps.
Apart from the architecture of the transports, I took a few new things out of this session: local transports for proxies calling proxies and jejb transports that use POJOs instead of XML.
Cloud integration: fine grained APIs are ruling
The presentation about cloud integration focussed on the challenges one encounters when integrating with cloud solutions. The example of RightNow, FusionApps and Salesforce.com were used to discuss API styles, lack of a consistent set of standards, governance, security and scalability. Interestingly patterns you might want to use internally for performance reasons (synchronous communication) can be a bad idea in cloud situations because of the unreliability of internet connections. So in cloud integration you might apply asynchronous solutions much more often to cater for that. The content of the presentation was good, but even better was the experience that Rajesh brought in while explaining it. We discussed why packaged apps offer APIs instead of coarse grained services. Therefore it is important that you encapsulate these services in your enterprise and offer coarse grained services to the other service consumers. You can use Oracle SOA Suite to accomplish this.
The day ended with another performance lab, showing the difference between latency and throughput and the effect asynchronous communication has on latency.
And so it ended
This concludes the last blog about the SOA Black Belt training. For me it was definitely worthwhile: I learned a lot, practiced some of that and met great new people.If anybody is interested in participating, they should contact Juergen Kress. I definitely recommend this training!