The Model Stack
The following is an overview of the model stack:
A Reference Architecture
The model
stack, has both BPM and SOA pieces ; the SOA
component is itself divided into two parts: a Process Integration Engine
that executes orchestration processes, and an Enterprise Service Bus
(ESB) that performs low-level message routing and transformation. This
three-layer structure is shown in the following figure:
The model stack supports a distributed
architecture in which the activities of client applications and partner
services, both internal and external to the organization, are
coordinated by orchestration processes. Clients and partners communicate
with these processes through an ESB. Internal connections typically use
MOM queues to access the bus; external connections use SOAP over HTTP.
The orchestration processes, besides coordinating partner activities,
also interface with backend systems (databases, mainframes, and so on)
and use BPM to delegate manual work to human actors. The next figure
illustrates this architecture.
Vendor Offerings
Although there
are niche vendors in both SOA and BPM, a few large vendors
today-notably TIBCO, BEA, Oracle, and IBM-offer a product stack with the
complete set: BPM, Process Integration, and ESB. The following table
breaks down each offering.
|
Vendor
|
BPM
|
Process Integration
|
ESB
|
|---|
|
TIBCO
|
iProcess
|
BusinessWorks
|
ActiveMatrix
|
|
BEA
|
AquaLogic BPM
|
Weblogic Integration
|
AquaLogic Service Bus
|
|
Oracle
|
"Fusion" BPA Suite
|
"Fusion" BPEL Process Manager
|
"Fusion" Enterprise Service Bus
|
|
IBM
|
Websphere Process Server, FileNet
|
Websphere Process Server, Websphere Interchange Server
|
Websphere Enterprise Service Bus, Websphere Message Broker
|
Each layer of
the stack is inherently process-oriented, which is not at all surprising
for the BPM and process integration layers. Even the ESB, it turns out,
is powered by small, quick-burst mediation processes that move messages
in and out of the stack. In a perfect world, these layers would use a
common process language and a common process runtime infrastructure. Processes are processes,
whether for human workflow or SOA automation. But in the real world of
vendor stacks, architecture is not so tidy. TIBCO's iProcess is entirely
different from its BusinessWorks, and BEA's AquaLogic BPM is worlds
apart from its Weblogic Integration. If you are proficient with
assembling boxes and arrows on one canvas, be prepared to retrain before
attempting a similar activity on another canvas.
Not
surprisingly, TIBCO and BEA acquired their BPM platform from pure-play
vendors: TIBCO from Staffware, and BEA from Fuego. The Oracle and IBM
platforms are motley in their own way. Acquisitions, religious wars,
old-meets-new, and the geographical dispersion of engineering teams make
for diverse toolsets. Still, if a vendor started with a clean slate,
and locked its SOA and BPM engineers in a war room, there's no question
they would emerge with a unified BPM/SOA system.
Where Does BPEL Fit?
BPEL is a
leading standard in the BPM/SOA world and presumably a key part of any
vendor's stack. Unexpectedly, vendors cannot agree on where it fits:
BPEL is
a first-class citizen for Oracle and IBM, but the line between process
integration and BPM is fuzzy in those stacks. Is Oracle's BPEL Process
Manager for process integration, BPM, or both? In which layer does IBM's
Websphere Process Manager-a BPEL engine with a BPEL4People
implementation-belong?
BEA
is a leading author of the BPEL specification, but BPEL is not a
first-class citizen in the BEA stack. The process language that Weblogic
Integration uses-known as Java Process Definition, or JPD-is very
similar in nature to, and influenced the design of, BPEL. Weblogic
Integration provides import and export facilities to transform BPEL to
or from JPD. Still, BPEL is surprisingly understated in the BEA
implementation.
For
TIBCO, BPEL is suitable for long-running orchestration processes in the
process integration layer (as an extension to BusinessWorks). In
addition, mediation flows in TIBCO's service bus are represented in a
restricted transform-and-route BPEL form. (The graphical editor hides
this detail from the developer.) TIBCO also makes prominent use of BPMN
(another well-known process standard) as the analyst-friendly language
of its BPM modeling tool Business Studio, and it provides a mapping from
BPMN to iProcess to move analyst models to executable form. Curiously,
TIBCO does not provide what you would expect-a mapping from BPMN to
BPEL. Numerous BPMN modeling tools and the BPMN specification itself
define a mapping to BPEL, but TIBCO keeps these standards separate: BPMN
is for BPM; BPEL is for SOA.
Design Tips on Separating BPM and SOA
Assuming we
have the model stack (which supports both BPM and SOA) and use case
requirements that call for a process with both BPM and SOA activities,
how do we decide how to split the design into BPM and SOA parts, and
which part drives the end-to-end flow?
The first step is to
tally the required process activities and divide them into two groups:
human tasks and automated tasks. If human tasks outnumber automated
tasks by a wide margin, a BPM-based solution might be the best choice;
if automated tasks win, we are inclined to choose SOA. In the disputes
process, as we discover in the next section, the split is nearly even,
which makes both approaches feasible.
But there are
several other factors to consider. One is the capabilities of the
stack. If the SOA part of the target platform is faster, more scalable,
more developer-friendly, and more functional than the BPM part, SOA is
the clear choice. The reverse can also hold true. Generally:
BPM has better process monitoring than SOA.
SOA can handle greater message volumes than BPM.
Not all SOA implementations support long-running processes.
Not all BPM implementations support inbound events from external sources.
Most BPM implementations have limited application integration capabilities.
Support for control flow process patterns-such as those presented at www.workflowpatterns.com-is
often a toss-up. On your platform, BPM might have better support than
SOA for, say, cancellation and multiple instances, but SOA might win on
deferred choice and synchronization. Decide which patterns you need and
determine which part of the stack best supports them.
A final
consideration is the interoperability of the two layers. A BPM-based
choice is feasible only if BPM can easily call and be called by SOA. An
SOA-based choice can be considered only if SOA has a good BPM plugin
that allows it to assign, and be notified of the completion of, work.
In this book on SOA, we concede that there are processes that are best controlled by BPM. Sometimes less is more
with SOA. But there just as many processes that belong to SOA. A good
architecture recognizes that processes are processes, and uses the stack
to its fullest to build them properly.
