- From: Adam Bosworth <adambos@crossgain.com>
- Date: Mon, 25 Jun 2001 14:59:38 -0700
- To: "Satish Thatte" <satisht@microsoft.com>, <www-ws@w3.org>
- Cc: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>, "Johannes Klein" <joklein@microsoft.com>
Sure. ----- Original Message ----- From: "Satish Thatte" <satisht@microsoft.com> To: <www-ws@w3.org> Cc: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>; "Johannes Klein" <joklein@microsoft.com> Sent: Monday, June 25, 2001 2:24 PM Subject: RE: Web Services and transactions > Adam, > > I think you are agreeing with me so you probably aren't missing anything > ;-) > > But web services will not always be used in the loosely coupled mode, so > there will be need for 2PC-like behavior in specialized circumstances. > > In any case a distributed agreement protocol for web services is > probably needed for both tightly and loosely coupled business > transactions. > > Satish > > -----Original Message----- > From: Adam Bosworth [mailto:adambos@crossgain.com] > Sent: Monday, June 25, 2001 11:12 AM > To: Satish Thatte; www-ws@w3.org > Cc: Henrik Frystyk Nielsen > Subject: Re: Web Services and transactions > > It is worth noting that supporting ACID distributed transactions over > Web > Services is very problematic. The very idea of a Web Service is a way to > enable disparate applications built by different organizations, groups, > or > even companies to be able to use services from each other. But it is > highly > unlikely under such circumstances that the outside client of a service > can > typically be trusted to invoke anything that requires locks over any > substantive period of time. In general, the model I'm familiar with for > handling such cases (coming out of long-running transactions and EAI) > has > tended to support compensating transactions and exception handling > rather > than true DTC for these reasons. > > It is true that the process engine for any applications that wants to > participate in a "transactional" web service would have to be > implemented as > an EJB, but that is surely internal to the application delivering up > support > for the service (or invoking it) and not the business of the Web > Services > Protocols. > > Am I missing something here? > > Adam Bosworth > > ----- Original Message ----- > From: "Satish Thatte" <satisht@microsoft.com> > To: <www-ws@w3.org> > Cc: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> > Sent: Monday, June 25, 2001 10:43 AM > Subject: Re: Web Services and transactions > > > > Dieter, > > > > > > > > The XLANG proposal for business process description includes a notion > of > > long-running transactions which can support nested ACID transactions > and > > compensate for them when needed [1]. This is also available in the > BPML > > process description language developed by BPMI [2]. I agree with you > > that transactions must be addressed in the context of web services in > > general and business processes in particular. There are two separate > > ways to do it. One is to build up a transaction coordination > > architecture with the usual 2PC semantics. This can be problematic > > because of the need to lock resources across service (and hence > > business) boundaries. Less onerously, one can use explicit > compensation > > as in XLANG. Both have their place in different circumstances. > > > > > > > > Satish > > > > > > > > [1] http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm > > <http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm> > > > > [2] http://www.bpmi.org/index.esp <http://www.bpmi.org/index.esp> > > > > > > > > > > > > -----Original Message----- > > > > From: Dieter E. Jenz [mailto:dejenz@bpiresearch.com] > > > > Sent: Monday, June 25, 2001 03:06 > > > > 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:59:41 UTC