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


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]