ESB vs. P2P：今すぐP2Pを撤廃すべき理由
ポイントツーポイントコーディング（P2P）によるアプリケーション統合には、多くの問題があります。Salesforceのテクノロジスト、Chris Tiernan氏は、「P2Pによる素早い統合は、大きな問題になりかねません」と指摘しています。
エンタープライズサービスバス（ESB）は、このような課題の多くを取り除きます。P2Pと比較して、ESBはアプリケーションを接続するためのより迅速で俊敏な方法を提供します。したがって、最も革新的な企業の多くがアプリケーション統合でESBを利用しているのも当然の流れです。
ESB vs. P2P：P2Pでは対応しきれない理由
初めに1つのアプリケーションしかなかったときは、何の問題もありませんでした。続いて2番目のアプリケーションが登場し、2つのアプリケーションを接続する必要が生じました。このときは、ハンドコーディングによって2つのアプリケーション間の接続を簡単に調整できました。これがポイントツーポイント統合です。
P2P統合では、システムは、相互について、さらに統合のために各アプリケーションがサポートするデータモデル/機能/テクノロジーインフラストラクチャ全般について、排他的に認識します。このため、2つのシステムは「緊密に結合されている」ものとみなされます。アプリケーションが少数であれば、これは問題ありません。しかし、緊密な結合の数が増えるにつれて、インフラストラクチャは脆くなり、また障害が発生しやすく保守が困難になります。
そのようなときに、ESBアーキテクチャーの真価が明らかになり始めます。ESBが登場する以前は、分岐させて次々と生み出す新しいアプリケーションをすべての既存アプリケーションに接続するために、P2Pスタイルが使用されていました。すべてにハンドコーディングが必要になるP2P統合に依存して成長し続けるインフラストラクチャでは、急速に複雑化が進むことがあります。
P2P統合の課題
そもそも、すべてのP2Pアプリケーション統合ソリューションは開発者にとって退屈な作業であり、ITインフラストラクチャに含まれるアプリケーション/システム/デバイス全体ですべての接続にカスタムコーディングが必要となります。
P2Pの最も明白な欠点は、融通が利かないことです。ポイントツーポイント統合は、維持する必要のある接続数とインターフェイス数が多いために極度の複雑さをもたらします。アプリケーションのバージョンが変更された場合や、使用されるデータモデルが変更された場合、消費する各インターフェイスへのハンドコーディングによる統合が結果として変更されなければならないため、その変更の影響が非常に大きくなります。アプリケーションは多くの場合、独自のテクノロジーとスキルセットに基づいており、通常は複数のトランスポートと通信のインフラストラクチャを実装しています。このような場合、どれほど冷静な開発者にとってもP2Pは悪夢となります。
リソースの不足とP2P統合の変更に伴うリスクは非常に大きく、インフラストラクチャへの影響を危惧して組織が変更を躊躇する可能性があります。
統合スタイルによって成長とイノベーションが脅かされるようになったら、明らかにほかの道を探るべきです。このような状況で、再びESBのメリットが浮上します。
ESBによる円滑でシームレスなアプリケーション統合
エンタープライズサービスバスは、アプリケーション統合に対するより柔軟なアプローチです。ESBは、アプリケーション間のインタラクションと通信を実装するために使用されるソフトウェアアーキテクチャースタイルまたはアーキテクチャーパターンです。この統合は、個別の再利用可能な機能のセットとして、各アプリケーション機能をカプセル化して提示することによって実現されます。
各アプリケーションが相互に直接統合されることがなくなり、代わりに以下に示すESBインフラストラクチャを通じて統合します。
通常、すべてのESBには次の2つのコンポーネントが含まれます。
- サービスレジストリ — ESBに提示されるすべてのサービスが公開され、登録される場所です。また、ほかのアプリケーションのサービスや機能を消費したい場合のポイントディスカバリーとしても機能します。
- 集中的な管理と監視 — ESB内部で発生するインタラクションのパフォーマンスについて、トランザクションのフローを表示します。
ESBの情報の流れ
一般的に、ESBに接続されるアプリケーションの機能の統合と公開は、「サービス」を介して行われます。通常使用されるのはWebサービスですが、必ずしもそうというわけではありません。これらの再利用可能な個別のサービスは、以下の流れで統合されます。
- アプリケーションがサービスを使用して、その機能を公開します。
- アプリケーションが一連の再利用可能サービスに分解されます。
- サービスがESBで利用可能になります。
- サービスがサービスレジストリに公開され、コンシューマーに提供されます。
サービスイネーブルメントはすべて自動化されているため、ESBではハンドコーディングする必要はありません。ESBのもう1つの主要メリットは、消費対象アプリケーションに関する知識がコンシューマーにほとんど求められないことです。技術的アーキテクチャー、バージョン、ソリューションのベンダー、アプリケーションの場所などの詳細は、コンシューマーにとっては重要ではなく、サービスの消費に影響を与えません。
リアルタイムおよびSOA機能の登場
ESBは、広範なアプリケーションとデータソースのより迅速な統合のために、アプリケーションの分離を可能にし、アプリケーションの調整と通信を行う中間インフラストラクチャを提供します。ESBは本質的に、イベント駆動統合とサービス指向アーキテクチャー（SOA）の概念という2つの主要統合スタイルに対して、充実したサポートを提供します。
実際のところ、ほとんどの組織は両方のスタイルを必要とします。サービス指向アーキテクチャーとイベント駆動アーキテクチャー（EDA）の統合スタイルは多様な理由による多様なニーズを満たすため、多くのESBは両方のスタイルと2つの間の移行をサポートしています。イベント駆動アーキテクチャーは、完全なSOAに移行する準備が整っていない組織や、そのような移行を望まない組織にとっての、初期の統合スタイルとしてよく使用されます。
決定的なスピードと柔軟性
結局のところ、P2P統合の限界を指摘するのも、アプリケーション統合におけるESBの明らかなメリットを指摘するのも、簡単です。
- さまざまな標準統合パターンを即座に利用できるようサポートすることで、統合が簡素化され、スピードアップされます。これにより、技術リソースの負担も軽減されます。
- 迅速に統合すべきアプリケーションとデータサービスの種類と数を増やします。
- BPMを介して技術インフラストラクチャのコンシューマーまたはビジネスコンシューマーに複合機能を提供するため、オーケストレーションを提供します。
ポイントツーポイント統合の限界は明らかです。ESB統合のメリットも明らかです。ESBは、主要な統合スタイルに対する充実したサポートを提供し、さまざまな標準統合パターンを即座に活用できるようにします。多くの企業がESBを使用してアプリケーション統合のニーズに対応しているのも、当然であると言えます。
Talend Open Studio for ESBの無償試用版
ESBのメリットは、実際に探索してみることで極めて明瞭なものになるでしょう。Talend Open Studio for ESBは、拡張可能なオープンソーステクノロジーに基づいた無償のソリューションです。Talend Open Studio for ESBを使用することで、アプリケーションやレガシーシステムを利用したサービスの実現が容易になり、サービス指向の強力なアーキテクチャーを構築できます。今すぐご確認ください。
