propose that we close this issue
with no action. I believe the concern is with this section:
analysis of the process determines that it is possible that the first
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
analysis coming to different conclusions for this question.
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
to determine which role can send the first message.”
that with this caveat, everyone’s
static analysis should come to the same conclusion.
Alex Yiu wrote:
The way that I read that section is: the logic there is quite
partnerLink can be
determined as a service,
then that is a service ...
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
activities without any logical ordering enforced in the process
will go into the reference case. Because, the static analysis
determine the partnerLink is a service.
My thought is: if different implementation come out a different
definition after static analysis of the same process, it sounds to me
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
And, I think if users do not want to rely on static analysis of a BPEL
to calculate the componentType, it may be a better idea to ask users to
an explicit componentType artifact. (That is an issue raised by Anish.)
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
determines that it is possible that the first message for a partner
be received in a <receive> activity, the <onMessage>
element of a
<pick> activity or the <onEvent> element of an event
the partner link has a corresponding SCA service in the component
I have concerns that this will leave cases where one vendor can make
determination, where another vendor, with a less sophisticated static
can not. This will leave the algorithm implementation-dependent. The
goal of the algorithm is to produce a component type from a BPEL file
deterministic way, with no external dependencies.