[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 9 - proposal draft for discussion
Hi Paco,
As you mention, there is a fuzzy boundary between checks that are purely syntactic and checks that require "static analysis". On the other end, it is also difficult to set crisp boundaries between the static checks that are required and those checks that will not be mandatory because they are not at the same level of complexity as the others. For example, should we leave the following constraint aside?
"A link MUST NOT cross the boundary of a while or forEach activity, an event handler or a compensation handler."
Also, I understand that the following statement was included in the list because static analysis is explicitly requested in the body of the spec:
"It is illegal for a link to have an activity as a target if the source activity of the link is an ancestor of the target activity of the link."
But this is just a special case of a more general rule that could also be checked statically:
"A link MUST NOT create a control cycle, that is, the source activity must not have the target activity as a logically preceding activity"
Basically it means that the relational union of the "control link" relation and the "structured activity-subactivity" relation must be an acyclic relation. And even though this is not hard to check, it may be left out of the "required static analysis" list since it is not a "simple check". But again, the boundary here is a bit fuzzy.
marlon
-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Tuesday, March 14, 2006 7:49 AM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 9 - proposal draft for discussion
Vinki and I took turns to go over the spec and collect places where static
analysis (SA) is required or might be granted. A draft of a SA appendix is
attached. It is of course only a first draft we can use for a discussion of
issue 9 on Monday.
About how the list was compiled: Vinki went included statements where
"static analysis" is explicitly requested. After that I went over places
where MUST/must occurs. This forced me to make judgements about which of
those MUSTs would require SA; in particular, I tried not to include purely
syntactic statements (i.e. about the "form" of individual elements), even
if some of those cannot be represented in XML Schema. The boundary between
what is pure syntax and what is not is relatively fuzzy so I believe we'll
be discussing that point.
Paco
(See attached file: Appendix - Static Analysis.doc)
Alex Yiu
<alex.yiu@oracle. To: Danny van der Rijn <dannyv@tibco.com>
com> cc: wsbpeltc <wsbpel@lists.oasis-open.org>, Alex Yiu <alex.yiu@oracle.com>
Subject: Re: [wsbpel] Issue 9 - proposal draft for discussion
03/13/2006 03:10
PM
Hi Danny,
I am OK with your suggested rephrasing of the last sentence of the second
paragraph.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I need to give this some thought, but right off the bat, I would
remove any notion of a configurable switch to stay consistent with
not mentioning the elephant. Maybe even just rephrase to:
Such an implementation SHOULD be configurable to disable these
non-specified static analysis checks.
Alex Yiu wrote:
Hi all,
As mentioned in the conf call last week, the way I interpret
Yaron's proposal more than a year ago was: ...
http://lists.oasis-open.org/archives/wsbpel/200409/msg00167.html
To: BPEL4WS takes it as a general principle that
compliant
implementations MAY choose to perform static analysis to
detect and
reject process definitions that may have undefined
semantics. Such
analysis SHOULD be performed optimistically, that is,
assuming the
process has no syntactic errors then if there exists at
least one
execution path from each start activity in the process
that can complete
successfully then the process MUST be accepted for
execution.
... basically to suggest (RFC SHOULD) WS-BPEL implementation
become a scripting engine like interpreter. E.g. say there is
an if-then-else block and the else-block has a syntactic
correct process definition (i.e. passing XSD validation), a
WS-BPEL process should still accept it, no matter how serious
semantic error the else-block code contains (e.g. failure to
resolve variables or partnerLinks).
I am not sure this is a preferred direction that the spec
should indicate to implementators, while I understand Yaron's
intention to ensure certain forms of portability.
Here is my attempt (as Diane requested) to rephrase that
paragraph to encourage a higher level of portability without
resulting into encouraging interpreter implementation.
From:
WS-BPEL takes it as a general principle that conformant
implementations MAY choose to perform static analysis to
detect and reject process definitions that may have
undefined semantics. Such analysis is necessarily
pessimistic and therefore might in some cases prevent the
use of processes that would not, in fact, create
situations with undefined semantics, either in specific
uses or in any use.
To:
WS-BPEL takes it as a general principle that conformant
implementations MUST perform basic static analysis listed
in Appendix [TBD - xref to Issue 84] to detect and reject
process definitions that has undefined semantics. Please
note that such analysis might in some cases prevent the
use of processes that would not, in fact, create
situations with undefined semantics, either in specific
uses or in any use. For example, a WS-BPEL implementation
will reject a process with <invoke> activity referring to
an undefined variable, where the <invoke> activity may
not be actually reached during execution of the process.
A WS-BPEL implementation MAY perform extra static
analysis checking beyond the basic static analysis
required by this specification to signal warnings or even
reject process definitions. Such an implementation SHOULD
provide a configurable switch to disable these non-basic
static analysis.
Note:
I avoided the term "pessimistic" vs "optimistic". Without
a clear definition what "pessimistic" and "optimistic"
mean precisely in the BPEL context, using those terms
would just create unnecessary confusion and contention.
The spec should just point out the cases of static
checking those clear violation of spec semantics. (aka
black cases). Definition of grey cases should rest on
vendors' shoulders. Grey area cases would diminish as
the spec and technology mature.
I hope the above draft proposal sounds right to most people on
the TC.
Thanks!
Regards,
Alex Yiu
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]