[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] BPELJ
Relative to Issue 101, it was suggested that I post a possible solution Relative to the use of Scope resolution Operators by Yaron. This Action is now being done in the hope of stimulating discussion.
Phil Phil Rossomando
Research Director, Technology & Architecture Unisys Corporation Unisys Way, B-330 Blue Bell, PA 19424 USA Philip.rossomando@unisys.com 215-986-3998 FAX 413-0215-2043
-----Original
Message-----
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.
Regards
Derek Miers Enix Consulting Limited Office: +44 (20) 8742 8500 http://www.enix.co.uk
From: Jim Clune
[mailto:jim@parasoft.com]
Ron wrote:
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]