[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 139.1 - Proposal For Vote
The reason I said they are related is simple. If you don't filter messages based on partner role, then the implicit EPR setting is unpredictable and unreliable because you may receive messages through the same partnerLink from multiple partners, and you have no idea which <from> is currently effective in the partner role. It is also unclear if this <from> is meant to be effective for a single reply, multiple replies to a single request, or is more of a long running conversation. The contract is unclear and therefore the lifetime of the <from> EPR relationship seems very ad hoc. In short there is semantic complexity here that you have not addressed. I therefore oppose adding this feature. Satish -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Monday, June 06, 2005 3:13 PM To: Satish Thatte Cc: wsbpeltc Subject: Re: [wsbpel] Issue - 139.1 - Proposal For Vote Actually 139.1 and 96.1 are totally unrelated. 139.1, in the text you refer to below, attempts to address the situation where the user expects a partnerLink to be bound to a transport that has functionality like WS-Addressing where incoming messages have <from> elements that provide the EPR of the sender. The programmer further expects that the engine will take the EPR out of the <From> and assign it to the partnerRole in the partnerLink. By putting on the flag the programmer is telling the deployment environment "I depend on the use of a transport that supplies the EPR of the sender of the message and further I depend on the engine being able to assign that EPR to the partnerRole, therefore this partnerLink MUST NOT be bound to a transport that does not have the previously described capability." Yaron Satish Thatte wrote: > I am very unclear on the need for "Put in another switch which specifies if the > binding used with the partnerLink must be able to set the partnerRole value when > receiving a message". This seems to be close cousin to the partner role > filtering proposal we saw earlier. We should discuss. > > ------------------------------------------------------------------------ -------- > *From:* Yaron Y. Goland [mailto:ygoland@bea.com] > *Sent:* Tue 5/24/2005 5:10 PM > *To:* wsbpeltc > *Subject:* [wsbpel] Issue - 139.1 - Proposal For Vote > > Issue 139.1: How/when BPEL can change partner role EPR > > Proposal: Put in a switch to specify if the programmer is depending on > the BPEL processor to initialize a partnerRole value on a partnerLink. > Put in another switch which specifies if the binding used with the > partnerLink must be able to set the partnerRole value when receiving a > message. > > Rationale: As discussed in the group we need to enable programmers to > make their intentions clear so that they can be properly enforced. After > discussing the matter it appears that there are two areas that need > clarification in the spec. > The first is - who is responsible for initializing a partnerRole? Today > the programmer has no explicit way of stating that they expect the BPEL > processor to handle initialization. Making it possible to state that > clearly in the code will make deploying BPELs much easier. > The second is - when is the BPEL processor allowed to overwrite a > partnerRole value? Some bindings (WS-Addressing comes to mind) have the > ability to carry updated EPR data. If a programmer doesn't know they > have been bound to such a binding they would be very surprised to find > out that their partnerRole value has been overwritten. We need a way to > let the programmer explicitly define their expectations. > > Section 7.2 > > Change the BNF to read: > > <partnerLinks> > <partnerLink name="ncname" partnerLinkType="qname" > myRole="ncname"? partnerRole="ncname"? > initializePartnerRole="yes|no"? partnerRoleSet="yes|no|may"?>+ > </partnerLink> > </partnerLinks> > > From: In the degenerate case where a partnerLinkType has only one role, > one of these attributes is omitted as appropriate. > > To: In the case where a WSDL binding is only specified for one of the > two roles then one of these attributes is omitted as appropriate. > > Insert the following as a new paragraph after the paragraph that ends > with "See Assignment for the mechanisms used for dynamic assignment of > endpoint references to partner services." > > The initializePartnerRole attribute specifies if the BPEL processor is > required to initialize a partnerLink's partnerRole value. The attribute > has no affect on the partnerRole's value after its initialization. The > initializePartnerRole attribute MUST NOT be used on a partnerLink that > does not have a partner role; this restriction MUST be statically enforced. > > If the initializePartnerRole attribute is set to "yes" then the BPEL > processor MUST initialize the EPR for the specified > partnerLink/partnerRole combination before that partnerRole is first > referenced by the BPEL process. If initializePartnerRole is set to "yes" > and for whatever reason the BPEL processor is unable to initialize the > partnerRole then the bpws:cannotInitializePartnerRole fault MUST be thrown. > > If the initializePartnerRole attribute is set to "no" then the BPEL > processor MUST NOT initialize the EPR for the specified > partnerLink/partnerRole combination before that partnerRole is first > referenced by the BPEL process. > > If the initializePartnerRole attribute is set to "may" then the BPEL > processor MAY initialize the EPR for the specified > partnerLink/partnerRole combination before that partnerRole is first > referenced by the BPEL process. > > If the initializePartnerRole attribute is omitted then its value MUST be > treated as "may". > > The partnerRoleSet attribute specifies if the binding used with the > partnerLink is required to be able to provide the EPR for the sender and > to then assign that EPR to the partnerLink's partnerRole. The > partnerRoleSet attribute MUST NOT be used on a partnerLink that does not > have a partner role; this restriction MUST be statically enforced. > > If the partnerRoleSet attribute is set to "yes" then the binding used > for the partnerRole MUST be able to retrieve the EPR of the sender of a > message received on that partnerLink and MUST use that EPR to set the > value of partnerRole on the partnerLink every time a message is received. > > If the partnerRoleSet attribute is set to "no" then the binding used to > receive messages on the specified partnerLink MUST NOT be used to set > the EPR on the partnerLink's partnerRole when a message is received even > if such EPR information is available. > > If the partnerRoleSet attribute is omitted then its value MUST be > treated as "no". > > Even if partnerRoleSet="yes" it is still possible for a programmer to > manually set the partnerRole value. However, if partnerRoleSet="yes", > then the next time a message is received the partnerRole EPR will be > overwritten by whatever EPR is specified in the received message. > > Appendix A: > > Add: > > bpws:cannotInitializePartnerRole - Thrown when > initializePartnerRole="yes" but for some reason the BPEL processor > doesn't have an initialization value. > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]