What’s in the SOA Suite and What’s it for?

I had a really good question recently.  Someone was struggling with Oracle Service Bus having previously used BPEL.

I am still working with OSB, and I am struggling to get to grips with how it will be used in FUSION and beyond.....
…
I know there is no definitive answer, but I want to try and get an idea of how it is intended to use OSB and Orchestration..... (cos it aint easy!!!)

Lets look at the three components in the SOA Suite that have some overlap and that my questioner was referring to.

• Oracle Service Bus (OSB)
• Oracle Enterprise Service Bus (OESB)
• Oracle BPEL Process Manager (BPEL)

All three of these provide connectivity services, all of them support transformation.  OSB and BPEL provide orchestration capabilities.  So what my correspondent was really asking was

What should be done in which service bus and what should be done in BPEL.

It is worth looking at each component in turn and identifying its sweet spots as I see them.

Oracle Enterprise Service Bus

Prior to the BEA acquisition this was Oracles primary service bus.  Since the acquisition of BEA the role of the OESB is to provide mediation services (transformation & simple routing) between SOA Suite components, primarily between BPEL processes in the 10g release.  In the 11g release this component becomes known as the Mediator and acts as a component in an SCA assembly.  If running on a non-WebLogic server then OESB becomes the only ESB available in the SOA Suite and so then it becomes a straight split between OESB and BPEL, with OESB providing routing and transformation services.

Oracle Service Bus (former AquaLogic Service Bus)

This is Oracles primary service bus and is the preferred platform for service virtualization and interactions external to the SOA Suite.  Currently OSB is only available on WebLogic server but the intention is provide it on other platforms as well in the future.  OSB is the foundation of service bus functionality moving forward.  This means that we should be using OSB for the following:

• Endpoint routing (providing location transparency) so that we do not care about the physical location of the endpoint.
• Endpoint abstraction (interface transparency) so that we do not care about the exact data formats required by the endpoint because the OSB will take care of transformations.
• Load balancing so that we do not care about which of multiple service implementations will actually service a request.
• Throttling so that we do not care about how use of services is restricted.
• Enrichment so that we do not care about how additional data is provided to the request to match the expected request and response formats.
• Simple synchronous composition so that we do not care if our abstract service call is actually made up of two or more physical service calls.
• Protocol conversion so that we do not care what physical transports are being used.
• Sync/async abstraction so that we can treat services as fire and forget or query response according to the needs of the client.

Oracle BPEL Process Manager

BPEL Process Manager is the primary composition, orchestration and process engine in the SOA Suite and as such should be used for the following.

• Complex composition of synchronous flows that involve more than a couple of services.
• Long running compositions that may run for minutes, hours or days.
• Asynchronous compositions that require correlation of requests and responses.
• Process abstraction that enables us to track processes and their interactions with multiple services.
• Human workflow for when we need to interface to wetware.

Summary

Hopefully the above has given you some indication of what each component is best used for.  The short version is, for routing and transformation between SOA Suite components use either OESB or OSB.  For service virtualization use OSB and for process orchestration and long running interactions use BPEL.  See, not that hard was it?