Lesson02-Mediator

Let us see how we can utilize features of Mediator component (previously known as Oracle ESB) to implement the following use-case.

MyBay is a fictious online store that lets customers view and place orders over the internet. MyBay utilizes its logistics partner MyDel to ship orders to customers. IT systems to handle order processing are created and maintained by MyDel.

MyBay can post order information to MyDel through MyBay’s online portal using Webservices. MyBay can also batch orders and transfer the file across to MyDel using FTP.

Step 1: Design Enterprise Business Objects (EBO)
First step is to create our canonical model. We need to carefully think through data, task and functional elements so as to maximize re-usability and minimize data transformation.
Namespace: Qualify schema with a meaningful namespace. Usually this takes the form of http://<your_website_url>/<organization>/<function>/xsd/
In our case, we’ll name it http://orafmwschool.com/training/mediator/xsd/OrderProcessing

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://orafmwschool.com/training/mediator/xsd/OrderProcessing"
targetNamespace="http://orafmwschool.com/training/mediator/xsd/OrderProcessing"
elementFormDefault="qualified">

Schema Elements: At a very minimum, we need information about selected item, transaction date and address it needs to be shipped to.

<xsd:element name="orderDetails" type="tOrderDetails"/>
<xsd:complexType name="tOrderDetails">
<xsd:sequence>
<xsd:element ref="itemDetails"/>
<xsd:element ref="transactionDate"/>
<xsd:element ref="shipTo"/>
</xsd:sequence>
</xsd:complexType>

Complete Order.xsd schema can be found here. Copy this XSD file into “xsd” directory of the project.
Step 2: Design Enterprise Business Message (EBM)
Enterprise Business Message is a wrapper over EBO. It usually combines one or more elements from EBO to create a meaningful input and output messages for the SOA services. In the current example, we’ll create two message elements: OrderDetailsRequest and OrderDetailsResponse. However, we need to refer to Order.xsd in order to use elements defined in the EBO.

<xsd:import
namespace="http://orafmwschool.com/training/mediator/xsd/OrderProcessing"
schemaLocation="Order.xsd"/>

<xsd:element name="orderDetailsRequest" type="tOrderDetailsRequest"/>
<xsd:complexType name="tOrderDetailsRequest">
<xsd:sequence>
<xsd:element ref="ord:orderDetails"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="orderDetailsResponse" type="tOrderDetailsResponse"/>
<xsd:simpleType name="tOrderDetailsResponse">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="SUCCESS"/>
<xsd:enumeration value="FAILURE"/>
</xsd:restriction>
</xsd:simpleType>

Complete OrderProcessingEBM.xsd can be found here. Copy this file to “xsd” directory of the project.

Step 3: Design abstract WSDL interface
Next step is to create an abstract Webservice interface that can be used in SOA services. In our case, we shall create two message elements: OrderDetailsRequestMessage and OrderDetailsResponseMessage.

<message name="OrderDetailsRequestMessage">
<part name="payload" element="ebm:orderDetailsRequest"/>
</message>

<message name="OrderDetailsResponseMessage">
<part name="payload" element="ebm:orderDetailsResponse"/>
</message>

Now that we have request and response messages created, we shall create an operation that consumes these messages.

<portType name="WSReadOrder">
<operation name="ReadOrder">
<input message="tns:OrderDetailsRequestMessage"/>
<output message="tns:OrderDetailsResponseMessage"/>
</operation>
</portType>

Complete OrderProcessing.wsdl can be found here. Do observe the xsd import element to import schema from MDS.
Step 4: Creating SOA Composite
Shown below is the snapshot of the composite we are eventually going to create. On the left side of the picture, you can see two services:

1. Service to read order details from File. OrderFTPABCS will then transform order records into canonical form before passing them to OrderABCS.
2. Webservice that external customers can invoke to post order details. These details are read directly in canonical form.

On the right side of the picture, we can see OrderManagementDBAdapter service that updates order details into Order Management Database. OrderABCS acts as a glue between all these services.

Proceed to Mediator Example Implementation.