RE: [wsbpel] Issue - 63 - Support of Array

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

Bernd,

I think we are talking about the same things - but we need to coalsce to make 
sure!

The key piece is your statement here.

Quoting "Eckenfels. Bernd" <B.Eckenfels@seeburger.de>:
> 
> And yes, personally I do not have a problem to invoke a splitting/merging
> service to kick off new sub-process, but I would like to run them under the
> same initial master process, and I would like to understand the overall
> business process by reading one single abstract BPEL script which actually
> defines the state transitions possible. And this clearly includes the state
> "partially shipped".
> 

I think this is what I want too - for the BPEL to provide the orchestration, 
and contain the devices and instructions to execute the BP.  But - that the
transaction manipulation is kept separate - and those itnerface points to 
transaction services are directed by the BP - and most important of all - that 
the BP provide the CONTEXT to those transaction handling service(s).

This frees up the BPEL to concentrate on what it does best.  People should 
still be able to exactly "see" the steps and the transaction state changes - 
just that the BPEL script will "hand-off" to a transaction processing engine 
to accomplish the data crunching piece.  This will actually make it CLEARER 
what is happening - since instead of having lowlevel code to rake thru in the 
BPEL - and questions as to what data crunching might occur - you will have a 
interaction - with call-outs, returns, and results to show all the 
permutations.

Also the OASIS BCM Choice Points toolset is particularly targetted at managing 
this so that you can exactly direct those manipulations - without having to 
change lowlevel code inside the BPEL script.  This makes BPEl much more re-
usable compared to if the transaction handling is hardwired inside its syntax.

Hope this makes it clearer.

Thanks, DW.