Re: [wsbpel] Issue 11 - Call for Discussion

[Danny van der Rijn <dannyv@tibco.com>]

glad to see we've won you over, david ;-)

it was never my intention to preclude 2.  and those that have complex things
to do and choose 1 hang themselves.  it's the people who have simple things
to do, and have to choose 2 (currently) that all the current fuss is about.

it seems, though, that the battle has always been about what's "simple" and
what's "complex."  i prefer not to make that choice on behalf of future
users of BPEL.  rather, i would choose to provide the ability to go a bit
further than "simple" in BPEL, and guide users.

danny

----- Original Message ----- 
From: "David RR Webber" <david@drrw.info>
To: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>; <ygoland@bea.com>
Cc: "Wsbpel@Lists. Oasis-Open. Org (E-mail)" <wsbpel@lists.oasis-open.org>
Sent: Wednesday, March 03, 2004 11:46 AM
Subject: Re: [wsbpel] Issue 11 - Call for Discussion


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 ----- 
  From: Ron Ten-Hove
  To: ygoland@bea.com
  Cc: Wsbpel@Lists. Oasis-Open. Org (E-mail)
  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:

    a.. Use serializable scopes.

    b.. Introduce a concept of "compound assignment" which is also atomic.
This could contain the <while> loop of concern.
    c.. 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