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");
   }
shows how the code contains the logic for a fragment of a business process that presumably does a portion of an order fulfillment process. It does a credit check, an inventory check, and then attempts to schedule production of the order, all with suitable fault creation should any of those steps fail.

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()) {
            ...
        }
    }
    ...
to add support for an order fulfillment process, where credit checking is unnecessary.

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

Comments:

[Trackback] Ron Ten-Hove has two interesting blog entries, one talking about how SOA Services != RPC and another one about the relation to business process automation. In his view, the most important difference is the separation of business process logic from the ...

Posted by Stefan Tilkov's Random Stuff on August 02, 2007 at 09:40 PM EDT #

It was as a result of development and maintaining this kind of hard-coded business logic for enterprise organisations that we conceived the idea of an product that solved several of the problems you mention. Although SOA and BPEL go some way towards addressing some of the issues, the complexity of that solution still leaves you with something that is far from transparent to the average business user, as well as being costly to implement. The product we came up with took the approach of defining the business process in the form of a deliberately simple executable flow diagram, tied to discrete business functions modules. This approach allows the business users to understand and even amend the business logic themselves and implement new processes quickly. As the processes generated in this way can be exposed as web services themselves, this solution works not as an alternative to a full-blown SOA implementation, but a stepping stone on the way to one, or as a tactical fix where full blown EAI or SOA is simply not feasible or cost-effective.

Posted by Ciaran on August 05, 2007 at 11:00 PM EDT #

Post a Comment:
Comments are closed for this entry.
About

rtenhove

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today