OSB 11g Asynchronous Request Response with 11gR1 SOA Composite

SOA 11gR1 now provides the soa-direct transport which makes it possible to use the RMI based transactional Weblogic T3 Protocol to communicate between OSB and SCA. I am not quite sure how much this is different from the sb transport already available with the earlier versions, but the current SOA 11gR1 version insists that the recommended twisted approach is to use a combination of both soa-direct and sb for the Asynchronous Request Response pattern.

The Request from OSB to SCA is sent via soa-direct transport while the callback from SCA to OSB happens via the sb transport. In essence, the flow comprises two one-way OSB flows: one for the request and the other for the response.

I fail to understand why a combination of sb and soa-direct transports are required.

Let’s go about creating it then. In our sample use case, we will use OSB to mediate between an Asynchronous Composite (Creq) and an Asynchronous Provider (Cprov). The requestor composite sends a Name, ID pair to the provider which responds back with a ‘Hello ‘+Name+’ Your ID is ‘+ID message. The OSB mediation comprises four artifacts a Requestor Proxy (P1), a Requestor Business Service (B1), a Callback Proxy (P2) and finally a Callback Business Service (B2).

Note that unlike BPEL, OSB has no OOTB support for Asynchronous Request Response Correlation and hence, this is achieved explicitly by using the WS-Addressing SOAP Header elements viz. ReplyTo and ReferenceParameters. I am assuming that you are already familiar with these WS-Addressing parameters.

The sequence of tasks to be performed for this Sample is:

  1. Create the Asynchronous Composite Provider (Cprov).
  2. Create the Requestor Business Service (B1).
  3. Create the Callback Business Service (B2).
  4. Create the Callback Proxy Service (P2)
  5. Create the Requestor Proxy Service (P1)
  6. Create the Asynchronous Composite Provider (Creq).

If you really don’t want to create the samples, and are more worried about the actual settings, this is the core of things happening:

  1. The Composite Requestor is based on a BPEL process that uses content based correlation.
  2. P1 receives the callback address of the Composite Requestor and stores the same in the WS-Addressing ReferenceParameters so that it gets echoed back by the Composite Provider during the Callback as a SOAP element. Also it specifies the URI of P1 to which the Provider Composite sends the callback.
  3. Requestor Business Service B1 is configured as an Asynchronous Client without any Callback Address as this gets set in Step 1.
  4. The Callback Proxy P2 receives the address of Composite Requestor in the SOAP Header and sets this in the URI of the routing options.
  5. Callback Business Service B2 is configured as an Asynchronous Callback Service and based on the URI set in Step 3, makes the callback to the Composite Requestor.

1.  Create the Asynchronous Composite Provider (Cprov):  This Composite consists of an Async BPEL Process and a Direct Binding adapter based exposed service.

The AsyncBPELProvider process receives input based on the following schema and returns a result together with the ID for correlation.

2. The Requestor Business Service B1 consumes the WSDL of the Asynchronous Composite Provider at the Direct Service Request Binding Port SOAP 1.1.

In the SOA Direct Configuration page, we set this service as an Asynchronous Client Service. We will not set the Callback service as this will be set by the Requestor Proxy Service later and make sure the WS-Addressing Version is http://www.w3.org/2005/08/addressing.

3. Next, we create the Callback Business Service. This will also be based on the Provider Composite WSDL we created earlier. The operation is now Direct Service Callback Binding Port SOAP 1.1.

In the SOA DIRECT Service Configuration select the role as Service Callback.

Note that this inserts a default Endpoint URI in the transport setup. Don’t bother about this URI. We will override this via the Callback Proxy Service later.

4. Now, lets create the Callback Proxy Service. This service is again based on the Composite Provider’s WSDL like in the previous step. However, now we select the sb transport in the transport configuration. Note that this service will receive the client callback port in the SOAP Header as the chunk $header/osb:Callback/osb:Address/text(). This will be inserted by the Requestor Proxy as a Reference Parameter thus making the Callback Composite include it in the callback SOAP Header. We will develop this later. For now, this address is simply copied into the OSB Routing Options inside the Routing node for the Callback Business Service. Optionally we also remove the osb:Callback element from the SOAP Header.

