インテグレーションのためのデザインパターン

インテグレーションのスペシャリストであれば、『インテグレーションのデザインパターン』を参照・使用・導入した経験をお持ちかと思います。こうしたデザインパターンには、正規化データモデルからファサードデザイン、メッセージング、ルーティング、複合型まで、数十種類のパターンが存在します。 

これらのデザインパターンはすべて、インテグレーションのスペシャリストにとって『（公的な）カタログ』としての役割を果たします。デザインパターンを使用することで、データやアプリケーション、プラットフォーム、システム、デバイスをうまく接続することができます。よりよく理解するため、『Service-driven approaches to architecture and enterprise integration（日本語訳：アーキテクチャとエンタープライズ統合のためのサービス主導型アプローチ）』で取り上げられているデザインパターンの代表例を見ていきましょう。

インテグレーション・デザインパターン①：正規化データモデル 

正規化データモデルは、「最も古い」デザインパターンだと考えられています。このモデルでは、利用者が、直接的または間接的に利用できるメッセージやデータを作成します。これらデータやメッセージは、インテグレーションプラットフォーム（Enterprise Service Busなど）を経由して、正規化かつ標準化された形式に変換されます。 

正規化データモデルは、さまざまな理由から多くの企業で使用されています。まずメンテナンスコストを大幅に削減できること、次にインテグレーション・プロジェクトの迅速化が可能になること、が理由として挙げられます。データが正規化されているため、インテグレーションのスペシャリストが新しいデータ構造を理解するために費やす時間が大幅に短縮できるからです。

このデザインパターンの欠点は、正規化データのモデルを一から作り直さなければならないため、（正規化表現に慣れていない場合は）設計フェーズに時間がかかってしまうことです。 

インテグレーション・デザインパターン②：ファサードデザイン

2つ目の例はファサードデザインです。このデザインパターンは、正規化データモデルの欠点を解消することを目的としており、正規化データを使用せずに簡素化したインタフェースを定義することで実装します。しかし裏側では、インタフェース内のメッセージが正規化データに変換されています（ユーザからは見えません）。 

このデザインパターンのメリットは変更の柔軟性です。インタフェース自体が正規化表現に準拠していないため、（裏の）正規化データモデルに変更を加えても、インタフェースやその利用者が直接影響を受けることがありません。つまり、すべてのインタフェースを変更する必要がないということです。  

このパターンの欠点は、保守のためのリソースやコストが増加してしまうことが挙げられます。正規化データモデルとは異なり、「変換」と「インテグレーション」の両方のロジックを管理・保守しなければなりません。 

インテグレーションのデザインパターンの活用

どのデザインパターンも、特定の目的を果たすために存在しています。例えば、あるアプリケーションから別のアプリケーションにイベントを送信するためや、アプリケーションのメッセージが利用可能になったときに表示したりするためなど。

インテグレーションのデザインパターンを効率的に活用するための第一歩は、新しいアプローチを検討・採用することから始まります。

 『ホワイトペーパー：API主導の接続性』をお読みいただき、インテグレーションの実装のための参考としてご活用ください。