SOA programming model for implementing Web services, Part 9: Integrating rules with SOA

This article reviews how business rules integrate with the IBM Service-Oriented Architecture (SOA) as a component type, bringing advantages in business agility and alternate execution models that complement the features of other component types. You'll learn about three general rule categories -- sequential rules, event correlation rules, and inference rules.

Share:

Mark Linehan (mlinehan@us.ibm.com), Senior Technical Staff Member, IBM

Author photoMark Linehan is a Senior Technical Staff Member in the IBM Software Group Emerging Technologies department. During the past few years, he’s worked on business rules technology. Previously, Mark developed cryptography-based communication protocols and designed and developed various communications software. Mark holds an MS in Computer Science from Columbia University and a BA from Case Western Reserve University.



29 November 2005

Also available in Chinese Vietnamese

Introduction

SOA accommodates a variety of component implementation types, such as plain old Java™ objects (POJOs), Business Process Execution Language (BPEL) processes, business state machines, and many others. Part 1 of this series introduces SOA concepts, and Part 6 describes components as key aspects of SOA.

Developers implement service components using any of a variety of different software technologies, or component types. Some services benefit from implementation using the business rules component type, because rules offer useful solution characteristics. One purpose of this article is to summarize the various categories of business rules and show how a single approach to integration with the IBM SOA fits different kinds of rules.

All component types, including rules, fit a single solution composition model, the SOA. One key benefit of SOA is the ability for business integrators to substitute one component implementation for another without affecting the rest of a business solution. A second objective of this article is to review how business rules, when implemented according to the SOA, achieve this benefit.

In SOA, services may interact with each other synchronously or asynchronously with only request messages or both request and response messages. This article also aims to describe the ways different categories of rules interact with the various service interaction styles.

Business rules

Business rules fall into three general categories:

  1. Sequential rules provide declarative rules executed sequentially. This rule category supports business agility by enabling nonprogrammers to maintain the rules.

    This category includes if-then statements and decision tables.

    Figure 1. If-then rule
    If-then rule

    As the name implies, each if-then rule consists of a Boolean expression that determines whether to execute one or multiple actions specified in the then clauses. These actions may compute rule results, assign values, or invoke other services. In Figure 1, an if-then rule assigns a shipping and handling charge of 5 for packages that weigh between one and five pounds and have volume less than nine cubic feet.

    Figure 2. Decision table
    Decision table

    Decision tables provide compact visualizations of orthogonal conditions. They are equivalent to multiple if-then rules that test the same condition terms for different values. Figure 2 shows a decision table that assigns shipping and handling charges for various combinations of package weight and volume. The shipping and handling charge is $7 for all packages with volume larger than 9 and for packages with weight greater than 5. For packages with volume less than 9, the charge is $2 when the weight is less than 1 and $5 when the weight is less than 5.

    The primary benefit of sequential rules is the potential for business analysts or other nonprogrammers to administer the rules. This comes from the easy-to-understand forms of sequential rules supplemented by tools that simplify rule maintenance.

    A secondary benefit comes from implementing rules as separate service components in SOA. The separation of the rules from other services enables the rules to be updated without affecting the other services. Most rule implementations permit dynamic update of the rules, enabling changes without the usual development-and-deployment cycle required of other component types. The combination of these benefits brings significant agility to business rules implementations, permitting the rules to evolve with fewer IT-based constraints.

    IBM WebSphere® Process Server and IBM WebSphere Integration Developer support if-then rules and decision tables, thus bringing these benefits to their customers in the context of SOA.

  2. Event correlation rules recognize relationships across multiple events occurring over time. These rules typically filter messages by type and condition within some time window and then detect situations according to various predefined patterns. Event correlation rules are used to recognize IT or business event situations in sequences of messages or events. For example, produce an alert if "check customer rating" service generates more than 10 SOAP faults within 1 minute.

    IBM Tivoli® Enterprise Console uses event correlation rules to recognize patterns in events generated from multiple sources in a given time period. The rules make it easy to identify situations that matter in IT or business monitoring, reducing what would otherwise require much manual effort or programming to create fairly simple rule statements.

  3. Inference rules implement forward inferencing, backward chaining, Prolog-style unification or other artificial intelligence (AI)-style rules. Use cases that benefit from inferencing are those that involve many interdependent rules whose execution orders must depend upon data instead of being predetermined. Resource selection, optimization, problem diagnosis, and planning problems often need some style of inference. These problems involve searching among many potential solutions to find those that satisfy the rules.

