Docstoc

wstxm2doc - Web Services Transaction Management _WS-TXM_

Document Sample
wstxm2doc - Web Services Transaction Management _WS-TXM_ Powered By Docstoc
					                                       Web Services Architectures




   Web Services Archtectures




      Web Services Transaction Management
                   (WS-TXM)




Muráncsik György            Web Servicese Transaction Management

                       1.
                                                                    Web Services Architectures




Architecture
WS-TXM leverages the WS-CF and WS-CTX specifications. The layering of WS-TXM onto
WS-CF. WS-TXM defines a pluggable transaction protocol that can be used with the
coordinator to negotiate a set of actions for all participants to execute based on the outcome of
a series of related Web services executions. The executions are related through the use of
shared context. Examples of coordinated outcomes include the classic two-phase commit
protocol or business process automation protocol.




Relationship of transactions to coordination                            Hierarchy
framework

Coordinators can be participants of other coordinators, as shown above. When a
coordinator registers itself with another coordinator, it can represent a series of local
activities and map a neutral transaction protocol onto a platform-specific transaction
protocol.

Brief Overview from WS-CTX and WS-CF

WS-CTX (Web Service Context)

WS-CTX defines the context, the scope of context sharing, and basic rules for context
management. WS-CTX describes how to define an Activity in which multiple Web services
are related through shared context. The responsibility for actions in relationship to the context
resides with the individual Web services within the Activity.



Muráncsik György                                     Web Servicese Transaction Management

                                                2.
                                                                 Web Services Architectures




                                Web Services CTX Concepts


The main component of the WS-CTX:
    Context Service: defines the scope of an activity and how information about it (the
      context) can be referenced and propagated in a distributed environment. Activities can
      be hierarchically structured, such that nesting and concurrent activities are possible.
    A context: defines basic information about the activity structure that is identified using
      a URI, propagated on application messages.The context is modeled as a Web resource
      and is accessible via a URI. Web services are identified as participants in the activity
      by including the context URI in the SOAP header.
      The purpose of a context is to allow multiple individual Web services to enter a
      relationship by sharing certain common attributes as an externally modeled entity.
      Typical reasons for Web services to share context include:
          o Common security environment – multiple Web services execute within a
              single authentication session or authorization check
          o Common outcome negotiation – multiple Web services or activities execute
              within a single transactional unit of work whose outcome must be coordinated
          o Common access to such resources as database management systems, files,
              queues, and displays such that multiple Web services can share a connection
          o Participation in an automated business process execution, or choreography
    The Activity Lifecycle service: these Web services are registered with the core Context
      Service and are informed of the lifetime of an activity and may further enhance it by
      suitable higher-level interfaces.

Scoping:The ability to scope arbitrary units of distributed work by sharing common context is
a requirement in a variety of distributed applications, such as choreography and business-to-
business interactions. Scoping makes it possible for Web services participants to be able to
determine unambiguously whether or not they are in the same composite application, and
what it means to share context. Scopes can be nested to arbitrary levels to better delineate
application work.

WS-CF (Web Services Coordination Framework)

The WS-CF allows the management and coordination in a Web services interaction of a
number of activities related to an overall application. It builds on the Web Services CTX
Service (WS-CTX) specification and provides a coordination service that plugs into WSCTX.



Muráncsik György                                   Web Servicese Transaction Management

                                              3.
                                                                     Web Services Architectures

WS-CF specification supports the following components:

   o Coordinator:Provides an interface for the registration of participants (such as
     activities) triggered at coordination points. The coordinator is responsible for
     communicating the outcome of the activity to the list of registered activities.
   o A Participant: The operation or operations that are performed as part of coordination
     sequence processing
   o A coordinator becomes a participant when it registers itself with another coordinator
     for the purpose of representing a set of other, typically local participants. When a
     coordinator represents a set of local participants, this is called interposition.
     Interposition assists in achieving interoperability because the interposed coordinator
     can also translate a neutral outcome protocol into a platform specific protocol.




                         Coordinator-participant distributed interactions.



The WS-CF specification supports the following services :
   o Activation Service: begin a new activity and specify the coordination protocols
     available to the activity.
   o Registration Service: The registration service 'register' allows a Web service to
     register and to select a protocol for the activity. Enrollment and selection allow the
     Web services involved in the activity to establish the traditional roles of coordinator
     and participant. The registration process identifies the specific protocol used for
     activity coordination.
   o A Coordination Service: Defines the behaviour for a specific coordination model. The
     Coordination Service provides a processing pattern that is used for outcome
     processing.

