Business Process Execution Language for Web Services 2nd Edition
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

Web Services Transaction Specifications

The Web Services Transaction specifications define the coordination types discussed in the previous section. These specifications are used along with WS-Coordination and WS-Security to implement distributed transactions across a set of diverse web services.

The Web Services Transaction Specifications define two specifications:

  • Atomic transaction (AT)
  • Business activity (BA)

An atomic transaction is a typical single-domain transaction that requires the ACID properties to be satisfied. This is typically used for activities of short duration and is applicable within a limited trust domain.

A business activity is used for activities having long duration. In this case, due to the long duration, the changes made by each participant are not hidden from others for an unduly long time and so are immediate and permanent. Exceptions are handled by the business logic and compensating transactions are used to guarantee consistency.

Both AT and BA allow coordination between applications that use different proprietary protocols and are running across different hardware and software infrastructures. Additionally, BA allows coordination across trust boundaries.

Atomic Transaction

In the case of atomic transactions, actions taken by all the involved participants before committal are tentative. If the coordinator commits the transactions, the actions are made persistent and are visible to others. If the coordinator aborts the transaction, all the actions by participating processes are rolled back and the application returns to its former state as if nothing occurred.

Atomic transactions leverage the WS-Coordination specification to coordinate the activities of all the involved parties. As seen in the previous section, WS-Coordination uses CoordinationContext to share the context information between participants.

Sharing Context Information

We use the CoordinationContext as follows:

<?xml version=”1.0” encoding=”utf-8”?>
<S:Envelope xmlns:S=”http://www.w3.org/2001/12/soap-envelope”
  <S:Header>
      ...
 <wscoor:CoordinationContext
                         
        xmlns:wscoor=”http://schemas.xmlsoap.org/ws/2002/08/wscoor”
        xmlns:wsu=”http://schemas.xmlsoap.org/ws/2002/07/utility”
        ...
        <wsu:Identifier> ... </wsu:Identifier>
        <wsu:Expires> ... </wsu:Expires>
     <wscoor:CoordinationType>
 http://schemas.xmlsoap.org/ws/2002/08/wstx
 </wscoor:CoordinationType>
        <wscoor:RegistrationService>
          <wsu:Address> ... </wsu:Address>
        </wscoor:RegistrationService>
        ...
 </wscoor:CoordinationContext>
      ...
  </S:Header>
  ...
</S:Envelope>

The CoordinationContext is defined in the message header. The CoordinationType is set to the specified URI. As discussed in the previous section, the CoordinationContext element defines the identifier, expiry date,and the address of the registration service. Additionally, it can contain any application-specific information.

As seen in the previous section, the application sends a CreateCoordinationContext message to the coordinator. The message may contain a CurrentContext. If the current context is provided, the coordinator will act as a subordinate to the current coordinator. If the current context is not provided, this will be treated as a new transaction and a new transaction context, along with its associated protocols, is created and returned to the application.

Coordination Protocols

After obtaining the context, the application sends a Register message to the coordinator to register a desired protocol with the coordinator. An application may register with the coordinator for multiple protocols by sending multiple messages to it.

We will now look at the coordination protocols that are defined in this specification. The specification defines the following five protocols:

  • Completion
  • CompletionWithAck
  • Two‑Phase Commit (2PC)
  • PhaseZero
  • OutcomeNotification

Completion

Applications use this protocol to tell the coordinator to either commit or roll back the current transaction. The coordinator returns the status of the final outcome.

CompletionWithAck

This is similar to the completion protocol, except that an acknowledgement of the status is returned to the coordinator. Until such time, the coordinator remembers the outcome of the transaction.

Two-Phase Commit

When there are multiple participants in a transaction, each participant registers with the coordinator using a 2PC protocol. The coordinator manages the commit or abort decision across all the involved resource managers. During phase one, all the resource managers are informed of the updates they are required to perform. Once all resource managers agree to perform the updates, during the second phase of the commit, the coordinator requests them to write the updates. This protocol is required for distributed transaction processing.

PhaseZero

A participant may cache the data and want to write the data to the database before a two-phase commit begins. In such cases, the application registers with the coordinator using a PhaseZero protocol. The coordinator now notifies the registered application before it begins a 2PC protocol.

OutcomeNotification

