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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

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

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

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. 



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

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