第5章 コンテンツベースルーティング

5.1. コンテンツベースルーティングとは

5.1.1. はじめに

通常、エンタープライズサービスバスのデータは、 メッセージという形式でパッケージ化、転送、格納されます。メッセージはエンドポイント参照 (これはサービスかクライアントを参照します) があて先となります。エンドポイント参照のロールは、メッセージのコンテンツを参集的に処理するマシン、プロセス、オブジェクトを特定します。しかし、指定のアドレスが無効の場合はどうなるのでしょうか。このシナリオに陥ってしまう状況には、サービスに問題がある、あるいは削除されている場合などが挙げられます。
また、サービスが特定のタイプのメッセージを処理しなくなっている可能性もあります。このような場合、おそらく他のサービスが元の機能を行いますが、それでもメッセージ自体がどのように処理されるのかが疑問に残ります。
元の受け取り側の隣にある他のサービスがこのメッセージの内容を必要としている場合はどうなるのでしょうか。あて先が指定されていない場合はどうでしょう。

5.1.2. コンテンツベースルーティングの紹介

このようなシナリオに対応する方法の１つに、コンテンツベースルーティングを使うことが挙げられます。この技術は、指定のエンドポイント参照を使うのではなく、実際のメッセージの内容からあて先を探しメッセージをルーティングしようとします。
コンテンツベースルーティングの機能の仕方ですが、メッセージが開かれそのコンテンツにルールセットを適用し、メッセージのルーティングを行います。これらのルールを使い、どのパーティがメッセージを必要としているか確認することで、エンタープライズサービスバスが送信先を決定することができます。これにより、送信アプリケーションがメッセージの送信先を把握する必要がなくなります。
コンテンツベースルーティングシステムは、ルーター (１つのみ) および サービス (通常複数個)の２つのコンポーネントをベースに構築されています。
サービスは、最終的にメッセージを「消費する」コンポーネントです。各サービスがルーターに対して特定のメッセージタイプを必要するかを指定する方法は実装により左右されますが、ルーターが正しく指示を出せるようにするには、メッセージタイプ (メッセージコンテンツの別のアスペクト) やサービスの間になんらかのマッピングが存在する必要があります。
ルーターという名前が示しているように、これはメッセージをルーティングします。メッセージを受領するとコンテンツを検証し、コンテンツにルールを適用後ルールの指示どおりメッセージを転送します。
ルーターとサービス以外に、ハーベスターを含むシステムもあります。これらのツールのロールは、興味深い情報を探し出し、フォーマットされたメッセージのようなかたちでパッケージされルーターに送信されます。ハーベスターは、 メール転送エージェントメッセージストア、ニュースサーバー、データベース、他のレガシーシステムなど、多くの情報源を「マイニング」します。

5.2. XPath を使ったコンテンツベースルーティング

5.2.1. はじめに

コンテンツベースのルーティングを簡単に実行するにはは、ContentBasedRouter アクションで XPath ルールプロパイダー を実行します。このプロバイダーの利用は非常に簡単で、インラインおよび外部ルールの定義の両方に対応しています。

手順5.1 インラインルールの定義

  1. cbrAlias プロパティを XPath に設定します。
  2. (container destinations プロパティ にある) route-to 設定のルーティングルールを定義します。 
    <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
   <property name="cbrAlias" value="XPath"/>
   <property name="destinations">
       <route-to service-category="BlueTeam"  service-name="GoBlue"  expression="/Order[@statusCode='0']" />
       <route-to service-category="RedTeam"   service-name="GoRed"   expression="/Order[@statusCode='1']" />
       <route-to service-category="GreenTeam" service-name="GoGreen" expression="/Order[@statusCode='2']" />
   </property>
</action>

