RE: [sca-bpel] Issue 5 - The algorithm for deciding whether a partnerLink is a service or a reference needs to be deterministic

Couple of comments inline below ...

-- Sanjay

  

  
  From: Danny van der Rijn 
  [mailto:] 
Sent: Thursday, Nov 01, 2007 8:46 
  AM
To: Michael Rowley
Cc: Alex Yiu; 
  
Subject: Re: [sca-bpel] Issue 5 - The 
  algorithm for deciding whether a partnerLink is a service or a reference needs 
  to be deterministic

  

Proposal:  Change the wording as follows:

" 
  
Defininition:  An SCA 
  A simple static analysis 
  is any analysis of the control flow, which does not 
  involve determining the values of any expressions, 
  will be used to determine which role can send the first message.  

  
<Sanjay> I think in addition to 
  describing what SCA static analysis does not involve, we should perhaps add a 
  clause/sentence to describe what it involves, or what its purpose is, 
  etc.</Sanjay>

  
<!--[if 
  !vml]-->
<!--[endif]-->  

  

  
Services: If a an SCA static 
  analysis of the process determines that it is possible that the first message 
  for a partner link will be received in a <receive> activity, the 
  <onMessage> element of a <pick> activity or the <onEvent> 
  element of an event handler then the partner link MUST be 
  wired to has a 
  corresponding SCA service in the component type. If the partner link 
  declaration has initializePartnerRole="yes", 
  then the service MUST 
  must be wired using a binding that knows the 
  identity of the partner as soon as the partner link becomes active (e.g. the 
  binding cannot depend on using a “reply-to” field as the mechanism to 
  initialize partner role.). " 

  
<Sanjay> I think we are using 
  the term 'wire' for different purposes in the above text. As I 
  understand, the SCA specifications in general use the term 'wire' 
  to relate a service with a reference. In the above text, we are 
  using the term wire for relating a SCA service with a BPEL parternLink, 
  and also for relating SCA service with a binding element. I propose 
  that we use the following alternative phrases:

  
s/the partnerLink MUST be wired to corresponding SCA 
  service/the partnerLink MUST be associated with the corresponding SCA 
  service

  
s/the service MUST be wired using a binding/the service 
  MUST be configured using a binding

  
< /Sanjay> 

  

Danny van der Rijn wrote: 
  You've hit upon 
    my major concern, and pointed out that it may be moot.  I might be 
    comfortable with a rewording that defines the static analysis in the same 
    area as the algorithm.  All of the requirements need to be reworded, 
    anyway, to use RFC 2119 (as amended).  I need to think about it a bit 
    further, though, if I may.

Michael Rowley wrote: 
    
      
      

      

      

      
I would propose 
      that we close this issue with no action.  I believe the concern is 
      with this section:

      

      
"If a static analysis of 
      the process determines that it is possible that the first message for a 
      partner link will be received in a <receive> 
      activity...”

      

      
If you only look 
      at this sentence, you could imagine runtimes with different level of 
      sophistication for their static analysis coming to different conclusions 
      for this question.

      

      
However, later in 
      the specification (line 75) says: “A simple static analysis 
      of the control flow, which does not involve determining the values of any 
      expressions, will be used to determine which role can send the first 
      message.” 
       

      

      
I believe that 
      with this caveat, everyone’s static analysis should come to the same 
      conclusion.

      

      
Michael

      

      

      

      

      
      

      
From: Alex Yiu 
      [mailto:] 
Sent: Thursday, October 04, 2007 
      12:16 PM
To: Danny van 
      der Rijn
Cc: ; 
Subject: [sca-bpel] Issue 5 - Title: 
      The algorithm for deciding whether a partnerLink is a service or a 
      reference needs to be deterministic

      

      
Alex Yiu wrote: 
      

      

Issue entered:
http://www.osoa.org/jira/browse/BPEL-5

Alex 
      Yiu wrote: 

      

Hi, Danny, 
      

The way that I read that section is: the logic there is quite 
      deterministic already: 

      
If a partnerLink can be 
      determined as a service, 
then that is a service ... 
If not, 
      
    if reference case#1, then ...
    
      if not #1 and if #2, then ... 
    if not 
      #1 or #2 and if #3, then ..
    if not #1, #2, 
      #3, then ... 

      

Let me give you an 
      example. If a partnerLink is used in both invoke and receive activities 
      without any logical ordering enforced in the process definition, it 
      will go into the reference case. Because, the static analysis CANNOT 
      determine the partnerLink is a service. 

My thought is: if 
      different implementation come out a different componentType definition 
      after static analysis of the same process, it sounds to me that it is more 
      like a bug in an implementation, not the case of the spec being unclear. 
      (unless you can give me a concrete example of our existing rules are not 
      sufficient)

And, I think if users do not want to rely on static 
      analysis of a BPEL process to calculate the componentType, it may be a 
      better idea to ask users to supply an explicit componentType artifact. 
      (That is an issue raised by 
      Anish.)

Thanks!

Regards,
Alex 
      Yiu

Danny van der Rijn wrote: 

      
TARGET: SCA C+I WS-BPEL spec, General 
      

DESCRIPTION: Section 2.1 currently states "If a static analysis of 
      the process determines that it is possible that the first message for a 
      partner link will be received in a <receive> activity, the 
      <onMessage> element of a <pick> activity or the 
      <onEvent> element of an event handler then the partner link has a 
      corresponding SCA service in the component type." 
I have concerns that 
      this will leave cases where one vendor can make such determination, where 
      another vendor, with a less sophisticated static analysis can not.  
      This will leave the algorithm implementation-dependent.  The goal of 
      the algorithm is to produce a component type from a BPEL file in a 
      deterministic way, with no external dependencies. 

PROPOSAL: 
      none