BPM in a SOA Environment
Abstract
In a service-oriented architecture a business process management (BPM) engine is both a provider and consumer of services. BPM's consumed services generally provide access to the enterprise's applications, while its provided services define and manage business processes. These provided services are used by different types of interfaces and (potentially, at least) other services. This talk explores some of the common design patterns linking BPM engines, other services, interface components, and applications.
We begin by exploring the relationship between SOA and BPM. From the BPM engine perspective, it is tempting to consider other services to be passive providers of functionality that are called upon demand. However, this view is too narrow. Non-BPM services may notify business processes asynchronously when certain business events occur, with this notification serving to triggering activity within the BPM engine. Non-BPM services may also recognize that an event has occurred and initiate a BPM process via the services provided by the BPM engine.
Exploring this further, we realize that there are portions of every business process that cannot be managed by a BPM engine - in particular, the sequence of events that leads to the initiation of a BPM process. Many (if not most) business processes are not managed at all - they are "hard wired" in the form of a chain of communicating components.
From the perspective of user (and other) interfaces, the BPM engine itself can be viewed as a service that defines and manages processes. Operations of this service create and modify process definitions, start and stop business processes, and interact with the individual activities of an executing business process.
The choice of patterns relating a user interface to a BPM engine depends upon which party (the user or the engine) assigns work and determines which task to perform next. We explore two different patterns covering what happens when a user completes one activity and begins another. We also explore the patterns that emerge when a user must interrupt one task and resume work on another.
Most interfaces require access to information that is being managed by services other than the BPM engine. There are several interesting design patterns for this interaction depending upon whether requests for these other services are directed through the BPM engine or are invoked directly by the interface component. Some of these patterns require transactional integrity across multiple service operation invocations.
