Mediators

Mediators

Introduction to Oracle Mediator:

          Oracle Mediator provides a lightweight framework to mediate between various components within a composite application. Mediator converts data to facilitate communication between different interfaces exposed by different components, which are wired together to build a SOA composite application. For example, a Mediator can accept data contained in a text file from an application or service, transform it to a format appropriate for updating a database that serves as a customer repository and then route and deliver the data to that database.

Oracle Mediator facilitates integration between events and services, where service invocations and events can be mixed and matched. You can use a Mediator component to consume a business event or to receive a service invocation. A Mediator component can evaluate routing rules, perform transformations, validate, and either invoke another service or raise another business event. You can use a Mediator component to handle returned responses, callbacks, faults, and timeouts.

This section provides an overview of Oracle Mediator features:

• Content-Based and Header-Based Routing
• Synchronous and Asynchronous Interactions
• Sequential and Parallel Routing of Messages
• Transformations
• Validations
• Java Callout
• Event Handling
• Dynamic Routing
• Error Handling
• Multiple Part Message Support
• Mediator Echo Support

Oracle Mediator provides support for setting rules based on message payload or message headers. You can select elements or attributes from the message payload or the message header and based on the values, you can specify an action. For example, Mediator receives a file from an application or service containing data about new customers. Based on the country mentioned in the customer's address, you can route and deliver data to the database storing data for that particular country. Similarly, you can route a message based on the message header.

• Synchronous and Asynchronous Interactions

Oracle Mediator provides support for synchronous and asynchronous request response interaction. In a synchronous interaction, the client requests for a service and then waits for a response to the request. In an asynchronous interaction, the client invokes the service but does not wait for the response. You can specify a timeout period for an asynchronous interaction, which can perform some action, such as raise an event or start a process. Sequential and Parallel Routing of Messages

A routing rule execution type can be either parallel or sequential. You can configure the execution type from Routing Rules panel.

• Transformations

Oracle Mediator supports data transformation from one XML schema to another. This feature enables data interchange among applications using different schemas. For example, you can transform a comma-delimited file to the database table structure.

• Validations

Oracle Mediator provides support for validating the incoming message payload by using a Schematron or an XSD file. You can specify Schematron files for each inbound message part and Oracle Mediator can execute Schematron file validations for those parts.

• Java Callout

Oracle Mediator provides support for Java callout. Java callouts enable the use of Java code, together with regular expressions.

• Event Handling

An event is message data sent because of an occurrence of an activity in a business environment. Oracle Mediator provides support for subscribing to business events or raising business events. You can subscribe to a business event that is raised when a situation of interest occurs. For example, you can subscribe to an event that is raised when a new customer is created and then use this event to start a business process such as sending confirmation email. Similarly, you can raise business events when a situation of interest occurs. For example, raise a customer created event after completing the customer creation process.

• Dynamic Routing

Dynamic Routing separates the control logic, which determines the path taken by the process, from the execution of the process. You can create a dynamic routing rule from the Mediator Editor.

• Error Handling

Oracle Mediator supports both fault policy-based and manual error handling. A fault policy consists of conditions and actions. Conditions specify the action to be carried out for a particular error condition.

• Mediator Echo Support

Oracle Mediator supports echoing source messages back to the initial caller after any transforms, validations, assignments, or sequencing are performed.

• Multiple Part Message Support

Oracle Mediator supports messages consisting of multiple parts. Some Remote Procedure Call (RPC) web services contain multiple parts in the SOAP message.

Difference between Mediator and BPEL

You have many tools to use in a composite, and they may overlap for some cases. Mediator is particularly useful for content based routing of events, and as a listener for events. BPEL of course offers more possibilities for business logic and would generally be suited to defining process logic. A more complex SOA composite likely includes both components and others as well.

Mediator serves the purpose of a bus. It can be best utilized when used for routing. It can do routing based on many parameters and the best part is, the routing rules can be modified at runtime, thus giving the flexibility to choose the target at any point in time.

BPEL

1) Complex Logic

2) Good Support language in form of”activities”

3) Performance wise very slow

4) Support of Dehydration and Instance Monitoring

5) For Long Running process BPEL is the Right Solution

6) To implement the controlled Transactions

Integration of Rules Engine and Human Workflow

7) To implement the service virtualization BPEL is not the right approach

Mediator

1) Less Complex Logic

2) Less Support

3) Three times faster than BPEL

4) No support of de hydration

 5) For Long Running process not a proper solution

6) You cannot control the transactions in Mediator.

7) Mediator is the right approach for the service virtualization

Virtualization – Service virtualization provides companies with the ability to create virtual services that offer a stable interface (location, transport, standards, policies, messages) even when the physical service changes.  Virtualization offers high-availability and load-balancing, performance and SLA monitoring and management, routing, versioning, and mediation capabilities to mitigate the impact of change at the provider on service consumers.

Mediator is used for Transformation and Routing.

Routing------------------Static routing and Dynamic Routing

Static----------------Serviced Based & Event Based

Dynamic------------Business Rules

• Oracle Enterprise Service Bus (OESB)

• Old „ESB“–OESB was the primary ESB prior to BEA acquisition.

• After acquisition of BEA its role is to provide mediation services between SOA Suite components

• In 11g this will be known as the Mediator and acts as a component in an SCA assembly

• OESB is the only ESB available if running on a non-Weblogic server

• Oracle Service Bus (OSB)

• Previously known as BEA Aqualogic Service Bus (ALSB)

• Oracle’s primary service bus

• 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

• Can be used independently, without SOA Suite

Mediator vs. Oracle Service Bus (OSB)

• Mediator

• The “tiny”, “light weight” service bus

• Limited to simple Mediator functionality for the implementation of the VETRO pattern

• V alidade

• E nrich

• T ransform

• R oute

• O perate

• Value Mapping and Cross-Reference Table for supporting the canonical datamodel

• Development through JDeveloper IDE

• Event Delivery Network for Publish-Subscribe semantic

• Message Transformation with XSLT

• Can be used and deployed as a SCA component

• Oracle Service Bus (OSB)

• The large, powerful service bus

• Extended functionality important for enterprise-wide Integration, like

• Message Throttling

• Service Pooling

• Reliable Messaging

• Development through Eclipse IDE or Web Console

• Message Transformation over XQuery and XSLT

• OSB specific deployment

• Not yet integrated with SCA