A work class is used to classify requests to apply a policy to the request. There are two types of policies that are applied to a request: routing and service. You can create routing policies for HTTP and SOAP requests, and you can create service policies for HTTP, IIOP, SOAP, and JMS requests. Additionally, work classes can contain classification rules for both policy types with the exception of JMS. Classification rules are not supported for JMS work classes.Routing and service policies for work classes are not supported for IIOP and JMS for applications deployed to z/OS®. WebSphere® Application Server z/OS provides IIOP and JMS service classification.
A work class is applied to the patterns that are associated with it. Every pattern has an object (application module or on demand router) with which it is associated. These pattern and object pairs make up the definition of which requests the work class is mapped to. Custom work class defined patterns take precedent over the default work class patterns. Every default work class contains a "/*" pattern, which means every request matches for that object.
Custom work class definitions are evaluated before default work class definitions when trying to find the matching definition. If an incoming request cannot be matched by any custom work class definitions, the default work class definition is used.
Routing policy | Description |
---|---|
permit:<application_name> | In this routing policy, application_name is the application name to route to with an optional edition specifier. This allows the request to continue as normal. |
permitsticky:<application_name> | The permitsticky routing policy is the same as the permit routing policy, except that the on demand router (ODR) also maintains client to server affinity for any future requests that come from the same client. In this case, the ODR adds a SET-COOKIE header to the response before sending the response to the client. |
reject:<HTTP_error_code> | This routing policy causes the ODR to reject any request that has the specified HTTP error code. For example, reject:503 returns a 503 Service is unavailable error. |
redirect:<URL> | With this routing policy, the ODR redirects the request to the specified URL. The URL has the pattern of protocol://URI. An example of a valid URL is: http://w3.ibm.com. |
The valid service policies are simply the list of transaction class names. The transaction class refers to a single service class.
There are four types of work classes:
Work class | Description |
---|---|
Application routing policy | Specifies how to determine the routing policy for a request to an application that is installed on WebSphere Extended Deployment. |
Application service policy | Specifies how to determine the service policy for a request to an application that is installed on WebSphere Extended Deployment. |
Generic server cluster routing policy | Specifies how to determine the routing policy for a request to a generic server cluster. |
Generic server cluster service policy | Specifies how to determine the service policy for a request to a generic server cluster. |
The following diagram illustrates the flow of a request targeted for an application that is installed on WebSphere Extended Deployment. The request is applied to an application routing policy work class to determine the routing policy. If the resulting routing policy is permit or permitsticky, the request continues to an application service policy work class to determine the service policy and the transaction class name.
Each application contains default application routing and application service policy work classes. You can also create additional non-default work classes. Each work class has a default match action. The default routing policy for an application is permit:<application_name>. The default service policy is Default_TC, the default transaction class.
Each work class contains an optional ordered list of rules that are evaluated for a particular request to determine the policy for that request. Each rule consists of a boolean expression and a policy value. If the expression evaluates to true for a particular request, the policy associated with that rule is used.
The syntax and semantics of a boolean expression for a rule are similar to the WHERE clause of a structured query language (SQL) expression. More precisely, the syntax of an expression is defined by the Java™ Message Service (JMS) 1.1 specification. See Rule-based request classification for more information.
In the JMS specification, identifiers refer to various attributes that can be associated with a request, for example, a specific query parameter, cookie, or HTTP header. A JMS identifier can be thought of as a request variable, or operand. These operands can be specific to a protocol. For example, the SOAP service name is an operand that is valid only in a SOAP work class.
clienthost LIKE '%.ibm.com''%.ibm.com' is a literal that is used to compare to the client host name for a request. This expression evaluates to true for all requests that originate from a computer in the ibm.com domain. Enclose string literals by single quotes. Do not enclose numeric literals in single quotes. Parentheses together with the AND, OR, and NOT operators can also be used to form compound boolean expressions. See the JMS 1.1 specification for a detailed description.
While new protocols can be added, and therefore new sets of operands defined, the following table lists operands and their associated protocols that are supported from the initial installation.
Request variable | Valid protocols | Description | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
IIOP | The name of the Enterprise Application where the EJB is contained. | ||||||||||||||||||
clienthost | HTTP SOAP
|
The fully-qualified client host name. This is the value of the internet protocol (IP) command host name. This operand does not support numeric operators such as >, >=, <, <=. | ||||||||||||||||||
|
IIOP | The client port name. | ||||||||||||||||||
clientipv4 | HTTP SOAP |
The IP address of the client computer using the Internet Protocol version 4 (IPv4) dotted quad address type n.n.n.n. | ||||||||||||||||||
clientipv6 | HTTP SOAP |
The Internet Protocol version 6 (IPv6) 128-bit address type of x:x:x:x:x:x:x:x following Request for Comments 1924 (RFC 1924) of the client computer. | ||||||||||||||||||
Contact header | The Contact header field. |
|||||||||||||||||||
Contact URI | The URI of the Contact header field. |
|||||||||||||||||||
cookie$<name> | HTTP SOAP |
A cookie name. For example, the expression cookie$My_Cookie_Name='My_Cookie_Value' tests
a request to see if it contains a cookie named My_Cookie_Name with
a value of My_Cookie_Value. To test for the presence
or absence of a particular cookie, use one of the following expressions: cookie$MyCookieName IS NOT NULL cookie$MyCookieName IS NULL |
||||||||||||||||||
|
IIOP | The module name of an EJB. | ||||||||||||||||||
|
IIOP | The name of an EJB. | ||||||||||||||||||
|
IIOP | The name of a method within the EJB. | ||||||||||||||||||
From header | The From header field. |
|||||||||||||||||||
From header display name | The display name in the From header field. |
|||||||||||||||||||
From URI | The URI of the From header field. |
|||||||||||||||||||
From URI host | The host in the From header field. |
|||||||||||||||||||
From URI port | The port in the URI of the From header field. |
|||||||||||||||||||
From URI user | The user in the From header field. |
|||||||||||||||||||
header $<name> | HTTP SOAP |
A header name and value. For example, the expression header$Host='localhost' tests
a request to see if it contains an HTTP host header with a value of localhost.
To test for presence or absence of the host header, use one of the following
expressions: header$Host IS NOT NULL header$Host IS NULL |
||||||||||||||||||
HTTPMethod | HTTP SOAP |
The HTTP method for the request. Possible values are POST, GET, PUT, and DELETE. | ||||||||||||||||||
MIMEType | HTTP SOAP |
The MIME type of the request. | ||||||||||||||||||
operation | SOAP | The name of a Web service operation. | ||||||||||||||||||
percentage$<val> | HTTP SOAP IIOP SIP |
The percentage operand evaluates to true, a fixed percentage of the time. For example, percentage$50 evaluates to true on average 50% of the time. | ||||||||||||||||||
port | HTTP SOAP IIOP |
The listening port on which the request was received. | ||||||||||||||||||
protocol | HTTP SOAP |
The communications protocol that transmits the request. Currently supported protocols are HTTP, HTTPS, SOAP, and SOAPS. | ||||||||||||||||||
queryparm$<name> | HTTP SOAP |
A header name and value. For example, the expression queryparm$timezone='EST' tests
a request to see if the request contains an HTTP query parameter named timezone with
a value of EST. To test for presence or absence of
a query parameter, use one of the following forms: queryparm$timezone IS NOT NULL queryparm$timezone IS NULL |
||||||||||||||||||
rampup$<startTime>$<completionTime> | HTTP SOAP IIOP SIP |
The rampup operand evaluates to true a
variable percentage of the time. It always evaluates to false before <startTime> and
to true after <completionTime>.
As time progresses from <startTime> to <completionTime>,
it evaluates to true, a linearly increasing percentage. The format of <startTime> and <completionTime> is day/month/year::hour:min:sec. where day is the day of the month, month is one of the twelve months: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec, year is the 4 digit year, hour is the 2 digit hour of the 24 hour clock, and min and sec are 2 digit values for minute and second, respectively.For example, rampup$01/Jan/2007::08:00:00$01/Jan/2007::17:00:00 begins to occasionally evaluate to true at 8 AM on Jan 1, 2007 and always evaluates to true by ramp up completion time at 5 PM of the same day. |
||||||||||||||||||
Request transport | The transport of the request. |
|||||||||||||||||||
Request URI | The request URI. |
|||||||||||||||||||
Request URI host | The host in the request URI. |
|||||||||||||||||||
Request URI port | The port in the request URI. |
|||||||||||||||||||
Request URI user | The user in the request URI. |
|||||||||||||||||||
Scheme of From header | The scheme of the From header field. |
|||||||||||||||||||
Scheme of To header | The scheme of the To header field. |
|||||||||||||||||||
Scheme of URI | The scheme of the URI. |
|||||||||||||||||||
serverhost | HTTP SOAP
|
The fully-qualified host name of the server. This operand does not support numeric operators such as >, >=, <, <=. | ||||||||||||||||||
serveripv4 | HTTP SOAP |
The IP address of the server computer using the IPv4 dotted quad address type n.n.n.n. | ||||||||||||||||||
serveripv6 | HTTP SOAP |
The IPv6 128-bit address type of x:x:x:x:x:x:x:x following RFC 1924 of the server computer. | ||||||||||||||||||
service | SOAP |
The name of a Web service. | ||||||||||||||||||
SIP method | The SIP method for the request. Possible values are INVITE, TRYING, RINGING, ACK, OK, and BYE. If the message is not a request, this operand returns null. |
|||||||||||||||||||
SIP response code | The response code of the response. If the message is not a response, this operand returns -1. |
|||||||||||||||||||
time | HTTP SOAP IIOP |
This operand is used to define the date and time of day that a given request must be honored. Two optional fields are StartTime and EndTime. If a request is received outside of that defined window, the request will not be processed. The Start Time and End Time fields each have the following format: dayOfWeek/dayOfMonth/month/year::hour:minute:second. For example, Thursday, the 11th of April, year 2007 at 1:03:45 PM is specified as: Thu/11/Apr/2007::13:03:45 Any field can use a wild card with the value *. For example, the 1st of each month is specified as */1. The dayofWeek values are Sun, Mon, Tue, Wed, Thu, Fri, Sat, and the dayOfMonth values range from 1-31. The month value is a non-numeric value representing the twelve months: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec. The year value is comprised of the year's four digits. For example, 2007. The hour value is the hour of day in the 24-hour clock. For example, 8am is represented as ::8. The minute and second are integers ranging from 0-59. The forward slash (/) is used to separate date parameters, the double colon (::) is used to separate the date parameters, and the colon (:) is used to separate the time of day parameters. Note that it is the boolean result of the entire rule in which the time operand is used that determines the routing action taken. |
||||||||||||||||||
To client host | The client host in the To header field. |
|||||||||||||||||||
To header | The To header field. |
|||||||||||||||||||
To header display name | The display name in the To header field. |
|||||||||||||||||||
To URI | The URI of the To header field. |
|||||||||||||||||||
To URI host | The port in the URI of the To header field. |
|||||||||||||||||||
To URI user | The user in the To header field. |
|||||||||||||||||||
virtual host | HTTP SOAP |
Virtual portals are created within WebSphere Portal Server, and WebSphere Extended Deployment supports this operand for better integration with WebSphere Portal Server. The virtual port is the request URL minus the context root for the WebSphere Portal application's web module. If a given request matches the virtual portal defined, then the routing action defined for that rule is taken. | ||||||||||||||||||
xpathexpr | SOAP |
The XPath string expression has a required field used
to contain the XPath expression and an optional field for defining local namespace(s).
If all the name spaces contained in the XPath expression are standard, then
the second field can be optional. If there are multiple local namespaces,
then separate each with a comma (,). An example of an xpathexpr with one local
namespace definition follows:xpathexpr$/soap:Envelope/soap:Body/m:getTimeZone/n:clientId$m\\=http://test.classify.ws.ibm.com,n\\=http://test2.classify.ws.ibm.com = \\'1000\\' or operation IS NOT NULL In the previous expression , the XPath expression is /soap:Envelope/soap:Body/n:getTimeZone/n:clientId. It contains the local namespace of n. So, the second field of the xpathexpr is defined as n \\=http://test.classify.ws.ibm.com. The dollar sign ($) is used to denote the start of a field definition. The double backslashes are the escape sequence in this example. The first equals sign (=) is escaped because it is part of the local namespace definition, whereas the second equals sign (=) is the operator in the classification expression and must not be escaped. Following is an example of an xpathexpr with two local namespaces: xpathexpr$/soap:Envelope/soap:Body/m:getTimeZone/n:clientId$m\\=http://test.classify.ws.ibm.com,n\\=http://test2.classify.ws.ibm.com = \\'1000\\' or operation IS NOT NULL A list of standard namespaces for xpathexpr follows:
|
WebSphere Extended Deployment supports the following operators in the rules expressions. These operators are also referred to as predicates in SQL terminology because they appear inside of a WHERE or HAVING clause. Operators are case-insensitive.
Operator | Description |
---|---|
OR | The logical OR operator. |
AND | The logical AND operator. |
NOT | The negation operator. |
IN | Expresses an operand with multiple values in a single
expression. Its meaning is consistent with the SQL standard meaning of the
operator. For example, if, for an operand called port, a
user wants to express that the port value could be any or all of the values
such as 9080, 9090, 9091, the expression fragment is: port IN (9080,9090,9091) In
SQL, how the values inside the brackets are expressed depends on the data
type of port. If port is an integer, the values without the single quote marks
are syntactically correct. If port is a string, the correct expression is:
port IN ('9080','9090','9091') |
LIKE | Expresses pattern matching for string operand values
and its meaning and use is consistent with that defined by the SQL language.
The value must contain the wildcard character (%) in the
position where the pattern matching is expected to commence. For example,
the expression:
host LIKE %blancamatches the word blanca or any other word that ends in blanca, while the expression: host LIKE blanca%matches the word blanca or any other word that starts with blanca. The expression: host LIKE %blanca%matches the word blanca or any word that has the token blanca imbedded in it. From a code implementation viewpoint, the java.util.regex.Pattern class is used. |
= | The equality operator expresses a match in a case-sensitive fashion. |
> | Greater-than operator for use with numeric operands. |
>= | Greater-than or equal operator for use with numeric operands. |
< | Less-than operator for use with numeric operands. |
<= | Less-than or equal operator for use with numeric operands. |
< > | Not equal operator. |
BETWEEN | Used with AND to select a range of values inclusive of the first (low) value and the last (high) value. Together, they operate on numbers and dates values. |
IS NULL | Tests for an operand having a NULL value. |
IS NOT NULL | Tests for an operand having a value other than NULL. |