There are three basic approaches. To illustrate, imagine a rule service that determines if a company will accept a transaction from a US customer. In the initial and most simple version, the company policy is to refuse a transaction from any customer under the age of 21. Age is the only decision criteria. In a future version of the same service, the decision criteria becomes more complex when it is determined that the threshold age should vary based on the customer’s US state of residence.
Small, fast, and simple
In this approach the rules service interface contains only the data required by the service to perform the implemented decision point. The structure of the data in the interface is flattened with respect to the decision point implementation and attribute names represent the business decision criteria. The objects in the interface can be used directly in the rule BOM and the default verbalizations will likely be sufficient. No additional mapping of data is required. Marshaling/de-marshaling and transport overhead is kept to a minimum allowing very rapid service response. In later versions of ODM[iii], a REST implementation becomes a viable option with a small number of specific input attributes related to the decision and low transportation overhead. This approach is fast to implement, execute, and easy to change in initial development, but is the least flexible to future change once deployed. Any future additional data requirement in the decision point will require an interface update to accommodate the change. This technique is best used to quickly develop a rule service with rapid changes to the decision criteria while still in development.In our example to identify customers below the age of 21, the interface initially may only consist of a customer identifier and the customer’s birthday. However our future implementation that observes the customer’s US State of residence will require a service interface change to add this attribute. Concurrent execution of old and new versions of the rule service requires strict versioning of the WDSL and therefore the rule app / rule set.
Enterprise Data Model
In this approach, the rule service interface consists of the entire enterprise data set that may be used to perform the implemented decision point, even if most of the data is unobserved in the initial rule implementation. In other words, the caller passes everything it currently knows about the subject of the decision in the event future rules might need additional information. This approach provides a more comprehensive data interchange, but is limited by the quality of the data model. This approach is most commonly used with vertical industries that have a well defined and widely accepted object model such as those defined by standards bodies such as ACORD, MISMO, EDI Standard formats, HL7, et al. The objects in the interface typically contain several levels of hierarchical data and maps poorly to a flatter, business-oriented BOM desirable in business rule implementations. This commonly necessitates at a minimum custom BOM verbalizations, and frequently mapping of the interface object to a flatter and less normalized form; all adding to the time and effort in rule implementation. However, the advantage is that future rules are less likely to require an interface change IF the enterprise data model is complete, stable, and universally accepted. Because the interface is typically large, in the case of most SOAP web services and message-based architectures, marshaling/de-marshaling, transportation overhead, and remapping become the overriding performance constraints rather than rule execution times.Using our example rule service implementing a decision point to identify customers below the age of 21, the initial interface would consist of everything about a Customer tracked in the enterprise data model. This will likely include the customer’s birthday allowing age to be derived. When the service needs to expand in the future, allowing the age threshold to vary by customer location, no interface changes will be required if the enterprise model already includes the US state of the customer’s residence. A ‘rules-only’ change can be made to add BOM mappings for the newly required attributes and the rules written using these new attributes. This approach should be avoided if the enterprise data model changes frequently or is unlikely to include future required data elements. Frequent changes in the enterprise model result in changes to the rule service interface even when the model changes do not affect the current rule implementation in order to remain consistent with all rule service consumers. And using this technique requires all consumers and rule services to implement the same version of the enterprise model. If the data model is unstable, managing this dependency alone can negate any flexibility gained with the more comprehensive initial interface.
Generic Key/Value Pairs
In this approach, the rule service consists of a generic list of key/values pairs commonly implemented as a Map or map-like structure. The ‘key’ is a string describing a business attribute name and the ‘value’ is the value of that attribute. This allows any data to be passed to through the rule interface without structural changes in the rule service interface itself and represents the most flexible interface style. Using the previous example of a rule service determining transaction acceptability based on customer age, the interface could initially have a list of keys ‘customerID’ and ‘customerBirthDate’ with their corresponding values. If in a future version, customer location becomes required, the caller would simply add a key ‘customerLocation’ to the list in the interface and provide a value for this information to the rule service in the granularity required. However, the rule service needs to be aware of all the possible key values. These are typically maintained manually as a static or dynamic enumeration in the rule source so business attributes may be properly mapped to BOM vocabulary. This has a distinct advantage over the enterprise data model scenario in that only the data required in any given version of the service is actually passed through the interface to the rules. This keeps marshaling and transportation overhead low, but still allows for new data to be added without changes to the structure of the rule service interface.However using this approach means it is more likely that the callers of the rule service will need to make corresponding coding changes to support future data requirements in the rule service. This will often invalidate the advantage that the rule service may be changed without java code alteration. An additional concern with this approach is the loose typing and late binding of the interface elements. While this provides flexibility in the data passed, it effectively places additional run-time validation requirements on the rule service to ensure that the interface data expected is actually provided and typed correctly. Finding the rule service implementation out of sync with the implementation and expectation of multiple consumers is a common problem with this approach.
--------------------------------------------------------------------------------
[i] Operational Decision Management, formerly known as IBM ILOG JRules or WODM, WebSphere Operational Decision Management
[ii] Hosted Transparent Decision Service, a feature of IBM ODM that exposes a ruleset as a SOAP Web service
[iii] REST API supported in ODM V8.5 and later
Written by Lawrence Terrill, Technical Lead, Prolifics Business Decision Management Practice
