wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Issue - 92.6 - proposal draft
- From: Alex Yiu <alex.yiu@oracle.com>
- To: wsbpeltc <wsbpel@lists.oasis-open.org>
- Date: Sun, 01 May 2005 19:08:54 -0700
Hi all,
Here is the proposal draft (as promised in the last conf call) for Issue
92.6.
If not controversial, I shall move it as the formal proposal soon.
Thanks!
Regards,
Alex Yiu
Title: Issue 92.6 Proposal Draft
Proposal Draft for Issue 92.6: need for an explicit syntax token to apply extension semantics from a NS URI
Last modified: May 01, 2005 - 6 pm PDT
Applied the following the text to the paragraph describing <extension> syntax:
--------------------------------------------
An extension declaration through <extension> syntax does not
automatically imply the application of any extension semantics defined
in the corresponding namespace to the process definition. It merely
declares the properties of the namespace of extension, such as, using
"mustUnderstand" attribute to denote whether a WS-BPEL processor can
safely ignore related extensions.
In order to apply an extension semantics to a WS-BPEL process
definition, one MUST use and include the corresponding syntax token
(either in an element form or an attribute form) explicitly in the
WS-BPEL source code and attach the token to a WS-BPEL extensible
construct.
The extension semantics can ONLY affect BPEL constructs within the
syntax sub-tree of the element where the explicit syntax token attached
to. In other words, extension syntax token MUST NOT "leak" its
semantics outside the subtree. As WS-BPEL source code itself is an XML
document, the definition of syntax sub-tree is trivial and can be
borrowed from self-or-descendant concept from XML world. Here are two
examples to illustrate the above concept further:
<process>
...
<scope>
<sequence>
<invoke operation="operation1"
foo:invokeProperty="someNature" ... />
<invoke operation="operation2" ... />
<invoke operation="operation3"
foo:invokeProperty="someNature2" ... />
</sequence>
</scope>
</process>
The "foo:invokeProperty" extension attribute are applied to
<invoke> activities for "operation1" and "operation3". The
<invoke> activity for "operation2" MUST NOT be affected.
<process>
...
<scope>
<foo:invokeProperty>someNature</foo:invokeProperty>
<sequence>
<invoke operation="operation1" ... />
<invoke operation="operation2" ... />
<invoke operation="operation3" ... />
</sequence>
</scope>
</process>
On the other hand, the "foo:invokeProperty" extension element can be
potentially applied to all <invoke> activities within the
<scope> activity where the extension element are attached to.
Apart from the above "MUST" restrictions, here are some extra "SHOULD"
guidelines for the design of extension syntax and semantics:
- Each extension syntax token SHOULD carry only semantics that fits
into a relatively modular and elegant boundary. An counter example of
bad design would be: one single extension syntax that carries dozens of
overloaded extension semantics ranging from transaction to security,
from message delivery QoS to XML data manipulation shortcuts. One
should break down the above variety of extension semantics into
different extension syntax token.
- Each extension syntax token SHOULD have a set of well-defined attachment points,
instead of making an extension syntax applicable to every BPEL
extensible constructs. Using the "invokeProperty" example above, the
set of attachment points are <invoke> and <scope>
constructs. Designers of extension are encouraged to keep the set of
attachment points small within reasons and to try to avoid using
grander level constructs (e.g. <process> and <scope>) as
attachment points unless the semantics of extension require.
--------------------------------------------
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]