What is a business rule and what is the connection to business Processes? A business rule is a statement how the business is done. It can be a law or custom that guides the behaviour or actions of members of a company. And it can be a companies policy that must be fulfilled. In each of these cases a business rules guide business processes. A typical result is the process of a loan approval - the result can be "yes", "no" or "better ask a human being".
Business rules are an important part of business processes but there are several other things that must be considered: social interaction and different organizational units.
At the level of a software system there a several ways to implement those business rules:
- Constraints (for instance assertions),
- derivation rules we know from logical programming languages and
- reaction rules (if a certain events occurs do something).
In one of my last blog entries a gave an example for an ABAP to ABAP transformation using XSLT. As an example I mentioned that verifying an information against a business rule can be implemented as validation against a schema perhaps formulated in Schematron. Having a Schematron implementation in XSLT we could use XSLT as an inference engine for business rules. But we can do much better:
- we need special languages to code business rules in terms of a certain logic,
- we should be able to use a certain domain specific vocabulary perhaps using RDF vocabulary,
- we need an inference engine for this logic.
In today’s integration scenarios nearly everything is coded in XML: the data we work on are coded in XML, the services we use are described in XML, we call the services in XML. So it is a natural approach to code the business processes in XML like we do in BPEL. Of course business processes rely on business rules. This blog entry is about coding business rules in XML. With these techniques we can separate this part of application logic from the rest the software system. If we do it we hope that
- the software is more flexible and better maintainable and that
- business experts might be able to implement business processes perhaps using a graphical tool.
There are several languages you can use to express business rules:
- Business Rule Markup Language (BRML),
- Agent-Object-Relationship Markup Language (AORML),
- Universal Rule Markup Language (URML),
- Artificial Intelligence Markup Language (AIML),
- Case Based Markup Language (CBML),
- Relational-Functional Markup Language (RFML),
- eXtensible Rule Markup Language (XRML) that is used in the context of semantic web.
If you use one of those languages you will need an (inference) engine or a code generation tool like Visual Rules or JRules from Ilog. But please be aware that additional components may be necessary, for instance tools for managing rules (often tools from knowledge management are used for this task).
XRML may be very exotic in the context of business rules but I chose to express the fact that a lot of different communities work on rule based languages using XML: the semantic web community often uses agent-oriented methods but there influences from artificial intelligence as well as workflow management. In the context of the semantic web we integrate processing rules in web pages so that these rules are understandable for human beings as well as for software agents. Therefore we need
- a method to express meta-information about rules (XRML uses the Rule Identification Markup Language RIML for this task),
- a method to transform the rules in a format understandable by the inference engine (XRML uses the Rule Structure Markup Language RSML therefore) and
- a method to for defining triggers if rules are integrated in software agents, workflow managements systems and so on (XRML uses the Rule Triggering Markup Language RTML).
Software Methodology Issues
In software engineering we do modularization to separate the concerns in our programs. We hope that we are able to increase the flexibility of our programs as well as robustness. If you start to code your business rules in a formal language you create an expert system and therefore it is not unlikely that you will have the same problems that most expert systems have: once they are created it is hard to change them. Some months ago I got in contact with programmers to chose to use Prolog as programming language and I had to listen to their problems doing even small changes because they could not predict the consequences of a change.
This is not unlikely because a local change of a certain can have global impact. So how can we minimize the impact of a local change and introduce separation of concerns? Most important is grouping of business rules so that every group contains only rules of one single area of knowledge. Then we have to identify inter-group facts - these are the ones who widen the impact of changes within one group to other rules.
In my opinion formalization of business rules needs more than expertise in gathering requirements and modeling business processes - we also need tools from knowledge management if the knowledge base gets huge.
And what about BPEL?
BPEL was made to code business processes in a way that web services can interact like business partners. So you can think of BPEL as a workflow specification language but without interaction. We can use XPath expressions for instance to compare variables to guide the business process. Just look an example of loanarroval.bpel von the BPEL4WS 1.1 specification:
<receive createInstance="yes" name="receive1" operation="approve"
partnerLink="customer" portType="apns:loanApprovalPT" variable="request">
<source linkName="receive-to-approval"
transitionCondition="bpws:getVariableData('request', 'amount')>=10000"/>
<source linkName="receive-to-assess"
transitionCondition="bpws:getVariableData('request', 'amount')<10000"/>
</receive>
In this example we do a case distinction by checking the amount of a loan approval request against the constants value of 10000$ and guide the process flow with respect this result.
In BPEL 2.0 we can use XSLT for variable transformations by the new XPath extension function bpws:doXslTransform. We can use those techniques to transform variables and compare them to control the flow of execution, but for coding business rules in the sense above it is not the right tool.
If you are new to BPEL I suggest to download an Open Source engine to play around. Just do the following steps and soon you will be able to run and modify sample business processes. But please be aware the difference between process integration using web services and building of rule based systems which was the topic of this blog entry.
Summary
This blog entry was about coding business rules in XML. Fpr most of these languages there are either open source or commercial Java tools.