The Outbound of the Callback Proxy Service looks something like this:
<con:endpoint name=”BusinessService$AsyncOSB2SOA$CallbackBusinessService” xmlns:con=”http://www.bea.com/wli/sb/context”&gt;
<con:request xsi:type=”soa:SOARequestMetaDataXML” xmlns:soa=”http://www.bea.com/wli/sb/transports/soa&#8221; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”&gt;
<tran:headers xsi:type=”soa:SOARequestHeadersXML” xmlns:tran=”http://www.bea.com/wli/sb/transports”&gt;
<tran:user-header name=”SOAPAction” value=”&quot;processResponse&quot;”/>
<tran:encoding xmlns:tran=”http://www.bea.com/wli/sb/transports”>utf-8</tran:encoding&gt;

The xml chunk in bold is the actual Composite Requestor’s Callback address returned as a SOAP Header by the Composite Provider.

5. Next, we will develop the Requestor Proxy Service. This Proxy is based on the same WSDL of the Async Composite Provider we have used before. The binding selected is Direct Service Request Binding SOAP 1.1.

Also we select sb as the transport for this Proxy. In the message flow there are a couple of things this service does. First, it copies the Client’s callback Address and inserts it in the WS-Addressing ReferenceParameters. Then it sets the WS-Addressing ReplyTo address with the sb transport address of the Callback Proxy Service we created in Step 4.

The resulting SOAP Header should look something like this:

<soap-env:Header xmlns:soap-env=”http://schemas.xmlsoap.org/soap/envelope/”&gt;
<wsa:ReplyTo xmlns:wsa=”http://www.w3.org/2005/08/addressing”&gt;
<osoa:callback osoa:connection-factory=”oracle.soa.api.JNDIDirectConnectionFactory” xmlns:osoa=”http://xmlns.oracle.com/soa/direct”&gt;
<osoa:property osoa:name=”java.naming.provider.url” osoa:value=”t3://localhost:7001″/>
<osoa:property osoa:name=”java.naming.factory.initial” osoa:value=”weblogic.jndi.WLInitialContextFactory”/>
<osoa:property osoa:name=”oracle.soa.api.invocation.direct.bean” osoa:value=”SOADirectInvokerBean#oracle.integration.platform.blocks.direct.Invoker”/>
<instra:tracking.ecid xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>0000IhiCI8lFw000jzwkno1Cdje_000585</instra:tracking.ecid&gt;
<instra:tracking.parentComponentInstanceId xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>bpel:660005</instra:tracking.parentComponentInstanceId&gt;
<osb:Callback xmlns:osb=”http://www.osbLabs.soaDirect”&gt;


The changed chunks are in bold. Note that the element refered by wsa:Address points to the URI of the Callback Proxy Service and the osb:Callback referes to the address of the Composite Requestor’s Callback.

6. Finally, we create the Async Composite Requestor. This composite is based on an Async BPEL Process which invokes the Requestor Proxy Service via a Direct Reference binding. In addition, it includes a WS as an exposed service for testing. For simplicity we have used the same message schema as employed by the Composite Provider we created in Step 1 and the correlation is based on the ID.

Right then, lets test this in the em console.

A)   In the Requestor Composite’s test , we specify the following input parameters:

B)   The Asynchronous Composite Provider completes as expected and the Async BPEL Provider process completes.

C) The Asynchronous Composite Requestor and the related BPEL Async Component completes as expected.

That’s all about it. The sample source is included. Follow the sequence of deployments as followed in this tutorial.

The pdf version of this tutorial is right here…

One Response to “OSB 11g Asynchronous Request Response with 11gR1 SOA Composite”
  1. sridhar says:

    Thanks for the post. I have couple of questions :

    Quoted from the blog above : “First, it copies the Client’s callback Address and inserts it in the WS-Addressing ReferenceParameters”

    1. How did you insert the clients callback address in to the soap headers wsa reference parameters. Can you please put the code or detailed steps here.

    Quoted from the blog above : “This will be inserted by the Requestor Proxy as a Reference Parameter thus making the Callback Composite include it in the callback SOAP Header. We will develop this later. For now, this address is simply copied into the OSB Routing Options inside the Routing node for the Callback Business Service. ”

    2. How did the callback proxy/business service got these reference parameters and set them in the soap header for calling client (composite requester’s right instance) ?

    I am new to OSB. I am going crazy about doing this , please help me asap.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: