[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Conflicting partnerlinks
Hello, The latest spec (an olders) describe in 14.5 > If during the execution of a business process instance, two or more receive > activities for the same partner link, portType, operation and correlation set(s) > are in fact simultaneously enabled, then the standard fault bpws:conflictingReceive > MUST be thrown by a compliant implementation. Other parts of the spec describe scoped partnerLinks and name overriding rules. So my question is, if a partnerLink has the same name is it the same partnerlink or only if it has the same declartion? If it is bound to the same declaration, how does one compare partnerlinks in different process templates or multiple versions? So for describing the intention behind the above definition, it would be good to define a "formal" identification string for a partner link (where we can do string compare). For this I introduce: <processnamespace>=the namespace of the process definitionm <processname>=the local name of the process <linkid>=unique string id for the declaration element (i.e. differs for scopes and process template instances!) <scopepath>=name of all parent scopes concatenated <linkname>=ncname of the partnerlink (could be multiple nested instances with the same name) So the question is, what would be a "virtual" fully qualified partnerLink name? <processnamespace><processname><linkid> Or <processnamespace><processname><scopepath><linkname> OR <processnamespace><linkname> Or <linkname> Or. ... Thinks we need to consider: Bla:Proc1 and Fasel:Proc2 both define a PartnerLink name="initial" - are outstanding receives allowed? Bla.Proc1 defines two PartnerLink name="initial" in <scope><partnerLink name="initial" /><scope><partnerLink name="initial" />...</sceope></scope> - are two conflicting receives allowed? Greetings Bernd
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]