Re: [wsbpel] Issue 11 - Call for Discussion

["David RR Webber" <david@drrw.info>]

Danny,

+1

However the problem appears to be that
we're falling between two stools at the moment.

We're trying to make 1) do bits of 2) as well.

What I'm trying to point out is that we cannot do
2) yet - and we need to make a clear way of
doing that available.  In simple terms - passing
a blob of XML to the external process via a
WSDL interface, and getting a possibly
different blob back, that can then be onward
directed by BPEL.

The means of creating the blob has to be
pretty simple - just grab these chunks and
pass them on - since we expect the 2)
process to sort out all the mucky-muck
involved for us - upto and including the
context driven handling BTW.

Thanks, DW.

----- Original Message ----- 
From: "Danny van der Rijn" <dannyv@tibco.com>
To: "Wsbpel@Lists. Oasis-Open. Org (E-mail)" <wsbpel@lists.oasis-open.org>
Sent: Wednesday, March 03, 2004 3:10 PM
Subject: Re: [wsbpel] Issue 11 - Call for Discussion


> 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
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>