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 BPEL, 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, Microsoft, 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-to-end business 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-to-end.
But BPEL has no concept of a subprocess, which you might consider the fundamental unit of reuse in BPM. That doesn’t mean you can’t build end-to-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 named 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 you do BPM without it? But it’s a feature tacked on, not baked into the service orchestration standard.
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-and-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 services for orchestration into new composite applications. Typically a middleware component called 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 systems 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 orchestration, i.e., invoking their 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 rarely discussion of business processes.
It’s more than simply a question of nomenclature. While a business analyst envisions an end-to-end process as a single hierarchical entity, with a well-defined beginning and end and well-defined overall state, an IT architect typically views the SOA solution embodying that process as a collection of service-oriented components that invoke each other in a peer-to-peer arrangement. When most IT architects think of SOA, they are not thinking about business processes, but more 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 allows 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 skeleton 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 process 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 automatically 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 components. 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 environments 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.
