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]
Sent: 26 March 2004 17:53
To: Ron Ten-Hove; Brand; Olivier;
VF-GP&S Düsseldorf
Cc:
wsbpeltc
Subject: Re:
[wsbpel] BPELJ
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