6 Introduction to Using Web Services Atomic Transactions

An introduction of usage of the web services atomic transactions to enable interoperability with other external transaction processing systems is detailed in this chapter.

It includes the following sections:

6.1 Overview of Web Services Atomic Transactions Framework

WebLogic web services enable interoperability with other external transaction processing systems, such as Websphere, Microsoft .NET, and so on, through the support of certain specifications.

These specifications are as follows:

These specifications define an extensible framework for coordinating distributed activities among a set of participants. The coordinator, shown in the following figure, is the central component, managing the transactional state (coordination context) and enabling web services and clients to register as participants.

Figure 6-1 Web Services Atomic Transactions Framework

Description of Figure 6-1 follows
Description of "Figure 6-1 Web Services Atomic Transactions Framework"

6.2 Overview of Web Services Atomic Transactions in WebLogic Server Environment

WebLogic Server interacts within the context of a web services atomic transaction.

Figure 6-2 shows two instances of such interaction. For simplicity, two WebLogic web service applications are shown.

Figure 6-2 Web Services Atomic Transactions in WebLogic Server Environment

Description of Figure 6-2 follows
Description of "Figure 6-2 Web Services Atomic Transactions in WebLogic Server Environment"

Please note the following:

  • Using the local JTA transaction manager, a transaction can be imported to or exported from the local JTA environment as a subordinate transaction, all within the context of a web service request.

  • Creation and management of the coordination context is handled by the local JTA transaction manager.

  • All transaction integrity management and recovery processing is done by the local JTA transaction manager.

For more information about JTA, see Java Transaction API and Oracle WebLogic Extensionsin Developing JTA Applications for Oracle WebLogic Server.

The following steps describe a sample end-to-end web services atomic transaction interaction, illustrated in Figure 6-2:

  1. Application A begins a transaction on the current thread of control using the JTA transaction manager on Server A.

  2. Application A calls a web service method in Application B on Server B.

  3. Server A updates its transaction information and creates a SOAP header that contains the coordination context, and identifies the transaction and local coordinator.

  4. Server B receives the request for Application B, detects that the header contains a transaction coordination context and determines whether it has already registered as a participant in this transaction. If it has, that transaction is resumed and if not, a new transaction is started.

    Application B executes within the context of the imported transaction. All transactional resources with which the application interacts are enlisted with this imported transaction.

  5. Server B enlists itself as a participant in the WS-AT transaction by registering with the registration service indicated in the transaction coordination context.

  6. Server A resumes the transaction.

  7. Application A resumes processing and commits the transaction.

6.3 Components of Web Services Atomic Transactions

Web services atomic transactions consists of a coordinator, activation service, registration service and application protocol X, Y.

Table 6-1 describes these components in detail.

Table 6-1 Components of Web Services Atomic Transactions

Component Description

Coordinator

Manages the transactional state (coordination context) and enables web services and clients to register as participants.

Activation Service

Enables the application to activate a transaction and create a coordination context for an activity. Once created, the coordination context is passed with the transaction flow.

Registration Service

Enables an application to register as a participant.

Application Protocol X, Y

Supported coordination protocols, such as WS-AtomicTransaction.

6.4 How Web Services Atomic Transactions are Enabled on a Web Service (Inbound)

You enable and configure web services atomic transactions on a web service at design time using Oracle JDeveloper when creating a web service, or at deployment time using the Fusion Middleware Control.

For more information, refer to the following sections:

For information about configuration options, see Web Services Atomic Transaction Configuration.

6.5 How Web Services Atomic Transactions are Enabled on a Web Service Client (Outbound)

You enable and configure web services atomic transactions on a web service client at deployment time using the Fusion Middleware Control.

You configure the version and flow type, as defined in Table 6-3.

For more information, see "Configuring Atomic Transactions Using Fusion Middleware Control" in Administering Web Services.

You enable and configure web services atomic transactions at design time using Oracle JDeveloper when creating a web service, or at deployment time using the Fusion Middleware Control. For more information, refer to the following sections:

