OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


David,

There isn't a <perform call="..."/> in BPEL.  Are you proposing that we 
should have one or are you actually talking about making a web service 
invocation <invoke portType=".." operation="..."/> ?

You propose that the repetitive processing and iteration should be done 
inside another web service which is implemented using lower level 
programming language.  Using the same argument can we also eliminate 
<assign>, <while> ?

While I certainly agree on layers of abstraction and push implementation 
details (which the process designer doesn't care) behind a web service, I 
don't think pushing repetitive processing out from BPEL is the right 
thing.  Business processing itself usually involve repetitive processing 
and if we pushing that out from BPEL, the process designer cannot describe 
the complete business process in BPEL.  The complete process is 
materialized in two forms, some in BPEL and some in Java code.  I don't 
think this is the right model.

Not sure if I understand your term "transaction handling engine".  Most TP 
Monitor product and spec like WS-Transaction, BTP ... are talking about a 
"co-ordination" protocol (using some 2-phase handshaking mechanism) between 
multiple parties to draw consensus of a common outcome.  It is purely a 
co-ordination protocol and has nothing to do with application logic or any 
form of data manipulation.  I'm lost what role they play in solving the 
repetitive processing problem that I raise.

Best regards,
Ricky

At 10:23 AM 9/17/2003 -0400, David RR Webber - XML ebusiness wrote:
>Ricky,
>
>My point is that you should NOT be trying to do this stuff inside
>the BPEL engine.
>
>My code is even simpler than yours:
>
><perform call="bpel:URL-to-do-it" context="bcm:threadID"
>result="bpel:here"/>
>
>There's two separate functions - there's the BP engine - and there is
>the Transaction Handling engine IMHO.  If you need to understand
>the context of the transaction (why else is the BPEL engine looking
>in there, eh?) - then you need a separate mechanism for that - and
>that is the third piece - and Choice Points mechanism handles that
>comprehensively.
>
>I've said before - no sane manager is going to buy a BP engine
>that can modify transactions.  What kind of a security nightmare
>is that?
>
>DW.
>=======================================================
>Message text written by Ricky Ho
> >
>David,
>
>Do you disagree the two code sample in my previous response that the one
>without Array support is more complicated ?
>
>Or you disagree that the simplification justify the introduction of Array
>in BPEL ?
>
>Are we trying to make BPEL simpler for the vendor to implement their
>product ? or are we trying to give a richer construct for the user to model
>
>their business process ?  Is this debate similar to another issue about why
>
>we still need construct like <sequence>, <switch>, given that everything
>can be model using <flow> ?
>
>Rgds,
>Ricky
><
>
>
>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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]