どのようなルール・ベースのテクノロジーでも、ルール・ベース処理には、 言語を形成するボキャブラリー、ステートメントの中でボキャブラリーを表すための文法、 およびルールを処理するエンジンの 3 つの基本領域があります。 このトピックでは、ボキャブラリーと文法について説明します。ルール処理エンジンは、共通コンポーネントから再使用可能です。
ボキャブラリーは、演算子、オペランドと呼ばれる変数キーワード、および制御フロー・ステートメントで構成されます。 選択する言語は、Java Message Service (JMS 1.1)、特にメッセージ・セレクター構文です。メッセージ・セレクターは、SQL92 条件式のサブセットをベースにしている構文を持つストリングです。 このアプリケーションでは、メッセージ・セレクターは分類ルールを表します。一般にステートメントの構文は以下のようになります。
expression。 ここで、expression は、条件文節に述部を含む有効な SQL クエリーです。 例えば、以下のようになります。
serverhost like ‘%ibm.com’
この式で、serverhost はオペランド、like は演算子、そして '%ibm.com' は、式が true に評価されるために serverhost が持っている必要があるリテラルまたは値です。式の結果は、実行するアクションです。 文法の観点からは、これらのアクションは、ポリシー・プロバイダーによって提供されるリテラルです。ルーティング・ポリシーとサービス・ポリシーという 2 つのタイプのポリシーがサポートされています。 したがって、実行するアクションは、ポリシー・プロバイダーによって指示されます。 ルーティングの場合、アクションは、許可、拒否、リダイレクト、およびスティッキーの許可です。 これらのアクションにはそれぞれ、該当するターゲット (アクションの受信側) があります。 式を評価した結果、許可のアクションをとることになった場合は、そのアクションのターゲットは、 ルーティングが許可されているアプリケーションになります。 サービス・ポリシーの場合、ターゲットはアクションにカプセル化されており、 アクションはトランザクション・クラスです。
完全なステートメントはルール式から構成され、実行するアクションの表現は、入力ソースに応じて異なります。 管理コンソールを使用する場合、アクションは、簡単に選択できるフォームとフィールドに分離されます。スクリプトによる作業クラスの管理を実行する場合、完全なステートメントは以下のようになります。
expression<delimeter>action 例: clienthost='localhost' and serverhost like '%.ibm.com'?permit?DefaultApplication.ear
ただし、実装の観点からは、XML 文書である作業クラスを使用して、ルール式、一致したアクション、およびその他の実装の成果物を取り込みます。 したがって、作業クラスは、ゼロ個以上の matchRules エレメント、および 1 つ以上の workClassModules エレメントを含む XML 文書です。詳しくは、作業クラスのルーティング・ポリシーおよびサービス・ポリシーを参照してください。
WebSphere Extended Deployment は、ルール式で演算子をサポートしています。一般に、オペランドの真のデータ型はわかりません。 しかし、 どのオペランドもデータ・タイプのストリングとして扱う HTTP 方式に従い、 データ妥当性検査の目的でオペランドの実データ・タイプのインディケーター として演算子を使用することができます。 オペランドに NULL 値が含まれているかどうかをテストする演算子の例は、IS NULL です。
Related reference
作業クラスのルーティング・ポリシー