With any rule-based technology, rule-based processing involves three basic areas: the vocabulary that forms the language, the grammar for expressing the vocabulary in statements, and the rule processing engine. This topic describes the vocabulary and the grammar. The rule processing engine is reusable from common components.
Vocabulary consists of the operators, variable keywords known as operands, and control flow statements. The language of choice is the Java™ Message Service (JMS 1.1), particularly the Message Selector Syntax. The message selector is a string whose syntax is based on a subset of the SQL92 conditional expression. In this application, it expresses a classification rule. The general statement syntax is:
operand operator literalExpression [| compoundOperator expression] .
For example,
serverhost like '%ibm.com' or clienthost = 'myhost.raleigh.ibm.com'
In that expression, serverhost and clienthost are operands, like and = are operators, or is the compound operator, and '%ibm.com' and 'myhost.raleigh.ibm.com' are the literalExpression. The [] indicates that the expression enclosed within is optional, and the | indicates that after the operator, a literalExpression or a compound operator can be followed by more expressions. The result of an expression is an action that is taken. From a grammatical viewpoint, these actions are literals that are provided by a policy provider. Two types of policies are supported: routing and service policies. Therefore, the actions that are taken are dictated by the policy provider. For routing, the actions are permit, reject, redirect, and permitsticky. Each of the actions has the appropriate target; the recipient of an action. If the result of evaluating an expression is to take the action of permit, the target of that action is the application for which routing is permitted. For service policies, the target is encapsulated in the action, and the action is a transaction class.
A complete statement consists of the rule expression, and the action to be taken is represented differently depending on the input source. With the administrative console, the actions are separated into forms and fields that are easily selectable. If you are using scripting, the complete statement might look as follows:
expression<delimeter>action For example, clienthost='localhost' and serverhost like '%.ibm.com'?permit?DefaultApplication.ear
However, from an implementation viewpoint, work classes, which are XML documents, are used to capture the rules expression, matched actions, and other implementation artifacts. Therefore a work class is an XML document containing zero or more matchRules elements, and one or more workClassModules elements.
WebSphere® Extended Deployment supports the operators in the rules expressions. In general, you might not know the true data type of a given operand. However, you can follow the HTTP way of treating every operand as a data type string and use the operator as an indicator for the real data type of the operand for data validation purposes. An example of an operator which tests for an operand having a NULL value is: IS NULL.
An example of an operand for HTTP requests is: MIMEType.