Subject: Re: [wsbpel] Issue - 130 - Proposal for vote
I originally asked that we hold off until the
abstract BPEL issue comes to a closer as this seemed of most relevance
for abstract BPEL (externally visible behavior use case in particular).
external interaction dependencies w.r.t. a collaborating party grouped
together, so that developer of the process on the collaborating side
can easily see the all interaction points with the processes that
it needs to mesh with. |
However, at this point I don't see much utility for this myself unless we specify how the users are expected to make use of this clearly. I agree with Paco that better to remove things that have no direct utility to the BPEL users.
-------- Original Message --------
I was of the same opinion as you (that partner elements may have a use in B2B modeling for example) but the truth is we don't know enough about their use to justify their inclusion in the final spec. Better err on the side of simplicity.
Paco From: Danny van der Rijn <firstname.lastname@example.org> To: wsbpeltc <email@example.com> Subject: Re: [wsbpel] Issue - 130 - Proposal for vote Date: 12/20/2004 05:34 PM While partners have no syntactic or semantic value in either abstract or executable BPEL (nor have they ever), they still retain semantic meaning at the modeling level. I don't actually recall a discussion about removing them, but I'm somewhat ambivalent about doing so, and wonder what others think on the issue. Danny Yaron Y. Goland wrote: > I had previously moved that we remove partners (not partnerLinks) from > the BPEL specification. I had been asked to table that proposal until > we had a better understanding of what role partners might play in > abstract processes. At the F2F the general consensus was that we now > have a good enough understanding of what abstract processes are likely > to look like in BPEL that we can safely conclude that partners will > not play a significant role. Therefore I was asked to re-raise my > original proposal. > > I therefore move that we remove partners from the BPEL specification. > > Thanks, > > Yaron