[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]