WebSphere Extended Deployment, Version 6.0.x
             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. 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.

Operators

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.

Operands

While new protocols can be added, and therefore 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
  • [For distributed platforms] SOAP over HTTP represented simply as SOAP
  • [For distributed platforms] [Version 6.0.1 and later] IIOP
  • JMS

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




Related reference
Routing and service policies work classes
Managing work classes with scripts
Concept topic    

Terms of Use | Feedback

Last updated: Nov 30, 2007 3:58:31 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/odoe_task/codoerule.html