手順5.2 外部ルールの定義

  1. cbrAlias プロパティを XPath に設定します。
  2. .properties ファイルのルーティング式を定義します。ここではプロパティキーがあて先の名前で、該当のあて先へのルーティングに関するプロパティ値が XPath 式となっています。
  3. container destinations プロパティの route-to 設定にてルーティングルールを定義します。外部 properties ファイルに定義されているように destination-name 属性は、XPath ルールキーを参照します。 
    <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
   <property name="cbrAlias" value="XPath"/>
   <property name="ruleSet" value="/rules/xpath-rules.properties"/>
   <property name="ruleReload" value="true"/>
   <property name="destinations">
       <route-to destination-name="blue"  service-category="BlueTeam"  service-name="GoBlue" />
       <route-to destination-name="red"   service-category="RedTeam"   service-name="GoRed" />
       <route-to destination-name="green" service-category="GreenTeam" service-name="GoGreen" />
   </property>
</action>
XPath ルールは .properties ファイルにあります。以下の構文で表現されます。 
blue=/Order[@statusCode='0']
red=/Order[@statusCode='1']
green=/Order[@statusCode='2']

5.2.2. 名前空間

XML 名前空間プリフィックスと URI マッピングは、name-space 要素で定義します (これらは namespaces コンテナープロパティ内に置かれています)。

手順5.3 XML 名前空間プリフィックスと URI のマッピングの定義

  • XML 名前空間プリフィックスと URI マッピングを外部もインラインルール定義も同じ方法で定義します。 
    <action class="org.jboss.soa.esb.actions.ContentBasedRouter" 
name="ContentBasedRouter">
    <property name="cbrAlias" value="XPath"/>
    <property name="namespaces">
        <route-to prefix="ord" uri="http://www.acne.com/order" />
    </property>
    <property name="destinations">
        <route-to service-category="BlueTeam"  
        service-name="GoBlue"  expression="/ord:Order[@statusCode='0']" />
        <route-to service-category="RedTeam"   
        service-name="GoRed"   expression="/ord:Order[@statusCode='1']" />
        <route-to service-category="GreenTeam" 
        service-name="GoGreen" expression="/ord:Order[@statusCode='2']" />
    </property>
</action>

5.3. Regex を使ったコンテンツベースルーティング

5.3.1. はじめに

ContentBasedRouter アクションの Regex ルールプロバイダーを使いコンテンツベースのルーティングを実行することも可能です。このプロバイダーは、インラインおよび外部のルール定義の両方に対応しています。

手順5.4 インライン Regex ルーティングルールの定義

  1. cbrAlias プロパティを Regex に設定します。
  2. (container destinations プロパティ にある) route-to 設定のルーティングルールを定義します。 
    <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
   <property name="cbrAlias" value="Regex"/>
   <property name="destinations">
       <route-to service-category="BlueTeam"  service-name="GoBlue"  expression="#*111#*" />
       <route-to service-category="RedTeam"   service-name="GoRed"   expression="#*222#*" />
       <route-to service-category="GreenTeam" service-name="GoGreen" expression="#*333#*" />
   </property>
</action>

手順5.5 外部のルール定義の設定

  1. cbrAlias プロパティを Regex に設定します。
  2. .properties ファイルのルーティング式を定義します。ここではプロパティキーがあて先の名前で、該当のあて先へのルーティングに関するプロパティ値が Regex 式となっています。
  3. container destinations プロパティの route-to 設定にてルーティングルールを定義します。外部 .properties ファイルに定義されているように destination-name 属性を設定し、Regex ルールキーを参照します。 
    <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
   <property name="cbrAlias" value="XPath"/>
   <property name="ruleSet" value="/rules/regex-rules.properties"/>
   <property name="ruleReload" value="true"/>
   <property name="destinations">
       <route-to destination-name="blue"  service-category="BlueTeam"  service-name="GoBlue" />
       <route-to destination-name="red"   service-category="RedTeam"   service-name="GoRed" />
       <route-to destination-name="green" service-category="GreenTeam" service-name="GoGreen" />
   </property>
</action>
    XPath ルールは .properties ファイルにあります。以下のシンプルな形式で表現されます。 
    blue=#*111#*
red=#*222#*
green=#*333#*

5.4. JBoss Rules エンジンを使ったコンテンツベースルーティング

5.4.1. はじめに

