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
|