[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 139.1 - Proposal For Vote
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]