I'm sensing here we need to divide and conquer the
problem.
1) For small scale inline manipulation -
<assign> can be
used within the constriants of W3C DOM
supported
manipulations. This fits with the BPEL/WSDL
model of
interprocess signalling of highly focused
information
couplets. Only a limited set of functions is
provided
and that ensures interoperability.
2) For large manipulations, particularly B2B
information
exchanges, then BPEL should look
to external
support, such as OASIS CAM, in
two roles -
a) content assembly and
reformatting
b) validation and error
handling
This BTW is tried and tested. The B2B
exchanges
rely on their mapper engines to do the heavy
lifting
on information exchanging, while allow some
simple
information inspection at the message layer to
determine routing, handle envelopes, and so
on.
DW.
----- Original Message -----
Sent: Wednesday, March 03, 2004 11:30
AM
Subject: Re: [wsbpel] Issue 11 - Call for
Discussion
Yaron Y. Goland wrote:
Ron
Ten-Hove wrote:
This is why <assign> is atomic. The
intermediate states are never exposed.
Even trivial XML
manipulation tends to involve some forms of computation during the
manipulation process. A classic example is a while loop that goes through a
document pulling out information in order to create a new document. During
the time the while loop is iterating it is likely that the new document will
be in a schema inconsistent state. Assign's atomicity is of no use here
since there is no way to shove a while loop into an assign.
Looping to construct a variable is a good example of where
the atomicity of <assign> is insufficient to hide the intermediate
stages you are concerned about. This could be addressed in several ways:
- Use serializable scopes.
- Introduce a concept of "compound assignment" which is also atomic. This
could contain the <while> loop of concern.
- Learn to live with the problem. This is nothing new; let the programmer
beware, as be already must in countless other languages.
More generally,
any XML manipulation which is not strictly linear and involves schema
inconsistent intermediate states cannot be dealt with in BPEL since assign
cannot contain decision or iteration logic.
Is there a
requirement that variables be schema-valid during all stages of variable
manipulation? Or should the requirement be the looser "variables should be
schema-valid when used (directly or indirectly) in a message sent by
<invoke> or <reply> activities? Or is there a more useful
requirement in the arena?
Therefore if
one wants to enable even simple XML manipulation in BPEL one inevitably ends
up having to create some kind of transacted schema free zone. I'm suggesting
we don't want to go there.
The assign mechanism, in all its
various forms that we have seen in this forum, is essentially a piece of
imperative code embedded in a declarative process model. This does introduce
some form of "impedance" mismatch. However, I think you are overstating
the problem by suggesting that this is too difficult to address. Imperative
logic that manipulates any kind of structure will always introduce transient
states that are illegal / nonsensical; this is a problem that has been with us
since t = 0. :-) This is also a problem that has been addressed in the
past, where t ≥ 0.
Is it your assertion that we should create a
standard that MUST be
supplemented by an unspecified companion
language, in order to create
executable processes?
Not at all. There are many ways to make BPEL work
on its own. But I am asserting that BPEL should focus on the areas that it
adds value and not re-invent functionality that is widely available in a
standardized form.
Leveraging existing standards is a Good
Thing, but being insufficiently prescriptive can harm portability. Leaving
this completely open to the whim of BPEL engine providers harms the
utility of the BPEL spec in this regard. (I believe the proposal Danny has put
forward leverages the existing W3C DOM work to a high
degree.)
-Ron