OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel] RE: Issue - 52 - Should BPEL provide a standard way to specify when flows are sending messages to each other?

Yes we could envisage static analysis.  But do we have the means to specify a prescriptive method to ensure deadlock free processes?
Re deployment, I actually agree with Yaron, Tony et al that if we do agree to support intra-process-instance messaging then this would be best done with feature enhancement and not through deployment tricks.  I am concerned about encouraging people to go down that road and run into serious difficulties with things like deadlock.  I would much rather find something simpler and more constrained, e.g., data flow through links (not thought through that yet, so please don't take it as an actual proposal).


From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Wed 8/27/2003 10:04 AM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] RE: Issue - 52 - Should BPEL provide a standard way to specify when flows are sending messages to each other?

Would not explicit support for intra-process messaging allow for static
analysis of the process, allowing detection of potential deadlock
situations? In addition, would it not be of assistance to deployment tools?

Alternatively, we could explicitly ban intra-process messaging, but I
think this would be a Bad Thing -- it is a useful pattern, although
admitedly potentially dangerous.


Satish Thatte wrote:

>Not quite.  Deadlock with a "partner" entity has always been possible.
>If you choose to deploy a process such that the partner entity is the
>same process instance then by implication you have a deadlock with
>yourself.  However, one can make the statement that assuming no deadlock
>with partner entities, a BPEL process instance will never deadlock
>That said, the point you are making about the desirability of providing
>means other than state sharing for data flow between concurrent
>activities is a valid one.  I am simply saying that
>intra-process-instance messaging is too much of a sledgehammer (whether
>through binding/deployment or explicit feature enhancement) to solve
>this, and one symptom of that is the possibility of deadlock.  However,
>adding a feature, to me, amounts to "guidance" that this is how we
>expect people to do things.  Deployment tricks are outside our scope to
>control.  I would therefore like to see us think harder about not
>forcing people into this cul de sac.
[snippage... this was getting way too long]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]