Achieving Separation of Concerns Using BPEL
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The vast majority of software producers focus exclusively on domain-specific solutions. In this way, software is becoming more customized and, correspondingly, less generic. While some end users (particularly large corporate customers) may be able to request features that closely fit their business processes, it’s likely that most of us end up with a poor fit between our deployed software and our business process needs. The end result is massive cross-vendor duplication of software development that tries to implement code as well as business process logic.
An interesting separation of concerns is becoming possible by the use of BPEL. BPEL (Business Process Execution Language) allows for business process logic to be expressed in a specific language and to be tied into external software. This reduces (and potentially eliminates) the need to code business process logic in a traditional programming language (such as Java or C++/C). In turn, this provides a clear separation between software features and business processes. By taking the business process logic (e.g., workflow management) out of the application code, the latter becomes simpler and more focused.
In this article, I’ll review the idea and merits of separating software features from business processes in the context of BPEL. Along the way, we’ll see how this leads neatly to the need for highly generic software. The latter is (in my opinion) a pressing concern for all software developers.
Dynamic 24-Hour Business
The pace of business continues to increase, outstripping the ability of IT to keep up. I saw this up close recently when I booked a flight online: I entered all of the flight details, my credit card number and address, etc., and clicked the Confirm button. The software chugged away doing its thing and returned with "Error 2, please ring the reservation center immediately." It was around 9:00 p.m. and was outside the business hours of the reservation center. The next day, I made contact with the center, and it turns out that the software allows three minutes to enter all details before leaving booking mode and transferring to enquiry mode. Credit-card deductions can’t be made in enquiry mode! So the operation failed with the apocalyptic message! This turned a normal synchronous (operate until finished) business process into an asynchronous process with an exception. The latter invariably requires human input!
To their credit, the agency contacted me at 9:01 a.m. to resolve the problem. This illustrates the close relationship such organizations have with their IT infrastructure. I suggested (amicably) that the software could possibly be improved by allowing users to enter a date range and have the system return with the best price, rather than being driven entirely by the user.
Figure 1 illustrates the existing user-driven workflow, where the system simply checks availability and books the travel details.
)
Figure 1 Flight-booking scenario
Let’s identify the business processes and the software elements in Figure 1. The business process is the overall set of activities that ultimately results in a revenue flow into the service provider. This means that the business process is everything that happens in Figure 1, as well as back-end operations.
The associated software is the code that runs in support of the business process and comprises
- Capturing flight details
- Capturing selected hotel details
- Calculating price
- Making the final booking
Let’s now try to separate the business process from the software elements. The "Journey Management" entity in Figure 2 is a notional placeholder that may or may not exist in the operational system.
)
Figure 2 Business process and software separation
The end-to-end business process starts with the instantiation of a notional Journey Management entity. The latter then creates entities to support the remainder of the business process. How might the provider implement the suggested improvement of allowing a range of dates? Figure 3 illustrates a possibility: adding an entity called "Enter Loose Details."
){kind=link}
)
Figure 3 Using business process thinking for a more flexible format
The Loose Details entity would allow selection of a date range and a destination. Then, it would search for the best rate or a selection of rates. The user could then select one of the returned options, and we’re back to the normal operational mode except that the system has supplied some critical (business-differentiating) data.
Where’s the BPEL?
Where does BPEL fit into this? Mostly in orchestrating the flow, starting with the Journey Management entity. In other words, the Journey Management entity (if it exists) can be expressed in BPEL. Under user direction, this entity invokes the other elements as web services. Such an arrangement provides the required separation of concerns.
In practice, if you wanted to add a feature (such as the loose date details above, followed by availability/price calculation), the programmers would have to start updating web service code, taking care not to break the containing business process flows. In other words, the code and business processes are unnecessarily intermingled. Does it have to be this way, or can organizations use the current wave of migration towards web services as an opportunity to improve things? I believe BPEL provides what may be a golden opportunity for the software industry to place code into a more generic or utility-centric role with minimal contact with business process flows.