Business Activity Coordination Using Web Services

Business Activity Coordination Using Web Services

Abstract:
Traditional transaction semantics are not appropriate for business activities that involve long-running transactions in a loosely-coupled distributed environment, in particular, for Web Services that operate between different enterprises over the Internet. In this paper we describe a novel reservation-based extended transaction protocol that can be used to coordinate such business activities. The protocol avoids the use of compensating transactions, which can result in undesirable effects. In our protocol, each task within a business activity is executed as two steps. The first step involves an explicit reservation of resources. The second step involves the confirmation or cancellation of the reservation. Each step is executed as a separate traditional short-running transaction. We show how our protocol can be implemented as a reservation protocol on top of the Web Services Transaction specification or, alternatively, as a coordination protocol on top of the Web Services Coordination specification.

Existing System

In Existing system the application services can adversely affect the relationships between an enterprise and its customers, suppliers and partners. Moreover, the resolution of inconsistencies among the databases of multiple enterprises is difficult, expensive, time-consuming and error-prone, much more so than the resolution of inconsistencies within a database within a single enterprise.

There are two problems with compensation transactions.
• First, compensating a committed task implies that one enterprise might retract what another enterprise committed, which is obviously undesirable.
• Second, before the compensating transaction is applied, another transaction might see the result of the committed task. Transactions that must be compensated are difficult to identify because there is no pre-defined way to find them.

Proposed System

We proposed the extended transaction protocol that avoids the use of compensating transactions while achieving atomicity and consistency similar to or better than existing extended transaction protocols. Each task within a business activity is executed as two steps. The first step involves an explicit reservation of resources according to the business logic. In the interests of the supplier, a fee is associated with the reservation and the fee is proportional to the duration of the reservation. The second step involves the confirmation or cancellation of the reservation. Each step is executed as a separate traditional short-running transaction.

MODULES

 Reservation-Based Coordination Protocol
 Reservation Protocol on Top of Web Service Transaction
 Reservation Protocol on Top of Web service Co-ordination
 Resource Reservation versus Locking
 Operation under Fault Conditions

MODULES DESCRIPTION

1. Reservation-Based Coordination Protocol
In this resource involved in the task is reserved in a single transaction. In the second step, the reservation is either confirmed or cancelled according to the business rules, also in a single traditional transaction. To understand how a reservation is carried out, consider the example of purchasing goods (application defined resources). The goods to be purchased are reserved at the seller upon a request by the buyer.

2. Reservation Protocol on Top of Web Service Transaction

In this module how to use the business agreement protocol defined in the WS-Tx specification to coordinate a business activity according to our reservation protocol.
We assume that the two suppliers and the two shipping companies provide the following Web Services:
 Request-for-Quote (RFQ), Reserve, Confirm and Cancel.
 We require that the coordinator is closely tied to the client process. At the beginning of the transaction, the client (i.e., the initiator of the transaction) registers with the coordinator and a coordination context is created and returned to the client,
 During the transaction, the client sends RFQ requests to the Web Services provided by the two suppliers and the two shipping companies transaction Because the RFQ requests contain the coordination context for the business transaction, the transaction participants register with the coordinator. The Web Services respond to the RFQ by sending the quotes to the client. After retrieving enough information from its business partners, the client starts the reservation phase by sending the reservation requests to the four Web Services.

3. Reservation Protocol on Top of Web service Co-ordination
We describe the reservation protocol as a Web Services coordination protocol on top of the WS-Coor framework. We omit the technical details of the XML schemas, the related WSDL declarations, and the content of the business activity Coordination Context. The coordinator sends the Cancel, Close, Forget, Exited, Reserve Order, Confirm Order and Cancel Order messages. The participant sends the Register, Cancelled, Closed, Faulted, Exit, Reserved Order, Confirmed Order and Cancelled Order messages. The Reserve Order, Reserved Order, Confirm Order, Confirmed Order, Cancel Order and Cancelled Order messages are not pure protocol messages. The coordinator-participant two-party state diagram of the reservation protocol

4. Resource Reservation versus Locking
In resource reservation and locking differ significantly in the context of our coordination protocol and the concurrency control protocols used in database systems. The application has full control over the reservation activity and how long the resource should be reserved. In concurrency control for database systems, the locking of a resource is internal to the database system and is transparent to the application. The resource is locked by the database system, and the application has no control over how long the resource should be locked. In practice, typically a timeout controls how long a transaction lasts, and also prevents a resource from being locked too long. However, the timeout used in a database system is quite different from the duration of the reservation activity in our protocol.

5. Operation under Fault Conditions
Under fault-free conditions, our reservation protocol ensures consistent results among the participants that have confirmed their tasks and, thus, it achieves a form of atomicity of the business transaction.

SYSTEM SPECIFICATINON:

Hardware Required
 System : Pentium IV 2.4 GHZ
 Hard Disk : 40 GB
 Floppy Disk : 1.44 MB
 Monitor : 15 VGA Color
 Mouse : Logitech
 Keyboard : 110 Keys enhanced
 Ram : 256MB

Software Required
 O/S : Windows XP
 Language : Asp.net, C#
 Database : Sql-Server 2005

Comments are closed.