Re: Web Services and transactions

Even in the internal Siebel case, I noted with interest when I started
looking hard at how the EAI systems worked, they typically don't use 2PC
against entire applications from the outside. The big apps just weren't
written to support this and they have the same issues with resources being
locked up for unpredictable periods of time. Most customers I've run into
actually do this using EJB's inside of an EJB container when they actually
want true ACID.

Adam

----- Original Message -----
From: "Nick Nadgauda" <nick@invertica.com>
To: "Satish Thatte" <satisht@microsoft.com>; <mark.potts@talkingblocks.com>;
"Adam Bosworth" <adambos@crossgain.com>; <www-ws@w3.org>
Cc: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>; "Johannes Klein"
<joklein@microsoft.com>
Sent: Tuesday, June 26, 2001 7:41 AM
Subject: RE: Web Services and transactions


> Just a small observation regarding this topic.  My sense is that
> people's
> notion of transactions parallels their notion of what web services
> should be
> about.  I think everyone agrees web services are about interoperability
> and
> integration, but --
>
> 1. if you're coming at if from an inter-organziational (i.e.
> SOAP/HTTP over
> the internet) viewpoint, you're probably thinking of long running
> business
> processes (a la a B2B exchange) and in this scenario a lightweight
> compensation model makes much more sense.  2PC is just impossible to
> implement.
>
> 2. On the other hand, if you're coming at web services from an
> intranet
> viewpoint (a la I need to get my Siebel to talk to my J2EE app and they
> both
> expose logic as services), 2PC might make more sense.  In fact, it's
> probably essential since all the endpoints (mainframes, etc.) support
> 2PC.
>
> Both scenarios are trying to solve slightly different, albeit similar,
> problems.  The former is for long range, long term B2B type exchanges,
> while
> the latter is better suited for OLTP (like a trading system)
> applications.
> I think that any transactional protocol, be it WSEL or something else,
> needs
> to support both scenarios -- or perhaps we need two protocols that tie
> together somehow.
>
> --Nick
>
> Nick Nadgauda
> :Chief Technology Officer
> :Invertica, Inc.
> :nick@invertica.com
> :[P] 212.571.4103 x6593
> :[F] 212.571.3588
> :[C] 917.847.7938
>
>
> -----Original Message-----
> From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
> Satish Thatte
> Sent: Tuesday, June 26, 2001 12:18 AM
> To: mark.potts@talkingblocks.com; Adam Bosworth; www-ws@w3.org
> Cc: Henrik Frystyk Nielsen; Johannes Klein
> Subject: RE: Web Services and transactions
>
>
> I am not a transactions expert but I asked some local experts and the
> opinion was that although 2PC is a classic agreement protocol that could
> be used for long running transactions (LRTs), the realities of
> implementation tradeoffs based on current 2PC practice with databases
> make 2PC too constraining for LRTs, and a more relaxed peer-to-peer
> protocol might be desirable.
>
> -----Original Message-----
> From: Mark Potts [mailto:mark.potts@talkingblocks.com]
> Sent: Monday, June 25, 2001 3:13 PM
> To: Satish Thatte; 'Adam Bosworth'; www-ws@w3.org
> Cc: Henrik Frystyk Nielsen; Johannes Klein
> Subject: RE: Web Services and transactions
>
> Satish
>
> While I agree whole heartedly with the need for a protocol that supports
> bit
> loosely coupled and more tightly coupled services, I think its important
> that 2PC is treated in any discussion about transactions as a protocol.
> 2PC
> defines a protocol for coordinating participants that have enrolled into
> a
> transaction  - this could just as well be used as a protocol where the
> levels of isolation and durability are relaxed, in the case of
> compensating
> transactions.
>
> Regards
> Mark Potts
>
> -----Original Message-----
> From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
> Satish Thatte
> Sent: Monday, June 25, 2001 2:15 PM
> To: Adam Bosworth; www-ws@w3.org
> Cc: Henrik Frystyk Nielsen; Johannes Klein
> 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 Tuesday, 26 June 2001 12:09:26 UTC