OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - R29 - Partner link's initializePartnerRole attribute


It seems that the purpose of this attribute is to convey information to someone that is deploying the process. The deployer needs to know what type of bindings to establish for the process as well as what initial values should be configured for partner link partner roles. A simple “yes | no” value only tells the deployer whether the deployment environment needs to init the partner link but it does not convey anything about what bindings the deployer should create for the process.

 

Alex’s point [b] below illustrates that even the value of “yes” is not enough to convey intent since the process could use a combination of techniques to init the partner link’s partner role. The value may be “yes” but the endpoint provided by the deployer could be overwritten by an <assign> or some reply-to header.

 

If this attribute cannot clearly convey the intent of the process, then let’s remove it. If we want to have a hint for the deployer, then let’s make the attribute values explicit as to the intent. The possible values could be:

Assign = process will init the plink through an assign

Addressing = process will rely on its bindings to init the plink through some reply-to header

Deployment = process will rely on its deployment to init the plink

Unspecified = process doesn’t specify how a plink is initialized

 

The default value would be “Unspecified”. I’m open to other values (perhaps “Bindings” instead of “Addressing”)  but I think these are the four possibilities. If a process is going to use a combination of values then it should just put “Unspecified”. If this is getting too complicated, then I’m back to my original objection which was to remove it from the spec altogether.

 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Tuesday, November 07, 2006 5:59 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,

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]