JBoss Rules は、コンテンツベースルーターのルールプロパイダーエンジンです。Enterprise Service Bus は、３つのルーティング action classes を使い、このエンジンを統合します。この３つの action classes は以下のとおりです。
  • JBoss Rules エンジンの DRL 言語で記述されたルーティングルールセット (あるいは、希望であれば DSL 言語を利用可能)
  • メッセージコンテンツ。これは、JBoss Rules エンジンへ入るデータです (XML 形式か、メッセージに埋め込まれたオブジェクト)。
  • デスティネーション (エンジンから出された結果情報)
メッセージは content-based router に送信されると、ルールセットはコンテンツを評価し、サービスのあて先を返します。
本章の残りで、ルールセットの作成方法、メッセージコンテンツの評価方法、この評価プロセスから出されたあて先で何ができるかについて説明します。

5.4.2. ３ 種類のルーティングアクションクラス

JBoss Enterprise SOA Platform には、ルーティング アクションクラスが同梱されており、それぞれ少し違います。これらは、エンタープライズ統合パターンを実装しています。 以下にその３つのアクションクラスを挙げます。
  1. org.jboss.soa.esb.actions.ContentBasedRouter
    このアクションクラスは、コンテンツベースのルーティングパターンを実装します。メッセージンコンテンツとコンテンツの評価するルールセットに従い、メッセージを１つ以上のあて先サービスにルーティングします。あて先が指定のルールセットあるいはメッセージの組み合わせと一致しない場合、コンテンツベースのルーターは例外をスローします。このアクションは、それ以降のパイプライン処理を終了するためパイプラインの最後に置かれます。
  2. org.jboss.soa.esb.actions.ContentBasedWiretap
    これは、WireTap パターンを実装します。WireTap は、メッセージのコピーを制御チャネルへ送信するエンタープライズ統合パターンです。WireTap は、標準のコンテンツベースルーターの機能と同じですが、パイプラインは終了しません。この機能が wire-tap として利用するのに適しているため、そのような名前がついています。
  3. org.jboss.soa.esb.actions.MessageFilter
    これは メッセージフィルターパターンを実装します。あるコンテンツ要件を満たされなかったためメッセージが単にフィルタリングされる場合にメッセージフィルターパターンを使います。つまり、コンテンツベースルーターと同じように機能しますが、ルールセットがあて先と一致しない場合に例外をスローせず単にメッセージをフィルタリングするだけという点が違います。

5.4.3. ルールセットの作成

ルールセットを作成するには、JBoss Developer Studio. を使います (このアプリケーションには、特別なプラグインが含まれており、このタスクを容易に実行できるようになります)。
通常のルールセットをコンテンツベースルーティングに利用できるようにするには、ESB メッセージを評価し、ルール一致によりサービスあて先名のリストを出力するようにする必要があります。これを行う前に以下を確認します。
  • ルールセットが ESB メッセージをインポートするようにします。また、テストを行うにはこのコードを使います。 
    import org.jboss.soa.esb.message.Message
  • ルールセットがあて先一覧を作成する以下のグローバル変数を定義しているようにします。 
    global java.util.List destinations;
このメッセージは JBoss Rules エンジンの作業メモリに送信されました。

5.4.4. XPath ドメイン固有言語　

XML ベースメッセージの XPath ベース評価は便利であると感じるかもしれません。Red Hat はドメイン固有言語 実装を同梱することで、これに対応しています。この実装を使い XPath 式をルールファイルに追加します。
追加の方法は、XPathLanguage.dsl ファイルで式を定義し、以下のコードとあわせてルールセットのファイルを参照します。 
expander XPathLanguage.dsl
XPath 言語により、メッセージが JBOSS_XML のタイプで、以下のアイテムが定義されていることを確認します。
  1. xpathMatch <element> : この名前による要素がマッチする場合は、true を出します。
  2. xpathEquals <element>、 <value> : 要素が見つかりその値が指定値と同じ場合に true を出します。
  3. xpathGreaterThan <element>、<value> : 要素が見つかりその値が指定値よりも大きい場合に true を出します。
  4. xpathLessThan <element>、 <value> : 要素が見つかりその値が指定値よりも小さい場合に true を出します。

