I'm sensing here we need to divide and conquer the
1) For small scale inline manipulation -
<assign> can be
used within the constriants of W3C DOM
manipulations. This fits with the BPEL/WSDL
interprocess signalling of highly focused
couplets. Only a limited set of functions is
and that ensures interoperability.
2) For large manipulations, particularly B2B
exchanges, then BPEL should look
support, such as OASIS CAM, in
two roles -
a) content assembly and
b) validation and error
This BTW is tried and tested. The B2B
rely on their mapper engines to do the heavy
on information exchanging, while allow some
information inspection at the message layer to
determine routing, handle envelopes, and so
----- Original Message -----
Sent: Wednesday, March 03, 2004 11:30
Subject: Re: [wsbpel] Issue 11 - Call for
Yaron Y. Goland wrote:
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:
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.
- 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.
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?
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.
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.
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.
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
Is it your assertion that we should create a
standard that MUST be
supplemented by an unspecified companion
language, in order to create
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