Kz2519141921

  • 69 views
Uploaded on

IJERA (International journal of Engineering Research and Applications) is International online, ... peer reviewed journal. For more detail or submit your article, please visit www.ijera.com

IJERA (International journal of Engineering Research and Applications) is International online, ... peer reviewed journal. For more detail or submit your article, please visit www.ijera.com

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
69
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.1914-1921 The Transaction Concept: Integrated With BPEL and WS-AT, WS-BA Coordination Protocols R.Soujanya (M.Tech) Guide: M.Venkateshwarlu M.Tech Department of SE, Department of CSE, Sri Kottam Tulasi Reddy Memorial College, Associate Professor CSE Department, Kondair. Andhra Pradesh. Sri Kottam Tulasi Reddy Memorial College, Kondair. Andhra Pradesh.ABSTRACT remote operation invocation is not the revolution Service-Oriented Computing (SOC) is brought by Service-Oriented Computing (SOC),becoming the mainstream development paradigmof applications over the Internet, taking though. Rather, it is the possibility of havingadvantage of remote independent functionalities. programs that perform complex tasks coordinatingWhen the control over the communication and and reusing many loosely coupled independentthe elements of the information system is low, services.developing solid systems is challenging. Inparticular, developing reliable web service Business processes are now able to executecompositions usually requires the integration of seamlessly across organizations and to coordinateboth composition languages, such as the Business the interaction of loosely coupled services. Often itProcess Execution Language (BPEL), and of is necessary to have transactionality for a set ofcoordination protocols, such as WS-Atomic business operations,Transaction and WS-Business Activity. But the loosely nature of such systems calls forUnfortunately, the composition and coordination techniques and principles that go beyond traditionalof web services currently have separate languages ACID transactions.and specifications. The goal of this paper is twofold. First, In the present treatment, a service is awe identify the major requirements of transaction standard XML description of an autonomousmanagement in Service-oriented systems and software entity, it executes in a standalone container,survey the relevant standards. Second, we it may have one or more active instantiations, and itpropose a semiautomatic approach to integrate is made of possibly many operations that areBPEL specifications and web service invoked asynchronously. A service composition is acoordination protocols, that is, implementing set of operations belonging to possibly manytransaction management within service services, and a partial order relation defining thecomposition processes, and thus overcoming the sequencing in which operations are to be invoked.limitations of current technologies. Such a partial order is adequately represented as a direct graph. A service transaction is a unit of workKeywords: Web services, transaction comprehending two or more operations that need tomanagement, WS-Business Activity, WS-Atomic be invoked according to a specific transactionTransaction, ACID properties, Service policy. The coordination of a service transaction iscomposition languages, and Business process the management of the transaction according to aexecution language. given policy. A service transaction can span over operations of one service or, more interestingly, of1. INTRODUCTION several services. The widespread adoption of Web servicesis feeding the promises of the new field of Service One may argue that transactionCentric Systems. As Service Centric (SC) Systems management is a well-known Technique for the neware being increasingly adopted, new challenges and features of transactions executed by web services;possibilities emerge. Standardized web service various web transaction specifications have beentechnologies are enabling a new generation of developed. WS-Coordination [1] specificationsoftware that relies on external services to describes an extensive framework for providingaccomplish its tasks. The remote services are usually various coordination protocols. The WS-invoked in an asynchronous manner. They are AtomicTransaction (WS-AT) [2] and WS-Businessknown by their published interfaces, and await Activity (WS-BA) specifications [3] are two typicalinvocations over a possibly open network. Single web transaction protocols. They leverage WS- Coordination by extending it to define specific 1914 | P a g e
  • 2. R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.1914-1921coordination protocols for transaction processing. effects should be durable in time. Given the natureThe former is developed for simple and short-lived of Service-Oriented Systems, satisfying theseweb transactions, while the latter for complex and properties is often not possible and, in the end, notlong-lived business activities. Finally, the Business necessarily desirable. In fact, some features areProcess unique to Service-Oriented Systems: Execution Language (BPEL) [4] is a  Long-lived and concurrent transactions, notprocess-based composition specification language. only traditional transactions which areIn order to develop reliable web services usually short and sequential.compositions, one needs the integration of  Distributed over heterogeneoustransaction standards with composition language environments.standards such as BPEL [5], [6]. Unfortunately,  Greater range of transaction types due tothese are currently separate specifications. different types of business processes, service types, information types, or product This paper has a double goal: the first one is flows.to look at the requirements of transaction  Unpredictable number of participants.management for Service-oriented systems. The  Unpredictable execution length.systematization of requirements is the starting point For example, information query andfor an analysis of current standards and technologies flight payment need 5 minutes; while e-in the field of web services. The second goal of the shopping an hour; and a complex businesspaper is to propose a framework for the integration transaction like contracting may take days.of BPEL with transaction protocols such as WS-  Greater dynamism. Computation andAtomicTransaction and WS-Business Activity. We communication resources may change atuse a simple but representative example across the runtime.paper, the drop-dead order (DDO) one, to illustrate  Unavailability of undo operations, mostrequirements and the proposed approach. often only compensating actions that return the system to a state that is close to the2. The Drop Dead Order Example initial state is available. The drop-dead order describes a scenario Furthermore, transactions may act differently whenwhere a customer wants to order products from a exposed to certain conditions such as logicaldistributor under the condition that the products are expressions, events expressed in deadlines, and evendelivered before the drop-dead date (Figure). errors in case of a faulty web service. To make sure In the scenario, the distributor tries to find a that the integrity of data is persistent, the twosupplier that has the products available. If he finds transaction models used are, namely, Composite andsuch a supplier, he will search for a carrier that is distributed that allow smooth recovery to a previousable to deliver the products before the drop-dead “safe” state.date. If both the supplier and the carrier are able to The set of emerging features mentionedfulfill the demands of the customer, the distributor earlier, which combinations of requirements arereports to the customer that he can fulfill the order. mostly coming from the areas of databases andAfter the customer has acknowledged, the distributor workflows provide the basis for identifying the mostsends a confirmation to the supplier and the carrier. relevant requirements for transactions in Service- Oriented Systems.FIGURE: The Drop Dead Order Example 3.1 ACID Properties 3.1.1 Atomicity Atomicity is the property of a transaction to either complete successfully or not at all, even in the event of partial failures. 3.1.2 Consistency Consistency is the property of a transaction to begin and end in a state which is consistent with the intended semantics of the system, i.e., not breaking any integrity constraints. 3.1.3 Isolation3 TRANSACTION REQUIREMENTS Isolation is the property of a transaction to In the field of databases, transactions are perform operations isolated from all otherrequired to satisfy the so-called ACID properties, operations. One transaction can therefore not see thethat is, the set of operations involved in a transaction other transaction‟s data in an intermediate state.should occur atomically, should be consistent, 3.1.4 Durabilityshould be isolated from other operations, and their Durability is the property of a transaction to record the effects in a persistent way. Whenever a 1915 | P a g e
  • 3. R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.1914-1921transaction notifies one participant of successful application memory by locking it in the transactioncompletion, the effects must persist, even when for the entire time. While the optimistic simplysubsequent failures occur. chooses to detect collisions and then resolves the3.2 Transaction Behaviors collision when it does occur. This scheme has better3.2.1 Rollback performance. When two transactions are concurrent, Rollback is the operation of returning to a they should not both claim the same supply of goodsprevious state in case of a failure during a from one Supplier.transaction. This may be necessary to enforceconsistency. TRANSACTION STANDARDS AND3.2.2 Compensating Actions SERVICE COMPOSITION LANGUAGES Compensating actions are executed in the WS-Transactions and Business Transactionevent of a failure during a transaction, all changes Protocol (BTP) are the two most representativeperformed before the failure should be undone. standards that directly address the transaction3.2.3 Abort management of web service-based systems, while Abort is the returning to the initial state in for representing compositions of services, thecase of failure or if the user wishes so. Business Process Execution Language and the3.2.4 Adding Deadlines Choreography Description Language (WS-CDL) are Adding deadlines to transactions involves most widely known and adopted. WS-Transactionsgiving timeouts to operations. consist of two coordination protocols: WS-Atomic3.2.5 Logical Expressions Transaction and WS-Business Activity which live in Logical expressions for specifying the WS-coordination framework. WS-AT providesconstraints are used for giving unambiguous and the coordination protocols for short-lived simplesemantically defined rules for guaranteeing operations, while WS-BA provides the coordinationconsistency. protocols for long-lived complex business activities. The WS-coordination framework is extensible and3.3 Transaction Models incremental. That is, WS-coordination can enhance3.3.1 Composite Transactions existing Service-Oriented Systems with transaction Composite transactions are nested properties by wrapping them with a specifictransactions. These transactions depend on the coordination.global outcome, that is, all three succeed or the BTP is a model for long-lived businesswhole composite transaction fails. transaction structured into small atomic transactions,3.3.2 Distributed Transactions and using cohesion to connect these atomic Distributed transactions are transactions operations. Its motivation is to optimize the use ofbetween two or more parties executing on different resource involved in a long-lived transaction underhosts. The transaction should support transactions loosely coupled web service environments andthrough a network between two different hosts. avoiding the use of a central coordinator. BPEL provides the facilities to specify3.4 Transaction Behavior—Alternatives executable business processes with references to3.4.1 Transaction Recovery services‟ interfaces and implementations. It does Transaction recovery by dynamic rebinding handle some basic issues of transactions, such asand dynamic recomposition at runtime is the compensation, fault, and exception handling, butpossibility of replacing a faulty web service when other transaction requirements are not managed.the current service is not able to fulfill its promises. WS-CDL provides the infrastructure to describeDynamic recomposition is the forming of a new cross-enterprise collaborations of web services in acomposition by replacing one or several services by choreographic way.another composition that fulfills the same function. Consider the proposed protocols that takeImagine that the first Carrier somehow fails and is the transaction and the business perspective ofunreachable. If this happens during a transaction, Service-Oriented Systems with respect to thethen automatic rebinding with a service that offers requirements. In Table 1, we summarize the resultsthe same service should take place. Recomposition of the evaluation for all requirements—each row—through rebinding with a third Carrier through the and for all protocols—each column—by denotingSupplier is also a possibility. the satisfaction with the “⨁” symbol, the partial satisfaction with “⨀” and no support with ”Ө”.3.4.2 Optimistic or Pessimistic ConcurrencyControl Optimistic or pessimistic concurrencycontrol refers to the support of different types ofconcurrency control to enforce consistency. Thiscontrol could either be optimistic or pessimistic. Thepessimistic approach prevents an entity in 1916 | P a g e
  • 4. R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.1914-1921 The above survey shows that there are standardized protocols for describing transactions and languages for describing processes in terms ofTABLE-1 Evaluation Results flows of activities. The connection among these is, to say the least, very loose. The problem is that processes are described in terms of activities and roles capable of executing the activities, but semantic dependencies among these activities are not represented beyond message and flow control. It may happen that several operations from a single web service are invoked within a BPEL process, and dependencies among these operations may exist. Our proposal consists of making the dependencies among the activities explicit via an automatic procedure and performing a restructuring step of the process, where necessary. The identified dependencies among activities can be then identified by the designer of the process as being transactions or not. In case they are, the designer will decide which kind of transactions they are and simply annotate them. The execution framework then takes care that transaction annotations are correctly managed at runtime. The need for the human design WS-AT is a traditional protocol which decision in the process is necessary due to the lacksatisfies the basic ACID properties. WS-BA, on the of semantic annotations of the BPEL processes.other hand, renounces atomicity to accommodate Only the designer can decide whether a set oflong-lived transactions. BTP has included confirm activities that seem to have a dependency in thesets. These confirm sets let the application element process are to be executed transaction ally or not.choose which operations with parties in thetransaction are to be canceled and which are to be Fig 3 Approach to integrating transactions intoconfirmed. In this way, the application element is BPEL processes.able to contact more services which perform thesame task and to choose the best option.Unfortunately, BTP is not part of the WS-Stack,which limits its compatibility with other web servicetechnologies. In addition, BTP does not supportlong-lived transactions. There is also a difference ingranularity between the above transaction standards.WSAT contains simple two-phase commit protocols,WS-BA contains nonblocking protocols and BTPconsists of a Sequence of small atomic transactions.As for security, WS-Security can be combined withWS-Transaction as well as with BTP. Dynamic rebinding is supported only byBPEL, though only at the implementation level. WS-CDL supports most requirements, while its majordisadvantage is that the large players in the field donot support it and that no implementation isavailable. Consider Fig. 3, where data transformation WS-AT is a very conservative business goes from left to right and we distinguish threetransaction model especially with respect to layers: the data layer at the bottom, the middleblocking. WS-BA is more appropriate for services, execution layer defining the data transformation, andby renouncing to the concept of the two-phase the knowledge level indicating from where thecommit. BTP places itself in the middle (two-phase knowledge to transform the data comes. We startcommit is followed in a relaxed way). As for BPEL with a generic business process designed to solveand WS-CDL, they address the business process some business goal. An automatic processing step,perspective with limited transaction support. which we define next, identifies dependencies among activities. These are then reviewed by an5 PROPOSALS FOR INTEGRATING expert that decides which actually transactions areTRANSACTIONS INTO BPEL and which not. For those who qualify, he further decides what kind of transactions they are and 1917 | P a g e
  • 5. R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.1914-1921annotates them. For instance, some may be long Figure 4: Representation of activities and the linkrunning while others may be atomic ones. We that connects them.remark how this is a design step performed by anexpert who understands the domain, the specificprocess, and the consequences of choosing atransaction policy in favor of another. This stepcannot be automated unless further semanticannotations are made on the BPEL. The restructuredand annotated process is then ready to be sent forexecution. Next the execution phase and will behandled by the execution framework. We considerthe three phases of the approach individually.5.1 Preprocessing Preprocessing the BPEL specification isperformed in two steps, namely, 1) identification and2) resolution of transaction dependencies. In order toillustrate the two steps, we introduce an abstractmodel of BPEL.5.1.1 Abstract Model of BPEL Specifications A BPEL process specification describes theinteraction between services in a specific compositeweb service. Its abstract model, known as behavioralinterface, defines the behavior of a group of servicesby specifying constraints on the order of messages tobe sent and received from a service. A BPEL specification „S‟ is a set ofactivities „A‟ and its associated links „L‟, representedby S = (A, L). The links, which are directed, define a 5.1.2 Dependencies Identification Algorithmpartial ordering over the set of activities and are thuswell represented as a directed graph (e.g., Fig. 4). If one specifies a set of activities within a An activity „a‟ in A having a type represented given BPEL specification S, there may exist by Ta, has the following properties: dependencies among activities that can hinder the- Name Na. application of transaction management as described- Operation OPa, which is usually implemented above. Assume that by the web service at a specific port. St = { ai│ ai is a transactional activity of a- Input variable IVa and output variable OVa, transaction t} is a transaction t specified within the which specify the parameters required and BPEL specification S. produced by the OPa, respectively. For any two activities am and an where am,- Set of source links SLa and set of target links 𝒍𝒋𝟏 𝒍𝒋𝒌 an ∈ St and am ≠ an, if there exists a path am …. TLa, which specify the outgoing and incoming links (transitions), respectively. an where lj1 and ljk are some links connecting activities, we say that an is reachable from am, A link l in S has a unique name Nl and is ∗ indirectly defined through two activities a1 and denoted as am an, and {lj1…. ljk} is a link chain of ∗ ∗ a2 which indicates not only the direction ld of am an denoted as LC { am an }. For any two the transition, but also the conditions lc for the activities am and an in a transaction St that are transition to take place. ∗ implemented by the same web service, if am an Furthermore, the Customer-to-distributor ∗link lc-d is one of the source links of the and OVam ∈ lc where l ∈ LC {am an}, then aReceiveOrder activity a1, namely, lc-d ∈ SLa1. transaction dependency exists between am and an.Furthermore, lc-d ∈ TLa6, where TLa6 is the target To identify the existence of transaction dependencieslink of the CompleteDistribution activity a6. within a given BPEL specification S, we proposeTherefore, the link lc-d connects the transition Algorithm 5.1.between a1 and a6, denoted as 𝒍𝒄−𝒅 a1 _ → a6. Fig. 4 provides an illustration of 𝒍𝒄−𝒅a1 → a6. _ 1918 | P a g e
  • 6. R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.1914-1921 5.2 Declaration of Transaction Policies Once transactions are identified and BPEL has been accordingly restructured, one needs to The algorithm is a standard graph algorithm define the desired transactional behavior. To thissimilar to those for reachable set construction. The end, we introduce a reference transaction policyfunction IdentifyDependency takes S as input and declaration schema, shown in Fig. 7.outputs a Boolean value that represents the existence With this schema, one can declare theof transaction dependencies. The function first transaction policy using the following elements:creates a path p for any two activities am and an. 1. Trans ID is a nonzero integer, representingThen, traverses the links in the link chain ls obtained transactions within a business process.from p. When a link l is detected and its transition 2. Trans Protocol specifies a protocol for thecondition lc contains the output variable OVam of the transaction, such as WS-AtomicTransaction or WS-first activity am, or if it contains an output variable BusinessActivity.OVai which is identical to OVam semantically, the 3. Trans Root indicates the parent transactionalgorithm stops and returns TRUE. Otherwise, it identified by Trans_ID. The value 0 is used tocontinues until all pairs of activities in St have been indicate the root transaction within the businessvisited. Finally, if no transaction dependencies are process. One can specify the hierarchy ofdetected, the algorithm returns FALSE. transactions by assigning appropriate Trans_IDs and Trans_Roots.5.1.3 Resolution of Dependencies With such a schema, one can annotate Once transaction dependencies are constraints or preferences to a specific activity in theidentified, it is necessary to handle them. To solve BPEL specification. The annotated activity must bethis problem, we merge the dependent activities into an invoke activity. One can separately specify theone transaction. Algorithm 5.2 resolves the desired constraints or preferences in the design-time-transaction dependencies within a BPEL info or runtime-info sections. For transactionspecification S. It employs Algorithm 5.1 to detect management, we declare the transaction policies intransaction dependencies and it asks the user for the section of the transinfo which is embeddedconfirmation that it is indeed a transactional within the section of runtime info, since adependency. The output is a new transaction policy is a runtime constraint. TogetherBPEL specification referred to as preprocessed with the other types of process information,BPEL where conflicts are resolved. transaction policies are stored in an XML file for use at runtime. 1919 | P a g e
  • 7. R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.1914-1921Figure 7: A transaction policy declaration schema. T.M. happens just before the binding. Currently,ODE and ActiveBPEL are two BPEL engines supported by the SCENE platform.  The Event Adapter maps the low-level events from the BPEL engine onto the binding-related events. The first version of SeCSE event adapter is extended to support the mapping of transaction-related events.  The Transaction Manager is a separate component in the executor and deployed in the Mule container (Mule is a messaging platform based on ideas from Enterprise Service Bus (ESB) architectures). The Transaction Manager consists of the following two transaction-specific components:5.3 The Execution Framework - TransLog is responsible for managing the lifecycle The proposed approach transforms a of transactions, such as creating transactiongeneric business process into a restructured one in instances, maintaining the status of transactionwhich transactions are identified and annotated. instances, and destroying transaction instances.Now, one needs an execution framework that is TransLog is also responsible for transferring thericher than a simple BPEL engine. In fact, one needs information among the components in the executor.to interpret the annotations, make sure that activities For example, it listens the transaction-are executed according to the transaction conditions related events from the Event Adapter, and it isand also that the binding among dependent activities responsible for the communication betweenis consistent with the transaction semantics. To Transaction Manager and JBoss Transaction Server.achieve this, we rely on the Service Centric System - PolicyOperator retrieves the transaction policiesEngineering (SeCSE) platform in the context of from the XML file, and parses the transactionwhich the current approach has been developed. policies, and then maps transaction policies onto the Service Centric System Engineering is a coordination context. It provides a set of APIs whichEuropean sixth framework integrated project, whose are to be called by the TransLog.primary goal is to create methods, tools, andtechniques for system integrators and service As for the implementation of transactionproviders and to support the cost-effective protocols, we rely on JBoss Transaction Server.development of service-centric applications. The JBoss Transaction Server is an open sourceSeCSE service composition methodology supports implementation of WS-Coordination,the modeling of both the service interaction view WSAtomicTransaction, and WS-BusinessActivity. Itand the service process view. A service integrator provides a set of APIs to support the coordinationneeds to design both the abstract flow logic and the services and transaction protocols. JBossdecision logic of the process-based composition. Transaction Server is selectedfor this purposeTherefore, the SeCSE composition language allows because it 1) is a complete, standalone, open sourcethe definition of a service composition in terms of a software tool, 2) has sufficient documentation and 3)process and some rules that determine its dynamic and supports WS-Coordination and WS-Transaction.behavior. Correspondingly, the flow logic can berepresented by a BPEL specification, while thedecision logic is defined by rules. 6. CONCLUSION: Web services are being increasingly Based on the architecture of the SeCSE adopted by organizations in order to run theirplatform, we built a transaction management tool business more effectively and efficiently. However,called DecTM4B. It consists of three modules, current technologies lack the support often requirednamely, by such organizations. The success of web services  The Preprocessor for Transaction lies, among other factors, in their reliability, Management is used to identify and especially when economic interests are involved. eliminate transaction dependencies One key feature is that of being able to deal occurring in the original BPEL transactionally with a set of operations, but this is far specification. The output is the from being easy, especially when the operations in preprocessed BPEL specification. The the transaction come from different remote service SeCSE platform will deal with the binding instances. of abstract services before the BPEL engine In this paper, we highlight the key requirements of executes the BPEL specification. The transaction management in Service-Oriented preprocessing executed by Preprocessor for Systems and propose a novel declarative transaction 1920 | P a g e
  • 8. R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.1914-1921management approach for web service compositions. Proc. 19th Int‟l Conf. Very Large DataThe key to implementing transaction management Bases, R. Agrawal, S. Baker, and D.A. Bell,into BPEL processes is to consider the combination eds., pp. 581- 591, 1993.of business logic with transactions, taking into 10) C. Sun and M. Aiello, “Requirements andaccount the challenges that make it impossible to Evaluation of Protocols and Tools fordirectly apply transaction models to all Transaction Management in Service CentricBPEL processes. Systems,” Proc. Ann. Int‟l Computer The proposal consists of first a Software and Applications Conf.preprocessing of the BPEL to identify and manage (COMPSAC ‟07), pp. 461-466, 2007.transaction dependencies among a group of 11) A. Lazovik, M. Aiello, and M. Papazoglou,activities. Then, it proceeds with the annotation with “Planning and Monitoring the Execution oftransaction policies. Finally, the interpretations of Web Service Requests,” Int‟l J. Digitalthe declared transaction policy are specified as Libraries, vol. 6, no. 3, pp. 235-246, 2006.event-action condition rules to be processed at 12) M. Aiello and A. Lazovik, “Monitoringruntime. Assertion-Based Business Process,” Int‟l J. Cooperative Information Systems, vol. 15,REFERENCES no. 3, pp. 359-390, 2006. 1) WS-C, “Web Services Coordination (WS- 13) B. Haugen and T. Fletcher, “Multi-Party Coordination),” technical report, Arjuna Electronic Business Transactions. Version Technologies Ltd., BEA Systems, Hitachi 1.1,” technical report, UN, 2002. Ltd., IBM, IONA Technologies, and Microsoft, 2007. AUTHOR BIOGRAPHIES: 2) WS-AT, “Web Services Atomic Transaction (WS-AtomicTransaction), Version 1.1,” technical report, Arjuna Technologies Ltd., BEA Systems, Hitachi Ltd., IBM, IONA Technologies, and R.Soujanya received her B.Tech, Microsoft, 2007. Degree in Computer science and information 3) WS-BA, “Web Services Business Activity technology from G.Pulla Reddy Engineering Framework (WSBusinessActivity), Version College, Kurnool India, in 2010. She is pursuing 1.1,” technical report, Arjuna Technologies her M.Tech in Software Engineering in Sri Kottam Ltd., BEA Systems, Hitachi Ltd., IBM, Tulasi Reddy Memorial College, Kondair India. Her IONA Technologies, and Microsoft, 2007. area of interest is in the field of Service oriented 4) BPEL, “Business Process Execution computing, Wireless Sensor Networks and Software Language for Web Services Version 1.1,” Testing. technical report, IBM, Microsoft, BEAT, SAP, and Siebel Systems, 2003. 5) C. Sun and M. Aiello, “Requirements and Evaluation of Protocols and Tools for Transaction Management in Service Centric Systems,” Proc. Ann. Int‟l Computer Software and Applications Conf. (COMPSAC ‟07), pp. 461-466, 2007. Mr.M.Venkateshwarlu Associate Professor, 6) A. Erradi, P. Maheshwari, and V. Tosic, completed B.Tech in Computer Science & “Recovery Policies for Enhancing Web Engineering in Sri Kalahastheeshwara Institute of Services Reliability,” Proc. IEEE Int‟l Technology, Sri Kalahasthi, and M.Tech in Conf. Web Services (ICWS ‟06), pp. 189- Computer Science & Engineering in Sri Kottam 196, 2006. Tulasi Reddy Memorial College of Engg, Affiliated 7) A.Portilla, “Providing Transactional to JNTU Hyderabad. His interested areas are Behavior to Services Coordination,” Proc. Wireless Sensor Networks, Artificial Intelligence. Very Large Data Bases (VLDB) PhD He attended two international conferences on Workshop, vol. 170, 2006. MANET`s and one national level conference on 8) S. Loecher, “Model-Based Transaction Networks. He attended Mission 10x program Service Configuration for Component- conducted by Wipro. Presently he was acting as The Based Development,” Component-Based Convener of R&D cell in SKTRMCE. Kondair, Software Eng., pp. 302-309, 2004. Mahaboob Nagar (Dt). He had total 07 years of 9) P.W.P.J. Grefen, “Combining Theory and teaching experience. Currently he was working as Practice in Integrity Control: A Declarative Associate Professor in CSE Department in KTM Approach to the Specification of a College of Engineering, Transaction Modification Subsystem,” 1921 | P a g e