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 fall into three general categories:
- 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
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
5for packages that weigh between one and five pounds and have volume less than nine cubic feet.
Figure 2. 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.
- 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.
- 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.
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
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
getDiscountcalculation 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.
Figure 4. Business rule group comprised of rule set(s) and rules
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
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:
- Each business rule group defines zero or more service references, according to the SOA. The service references specify required service specifications.
- 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.
Services interact in two primary ways; both of these also apply to rules:
- Request-response style -- synchronous invocation by client services. A client invokes a service that may produce a synchronous result.
- 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.
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.
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
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.
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 style | Event-handling style | |
|---|---|---|
| Stateless | Sequential rules or inference rules | Event correlation rules (simple pattern) |
| Stateful | Inference rules | Event 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.
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.
Learn
- Learn about the IBM programming model for SOA in Part 1 (developerWorks, June 2005) of this series.
- Get an overview of the component-based programming model in Part 6 (developerWorks, August 2005) of this series.
- Create an intelligent and flexible solution with BPM, Business Rules, and Business Intelligence: Business process analysis (developerWorks, October 2005) is the first in a series of articles that looks at scenarios for creating flexible, dynamic business solutions through the integration of business process management, business rules, and business intelligence.
- Read WebSphere Process Server: IBM's new foundation for SOA (developerWorks, September 2005) for a summary of the main features of WebSphere Process Server and to learn how it supports SOA.
- Visit the WebSphere Process Server product site to get started with the runtime WebSphere Process Server.
- Check out the WebSphere Integration Developer site for a description of the key development tool for WebSphere Process Server.
- Get product documentation for both WebSphere Process Server and WebSphere Integration Developer at their Information Center.
- Visit the developerWorks SOA and Web services zone for extensive how-to information, tools, and project updates on SOA and Web services technologies.
- Browse all the SOA and Web services articles and free SOA and Web services tutorials available from developerWorks.
Discuss
- Participate in the discussion forum.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Mark 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.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
