[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - R29 - Partner link's initializePartnerRole attribute
We should fix the examples in any case since as I explained they seem wrong.
But I have other concerns in the way this is currently specified.
* From what we see from our customers today is that greater than 80% of the
cases would require initializePartnerRole="yes", which isn't the default.
Most people would prefer defaults to be the most common case.
* The WS-Addressing type scenario should be considered a special case of the
environment initializing the partnerLink. We have called it out in the same
way as an assign initializing the partnerLink, which seems wrong.
* If the user has assigned to a partnerLink directly static analysis can
easily find this. So there is no extra reason to document the intent there.
If a user has said initializePartnerRole="no" or left it blank since "no" is
the default then deployer must use an address style binding if no assign is
found. What if the process is like our loanApprovalProcess where the
partnerLink's first use is an invoke activity and in addition has no
corresponding myRole, should we have a static analysis error saying "invalid
initializePartnerRole setting" when it is "no" or not specified?
Finally this is one of two place we discuss deployment environments in the
specification. And the other place says the following (from sec 1):
"The description of the deployment of a WS-BPEL process is out of scope for
this specification."
Should we amend this to say except for restrictions due to
initializingPartnerRole settings?
Regards,
Chris Keller
-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
Sent: Tuesday, November 07, 2006 5:33 AM
To: Alex Yiu
Cc: Alex Yiu; chris.keller@active-endpoints.com; 'Mark Ford'; 'wsbpeltc'
Subject: Re: [wsbpel] Issue - R29 - Partner link's initializePartnerRole
attribute
+1 (using initializePartnerRole as a statement of intent).
I am also in favor of adding initializePartnerRole to the WS-BPEL examples.
Kind Regards
DK
Dieter König Mail: dieterkoenig@de.ibm.com
IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49)
7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49)
7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office): (+49)
7032-201464 Germany
Alex Yiu
<alex.yiu@oracle.
com> To
chris.keller@active-endpoints.com
07.11.2006 07:05 cc
"'Mark Ford'"
<mark.ford@active-endpoints.com>,
"'wsbpeltc'"
<wsbpel@lists.oasis-open.org>, Alex
Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - R29 - Partner
link's initializePartnerRole
attribute
Hi Chris,
The application of "initializePartnerRole" to "loanApprovalProcess" example
in section "15.3.2. Process" is actually relatively simple.
I would say we just forgot reviewing the need to add
"initializePartnerRole" in those complete process example, when we passed
the issue of adding "initializePartnerRole" to the spec. (Hence, to me the
resolution of R29 is to apply "initializePartnerRole" appropriately to our
process sample, instead of removing the "initializePartnerRole" attribute).
In the "loanApprovalProcess" example in section 15.3.2,
partnerLinkType for "customer" partnerLink has only one role. That
is, myRole for "customer" partnerLink. Hence, initializePartnerRole
attribute is NOT applicable to this partnerLink.
For the case of partnerLinks "accessor" and "approvers", they are in
the same boat. There are no <assign> activities on partnerRoles of
partnerLink and there are no other activities performed on these two
partnerLinks (hence WS-Addressing like mechanism is not applicable
either). Therefore, we need to set "initializePartnerRole" = yes on
these partnerLinks.
For the process example in section 5.1, partnerLinks
"purchasing": initializePartnerRole N/A
"invoicing": initializePartnerRole="yes"
"shipping": initializePartnerRole="yes"
"scheduling": initializePartnerRole="yes"
For example in section 13.4.5, partnerLinks
"homeInfoVerifier": initializePartnerRole="##opaque" (as most of
partnerLink declaration is opaque)
For the process example in section 15.1.3, partnerLinks
"customer": This is an AP11-profile abstract process. The
initializePartnerRole should be set to "no" or leave it as default.
For the process example in section 15.2, partnerLinks (another template
abstract process)
"ordering": initializePartnerRole N/A
"orderingResponse": initializePartnerRole="no"
"shipper": initializePartnerRole="yes"
"shipperResponse": initializePartnerRole N/A
"shipperRequester": initializePartnerRole N/A
"invoiceProcessor": initializePartnerRole N/A
"invoiceResponse": initializePartnerRole="no"
"orderingConfirmation": initializePartnerRole="no"
[***Side note:
After reviewing the example in section 15.2, I think there are some changes
needed which are not related to Issue R29 in general:
(a) Syntax correction from:
<condition>"##opaque"</condition>
to:
<condition opaque="yes" />
(b) Rectified opaque from spec usage: (because of another bug fix in other
part of the spec)
<from opaque="yes" />
to
<opaqueFrom />
(c) Simplify partnerLink usage:
The number of partnerLink used in this example is a bit too many. It makes
the example harder to understand. I would suggest to combine some of them.
"ordering" + "orderingResponse" + "orderingConfirmation" =>
"ordering" (initializePartnerRole="no")
"shipper" + "shipperResponse" => "shipper"
(initializePartnerRole="yes")
"invoiceProcessor" + "invoiceResponse" => "invoiceProcessor"
(initializePartnerRole="no")
"shipperRequester" unchanged (initializePartnerRole="no")
***]
For the process example in section 15.4, partnerLinks:
"seller": initializePartnerRole="no" (explicit assign is used)
"buyer": initializePartnerRole="no" (explicit assign is used)
"auctionRegistrationService": initializePartnerRole="yes"
Thanks!
Regards,
Alex Yiu
Chris Keller wrote:
Alex,
I agree with Mark we should just eliminate the initializePartnerRole
attribute. If it is useful for expressing intent we should use it in
our examples, but we do not. The loanApprovalProcess example from
section 15.3 in my opinion is a place where it should be set to
“yes”. The process is created by receiving a request from a
partnerLink named “customer” and then immediately invokes on a
partnerLink “approver”. Leaving it unset is the same as “no” (per
6.2) and implies the “approver” partnerLink is set in one of the
following 2 ways (from section 6.2):
• Business logic expressed in the process definition
• Auto-assignment of EPR logic in an underlying EPR scheme, such as
the reply-to feature in WS-Addressing
The first bullet isn’t happening as the process doesn’t directly
assign the “approver” partnerLink a value. And the second doesn’t
make sense based on the use case (I have never seen a business
process where a “customer” sends credit info and tells the system
where to approve it). If the WS-BPEL processor (aka the elephant,
which isn’t allowed to set it per section 6.2) isn’t setting it then
what is?
Alex wrote: “Without this attribute, it will be much harder to
determine the intent of a partnerLink by static analysis of a process
definition.”
If we can’t agree how and where to use this flag to specify intent
appropriately in our own examples how will BPEL users?
Regards,
Chris Keller
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, November 06, 2006 3:14 PM
To: Mark Ford
Cc: 'wsbpeltc'; Alex Yiu
Subject: Re: [wsbpel] Issue - R29 - Partner link's
initializePartnerRole attribute
Hi Mark,
I would like to respond to a particular point:
Mark wrote:
Setting a value for the initializePartnerRole attribute requires an
understanding of the specific service-ref implementation for the
process as well as its deployment environment.
Your statement above just covers some advanced cases of
initializePartnerRole usage.
I want to stress that initializePartnerRole can be used in a fashion
that is totally independent of the underlying addressing mechanism.
In other words, initializePartnerRole can be used without involving
WS-Addressing like situation.
Example #1, if someone wants to design a loan approval process, one
of the partnerLink is used to obtain the credit rating of a loan
applicant. The process designer wants to express the intent that the
partnerRole of that credit-rating partnerLink needs to be
initialized.
The usage of this initializePartnerRole can be as simple as that. :-)
In this particular case, the process designer does NOT need to
consider any WS-Addressing-like mechanism or details of deployment
environment.
Example #2, using the same loan approval process as the example, the
partnerLink that is used in the start operation may be
bi-directional. It may have a partnerRole for callback to signal loan
approval result. In that case, the process designer will typically
leave out initializePartnerRole unspecified, which is by default
"no", if the process designer adds an explicit <assign> logic to
initialize that partnerRole OR the process designer expects some
sorts of a WS-Addressing reply-to mechanism is involved for that
particular partnerRole.
Without this attribute, it will be much harder to determine the
intent of a partnerLink by static analysis of a process definition.
Thanks!
Regards,
Alex Yiu
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]