RE: Web Services and transactions

I don't this you are missing anything and I agree compensation is the
logical answer, where transactions are going to be long lived or
participants are unwilling or cant expose their internal transaction
coordination facilities.

However between trading partner communities where the level of trust is a
given then support for ACID type transactions maybe be useful. Any protocol
should be suitable for an inter-organizational Web Service environment, but
also be capable of coordinating updates in conventional databases which
offer a distributed transaction interface such as XA ( BEA Weblogic for
instance offer the Server as an XA resource in ver 6.1)and be capable of
integration with conventional atomic transaction services, such as the OMG’s
Object Transaction Service. While supporting the well-known ACID (atomicity,
consistency, isolation, durability) properties; any protocol also must
support transactions to be created where isolation and durability are
consciously relaxed, and for this to be achievable and realistic, as you
said, a scheme such as compensating transactions is required.

Compensating participants enable the consistent reversal of the effects of
atoms through recorded before- or after-images, or compensation operations
to provide the “roll-forward, roll-back” capacity which enables their
subordination to the overall outcome of an atomic business transaction.

I do agree however that the realm of Web Services is distinctly in the
interoperability arena and as such dictating the technology adoption to
consumers and providers ( and or coordinators ) of Web services is not
appropriate or feasible. However transactions are essential for
inter-organisation commerce and as such standardised ways of defining and
propagating transactional context between services ( either AICD or
"relaxed/ compensating" ) such that they can enrol, and be coordinated as a
single atomic unit of work.

Regards
Mark Potts

-----Original Message-----
From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
Adam Bosworth
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:55:55 UTC