April 19, 2003

Process Scripting

Carlos Perez writes:

I was reading "Could Applications Servers be Overkill?" and came upon something that jogged my memory a bit. [Annrai] O'Toole the CEO of Cape Clear was arguing against XML based business process standards like BPELWS; he claimed that Javascript would do a much better job. Well that made me recall that BEA also was exploiting Javascript for its web orchestration product, in fact I did blog about BEA's native XML scripting.

I may have missed the news, but it's been announced next version of the ECMAScript standard (a.k.a. Javascript) will have native XML scripting. Even better, Brendan Eich of Mozilla has planned to include the additions into Mozilla's open source javascript interpreter. I hope to see their additions in the Rhino interpreter soon.

[ ::Manageability:: - Why Hacking Rhino may be Rewarding ]

If you actually read the article fully, Annrai wasn't really arguing _against_ BPEL as such, just pointing out that the important focus is on "documents", and that there are other ways to achieve _some_ of what BPEL is trying to do, but in a much more straightforward fashion - such as the example of using Javascript. As Carlos points out, several companies like BEA are also taking this viewpoint to a greater or lesser extent too.

Of course, many of the hardcore BPEL supporters jumped up and down animatedly about this mention of the words "process" and "javascript" in the same article, and completely ignored the real underlying points - that documents are central, and formal processes are just too hard for many developers. Thankfully, some people like Becky understand the points, though.

I don't really want to reopen this debate again - although I am sure it will! I have stated my own views already :

BPM (Business Process Modelling) technology and products have been around for a long time, but still not every developer on every project is using them - even in circumstances where they arguable could / should.
Why is that, do you think?
An interesting analogy is why don't all programmers use flowchart diagrams when writing code? This flowchart vs code-hacking comparison is exactly the same question in my mind as the graphical process definition vs procedural / action-oriented scripting approach using Perl or JavaScript or VB or whatever.
The real question then is how do process composition and control functionality become more appealing, accessible and usable to the 95% of developers in the world who are not "enterprise developers".

[ Jorgen Thelin - Why is everyone not using BPM products already? ]

In other words, there is the room and a requirement for both process-oriented and procedural-oriented approaches to composition and orchestration.

This seems to be exactly the same sentiment behind the desire for a cleaner separation of the choreography and orchestration concepts in the latest BPEL v1.1 specification - precisely because the implementation of orchestration logic will be and is being handled in several different ways. Who knows, maybe Javascript will be one of those ways that appeals most to the mainstream developer.

