COMP6017 – Advanced

Topics on Web Services

Implementation of a Transaction using Web
Services

A simple program demonstrating the use of Web Services

Interoperability Toolkit and WS transaction.

Chen, Cheng-Che
Gopalakrishnan, Eakan
Sun, Wei

Master of Science in Web Technology

School of Electronics and Computer Science,
University of Southampton
 Implement a Transaction using a Web Service

Chen Cheng-Che: cc17e09@ecs.soton.ac.uk

Gopalakrishnan, Eakan: eg5g09@ecs.soton.ac.uk
Sun Wei: ws4g09@ecs.soton.ac.uk

School of of Eletronics and Computer Science

University of Southampton

1 Web service

1.1 What is Web service?

A Web service is a software application that can be accessed remotely using different XML-based languages.
Normally, a Web Service is identified by a URL, just like any other Web site. What makes Web services
different from ordinary Web sites is the type of interaction that they can provide.
Most Web sites are designed to provide a response to a request from a person. The person either types in the
URL of the site or clicks on a hyperlink to create the request. This request takes the form of a text document that
contains some fairly simple instructions for the server. These instructions are limited to the name of a document
to be returned or a call to a server-side program, along with a few papa meters. (Figure 1.1.1)

A Web service is similar in that it is accessed via a URL. The difference lies in the content of what is sent in the
request from the client to the service. Web service clients sent an XML document formatted in a special way in
accordance with the rules of the SOAP specification. A SOAP message can contain a call to a method along
with any parameters that might be needed. In addition, the message can contain a number of header items that
further specify the intent of the client These header items might designate what Web services will get this
method call after the current service finishes its work, or they might contain security information. In any case,
the complexity of the SOAP message far exceeds the complexity that is possible using only a
browser.(Figure1.1.2)

Comparing the Figure 1.1.2 with 1.1.1 as below:

Fig. 1.1.1 A browser interacts with a Web server to make requests

Fig. 2.1.2 A client interacts with a Web service via a Web server such as Apache Tomcat or MS IIS.
1.2 How Does Web Service Work?

The basic Web services platform is XML+HTTP

XML provides a language which can be used between different platforms and programming languages and still
express complex messages and functions.
The HTTP protocol is the most used Internet protocol.
Web Services platform elements:

SOAP (Simple Object Access Protocol) – SOAP is an XML-based protocol to let applications exchange
information over HTTP, to describe it more simple, it’s a protocol for accessing a Web Service. (To
communicate)

UDDI (Universal Description, Discovery and Integration) – UDDI is a directory service where companies
can register and search for Web services. (To advertise and syndicate)

WSDL (Web Services Description Language) – WSDL is an XML-based language for locating and
describing Web services. (To describe)

Figures 1.2.1 shows how does Web service work. This is a SOA(service-oriented architecture)that provide the
theoretical model for all Web services. The simple model that contains three entitles and three operations.

Fig. 1.2.1 SOA model for web services.

 The Service Requestor is an application that wants to receive a service from another application.
 The Service Broker is a well-known application that returns information about Web services in response to
search criteria that has been submitted by a Service Requestor in the Find( ) operation.
 The Service Providers Publish() these classification details as well as the connection details to the Service
Registry.

2 Web Services and Transactions

2.1 Compare with Traditional transactions

Transactions are a fundamental concept in building reliable distributed applications. A transaction is a
mechanism to insure all the participants in an application achieve a mutually agreed outcome. Traditionally,
transactions have held the following properties collectively referred to as ACID:

Atomicity: If successful, then all the operations happen, and if failed, then none of the operations happen.

Consistency: The application performs valid state transitions at completion.

Isolation: The effects of the operations are not shared outside the transaction until it completes successfully.

Durability: Once a transaction successfully completes, the changes survive failure.

A Web service environment requires the same coordination behavior provided by a traditional transaction
mechanism to control the operations and outcome of an application. However it also requires the capability to
handle the coordination of processing outcomes or results from multiple services, in a more flexible manner.
This requires more relaxed forms of transactions – those that do not strictly have to abide to the ACID properties.
Additionally, there is a need to group Web services into applications that require some form of correlation, but
do not necessarily require transactional behavior. Recognizing this situation, BEA, Microsoft, and IBM have
begun work on a standard way of handling Web services transactions called WS-Transaction. The WS-
Coordination and WS- Transaction specifications provide a WSDL definition for such coordinated behavior.

2.2 WS-Coordination