The coordinator provides additional features for persisting context operations and
guaranteeing the notification of outcome messages to the participants. WS-CF is designed to
complement WS-CTX and can be used independently of the WS-TXM specification.

Web Services transaction management

The WS-TXM specification defines three transaction models that address different use cases
in current business-to-business interactions:
     ACID transaction: a traditional ACID transaction (AT) designed for interoperability
        across existing transaction infrastructures.
     Long running action: an activity, or group of activities, which does not necessarily
        possess the guaranteed ACID properties. A long running action (LRA) still has the “all
        or nothing” atomic effect, i.e., failure should not result in partial work. Participants
        within an LRA may use forward (compensation) or backward error recovery to ensure
        atomicity. Isolation is also considered a back-end implementation responsibility.
     Business process transaction: an activity, or group of activities, that is responsible for
        performing some application specific work. A business process (BP) may be
Muráncsik György                                      Web Servicese Transaction Management

                                                4.
                                                                  Web Services Architectures

       structured as a collection of atomic transactions or long running actions depending
       upon the application requirements.

Because WS-TXM uses WS-CF, it builds upon the context information defined by that
specification. Each transaction protocol specified within WS-TXM has its own context.

Atomic Transaction (AT)

Atomic Transaction defines protocols that govern the outcome of atomic transactions. It is
expected that existing transaction processing systems wrap their proprietary mechanisms and
interoperate across different vendor implementations. This specification leverages WS-
Coordination by extending it to define a coordination type to support atomic transactions. It
does this by defining the behavior and messages required by the respective coordination
protocols.
The WS-Coordination protocols are used for transactions to do the following:

   o Create a new atomic transaction CoordinationContext that is associated with a
     coordinator.
   o Add an interposed coordinator to an existing transaction.
   o Propagate the CoordinationContext in messages between web services.
   o Register for participation in coordination protocols, depending on the participant's role
     in the activity. Each of these protocols is one of the coordination protocols of the
     atomic transaction coordination type defined in this specification. These protocols
     include Completion, PhaseZero, 2PC (two-phase commit) and OutcomeNotification.

Atomic Transaction Context

An atomic transaction uses one of the special ContextType of WS-CF as
CoordinationContext. The CoordinationContext allows elements to be added via extensibility
elements. For each newly created activity, the activation service returns a this. An that contex
contain the following fiels:

   o Identifier: a unique name to identify the CoordinationContext.
   o Expires: an activity timeout value.
   o CoordinationType: a defined set of coordination protocols that describe the
     supported completed processing behaviors.
   o Registration Service: address of the registration service, the service is used to
     register interest and participation in a coordination protocol for determining the overall
     outcome of the activity.
   o Extensibility element: provides for optional implementation-specific extensions.

Atomic Transaction adds the following semantics to the CreateCoordinationContext
operation on the activation service.

   o If the request includes the CurrentContext element, the target coordinator is interposed
     as a subordinate to the coordinator stipulated inside the CurrentContext element.
   o If the request does not include a CurrentContext element, the target coordinator creates
     a new transaction and acts as the root.
Muráncsik György                                    Web Servicese Transaction Management

                                               5.
                                                                  Web Services Architectures



The Atomic Transaction protocol is identified by the following coordination type:
http://schemas.xmlsoap.org/ws/2003/09/wsat

Atomic Transaction Protocols
This specification defines the following protocols for atomic transactions.

   o Completion: One participant (generally the application that created the transaction)
     registers for the completion protocol, so that it can tell the coordinator either to try to
     commit the transaction or force a rollback. A status is returned to indicate the final
     transaction outcome.
   o CompletionWithAck: Same as Completion, but the coordinator must remember the
     outcome until receipt of an acknowledgment notification.
   o PhaseZero: A participant that wants the coordinator to notify it just before the 2PC
     protocol begins registers for this. A typical example is an application that caches data
     and needs a notification to write outstanding updates to a database. This is executed
     prior to the 2PC protocol.
   o 2PC: A participant such as a resource manager (e.g., database) registers for this, so
     that the coordinator can manage a commit-abort decision across all the resource
     managers. If more than one 2PC participant is involved, a PhaseOne and then
     PhaseTwo are executed. If only one 2PC participant is involved, a OnePhaseCommit
     is used to delegate the commit-abort decision to the participant.
   o OutcomeNotification: A transaction participant that wants to be notified of the
     commit-abort decision registers for this. Applications use outcome notifications to
     release resources or perform other actions after commit or abort of a transaction.

