Re: [wsbpel] Issue - 52 - Issue Summary

["Frank Leymann" <LEY1@de.ibm.com>]

Back from vacation, Dieter and I are trying to understand this issue.  We
both don't understand the original scenario ("powerplant") that triggered
that discussion and resulted in this issue. Can you, Yaron, provide at
least snippets of the associated BPEL documents?  Or describe in more
general terms what the scenario is?

Furthermore, we do NOT agree with Yaron's statement, that it is "general
consensus" that shared variables are "too hard to get right".

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinguished Engineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858
--------------------





Please respond to <ygoland@bea.com>

To:    <wsbpel@lists.oasis-open.org>
cc:    "'Satish Thatte'" <satisht@microsoft.com>, "Assaf Arkin \(E-mail\)"
       <arkin@intalio.com>, "'David RR Webber - XML ebusiness'"
       <Gnosis_@compuserve.com>
Subject:    [wsbpel] Issue - 52 - Issue Summary


Executive Summary:
             Issue: How to enable intra-process communication (e.g. how to
allow flows
in the same process instance to share information).

             Possible Solutions:

                         Shared Variables: General consensus that this is
too hard to get right.

                         BPEL Messaging: Allow a BPEL process instance to
send itself messages.
There are concerns around deadlocks.

                         BPM Choice Points: An alternate programming
language being developed in a
separate OASIS TC, I have reviewed some material on it but do not feel that
I understand it well enough to properly summarize it.

                         Other: Assaf and Satish have proposed not using
BPEL messaging and agree
to not liking shared variables but have not yet made an alternate proposal.

Long Winded Version:

Diane asked me to lead a conversation on issue 52 during Wednesday's phone
call. I'm not sure if that is still on since she asked me to get out a
summary by Monday and I was on vacation but just in case here is my summary
of the threads on this subject to date.

There seems to be consensus that currently there is no standardized
mechanism other than shared variables to enable flows in the same process
instance to communicate with each other (intra-process communication).
There
furthermore seems to be a consensus that if one wants to do intra-process
communication then shared variables are a sub-optimal mechanism because
they
are very easy to get wrong.

It was proposed that one could re-use the existing messaging facilities
within BPEL to enable intra-process messaging as a solution to the problem
of intra-process communication. In other words, we would enable flows in
the
same process instance to send each other messages using the normal BPEL
messaging facilities.

This led to a discussion of how to enable this scenario. Two solutions were
offered.

One solution was to use WSDL bindings to specify that a WSDL service was
bound to the process instance. That way if the process should send that
service a message then by definition the message must loop back to the same
process instance. However there appeared to be consensus that there was no
standard way to specify this at the WSDL level and no desire to introduce
WSDL hacking.

The alternate proposal was to introduce an attribute that could be used on
role definitions to specify that both ends of the role point to the same
process instance. This would allow the process to send messages to itself.
For more details on this proposal and comparison of it to other proposals
see http://lists.oasis-open.org/archives/wsbpel/200308/msg00158.html.

Both Satish and Assaf didn't like the idea of using BPEL messaging for
intra-process communication. Assaf was uncomfortable with the idea of
defining WSDL interfaces strictly for intra-process use. Satish's objection
was that using BPEL messaging for intra-process communication could lead to
deadlocks within a single process instance. While deadlocks were always
possible between BPEL processes Satish's contention is that the
introduction
of this feature would, for the first time, enable a deadlock within a
single
BPEL process instance. I need to follow up with Satish on this point since
it is my understanding that it was always possible to cause deadlock within
a BPEL process instance through shared variable access.

Both Satish and Assaf want to use an alternate mechanism to the ones
proposed but so far have made no concrete proposals for how to proceed.

David Webber has suggested using BCM choice points. I reviewed the
presentation he sent out and I must admit that I'm am still very unclear as
to exactly what choice points do. It looked like some kind of rules based
business language. I am also unclear as to how mature the choice point
proposal is, what schedule it is on, how well its functionality meets
BPEL's
requirements, how interested BPEL and/or the choice point folks are on
collaborating, etc. Hopefully David Webber will be available for the phone
call and will be able to clarify issues around choice points.


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.