Rule-based request classification

Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Rule-based request classification

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.

Vocabulary

Vocabulary consists of the operators, variable keywords known as operands, and control flow statements. The language is the Java™ Message Service (JMS 1.1), and the Message Selector Syntax. The message selector is a string whose syntax is based on a subset of the SQL92 conditional expression. The general statement syntax is:
operand operator literalExpression [| compoundOperator expression] .
In the following example,
serverhost like '%ibm.com' or clienthost = 'myhost.raleigh.ibm.com'
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
Service
The actions that are taken are dictated by the policy provider. For routing, the actions are:

permit
reject
permitsticky
redirect
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. In the administrative console, the actions are separated into forms and fields that are 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
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 that contains zero or more matchRules elements, and one or more workClassModules elements.

Operators

WebSphere^® Virtual Enterprise supports the operators in the rules expressions. In general, you might not know the true data type of a given operand. If you use the Hypertext Transfer Protocol (HTTP), every operand is treated 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 that has a null value is: IS NULL.

Operands
When new protocols are added and new sets of operands defined, operands are valid within protocol scopes. If an operand is specified in a scope for which it is not valid, an error condition is indicated. In this release, supported protocols are:

HTTP
JMS
SOAP over HTTP represented simply as SOAP
IIOP

An example of an operand for HTTP requests is: MIMEType.

Related reference

Routing and service policies
workclassoperations.py script