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

BPEL Activities & Components

Introduction to Activities and Components

When you expand SOA Components in the Component Palette of Oracle BPEL Designer, service components are displayed. Figure shows the components that display for a BPEL 1.1 process. A BPEL 2.0 process also shows the same components.

Figure A-1 SOA Components

Introduction to BPEL 1.1 and 2.0 Activities

This section provides a brief overview of BPEL activities and provides references to other documentation that describes how to use these activities.
Oracle BPEL Designer includes BPEL 1.1 and BPEL 2.0 activities that are available for adding in a BPEL process. These activities enable you to perform specific tasks within a process. Some activities are available in both BPEL 1.1 and BPEL 2.0. Others are available in only BPEL 1.1 or BPEL 2.0.
To access these activities, go to the Component Palette of Oracle BPEL Designer. The activities display under either of two categories:

·         BPEL Constructs: Displays core activities (also known as constructs) provided by standard BPEL 1.1 and 2.0 functionality. The activities in this category are displayed under additional subcategories of Web Service, Activities, and Structured Activities in BPEL 1.1 and Web Service, Basic Activities, and Structured Activities in BPEL 2.0.

·         Oracle Extensions: Displays extension activities that add value and ease of use to BPEL 1.1 and 2.0 functionality

1.Assign Activity

This activity provides a method for data manipulation, such as copying the contents of one variable to another. Copy operations enable you to transfer information between variables, expressions, endpoints, and other elements.

• Provides a way to copy data between variables in a BPEL Process
• One of the ways you can copy data from source to target in a BPEL Process.

<assign name=“Assign_1”>

• When you Double Click the Activity Icon. Assign popup window will appear you can perform following operation
• Copy , Append, insert  and Remove

• Copy operation

2.Compensate Activity

This activity invokes compensation on an inner scope activity that has successfully completed. This activity can be invoked only from within a fault handler or another compensation handler. Compensation occurs when a process cannot complete several operations after completing others. The process must return and undo the previously completed operations. For example, assume a process is designed to book a rental car, a hotel, and a flight. The process books the car and the hotel, but cannot book a flight for the correct day. In this case, the process performs compensation by unbooking the car and the hotel. The compensation handler is invoked with the compensate activity, which names the scope on which the compensation handler is to be invoked.

Below Figure shows the Compensate dialog in BPEL 1.1. You can perform the following tasks:

·         Click the General tab to provide the activity with a meaningful name.

·         Select the scope activity on which the compensation handler is to be invoked.

Figure Compensate Dialog

In BPEL 2.0, the Compensate dialog does not include a Skip Condition tab.

3. Email Activity

This activity enables you to send an email notification about an event.
For example, an online shopping business process of an online bookstore sends a courtesy email message to you after the items are shipped. The business process calls the notification service with your user ID and notification message. The notification service gets the email address from Oracle Internet Directory.
Figure A-11 shows the Email dialog in BPEL 1.1 and BPEL 2.0.

Figure A-11 Email Dialog

4. Empty Activity

This activity enables you to insert a no-operation instruction into a process. This activity is useful when you must use an activity that does nothing (for example, when a fault must be caught and suppressed).

Figure a-12 Empty Dialog

In BPEL 2.0, the Empty dialog includes a Documentation tab and does not include a Skip Condition tab.

5. Flow Activity

This activity enables you to specify one or more activities to be performed concurrently. A flow activity completes when all activities in the flow have finished processing. Completion of a flow activity includes the possibility that it can be skipped if its enabling condition is false.
For example, assume you use a flow activity to enable two loan offer providers (United Loan service and Star Loan service) to start in parallel. In this case, the flow activity contains two parallel activities – the sequence to invoke the United Loan service and the sequence to invoke the Star Loan service. Each service can take an arbitrary amount of time to complete their loan processes.
Figure A-14 shows an initial flow activity with its two panels for parallel processing. You drag activities into both panels to create parallel processing. When complete, a flow activity looks like that shown in Figure A-15.

Figure A-14 Flow Dialog (At Time of Creation)

Description of "Figure A-14 Flow Dialog (At Time of Creation)"

Figure A-15 Flow Dialog (After Design Completion)

You can also synchronize the execution of activities within a flow activity. This ensures that certain actives only execute after other activities have completed.

Note: Oracle’s BPEL implementation executes flows in the same, single execution thread of the BPEL process and not in separate threads.

6. FlowN Activity

This activity enables you to create multiple flows equal to the value of N, which is defined at runtime based on the data available and logic within the process. Index variable increments each time a new branch is created, until the index variable reaches the value of N.
Figure A-16 shows the FlowN dialog.

Figure A-16 FlowN Dialog

 

 

7. Invoke Activity

