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


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]