JBoss Fuseを使い倒す その2：デザインパターン概要編

はじめに

これまでの記事では、JBoss Fuseの基本的な使い方や設定方法を紹介してきました。しかし、いざJBoss Fuseを使って本格的なシステム間統合ソリューションを設計・実装しようとなると、現実のシステム間統合のシナリオで求められる、より実践的な設計ノウハウが必要となります。こうした実践的なノウハウ集、つまりシステム間統合のデザインパターンを知り、必要に応じてそれらを適用できるようにしておくことが、JBoss Fuseの導入を成功させる上で非常に重要です。

例えば、以下のようなシステム間統合の設計課題を考えてみてください。

• リクエスト／リプライ型の非同期メッセージングを行いたいときに、どのようにリクエストとリプライのメッセージをひも付ければいいか
• 非同期メッセージの処理中に発生しうるエラーに対して、どのような例外処理を設計すればいいか
• 1つのメッセージでは送りきれないような大きなデータを転送したい場合に、どういった設計アプローチがあるか
• 構築したシステム間統合ソリューションの、運用時におけるシステム監視・管理をどのように設計すればよいか

こうした実践的な設計課題に対して、先人達がたどり着いた答えをまとめたものが、これまでもたびたび登場した「エンタープライズ統合パターン（Enterprise Integration Patterns、以下、EIP）」です。本連載の締めくくりに、EIPの概要と、EIPをJBoss Fuse上でどのように活用できるかについて、2回に分けて紹介していきます。今回は、EIPの概要編です。

エンタープライズ統合パターンとは

改めて紹介すると、EIPは2003年に書籍『Enterprise Integration Patterns』（Gregor Hohpe、Bobby Woolf著）でまとめられたパターン集です。原著の出版からおよそ12年も経った2015年になっても、残念ながら日本語訳は出版されていません。本書は、ESBやSOAに携わる技術者必携の書籍ですので、洋書ではありますが、手元に一冊置いておくことをお薦めします。

図1：書籍『Enterprise Integration Patterns』（Gregor Hohpe、Bobby Woolf著）

パターンカタログと各パターンの要約、およびケーススタディの3章（「Interlude：...」の章）を含む書籍の一部は、EIPの公式サイトでも参照できます。

EIPを理解する上で注目すべき特徴の1つは、それがパターン「言語」を構成していることです。いわゆるGoF（Gang of Four）デザインパターンのような、パターン間につながりの乏しい単なるパターンカタログではありません。システム間統合のソリューション全体を扱う大局的なパターンに始まり、そこから部分・全体の関係を保ちつつ段階的に詳細なパターンへと細分化されていく、という構造を持ちます。さらに、同じ詳細レベルの個々のパターン間でも様々な関連が張り巡らされており、1つのパターンの適用が別のパターンへと派生していくといった、パターンとして望ましいとされる有機的な言語の特徴を持ちます。

基本的なシステム間統合スタイル

EIPはまず、エンタープライズにおけるシステム間の統合アプローチを、大きく次の4つのスタイルにパターンとして分類します。

	パターン	概要
	File Transfer ファイル転送	ファイルを介してシステム間の通信を行う
	Shared Database 共有データベース	共通のデータベースを参照・書き込みすることで、システム間のデータをやり取りする
	Remote Procedure Invocation リモート手続呼出	Webサービス（SOAP、REST）のような同期型のRPCによって、システム間の通信を行う
	Messaging メッセージング	JMSのような非同期型のチャネルを介して、システム間の通信を行う

ファイル転送や共有データベースは、昔から行われてきたよくあるシステム間統合のスタイルと言えるでしょう。これらのスタイルの特徴は、導入の技術的敷居が低いことです。その一方で、ファイル転送にはバッチ処理により必然的にタイムラグが発生する、共有データベースにはデータの共有のみで機能や処理の共有はできない、といった様々な問題があります。

そういった問題に対処できるスタイルとしてリモート手続呼出とメッセージングがあります。どちらもデータではなく機能・処理を統合するアプローチですが、それが同期型か非同期型かでリモート手続呼出とメッセージングに分かれます。

EIPとESB

EIPの書籍では、メッセージングを最も洗練された統合スタイルであるとしており、以降のパターンは全てこのメッセージングを深く掘り下げたものとして説明されています。しかしESB（Enterprise Service Bus）が普及した現在、筆者は必ずしもEIPを「メッセージング」に限定したパターンと捉える必要はないと考えます。

EIPが出版された2003年当時、システム間統合の製品としてはMOM（Message-Oriented Middleware）やEAI（Enterprise Application Integration）といったカテゴリが主流でした。EIPを体現したミドルウェアとでも言えるESBの概念は、まだほとんど普及していませんでした。

実際のところJBoss Fuseを含むESBでは、一般にどの統合スタイルを取るかという問題は、外部システムとESBとの接続点であるエンドポイントにおいて抽象化されるものであり、その通信のメッセージ交換パターン（Message Exchange Pattern：MEP）さえ意識しておけば、基本的にはEIPのどのパターンも適用可能になります。したがって本記事では、あえてEIPをメッセージングに限定せずに説明していきます。

システム間統合のパターン「言語」

EIPのパターン言語が始まるのは、ここからです。EIPのパターン言語は、トップダウンの整然とした階層構造をしています（図2）。

図2：EIPパターン言語の構造（書籍より抜粋の上、一部加筆・修正）

この図から分かるように、EIPはシステム間統合のソリューション（＝ESB／メッセージングシステム）をメッセージチャネル、メッセージ、パイプ＆フィルタ、メッセージルータ、メッセージ変換、メッセージエンドポイントという6つの概念に細分化します。本連載の読者の皆さんは、Apache Camelのアーキテクチャが、この構成にそのまま基づいていることに気づかれたでしょう。

この6つの概念にまつわる基本的な問題と解決策、および検討事項がまず大局的な「ルートパターン」として定義されます。

	パターン	概要
	Message Channel メッセージチャネル	システム間の通信手段を、チャネルという形に概念化して扱う
	Message メッセージ	チャネルを介して通信するデータの単位を、ヘッダと本文からなるメッセージの形式で扱う
	Pipes and Filters パイプ＆フィルタ	システム間統合の基本的なアーキテクチャの考え方。UNIXのようにパイプ（チャネル）とフィルタ（プロセッサ）でソリューションを構築する
	Message Router メッセージルータ	パイプ＆フィルタにおいて複雑なメッセージ処理を実現するには、メッセージをルーティングするフィルタを導入する
	Message Translator メッセージ変換	システム間のデータ形式の違いを吸収するために、メッセージを変換するフィルタを導入する
	Message Endpoint メッセージエンドポイント	ESBが外部システムと接続する部分を、エンドポイントという形で抽象化する

EIPのパターン言語は、これらのルートパターンがまずシステム間統合ソリューションの大枠の問題についての解決策を示した上で、個々のルートパターンが内包する詳細な技術的課題や特殊なケースへの対応、さらに派生する設計問題などを、ルートパターンの元で深堀りする構成になっています。

さらに、システム間統合ソリューションの監視・管理に関するパターンがこの体系に加えられて、全体としてのEIPが完成します。ただし監視・管理に関するパターンは、システム間統合ソリューションの本体からすれば付随的であるためか、ルートパターンには表されていません。

なお、EIPではメッセージが図3のように独特なアイコンで表現されますが、これはXMLのように、ルート要素があってそこから子要素が階層的にぶら下がる半構造データを表現していると理解すればいいでしょう。

図3：EIPにおけるメッセージのアイコン