[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]