ESBの処理パターン
前回はWebサービスとESBの違いを解説し、ESBは粒度の大きなサービスを提供する際にメディエーションとして利用されると説明してきた。この ようなサービスは複数のステップから構成されていることが多く、これらのステップを分類した言葉として「VETRO」がある。
VETROとは表1であげる項目の頭文字であり、メディエーションのステップの典型的な処理を示している。
| 項目 | 説明 |
|---|---|
| Validate | メッセージの検証 |
| Enrich | メッセージに情報を付加 |
| Transform | メッセージの変換 |
| Route | ルーティング |
| Operate | 処理 |
まずは、これらの構成要素を説明する。
Validation（検証）
Validationステップは、入力されたメッセージが正しい形式のXML文書になっており、該当するXMLスキーマあるいはWSDL文書に準拠しているかを確認することである。
Enrich
入力されたメッセージにデータを追加し、サービスの前提条件を満たす処理をEnrichと呼ぶ。
例えば、ユーザ情報が前提条件となるサービスを呼び出す場合を考えてみよう。このサービスを呼び出す度にクライアントはユーザ情報を検索して格納しなければならないとすると、サービスの利便性は高くない。
そこでEnrichの処理パターンを利用して、メッセージの中にユーザIDを含めて、EnrichをおこなうサービスがユーザIDからDBを検索し て、ユーザ情報を取り出してメッセージに追加し、後続のサービスを呼び出すとすれば、前提条件を少なくすることができ、再利用の可能性をあげることができ る。
EnrichはESB固有の処理ではなく、エンタープライズインテグレーションに欠かせない方法である。グレーゴル・ホペのエンタープライズインテグレーションパターンにもEnrichは紹介されている。
Transform
Transformステップは、メッセージフォーマットの変換をおこなうステップである。
SOAで求められるサービスの粒度では複数のOperationが呼び出されることが多く、入力されたメッセージフォーマットがOperation のメッセージフォーマットであることは少ない。そのため、このステップでは入力メッセージの一部を取り出してOperationのメッセージとし、 Operationが呼び出された後の出力メッセージを取り出して入力メッセージの一部とするなどの処理を行う。
バックナンバー
この記事の筆者
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
