OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]