Transaction processing for WebService

Because the question is more discussed, so another topic is opened up.

If you just want to solve the transaction synchronization problem between the two systems, you can use the method of judging whether the service is successful, namely:

* A system starts its own business, processes its own data, then ...
* Call the services of system B before committing.
* System B starts its own transaction B, processes the data in the transaction, and commits the transaction.
* B System makes the information of the success or not of its own transaction as the return value feedback a system.
* A system determines whether a transaction is committed or rolled back based on the transaction success of B.

However, before continuing in-depth discussion of this issue, ask an extension question: When the subsystem for transaction control between distributed systems is not two, but N, what if transaction control?

Distributed transactions have always been a difficult problem to solve. In the distributed application for DCOM, there is a distributed transaction support strategy, the general idea is to use two-segment transaction submission method, the first commit is pre-commit, after the pre-commit can be rolled back. The second commit is a permanent commit and cannot be rolled back after submission. And, if the pre-submission succeeds, the second commit must be successful, and the system has to be able to guarantee that.

In this way, once each system supports this two-stage commit, it is possible to adopt such transaction management: A control role submits execution requirements to each distribution system and requires that the first transaction commit be completed. When the first commit of each system succeeds, all systems are required to complete the final permanent submission, which is sure to be completed, so there is no need to worry about the success of this submission.
If some applications fail in the first commit, all applications are required to roll back the transaction.
Some database software natively support transaction nesting, such as SQL Server, unfortunately, our main database Informix does not support.
In order to simplify this kind of distributed transaction management, some middleware products can be used, the more extensive is Ms DTS.

As you may have seen, such a transaction control strategy can satisfy the acid requirements of a transaction in a distributed environment, but it is required for each distributed component, which is not a problem in a distributed application based on COM, remoting,jrmi technology. But in a scenario with a Web service, this is problematic.

Question 1. Web service is a kind of integration method, which is based on loose coupling, in general, it advocates the use of stateless method.
WebService argues that there is no context between the two invocations, that is, one call has nothing to do with any of the previous and subsequent calls, and one commit completes a complete processing. But distributed transactions require the parties to maintain a dialog between two conversations, so that when this permanent commit is made, the final commit is made to a transaction that has previously been successfully pre-committed.
When we encounter this problem, we have to ask ourselves one more question: Have we chosen the right integration technology? If there is such a tight transaction coupling between multiple systems, I suspect that they are actually the same application system. In the same application system, there should be the same platform, the same process space, the same data model and the data source. In this case, using Web service is a bad choice, and Web service should be used for system integration of different platforms, different applications, different data models. Even if it is necessary to implement distributed architecture among modules for some reason in the same application system, far-process access technology within the same technology platform should be adopted, which can usually provide better coupling support than Web service.