Example Atomic Transaction Message Flow




Above picture illustrates the interaction flows for the WS-Coordination protocols for an
atomic transaction using a common scenario. There are three hosts, each containing part of
the application (App1 is a web server that builds web pages, App2 is a middleware server
containing business logic and cached data, and DB is a database server). Each has its own
Muráncsik György                                    Web Servicese Transaction Management

                                               6.
                                                                 Web Services Architectures

coordinator containing the coordinator's side of an Activation service (AS) and a Registration
service (RS). Each application service also supports the participant end of the Activation and
Registration services.

App1 begins by doing the following:

   o It sends a CreateCoordinationContext message (message 1 in Figure AT1) to its local
     coordinator's Activation service ASa to create an atomic transaction T1, and gets back
     in a CreateCoordinationContextResponse message (2) a CoordinationContext C1
     containing the transaction identifier T1, the atomic transaction coordination type and
     CoordA's Coordination PortReference RSa.
   o It sends a Register message (3) to RSa to register for the Completion protocol and gets
     back a RegisterResponse message (4), exchanging protocol service PortReferences for
     the coordinator and participant sides of the two-way protocol
   o It sends an application message to App2 (5), propagating the CoordinationContext C1
     as a header named wscoor:CoordinationContext in the message.

App2 does the following:

   o Instead of using CoordA, it decides to interpose its local coordinator CoordB in front
     of CoordA, which acts as a proxy to CoordA for App2, so that CoordA is the superior
     and CoordB is the subordinate. It does this by sending a CreateCoordinationContext
     message (6) to the Activation service of CoordB (ASb) with C1 as input, and getting
     back (7) a new CoordinationContext C2 that contains the same transaction identifier
     (T1) and coordination type, but has CoordB's Coordination PortReference RSb.
   o It registers with CoordB for the PhaseZero protocol (8 and 11), because it caches data
     from the database DB, exchanging protocol service PortReferences for the coordinator
     and participant sides of the two-way protocol.
   o CoordB registers with CoordA for the PhaseZero protocol (9 and 10), exchanging
     protocol service PortReferences for the coordinator and participant sides of the two-
     way protocol.
   o It sends a message to DB (12), propagating CoordinationContext C2.

DB does the following:

   o Instead of using CoordB, it decides to interpose its local coordinator CoordC by
     sending a CreateCoordinationContext message (13), further extending the superior-
     subordinate chain. When it makes this association, it gets back (14) a new
     CoordinationContext C3 that contains the same transaction identifier (T1) and
     coordination type, but CoordC's Registration service PortReference RSc.
   o It registers with CoordC for the 2PC protocol because it is a resource manager (15 and
     20), exchanging protocol service PortReferences for the coordinator and participant
     sides of the two-way protocol.
   o This causes CoordC to register with CoordB for the 2PC protocol (16 and 19),
     exchanging protocol service PortReferences for the coordinator and participant sides
     of the two-way protocol.
   o This causes CoordB to register with CoordA for the 2PC protocol (17 and 18),
     exchanging protocol service PortReferences for the coordinator and participant sides
     of the two-way protocol.

Muráncsik György                                   Web Servicese Transaction Management

                                              7.
                                                                 Web Services Architectures




Recovery and interposition

WS-TXM layers on WS-CF, interposition is allowed though not required. Individual
participants may be subordinate coordinators to improve performance or to federate a
distributed environment into separate domains
Each participant or subordinate coordinator is responsible for ensuring that sufficient data is
made durable in order to complete the transaction in the event of failures. Recovering
participants or coordinators use the recovery mechanisms defined in WS-CF to determine the
current status of a transaction/participant and act accordingly.

Long running action

The long running action model (LRA) is designed specifically for those business interactions
that occur over a long duration. Within this model, an activity reflects business interactions:
all work performed within the scope of an activity is required to be compensatable. Therefore,
an activity’s work is either performed successfully or undone. How services perform their
work and ensure it can be undone if compensation is required, are implementation choices and
not exposed to the LRA model. The LRA model simply defines the triggers for compensation
actions and the conditions under which those triggers are executed.
Each LRA is tied to the scope of an activity. This means that when the activity terminates, the
LRA coordination protocol will be automatically performed either to accept or compensate
the work.
In the LRA model, each activity is bound to the scope of a compensation interaction.

