[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - R29 - Partner link's initializePartnerRole attribute
Re [a]: While switching the default to "yes" would be useful for
process-level partner links that are most likely "wired" to an endpoint at
deployment time, I am concerned about having a default of "yes" for
scope-level partner links. A working but probably less usable approach
would be a default of "yes" for process-level partner links and a default
of "no" for scope-level partner links.
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 23:58 cc
Dieter Koenig1/Germany/IBM@IBMDE,
"'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,
I thought you would know me or my communication style already. Silence on a
topic does not mean I am ignoring that topic. That usually means I am
"chewing" and thinking on that topic. I don't want to give a pre-mature
opinion. :-) I hope you would understand. ... ;-)
[a]
On the issues of:
Switching the default from "no" to "yes" ... or ...
Chris wrote: "We can say there is no default and so the bpel designer
has not specified intent."
I am still chewing on them and evaluating their implication.
[b]
On the other hand, about your multiple-choice suggestion:
Chris wrote:
initializePartnerRole=”assigned|addressing|deployment|ncname”.
I am not that warm to the idea. Because, the usage of that partnerLink can
be a combination of a number of them. (e.g. One can leverage the EPR from
assignement or deployment within the same process.) I don't want to make
the initializePartnerRole switch too complicated.
[c]
Chris wrote:
From section 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 resulting
from initializingPartnerRole settings?
I am open to that suggestion. How about:
A WS-BPEL process is a reusable definition that can be deployed in
different ways and in different scenarios, while maintaining a
uniform application-level behavior across all of them. A WS-BPEL
process definition may contain some indicators, such as
initializePartnerRole attribute, to signal certain application-level
usage intent of resources. Such indicators in turns facilitate the
deployment of process definitions. The details of the deployment
description of a WS-BPEL process is out of scope for this
specification.
Thanks!
Regards,
Alex Yiu
Chris Keller wrote:
Hi Alex,
Thanks for the response on intent and static analysis. I continue to
question this attribute, in particular the grouping of WS-Addressing
and assign as a single intent.
You didn’t respond to 2 points can you and/or others provide their
thinking on these 2 which I will summarize again here.
1) The default is the 20% use case rather than the 80%. We should at
change the sense of this attribute if we keep it. Here are 2 ideas.
a) Perhaps something other than yes or no. We can change it to be an
extensible ncname and have a few predefined
initializePartnerRole=”assigned|addressing|deployment|ncname”.
b) We can say there is no default and so the bpel designer has not
specified intent.
2) From section 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 resulting from
initializingPartnerRole settings?
Regards,
Chris Keller
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Tuesday, November 07, 2006 4:11 PM
To: chris.keller@active-endpoints.com
Cc: 'Dieter Koenig1'; 'Mark Ford'; 'wsbpeltc'; Alex Yiu
Subject: Re: [wsbpel] Issue - R29 - Partner link's
initializePartnerRole attribute
Hi Chris,
Thanks for the quick response and understanding. :-)
Static analysis of PartnerLink usage intent for simple case is easy.
To describe a universal and comprehensive logic of static analysis of
PartnerLink is quite tough.
For example:
Chris wrote:
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.
The <assign> can be within a condition. The BPEL process designer may
still want to mark of that partnerLink initializePartnerRole as yes
as the default EPR of the partner. But when certain condition is
true, the BPEL logic will assign another EPR (maybe from another
message) to the same partnerLink.
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.
That seems to be a reasonable assumption. (which I don't think we
need to call it out explicity in the spec)
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?
I agree that static analysis can signal such a warning / error. In
typical / simple cases, one can easily determine whether a
partnerLink (with or without myRole) is first used in <invoke>. In
some cases, it may not be that easy. The next question is: whether we
want to state this kind of static analysis in the spec (which depends
on whether we find an elegant and effective way to describe it
without convolution.)(I tend to think it is possible so far)
Thanks!
Regards,
Alex Yiu
Chris Keller wrote:
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]