Separation of Concerns and BPEL Blog


    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 development of software 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 allows for business process logic to be expressed in a specific language and 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, etc.). 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.

    Let's say you buy a shrink-wrapped package with nfeatures. If this software is integrated into a BPEL framework, then it should theoretically be possible for you to swap out any of the n features and replace them with web service (or downloaded) code of your choice.

    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. I believe the latter is a candidate for a project.

    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!

    A Happy Ending

    To their credit, the agency contacted me at 9:01 a.m. the next morning 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.

    Flight-booking scenario

    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.

    Business process and software separation

    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."

    Using business process thinking for a more flexible format

    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.

    BPEL: An Integration Framework

    BPEL is a programming abstraction that allows for the business-specific orchestration of multiple web services to achieve some business computing need. The orchestration results in a complete or partial business process flow. The flow may be:

    • Synchronous: Wait for a result until completion.
    • Asynchronous: Completion is notified later.
    • Long running: Input might be required from a customer contacted by post.
    • Deferred: The state is stored for later re-activation.

    An important element of BPEL is its support for XML technologies, such as XPath, XSLT, and XQuery. This means that BPEL can manage XML documents and make calls to external web services.

    This provides a means of moving business logic out of the built-to-order area (today's code) and into the generic web services layer and the BPEL layer as illustrated in Figure 4. The migration process from built-to-order to web services is happening today, but there is also an opportunity to add value with the use of BPEL.

    Migration of Today's Built-to-order Code to BPEL and web services

    Figure 4. Migration of today's built-to-order Code to BPEL and web services

    BPEL can be used to implement the business logic, and the web services code can provide far more generic services. In effect, Figure 4 illustrates a means of separating the dual concerns of expressing business logic and the associated software-based services.

    What does such a separation of concerns give us? To answer this, let's take a look at separation of concerns (SOC) in other areas.

    Separation of Concerns and Business Processes

    The notion of separating business logic from presentation logic is well established in technologies such as J2EE. The Struts framework provides separation by its use of the MVCdesign pattern to avoid duplication of access logic. The software architecture movement views SOC as a fundamental approach for creating architecture-driven designs.

    In fact, SOC has been with us for a long time. For example, look at the way networks are designed and built: devices are selected, configured to run (usually) several protocols, and services are delivered across the network. SOC also permeates society--if you want a loan, it's unlikely you'd make much progress by going to the dentist! Rather, you go to the service provider who can deliver your requirements.

    Software is one of the few remaining areas where most vendors are still following a one-size-fits-all approach. This is largely because no widely adopted standard has existed up to now for expressing business process logic. As we've seen, BPEL now fills this gap.

    The Advantages of SOC

    If we look at Figure 4, an organization migrating to web services can use this as an opportunity to encourage more generic software while simultaneously expressing business logic in BPEL. Such a framework offers scope for organizational differentiation.

    Customization is the key as vendors try to address segmented markets. For this reason, generic software is not just desirable but is in fact a business imperative.

    BPEL Facilities

    Let's take a look at what BPEL has to offer.

    • <invoke>: Used to call a service synchronously, such as the Confirm Details element in Figure 2.
    • <assign>: Used to manipulate XML documents prior to invoking a web service.
    • <faultHandlers>: Used to catch and manage exceptions, e.g., if a customer has bad credit.
    • <flow>: Used to initiate asynchronous service execution.
    • <receive>: Used to handle asynchronous callbacks from long-running services.
    • <switch>: Used to support decision making, such as booking the lowest price.

    The above facilities allow for a combination of flexible manipulation of business processes as well as a clear separation between business process logic and software.

    Benefits of Generic Software

    Removing business logic from software and placing it in a BPEL "layer" should help to simplify the software. Software for uses such as flight pricing can then become more generic; i.e., a true service. The data acquisition and service invocation can occur in the BPEL layer and the pricing code becomes more of an "engine" model. The latter is similar to a database engine: a generic element of a broader database management system product.

    If the service code is well-engineered, then we might see a true software service component market emerge. Examples of such components could include capital gains tax calculation, flight pricing and booking (as we saw earlier), etc.

    The key benefit for the IT sector in such a trend would be generic cleanly separated software.

    Is Telecom Putting the Brakes on Global Communications?

    Let's take a look at a fairly basic telecom business process: switching on a complex cross-network service.

    A typical telecom service

    Figure 5. A typical telecom service

    The service (and its customers) illustrated in Figure 1 requires multiple routers in the service provider network. It could be a virtual private network (linking geographically distributed sites), an IPv6 transport, an IP telephony solution, etc. The exact service isn't of interest to us here; suffice to say the service requires more than one router in Figure 5 and might also require use of routers in other service provider networks.

    Let's assume the network in Figure 5 is made up of routers from more than one vendor. How is a service such as the one depicted in Figure 5 created by the service provider? Normally, this is done as part of a business process called service provisioning, an often labyrinthine combination of software, human input, truck rolls, and customer service. The facility that implements all this is called the operational support system (OSS). The OSS orchestrates the overall service provisioning process.

    OSS installations are massively complex bodies of software and business process logic. Many have been built up over 20 or more years. Again, the business process and software logic is inextricably interwoven. While there are many OSS vendors, it is a fragmented inefficient market that serves overly complex installations. The same principles apply to the OSS area as were discussed in relation to Figures 1, 2, and 3.

    Competition Versus Collaboration

    The major software vendors have long competed with each other, and so it should be! Witness the often bitter struggles between Microsoft and Novell. The unproductive practice of extinction-producing competition is diminishing as Microsoft and Sun Microsystems start to collaborate. This should help end users get better products rather than just de facto brands that contain business process logic lumped together with software features.

    I often wonder at the extent of duplication in the software industry: this is certainly the case in telecom where dozens of vendors slavishly implement products based on ever-evolving standards (such as MPLS). Each vendor tries to bring some new wrinkle to their product that will move buyers in their direction. This model can provide benefits in specific domains, such as accounting solutions, but it may be less helpful in industries in crisis (such as telecom) undergoing massive restructuring and technology upgrade. The latter may need a more fundamental approach.

    More collaboration is needed in the software industry to reduce the level of duplication and to increase the generic characteristics of products.


    Globalization has resulted in overcapacity in a number of core industries, such as telecom, IT services, retailing, and car manufacturing, among others. The price transparency offered by the Web has enabled customers to extract maximum value, a trend that has led to unprecedented price competition. It seems unlikely that profits will rise dramatically in the years ahead, even as the world pulls out of what some commentators reckon was the first "global" recession. This may well result in cost cutting on an ongoing basis, and there's no reason to suspect that IT won't be hit. I think that IT should endeavor to become as streamlined as possible and BPEL/web services suggests itself as a possible path to take.

    By removing business process logic from code, we would see the potential emergence of generic software for web services use. Business process logic would then reside in a BPEL layer that would orchestrate the required service calls. This would help to reduce the growing complexity of software and systems.