Use WS-atomictransaction and JTA distributed transactions

Introduction

Current enterprise applicationsProgramIn development, web services are becoming more and more common. However, traditionally, they have not reached the same level as the supported services. When building J2EE applications, especially transaction services, enterprises rely on these services. This topic describes how a transaction service can be seamlessly connected to a web service with the help of a Web service transaction in a J2EE environment using Java transaction APIs.

This article briefly outlines this new Web Service technology and the proven traditional transaction technology, explains how they can achieve interoperability across distributed J2EE environments and even across different transaction architectures.

This article assumes that you have understood the concepts of transaction services (such as ACID properties, commit/rollback, Transaction Division, and so on) to an intermediate level. For more information about the transaction service, especially JTs, seeArticle Java Theory and Practice: Understanding JTs -- An Introduction to transactions. This article can be found on developerworks (see references ). Similarly, I would like to recommend a good book with more comprehensive information about transactions, which was co-authored by Philip Bernstein and Eric newcomer.Principles of Transaction Processing(See references)

What is Java transaction API (JTA )?

JTA is a J2EE solution for transaction services. Essentially, it describes the transaction interface (suchUsertransactionInterface. developers can use this interface directly or use this interface through the J2EE container to ensure that the business logic can run reliably.

JTA has three main interfaces:UsertransactionInterface,TransactionmanagerInterfaces andTransactionInterface. These interfaces share common transaction operations, suchCommit ()AndRollback ()But it also contains special transaction operations, suchSuspend (),Resume ()AndEnlist ()They only appear on a specific interface to allow a certain degree of access control in the implementation. For example,UsertransactionAble to perform Transaction Division and basic transaction operations, whileTransactionmanagerAbility to perform context management. This article only requires you to have a basic understanding of JTA.

What are the benefits of JTA?

JTA is a well-defined transaction service that can be directly used by J2EE application developers. As an option, an application may also be deployed in this way, and the container will manage transaction behavior in place of developers. In the latter case, developers are able to concentrate on the business logic of their applications, and the J2EE container is responsible for the transaction logic.

The advantage of a transaction service with a clear model is that each individual transaction always maintains four ACID properties. Despite this implementation issue, WebSphere Application Server provides the ability to protect these acid features for each imported or exported transaction, regardless of the number of concurrent transactions.

JTA restrictions?

Having gone through all the transaction architectures, it is very difficult to efficiently send a group of transactions to other transaction services that do not share the same model while maintaining atomic units of work. In our case, the modeled JTA runs on Java Transaction Service (JTs), and JTs processes the requests sent by the input and output transactions.

Because JTs is a Java implementation of the Object Transaction Service (OTs) defined by CORBA, it can only be connected to another OTS model. Therefore, one transaction can only be transferred to another OTS-compatible target, typically another J2EE implementation. Because the JTA and JTs specifications do not limit the underlying implementation of these interfaces (as long as they comply with the model), transactions can be securely transmitted between two J2EE-compatible application servers, there is no risk of losing their ACID properties. However, the J2EE server does not have to handle non-J2EE calls.

Some J2EE servers may be exceptions. For example, WebSphere Application Server correctly processes an input CORBA Request associated with a CORBA-compatible transaction and sends the transaction to the thread, then execute the transaction in its context. However, in most cases, when you try to move between the transaction model, you have to go beyond JTA and JTs and look farther. Here the Web service appears.

What is Web service?

A Web Service is an object that can be deployed on an accessible server as part of an application for internal and external customers. A Web Service is described by its Web Service Description Language (WSDL. It defines the usage of input and output parameters for a Web service that uses XML-based calling (typically using the SOAP protocol. For example, the client can view the WSDL published by the server and then construct the clientCodeTo call the web service. Once completed, it can be called by passing the SOAP message to a web service method. This SOAP message contains information such as the method name and any parameters it requires. The return value will be sent back in another SOAP message and then extracted by the customer.

What are the benefits of using Web Services?

It doesn't matter which language the Web Service is written by, because WSDL does not have details about the definition language or programming model (such as Java and J2EE technologies ). This gives the Web Service author and client author the flexibility to choose his preferred solution.

Let's compare the web service and Enterprise JavaBean (EJB) components. The EJB component requires RMI-compiled code so that the client can access it. Therefore, it can create local stub objects like its proxy. Therefore, it is necessary to re-allocate the stubs (stub) to all clients each time they change ). In any case, you will use the WSDL together with the Web service, so the client can construct their own client call code, and the local class path does not require the server class to execute the call. This model provides a very clever method call process. As a part of the J2EE model, EJB must be called by Java clients, preferably a client managed by J2EE. On the other hand, the Web service can be called by any client code, which can construct a well-structured SOAP request. Therefore, for example, a Web Service deployed on the J2EE server can be called by C ++.

Restrictions on Web Services?

Because the nature of Web Service requests (via HTTP soap) is very different from that of other method calls (for example, an Rmi EJB call using IIOP, code that supports execution of distributed transactions is not available until recently. This has become a major problem when using Web Services as part of Distributed Transaction enterprise applications. Essentially, a Web service cannot run in the transaction context starting before a web service call, nor can it send a transaction context to another component.

So what is the problem?

If Web services are used in industry, make sure they work in a reliable and predictable manner when running in a transaction environment. Until now, web services can only use transactions independent of other components-rules defined in the scope of Web Services methods and implemented by the underlying transactions-and cannot physically leave web services or enter another web service. Enterprise applications have transactions that always flow between enterprise components. This must be a standard for Web Services to ensure they are correctly used, avoid changing your programming style by taking advantage of the functionality of web services by simply ignoring the transaction support that is relied on and used in all of our strict enterprise applications.

So what is the solution?

The solution is a new technology called WS-transaction. It can adjust the transaction context. This context can be used by web services, other J2EE components such as EJB, and other non-J2EE transaction services that support WS-transaction.

WS-transaction is a specification. It extends the WS-Coordination specification to define a coordination that supports atomic transactions.

What is WS-coordination?

WS-coordination is a coordination framework that enables distributed participants to reach an agreement on a general outcome over their individual actions.

Essentially, this means that distributed participants (for example, two application servers on different machines) can use WS-coordination to combine the actions of each participant. Further, further management of these actions is achieved by ensuring that they fully agree to produce a single result for all actions they perform in this coordination context. Otherwise, these functions cannot be completed in a controlled manner.

The Coordination context can be seen as an identifier, and the behavior is executed under this identifier. For a comparison, this concept is very similar to the transaction context. When the transaction is completed, it is managed in the transaction context. When the context is called to determine or roll, the task is completed. The additional information contained in the Coordination context is a coordination identifier, detailed information about the coordination type, and the coordination protocol that includes port information so that the coordination service can be accessed. These terms are defined below.

 

Coordinate the service, orCoordinator), Which is further composed of three services:Activation Service),Registration Service)AndCoordination Protocol)Service. Activate Service SupportCreatecoodinationcontextOperation to allow the existence of a new coordination context. The Registration Service supports the Register operation to allow participants to perform work in the Coordination context. The coordination protocol service supports the use of the coordination protocol, which defines the behavior and communication between the Coordinator and the participants.