Compenstor

A Compensator is the LRA participant that operates on behalf of a service to undo the work it
performs within the scope of an LRA or to compensate for the fact that the original work
could not be completed. How compensation is carried out will obviously be dependant upon
the service; compensation work may be carried out by other LRAs which themselves have
Compensators.
For example, consider the travel example. The user first attempts to book a first-class seat on
an airline; the compensator for this (which is executed in the event of a crash or failure to
complete the booking, for example) starts another LRA that tries to cancel the booking. If the
Muráncsik György                                    Web Servicese Transaction Management

                                              8.
                                                                  Web Services Architectures

cancellation LRA fails, then its compensator emails the system administrator for the airline
reservation site; if the cancellation succeeds, however, it tries to book an economy seat on the
same flight.




                                     Compensator LRAs

Business process transaction

In the business process transaction model (BP model) all parties involved in a business
process reside within business domains, which may themselves use business processes to
perform work. Business process transactions are responsible for managing interactions
between these domains. A business process (business-tobusiness interaction) is split into
business tasks and each task executes within a specific business domain. A business domain
may itself be subdivided into other business domains (business processes) in a recursive
manner. An individual task may require multiple services to work. Each task is assumed to be
a compensatable unit of work. However, as with the LRA model described earlier, how
compensation is provided is an implementation choice for the task.

The business process transaction model supports this synchronous and asynchronous
interaction pattern. Business domains are instructed to perform work within the scope of a
global business process. The business process has an overall manager that may be informed
by individual tasks when they have completed their work (either successfully or
unsuccessfully), or it may periodically communicate with each task to determine its current
status. In addition, each task may make period checkpoints of its progress such that if a failure
occurs, it may be restarted from that point rather than having to start from the beginning. A
business process can either terminate in a confirmed (successful) manner in which case all of
the work requested will have been performed, or it will terminate in a cancelled
(unsuccessful) manner, in which case all of the work will be undone.
If it cannot be undone, then this fact must be logged. One key difference between the business
process transaction model and that of traditional 2PC is that it assumes success, that is the BP
model is optimistic and assumes the failure case is the minority and can be handled or
resolved offline if necessary, or through replay/void/compensation, but not always
automatically, often requiring human interaction.




Muráncsik György                                    Web Servicese Transaction Management

                                               9.
                                                                 Web Services Architectures




                               Business processes and tasks


Business domains and interposition

In order to participant within a business process transaction (BP model), each business
domain is exposed as a single subordinate (interposed) coordinator, forming a parentchild
relationship; the business domain is identified by the coordinator URI. The interposed
coordinator is responsible for managing the domains participation within the overall business
transaction. The internal implementation of a domain is not the responsibility of this
specification. In order to perform work necessary for a business task a domain may use its
own business process transaction, ACID transactions, or some other infrastructure.




                          Example business process interposition


Some interest

Web Services – Atomic Transaction for WebSphere Application Server 5.0.2

The Web Services Atomic Transaction for WebSphere Application Server (WS-AT for
WebSphere Application Server) technical preview is an implementation of the Web Services
Atomis Transaction (WS-AT) and the Web Services Coordination (WS-COOR)
specifications. It provides transactional quality of service to the Web services environment,
allowing distributed Web service applications, and the resources they use, to take part in
distributed global transactions.

WS-AT for WebSphere Application Server uses the standard JTA support in the J2EE
programming model to scope transactions. JTA transactions are interpreted by the WS-AT

Muráncsik György                                   Web Servicese Transaction Management

                                             10.
                                                                                                        Web Services Architectures

for WebSphere Application Server runtime into CoordinationContexts such that a WS-AT
representation of the current JTA transaction is flowed on Web service application requests.


  Overview: role of WS-AT for WAS in server to server Web Service Application requests


            WAS Server                                                                     WAS Server


                                          Web Service Business request                         Web Service
                                                                                               Web Service
      Application         WS-AT WS-COOR                                                        Application
                                                                                                Application




                                                                           WS-AT WS-COOR
                                              Registration request




         J2EE                                  2PC Protocol flow                                   J2EE




When the Web service request enters the target server, WS-COOR is used to register for
participation in the 2PC protocol. The 2PC protocol is driven by the caller’s WS-AT
Coordinator at transaction completion.

