第5章 その他のコンポーネント

本章では、JBoss Enterprise Service Bus 内の他のインフラストラクチャーコンポーネントやサービスについて説明します。これらのサービスのいくつかはそのサービス独自のドキュメントがありますので、この場合はそちらも参照してください。本章の目的は開発者が利用できるその他のコンポーネントに関する概要を示すことです。

5.1. メッセージストア

JBoss Enterprise Service Busメッセージストアのメカニズムは監査追跡の目的を念頭に置いて設計されています。他の ESB サービスと同様にプラグイン可能なサービスであり、 特殊なニーズがある場合など開発者が独自の永続メカニズムにプラグインすることができます。JBossESB で提供される実装はデータベース永続メカニズムになります。ファイル永続メカニズムなどが必要な場合は、単にこれを行う独自のサービスを記述し設定変更でデフォルトの動作をオーバーライドします。

注記

現在、メッセージストアはベース実装のみです。Red Hat では、メッセージストアの機能性が高度な監査と管理要求に応えられるようにするためコミュニティおよびパートナーの方々と共同で作業を進めていく予定です。したがってこれは出発点となります。

5.2. データ変換

クライアントとサービスは同じボキャブラリーを使用して交信することがよくありますが、そうではない場合にはあるデータ形式から別の形式に即時対応による変換が必要になります。単一のデータ形式がすべてのビジネスオブジェクト、特に大規模な開発や長期にわたる開発において適しているとみなすのは非現実的です。したがって、あるデータ形式から別の形式への変換メカニズムを提供することが必要になってくるわけです。
Transformation Service と呼ばれています。JBoss Enterprise Service Bus のこのバージョンは Smooks をベースとしたすぐに使用できる Transformation Service が同梱されます。Smooks は変換実装および管理フレームワークになります。これにより、XSLT、Java などの形式で変換ロジックを実装できます。また、この変換ロジックの集約管理ができる管理フレームワークを実現します。

注記

Smooks に関する詳細は、サービスガイド の「メッセージ変換」の章と Smooks ガイド を参照してください。

5.3. コンテンツベースルーティング

JBoss Enterprise Service Bus は、送信元にメッセージを動的にルーティングする必要がある場合もあります。以下のような場合に必要です。
  • 元の送信先が利用できない
  • サービスが移動された
  • アプリケーションがコンテンツベース、時間、その他の属性でメッセージの送信先を管理する必要がある
コンテンツベースのルーティングの仕組みを使用して、任意の複雑なルールをもとにメッセージをルーティングします (これらのルールはXPath、Regex Content-Based Routing (CBR)、あるいはJBoss Rules 表記に定義可能です)。または、コンテンツベースのルーティング機能を提供します。

5.4. レジストリ

SOA のコンテキスト内で、registry はそのサービスに関する情報を格納するための集約点をアプリケーションやビジネスに提供します。そのクライアントに対して標準市場と同レベルの情報や同じ範囲におけるサービスの提供が求められます。理想的には registry は自動ディスカバリや e-commerce トランザクションの実行を容易にし、ビジネストランザクションの動的環境を実現する必要もあります。したがって、registry は単に「e-business ディレクトリ」というだけではなく、SOA インフラストラクチャの固有となるコンポーネントになります。
いろいろな意味で、registryJBoss Enterprise Service Bus の心臓部となります。サービスはエンドポイント参照 (EPR) を自身で公開し、また使用されなくなるとエンドポイント参照を削除します。コンシューマーは registry を調べて現在のタスクに適したサービスの EPR を確定することができます。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。