The coordination type is a fixed set of coordination actions. This set details the collection of Coordination protocols and how coordinator should drive the completion. The WS-transaction specification describes two coordination types --Atomic transaction)(AT) andBusiness Agreement)(Ba ). Each of these types includes a coordination protocol. For example, the atomic transaction (atomic transaction) Coordination type includesTwo-phase commit protocol(Durable2pc) andPhaseZero Protocol(Volatile2pc. You can use these two protocols in an environment that supports atomic transactions.

The business agreement coordination type provides a different function type. It is designed for longer frames. Unlike an atomic transaction, you normally have a very short life cycle associated with it. An example of the business agreement protocol is that it is called a business agreement, which is a compensation agreement.

What is the relationship between WS-coordination and WS-transaction?

WS-coordination is a basic framework that makes distributed results of activities between participants possible. WS-transaction defines the coordination type, such as atomic transaction. The coordination type is defined using the WS-coordination framework. Coordinator must follow these rules when communicating with participants. The difference between the two is very important.

The main coordination process between two applications and a coordinator is shown in figure 1 below.

1. App1Send a request to the activation service on the Coordinator.
2. The Coordinator starts a new activity and uses itsCoordinationcontext(The XML message of the Coordinator)App1Make a response.
3. App1Submit a request to the registration service to register the use of coordination protocol X.
4. App1Call it as expectedApp2, TransferCoordinationcontextTo the Coordinator.
5. App2Request to the Registration Service (using parameters such as port information, they canApp1TransmittedCoordinationcontextTo register and use the coordination protocol y.
6. App2End its work and return the controlApp1The activity is over.
7. The coordinator uses protocol X-type message responseApp1.
8. The coordinator uses the Y-type message response protocolApp2.

Coordinator mediation

In a real world, Web services may be transactional and distributed, and the initiators of the Coordinator (App1) SetCoordinationcontextTo any participant in the activity that it expects (App2). The receiver of this context has two options: they can use the created Coordinator (CA), Or, if they are willingCoordinationcontextTo the new coordinator. Then, select the new coordinator (CB)App2. It will includeCAThe same activity identifier, but whenApp2To its CoordinatorCBWhen the durable2pc protocol is registered, its request is directly sent to the Coordinator.CA. Similarly, at the end, the message preparation and submission will arrive at the endApp2(It has registered the durable2pc protocol) beforeCAPass to CoordinatorCB.

See section 4.1 of the WS-transaction specification.At3.1 example atomic transaction message flow, Where you will see a good example of the WS-coordination process between an application and the mediation coordination (see references ).

Web service transaction: WS-atomictransaction)

WS-atomictransaction is a special coordination type for atomic transactions. It provides a set of Coordination protocols. These coordination Protocols are:

• Completion
• Completionwithack
• Volatile2pc
• Durable2pc
• Outcomenotification

After the coordination context is created, the coordination type is specified, but the coordination protocol is not specified until registration. Any participant can register any number of Coordination protocols and should send and receive the appropriate messages defined by the Protocol. For example, if a participant registers the durable2pc protocol in the coordinator, a preparation message is sent to the participant upon completion, they will be considered to vote in a way similar to normal transaction resources. For more information about each protocol and their status chart, see the WS-transaction specification, section 4th.At3 Coordination protocols(See references ).

How can we use JTA transactions with WS-atomictransaction?

Because JTA and JTs are implementation-related, the examples I will use are WebSphere Application Server v5.0.2 and WS-transaction tech preview. In this scenario, there will be two machines, each running with an application server, as shown in figure 2. Application Server A deploys and runs a bean managed transaction (BMT) EJB component. Application Server B deploys and runs a web service. The EJB component uses the interfaces provided by JTAUsertransactionStart a transaction. It executes transactions on the Xa-compliant database (step 1) and then sends a request (step 2) to the Web service on Application Server B using SOAP/HTTP ). The Web service executes work on the Xa-compliant database (Step 3), then returns to the EJB component (step 4), and uses it again.UsertransactionInterface to submit transactions. All the transactions executed by the EJB and web services to the database have been included in the scope of an activity, which was created by the Coordinator just before the Web service was called (step 2, it has been submitted and stores all acid features. It is like a single unit of work.

Let's take a look at the following two fields: J2EE and Web services. In the J2EE field, the transaction model used is JTA. In the Web service field, the transaction model used is WS-atomictransaction. WebSphere Application Server regards a Java Web Service as a J2EE object, which means that the implementation of Web Services belongs to the J2EE field, while the invocation belongs to the Web service field. In the WebSphere field, it is always the responsibility to correctly drive the model being used (JTA or WS-atomictransaction.

Figure 2 shows how easy it is to include web services in a transaction enterprise application, it also shows how seamless the Web service is for users who run the Web service in the import transaction context without having to pay a line of code.

Note: The EJB component is running in a managed environment (EJB container) and the web service is compliant with JSR 109.

Can it only work with JTA?

WS-coordination relies on its XML-based calling to take advantage of its Web Service advantages. Because the protocol used to call the WS-coordination operation is soap, the message content is plain text in XML format. This means that when HTTP is passed to the Web service, the customer's details cannot be identified simply by the soap package itself, for exampleProgramming Language. Therefore, WS-atomictransaction can be connected to any other transaction service that uses any programming language that supports WS-atomictransaction.

In a recent Web service demonstration sponsored by IBM and Microsoft, this cross-Transaction Service and programming language interoperability of WS-atomictransaction is presented. Figure 3 shows a scenario that demonstrates this technology.

In Figure 3, A. NET Server starts a non-JTA transaction and initiates a web service call request to two websphere application servers and another. NET Server. Each application server uses their underlying transaction service to execute transactions. Each time you can use WS-transaction to call a web service that you will transfer. When the initiators complete the transaction, you use the WS-transaction technology to coordinate each participant and ensure that they have been completed, as if they were a single unit of work.

Summary

In this article, you have learned the basic concepts of WS-coordination and WS-transaction. Up to now, Web Services cannot use transactions in distributed environments. WS-transaction allows the Web service to execute transactions, which are part of the broader activity generation components, application servers, and even implementations, as shown in the demo of IBM and Microsoft Web Services.

With the support of WS-transaction, we can use Web Services reliably as part of our enterprise applications because it has embedded transaction support into other enterprise components.