エンタープライズアプリケーション統合

エンタープライズアプリケーション統合（EAI ）は、ソフトウェアとコンピュータシステムのアーキテクチャ原理を利用して、一連のエンタープライズコンピュータアプリケーションを統合することです。^[1]

エンタープライズアプリケーション統合は、企業全体のシステムとアプリケーションの統合を可能にするミドルウェアまたは「ミドルウェアフレームワーク」を形成する一連のテクノロジとサービスから構成される統合フレームワークです。 ^[1]

サプライ チェーン管理アプリケーション、ERPシステム、顧客管理用のCRMアプリケーション、ビジネス インテリジェンスアプリケーション、給与計算、人事システムなどの多くの種類のビジネス ソフトウェアは、通常、データやビジネス ルールを共有するために相互に通信することができません。このため、このようなアプリケーションは、自動化の島または情報サイロと呼ばれることがあります。この通信の欠如は、同一のデータが複数の場所に保存されたり、単純なプロセスを自動化できなかったりするなど、非効率につながります。^{[引用が必要]}

エンタープライズ アプリケーション統合とは、既存のアプリケーションやデータ構造に大幅な変更を加えずに、ビジネス プロセスを可能な限り簡素化および自動化するために、単一の組織内のアプリケーションをリンクするプロセスです。アプリケーションは、バックエンドでAPI経由でリンクすることも、フロントエンド ( GUI ) でリンクすることもできます (まれに)。^{[引用が必要]}

調査会社ガートナーによれば、「EAIとは、企業内の接続されたアプリケーションやデータソース間でデータとビジネスプロセスを制限なく共有することです。」^[2]

相互にリンクする必要のあるさまざまなシステムは、異なるオペレーティング システム上に存在したり、異なるデータベースソリューションやコンピュータ言語を使用したり、異なる日付と時刻の形式を使用したり、元々作成したベンダーによってサポートされなくなったレガシー システムである可能性があります。場合によっては、このようなシステムは、変更が非常に困難な方法で詰め込まれたコンポーネントで構成されているため、 「ストーブパイプ システム」と呼ばれます。 ^{[引用が必要]}

構造化された EAI アプローチに従わずに統合を適用すると、ポイントツーポイントの接続が組織全体に広がります。依存関係が突発的に追加され、維持が困難な複雑な構造になります。これは一般にスパゲッティと呼ばれ、プログラミングにおけるスパゲッティ コードに由来しています。

たとえば、n個のポイントを持つ完全にメッシュ化されたポイントツーポイント接続に必要な接続数は、 (二項係数を参照)で与えられます。したがって、10 個のアプリケーションを完全にポイントツーポイントに統合するには、2 次増加パターン に従うポイントツーポイント接続が必要です。${\displaystyle {\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}}$${\displaystyle {\tfrac {10\times 9}{2}}=45}$

ただし、組織内の接続数は、必ずしもポイント数の 2 乗に比例して増加するわけではありません。一般に、任意のポイントへの接続数は、組織内の他のポイントの数によってのみ制限されますが、原理的には大幅に少なくなる場合があります。EAI は、システム間の結合を増加させ、管理オーバーヘッドとコストを増加させる可能性もあります。^{[引用が必要]}

EAI は、アプリケーション間でデータを共有するだけでなく、ビジネス データとビジネス プロセスの両方を共有することにも重点を置いています。EAIを担当するミドルウェア アナリストは、多くの場合、システム オブ システムズを検討します。^{[引用が必要]}

EAIはさまざまな目的で使用できます: ^{[引用が必要]}

• データ統合: 複数のシステム内の情報の一貫性が保たれるようにします。これは、エンタープライズ情報統合(EII)とも呼ばれます。
• ベンダー独立性: アプリケーションからビジネス ポリシーまたはルールを抽出し、EAI システムに実装します。これにより、ビジネス アプリケーションの 1 つが別のベンダーのアプリケーションに置き換えられた場合でも、ビジネス ルールを再実装する必要がなくなります。
• 共通ファサード: EAI システムは、アプリケーションのクラスターのフロントエンドとして機能し、これらのアプリケーションへの単一の一貫したアクセス インターフェイスを提供し、ユーザーがさまざまなソフトウェア パッケージの使用方法を学習する必要がないようにすることができます。

このセクションでは、統合、アクセス、ライフタイムパターンなど、EAIを実装するための一般的な設計パターンについて説明します。これらは抽象的なパターンであり、さまざまな方法で実装できます。業界では、高レベルの抽象的な設計パターンから非常に具体的な実装パターンまで、他にも多くのパターンが一般的に使用されています。^[3]

EAIシステムは2つのパターンを実装します: ^[4]

調停（内部コミュニケーション）

ここで、EAI システムは複数のアプリケーション間の仲介役またはブローカーとして機能します。アプリケーションで興味深いイベントが発生すると (たとえば、新しい情報が作成されたり、新しいトランザクションが完了したりする)、EAI システムの統合モジュールに通知されます。その後、モジュールは変更を他の関連アプリケーションに伝播します。