A participant interested in the outcome of a transaction registers with the coordinator with this message. The coordinator informs the registered participant whether the current transaction is committed or rolled back. The participant may use this information to release resources held by it or to perform any other desired operation, depending on the transaction outcome.

Business Activity

The business activity transaction type is used whenever coordination for achieving a distributed transaction between several participants having different vendor implementations, such as IBM, Sun, Microsoft, and so on is desired. A business activity consists of a series of tasks, each executed independently of the others. For example, a purchase business activity may consist of sending requests for quote (RFQ), selecting the lowest quote, negotiations, and eventually generating and sending a purchase order to the winner. The entire business process may require human interventions and is usually a long-running activity. The process requires several cooperating partners. The partner processes are not under direct control of the initiating process. Thus, the entire activity consists of several tasks executed in a specified sequence. Such a sequence may be specified in BPEL. Each task may be an atomic transaction. However, the entire business activity cannot be implemented as an atomic transaction. The reasons for not doing this are:

  • The process is long running and it is not advisable to lock the resources for unknown time durations.
  • The partners may not allow the initiating process to put locks on their resources.

The business activity coordination type used in WS-Coordination allows you to coordinate the activities of several participants in such situations. The coordination process and the flow of events remain the same as in the previous sections.

Each task runs as an atomic transaction. If the initiating process decides to abort the business activity, a compensating transaction is sent to the involved participants requesting them to reverse the activities they have performed so far as part of the current business activity.

Sharing the Context Information

The application sends a message to the coordinator for defining the coordination context. The message header uses the CoordinationContext element as shown below:

<?xml version=”1.0” encoding=”utf-8”?>
<S:Envelope xmlns:S=”http://www.w3.org/2001/12/soap-envelope”
  <S:Header>
      ...
 <wscoor:CoordinationContext
          xmlns:wscoor=”http://schemas.xmlsoap.org/ws/2002/08/wscoor”
          xmlns:wsu=”http://schemas.xmlsoap.org/ws/2002/07/utility”
                ...
          <wsu:Identifier> ... </wsu:Identifier>
          <wsu:Expires> ... </wsu:Expires>
 <wscoor:CoordinationType>
 http://schemas.xmlsoap.org/ws/2002/08/wsba
 </wscoor:CoordinationType>

          <wscoor:RegistrationService>
              <wsu:Address> ... </wsu:Address>
          </wscoor:RegistrationService>
          ...
 </wscoor:CoordinationContext>

      ...
  </S:Header>
  ...
</S:Envelope>

This header is similar to the one used for an atomic transaction, except that the URI used in the CoordinationType is different. As in the earlier case, the header may contain additional application-specific information. Similar to the previous case, if the message contains the CurrentContext, the target coordinator is interposed as a subordinate to the current coordinator, else a new business activity context is created.

Coordination Protocols

The specification defines two protocols for the business activity coordination type:

  • BusinessAgreement
  • BusinessAgreementWithComplete

A business activity is initiated by some business task; we call it a parent task. The parent task delegates several business activities to child tasks. The child task registers with its parent and keeps the parent updated on its state. The two agreements defined here address the proper coordination between the parent and the child scopes.

BusinessAgreement

The child scope participant registers with the parent scope coordinator. The child knows the scope of business activities or tasks it is supposed to perform as part of the outer business activity. During the business activity, a child may send the following messages to the coordinator:

  • Exited: The child scope sends this message after completing all required activities.
  • Completed: After completing the required tasks, a child may decide to continue its participation in the business activity and notify the coordinator of such intent. After completing such activities, the child sends a Completed message to the coordinator.
  • Closed: The parent may request the child to close. The child then sends a Closed message to the coordinator after closing.
  • Compensated: The parent may request the child to compensate an earlier activity. The child sends a compensated message to the coordinator after performing the desired compensation.
  • Canceled: At the request of the parent, the child will cancel the current activity and send a canceled message to the coordinator after doing so.
  • Faulted: If an error occurs while performing the task, the child sends this message to the coordinator.

BusinessAgreementWithComplete

This protocol is similar to BusinessAgreement, except that now the parent informs the child whenever it has completed all the desired tasks. Thus, the child keeps on performing the tasks on behalf of the parent until the parent sends a Completed message to the child marking the end of all the requests to the child as a part of the current business activity.

Having seen the Web Services Transaction specifications, we will now study another protocol for implementing business transactions.

上一章目录下一章