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

I am usually a lurker observer on this TC (so I don’t suppose that my opinions really count for much in the way that decisions are made). Again, I haven’t yet read the IBM-BEA paper itself (too much to do and not enough hours), just the many and various reactions to it popping up all over the Web. So here is my 2 penny worth:


There seem to be two camps involved – those who see this as something necessary to ease the burden on the poor Java programmer. For them, something like BPELJ sounds much easier to deal with than having to jump through hoops to work with BPEL. Here, ‘loose coupling’ is a pain in the butt. BPELJ lets them insert a ‘work around’ to get by a whole raft of difficult situations.


At the other end of the scale are those folks who (like me) are looking at BPEL as an execution language for ‘Business Processes’ (and there are still many issues there). Here, the engine can read the definition and execute. The semantics of the process need to be separated out from detailed programming of functional calls. If we can do that then there is a chance to close the gap between business users (who dream up new ways of working) and the systems that are used to support their operations. With the right tools, they can envision a process and then ‘make it so’, without resorting to an army of programmers – modern BPM environments are already enabling just such an approach. Here, ‘loose coupling’ is what enables re-use, flexibility and adaptability.  


The idea should be that these sorts of languages (BPML and BPEL) should pursue the old truism - that if it can be abstracted into the semantics of the approach, then it should. By introducing a change like BPELJ, IBM and BEA are taking things firmly back in the other direction - into the realms of programming that requires deep technical skill.


I used to have an adage that I used when looking at workflow engines. If you asked about something a little more difficult, they would say something like "that's easy, you have to write a program to do that". You'd get that answer for all sorts of questions - like asking how you would ensure the same actor received the work item if it navigated back to that role, or integrating even the simplest application.


All that this (BPELJ) shows is that the Application Server vendors and integration centric players have difficulty meeting the semantic needs of true BUSINESS PROCESSES. "How things get done around here" is full of all sorts of subtleties, and if you cannot represent it at the semantic level, then you have to resort to programming.


For those of us, who see a future where an executable business process language can enable a whole new approach to computing, the introduction of Java programming extensions within BPEL is a very retrograde step. Quite simply, it will ensure that the ‘standards’ end up having very little to do with the business and a lot to do with programming – thus sustaining the Business-IT divide. To me, the key point is not one of portability on platforms (one could argue that Java is portable). Instead, it is whether the engine can externalize the logic embedded in the Java.


The BPEL TC should resist this sort of attempt to divert its activities and focus their attention on solving the problems of the business process at the semantic level – giving the BPEL specification the sorts of process-oriented capabilities needed by business. At least then there is a chance for a whole new raft of software platforms that can present these semantics in an end-user accessible environment.


The TC should very explicitly reject the antics of vendors who want to divert its activities back towards developing yet another irrelevant guideline for IT programmers. BPELJ seems (at least to me) to serve only the needs of the existing application server and programming tool vendors – those who are most threatened by the emergence of business accessible computing environments.  





Derek Miers

Enix Consulting Limited

Office:         +44 (20) 8742 8500



From: Jim Clune [mailto:jim@parasoft.com]
Sent: 26 March 2004 17:53
To: Ron Ten-Hove; Brand; Olivier; VF-GP&S Düsseldorf
Cc: wsbpeltc
Subject: Re: [wsbpel] BPELJ


Ron wrote:

Why don't we take the approach that IBM is following within their BPEL implementation: make use of the WSDL binding extensions to include other type of technology? I am talking here about WSIF. It seems to be a good approach. The BPEL compiler will be the one optimizing access to the objects.

I have spend a lot of time making similar points with my colleagues. I have consistently run into the objection that packaging very fine-grained data manipulation operations as Web services is a) an unnatural act for a programmer, and b) incredibly inefficient. I have found some could ways to counter the latter point (to some degree), but not the former. Does anyone have some insight into the former line of argument?

Well, I don't know how insightful it is, but here's my two cents.


I think that objection (a) is largely a product of what it means to package a Java method as a Web service today and not necessarily a reflection of obstacles intrinsic to the WSIF paradigm. It is true that a WSIF-oriented approach requires the programmer to think at least in terms of methods and classes instead of snippets, but Java programmers already think in terms of methods and classes. Refactoring data-manipulation expressions into separate methods is simple (and often useful in its own right) so I don't think that would encounter much resistance. The present gap that exists is that once the programmer writes a class exposing methods to be used in the BPEL, the programmer needs to jump through hoops to describe the Java service in the WSDL. I suspect that if the WSDL generation process was simple and reliable, many programmers would actually be more attracted to writing real Java classes instead of JSP-like embedded snippets.


Jim Clune
Parasoft Corporation          email: jim.clune@parasoft.com
101 E. Huntington Ave.      voice: (626) 256-3680
Monrovia, CA.  91016           fax  : (626) 256-6884


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