フェデレーション（相互通信）

この場合、EAI システムは複数のアプリケーションにまたがる包括的なファサードとして機能します。外部からアプリケーションへのすべてのイベント呼び出しは、EAI システムによってフロントエンド化されます。EAI システムは、基盤となるアプリケーションの関連情報とインターフェイスのみを外部に公開するように構成され、要求者に代わって基盤となるアプリケーションとのすべてのやり取りを実行します。

両方のパターンは同時に使用されることがよくあります。同じ EAI システムが複数のアプリケーションの同期を維持しながら (仲介)、これらのアプリケーションに対する外部ユーザーからの要求に応答することができます (フェデレーション)。^{[引用が必要]}

EAI は、非同期 (ファイア アンド フォーゲット) と同期の両方のアクセス パターンをサポートします。前者は仲介の場合に一般的であり、後者はフェデレーションの場合に一般的です。^{[引用が必要]}

統合操作は、短期間のもの（たとえば、2 つのアプリケーション間でデータを同期させる作業が 1 秒以内に完了する）もあれば、長期間のもの（たとえば、ステップの 1 つで、EAI システムが人間のワークフロー アプリケーションと対話して、完了までに数時間または数日かかるローンの承認を行う）もあります。^{[引用が必要]}

主なトポロジには、ハブアンドスポークとバスの 2 つがあります。それぞれに長所と短所があります。ハブアンドスポーク モデルでは、EAI システムが中心 (ハブ) にあり、スポークを介してアプリケーションと対話します。バス モデルでは、EAI システムがバスです (または、既存のメッセージ バスまたはメッセージ指向ミドルウェアの常駐モジュールとして実装されます)。^{[引用が必要]}

大企業の多くは、ゾーン化されたネットワークを使用して、ネットワーク指向の脅威に対する階層化された防御を構築しています。たとえば、企業には通常、クレジットカード処理 (PCI 準拠) ゾーン、非 PCI ゾーン、データ ゾーン、外部ユーザー アクセスをプロキシする DMZ ゾーン、および内部ユーザー アクセスをプロキシする IWZ ゾーンがあります。アプリケーションは複数のゾーンにまたがって統合する必要があります。この場合、ハブ アンド スポークモデルの方が適しています。^{[引用が必要]}

EAIシステムの各コンポーネントの実装には複数のテクノロジが使用されます。^{[引用が必要]}

バス/ハブ

これは通常、標準ミドルウェア製品 (アプリケーション サーバー、メッセージ バス) を拡張することによって実装されるか、スタンドアロン プログラム (つまり、ミドルウェアを使用しない) として実装され、独自のミドルウェアとして機能します。

アプリケーション接続

バス/ハブは、一連のアダプタ(コネクタとも呼ばれる) を介してアプリケーションに接続します。これらは、基盤となるビジネス アプリケーションと対話する方法を知っているプログラムです。アダプタは一方向通信 (単方向) を実行し、ハブからの要求をアプリケーションに対して実行し、アプリケーションで重要なイベント (新しいレコードの挿入、トランザクションの完了など) が発生したときにハブに通知します。アダプタは、アプリケーションに固有のもの (アプリケーション ベンダーのクライアント ライブラリに対して構築されるなど) またはアプリケーションのクラスに固有のもの (SOAP 、 SMTP 、 Action Message Format (AMF) などの標準通信プロトコルを介して任意のアプリケーションと対話できるなど) にすることができます。アダプタは、バス/ハブと同じプロセス空間に存在することも、リモートの場所で実行して、メッセージ キュー、Web サービスなどの業界標準プロトコルを介してハブ/バスと対話することも、独自のプロトコルを使用することもできます。Java の世界では、 JCAなどの標準によって、ベンダーに依存しない方法でアダプタを作成できます。

データ形式と変換

各アダプタが他のすべてのアプリケーションの形式との間でデータを変換する必要がないように、EAI システムでは通常、アプリケーションに依存しない (または共通の) データ形式を規定します。EAI システムは通常、アプリケーション固有の形式と共通形式間の変換を支援するデータ変換サービスも提供します。これは 2 つの手順で実行されます。アダプタは、情報をアプリケーションの形式からバスの共通形式に変換します。次に、これにセマンティック変換が適用されます (郵便番号を都市名に変換する、1 つのアプリケーションのオブジェクトを他のアプリケーションのオブジェクトに分割/結合するなど)。

統合モジュール

EAI システムは、任意の時点で複数の同時統合操作に参加している可能性があり、各タイプの統合は、異なる統合モジュールによって処理されます。統合モジュールは、特定のタイプのイベントをサブスクライブし、これらのイベントが発生したときに受信した通知を処理します。これらのモジュールは、さまざまな方法で実装できます。Java ベースの EAI システムでは、これらはWeb アプリケーション、EJB、またはEAI システムの仕様に準拠するPOJOである可能性があります。

