Real World SOA and Decision Services - Part 1
Published by Rajgo August 9th, 2007 in Business Rules, BRMS, Business Rule Engine, Business Rules Management System, SOA, Web ServicesThis is the first of my 3 part series on real world SOA and rule driven decision services. I am going to essentially talk about the following items
- What you need to know about a Decision Service ?
- The implementation landscape including actors and roles, technologies and skill sets. What are the typical challenges that might arise when using rule driven Decision Services in an SOA
- What Kind of a Solution should you need to look for when you need a Decision Service?
Decisions and software Automation
There are many business decisions that can never be automated, like say a hiring decisions. But many others can be. Some examples of business decisions that can be automated are
- What is the Severity Level of a Support Request?
- Is an applicant eligible for a Loan?
- What is the risk factor for a specified loan applicant?
- How much discount to give a specific buyer?
- How should a marketing campaign be structured for best results?
- How much commission should be given to sales force personnel
Some of the ways to automating these decisions
- Write a java/j2ee/.NET module that will provide the decision making functionality.
- Keep decisions close to data and implement them as stored procedures in the database
- Use a scripting language like Ruby, and build a DSL
- Use a BRMS, externalize the business rules that drive the decisions, and use a rule engine to execute these rules
When it comes to Decisions, plain Automation is not enough
Plain vanilla automation is not enough when it comes to automating business decisions. The reason being that
- The rules that drive decisions change because of business requirements change
- The rules might change often and follow a different change cycle than the rest of the system1
- IT personnel maintaining the software system will not be knowledgeable in these rules.
So, a Decision Automation design must be built to accommodate these regular changes to the rules. As you can see, managing changing requirements and accommodating changes quickly must be a design criteria.
So, the assertion here is that what we need is Decision Change Management, and not just Decision Automation
Introducing the Rule Driven Decision Service
Using a rule engine can be the best solution for many situations to implement Decision Change Management. Please refer to Automating Decisions using a Rule Engine for a better treatment of the subject.
So, this is how you do it with a rule engine.
- Step 1: Define a Service interface for the required decision.
- Step 2: Implement the Service such that it internally uses a rule engine
- Step 3: The “how to take a decision” criteria, you implement as rules
- Step 4: Manage your rules using a business rules management system
The Service interface can then participate in any kind of an orchestration.An example of a Decision Service could be a Discount Service
- A Discount Service will compute and return a discount for a given buyer based on his past history
- The Discount Service will internally use a rule engine to deliver the decision
- Users of the Discount Service will see it it as a Stateless, and Reusable Service/Module
- The rules will be managed using a business rules management system
In the Next Post
The implementation landscape including actors and roles, technologies and skill sets. What are the typical challenges that might arise when using rule driven Decision Services in an SOA



















No Responses to “Real World SOA and Decision Services - Part 1”
Please Wait
Leave a Reply