BPEL can usher in a new era of Business Process Management
Business Process Execution Language promises to aid enterprises
in the quest for SOA. Akshay Aggarwal, Solution Architect, BEA Systems,
talks to Network Magazine about what BPEL can provide.
SOA has been a buzzword for quite a while. What are the
roadblocks that the concept faces today?
One of the most significant trends in computing right now is the migration to
service oriented architecture, or SOA, which is a standards-based
organisational and design methodology that more closely aligns IT with business
processes using a collection of shared services on a network.
Employing standard interfaces that help mask the underlying technical complexity
of the IT environment, SOA enables greater re-use of IT assets resulting in
more rapid development and more reliable delivery of new and enhanced business
services. However, implementing SOA and successfully putting it to work for
your enterprise requires a crucial first step of identifying, optimising and
ultimately automating your key business processes. To make this happen as simply
as possible, the need for an open, common, standard language and interface is
Do Business Process Management (BPM) solutions available
today fulfil this need for open standards?
Standardisation will not only provide enterprises with
more choices, but will also give them a new level of investment protection
and accelerate the adoption of SOA
For several years, a wide range of BPM solutions have been
available, and many of these can no doubt meet the challenge of automating business
processes, but traditionally each has utilised its own proprietary process language,
design tool and run-time engine.
This lack of commonality and openness has essentially trapped customers within
the confines of the tools provided by their chosen vendor, and it has also arguably
slowed the adoption of BPM technologies at a time when enterprises should be
drawing great benefits from them. Adding further complexity to the situation,
the historical lack of a standard interface mechanism for interacting with enterprise
resources has led many BPM and EAI vendors to invent their own adapter and connector
Are there any new open standards/technologies that are
available or are being developed to solve these integration issues?
Just as the advent of Web services standardisation has simplified
the connectivity problem, similar standardisation is sorely needed for business
processes logic. Such standardisation will not only provide enterprises with
more choices, but will also give them a new level of investment protection and
accelerate the adoption of SOA. Fortunately, the first steps are already being
taken towards standardisation. One of the key efforts of relevance is WSBPEL
(Web Services Business Process Execution Language, often commonly referred to
as BPEL), a specification originally co-written by BEA, IBM and Microsoft, and
now being standardised via OASIS. Currently in the midst of heavy revision (with
the goal of formal standardisation by around late 2005), BPEL will provide a
standard way of building automated processes that orchestrate interactions between
What are the main features that BPEL will provide?
The key goal of BPEL is portability. It will enable customers to protect their
investments by allowing them to move their process definitions between a variety
of authoring tools and execution platforms regardless of the underlying technology.
For example, a user should be able to build their BPEL process in one vendors
tool, display and edit it in another, and deploy and execute it in a third.
Realistically, the first version of the standard will not entirely achieve this
goal, but users will still enjoy a higher level of portability than has traditionally
been possible. As BPEL is still in its infancy and not yet a standard, the OASIS
technical committee continues to work through issues and the specification continues
to change significantly. In late 2005 we expect to see a solid working version
of this standard, which we anticipate will bring much-needed portability and
standardisation to the world of business process logic.
While there have been previous attempts at creating a standardised business
process definition language, BPEL has attracted an unprecedented level of interest
and is the first to gain critical mass among software vendors. For those interested
in SOA trends, Web services and BPM, this budding standard is definitely one
to keep a watchful eye on.
How does BPEL work?
BPEL enables customers to protect their investments
by allowing them to move their process definitions between a variety of
authoring tools and execution platforms regardless of the underlying technology
BPEL utilises an XML syntax from which a process diagram can
be rendered, enabling developers to build their processes largely by using visual
drag-and-drop tools. BPEL processes can automate both simple and complex interactions
between multiple SOAP-based Web services using XML documents and types, and
can also represent sophisticated logic such as long-running transactions with
compensation, parallel execution, and both synchronous and asynchronous interactions.
Does BPEL have any problems or drawbacks as of now?
Since it is intended as an SOA standard for Web service orchestration, BPEL
cannot directly interact with resources that do not offer a Web service interface
(such as custom applications with proprietary APIs), nor can it represent fine-grained
procedural logic or complex data manipulation. It is expected that BPEL will
often be extended with other languages and paired with other technologies in
order to solve these types of problems.
Although BPEL is clearly poised to become the dominant standard for orchestration
of Web services, it does not address a number of significant issues faced today
by organisations with heterogeneous IT environments. By design, BPEL only describes
interactions between Web services. While nearly all systems or objects can be
wrapped in Web service interfaces, this mechanism is itself a heavyweight abstraction
that introduces overhead and complexity that may not always be necessary.
When communicating with local resources, lighter-weight interfaces such as Java
APIs often provide a more direct approach. In addition, BPEL does not try to
be a general-purpose programming language, but instead focusses on business
process logic (programming in the large). It is assumed that BPEL
will be combined with other languages like Java which are used to implement
business functions (programming in the small).
So is any work being done to sort out these issues with
It was with these issues in mind that BEA first authored and sponsored JSR 207,
which is chartered with exploring and standardising the relationship between
process languages like BPEL and the Java language and J2EE platform. As the
next major step to defining this Java process standard, BEA and IBM have closely
collaborated to create a new specification titled BPELJ.
This specification has also been submitted to the JSR 207 working group for
consideration. Described in a joint white paper, BPELJ is a combination of BPEL
with Java that allows these two programming languages to be used together to
build complete business process applications. By enabling BPEL and Java to work
together, BPELJ allows each language to do what it does best. Since BPELJ is
implemented via extensions to the BPEL language, any BPEL process is also a
valid, executable BPELJ process. By standardising these extensions, BEA and
IBM are working to ensure that real world automated business processes will
be truly portable and inter-operable across the J2EE platform.