Difference between Oracle Service Bus and Mediator

Oracle Service Bus Vs Mediator

While Oracle Service Bus provides enterprise service re-use and management; the Mediator component provides certain localized mediation capabilities with the Business Service Layer. Thus, the lifecycle of a Mediator component is tightly coupled with that of the SOA composite application that provides the application logic. Mediator provides the following capabilities with the context of a single composite application:

• Connectivity abstraction from a business process

• Inline data transformation / mapping

• Message filtering

Oracle Service Bus enables effective de-coupling of systems and lifecycles within enterprise architecture. Mediator provides any abstraction that the Business Process needs within the context of a single composite. The key considerations for using Mediator include:

• The functionality is available within the context of a single SOA composite

application.

E.g. Mediator can be used to expose a BPEL process to multiple services

defined on the same composite.

• Mediator does not focus on key capabilities required for the SOA

Infrastructure category such as traffic shaping and end-point management.

• Mediator should not be used to share services at an enterprise-wide level.

Since the lifecycle of a Mediator component is tied to the lifecycle of the

underlying process logic, Mediator cannot effectively separate the lifecycle

of the service contract from the service implementation.

An example of the above principle is determining where to implement the message transformation logic associated with an integration scenario. When integrating between multiple systems/domains, there are two distinct approaches to data modeling that may be determined by the Information Architecture:

1. Point-to-point Data Mapping:

The business objects are exposed in domain (system) specific format. Transformation logic maps the data format between the native formats of the 2 systems.

2. Normalized Domain Model:

The business objects are always exposed in a normalized data format i.e. the data is always transformed to a common domain model when exposed through a service. Transformations are used to convert to/from the normalized format from / to the system specific format.

The difference in the above approaches is that the transformation logic in first approach is use case specific while the transformation logic in the second approach can be shared by all use cases using the same data. Thus, transformations that fit the first pattern can be implemented in Mediator while transformations that fit the second pattern should be implemented in Oracle Service Bus.

Modeling Business Process Orchestration

Any application logic should be delivered through one of the Business Service Layers. In the case of Oracle SOA Suite 11g, such logic should typically be implemented using the BPEL Process Manager. Oracle Service Bus is specialized to address use cases associated with the SOA Infrastructure category. While it is possible to create simple transactional service aggregation scenarios within Oracle Service Bus; due care must be exercised when going down this path as Oracle Service Bus is a stateless engine that is optimized for use cases with short-lived single transaction semantics. Below are examples of use cases that require a fullfledged

orchestration engine and should not be implemented on Oracle Service Bus:

• Service needs to maintain state

• Service requires complex transaction management

• Requires multiple transactions

• Compensation logic required on rollback

• Short or long-lived process

• Exception handling requires Human workflow

• Service needs to handle asynchronous callbacks reliably

Thus, Oracle Service Bus provides a clean separation between clients, business processes and back-end information systems. This virtualization layer can be used to inject various IT concerns such as traffic shaping, alerting, and fault isolation.