In the world of web services there seems to be some confusion about the value and place of transactional control. The general WSDL definition does not even mention this problem and there are several competing standard approaches like WS-Transaction (IBM et al.), BTP (Choreology et al.) or WS-TXM (Oracle et al.), which try to provide a satisfactory solution to this issue. I therefore would like to present some thoughts which stem from the perspective of business processes and their requirements, which may provide some additional guidance.
Transactional control within business process steps
Transactional control is one of the mainstays of business processes. Why? Because it is the commonly agreed model of business processes that they are to be described as a sequence of steps which are supposed to be ACID: atomic, consistent, isolated and durable. A simple way to achieve consistency is to formally guarantee that the state changes of all participants occur either together or not at all. In other words to control the transactional behavior of all functionality which has to be used to accomplish this process step, in particular to be able to eventually revoke all state changing actions in case only some of them fail. Thus, with this approach, the so called commit problem arises, how to reach consensus about the final go or nogo decision for the step as a whole.
From theoretical considerations it can be shown that there is no solution to the distributed commit problem in the case of unlimited link failure. I.e. in case of unreliable communication, there is no way to guarantee consistent distributed transactional behavior. This is in contrast to possible process failure with reliable communication. With only process failure, blocking (two-phase commit) as well as non blocking (three-phase commit) algorithms are known, which guarantee consistent distributed transactional behavior. (For further reading, see e.g. Nancy A. Lynch, Distributed Algorithms, Morgan Kaufmann publishers, 1997)
Ok, no problem, we could say - there are simple means to make communication channels reliable. However, there is the factor time. Although, channels can be made reliable, it may be that the extra costs for reliability lead to transportation times exceeding internal processing times by far. Additionally, the reliability of a composed system, whose functionality depends necessarily on all components scales with the product of the reliabilities of the single components. For example, a system consisting of 10 components with an individual reliability of 99% is itself reliable to merely 90%. Thus, the scalability of distributed transactions in dependency of the number of involved systems becomes limited by the reliability costs, which are lower bounded by the weakest component and channel. Since the essence of the internet is unreliable transport and performance, any attempt of system orchestration over the internet, which is based on distributed transactions will probably scale pretty badly.
As a consequence, transactional control to achieve consistency makes sense only in thoroughly controlled environments, limiting the number of components and guaranteeing the functioning of the components and communication channels to a sufficiently high degree. Otherwise, we have to accept either bad scaling and/or high costs due to the frequent manual interventions necessary to correct the occuring inconsistencies.
Lacking transactional control between business process steps
On the other hand, business processes do interact with each other, obviously without mutual transactional control. If a buyer sends a seller a purchase order (possibly electronically signed), then it is definitively not possible for buyer to simply recall it and revoke all actions seller has already performed in case some of its other businesses went wrong. Quite the opposite, the sent purchase order may allow seller to insist non repudiably that buyer has to buy what he said he wanted to buy. Such a relation essentially rests on the mentioned ACID business process model. Because the step of buyer to declare his intention to buy has been finally and irrevocably completed with sending the purchase order, seller can relate to it as such. The only function with respect to a partner process, which needs to be transactionally controlled from a business step perspective would be the send() function of the communication channel, i.e. only sending the intended data is transactionally coupled to the rest of the business step functionality.
Additionally, the whole idea of state alignment between business processes, which surpasses the business interaction itself and additionally depends on some supervising third party transaction management does not seem to mirror peer to peer reality adequately.
Summary
To summarize, transactional control within process steps provides a simple mean to implement an ACID model of business processes. It does not make sense to talk about transactional control in the same sense to describe the relation between two business process steps, especially between business process steps of different partners.
As a consequence, transactionally uncontrollable state changing functionality seems to be of limited value for implementations of business processes according to an ACID model but will lead to more frequent manual interventions needed to correct eventually occuring inconsistencies.
