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