Re: [sca-bpel] NEW ISSUE: Title: The algorithm for deciding whethera partnerLink is a service or a reference needs to be deterministic

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Per the issues process that we agreed on, during the last f2f:
A new issue will not be discussed till it is assigned a number. Once it 
is assigned a number that number will be included in the subject so that 
we can search for discussion on a particular issue. I would prefer that 
when the issues editor assigns a number he would reply to the 'NEW 
ISSUE' email with the issue number and a modified subject containing the 
issue number.

Given that we haven't figured out issue mgmt (JIRA) yet, this is not 
possible right now. Which is a little frustrating.

Martin: do you know if we have any resolution from the OASIS admin regd. 
JIRA?

Thanks.

-Anish
--

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