The WS-Coordination specification is a generalized facility to allow the management of the activities or tasks
related to the overall application. WS-Coordination supports, integrates, and unifies several popular
coordination models that provide mechanisms and technologies that will allow a variety of systems to
interoperate transactionally.

WS-Coordination provides standard mechanisms to create and register services, using the protocols defined in
the WS-Transaction specification that coordinate the execution of distributed operations in a Web services
environment (for example, atomic transaction protocols, long-running business transaction protocols).It also
provides an important foundation layer that will help developers control operations that span across broadly
interoperable Web services

To implement WS-coordination, there are three elements in coordination framework shows below figure 2.2.1

Fig. 2.2.1 A sample of WS-coordination

Activation service: The activation service uses the Create message to begin a new activity and specify the
coordination protocols available to the activity.

Registration service: The registration service register allows a Web service to register and to select a
protocol for the activity.

Coordination service: The coordination service controls the activity completion processing for the
registered Web services using the selected coordination

2.3 WS-Transaction

As mentioned in previous section, WS-Coordination has two element services: Activation, Registration, and
Coordination. Particularly, the Coordination Protocols as defined in the WS-Transaction specifications are:

Protocols for Atomic Transactions: The protocols for atomic transactions handle activities that are
short-lived. Atomic transactions are often referred to as providing a two-phase commitment protocol. The
transaction scope states that all work is completed in its entirety, that is, that the result of an activity, if
successful, is that all operations are performed, or if unsuccessful, that no operations have been performed.
Upon successful completion the results of the activity are available to other users.
It also defines two protocols:
  Completion: The completion protocol initiates commitment processing. Based on each protocol’s
registered participants, the coordinator begins with Volatile 2PC then proceeds through Durable
2PC. The final result is signaled to the initiator.
 Two-Phase Commit (2PC): The 2PC protocol coordinates registered participants to reach a commit
or abort decision, and ensures that all participants are informed of the final result. The 2PC protocol
has two variants:
 Volatile Two-Phase Commit: Participants managing volatile resources such as a cache
should register for this protocol.
 Durable Two-Phase Commit: Participants managing durable resources such as a database
should register for this protocol.

Protocols for Business Transactions: The protocols for business transactions handle long-lived activities.
These differ from atomic transactions in that, such activities can take much longer to complete, and to
minimize latency of access by potential users of the resources used by the activity, the results of interim
operations need to be released before the overall activity has completed. In light of this, mechanisms for
fault and compensation handling are introduced to reverse the affects of previously completed business
activities (for example, compensation, reconciliation, etc).

4 Tool: WSIT

Web Services Interoperability Technology (WSIT) is an open-source project started by Sun Microsystems to
develop web service technologies such as message optimization, reliable messaging, and security. WSIT is an
implementation of a number of open web services specifications to support enterprise features. Figure 4.1 shows
the underlying services that were implemented for each technology.

In WS-Transaction, WSIT provide the technology to make transaction reliable. The reliable message technology
ensures that messages in a given message sequence are delivered at least once and not more that once and
optionally in the correct order. When messages in a given sequence are lost in transit or delivered out of order,
this technology enables system to recover from such failures. If a message is lost in transit, the sending system
retransmits the message until its receipt is acknowledged by the receiving system. If messages are received out
of order, the receiving system may re-order the messages into the correct order. The Reliable Message
technology can also be used to implement session management. A unique message sequence is created for each
client-side proxy, and the lifetime of the sequence identifier coincides with the lifetime of the proxy. Therefore,
each message sequence can be viewed as a session and can be sued to implement session management.

Fig. 1.2.1 WSIT Web service features

In next section, we will use WSIT as tool to implement the WS-Transaction (Atomic Transaction).
5 Implementation

For implementing a transaction using WSIT, we used NetBeans 6.7.1IDE. NetBeans is the only IDE for which
there is a plug-in available to provide support for WSIT. The IDE comes integrated with features for Java web
development features that ease the development process by reducing the amount of code that the developers
have to write.

A simple transaction can be observed by taking a closer look at money transfer between accounts. Transferring
money from one account to another can be seen as a set of operations that require co-ordination to maintain
consistency, which exactly is Transaction.

The operations that form a part of this money transfer transaction are:

1) Debit some amount x from account 1

2) Credit the same amount x in account 2

The web service is implemented as an Enterprise Java Bean since it has built in transaction management which
can be specified by annotations while coding the bean. The stateless session bean is exposed as a web service
using a simple annotation in Java: @WebService.

