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


Ricky,

Thanks - I was strapped for time - so you correctly guessed 
I meant <invoke .../>

I think there's two things here - in terms of looping constructs - 
there's looping to do with flow control - and that makes sense,
wait inside this loop until "event X" occurs - classic process 
control stuff.

But trying to purpose these things against transaction content
and loops in XML content structures is a different story.  
By transaction I mean EDI, Purchase Order,
that stuff.  And so a Transaction engine processes same - products
like DataJunction, GoXML Transform, Mercator, MQSeries mapper,
OASIS CAM, and so on.  BPEL does not need to go there!  These things 
are all webservice enabled already - let them handle business
transactions, and pass back results required.

I'm not proposing however that you rely on 3GL such as Java.  That
defeats the purpose of BPEL.  The scripting language needs to
be able to control and react to CONTEXT triggers.  And that is 
fundamental - and why I keep on about the BCM Choice Point
approach - because it allows you to formulize those context
drivers - and provide a consistent way of doing that - without
having to resort to a 3GL.   We want XML scripting to enable
the complete process - as you see by combining say
BPEL and CAM together.  Then the engines are written in Java
or C that then execute the scripts.

Each script language can then focus on its strengths - I do not expect
to see BP flow commands available in CAM, and similarly transaction 
assembly commands in BPEL - but I do expect to see these two spec's
able to interact seamlessly to give you the best of both.

Thanks, DW.

Message text written by Ricky Ho
> 
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.

<



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