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.