This activity enables you to specify an operation you want to invoke for the service (identified by its partner link). The operation can be one-way or request-response on a port provided by the service. You can also automatically create variables in an invoke activity. An invoke activity invokes a synchronous web service or initiates an asynchronous web service.
The invoke activity opens a port in the process to send and receive data. It uses this port to submit required data and receive a response. For synchronous callbacks, only one port is needed for both the send and the receive functions.
The invoke activity supports the bpelx: inputProperty and bpelx: outputProperty that facilitate the passing of properties through the SOAP header and the obtaining of SOA runtime system properties for useful information such as the tracking.compositeInstanceId and tracking.conversationId.
Figure A-20 shows the Invoke dialog in BPEL 1.1. You can perform the following tasks:

·         Provide the activity with a meaningful name.

·         Select the partner link for which to specify an operation.

·         Select the operation to be performed.

·         Automatically create a variable or select an existing variable in which to transport the data (payload).

Figure A-20 Invoke Dialog

 

 

8. Java Embedding Activity

This activity enables you to add custom Java code to a BPEL process using the Java BPEL exec extension bpelx: exec. This is useful when you have Java code that can perform a function, and want to use this existing code instead of starting over. In BPEL 2.0 projects, the bpelx: exec extension and Java code are wrapped in an <extension Activity> element.

• This activity enables you to add custom Java code to a BPEL process using the Java BPEL exec extension <bpelx:exec>.
• When user double clicks on the Java embedding icon, popup window will appear and user can enter the java code on it.

9. Notification Activities

• This activity enables you to send notification about an event to a user, group, or destination address.
• You can send a notification by e-mail, voice mail, fax, pager, or short message service (SMS).

 

10. Partner Link Activity

This service enables you to define the external services with which your process interacts. A partner link type characterizes the conversational relationship between two services by defining the roles played by each service in the conversation and specifying the port type provided by each service to receive messages within the conversation. For example, if you are creating a process to interact with a Credit Rating Service and two loan provider services (United Loan and Star Loan); you create partner links for all three services.
Figure A-22 shows the Partner Link dialog in BPEL 1.1. You provide the following details:

·         A meaningful name for the service.

·         The web services description language (WSDL) file of the external service.

·         The actual service type (defined as Partner Link Type).

·         The role of the service (defined as Partner Role).

·         The role of the process requesting the service (defined as My Role).

Figure A-22 Partner Link Activity

11. Pick Activity

This activity waits for the occurrence of one event in a set of events and performs the activity associated with that event. The occurrence of the events is often mutually exclusive (the process either receives an acceptance or rejection message, but not both). If multiple events occur, the selection of the activity to perform depends on which event occurred first. If the events occur nearly simultaneously, there is a race and the choice of activity to be performed is dependent on both timing and implementation.
The pick activity provides an OnMessage branch. When you double-click the OnMessage icon in BPEL 1.1, the dialog shown in Figure A-24 appears.

Figure A-24 OnMessage Dialog

The two branches of the pick activity are as follows:

·         onMessage (automatically displays below the Pick activity icon)

Contains the code for receiving a reply, for example, from a loan service.

·         onAlarm (does not automatically display; you must manually add this branch by selecting the Pick activity icon and clicking the Add OnAlarm icon)

Contains the code for a timeout, for example, after one minute.

Whichever branch completes first is executed; the other branch is not executed. The branch that has its condition satisfied first is executed.
Figure A-25 shows the OnAlarm dialog of the pick activity in BPEL 1.1.

Figure A-25 OnAlarm Branch Dialog of a Pick Activity

.

Note: You can also create onMessage branches in BPEL 1.1 scope activities and onAlarm branches in BPEL 1.1 and 2.0 scope activities. Expand the Scope activity in Oracle JDeveloper, and browse the icons on the left side to find the branch you want to add.

If you add correlations to an OnMessage branch, the correlations syntax is placed after the assign activity syntax. The correlation syntax must go before the assign activity.
As a work around, perform the following steps:

1.     Create a correlation set in Oracle JDeveloper.

2.     Assign this to the OnMessage branch.

3.     Complete the remaining design tasks.

4.     Before making or deploying the BPEL process, move the correlation syntax before the assign activity in the BPEL

12. Receive Activity

This activity specifies the partner link from which to receive information and the port type and operation for the partner link to invoke. This activity waits for an asynchronous callback response message from a service, such as a loan application approver service. While the BPEL process is waiting, it is dehydrated (compressed and stored) until the callback message arrives. The contents of this response are stored in a response variable in the process.The receive activity supports the bpelx:property extensions that facilitate the passing of properties through the SOAP header, and the obtaining of SOA runtime system properties for useful information such as tracking.compositeInstanceId and tracking.conversationId.
Figure A-26 shows the Receive dialog in BPEL 1.1. You can perform the following tasks:

·         Provide a meaningful name.

·         Select the partner link service for which to specify an operation.

·         Select the operation to be performed.

·         Automatically create a variable or select an existing variable in which to transport the callback response.

·         Figure A-26 Receive Dialog

