[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: ebBPSS: Choreographing transitions between business transactions inmultiparty collaboration
I'm working on a an example for ebBPSS and have some difficulty understanding the specification on the issue of choreographing transitions between business transactions in a multiparty collaboration. The ebBPSS DTD allows <Transition> within <BinaryCollaboration> and within <BusinessPartnerRole>. I assume the former are intended to encode transitions within business states in the scope of the specific <BinaryCollaboration> and the latter for global transitions. The dropshop sample uses them for this purpose. Is this correct? If so, what is the semantics of attaching <Transition> elements as daughter nodes of particular <BusinessPartnerRole>s rather than others? Does this mean that the <BusinessPartnerRole> must be involved in the source or target business state or is this irrelevant? In my application, I would like to <Fork> at the multiparty level, to perform a number of <BinaryCollaboration>s, involving different parties, in parallel, then <Join> back. Is this possible with ebBPSS? <Fork> and <Join> are only allowed within <BinaryCollaboration>s. With the current DTD, I could put the <Fork> as last state in the <BinaryCollaboration> before the parallel branches, and a <Join> as first state in the first <BinaryCollaboration> after the parallel branches, and a <Transition> at the multiparty level. Is this the way to do this? Can someone elaborate on the decision not to allow <Transition>, <Fork> and <Join> as allowed content for <MultiPartyCollaboration> ? Regards, Pim van der Eijk
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC