Re: Web Services and transactions

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