Well, assuming you're thinking, the answer to the question is "yes": we do have to implement distributed transaction control between heterogeneous, multiplatform, and inherently low-coupling systems. So, WebService still useful?
Thankfully, Web service advocates a stateless approach between interactions, but it is not forbidden to use stateful interactions. Web service is also a web technology, and State preservation in web technology is probably one of the first problems to be solved. In all Web development technology platform, there are session mechanism, whether these sessions through ip,cookies, hidden input to achieve, or URL sessionid to achieve, anyway, there are ways to achieve, Please refer to the session support mechanism on the platform you are using. 10,000 steps back, you can also be implemented by maintaining an application-level transaction pool in the server, and not the last committed transaction objects are placed inside, each transaction object is given a unique ID to identify the identity of a Dictionary object pool. If the transaction is successful, the ID of the transaction is returned to the caller, and when the second commit is made, the ID of the transaction is submitted as a parameter. (casually mention, in this way, you must not put the object's pointer, handle, reference to what the platform-related values to the client side, not afraid of security problems, but these values in the distribution system is meaningless, the last pointer returned to the garbage collector has been moved to another place)

In any case, the webservice is a non-connected protocol on the communication layer, and the TCP connection is disconnected between each of the two invocations, so you must be responsible for the lifetime of these sessions by using the session mechanism to manage the context. Imagine what would happen if a transaction context was turned on and the client system suddenly became a machine? In the same application domain, when the client has an opportunity to interrupt the connection, the server immediately interrupts and rolls back the transaction, but in WebService, the state manager cannot immediately feel that the caller of the transaction has lost control, only after a certain amount of time, only to discover: "Aye?" This transaction has been n long time no one has visited! Come on, get back! "In ASP., the default state timeout is about 20 minutes, and the JSP is about the same, and what's the impact of a 20-minute transaction blocking the data source?" Therefore, you must consider the appropriate state duration and transaction isolation level to reduce the performance impact on the data source.

Question 2. The "anti-pattern" methodology of Web service makes it impossible to unify a common abstraction interface between systems.
Web service is a kind of "anti-pattern" system architecture idea, that is, not the general starting from the first modeling and abstraction interface, and then by each distribution system to implement the interface of the system construction, but in turn: The system may have been completed, the problem is the information between the two systems interaction, Therefore, the interface specification of the interaction is based on the need, the system data model to the paradigm to pick pick and pick.
Therefore, the interface abstraction is not supported in WebService: You cannot define an abstract transaction interface that each system must implement, and then the various systems implement the polymorphism of the interface, and finally call the unified transaction interface in the application that assumes the transaction controller to dispatch the distributed transaction. Although such interface models are supported in far-process invocation techniques in many object-oriented development platforms, as previously mentioned, Web service is a loosely coupled anti-pattern methodology for integration rather than for distributed objects in tightly coupled systems.
So, it's a little annoying, but once again I'm tempted to ask the question I've asked: do we really have the right technology? If there is such a level of interface coupling between multiple systems, I really have to be more and more skeptical that they are actually the same application system.
Suppose your answer is "Yes, they really are not the same system, they are heterogeneous platform, heterogeneous data!" "Well, then go on. Let's use a Web service to complete the integration, but you must forget your OOP ideas, code honestly, and use tedious, repetitive code to control all of your system's transactions, and don't try to save things with the concept of object abstraction.
Are you sure?
What if the transaction controller is independent? Suppose we set up an application dedicated to distributed service control, and advertise the interface as a Web service, allowing other applications to register their own two-segment transactions with the Web service interface to open, commit, and fallback. Then, when a customer wants to start a distributed transaction, they can initiate a distributed transaction request to the transaction controller, select the parties to the transaction, initiate a distribution, and finally direct the commit request to the transaction controller, rather than the individual transaction parties, so that the transaction control polymorphism can be implemented in the transaction control server. While implementations may be implemented by looking at tables, rather than platform-level abstractions, such a server is a polymorphic implementation part for transactional clients.
If it is really faster and better than MS to implement such a Web service interface, distributed transaction controller for heterogeneous systems, Nasdaq may have your place!

Question 3. Heterogeneous platforms do not necessarily support two-segment transactional commit mode.
Web services are geared towards the integration of a fully heterogeneous platform, so it is clear that each platform can not be expected to support two-segment commit transaction mode. However, the standard is the standard, the agreement is the agreement, the standard is to let everybody abide by, if a platform originally does not support two-segment transaction, then in order to support the distributed transaction, it must transform to achieve two-stage transaction commit.
How the transformation is internal to each application system, for this article discusses the whole, also here a little involved.
The preferred approach is implemented by means of data caching. Many OO systems have adopted the so-called N-tier architecture, that is, the business object and the relational table model, the business object is located in the system memory or cache, by the Runtime object container management, the container according to a certain policy, the cache of business objects to the database such as Hisanaga media storage, or load the required business objects from the database, and during the save and load process, the conversion of the object to the table data is done, or vice versa.

In a typical n-tier middleware product, there are two levels of transactions, that is, transaction control for objects in the cache and transactions for the persistence process, and you can consider simply committing two of the transactions in the distribution transaction at the two transaction levels. However, this approach has to take some risks, such as the success of the transaction at the object container level, and the failure of the database transaction commit, which will result in a risk of inconsistent data, although this is not a very high probability.

In the case of using a data container, you can also use the historical state of the saved object to implement a manual fallback of the transaction. Because after the business object layer is separated from the persistence layer, the persistence layer does not have complex logic when the data is updated, just a list of data update sequences that are not related to business significance. If you can maintain the state history of the object, you can restore the state of the object to the old old version when needed. In fact, in some excellent middleware platform, this mechanism has been implemented very well. (You can refer to the Graphtalk platform for object persistence management, which is genius!) ）

Another dumb way to do this is to use data logic to commit two transactions, such as when a request is made for the first time, that is, a real commit, and a second commit that does nothing but returns to normal. If fallback is required, the data is updated to the old state through data logic or business logic. This approach is definitely a headache.

Fortunately, however, we are not designing a two-segment transaction mechanism for a common database. To be aware, service-oriented transactions are not the same as database-level transactions, and there is an infinite likelihood of the operation of the data during a transaction. Usually we a service is a function, its data operation process, the data change way is predictable, so the state of recovery data is a concrete and fixed process, as long as we design data recovery function for each service operation.

Finally, if these are not possible-more than 50% of the possibility, because of time, cost, technology and other reasons, these can not be achieved, then only by two words: compromise.

Transaction processing of WebService (RPM)