Context
The emerging de facto standard for building business process-driven SOA solutions is to use the Business Process Execution Language (WS-BPEL, henceforth simply "BPEL") to implement
the executable process. BPEL can be used to:
-
Create an executable version of a Business Process Modeling Notation (BPMN) modeled business process (process flow
logic).
-
Implement a composite service by orchestrating a set of calls on atomic services (composition logic).
For any given executable process, both of these tasks can be achieved using a single BPEL artifact describing a
sequenced step of Web service invocations.
Forces
-
It makes it more difficult to reuse the composition logic.
-
It makes it more difficult to understand the process flow by looking at the BPEL.
-
The resulting implementation artifact is more complex and therefore more difficult to maintain.
-
It makes it more difficult to split the roles of process developer and service developer.
Problem
Mixing process flow logic and composition logic together in the same implementation artifact has problematic side
effects.
Solution
For each Participant that realizes a composite service, create owned behaviors that describe how each exposed operation
is implemented. The first diagram in Example: Participant (SoaML) illustrates an OrderProcessor Participant owning a
behavior for an operation, processPurchaseOrder. The second diagram in that example illustrates the owned
behavior, in this case an Activity. For each such Participant, either generate or hand-code BPEL that can be
used to orchestrate the calls that realize each service operation.
Limit the BPEL that drives the business process to orchestrating the calls to the service operations that realize each
of the sub-processes and/or tasks that are in the first level of decomposition of the business process. See Concept: Business Process Decomposition for an overview of business
process decomposition.
Use the BPEL that was created from the Participants' owned behaviors to implement the composite service operations
that are called from the process flow BPEL.
In the case of a hierarchy of composite services -- that is, we have composite service operations which are realized by
calling services provided by other composite service providers -- apply the above solution pattern
recursively. The BPEL for realizing the operations for one level of composite services shall be limited to
invoking the operations provided by services in the next-lower level of the hierarchy. The BPEL at one level of
service choreography shall contain no information that can be used to infer how its realizing operations are themselves
realized.
Notes:
-
The composition logic need not be implemented using BPEL. Oftentimes it is simpler to just use plain old Java, or
another conventional programming language. This might depend on the tools and skills of the developer assigned to
implementing these components.
-
"Pattern 12: Represent Processes as Service Consumers" is closely related to
this pattern.
-
This pattern is a special case of a more general pattern on separation of concerns. In this pattern, we
talk specifically about separating the composition logic from the process logic. There are other concerns
that need to be separated as well, such as business logic, security logic, or connectivity logic.
Rationale
Keeping the process logic separate from the composition logic means:
-
It is easier to reuse the composition logic across multiple processes.
-
It is easier to understand the process flow BPEL as it only contains flow logic.
-
The resulting BPEL is simpler and therefore easier to maintain.
-
It is easier to split the roles of process developer and service developer. Process developers implement the
business process service consumers. Service developers implement the composite business application services (and
any atomic business application services they require).
|