Posted by Jorgen Thelin at April 19, 2003 12:07 AM - [PermaLink]
Hi Jorgen, I have a couple comments: #1 The addition of native XML support to JavaScript simplifies data manipulation. How does it address asynchronous interactions (BPEL4WS ) and flow coordination (, links)? I think that you are confusing BPEL4WS with XSLT and/or XQuery. #2 You position process-oriented against procedural-orient. Shouldn't it really be process-oriented versus event-oriented. I would recommend that you take a flow and implement it using both approaches and then judge which of them is easier to implement, read, debug and maintain. The reality is that less then 4% of developers know how to implement event driven systems. BPEL4WS and other flow language take event-driven interations and linearize them while encapsulating 60 to 80% of the code. If you do not believe me, I highly recommend you go through the exercise once. As to your question regarding why BPM solution have not been adopted yet, I think that there are 2 main raisons: 1) BPM tools are intrusive and do not integrate well with existing application models. In that respect BPEL alone is not enough to solve the solution. The key is to how BPEL is package and can become one artifact on the developer palette rather than a monolithic IDE. 2) Visual modeling does not scale. Some processes are coarse-grain and can be visually implemented but a lot of processes are more dynamic and finer grain. There a visual flow chart approach will not be enough: the industry will mature towards true "process scripting": Microsoft X# and Collaxa's JBPEL are 2 instances of that evolution. But this is orthogonal to BPEL given that those "script" will be pre-processed into BPEL4WS execution maps. Posted by: Edwin Khodabakchian on April 20, 2003 07:32 AM
Hi Edwin, Yes, I view event-oriented approaches as ultimately always needing some procedural entry point to call back to, so I did sub-consciously lump them together because I largely view them as inseparable in the context of this discussion. I would be interested to see some figures behind your quote that "less than 4% of developers know how to implement event-driven systems". For example, there are a lot of VB programmers out there! Those guys are at least _using_ event driven programming, although I guess the question is how much they _understand_ about systems design and "programming in the large". I think we have to credit the VB guys with at least some level on "knowledge" though. I think you already answered most of the rest of your own questions for me! "Process scripting" and BPEL _are_ largely orthogonal to each other. Annrai's comments about Javascript were not really saying that we should all throw out BPEL, just that it wasn't the "Golden Hammer" that would solve all the world's IT problems - there are still a lot of non-nails out there! Applying BPEL as one tool in the toolbox is the correct and only way to go IMHO, although there are a lot of other tools in the toolbox too. I also think we need to look at ways of making _each_ of those tools more widely appealing and usable to a larger contingent of the IT workforce. I believe that is a sentiment you guys at Collaxa share too. Posted by: Jorgen Thelin on April 20, 2003 01:25 PM
For info, Edwin posted some related points in the Collaxa weblog: http://www.collaxa.com/radio/2003/04/20.jsp#a334 Posted by: Jorgen Thelin on April 20, 2003 01:29 PM
Jorgen, VB is indeed an event-driven programming model but building user interface is very different from building business flows: in the user interface case, the end user is the controller therefore there is very little flow logic and interactions are *very* dynamic. In that use case, event handlers and contrained-based logic are the best approach. I was talking about event based programming in the context of server side integration: similar to the type of development you would do on top of JMS. In that use case, the developer needs to manage state and sequence interactions into long-running flows ( = the server is the controler). Writing that controller/flow logic is what is *complex*. Going through a simple example proves it. I am not judging VB developers...it is just that the use case is different from UI apps and there are only a handful of system developers that know how to tackle this type of problem. I am very much in agreement with your point regarding BPEL not being a golden hammer but rather one tool in a large toolbox! Unfortunately there is a wide education gap. This is mainly driven by traditional EAI vendors and even start ups like Intalio who claim to offer everything you need and associating at the same time the standards like BPEL4WS with those monolithic "business-analyst" focused magic pills. Thank you. I enjoyed this discussion. Please let me know next time you come in the bay area and may be we can connect in person and go have a beer! Best, Edwin Posted by: Edwin Khodabakchian on April 20, 2003 09:50 PM
The focus on the document metpahor and thereby away from documents to invoke services wins my vote. But I'm wrestling with two thoughts: How much clear blue water between this and traditional MOM? XML documents are a fancy kind of text in the message. http is a ubiquitous kind of transport. Instead of using LDAP to find queues, we now use UDDI to find service points. Evolution or revolution? For example: in a document the XML is just syntax. The value is in the next level - the business vocabulary and grammar. Take an industry standard like fpML. They're rolling their own fpML parsers. At this point the document could be ASN1, CSV, or even Corba bytes - as the access is via the parser. As vertical industry standards spread will the document become secondary to the way it is addressed? Already developers think "DOM" instead of XML as this is what they use. The other difficulty with the document metaphor is pathological behaviour. The document is an interface and the weakness of most static interface definitions is they can't anticipate unexpected errors and other exceptions. This will also be the challenge of BPEL4WS - that you define the behaviour you wan't, but what to do in failure cases? Realistically we won't automate this and will need to support in-flight remediation. Instead of modeling exceptions in BPEL4WS we'd be better off using a VAN (value added network) to track where the documents are and why they are there. The document metaphor tells us "lost in the post" will be a bigger problem than not knowing whether to pass to George or Mildred. Is there a Grand Central equivalent for inside organisations? btw - cool blog! Posted by: Matthew Rawlings on May 1, 2003 12:44 AM
Edwin can you provide more detailed use case on why you think visually modeling does not scale ? Is that because you think the models become inherently complex and therefore less readable/difficult to maintain (e.g UML models for a complex system) or you think some metaphors cannot be modeled graphically ? What you refer to "magic pills" I would define as addressing requirements/users in a different part of the whole lifecycle.You can see BPEL as a better way of integrating (as in UDDI is better way of looking up queues than in LDAP) or you can view it was a better way of getting closer to the actual business process that someone might actually draw in Visio. The opinions expressed here represent my own and not necessarily those of my employer. Posted by: Ashish Agrawal on May 5, 2003 09:07 PM
You know your employer feels the same way! Posted by: Marco Island on August 4, 2003 01:41 PM