With the acquisition of BEA Oracle has taken ALSB made some changes to it and re-branded it as Oracle Service Bus (OSB). With the co-existence of OSB and Mediator one has to wonder, what’s the strategic direction from Oracle for OSB and mediator?

To start with, Oracle Fusion Middleware and OSB come in two different installations.

Mediator is an internal component installed as part of the SCA Composite editor within JDeveloper. Mediator has essentially taken place of the role of ESB in 11g.

From the onset Mediator is a replacement to ESB and takes care of the communication brokering within an application. As ESB primarily took care of validation, transformation, routing and delivery, Mediator has inherently adopted that as well. The primary difference between Mediator and OSB is that Mediator is geared at being used to broker messages between components that compliment each other and form a composite. Thus adhering to SCA (Service Component Architecture)

It works as an aggregator or mediator of components within a composite application or by mediating components from external systems. Also, the only ESB (provided by Oracle) for non-weblogic environments.

Mediator also offers functionality such as

• Cross Referencing (XREF) – Referencing of keys and fields from separate systems, by means of storing a mapping table.
• Domain Value Maps (DVM) – Essential DVM is used to map information from one domain to another, this helps significantly when utilizing Canonical Data Models.
• Schema Validation – The ability to make assertions of data types in a XML Tree.

Oracle Service Bus (OSB) is Oracle’s primary enterprise service bus. Although it performs similar tasks as Mediator, IE brokering, validation, transformation routing and delivery, OSB is geared at brokering Information Company wide and serves to decouple inter-application communication. OSB however has inherited functionality from ESB; it however is not based on ESB and is rather based on ALSB.

OSB is a fully fledged standalone stateless ESB, and works as an intermediary between service consumers. It does this by primarily working as a proxy or a differentiated layer between the two.

Preferred platform for service virtualisation and interactions external to the SOA Suite. Currently, only available on weblogic server but in intended to be available on other platforms in future.

One of the features of OSB that really stands out for me and assists me to understand the role of the product is the functionality that OSB can play as being a Proxy or a buffering layer between layers in your architecture.

One of the issues that many businesses face today is one that once SOA was first introduced business took the approach to utilize SOA primarily as integration metric. Although this is handled very well it is not always the primary focus that one should use when adopting a SOA. When designing the scope of a SOA one can take two approaches, one of top down development approach and one of a bottom up development approach. Let me explain further

• Top down – This is where one would assess your business and design canonical schemas that would represent the data that your services will expose. This approach is normally well thought out and is used when business adopt SOA as a metric to increase productivity and save costs in the business.
• Bottom up- This is where one would utilize SOA to integrate certain components in the business. In most cases business don’t always have a holistic view on what they are trying to achieve with SOA. They would then start developing services that served a specific integration need. Well this works very well, one is often left with a situation where we have many services that may or may not serve the same process.

Oracle took note of this and is using the proxy functionality of OSB to allow customers to consume these very specific services and expose them as a more generic service. Although this is not OSB’s primary function it does provide customers with a solution to there already existing SOA.

Summary:

What this means is that there is currently a differentiation and clear cut line as to what product one should use for each requirement, and one therefore can utilize each product for its merit, either for application development or integration. The decision though is based on required and the supported features.

Standalone ESB needed –> OSB

Interactions with other SOA Suite components –> Mediator

For a complex large scale SOA solution  –> better off combining the 2 solutions as required.

To extend this comparision with BPEL refer http://nitinaggarwal.wordpress.com/2011/11/10/bpel-vs-oracle-service-busmediator/