13. Reply Activity

This activity allows the process to send a message in reply to a message that was received through a receive activity. The combination of a receive activity and a reply activity forms a request-response operation on the WSDL port type for the process.Figure A-31 Reply Dialog

14. Rethrow Activity

This activity enables you to rethrow a fault originally captured by the immediately enclosing fault handler.

Note: This activity is only supported in BPEL 2.0 projects.

Figure A-32 shows a rethrow activity within a fault handler (catch activity).

Figure A-32 Rethrow Activity

15. Scope Activity

This activity consists of a collection of nested activities that can have their own local variables, fault handlers, compensation handlers, and so on. A scope activity is analogous to a { } block in a programming language.Each scope has a primary activity that defines its behavior. The primary activity can be a complex structured activity, with many nested activities within it to arbitrary depth. The scope is shared by all the nested activities.

Figure A-33 Scope Dialog

Fault handling is associated with a scope activity. The goal is to undo the incomplete and unsuccessful work of a scope activity in which a fault has occurred. You define catch activities in a scope activity to create a set of custom fault-handling activities. Each catch activity is defined to intercept a specific type of fault.

Figure A-34 shows the Add Catch icon inside a scope activity. Figure A-35 shows the catch activity area that appears when you click the Add Catch icon. Within the area defined as Drop Activity Here, you drag additional activities to create fault handling logic to catch and manage exceptions. For example, a client provides a social security number to a Credit Rating service when applying for a loan. This number is used to perform a credit check. If a bad credit history is identified or the social security number is identified as invalid, an assign activity inside the catch activity notifies the client of the loan offer rejection. The entire loan application process is terminated with a terminate activity.

Figure A-34 Creating a Catch Branch

Figure A-35 Catch Activity Icon

16. Sequence Activity

This activity enables you to define a collection of activities to be performed in sequential order. For example, you may want the following activities performed in a specific order:

·         A customer request is received in a receive activity.

·         The request is processed inside a flow activity that enables concurrent behavior.

·         A reply message with the final approval status of the request is sent back to the customer in a reply activity.

A sequence activity makes the assumption that the request can be processed in a reasonable amount of time, justifying the requirement that the invoker wait for a synchronous response (because this service is offered as a request-response operation).
When this assumption cannot be made, it is better to define the customer interaction as a pair of asynchronous message exchanges.
When you double-click the Sequence icon, the activity area shown in Figure A-36 appears. Drag and define appropriate activities inside the sequence activity.

Figure A-36 Sequence Activity

17. Switch Activity

This activity consists of an ordered list of one or more conditional branches defined in a case branch, followed optionally by an otherwise branch. The branches are considered in the order in which they appear. The first branch whose condition is true is taken and provides the activity performed for the switch. If no branch with a condition is taken, then the otherwise branch is taken. If the otherwise branch is not explicitly specified, then an otherwise branch with an empty activity is assumed to be available. The switch activity is complete when the activity of the selected branch completes.
A switch activity differs in functionality from a flow activity. For example, a flow activity enables a process to gather two loan offers at the same time, but does not compare their values. To compare and make decisions on the values of the two offers, a switch activity is used. The first branch is executed if a defined condition (inside the case branch) is met. If it is not met, the otherwise branch is executed.

Figure A-39 Switch Activity

18. Terminate Activity

A terminate activity enables you to end the tasks of an activity (for example, the fault handling tasks in a catch branch). For example, if a client's bad credit history is identified or a social security number is identified as invalid, a loan application process is terminated, and the client's loan application document is never submitted to the service loan providers.

Note:

Figure A-40 shows several terminate activities in the otherwise branch of a switch activity.

Figure A-40 Terminate Activity

19. Throw Activity

This activity generates a fault from inside the business process.
Figure A-41 shows the Throw dialog.

Figure A-41 Throw Dialog

20. Transform Activity

This activity enables you to create a transformation that maps source elements to target elements (for example, incoming purchase order data into outgoing purchase order acknowledgment data).
Figure A-42 shows the Transform dialog in BPEL 1.1. This dialog enables you to perform the following tasks:

·         Define the source and target variables and parts to map.

·         Specify the transformation mapper file.

·         Click the second icon (the Add icon) to the right of the Mapper File field to access the XSLT Mapper for creating a new XSL file for graphically mapping source and target elements. Click the Edit icon (third icon) to edit an existing XSL file.

Figure A-42 Transform Dialog

.

21. Wait Activity

This activity allows a process to specify a delay for a certain period or until a certain deadline is reached. A typical use of this activity is to invoke an operation at a certain time. This activity enables you to wait for a given time period or until a certain time has passed. Exactly one of the expiration criteria must be specified.

Figure A-46 Wait Dialog

22. While Activity

This activity supports repeated performance of a specified iterative activity. The iterative activity is repeated until the given while condition is no longer true.

Figure A-47 While Dialog