注記

fun_cbr クイックスタートは XPath の使用方法について説明します。

注記

全く違うドメイン固有言語を定義することができます。

5.4.4.1. XPath および名前空間

XPath と名前空間を使うには、名前空間プリフィックスを XPath 式で使うかを指定しｍさう。名前空間プリフィックスは、この形式 (prefix=uri,prefix=uri) でコンマ区切り一覧として指定します (上述した各種 XPath 式でも実行可能)。
  1. xpathMatch expr "<expression>" use namespaces "<namepaces>"
  2. xpathEquals expr "<expression>", "<value>" use namespaces "<namspaces>"
  3. xpathGreaterThan expr "<expression>", "<value>" use namespaces "<namspaces>"
  4. xpathLowerThan expr "<expression>", "<value>" use namespaces "<namespaces>"
名前空間対応のステートメントはすべて、XPath 式の最初に expr というキーワードをつける必要があります (これを追加することで、DSL ファイルで XPath 対応でないステートメントと衝突を起こさないようにするためです)。このプリフィックスは、評価する際に XML で利用したものとマッチする必要はありません。統一資源識別子 (URI: Uniform Resource Identifier) が同じにすることが重要です。

5.4.4.2. 設定

これらはそれぞれ、構成設定を介してすべて接続されており、jboss-esb.xml ファイルに保存されます。以下の service configuration は、サービス設定のフラグメント例です。このフラグメントでは、サービスは Java Message Service キューをリッスンしています。 
<service 
        	category="MessageRouting" 
        	name="YourServiceName" 
        	description="CBR Service">
        	<listeners>        
                  <jms-listener name="CBR-Listener"                  
                            busidref="QueueA" maxThreads="1">             
	           </jms-listener>
               </listeners>
		<actions> 
		     <action class="org.jboss.soa.esb.actions.ContentBasedRouter" 
		     				     name="YourActionName">
                    	<property name="ruleSet" value="JBossESBRules.drl"/>
                    	<property name="ruleReload" value="true"/>
                    	<property name="destinations">
                           <route-to destination-name="xml-destination" 
				    service-category="category01" 
			           service-name="jbossesbtest1" /> 
                           <route-to destination-name="serialized-destination"
                            				           service-category="category02" 
				    service-name="jbossesbtest2" /> 
                    	</property> 
                    	<property name="object-paths">
				<object-path esb="body.test1" /> 
				<object-path esb="body.test2" /> 
		     	</property>
                    </action>
		</actions>
            </service>
各メッセージは ContentBasedRouter アクションクラスに渡され、特定のルールセットにロードされます。次に、JBoss Rules エンジンの作業メモリへメッセージを送信、ルールを実行、あて先一覧を取得、メッセージのコピーをサービスに送信します。
この場合、JBossESBRules.drl ルールセットを使い xml-destination と serialized-destination の 2 つのあて先にマッチします。これらの名前は、route-to セクションの真のサービスにマッピングされます。
このテーブルは action タグの属性を示しています。これらの属性は使用する action と渡す名前を指定します。

表5.1 CBR アクション設定の属性

属性 説明
Class アクションクラスで、 以下のいずれかになります :org.jboss.soa.esb.actions.ContentBasedRouter、org.jboss.soa.esb.actions.ContentBasedWiretap あるいは org.jboss.soa.esb.actions.MessageFilter
Name カスタムアクションの名前
この表はアクションプロパティを示しています。このプロパティは、どのルールセット (ruleSet) をアクション内で利用するか指定します。

表5.2 アクション設定プロパティ

