Recent Blog Entries

Friday, 13 August 2010

Web Service Transactions Part 2: WS-AtomicTransaction with SOA Composite calling EJB-Web Service

In the first part we have looked at web service transactions between JAX-WS web services without any SOA composite/component.

The next scenario where we will look at is a SOA composite calling the web service WsatBankTransferService deployed in part 1. (click on each image to display in full quality):


Enable WS-AT on the SOA domain

The installation of the Patch Set of Oracle SOA unfortunately does not update the file policy-accessor-config.xml in the created domain or WLS instance to the required WS-AT settings.

The definition of policy interceptors is however mandatory for WS-AT to work. If you did not configure anything in policy-accessor-config.xml yourself, this means that you will need to replace your version of the file with this version. (The original file can the found here for comparison).

Rename you file to .old and copy the downloaded file to the directory. Restart the Weblogic server.

Design and Deploy the Composite

First start the Weblogic samples server and use a port different than the SOA instance. I use port 8001 for the examples WLS domain and port 7001 for the admin server where the soa domain is deployed.

Then start TcpMon – to be able to monitor the SOAP request lateron and tunnel all request from port 8081 to port 8001:


We will create a BPEL based SOA composite with the SOA designer.

Create a new SOA project and a new composite with a BPEL component. Choose a synchronous BPEL process type and name it like you want. 

After that, drop a web service from the resource palette into the right part of the composite editor to create a reference. Fill in the details of the WsatBankTransferService but use the port set with TcpMon. Paste the WSDL URL of the WsatBankTransferService into the form and select MANDATORY and DEFAULT for WS-AT transaction propagation and version


Next edit the bpel process to include a Invoke activity for “CreateAccount” using the newly created Partnerlink and pass the input parameter with an Assign activity to the invoke:


The result should look like:


Now you can deploy and test the composite, right?

No, because at this point, the BPEL component would not automatically start a transaction. To achieve this, edit the composite.xml and insert the bpel.config.transaction property like:

<component name="WSATBPELClient">
  <implementation.bpel src="WSATBPELClient.bpel"/>
  <property name="bpel.config.transaction"
       many="false" type="xs:string">requiresNew</property>
<reference name="BankAccountService"
  <interface.wsdl interface=""/>
  < port=""
    <property name="weblogic.wsee.wsat.transaction.flowOption"
              type="xs:string" many="false">MANDATORY</property>
    <property name="weblogic.wsee.wsat.transaction.version" type="xs:string"

At this point it does not matter if you used “RequiresNew” or “Required”, any of the two will start a new transaction because we do not pass any to the inbound “client” partnerlink.

Now you can deploy the composite to the SOA domain.

Testing and Debugging WS-Atomic Transactions

Execute the composite in the EM Test page (http://host:7001/em)

You should see a successfully completed instance and several SOAP or https calls in TcpMon. The latest should be the SOAP request to create the account – with the same WS-Coordination Context as seen in part 1:

<env:Envelope xmlns:env=""
        <instra:tracking.ecid xmlns:instra="">0000Id_N1rj3n3WjLxZR8A1COuk800001X</instra:tracking.ecid>
        <instra:tracking.conversationId xmlns:instra="">urn:73432EF0A5E911DFBFAC43B9B866DC33</instra:tracking.conversationId>
        <instra:tracking.parentComponentInstanceId xmlns:instra="">reference:50001</instra:tracking.parentComponentInstanceId>
    <ns3:CoordinationContext xmlns:ns3=""
          <wls-wsat:txId xmlns:wls-wsat="
          <wls-wsat:routing xmlns:wls-wsat="
    <createAccount xmlns="">wwewe</createAccount>

Debugging of all WS-AT related actions on server-side can be switched on with the java command line flag


You will see a lot of 2PC handshake requests like for example:

<WseeWsat> <BEA-224575> <WS-AT transaction id is BEA1-45D0D4EFBBE0B5C280E1 and time to live is 299,000 for transaction Name=…

<WseeWsat> <BEA-224504> <registerOperation entered with …

<WseeWsat> <BEA-224503> <Registering Durable2PC Participant

<WseeWsat> <BEA-224538> <Durable2PC WS-AT Participant created for Address

<WseeWsat> <BEA-224539> <Prepare called for Address

<WseeWsat> <BEA-224603> <Successfully created participant port

<WseeWsat> <BEA-224602> <Durable participant port placed in cache for

<WseeWsat> <BEA-224510> <preparedOperation Xid:

<WseeWsat> <BEA-224511> <preparedOperation exited with Notification

<WseeWsat> <BEA-224546> <Commit called for Address

<WseeWsat> <BEA-224590> <About to send commit for durable participant with Xid

<WseeWsat> <BEA-224518> <committedOperation entered with Notification

<WseeWsat> <BEA-224591> <Commit sent for durable participant with Xid

<WseeWsat> <BEA-224547> <Commit call received reply COMMITTED before wait was entered for Address

<WseeWsat> <BEA-224583> <Durable participant port removed from cache

<WseeWsat> <BEA-224584> <Durable participant XAResource removed from cache

Monitoring and Management

In the SOA Control web administration frontend, you can set or change the WS-AT settings for all endpoints. Right-click on the SOA composite and select “Service/Reference Properties”:


In our case, we only see the client-side composite endpoint because we do not have a SOA on the callee side.

Under “Properties” you have access to the Transaction Flow and WS-AT Version settings.


For the JAX-WS Webservice published on the Samples Server you can see the settings in the WLS console:


Navigate to the webservicesWsatSimpleEar deployment, expand the WsatBankTransferService web service and click on it. You will see the WS-AT setting under “Configuration”, “Ports”:


Click on any operation or the whole web service to modify this:


You can also verify the WS-AT setting in the WSDL on the web service:

If you look at the WSDL then you see for every binding the attached WS-AT policy:

<operation name="createAccount">
   <wsp:PolicyReference URI="#WSAT10"/>

This scenario was a single operation “CreateAccount”. In the next part we will create a sample using 2 SOA composites being called by another composite in one atomic transactions. Both callees use DBAdapter, so we can play around with rollbacks easily.

Stay tuned!


If you receive the following exception when testing the composite, then you did not copy the new policy-accessor-config.xml

Caused by: transaction context is required to be inflowed at at at at ...

No comments:

Post a Comment