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

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

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.

-Ron

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
>internally.
>
>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]