The EJB has four web methods as follows:

1) public void init()

2) public int debitAccont(String account_num, String amount)
3) public int creditAccount(String account_num, String amount)
4) public void destroy()

The init() method creates a connection to the database for updating the tables. The debitAccount()
debits the amount given as input from the account number given to it as input. Whereas creditAccount()
does exactly the opposite; it credits amount into the account which was given to it as input parameters. The last
method destroy() closes the connection so that no dead locks occur when other programs are trying to
access the database.

These web methods are accessed by a servlet that handles the transaction. The servlet initiates the transaction
using the begin() method from UserTransaction interface. If the transaction is successful, i.e if both
debitAccount() and creditAccount() are successful then the transaction is committed using
commit() method of the UserTransaction interface else rolled back by the rollback() method of
the same interface.

This way the whole transaction is controlled. The web methods in the EJB support transaction and this is
mentioned in the xml using the “Edit Web Services Attributes” panel of NetBeans 6.7.1. Screen shot is given
below:
The transaction attributes can be provided also by code using annotations @TransactionAttribute() and
mentioning the transaction attribute as a parameter.

The Web service is then consumed by BankClient1 a web application created using JSP and simple java bean.
The java bean DbBean has functions to maintain user details and fetch account details from the database for
display. The functions in the DbBean are as follows:

1) setDbUrl()
2) setDbUserName()
3) setDbPassword()
4) getAccountdetails()

The set functions are those to set the attributes of the bean. The getAccountdetails function connects to
the database and retrieves the account details of the customer whose name was entered in the login page. The
function takes in the customer reference and returns a hashtable with the account number and account balance as
the key value pair.

Another simple java bean used in the program is UserData bean. This bean is used only to set the user name to
be remembered in the welcome page after the user logs in.

The simple client shows a simple banking client which has login screen which prompts the user to enter the user
name. For simplicity we have created only one account for this bank and that account is named “Bill Gates”.
The login does not require a password. On logging in the user is presented the account details and options to
transfer money from one account to another.

On clicking the transfer button the control is handed over to TransferServlet which consumes the web
service and performs the transaction. To simulate both successful and unsuccessful transaction the
creditAccount() function has a check on the amount being transferred. The transaction would be
successfully performed as long as the amount is less than 100000. If the user tries to transfer an amount greater
than this credit limit then an exception is thrown saying that the “credit limit has exceeded” and the transaction
is rolled back.

To summarize the process in code snippets:

public class TransferServlet extends HttpServlet {

...
..
@Resource
UserTransaction ut;
..
..
@WebServiceRef(wsdlLocation = "WEB-
INF/wsdl/localhost_8080/BankWebServiceBeanService/BankWebServiceBean.wsdl")
private BankWebServiceBeanService service;
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException, Exception {
...
bwsb.BankWebServiceBean port = service.getBankWebServiceBeanPort();
..
port.init();
try {
ut.begin(); //demarcate beginning of transaction
result = port.debitAccount(dest_account, amount);
result = port.creditAccount(dest_account, amount);
ut.commit();
}catch(Exception e)
{ut.rollback();}

The screen shot of the login page is as follows:

The screen shot of the welcome.jsp page displayed once the user has logged in:

The screen shot of the page that is displayed after a successful transaction:
The screen shot of the page that is displayed after an erroneous transaction:

The bank database is implemented in Apache derby database. This was chosen because it comes integrated with
the NetBeans IDE. The services pane shows the database available and has support for querying the database
and creating and modifying tables. Only one table is used for maintaining the account details:
CUSTACCOUNTDETAILS; which has three columns namely:

1) ACCOUNT_NUM
2) ACCOUNT_BALANCE
3) CUSTOMER_REF

ACCOUNT_NUM is the primary key.

Screenshot is given below:

References:

1) http://www.w3schools.com/webservices/ws_intro.asp
2) http://www.w3.org/TR/2002/WD-ws-arch-20021114/
3) http://soa.sys-con.com/node/39769
4) http://idior.cnblogs.com/articles/408296.html
5) Java EE 5 Tutorial, Sun Microsystems
6) Java Web Services Tutorial, Sun Microsystems
7) Teach Yourself Web Services in 24 Hours, Sams Publishing
8) NetBeans : The Definitive Guide, O’Reilly
9) Project Tango: Overview, Sun Microsystems
10) WSIT Tutorial, Sun Microsystems
11) WS Atomic Transaction specification
12) WS Coordination specification