Category Archives: BPEL

Comparison of SOA Suites

Several SOA vendors are trying to put together comprehensive suites of SOA products that in theory should be capable of
addressing
all aspects of SOA, including governance, integration, business process management and others.

Formation of SOA suites is having a tremendous impacts on how SOA products are selected
as many organizations
are being tempted to settle for “one stop shop” approach as opposed to doing proper product evaluation
within each SOA product category. (Interesting discussion about SOA suites is available at
ZDNet).

So what is a SOA suite and how offerings from different vendors support different aspects of SOA?
The table below attempts to answer this question.

Read the rest of this post »

Limits of Visual Service Orchestration

Visual tools for designing message or process flows are part of many ESB
products. BPM products supporting BPEL or BPMN also heavily rely on visual tools.
Flowchart-like visual notation used by these tools represents a specialized
language that includes all elements of structural programming (“if-then-else”, “while” and
so on).

Unfortunately, these languages have very limited support for reuse. Not all such
languages support sub-processes (i.e., subroutines). There is no inheritance or
extension, in other words, I can’t take an existing process flow or message flow
and change some of its logic without duplicating the logic of an existing flow.
Lack of these facilities makes it difficult to implement complex and reusable
process and message flows.

From my experience any real-life process flow is going to be pretty complex.
Three-step loan approval process widely used as an example in many different
BPEL products does not exist in reality. Real-life business processes include
many different activities and involve many different roles. They also have to
take into account various exceptions, not just a “happy path” scenario. For
example, if a loan application is rejected because of a credit history, a lender
can try to offer a loan under different terms.

Also note that there is a difference between using visual tools for modeling and
for coding. A model does not have to include each and every detail, its main
goal is to convey key ideas; details can be taken care of during implementation.
Not so if we want to visually create executable code; in this case all details
have to be accounted for.

I am also not convinced that structural programming approach that BPEL and other
“flow” languages support is best suited for visual tools. Structural
programming constructs replace explicit “flow” represented by “go to”. In a
visual flow-oriented language, however, “go to” (i.e., explicitly connecting
nodes) might be a better alternative.

I also doubt that visual approach works well for code with high cyclomatic
complexity (and without subroutines high complexity is almost guaranteed),
especially with high degree of nesting. Text-based representation of nested code
blocks using indentation could be very compact. This is not the case when each
branch has to be presented by its own “flow” of connected nodes.

So I think that text-based representation using a high-level specialized
language could be a much better alternative for expressing process and message
flows in SOA. This language could be a domain specific language (DSL) or a
general purpose dynamically typed language with built-in XML and Web services
support and other constructs required for supporting process flow. Syntax of
this language should be simple enough and at the same time it needs to have good
support for reuse (this may or may not require full OO support).

Visual representation of a program written in such language could still be
supported; however I see it as a “report” that could be used to facilitate
discussion with business users. Developers should not be required to use visual
environment for programming; I don’t think it makes anybody more productive
relative to text-based approach (unless a flow is really simple). And I’m not
talking about XML-based serialization of a visual flow, such as in BPEL where
XML is so unwieldy that it is almost impossible to hand-edit it. We need a true
powerful “service orchestration” language that will make developers (and
business users along with them) more productive.

BPEL, SCA and Refactoring

With the advent of SOA and SOA -related technologies and standards, such as WSDL ,
BPEL, and, more recently, SCA
and SDO
, more and more application metadata (and just plain data) is
externalized into XML . XML is used for:

  • Flow definitions (BPEL).
  • Interface definitions (WSDL).
  • Component and assembly definitions (SCA).
  • Data (SDO).

Business logic, however, largely remains written in Java. For many people, key
strength of Java and Java IDEs has been very strong support for refactoring (other
languages support refactoring as well, but in this blog I focus mostly on Java).
In fact, in my view, refactoring made agile development possible; it finally
combined design and coding activities into one continuous process.

Unfortunately, with more and more information going into XML files, benefits of
pure Java refactoring are diminishing.

For example, with SOA technologies, an interface name could be used in several
different places:

  • WSDL file (probably in multiple places if we want to use naming conventions, e.g.,
    in “portType“ and “service“ elements).
  • BPEL (multiple places, e.g., in “import“ and “portType“).
  • SCA component definition file.

So what happens if I want to change the name of an interface or rename an
operation? Personally I am not aware of XML refactoring support in BPEL products
(obviously, I have not tested all of them, so I might be wrong here) and I don‘t
expect the situation to improve when SCA /SDO are added to the mix. For example,
is SDO property renaming going to be supported? How will it work if I use XPath
expressions against XML -backed SDO in BPEL ?

Now, dynamic APIs are nothing new, we‘ve been dealing with XML for quite some
time now. However, the approach in Java has always been to map XML to statically
defined classes and so the ripple effect from, for instance, renaming was
somewhat contained (I know that I‘m simplifying here). With BPEL and SCA , the
problem becomes more widespread.

Also, tools for working with these technologies are supposed to rely mostly on
visual modeling and so their users are not necessarily J2EE developers. In fact,
the idea of BPEL is to be able to change business process-related logic quickly
and easily. The idea of SCA (among other things) is to be able to easily wire
and assemble components together. I think that without refactoring, the ability
to accomplish these goals could be impaired.

I just hope that tool vendors realize this risk; otherwise we‘re in for another
round of “XML hell”.

BPEL as a Modeling Tool

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?