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] Issue 5 - The algorithm for deciding whether a partnerLinkis a service or a reference needs to be deterministic

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:
2E22E42D2E71B845B67F093A02B962DB0119813C@repbex01.amer.bea.com" type="cite">


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.





From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, October 04, 2007 12:16 PM
To: Danny van der Rijn
Cc: sca-bpel@lists.oasis-open.org; ALEX.YIU@oracle.com
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:

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


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.





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