プロパティ 説明
ruleSet これは、JBoss Rules engineruleSet を含むファイル名で、メッセージコンテンツを評価するのに利用するルールセットです(各コンテンツベースルーティングインスタンスに対し、ruleSet １つのみを渡すことができます)。
ruleLanguage これは、ルールセットの評価に利用するドメイン固有言語の定義を含むファイルへの参照（オプション）です。
ruleReload これはオプションのプロパティで、ルールセットのホット再デプロイメントを有効にするには true に設定します。この機能はルール処理のオーバーヘッドを引き起こします。また、ルールが置かれている .esb アーカイブが再デプロイされると、ルールがリロードされる点にも注意してください。
ステートフル これはオプションのプロパティですが、RulesService に (呼び出しと呼び出しの間にファクトを記憶させる) ステートフルセッションを使うよう伝えます。詳細については「ステートフルルール」の章を参照してください。
destinations これは route-to プロパティセットで、レジストリ内に参照されたサービスカテゴリとサービス名にあわせ、サービスカテゴリと名前あて先の論理名を含みます。論理名はルールセットで利用する必要のある名前です。
object-paths これはオプションのプロパティで message オブジェクトを working memoryに渡します。
ruleAuditType これはオプションのプロパティで、JBoss RUles エンジンが監査ロギングを実行できるようにします。ログは JBoss Developer Studio プラグインに読み込まれ検証されます。有効な値は、CONSOLE、FILE、THREADED_FILE です。デフォルトでは、監査ロギングは実行されません。
ruleAuditFile これはオプションのプロパティで、監査ロギングのファイルパスが定義できるようになります。FILE か THREADED_FILE の ruleAuditType のみに適用される点に注意してください。デフォルトは "event" です。JBoss Rules エンジンは".log" を追加します。このファイルのデフォルトの場所は、"."と現在の作業ディレクトリ (JBoss では bin/ ディレクトリ内) です。
ruleAuditInterval これはオプションのプロパティで、監査イベントを監査ログにフラッシュする頻度を定義することができます。これは THREADED_FILE ruleAuditType のみに適用されます。デフォルトは 1000 (ミリ秒) です。

5.4.4.3. ステートフルルールセッション

ステートフルセッションを使うと、ファクトオブジェクトは各呼び出しの間で記憶されます (言い換えると、ステートフルが trueに設定されると、作業メモリは消去されません)。
メッセージプロパティを使い現在のセッションを継続するか、消去するかステートフルルールサービスに伝えます。
既存のステートフルセッションを継続するよう通知するには、以下の２つのメッセージプロパティを設定します。 
message.getProperties().setProperty(“dispose”, false);
message.getProperties().setProperty(“continue”, true);
最後にルールを実行する場合、常に dispose を true に設定し JBoss Rules エンジンの作業メモリを消去します。 
message.getProperties().setProperty(“dispose”, true);
message.getProperties().setProperty(“continue”, true);

注記

ステートフルルールセッションの利用に関する詳細は、business_ruleservice_stateful クイックスタートを参照してください。

5.4.4.4. 事前コンパイル済みのルールパッケージの利用

コンパイル済みのルールパッケージを使うには KnowledgeAgent を使います。これらのパッケージはローカルファイルシステム、あるいはリモートロケーション (URL 経由でアクセス) に置くことが可能です。

5.4.4.5. ビジネスルールの実行

ビジネスプロセスに従いメッセージのコンテンツを変更するというルールを実行するのは、ルーティングのルールを実行する場合と非常によく似ています。business_rule_service というクイックスタートのサンプルでこれについて例示しています (このクイックスタートは org.jboss.soa.esb.actions.BusinessRulesProcessor アクションクラスを利用します)。
このプロセスはBusiness Rule Processorと呼ばれるコンポーネントを使います。これはルーターにほぼ同じで、違いは以降の処理のためにaction pipeline に変更メッセージを返す点です。
希望であればビジネスとルーティングルールを１つのルールセットで組み合わせることもできます (ただし、前述した３つのルーティングaction クラスの１つを使う場合のみ機能します)。

5.4.4.6. ルールサービス実装の変更

このルールサービスは org.jboss.soa.esb.services.rules.RuleService インターフェースを実装します。デフォルトルールサービスを利用したくない場合、アクション設定で使いたいクラスを指定します。 
<property name="ruleServiceImplClass" value="org.com.YourRuleService" />