Hi Chris,
I have just refreshed my own memory on this topic. (related to Issue
139 and 139.1)
If my memory and understanding is right, these two issues are related
to whether a BPEL engine can initialize a partnerRole EPR based on a
message received via myRole EPR. (e.g. its WS-Addressing header) when
the partnerRole is not initialized by its deployment descriptor.
In the spec text / proposal text, there are important "before" clauses
attached to it:
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 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.
To my eyes, it is about controlling the timeline of partnerRole
initialization.
Yes, on retrospection, the proposal / spec text may not be clear enough
and its purpose may be too subtly described. Particularly the "MUST"
wording in the "yes" case is not used correctly.
If we want to clarify the text, I would suggest changes of the
following:
FROM:
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 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 omitted then its value MUST be
treated
as "no".
TO:
The
initializePartnerRole attribute specifies when the BPEL
processor is allowed 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 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 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 but the BPEL processor MAY still initialize the EPR at
the point when the partnerRole is first referenced. An example of
referencing a parternerRole is: using the partnerLink in an
<invoke> activity. If
the initializePartnerRole attribute is omitted then its value MUST be
treated
as "no".
If we want to go to one step first further, I would suggest to changes
its value from its boolean to the following:
"yes" => "before-first-reference"
"no" => "at-first-reference" (this is the default one).
(If people can stand this long attribute value description)
Chris and others, please let know whether my interpretation of this
past resolution make senses and whether you guys want to change the
spec text for clarification as suggested above.
Chris and everyone on TC, Happy Holidays!!!
Regards,
Alex Yiu
Chris Keller wrote:
I was reviewing the
current draft and the initializePartnerRole
attribute for a partnerLink has a default value of “no”. Currently
“no” means that an implementation MUST NOT initialize the EPR for
the partnerRole. This seems wrong to me. In my experience most
partnerRole EPRs
are initialized by the implementation. My feeling is that if possible
the defaults
should reflect the most common usage so the default should be “yes”.
Although I believe everywhere else in the specification the defaults
are “no”,
maybe we should change the sense of the attribute name. Does anyone
else have
any thoughts on this?
Regards,
Chris Keller
|