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