Rule sets

Most rule systems group rules in rule sets that are predefined in tools or dynamically composed at run time. Rule sets contain lists of rules that jointly evaluate some set of inputs and produce one or more results. Decision trees provide an alternative representation of sequential if-then rule sets.

Figure 3. Rule set
Rule set

Figure 3 shows a rule set with two if-then rules. The interface section documents the inputs and outputs of the rule set. The first rule charges $2 for packages that weigh less than 1 pound and are smaller than 9 cubic feet. The second rule charges $5 for packages between 1 and 5 pounds with volume less than 9.

Each rule set implements a single operation of an interface, realizing the operation’s purpose (per the operation or method name) and signature (parameters and result). Thus, each rule set fulfills the role of an individual operation in the SOA.

There are numerous advantages to this approach:

  • The client service is agnostic to how the service is implemented -- whether rules or some other implementation technology -- and to which rule category is used, when there is a choice. This means the client can be wired to alternate service components at different installations or over time, thus providing you a degree of configuration flexibility.
  • The usual benefits of type safety as enabled by service contracts.
  • Programming model simplicity -- no special API just for calling rules.
  • Process choreography engines can invoke rules just like other services. An engine doesn't need to be aware that particular operations are implemented using rules.
  • Reuse of existing container features, such as access control and transaction management. For example, in the solution design, it might be important that a getDiscount calculation participates in the same database transaction as the rest of the client application. Invoking rules just like any other service type makes container features applicable to rules.

Business rule groups

Figure 4. Business rule group comprised of rule set(s) and rules
Business rule group

As depicted in Figure 4, services can provide multiple operations, whereas a rule set realizes a single operation. Business rule groups package multiple rule sets that jointly implement all the operations of a service. From the service wiring viewpoint, the business rule group is the component "wired" into an application. Thus, a business rule group packages multiple rule sets into a service that exports a provided interface that may be referenced by other services.

For example, a business rule group might realize a Customer Relationship Management (CRM) interface containing calculate discount and calculate shipping operations by including a rule set for each operation. If a service client is wired to a business rule group that uses the rule set in Figure 5, then the rules execute when the client invokes the calculate shipping operation.

Figure 5. Business rule group shell bridges SOA service to rules engine
Business rule group shell

Each business rule group supports the operation signatures defined in a provided interface, thus enabling type safety. Typically, tools generate the business rules group as shell code that implements the operation signatures, captures the incoming parameters, and passes them to a rule engine in some engine-specific manner. The shell code solves the mismatch between application-specific operation signatures and the application-independent interfaces of many rule engines. Figure 5 illustrates that the shell code provides a bridge between the client and the rule engine, enabling the client to invoke the rules as a service and enabling the rule engine to participate in the SOA.

Invoking other services from rules

