3. JBI仕様

【図3a】JBIアーキテクチャ

JSR-208: Java Business Integration(以下、JBI仕様)は、ESBをJavaで実装するときのフレームワークについて定義した仕様です。JBI仕様では、各種プロトコルと接続し、様々な付加機能を提供するコンポーネント、コンポーネント間で流れるメッセージのルーティングを行うサービスバス、およびサービスバスがルーティングするメッセージ形態、JMXベースの運用管理についてそれぞれ定めています。

WebOTX ESBはこのJBI仕様に準拠しています。ここでは、WebOTX ESBをより良く知る上で必要となる項目について説明します。

3.1. コンポーネントフレームワーク

【図3.1a】コンポーネントフレームワーク

JBIでは、バインディングコンポーネント(BC)と呼ばれる様々なプロトコルで通信を行うモジュールや、サービスエンジン(SE)と呼ばれるメッセージ変換やルーティングなどの内部的な処理を行うモジュールをコンポーネントとしています。JBI環境の一部であるコンポーネントフレームワークによって、JBI仕様に準拠して開発されたコンポーネントを自由にインストール/アンインストールすることができ、利用するケースに応じてコンポーネントの入れ替えを行うことができます。

Memo
WebOTX ESBではJBI仕様に準拠したBCとSEが予めインストールされています。

3.2. Normalized Message Router

JBI仕様では、ESBにおけるサービスバスをNormalized Message Router(以下NMR)として定義しています。以下ではNMRの主要な働きについて説明します。

コンポーネントとのメッセージ通信

【図3.2a】コンポーネントとのメッセージ通信

NMRはDelivery Channelと呼ばれる通信路を介して、コンポーネントとメッセージの送受信を行います。また、コンポーネント間の直接の通信は許されておらず、コンポーネントは他のコンポーネントとメッセージを受け渡しする際には、必ずNMRを仲介して行います。また、このときに流れるメッセージがメッセージエクスチェンジ(後述)です。

エンドポイントとアドレッシング

【図3.2b】EPR登録・解決

各コンポーネントは外部サービスのエンドポイント参照情報をWSDL2.0定義に基づきEndpoint Reference(以下EPR)として定義し、NMRに操作を行います。EPRに関する操作は以下の2つがあります。

JBI仕様では、エンドポイントのインタフェースをWSDLで定義できることを定めており、JBI内部ではエンドポイント情報をWSDL 2.0に合わせて、エンドポイント名(任意の文字列)、サービス名(QName)、インタフェース名(QName)の3つをセットで扱うことになっています。EPRの登録では以下のような情報を登録します。

メッセージ交換方式(MEP)

