[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]