Implementation of business rules and business processes in SOA

One of the main drivers for using of the Service Oriented Architecture (SOA) is to increase enterprise agility and minimize the impact of inevitable changes. This is typically achieved through separating the implementation artifacts that change often from the ones that are fairly stable. Common techniques to support such separation are decomposition and encapsulation. In the case of SOA decomposition leads to the definition of services, representing more stable artifacts, and business processes, representing more fluid ones [1]. In a typical SOA implementations, services do not change often, but are composed and recomposed fairly often to build/modify enterprise solutions.

Such decomposition does not directly address the positioning of the business rules - another frequently changing component of the overall IT implementation. Based on the fact that business rules can change fairly often, one of the widely adopted practices is associating them with the business processes - more frequently changing SOA components. The popularity of such an approach is additionally backed by the fact that many practitioners consider business rules as part of the broader business process management (BPM) picture and tend to bundle business rules and business processes together ¹. As a result many consider business rules engines and business process engines as two competing technologies for business processes/business rules implementation. This is based on the following popular misconceptions:

• Business rules and business processes are sharing the same design and implementation model.
• Business rules and business processes deliver the same artifacts and can be used the same way.

In this article we will outline commonalities and differences between business rules and business processes and present some guidelines on positioning business rules in SOA implementation and appropriate usage of each technology.

Business rules

"Business rules describe the operations, definitions and constraints that apply to an organization in achieving its goals. These rules are used to help the organization to better achieve goals, communicate among principals and agents, communicate between the organization and interested third parties, demonstrate fulfillment of legal obligations, operate more efficiently, automate operations, perform analysis on current practices, etc" [2]. Business rules can be viewed as a collection of business practices, defining the actual implementations - business logic. Implementation of such logic can often be simplified through the usage of specialized tooling - business rules languages and business rules engines.

A rules language is a domain specific language, containing constructs for defining of the business rules. These constructs can vary greatly depending on the business requirements. The scope of possibility ranges from a textual description (using a rule specific language or plain English) to the use of decision tables or decision trees. In some cases, it is also possible to graphically determine the sequence of execution of those business rules using a rule flow. The last one is often the cause of the confusion between business processes and business rules. Although they look similar, business process flows are defining the execution sequence of services which may run across many different and heterogeneous systems. On the other hand, business rule flows are limited to the orchestration of the rules execution sequence.

Sidebar. Domain Specific Programming Languages

"A domain-specific programming language (DSL) is a programming language designed to be useful for a specific set of tasks. This is in contrast to general-purpose programming language (GPL), such as C, Java, C#, etc."[3]. DSLs are typically tailored specifically to a specific problem domain. As a result it captures precisely the domain's semantics. In order to further simplify their usage, DSLs are usually highly declarative and describe what needs to happen, rather then how it is done (the latter is responsibility of the language implementer). Because of this, DSLs often are considered (executable) specification, not programming languages.

The key advantages of a specific DSL are domain specific abstractions and notations as well a restricted (or rather focused) expressive power. There are several reasons that make DSLs more attractive than GPLs for some classes of applications [4]:

Easier programming

Because it is uses a higher level of abstraction, which is well aligned with a problem domain and defines what to implement, rather then how to do it, a DSL program is generally more precise (due to its alignment with the domain) and easier to implement and understand (not only by developers, but also by domain experts) compared to GPL implementation. This typically leads to a shorter development time and less expensive maintenance. Additionally DSLs are coming with high level debagging support, allowing for to analyzing and debugging code directly on the domain concepts level.

Systematic re-use

Reuse was always one of the ways of improving implementation of new applications and shortening development cycle. Although GPLs promote reuse through usage of standard and domain - specific libraries, their actual usage is left to the developer. DSLs, on the other hand, enforce reuse of the libraries that are utilized by the DSL implementation. Additionally, because DSLs are defined for particular problem domains, they capture and consequently reuse specific domain knowledge.

Easier verification

With advances in software engineering, formal code verification is playing an important role in successful development. While in the case of GPL, such verification only ensures that the code will execute, in the case of DSLs, due to their compactness and domain alignment, validation can often ensure that the code will produce correct results.

Increased cooperation

The use of the same business related semantics across the organization facilitates the sharing of the information and reduces the risk of mismatch between the business logic actual implementation and the business users' expectations.