NMRは、WSDL 2.0(http://www.w3.org/TR/wsdl20-adjuncts/)に規定されたMessage Exchange Pattern(略称MEP)というメッセージ交換方式のうち、次の4つをを採用しています。

図3.2.c〜fにて、それぞれについて説明します。図中のコンシューマは、一般的にはサービスリクエスタと呼ばれるサービスに要求を出すプレーヤーです。プロバイダは一般的にはサービスプロバイダと呼ばれる、サービスを提供するプレーヤーです。

また、コンシューマとプロバイダで交換するメッセージは、その意味合いに応じて次の3種類が定義されています。

また、メッセージの他に以下のようなステータスも交換されます。

以下では、それぞれのメッセージ交換方式について図を用いて説明します。(ただし、errorステータスはどこでも起こりえるので表記しません。)

【図3.2c】In-Only

One-way通信のパターンです。

コンシューマの要求(1.in)に対して、プロバイダは完了ステータス(2.done)のみ通知します。

【図3.2d】Robust In-Only

信頼性の高いOne-way通信のパターンです。

コンシューマの要求(1.in)に対して、プロバイダは受け取ったこと(2.done)のみを通知しますが、プロバイダの処理で異常が発生した場合は異常メッセージ(3.fault)を返します。コンシューマがFaultを受け取った場合は、プロバイダに完了ステータス(4.done)を通知します。

【図3.2e】In-Out

Two-way通信のパターンです。

コンシューマの要求(1.in)に対して、プロバイダは応答(2.out)を返します。プロバイダの処理で異常が発生した場合は異常メッセージ(3.fault)を返します。コンシューマは、プロバイダにメッセージを(4.done)完了ステータスを通知します。

【図3.2f】In Optional-Out

プロバイダの返信が任意となるTwo-way通信のパターンです。

コンシューマの要求(1.in)に対して、プロバイダは応答(2.out)か異常メッセージ(3.fault)、あるいは完了ステータス(4.done)のいずれかを返します。残りのシーケンスは4の場合はin-only、および2または3の場合はin-outと同じですが、コンシューマは2.outに対して5.faultを返すことができる点で異なります。

3.3. メッセージエクスチェンジとノーマライズメッセージ

ここではJBI環境においてコンポーネントとNMRの間で送受信されるメッセージの形式の仕様について説明します。

【図3.3a】メッセージエクスチェンジの構造

JBIのサービス間で交換するメッセージは、メッセージエクスチェンジ(Message Exchange)と呼ばれます。メッセージエクスチェンジには、そのメッセージの宛先、ノーマライズメッセージ、様々な処理に用いることが可能なプロパティなどの図3.3aに挙げたものが格納されています。メッセージの宛先は動的に変更することが可能となっており、宛先を柔軟に切り替えることができます。ステータスはメッセージエクスチェンジの状態を表しており、これによりメッセージエクスチェンジが「メッセージ交換方式(MEP)」で説明したシーケンスのどのステージにあるかを判断します。エンドポイント情報は、WSDL 1.1ではPortTypeインタフェースに相当します。

【図3.3b】ノーマライズメッセージ(およびFault)の構造

ノーマライズメッセージ(Normalized Message)は、サービス間でやり取りするメッセージの本文です。ノーマライズメッセージには、次のサービスへ伝達するXML文書が入るメッセージコンテントの他、添付ファイルとプロパティが含まれます。プロパティには、コンポーネントの処理で必要となるメッセージのヘッダのような付加情報を任意で追加できるほか、JBI仕様で予め規定されたセキュリティサブジェクト、プロトコルタイプ、プロトコルヘッダが格納されます。

Faultは異常系のメッセージを表しますが、ノーマライズメッセージと構造は同じです。

Memo
WebOTX ESBではメッセージコンテントに非XML文書を格納することもできます。ただし、メッセージを受け取るコンポーネントによっては非XML文書を扱えません。

3.4. 運用管理

JBIでは運用する対象として、「3.2コンポーネントフレームワーク」で述べたコンポーネントの他に、サービスに関する設定情報をパッケージしたサービスユニットやサービスアセンブリがあります。従って、JBI環境における運用とは、コンポーネントやサービスユニット/サービスアセンブリの配備やライフサイクル管理となります。

以下では、サービスユニット/サービスアセンブリについてと、JBIにおける運用操作について説明します。

サービスユニット

【図3.4a】サービスユニットの構成

サービスユニット(Service Unit)はコンポーネントに関する設定情報をパッケージしたもので、コンポーネントに配備する最小の単位です。JBI環境はサービスユニット配備時には配備記述子だけ読み取り、SUが対象とするコンポーネントに引き渡します。

SUは右図のように、配備記述子に加え、コンポーネントに対する付加情報(artifact)などのファイルがパッケージされています。

Memo
「サービスユニット」は「SU」と略されることがあります。

サービスアセンブリ

【図3.4b】サービスアセンブリの構成

JBIではいくつかのサービスを組み合わせて、JBI環境の外部に対して1つの新しいサービスとして提供することがあります。

JBIでは、このように1つのサービスに統合した単位でサービスアセンブリ(Service Assembly)としてパッケージします。JBIでは、サービスアセンブリ単位で配備・ライフサイクル管理などの運用を行うことで個々のサービス単位で運用する手間を省いています。

サービスアセンブリは、図3.4bのようにいくつかのサービスユニットによって構成されます。

Memo
「サービスアセンブリ」は「SA」と略されることがあります。

JMXベースの運用管理

JBIの運用管理の操作には以下のようなものがあります。

JBIではこれらの操作をJMXを用いて行うこととしており、その為に以下で挙げるMBeanを定義しています。

これらのMBeanの他に、個々のコンポーネントが独自で、例えばログレベルなどを設定するためのMBeanを提供している場合もあります。

JBIではこれらのMBeanをJMXベースの管理ツールを用いて操作することで運用を行います。