Ask 10 people the question: What is SOA? You will most likely get 10 different answers. Chances are that in more than 50 percent of the cases, the word "Web services" will be a part of the answer. Another 20 percent will talk about process orchestration, XML, integration, and so on. All of these answers definitely describe either the elements of SOA or the components used for the implementation of SOA. One of the technology paradigms that does not instantly come to mind though is "business rules."

The association of business rules technologies with service orientation is rather new, although the technology itself has been around for a while. Business rules and process orchestration make a rather interesting combination. A few years ago the two areas had substantial overlap, and in a project it was sometimes hard to determine which one to use to solve which problem. A couple of years back a client had engaged us in a project that involved a rather elaborate proof of concept to determine whether the combination of process orchestration business rules made sense in their organization. The project was part of a larger initiative to service enable their legacy applications. Since the whole team was new to the technology, often questions arose regarding what to model where. The process orchestration vendors provide the ability to execute conditional logic within the process. Of course, this should be limited to logic that is routing, branching, etc. - not logic that is associated with actual calculations, decisions, and complex computations. The BRMS (Business Rules Management Systems) vendors, on the other hand, allow you to do the opposite - execute flows in the midst of processing complex logic. What can't be achieved (in either product) through the basic constructs can be done by using the programming language and scripting plug-ins that are available.

The market has matured quite a lot since then. It is not that the features have been removed - indeed, the products offer more, not less. It is just that the space that is occupied in the tiers of an SOA is much more clearly defined. Process orchestration is for the orchestration of business logic (implemented in SOA as discrete services). It allows us to separate the actual execution of the service from the context in which it is executed.

The service that is orchestrated through process orchestration performs business logic. If that business logic is composed of complex computations based on decisioning, it lends itself very well to the paradigm of business rules. All of the business rules engine (BRE) vendors in the market specialize in modeling such logic during design and executing it very efficiently during run time. Also, the interface to this logic is accessible as a well-defined service in an SOA. If you are designing a business process, essentially you will end up with discrete tasks. The tasks that lend themselves well to complex conditional logic are excellent candidates for business rules. BREs also provide powerful features for designing and modifying the rules in "business terms," which helps an SOA achieve the business agility objective.

Thus the question that may come to mind is: Why don't we see business rules mentioned whenever there is a reference to SOA - such as orchestration? Well, though business rules can be used to implement services in an SOA, they are applicable to a certain kind of service. In other words, there are other paradigms for creating services - object-oriented programming language constructs constitute one of the most prevalent. On the other hand, process orchestration orchestrates all services, whether they are business related or not.