Business rules engines support evaluation of rules expressed in a corresponding rules language. Their main functionality is to manage a collection of facts and to evaluate rule sets comprised of one of several predicates. Dealing with large numbers of facts and efficiently evaluating predicates is one of the key challenges of rule evaluation.

Based on the business rules definitions, expressed in the business rules language, business rules engines typically provide some mapping mechanism to generate lower level execution code - usually general purpose language classes. Those classes can be used as a partial implementation of a larger business component. An immediate consequence of such an approach is that the business rules' implementation lifecycle is aligned with the lifecycle of the business component to which they belong to.

Flexibility and modifiability of business rules implementations is achieved through the rules maintenance support enabling dynamic changes (using the original rules language). Such ability provides a convenient way to dynamically modify business rules without rebuilding and redeploying implementation to quickly adapt to changing business environments.

Declarative programming (i.e., prescribing the what) represents the paradigm of choice for rules: something gets triggered (i.e., an action) based on whether a rule evaluates to true or false. The control flow (i.e., the sequencing of these invocations) is implicit and emerges as the rules fire off.

Business Processes

"A business process is a set of linked activities that create value by transforming an input into a more valuable output. Both input and output can be artifacts and/or information and the transformation can be performed by human actors, machines, or both" [5]. Activities comprising a business process do not include any process-level decision making and are not worth further decomposing ².A business process definition can be viewed as a recipe for achieving a specific goal. Similar to the case of business rules, implementation of business processes can be significantly simplified using business processes DSLs and specialized business process engines.

Business process programming requires specifying the sequence and conditions of execution of process activities (control flow) and data exchanges between activities (data flow). Typical language constructs allow for defining a process either in the form of extended flowcharts or finite state machines.

