BPEL can be used to implement workflow and business processes. In theory, BPEL
is not tied up with Web services or SOA since all J2EE BPEL vendors support
callouts to EJB , JMS or even POJOs in their BPEL implementations (BPELWS, BPELJ
). BPEL has some interesting capabilities, such as the support for asynchronous
and long-running processes, transaction compensation, and integration with UI
for human activities. But the main point of BPEL is really its visual nature,
the fact that the BPEL flow can be modeled in a visual designer tool. If not for
that, it would’ve been more efficient to provide the aforementioned capabilities
in the form of yet another Java API . The fact that BPEL is “visual” should make
it easier to gather requirements and communicate changes to business
stakeholders. Some vendors even go as far as proclaiming that now a business
analyst can change and optimize a business process without requiring the
involvement of a software developer.
However, for any real-life system some logic would still remain in the Java code.
At the very least, the Java code would have some kind of persistence support for
data transferred by the BPEL flow. More likely, complex business rules, the ones
that would be too unwieldy to implement in BPEL will also be coded in Java. Also,
since BPEL does not have the reuse capabilities of an OO language, anything
reusable will probably be coded in Java (although, a piece of reusable logic
could also be implemented as a reusable BPEL subprocess).
So on one hand, BPEL should be pretty high level and the business process‘
activities (and, therefore services APIs) should be coarse-grained. But this
will externalize only the most rudimentary logic of the system. Granted, this
high level flow could still be useful if the goal is to integrate different (probably
heterogeneous) systems, but if we want to use BPEL for its process modeling
capabilities, this may prove insufficient. Devil is always in details and so
most likely in real life business process changes or optimization will require
changes to these complex business rules implemented in Java. In other words, no
matter how we try, business people still need to work together with the
developers, make sure that the use case are right, changes are thoroughly
tested and so on.
On the other hand, implementing very complex detailed business processes in BPEL
is probably difficult at best. Visual modeling approach has its natural limits
and so at some point it will become much easier to fire up a Java IDE . I guess
it is also possible to hand-edit BPEL XML code, although this probably won‘t be
pretty either, using XML as a procedural programming language has its limits too.
So what is the right usage of BPEL ? Is just a Web services orchestration
language or a general purpose business modeling environment?
Thank You