要求に対してポリシーを適用するため、作業クラスを使用して要求を分類します。要求に対して適用されるポリシーには 2 つのタイプがあります。 それはルーティング・ポリシーとサービス・ポリシーです。HTTP および SOAP 要求のルーティング・ポリシーを作成できます。HTTP、IIOP、SOAP、および JMS 要求のサービス・ポリシーを作成できます。また、作業クラスには、 両方のポリシー・タイプの分類ルールを含めることができます (JMS を除く)。分類ルールは、JMS 作業クラスに対してサポートされていません。作業クラスの ルーティング・ポリシーおよびサービス・ポリシーは、z/OS に対してデプロイされたアプリケーションの IIOP および JMS に対してサポートされていません。WebSphere Application Server z/OS は、IIOP および JMS のサービス分類を提供します。
ルーティング・ポリシー | 説明 |
---|---|
permit:<application_name> | このルーティング・ポリシーでは、 application_name はオプションのエディション指定子で指定するアプリケーション名です。これにより、 要求は通常通り継続されます。 |
permitsticky:<application_name> | permitsticky ルーティング・ポリシーは、 オンデマンド・ルーター (ODR) も同じクライアントから来る将来の要求に対してクライアントと サーバーの類縁性を保つという点を除き、permit ルーティング・ポリシーと同じです。 この場合、 ODR はクライアントに応答を送信する前に SET-COOKIE ヘッダーを応答に 追加します。 |
reject:<HTTP_error_code> | このルーティング・ポリシーにより、ODR は指定された HTTP エラー・コードのある要求 をリジェクトします。例えば、reject:503 は、503 Service is unavailable エラーを戻します。 |
redirect:<URL> | このルーティング・ポリシーにより、ODR は指定された URL に要求をリダイレクトします。URL のパターンは、protocol:// ; です。有効な URL の例は、http://w3.ibm.com です。 |
有効サービス・ポリシーはトランザクション・クラス名の単なる リストです。トランザクション・クラスは単一のサービス・クラスを参照します。
作業クラスには次の 4 つのタイプがあります。
作業クラス | 説明 |
---|---|
アプリケーション・ルーティング・ポリシー | WebSphere Extended Deployment にインストールしたアプリケーションに対する要求の ルーティング・ポリシーを決定する方法を指定します。 |
アプリケーション・サービス・ポリシー | WebSphere Extended Deployment にインストールしたアプリケーションに対する要求の サービス・ポリシーを決定する方法を指定します。 |
汎用サーバー・クラスター・ルーティング・ポリシー | 汎用サーバー・クラスターに対する要求のルーティング・ポリシーを決定する 方法を指定します。 |
汎用サーバー・クラスター・サービス・ポリシー | 汎用サーバー・クラスターに対する要求のサービス・ポリシーを決定する 方法を指定します。 |
WebSphere Extended Deployment にインストールしたアプリケーションをターゲットにする 要求のフローを次のダイアグラムで説明します。 要求は、アプリケーション・ルーティング・ポリシー作業クラスに適用され、 ルーティング・ポリシーが決定されます。結果のルーティング・ポリシーが permit または permitsticky の場合、 要求はアプリケーション・サービス・ポリシー作業クラスに継続し、 サービス・ポリシーとトランザクション・クラス名を決定します。
それぞれのアプリケーションは、 デフォルトでアプリケーション・ルーティング・ポリシーとアプリケーション・サービス・ポリシー 作業クラスを含んでいます。また、追加でデフォルト設定ではない作業クラスを作成できます。各作業クラスには、デフォルトの一致アクションがあります。デフォルトの アプリケーション用ルーティング・ポリシーは permit:<application_name> です。 デフォルトのサービス・ポリシーは Default_TC、すなわちデフォルトの トランザクション・クラスです。
それぞれの作業クラスは、オプションの番号付きルールのリストを含みます。 このルールは、特定の要求について評価され、その要求に対するポリシーを 決定します。それぞれのルールはブール式とポリシー値で 構成されます。式が特定の要求を真と評価した場合、 そのルールに関連したポリシーが使用されます。
ルールに対するブール式の構文とセマンティクスは、 構造化照会言語 (SQL) 式の WHERE 文節に 似ています。さらに詳しく言えば、式の構文は Java Message Service (JMS) 1.1 仕様 で定義されます。詳しくは、ODR ルール・ベースの要求分類を参照 してください。
JMS 仕様では、 ID は特定の照会パラメーター、Cookie、HTTP ヘッダーなど、 要求に関連するさまざまな属性を 参照します。JMS ID は要求変数またはオペランド と考えることができます。このオペランドはプロトコル固有のものである場合があります。例えば、SOAP サービス名は、 SOAP 作業クラスでのみ有効なオペランドです。
オペランドのリストは動的ですが、 以下にリストしたオペランドは基礎となるオペランドです。詳しくは、 拡張リストをサポートする製品の製品文書を参照してください。次の表にオペランドと その関連プロトコルを示します。
要求変数 | 有効なプロトコル | 説明 |
---|---|---|
|
IIOP | EJB が含まれている Enterprise Application の名前。 |
clienthost | HTTP SOAP
|
完全修飾クライアント・ホスト名。これは、 インターネット・プロトコル (IP) コマンド・ホスト名の値です。 このオペランドは、>、>=、<、<= などの数値演算子をサポートしていません。 |
|
IIOP | クライアント・ポート名 |
clientipv4 | HTTP SOAP |
Internet Protocol version 4 (IPv4) ドット付きクワッドのアドレス・タイプ n.n.n.n を使用したクライアント・マシンの IP アドレス。 |
clientipv6 | HTTP SOAP |
クライアント・マシンの Request for Comments 1924 (RFC 1924) に従う Internet Protocol version 6 (IPv6) 128 ビット・アドレス・タイプ x:x:x:x:x:x:x:x。 |
cookie$<name> | HTTP SOAP |
Cookie (クッキー) 名。例えば、式 cookie$My_Cookie_Name='My_Cookie_Value' は要求をテストし、その要求が、値が My_Cookie_Value である My_Cookie_Name という名の Cookie を含むかどうかを確かめます。ある特定の Cookie が存在するかどうかをテストするには、
次の式のいずれかを使用します。cookie$MyCookieName IS NOT NULL cookie$MyCookieName IS NULL |
|
IIOP | EJB のモジュール名。 |
|
IIOP | EJB の名前。 |
|
IIOP | EJB 内のメソッドの名前。 |
gid | HTTP SOAP |
要求送信側のグループ ID。 |
header $<name> | HTTP SOAP |
ヘッダー名と値。例えば、式 header$Host='localhost' は、要求をテストし、
値が localhost である HTTP ホスト・ヘッダーを含むかどうかを確かめます。ホスト・ヘッダーが存在するかどうかをテストするには、
次の式のいずれかを使用します。cookie$Host IS NOT NULL cookie$Host IS NULL |
HTTPMethod | HTTP SOAP |
要求に対する HTTP メソッド。考えられる値は、 POST、GET、PUT、DELETE です。 |
MIMEType | HTTP SOAP |
要求の MIME タイプ |
operation | SOAP | Web サービス・オペレーションの名前。 |
port | HTTP SOAP IIOP |
要求を受け取った listen ポート。 |
protocol | HTTP SOAP |
要求を伝送する通信プロトコル。 現在サポートされているプロトコルは、HTTP、HTTPS、SOAP、SOAPS です。 |
queryparm$<name> | HTTP SOAP |
ヘッダー名と値。例えば、式 queryparm$timezone='EST' は要求をテストし、
その要求が EST の値を持つ
timezone という名の HTTP 照会パラメーターを含むかどうかを確認します。照会パラメーターが存在するかどうかをテストするには、
次の式のいずれかを使用します。queryparm$timezone IS NOT NULL queryparm$timezone IS NULL |
serverhost | HTTP SOAP
|
サーバーの完全修飾ホスト名。このオペランドは、>、>=、<、<= などの数値演算子をサポートしていません。 |
serveripv4 | HTTP SOAP |
IPv4 ドット付きクワッドのアドレス・タイプ n.n.n.n を使用したサーバー・マシンの IP アドレス。 |
serveripv6 | HTTP SOAP |
サーバー・マシンの RFC 1924 に従う IPv6 128 ビット・アドレス・タイプ x:x:x:x:x:x:x:x。 |
service | SOAP |
Web サービスの名前。 |
uid | HTTP SOAP |
要求送信側のユーザー ID。 |
clienthost LIKE '%.ibm.com'で、 '%.ibm.com' は要求のクライアント・ホスト名との比較に使用されるリテラルです。この式は、ibm.com ドメインのマシンで発生したあらゆる要求について、 真の評価を行います。ストリング・リテラルを単一引用符で 囲みます。数字リテラルは単一引用符で囲まないで ください。AND、 OR、NOT 演算子を含む括弧も、複合ブール式の形成に 使用できます。詳しくは、JMS 1.1 仕様 を参照してください。
WebSphere Extended Deployment は、ルール式で以下の演算子をサポートしています。これらの演算子は、WHERE または HAVING 文節の内部に現れるので、SQL 用語では述部 とも呼ばれます。 演算子は大/小文字を区別しません。
演算子 | 説明 |
---|---|
OR | 論理 OR 演算子。 |
AND | 論理 AND 演算子。 |
NOT | 否定演算子。 |
IN | 単一の式に複数の値を持つオペランドを表します。その意味は、演算子に対する
SQL 標準の意味と整合します。
例えば、port というオペランドで、その port の値を 9080、9090、9091
のいずれか、またはすべてにできることを表す場合、式のフラグメントは以下のようになります。port IN (9080,9090,9091)
SQL では、ブラケット内の値の表し方は、ポートのデータ・タイプによって決まります。
port が整数の場合、単一引用符がなくても値は構文的には正しくなります。port
がストリングの場合、正しい式は、以下のようになります。
port IN (‘9080’, ‘9090’, ‘9091’) |
LIKE | ストリング・オペランドの値とその意味についてのパターン・マッチングを表し、使用法は SQL 言語によって定義されている使用法と一致します。値には、パターン・マッチングの始まりが予期される位置にワイルドカード文字
(%) が含まれている必要があります。
例えば、
host LIKE %blancaという式は、blanca という語または blanca で終わるすべての語に一致し、 host LIKE blanca%という式は、blanca という語または blanca で始まるすべての語に一致します。 host LIKE %blanca%という式は、blanca という語またはトークン blanca が埋め込まれたすべての語に一致します。 コード実装の観点からは、java.util.regex.Pattern クラスが使用されます。 |
= | 等価演算子は、大/小文字を区別した一致を表します。 |
> | より大演算子は、数値オペランドで使用されます。 |
>= | より大演算子または等価演算子は、数値オペランドで使用されます。 |
< | より小演算子は、数値オペランドで使用されます。 |
<= | より小演算子または等価演算子は、数値オペランドで使用されます。 |
< > | 非等価演算子。 |
BETWEEN | AND とともに使用して、最初の (低い) 値と最後の (高い) 値を含む、ある範囲の値を選択します。これら 2 つの値を一緒にして、数と日付の値に対して使用します。 |
IS NULL | オペランドに NULL 値が含まれているかどうかをテストします。 |
IS NOT NULL | オペランドに NULL 以外の値が含まれているかどうかをテストします。 |
Related concepts
ODR ルール・ベースの要求分類
Related tasks
サービス・ポリシーの定義
複数エディションの並行した活動化
エディションの妥当性検査