取引のサポート

EAI システムは、プロセス統合に使用する場合、すべてのアプリケーションにわたるすべての統合操作を単一の包括的な分散トランザクション ( 2 フェーズ コミット プロトコルまたは補正トランザクションを使用) で実行することにより、アプリケーション間でトランザクションの一貫性も提供します。

現在、エンタープライズ アプリケーション統合に最適なインフラストラクチャ、コンポーネント モデル、標準構造を構成するものについては、さまざまな考え方があります。現代のエンタープライズ アプリケーション統合アーキテクチャには、次の 4 つのコンポーネントが不可欠であるという点で、コンセンサスが得られているようです。^{[引用が必要]}

1. セキュリティ、アクセス、および通信を処理する集中ブローカー。これは、統合サーバー ( School Interoperability Framework (SIF)ゾーン統合サーバーなど) またはサービス マネージャーとして機能するエンタープライズ サービス バス(ESB) モデルなどの同様のソフトウェアを通じて実現できます。
2. 標準データ構造に基づく独立したデータ モデル。標準データ モデルとも呼ばれます。XML と XML スタイル シートの使用は、この統一されたビジネス言語の事実上の標準、場合によっては法的な標準となっているようです。
3. 各ベンダー、アプリケーション、またはインターフェースが、そのアプリケーションとネイティブに対話し、集中ブローカーと通信できる単一のコンポーネントを構築できるコネクタまたはエージェント モデル。
4. API、データ フロー、システムへの関与ルールを定義し、標準化された方法でシステムとインターフェイスするコンポーネントを構築できるようにするシステム モデル。

データベースやユーザー インターフェイス レベルでの接続などの他のアプローチも検討されていますが、拡張性や調整性は確認されていません。個々のアプリケーションは、集中ブローカーにメッセージを公開し、そのブローカーから特定のメッセージを受信するようにサブスクライブできます。各アプリケーションは、ブローカーへの接続を 1 つだけ必要とします。この集中制御アプローチは、非常に拡張性が高く、進化しやすい可能性があります。^{[引用が必要]}

エンタープライズ アプリケーション統合は、メッセージ指向ミドルウェア ( MOM )などのミドルウェア テクノロジや、XMLやJSONなどのデータ表現テクノロジに関連しています。その他の EAI テクノロジでは、統合手段としてサービス指向アーキテクチャの一部としてWeb サービスを使用します。エンタープライズ アプリケーション統合は、データ中心になる傾向があります。近い将来、コンテンツ統合やビジネス プロセスも含まれるようになります。^[要出典]

2003 年には、EAI プロジェクトの 70% が失敗するという報告がありました。これらの失敗のほとんどは、ソフトウェア自体や技術的な問題ではなく、管理上の問題によるものです。Integration Consortium European の会長である Steve Craggs 氏は、EAI システムを使用する企業が陥りやすい 7 つの主な落とし穴を概説し、これらの問題の解決策を説明しています。^[5]

1. 絶え間ない変化: EAI の本質は動的であり、その実装を管理するには動的なプロジェクト マネージャーが必要です。
2. EAI 専門家の不足: EAI には多くの問題と技術的な側面に関する知識が必要です。
3. 競合する標準: EAI 分野においては、EAI 標準自体が普遍的ではないという矛盾が生じます。
4. EAI はツール パラダイムです。EAI はツールではなくシステムであり、そのように実装する必要があります。
5. インターフェースの構築は芸術です。ソリューションを設計するだけでは不十分です。ソリューションは、最終的な結果について共通の合意に達するために、ユーザー部門と交渉する必要があります。インターフェース設計に関する合意が得られないと、さまざまなシステムのデータ要件間のマッピングに過度の労力がかかります。
6. 詳細の喪失: 初期の段階では重要ではないと思われた情報が、後になって重要になる場合があります。
7. 説明責任: 多くの部門で多くの相反する要件があるため、システムの最終的な構造に対する説明責任が明確である必要があります。

以下の領域では他の潜在的な問題が発生する可能性がある: ^{[引用が必要]}

• EAI作業の集中的な調整の欠如。^[6]
• 新たな要件: EAI 実装は、将来の変更に対応できるように拡張可能かつモジュール化されている必要があります。
• 保護主義: データが統合されるアプリケーションは、技術的、文化的、政治的な理由から他の部門とデータを共有したくない異なる部門に属していることが多い。

• エンタープライズアーキテクチャフレームワーク
• エンタープライズアプリケーション統合の戦略
• ビジネスセマンティクス管理
• データ統合
• 企業情報統合
• エンタープライズ統合
• エンタープライズ統合パターン
• エンタープライズ サービス バス
• 汎用エンタープライズリファレンスアーキテクチャと方法論
• 統合アプライアンス
• 統合コンピテンシーセンター
• 統合プラットフォーム
• システム統合

• 健康レベル7
• オープンナレッジイニシアチブ
• JavaによるOSS
• 学校相互運用性フレームワーク(SIF)