But my question is that how to solve the heuristic rollback beacuse I have not found in those
sources. Although this implementation is given in class byte code and I had to decomplied
those code to java source code and I could not decompiled each class file. So here is the short
detail of the contexttype implementation:

public abstract class ContextType implements Serializable
{
  private AttributedDateTime expires;
  private AttributedURI identifier;
  private transient ThreadLocal __history;
  private transient ThreadLocal __hashHistory;

  public AttributedDateTime getExpires() {
       return expires;
  }

  public void setExpires(AttributedDateTime attributeddatetime) {
       expires = attributeddatetime;
  }

  public AttributedURI getIdentifier() {
       return identifier;
Muráncsik György                                                           Web Servicese Transaction Management

                                                                     11.
                                                                   Web Services Architectures

    }

    public void setIdentifier(AttributedURI attributeduri) {
         identifier = attributeduri;
    }
                 //Serialization implementation
}

Coordinationcontexttype implementation:


public class CoordinationContextType extends ContextType
  implements Serializable
{
  private URI coordinationType;
  private EndpointReferenceType registrationService;
  private SOAPElement[] _any;

    public URI getCoordinationType() {
         return coordinationType;
    }
                 //Serialization implementation
}

From this result the another question that WS-AT is implemented entirely in web services
implementation of every vendors.


Advantages

Benefit of Context

One of the main benefits of sharing context is that all participants can discover the result of
the execution of the overall cooperating unit of work, or scope of the shared function.
The context defines and gives certain logical frame to around the web services. The ability to
scope arbitrary unit of distributed work provides us to define more logical units in a big work.
We also have ability to define nested scopes hereby nested context.

The contex and scoping give a lot of important supporting for the complex software
development. For example in the business process planning we can use some kind of view of
object oriented programming. We can make use of the some of principles of the OOP and
approach the business process modell similarly in the aspect of the OOP.


Here are some example:

           we can build up our business process in modular. Here a modul symbolize a context,
            in BP model modul may be business task or business domain, but business domain


Muráncsik György                                        Web Servicese Transaction Management

                                                  12.
                                                                   Web Services Architectures

       consist of business tasks namely modul is built up moduls and business domains and
       business tasks make use of contex services.
      we can model the real world in our process i.e. we can use abstraction.
      Recources what is used in a context (modul) is protected from the other process,
       activity which is in the othermodul and they could not use accidentally those
       recourdes.
      reusing. We can reuse that moduls what we developed perviously.
      Tracing. I suppose that the tracing is solved or we ourself also accomplish that.

Benefit of Coordination:

One of the main benefits of a coordinator is that it can take the responsibility for notifying the
participants of the outcome, persisting the outcomes of the participants, and managing the
context.
When a coordinator represents a set of local participants, this is called interposition.
Interposition assists in achieving interoperability because the interposed coordinator can also
translate a neutral outcome protocol into a platform specific protocol.

Benefit of Transaction

The main benefit of adding transaction-based protocols is that the participants and the
coordinator negotiate a set of agreed actions or behaviors based on the outcome, such as
rollback, compensation, synchpoint, three-phase commit, etc


References:
Dev Center of BEA: Web Services Transaction
http://dev2dev.bea.com/techtracks/ws-transaction.jsp

Dev Center of BEA: Web Services Coordination
http://dev2dev.bea.com/technologies/webservices/ws-coordination.jsp

Web Services Composite Application Framework (WS-CAF)
Ver1.0
http://www.oasis-open.org/committees/download.php/4343/WS-CAF Primer.pdf


IBM developerWorks: Transactions in the world of Web services
http://www-106.ibm.com/developerworks/webservices/library/ws-wstx1
http://www-106.ibm.com/developerworks/webservices/library/ws-wstx2

Web Services Transaction Management (WS-TXM) Ver1.0
http://www.oasis-open.org/committees/download.php/4346/WSTXM.pdf

Web Services Context (WS-Context) Ver1.0
http://www.oasis-open.org/committees/download.php/4344/WSCTX.pdf



Muráncsik György                                     Web Servicese Transaction Management

                                               13.
                                                         Web Services Architectures

Web Services Coordination Framework (WS-CF) Ver1.0
http://www.oasis-open.org/committees/download.php/4345/WSCF.pdf

IBM AlphaWorks: Web Services Atomic Transaction for Websphere Application
Server
http://www.alphaworks.ibm.com/tech/wsat




Muráncsik György                              Web Servicese Transaction Management

                                        14.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:5/13/2010
language:English
pages:14