A decision service is a service operation taking decisions, and in the context of this article, implemented using business rule engine technology. There a recent tendency to use the term decision service everywhere even on unrelated product features use such term. This may not help to adopt best practices for decision service design and implementation and may confuse the users. Another tendency is to use some features blindly, short cutting the design and considerations of what decision service needs to be in SOA, forgotten the years of SOA practices. This article does not pretend to solve all the problems, but at least should help to design and implement such services in the context of sustainable architecture.
The use of business rule engine technology to support the implementation of decision service, brings transparency and encapsulation of the business logic within the service. It is possible to change this logic very often and without redeploying a business process, or any business application. Using WebSphere Operational Decision Management (also known as ILOG Jrules), business analysts are able to maintain the rules themselves.
The life cycle of such logic is very different from a workflow (BPD in IBM BPM 7.5.1) or a service orchestration (BPEL or mediation flow in WESB). It is possible to change the business rules on a daily basis, which is not thinkable for a business process definition, or a reusable service. As a business service, decision service should promote reuse for any consumers, and not only one, for example, a business process.
One basic example of decision service, is data validation, where business requirements constraints the data. The decision is to log issue, or/ and reject the business transaction. In a claim processing the “validate claim’, or “adjudicate claim” are examples of such decision service. Approving a loan, an insurance policy, assessing a fraud are decision services. Externalized from the core application logic, decision service is a service provider, consumable by a business process application but also by any other applications. Rule processing is data oriented, and process a large scope of data elements to take decision, where a BPM product is flow oriented, and carrying minimum information. The two technologies are orthogonal. Tendencies to group the two technologies into the same product do not help, and confuse the industry. We will start some posts to present the design considerations and the implementation best practices using WebSphere Operational Decision Management (WODM). IT Architects and developers have to address questions such as:
- How do I identify decision service?
- What kind of decisions the business is taking?
- How do design the decision service?
- What are the object model needs for the rule processing?
- Should I design my service from the business process, using a top down approach?
- Does my ruleset signature is my service?
- Where the data are coming from?
- What is the frontier of my service definition?
Also using product features blindly, developers may go to dramatic implementation, with poor performance, poor maintainability, or quick and dirty solution.