Composite Materials

SOA lessons learned from business process automation

As mentioned in my previous blog entry, the current SOA notions of business process composition using reusable business functions (services) owes a great debt of thanks to the business process automation industry.

It was (and continues to be the case, in many places) that business process logic is "hard coded" into applications. One sees this in very modern EJB and Servlet applications (to cite two common examples), but has been the case for many years, and in many languages and implementation technologies.

Examples abounded (and continue to abound) in many IT shops. For example

   if (CreditChecker.isCreditOkay(order.getCustomer(), order.getAmount()) {
      if (Operations.checkInventory(order.getManifest() != OKAY) {
         throw new OrderCannotBeManufacturedException(order, "missing_parts");
      }
      if (Operations.scheduleForManufacturing(
            order.getPromisedDate(), 
            order.getCustomer().getId(), 
            order.getManifest(),
            order.getShipAddress(),
            order.getShipMethod()) != OKAY) {
         throw new OrderCannotBeManufacturedException(order, "cannot_schedule");
      }
   } else {
      throw new OrderDeniedException(order, "bad_credit");
   }

The weakness in this approach is two-fold. Firstly, the overall logic of the business process is very hard to determine. (What happens in the scheduleForManufacturing() step, for instance? It obviously (eventually) does something to arrange shipping -- but that is in some other code!). The process is implicit in the code, intermixed with a lot of other code (in more realistic examples). Secondly, composition of new processes is difficult, due to the mixing of process logic with other (implementation) logic. No I add a new process by adding some sort of variables to affect the logic?

    if (!isInternalFulfillmentProcess) {
        if (CreditChecker.isCreditOkay(order.getCustomer(), order.getAmount()) {
            ...
        }
    }
    ...

What the business process automation industry taught us was to separate the business process logic from the implementation logic. A business process in composed of various activities (business functions). These functions are realized by automated agents (programs), or by people (I'll save BPEL4People for another blog entry!). A separate business process definition serves to hold the logic connecting these various activities. A process engine serves to execute the process definition logic at run-time, orchestrating the business functions appropriately.

This isn't just an exercise in refactoring. What this enables (and is the key insight of business process automation) is the composition of new process definitions, based on the activities used by others. In fact, the business functions embodied by such activities are now free of the context in which they are executed: they cannot assume anything about why they invoked. They certainly cannot contain logic about what steps in the process are executed "next"; that is now part of the process definition, not the activity code.

If you look at WS-BPEL, you see these concepts (minus the human activity part) embodied in a language that is based on web services. Orchestration (execution of the business process logic) is defined by something that is completely separate from the implementation of the activity logic: a separation of concerns, exactly as realized in business process automation.

This separation of concerns continues to help us as we continue to explore SOA systems based on ubiquitous messaging protocols, which eliminate many technical coupling impediments to interoperation. In particular, services (like process activities before them) are the essential units of reuse in a business process. Thus we come full circle to my previous entry, "What is a service?"

Posted at 12:02AM Aug 03, 2007 by rtenhove in Service Oriented Architecture  |  Comments[2]