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 

[2]  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