- From: Mark Potts <mark.potts@talkingblocks.com>
- Date: Mon, 25 Jun 2001 14:12:31 -0700
- To: "'Dieter E. Jenz'" <dejenz@bpiresearch.com>, <www-ws@w3.org>
- Message-ID: <002b01c0fdbb$8cc200d0$8401a8c0@talkingblocks.com>
Dieter You are correct WSFL does not attempt to define the transactional semantics that may span multiple Web services ( activities ) unlike XLANG. However the accompanying WSEL ( endpoint definition language will cover QoS semantics and others, it is not yet defined if this will include transactional semantics also. The coordination and termination protocol can be specified elsewhere unless you want to piggy-back ) transaction context with service invocations ) but the demarcation has to be specified as part of the business process and the alternative flows that come along with error conditions surrounding the transactional of the process. I believe BPMI is looking into the adoption of BTP (Business Transaction Protocol) currently being worked on by an OASIS technical committee, there is also a W3C submission pertaining to XLANG. Regards, ------------------------------------------------- Mark Potts Chief Technology Officer Talking Blocks www.talkingblocks.com t. 415 255 7424 f. 415 255 7425 c. 415 606 9096 e. mailto:mark.potts@talkingblocks.com ------------------------------------------------- -----Original Message----- From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of Dieter E. Jenz Sent: Monday, June 25, 2001 3:06 AM To: www-ws@w3.org Subject: Web Services and transactions Hi, The "transactions" issue seems to be virtually ignored in almost all discussions that I am aware of. I'm viewing things from a business process management perspective. In that context, Web services are typically transactional. The question needs to be answered how transactions can work in an operational environment. I just want to illustrate my point using a simple scenario. Scenario: An activity (business process activity) is a Web Service, which is implemented by an Enterprise JavaBean (EJB). With container-managed persistence (CMP) the EJB container may independently initiate a commit. If the process engine is not implemented as an EJB, the Web Service EJB cannot "join" a transaction (i.e. the MANDATORY transaction attribute would have no effect), which makes all the changes caused by the EJB persistent. If the process engine crashes for some reason, it will reestablish a consistent state upon restart, actually resulting in the rollback of the activity. However, the activity implementation has already committed. Consequently, the process engine will schedule the activity for execution, resulting in the duplication of work. (It might be able to declare the activity just rolled back as "in doubt" and put the activity in "suspended" mode, however). The above scenario triggers a lot of questions, for example: - What happens if the process engine is implemented as an EJB? Then, the process engine can initiate a transaction, which the activity implementation can join. The inconsistency problem may not arise. - What happens if some activity implementations are EJBs, some are COM components, some are ...? The problem space can become extremely complex, since entire business processes can be exposed as Web services. In addition, Web services can be composed of other Web services. WSDL does not provide information on non-functional characteristics of the service (e.g. QoS information). Also, there is no way do declare Web services as transactional. The overall goal of Web services, to enable application integration over the Internet regardless of programming language or operating environment would be severely compromised if it was not possible to solve the transactions issue in a satisfactory way. Consider the above scenario: just putting in a process engine implemented as an EJB would make a real difference. Are there any practical solutions already available (that I am unaware of) or on the way? Regards Dieter
Received on Monday, 25 June 2001 17:06:09 UTC