BPMS Watch: BPM and SOA: One Technology, Two Communities ...

spinabundantInternet and Web Development

Jul 30, 2012 (5 years and 9 months ago)


BPMS Watch: BPM and SOA: One
Technology, Two Communities

Monthly Column by Bruce Silver, Independent BPMS Industry Analyst

Last month we talked about how service
oriented architecture (SOA) is making BPMS
technology more agile by eliminating the custom code once needed to integrate the
various systems involved in a business process. But we also talked about the fact that

the process definition language standard based on SOA, has not been warmly
embraced by most of the BPM community. Notwithstanding that, BPEL remains at the
very heart of the accelerating BPMS efforts of the world’s largest software companies

IBM, Micros
oft, Oracle, SAP. What’s going on here?

Despite its name

Business Process Execution Language

BPEL is not really about
business processes, at least in the way the BPM community thinks about processes. For
example, in the BPM view, an end
end busines
s process is composed of various
subprocesses in some nested or chained arrangement. Each subprocess might be owned
and executed by a different business unit, but somehow the BPMS manages and tracks
the whole thing end

But BPEL has no concept of a

, which you might consider the fundamental
unit of reuse in BPM. That doesn’t mean you can’t build end
end processes out of
nested and chained components in BPEL. Of course you can. It’s just that the notion of
subprocesses is absent in BPEL.

Similarly, BPEL has no concept of human participants identified by role, group, or even
user name. In BPEL, process activities are assigned to
service endpoints
, which resolve
to URLs. There is not a separate service endpoint for each role, group, and na
med user.
Instead there is a single endpoint for a
task management service

external to the
process model

that routes the task to the appropriate user or queue. Again, all BPEL
based BPMS tools provide some sort of task management service

how could yo
u do
BPM without it? But it’s a feature tacked on, not baked into the service orchestration

So what are SOA, BPEL, and service orchestration “really” about? At this point in their
evolutionary cycle, they are really about enabling developers to
build all types of
applications faster and with less coding. Also, unlike the traditional gargantuan rip
replace style of IT system development, SOA lets companies use what they already
have. Even though they might be self
contained monoliths differing

in platform, API
language, and data models, existing systems can be decomposed, using new SOA
middleware, into discrete functions that are thereby exposed as

into new
composite applications
. Typically a middleware component
ed an integration adapter “wraps” the existing system and presents a new, standards
based interface (called WSDL) to the orchestration design tool. In BPEL, the
orchestration engine (in BPMS we call it the process engine) executes functions on
these system
s by invoking the WSDL interface.

This is really a revolution in application development. The middleware hides the
implementation differences between existing (and new) systems and allows new
applications to be composed by

i.e., invoking th
eir services in the proper
sequence. The term “composed” is important. These composite applications are not
written from scratch, but assembled, from reusable units, i.e., services.

BPEL is the language defining that composition. BPEL
based orchestration
engines rely
on many of the native capabilities of J2EE and .Net application servers and their
associated middleware stacks. So it should be no surprise that IBM, Microsoft, Oracle,
and SAP are behind BPEL and service orchestration in a big way.

But what
the BPM community calls a business process is only one style of integration
based on SOA. In fact, within the SOA community the BPM style could even be
described as a special case. At SOA conferences, for instance, you may hear discussion
of BPEL but rarel
y discussion of business processes.

It’s more than simply a question of nomenclature. While a business analyst envisions an
end process as a single hierarchical entity, with a well
defined beginning and end
and well
defined overall state, an IT arc
hitect typically views the SOA solution
embodying that process as a collection of service
oriented components that invoke each
other in a peer
peer arrangement. When most IT architects think of SOA, they are not
thinking about business processes, but mo
re generally how to build reusable service
components and assemble them into composite applications.

This mindset dichotomy is clearly visible in IBM’s recent blockbuster WebSphere SOA
announcements. For the business analyst, WebSphere Business Modeler v6

business analysts to define, simulate, and design key performance indicators for a
process solution using the BPM paradigm. This model lacks the implementation detail
to be immediately executable, but it can be imported directly as a set of skeleto
n service
components into WebSphere Integration Developer (WID), IBM’s new SOA design
tool for IT.

WebSphere Integration Developer and its associated runtime engine, called WebSphere
Process Server, provide all the functionality of an advanced BPMS, based

entirely on
SOA. But their solution artifacts don’t describe process activities. Instead they reflect
the IT perspective of SOA in which service components of any kind are wired to each
other as peers through an enterprise service bus (ESB). A BPEL proces
s is a service
component, but so is a business rule, and so is a human task. They are all peers. The
fundamental units of reuse are not activities and subprocesses, but the more generic
component assemblies

As Process Server executes, it issues events au
tomatically as instances of service
components are executed. Using specifications defined in Business Modeler, these
events are captured by WebSphere Business Monitor and aggregated as KPIs and other
metrics displayed in performance management dashboards.
These can be fed back into
Business Modeler, closing the cycle of continuous process improvement, one of the
cornerstones of BPM.

In its new SOA framework, IBM addresses the BPM/SOA dichotomy directly.
WebSphere Modeler and Monitor, intended for business
analysts and process owners,
embrace BPM concepts and view the IT platform as a BPMS. WID and Process Server,
used by IT, describe the solution artifacts, even those created by Modeler and displayed
in Monitor, more generically as interacting service compo
nents. But unlike the
traditional business
IT handoff, in which business analyst tools simply create
requirements documents that must be interpreted by IT in their designs, IBM unites the
underlying descriptions and artifacts created in the two environment
s and performs all
necessary translations automatically under the covers. While much of its SOA customer
base might just use WID and Rational developer tools, IBM allows those tools to serve
the BPM market as well by wrapping them in Modeler and Monitor.

Most of the BPMS vendor community has been stymied by the BPM/SOA dichotomy.
IBM’s new Process Integration Suite provides a neat solution.