One ring to rule them all?
by CBDi Forum
Web services are about automation of processes internal and external to an enterprise, to allow server to server interaction generally without human intervention. The potential upside is more efficient processes, instant response to events and lower resource effort and costs in straight through processes. However the downside is that the impact of errors may be magnified, as they continue unnoticed with loss of revenue or security. You may recall the Kodak case where an administrative glitch in pricing cameras stimulated large numbers of people, alerted by third party newsgroup and e-mail broadcasts, to buy at ridiculously low prices supported by an automated e-commerce system that continued blissfully unaware of the error.
Rule-based service behavior modification
Several of the new service management tools have implemented rules-based logic processors that enable variable service behavior. Using the CBDI differentiated service pattern, rules are set to select different services and or set parameters of the selected service, depending on the context of the transaction. It was popular last year to refer to such devices as smart services.
These same rules processors can also be put to many different purposes. They could conceivably implement monitoring rules which would have prevented Kodak's well-publicized losses. They could be used to implement multiple functional versions from a common set of services, perhaps supporting many different enterprise implementations from a common set of services, enabling the ASP to achieve significant reductions in cost while offering adaptable functionality.
Background to business rules
Although business rules have been proven by some, they are not widely accepted and there is little consensus about what business rules are, what they look like, how they can and should be used. There are several well established rules-based products that have demonstrated the benefits of declarative approaches to specification. However, whilst there has been some progress in developing an XML-based rule interchange format Business Rules Markup Language (BRML), modeling techniques and notations remain very immature. Although business rules should be an excellent requirements specification vehicle, business rule models are generally not accessible to users.
But for organizations implementing rules-based service management tools, it will be critical to decide what type of rules will be implemented where. If business rules are implemented in the service management layer, which may also be modified on a dynamic basis, how do these relate to business rules that have been implemented in the application providing the service?
Of course this issue exists irrespective of whether you have implemented an explicit business rules based architecture, or whether the business rules are inherent in the application code. In both cases there is almost certainly a lack of transparency because there are many different approaches to business rule implementation, which span modeling, application design and construction, process design and deployment and more recently service choreography and management. Also whatever your approach, it's hard to see how business rules are reflected in architectures, system designs and technical mechanisms, and hard to trace business rules against specific components and services, hard to align rule management with configuration management. Also it's surprisingly hard to bridge genuine business rules with the technical policies that are supposed to implement them.
Business rules management
The management of dependencies between rules has been a subject of great debate within the rules community over time. Because rules are implemented in many different places it's easy to imagine a rule implemented in one product based system saying that customers that score less than X will not be granted credit, while another product-based system says that customer who score more than Y will be granted credit. Now the introduction of service management layer rules introduces yet another place where we may define rules, and the opportunities for inconsistency will be legion.
A good place to start is with a classification system that determines types of rules and where they will be implemented. Commence with a basic classification of rules covering relationships, derivations, constraints, etc. Then move on to map these to your macro services defining applicability. This basic framework provides a basis for defining policy for rule implementation. A key objective is to identify dependencies so that rules can be implemented in a decentralized and federated manner, and to allow you to address the problem on an incremental basis.
In this way you are hopefully making intelligent decisions on what rules are implemented at the service execution layer, and how these inter-relate to existing rules structures, irrespective of whether these would be recognized as "rules-based systems" or not.
In our report Rule Based Development, published in the July/August CBDI Journal, we provide the basic framework for defining the different types of business rules and highlight where they can be used to good effect, and how they should be managed. We would anticipate that many companies moving to embrace rules approaches in general, and service based rules processors in particular will benefit from developing their policies based on derivations of this framework. Report available to Silver and Gold members at:
You can also get this report by purchasing a copy of the July/August CBDI Journal on our Report Sales page at:
Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.