For information about configuration options, see Web Services Atomic Transaction Configuration.

6.6 Web Services Atomic Transaction Configuration

You can set certain configurations to enable web services atomic transactions.

Table 6-2 summarizes the configuration options that you can set when enabling web services atomic transactions.

Table 6-2 Web Services Atomic Transactions Configuration Options

Attribute Description

Version

Version of the web services atomic transaction coordination context that is supported. For web service clients, it specifies the version used for outbound messages only. The value specified must be consistent across the entire transaction.

Valid values include WSAT10, WSAT11, WSAT12, and DEFAULT.

The DEFAULT value for web services is driven by the inbound request and can be any of the values.

The DEFAULT value for web service clients is as follows:

  • If the flow option is WSDLDRIVEN, then the version advertised in the WSDL is used.

  • If the flow option is any setting other than WSDLDRIVEN, then WSAT10 is used.

Flow type

Whether the web services atomic transaction coordination context is passed with the transaction flow. For valid values, see Table 6-3.

Table 6-3 summarizes the valid values for flow type and their meaning on the web service and client. The table also summarizes the valid value combinations when configuring web services atomic transactions for an EJB-style web service that uses the @TransacationAttribute annotation.

Table 6-3 Flow Transaction coordination contextypes Values

Value Web Service Client Web Service Valid EJB @TransactionAttribute Values

NEVER (Default for SOA service)

JTA transaction: Do not export transaction coordination context.

No JTA transaction: Do not export transaction coordination context.

Transaction flow exists: Do not import transaction coordination context. If the CoordinationContext header contains mustunderstand="true", a SOAP fault is thrown.

No transaction flow: Do not import transaction coordination context.

NEVER, NOT_SUPPORTED, REQUIRED, REQUIRES_NEW, SUPPORTS

SUPPORTS

JTA transaction: Export transaction coordination context.

No JTA transaction: Do not export transaction coordination context.

Transaction flow exists: Import transaction context.

No transaction flow: Do not import transaction coordination context.

SUPPORTS, REQUIRED

MANDATORY

JTA transaction: Export transaction coordination context.

No JTA transaction: An exception is thrown.

Transaction flow exists: Import transaction context.

No transaction flow: Service-side exception is thrown.

MANDATORY, REQUIRED, SUPPORTS

WSDLDRIVEN (SOA references only, and the default)

Behaves according to the value that is advertised in the web service WSDL.

N/A

Depends on advertised value.

6.7 Properties Configured for Messages Exchanged Between the Coordinator and Participant

You can secure messages exchanged between the coordinator and participant using the WebLogic Server Administration Console.

To secure messages exchanged between the coordinator and participant, you can configure the properties defined in the following table using the WebLogic Server Administration Console. These properties are configured at the domain level.

For detailed steps, see "Configure web services atomic transactions" in the Oracle WebLogic Server Administration Console Online Help.

Table 6-4 Securing Web Services Atomic Transactions

Property Description

Web Services Transactions Transport Security Mode

Specifies whether two-way SSL is used for the message exchange between the coordinator and participant. This property can be set to one of the following values:

  • SSL Not Required—All web service transaction protocol messages are exchanged over the HTTP channel.

  • SSL Required—All web service transaction protocol messages are exchanged over the HTTPS channel. This flag must be enabled when invoking Microsoft .NET web services that have atomic transactions enabled.

  • Client Certificate Required—All web service transaction protocol messages are exchanged over HTTPS and a client certificate is required.

For more information, see "Configure two-way SSL" in the Oracle WebLogic Server Administration Console Online Help.

Web Service Transactions Issued Token Enabled

Flag the specifies whether to use IssuedToken to enable authentication between the web services atomic transaction coordinator and participant.

The IssuedToken is issued by the coordinator and consists of a security context token (SCT) and a session key used for signing. The participant sends the signature, signed using the shared session key, in its registration message. The coordinator authenticates the participant by verifying the signature using the session key.