The business process definition, expressed in a business process language, is typically directly executed by a business process engine. (An engine internally can either compile or interpret the business process language. The business process engine supports coordination of process activities execution and propagation of data between them. Managing of the simultaneous execution of multiple asynchronous process instances under resource constraints is one of the key challenges of business process engines.

As a result business process implementation is separated from the implementation of activities, orchestrated by a business process. This provides capabilities of introducing changes into business process with no or minimal impact to the underlying activities, thus providing a higher level of modifiability to the overall system.

Imperative programming (i.e., prescribing the how) represents the paradigm of choice for business processes implementation: something gets invoked after something else because the business process definition prescribes their sequence. The control flow is explicit.

In order to remain competitive a company needs to constantly change and improve its business processes. Factoring business processes out of the applications and using a business process language and engine for their implementation allows the simplification of the implementation and modifiability of enterprise business processes.

Decision considerations

Determining the right technology becomes critical when it comes to best supporting business requirements and achive the optimal architectural qualities. At the end of the day, assuming that appropriate DSL and engine are used, the implementation choice between business rules and business process paradigms depends on the two major factors:

• Capabilities of the appropriate engine
• Decomposition of the overall system.

When it comes to the capabilities of the rules vs. business process engines, the following should be considered:

• Synchronicity. Rules evaluation is synchronous, and Rules Engines are designed to evaluate business rules as quickly as possible. Processes, on another hand, are typically long running and asynchronous in nature. The strength of the process engines is the ability to support long-running processes, where actions can take a long time to complete. As a result they provide mechanism required to deal with asynchronous invocations, such as request/response correlation, compensations, etc.
• Statefulness. Rules engines are stateless; when a rule fires an engine typically pulls its inputs either from the input parameters or the knowledge base, evaluates it, and then either updates the knowledge base or propagates results to the output. Business process engines are specifically designed to hold the state of each active process instance, hydrate and store it between activities invocations and re-hydrate it for the execution of the next activity.
• Determinism. The Rules Engine fires rules whose conditions evaluate simultaneously. However, their ordering is non-deterministic. Business processes are, for the most part, deterministic ³, and people typically add checks and balances to ensure determinism.
• Granularity. Although the business rules themselves can be used at the company level, they are usually considered as components. As such, they provide a smaller granularity and offer a higher level of flexibility from a maintenance and deployment perspectives. Business processes on the other hand can be more viewed as stable assets that are less likely to go through drastic change over time.

As defined in [1], SOA design is based on the top down decomposition of the enterprise business model, defined as a collection of the top level business processes. In this approach (Figure 1) top level business processes define a set of activities, which constitute high-level business services. These services, in turn, are often considered to be processes, which leads to the recursive decomposition. Finally, services are implemented as a coordination of a set of components, which represent leaf elements of this decomposition.

Figure 1 Hierarchical decomposition

Different implementations of business components in this case may include "wrappers" of existing enterprise functionality ⁴ , new implementation using general purpose programming languages, business rules based component and orchestration based components.

Based on this decomposition approach above, the following usage of business process/rules are typically present in SOA implementations:

• Business processes implementing business services orchestration
• Business rules implementing business components, which are part of service implementations
• Business components, responsible for orchestration of other components within a given services.

Finally, not reflected in this decomposition is the case of using business rules for implementation of decisions in business process execution.

What is the appropriate technology?

Based on the above comparison of business processes/ business rules engines capabilities and SOA decomposition the following recommendations can be made for technology choice:

Service Orchestration

Service orchestration typically deals with long-running and asynchronous invocation of external activities/services. Today's business rules engines do not support these capabilities. Business process language/engine, designed specifically to define and execute long-running coordinations with asynchronous invocations is the most appropriate paradigm for the service orchestration.

Business components implementation

When it comes to implementation of business components a case of short - lived transactional implementations with only synchronous interactions - the line between business rules/business processes becomes blurry. Often the same problem can be defined and consequently solved with either technology.

Let's consider the example of claim handling charge calculation ⁵.The claim can be either subject to the flat handling charge, or loss conversion factor (LCF). In the first case the flat charge can apply to either claim as a whole or each suffix of the claim separately. The combination of these different options creates three distinct claim handling charge calculation rules. This rules set can be represented either as a set of rules (Figure 2) or as a process (Figure 3).

Figure 2 Representation of claim handling charge calculation using rules

Figure 3 Representation of claim handling charge calculation using process

As a result, based on the design-time paradigm, one might consider using either a rule set or a business process approach for solving the same problem.

• The advantage of using business process approach in this case is simplified support for invocation of external activities (services).
• The advantage of using business rules approach in this case is the ability to change rules without recompiling and redeploy of the business rules components and to reuse the implemented business logic at the component level (as opposed to the service level when dealing with business processes).

Implementation of business rules controlling business process execution

In the case when rules define the execution of business process itself, it is necessary to consider their complexity and change frequency.

Modern business process engines usually provide capabilities for evaluating simple rules, either built in the business process language or by invocation of general purpose languages. Thus it is entirely feasible to implement "simple" business rules in the business process engine. In this case however, any change in the rules will require a full testing and deployment of the business process. As for complex business rules, they typically need to be extracted from the process and implemented as a separate service, using a rules engine.

Another typical scenario is the one when the business process itself (process structure) is fairly stable, but the rules, governing activity transitions, although fairly simple, can change fairly often (see Figure 4). In this case externalizing rules implementation as separate services, implemented using a rules engine can significantly improve overall solution maintainability. The ability of business rules to support dynamic changes in business rules, allow, in this case, to modify business process implementation without changing and redeploying it.

Figure 4 Typical change of rate for services, processes and rules

Overall SOA implementation

Figure 5 shows typical usage of business process and rules engines in the SOA implementation.

Figure 5 Typical usage of business process and rules engines in SOA

As we can see from the figure above a prevalent pattern in SOA implementation is employment of rules engine as part of service implementation and the use of business process engines for service orchestration. In cases when rules control activities whose coordination is complex enough, or change much faster the process itself, so that they require usage of the rules engines, these rules are usually externalized as a special rules service, invoked by business process engine. Because this service invocation can be potentially expensive (network calls) some of the business process engines, for example Biztalk 2004 from Microsoft, WebSphere Process Server from IBM, Smart BPM Suite from PegaSystems and others incorporate both business process and rules engine in a single application.

Conclusion

Business process and business rules should not be treated as competing but rather as complementary technologies. Business processes define a set of activities that need to be performed in order to perform a business functions. Business rules provide a value add approach to implement those activities by offering a superior level of flexibility and configurability to adapt to rapidly changing business environments.

References