Recent Blog Entries

Tuesday, 17 August 2010

The program of this years DOAG 2010 Conference from Nov 16 to 19,2010 in Nuremberg, Germany is online!See http://www.doag.org/konferenz/doag/2010/programm (currently German only)Please don't miss my presentation on day 2 (Nov 17th) about "Oracle BPEL PM - Performance Tuning and Clustering Best Practises".

Monday, 16 August 2010

Overview

The previous sample (Part 2) only contained a call to one web service from a SOA composite. It really gets interesting only when multiple distributed web services join one atomic transaction. To be able to execute this including rollbacks, we will implement 2 web services using SOA composites and the Oracle Database adapter.

Lets assume we have a CRM System (CustomerService) and and Order Fulfillment System (OrderService). The requirement should be that an order is only stored in the Order System if the customer has been stored successfully in the CRM system. Also, if a new order is placed incorrectly, the customer should not be stored in the CRM System.

Please be aware that with a single Weblogic server domain and when not using TcpMon, you will not see any WS-AT transactions because the local optimization kicks in and SOAP will not be used….

Lets design first the CustomerService. You can find the complete source code here. (Again please click on any image to enlarge)

Select the db connection and schema wstest which you have created before and select CUSTOMERS as target. Select Insert or Update as operation. After the DB Adapter wizard, create an Input Variable as inidicated below:

Your SOA Composite should now look like:

Edit the BPEL Process to insert an Invoke activity to call the newly created Partnerlink:

Use a Transform activity before the Invoke to map the input parameters to the variables of the Invoke:

You now can deploy and test the CustomerService using the SOA Console Test Page and should see a inserted row in the customers table.

Design and test of the OrderService

Repeat each step of CustomerService to create a similar OrderService. Just select in the DB Adapter Wizard the table ORDERS.

In addition to the CustomerService I have selected the genuid function as input for the orderid variable. So add an additional copy rule in an Assign activity before the Transform.

This leaves only the Order Item Description as input (for simplicity each time “one “ is assumed for the order amount).

The resulting SOA composite should look like

Deploy and the the OrderService using the SOA Console and verify that an Order has been created in the ORDERS table.

Configure TcpMon

Start TcpMon with 8081 as forwarding port and the server:port where you have deployed the CustomerService (i.e. http://localhost:7001) as target.

Testing both webservice in one atomic transaction

Create a new SOA composite CreationService using a synchronous BPEL component which calls both web services – CustomerService and OrderService – sequentially:

Insert 2 web service references in the right side of the SOA composite editor and enter the WSDL URLs of CustomerService and OrderService – but be sure to use the port where TcpMon listens (8081).

Edit the XSD of CreationService and modify it to use customerid, firstname, lastname and orderitem as input parameters.

Then edit the BPEL process, insert 2 Invoke activities, calling the Partnerlinks – first for CustomerService, then Orderservice.

Map the variables so that customerid, firstname and lastname are fed into teh input variable for CustomerService and orderitem for OrderService.

Last 2 steps are:

Insert bpel.config.transaction=RequiresNew (or Required) in the CreationService BPEL component to start the transaction when the composite is called (see Part 2).

Modify the WS-AT settings to a MANDATORY transaction flow

Now you can deploy and test the CreationService.

Try first one Order Item (a arbitrary string) with less than 20 characters. This should create a new customer and a new order.

Then try with an Order Item string longer than 20 chars: this results in an SQL exception at the OrderService call and also roll backs the CustomerService as designed:

Friday, 13 August 2010

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 11.1.1.3 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:

Testing and Debugging WS-Atomic Transactions

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:

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!

Troubleshooting

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

Caused by: javax.xml.ws.soap.SOAPFaultException: transaction context is required to be inflowed at oracle.j2ee.ws.client.jaxws.DispatchImpl.throwJAXWSSoapFaultException(DispatchImpl.java:955) at oracle.j2ee.ws.client.jaxws.DispatchImpl.invoke(DispatchImpl.java:750) at oracle.j2ee.ws.client.jaxws.OracleDispatchImpl.synchronousInvocationWithRetry(OracleDispatchImpl.java:234) at ...

Thursday, 12 August 2010

To make it clear at first: I am not a fan of web service transactions. They contradict the principle of loose coupling in a SOA. But it is like with XA and 2PC – there are situations where you want to use them or where it is almost mandatory.

In SOA there have been concepts like compensation in BPEL to avoid atomic transactions spanning several SOAP calls (before they were possible and available technically) but some business requirements do not allow to commit at first and undo later on.

Also, Oracle SOA Suite optimizes local calls, so transactions were possible over multiple service invocations if they are on the same application server instance (see optSoapShortcut property in 10g)

To allow web services with SOAP using transactions like in EJB-based distributed applications the following standards have been published by OASIS (http://www.oasis-open.org/specs/):

The latest version 1.2 was published in February 2009 and WS-Coordination and WS-AtomicTransaction support started in Weblogic Server 11gR1 (10.3.3) and Oracle Soa Suite 11g PS2 (11.1.1.3). WS-BusinessActivity is for long running business transactions and therefore not covered here.

With WS-AtomicTransaction (abbreviated WS-AT) it is possible to call another web service (callee) from a web service (caller) within the same transaction. The transaction context is passed to the other web service via soap in a CoordinationContext structure in the SOAP header. Some other components work together as outlined here to let the second web service participate in the transaction.

Let’s have a look at how you can setup a transaction spanning 2 or more web services.

The first scenario we will look at is when you have implemented 2 web service based on JAX-WS EJBs in Weblogic and you want to call the one from the other.

A good startup example for WS-AtomicTransaction is included in the Weblogic Server 11gR1 installation when you select custom install and include the "Server Samples” for installation. Then you can move to %WLS_HOME%\wlserver_10.3\samples\server\examples\src\examples\webservices\jaxws\wsat.

After setting the examples environment, compiling and deploying with ant you will see the Bank application:

You can enter for example local account number 100 and remote account number 100 with initial amounts of 100 USD.Then try to transfer 20 USD from local to remote account. This is done in one atomic transaction.

The application consists of one servlet which makes modifications on the local account and then calls the web service for the remote located at

About Me

Stefan is a leading SOA architect within Oracle. He has more than 15 years experience in delivering complex projects on Oracle platforms. Since 1997 he has specialized in J2EE and middleware. Since 2004 Stefan is architecting complex SOA solutions and in 2011 moved to the Fusion Middleware Architects Team (A-Team) within Oracle Product Development.