[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - R29 - Partner link's initializePartnerRole attribute
Hi, Dieter, Chris, Mark and others,
If we want to change the default setting of this "initializePartnerRole"
attribute, I would lean towards (after more "chewing" and thinking):
Chris wrote: "We can say there is no default and so the bpel designer
has not specified intent."
That means: I would prefer there is no default value for this optional
attribute. If people do not specify this attribute explicitly, it means
the designer does not state any intent.
It will make migration users from BPEL 1.1 to BPEL 2.0 a bit easier. We
would not force users to think of an "initializePartnerRole" attribute
value. And, we do not need to force ourselves to make a potential
pre-mature decision on what value should be the default for this
"initializePartnerRole" attribute.
I am not that warm to switch the default to "yes" either. Because,
"initializePartnerRole" does not apply to a partnerLink with myRole
only. Having a "yes" default value (specified in XSD) for
"initializePartnerRole" attribute is problematic. That means we will be
forced to use spec text to describe the "smart" default value of that
"initializePartnerRole" attribute. That will make this attribute
over-complicated.
At this time of spec cycle, changes should be simple instead of
complicated to avoid introducing new bugs.
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
>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]