Business rules often need to invoke other services, either as part of test conditions (such as "'if moon.getStatus() == "Full" …') or to invoke actions, such as sending e-mail. We model this in two parts:

  1. Each business rule group defines zero or more service references, according to the SOA. The service references specify required service specifications.
  2. In Figure 4, rules belong to rule sets that belong to rule groups. Rules may invoke any of the services referenced from the business rule group that indirectly "owns" the rules.

This approach enables a development lifecycle where the relationship among rule groups and other services is defined earlier than the actual rule sets and rules that use those services. An application may be defined and wired at implementation or deployment, while the rules may be managed in running systems.

For example, some business rule group might refer to services A, B, and C. At some point in time, rules within that rule group might actually invoke service A, while at another time, the rules might also invoke service B. The rules cannot invoke service Z because that service is not referenced by the business rule group.

Invocation styles

Services interact in two primary ways; both of these also apply to rules:

  1. Request-response style -- synchronous invocation by client services. A client invokes a service that may produce a synchronous result.
  2. Event-handling style -- asynchronous message processing, as found in IBM WebSphere Enterprise Service Bus. A client sends a message to a service in a fire-and-forget style. The service passes a response -- if there is one -- back to the client via another asynchronous message.

The request-response style is covered first, because the event-handling style builds upon the request-response style.

Request-response style

In the request-response invocation style, a client service invokes an operation that happens to be implemented through rules. The context for the rules is the arguments passed from the client, plus any static data or services accessible to the rules, plus any state maintained within the rules. As with any operation, the rules perform some computation and may return a result to the client. The rules may also cause some actions or other side effects by invoking other services.

With SOA, all operation signatures are usage specific. Thus, the inputs, result, and name of an operation that calculates discounts would be entirely different from an operation that validates a driver’s insurability. The designer of each application specifies the inputs passed to rules and any result expected from the rules; there is no special API used to invoke rules.

Event-handling style

In the event-handling style, a rule set asynchronously processes a stream of messages, as shown in Figure 6. The rule set examines each message one by one and may take some action (by invoking another service) or may generate an outbound message. Typical applications include responding to business situations, auditing business events for irregular conditions, and monitoring IT events for problems. Rules technology simplifies such applications by making it easier for users to define the message processing without requiring as much programming expertise.

Figure 6. Business rules and the event-handling style
Event-handling style

The event-handling style builds upon the request-response style described previously. The business rule group receives each incoming message and invokes a rule set. Typically, the rule set receives the incoming message as an argument and returns no result (because of the asynchronous processing environment). The rule set produces output -- if any -- by invoking another service, which may or may not be associated with any of the message sources. Thus, from the perspective of the rules technology, the differences between the event-handling and request-response style are environmental rather than intrinsic. The rules execution model does not vary for the two styles; the distinction shows up only in the signature of the interface used to invoke the rule set and the interactions between the rule set and the client applications.

Stateless versus stateful rules

As with other service implementation types, business rules may be either stateless or stateful, meaning they may choose to maintain internal data records across multiple invocations. Rules keep state to extend their context across their history of invocations, enabling decisions or computations that consider more than just the arguments passed on the current invocation. Examples of stateful rules include most event correlation rules and some uses of inference rules.

The relationship between state data maintained within business rules and the client service is application specific and not addressed in the architecture. Typically, the rules use one or more invocation arguments to address the appropriate internal state.

Any state maintained within rules should be persisted to support the clustered configurations and high availability requirements typical of most business configurations. Enabling the flexibility provided by rules along with scalability and recoverability can be a significant challenge for many rules systems.

Typical usage patterns

The previous discussion outlines two basic rules invocation styles (synchronous request-response style and asynchronous event-handling style) and distinguishes stateless versus stateful processing. Any rules type (as discussed previously) may be used with any of the four possible combinations of invocation style and of stateful versus stateless execution. The following table identifies the most typical use patterns:

Table 1. Typical usage patterns for business rules
Request-response styleEvent-handling style
StatelessSequential rules or inference rulesEvent correlation rules (simple pattern)
StatefulInference rulesEvent correlation rules (complex patterns)

The table identifies the combinations that make the most sense according to the features of each rule type. Other uses are certainly possible. For example, substituting sequential rules or inference rules for stateless event handling would provide functionality equivalent to the simplest type of event correlation rules but lose the ability to extend the rules smoothly to true multi-event correlation. As another example, you could apply inference rules to stateful event handling to make inferences about message sequences. Application requirements and tools capability determine the best choice in each situation.

Summary

This article summarizes three general rule categories and describes how they integrate with the SOA -- regardless of:

  • Whether the rules are stateless or stateful.
  • Whether the invocation style is synchronous request response or asynchronous message based.

The integration approach described here treats rules as a first-class service component type, joining the menu of technologies alongside other choices, such as plain old Java code, business processes, and state machines. For developers of service clients, this means that rules are invoked just like other services, without special API considerations. For overall solution developers, this creates the ability to mix and match rules with other implementation types, applying the most appropriate technology for each component in an overall solution.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=99337
ArticleTitle=SOA programming model for implementing Web services, Part 9: Integrating rules with SOA
publish-date=11292005