Like the previous days at Kscope my focus has been on the Fusion Middleware track. In this post I’ll share some of the highlight and summaries of some of the talks over here.
Fault Handling in SOA Suite
Ronald van Luttikhuizen en Guido Schmutz presented on Fault Handling in the SOA Suite. There is a clear need for another approach compared to say traditional systems. This is because SOA based systems differ from traditional system on the following aspects: level of heterogeneity, number of (different types of) consumers, asynchronous responses, and the way that transactions are handled.
Guido showed us around in the OSB with a focus on the following features: Result Caching, Service Throttling, Retry mechanism, Service pooling (talking to multiple endpoints) and Fault Message on callback (in async). Ronald gave a demo on how the Compensate and Fault Policy Framework work in BPEL.
This presentation on SOA Suite Fault Handling is also available on slideshare.
Using Oracle Apex as a replacement for BPEL Console
The company where this case was build has a high number of messages running through their BPEL 10g. This causes performance issues in the BPEL Console due to the high number of instances (millions on a daily basis) in the dehydration store (on which full table scans are performed). They created an own more lightweight console in Apex to manage both deployed BPELs as well as instances. Their solution uses the following ingredients:
- A BPEL api – which is included in a BPEL script. They import orabpel.jar for this.
- A BPEL script that exposes a part of the BPEL api as a web service. Embed Java in a BPEL and call the API.
- An Apex front end that calls the web service to perform maintenance tasks.
In my opinion this delivers value to this company, however are there better ways to expose Java as a web service. Besides that this adds additional BPEL instances to the bottleneck resource.
Tuning SOA Suite 11g for perfomance
This presentation was delivered by Vikas Anand. One of the best parts of his presentation was that he didn’t only address the tuning part but also the design part. This mainly focus on preventing the need for tuning afterwards. Some of the design considerations he mentioned were:
- Choose the right tool for the job.
- Design it right – Consider what parts of the integration have to be synchronous and what have to be asynchronous. To which he added the advise to be aware of transactional boundaries.
- Need a holistic view on sizing and capacity – Based on business requirements.
- Plan sizing of dehydration DB – make sure there is a retention strategy and implement dehydration strategy.
- Use the same JVM across (different) clusters.