Re: [wsbpel] Issue 11 - Call for Discussion

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

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