メッセージベースの統合。 他のアプローチとの利点と違い

各企業は、その存続期間中に、ビジネスプロセスを実装するためのさまざまなソフトウェアソリューションを蓄積します。 その結果、単一のソフトウェア製品の範囲を超えてデータと機能に依存するエンドツーエンドのビジネスプロセスを実装するために、これらのソフトウェア製品間の相互作用を保証するタスクが発生します。



アプリケーションを統合する主な方法：



•ファイル共有

•共通データベースを介した交換

•リモート関数呼び出し

•会社のサービスバス（MQ、ESB）

ファイル共有

この交換方法は、最新のすべてのオペレーティングシステムの基盤であるファイルメカニズムに基づいています。 ファイル共有の主な利点は、ソースシステムがコンシューマシステムについて何も知る必要がないことです。 データファイルを作成し、リポジトリ（たとえば、ファイルディレクトリ）に配置するだけで、統合プロセスの他の参加者がそこから情報を取得できます。 この統合アプローチを主なものとして使用しているソフトウェアソリューションはかなりあります。



ファイル共有による統合の利点は次のとおりです。



•統合アプリケーション間の強力なリンクの欠如

•追加のソフトウェアをインストールする必要はありません

•一般的な実装の容易さ、開発者の高い資格の欠如



ただし、このスキームには、統合モデルの開発時に考慮する必要があるいくつかの重要な制限があります。



•ほとんどのアプリケーションはむしろ「利己的」に動作し、唯一の消費者などのファイルで動作します。 その結果、ファイルへのアクセスに関してシステムが互いに競合する状況がしばしば発生します。 これは、データ配信の確認がファイルを特別なディレクトリに移動するか削除する場合に特に顕著です。



•最初の問題を回避するために、消費者ごとに個別のファイルが生成されるアプローチがよく使用されます。 ただし、この場合、ソースシステムによって生成されるデータ量の増加、発信トラフィックの増加、共有フォルダーにファイルを配置するための時間遅延の増加など、いくつかの新しい問題が一度に発生します。 このアプローチには別の問題があります。ファイルを正しく作成するために、ソースシステムは、データの種類ごとに誰がこのデータを消費するかを明確に想像する必要があります。



•多くのシステムには、ファイルシステムと対話するための組み込みツールがありません。 ファイルの記録または変更のイベントにサブスクライブしたり、ファイルへの書き込みが完了したイベントを追跡したりする機能は提供されません。 このようなシステムでは、ファイルリソースの定期的なポーリングのサイクルを実装する必要があります。これにより、システムに追加の非典型的な負荷がかかります。 信頼性の高いファイル交換を確保するために、データのアップロードとダウンロードの規制期間を明確に別に設定する必要がある場合があります。 これは、統合システムの一時的な非同期化につながります。



•交換はポイントツーポイントで実行されます。 ルートとデータフローの履歴を集中的に追跡することは非常に困難です。 統合モデルの困難な集中管理。

共有データベースを介した共有

共通データベースを介したデータ交換は、ファイルを介してデータを転送する方法の開発であり、その欠点を克服します。 このアプローチでは、統合プロセスのすべての参加者が接続できる単一の統合データベースが強調表示されます。 ソースシステムはこのデータベースにデータを配置し、コンシューマシステムは必要なデータのみを読み取ります。



主な利点は次のとおりです。



•競争力のあるデータへのアクセスを制限するための組み込みDBMSメカニズム。 記録手順が完了するまで、データを読み取ったり変更したりすることはできません。



•データを読み書きするための統一されたメカニズム。 すべてのアプリケーションは、データを操作するための標準DBMSメカニズムで動作します。 これにより、変更の開発と導入に対する一般的なアプローチを整理できます。



•統合プロセスのすべての参加者のための単一のデータ形式。 意味的不協和の問題は解消されました。 すべてのアプリケーションはデータを統一された型に変換し、どのアプリケーションも現在のデータ型とその構造に関する完全な知識を持っています。



•ファイル共有に比べてデータ配信の高速化。 このスキームでは、データにアクセスするための規制期間を割り当てる必要はありません。データベースにコミットされた直後に読み取ることができます。



•データへのアクセスを記録するための組み込みのDBMSメカニズムにより、配信拒否の原因を調査できます。



スキームの欠点は次のとおりです。



•単一のデータベースは、統合ループ全体の障害ポイントです。 単一のデータベースに障害が発生すると、統合スキーム全体の機能が不可能になります。 アプリケーションは、未送信の情報を蓄積する独自のメカニズムと、統合データベースへのアクセス状態を監視するメカニズムを提供する必要があります。



•交換レートが高い場合、統合データベース自体がボトルネックになる可能性があります。 データへの競合アクセスが表示され、データ変更のブロックが可能です。



•かなり高度なアプリケーション接続。 交換スキームに変更を加えるには、それぞれのシステムの調整された変更が必要になります。



•単一のフォーマットで作業すると、保存されたデータが統合プロセスのすべての参加者を満たさなければならないため、統合データベース設計を設計する際の要件が高くなります。 データは、統合プロセスのすべての参加者が明確に読み取れる形式と構造で保存する必要があります。



•統合ランドスケープのすべての参加者は、統合データベースに接続できる必要があります。 統合プロセスのすべての参加者が最新のDBMSの使用をサポートしているわけではないことを理解しておく必要があります。 これは、DBMSを選択する際の制限要因であり、送信のオーバーヘッドの増加につながる可能性があります。 さらに、アプリケーションがサードパーティのDBMSからの書き込みおよび読み取りのメカニズムをまったく持たないことも珍しくありません。



•分散ネットワークで作業する場合、過剰なトラフィックが表示されます。 コンシューマシステムの半分が統合データベース以外のセグメントに配置されているが、ソースシステムがコンシューマシステムと同じセグメントにある場合、このセグメントのデータは統合データベースに配置され、コンシューマシステムによってのみ読み取られる必要があります。 セグメント間で冗長なデータ転送が行われます。



•送信元システムは消費者システムによるデータ受信の離散性に影響を与えないため、送信データと受信データの間に矛盾があります。 このような状況では、受信者システムが受信したデータの完全性と一貫性を追跡することは非常に困難です。 関連データの配信の遅延のために受信データを処理できない場合の可能性が高く、いつ処理できるのか（不明なデータの受信時）がわかりません。 後処理およびデータストレージのメカニズムの編成が必要です。

リモート関数呼び出し

上記のアプローチ（ファイル共有および共通データベースを介した共有）は、機能の面ではなく、データの面でアプリケーション間の相互作用を保証することを目的としています。 機能レベルでの相互作用を保証するために、リモート機能を呼び出すためのさまざまなテクノロジーとメカニズムが使用されます。



このアプローチを実装するには、リモートプロシージャコールメカニズムを提供する次のテクノロジを使用できます。



•COM

•CORBA

•SOAP

•Java RMIなど



この場合、アプリケーションは、データへのリモートアクセスを提供するメカニズムを独自に実装する必要があります。



このアプローチの主な利点は次のとおりです。



•中間データウェアハウスを編成する必要はありません。 消費者システムは、そのようなニーズが生じたときに独立してデータを要求します。



•データの一貫性。 ソースシステムは、すべてのデータ整合性機能を含む予備的なデータ準備を実行します。



•データ取得の速度。 中間リポジトリーからデータを記録および受信する必要性に関連する遅延はありません。



•データの「プル」および「プッシュ」スキームを整理する機能。 前者の場合、ソースシステムはデータを受信するために必要な機能を提供し、サブスクライバーシステムはデータを受信する必要があるとすぐにそれを呼び出します。 2番目のケースでは、ソースシステムはデータをロードする機能を提供します。 送信は、対応するイベントが発生したときにソースシステムによって実行されます。



このアプローチの欠点は次のとおりです。



•高度なアプリケーション接続。 コンシューマシステムのパフォーマンスは、ソースシステムの可用性とパフォーマンスに完全に依存し始めます。 システムでは、統合プロセスの他の参加者との通信が不足している期間、統合データを保存するデータバッファを実装する必要があります。



•統合の状況を拡大する場合、ソースシステムとコンシューマシステムの改善が必要です。



•リモートプロシージャを提供するためのさまざまなテクノロジーを実装するシステムが統合ランドスケープに含まれる場合、たとえば、一部のアプリケーションはCORBAおよび一部のSOAPを実装します。すべてのアプリケーションがすべてのアプローチを実装できるか、1つのテクノロジーへの交換を減らすプロキシアプリケーションのレイヤーが表示されます。



•技術の違いにより、システムは異なるデータ構造とタイプで動作できます。 追加のデータ変換コストがあります。



•交換レートが高いと、アプリケーションは、ビジネスプロセスのサービスではなく、統合層のサービスに、より多くのリソースを費やし始めます。

エンタープライズサービスバス

アプリケーション機能へのアクセスを伴うデータ転送の問題に対する包括的なソリューションを実現するために、特殊な製品を介してメッセージを転送するアプローチが使用されます。 従来、これらの製品は、メッセージキューサービス（MQS）とエンタープライズサービスバス（ESB）の2つのタイプに分類できます。 統合を構築する一般的なアプローチは次のとおりです。システムは専用のコネクタを介して統合バスに接続されます。 コネクタの主なタスクは、システムにデータを受信し、システムからデータを送信するためのチャネルを提供することです。 ソースシステムのタスクは、データをコネクタに転送することであり、コンシューマシステムへのメッセージのルーティング、変換、および配信は、その参加なしで実行されます。



コネクタはシステムに可能な限り近くに配置され、ネットワーク接続がない場合でもデータ転送の可能性を保証します。これにより、データストレージと送信のオーバーヘッドから統合に関係するシステムをアンロードします。



このシステムの主な利点は次のとおりです。



•統合に関係するシステム間の弱い接続。 さらに、適切に構築された統合モデルでは、システムは統合ランドスケープの他の参加者について何も知りません。 すべての作業は、サービスバスへのメッセージの送信とバスからのメッセージの受信に削減されます。 これにより、以前に検討されたすべてのシステムに比べて最高レベルの柔軟性とスケーラビリティが実現します。



•データ変換の機会。 さまざまなデータ形式用に設計されたアプリケーションを、変更することなく統合できます。 これは、システムによるデータ処理のコストを削減するのに役立ちます（データはソースシステム形式で一度送信され、「ネイティブ」形式でコンシューマシステムに受け入れられます）。また、システム統合に統合することもできます。 さらに、データ変換のコストは統合システムでは発生しません。



•データルーティング。 サービスバスの最も重要なメカニズムの1つ。これにより、統合プロセスの参加者の依存性と接続性を劇的に減らすことができます。 ルーティングメカニズムを使用すると、ソースシステムはバスにメッセージを1回送信するだけで済みます。 彼女は、誰がこのメッセージを受け取るべきか、彼がメッセージを受け取る準備ができているかどうかなどについての知識を必要としません。 メッセージは、現在のルートに従ってすべての消費者に配信されます。



したがって、スキームをスケーリングする場合、すべてのシステムに変更を加える必要もありません。 データコンシューマを追加または削除して、ルートを変更するだけで十分です。 また、特定の条件に従ってメッセージを配信することもできます。 さらに、システム自体はルートを通過するための条件の決定に関与しません。つまり、システムに変更を加える必要なく、この動作を簡単に変更できます。



•データ配信の保証。 エンタープライズサービスバスのこのメカニズムにより、安定性の低いチャネルでのデータ配信スキームが大幅に簡素化され、ソースシステムからの負荷が軽減されます。 配信チャネルが使用できないときに、通信チャネルとメッセージの中間リポジトリの可用性をチェックするメカニズムを実装する必要はありません。 また、このメカニズムにより、配信確認メカニズムの実装に対するアルゴリズムの負荷を軽減できます。 この機能は、サービスバス統合メカニズムのレベルで実装されます。



•データ転送の保護。 多くの場合、送信中に機密データの漏洩が正確に発生することは秘密ではありません。 バスは、送信データの暗号化を提供し、安全なネットワーク接続もサポートします。



•一元化された統合スキーム管理は、あらゆる統合ランドスケープの重要なコンポーネントです。 このアプローチにより、初期セットアップ、スケーリング、および回路全体の健全性の維持のオーバーヘッドが大幅に削減されます。 また、必要なコンピテンシーを統合可能なシステムにスプレーすることなく、1か所に集中させることができます。



•状態の診断。 特殊なサービスタイヤを使用する重要な機能は、診断メカニズムです。 これらのメカニズムを使用すると、データ転送と統合に関係するシステムの状態の両方に関連する問題を特定することができます。 最も先進的なシステムは、予防的な診断ツールを提供します。 このタイプの診断により、問題が完全に顕在化する前の初期段階で潜在的な問題を特定し、先取りアクションのセットをタイムリーに実装できます。



モデルの主な欠点は次のとおりです。



•特殊なソフトウェア製品（MQ、ESB）の取得とサポートの追加費用。 多くの場合、追加のサーバーリソースを割り当てる必要があります。



•これらのソフトウェア製品に関するスタッフトレーニングの必要性。

統合方法の選択基準

特定の統合方法を選択するための基準は何ですか？ いくつかの主要な基準を区別できますが、特定の基準の重みは、現在の状態と解決すべきタスクによって決まることに留意してください。



• 選択した統合方法を使用するすべての統合ループアプリケーションの機能



さまざまなアプリケーションをさまざまなアーキテクチャスタイルと開発パラダイムで実装できることは周知の事実です。 統合メカニズムを提供するアプリケーションがありますが、そのようなメカニズムを持たないアプリケーションもあります。 1つの統合メカニズムを実装するアプリケーションがあります。 たとえば、「ファイル共有」統合方法を選択する場合、統合ループのすべてのアプリケーションがファイルを交換でき、各アプリケーションが提供する形式で動作できることを確認する必要があります。



• アプリケーションを変更する機能



以前に表明された基準に基づいて、アプリケーションを完成させて、集積回路への関与を保証する可能性を評価することが必要になります。 また、市場のスペシャリストの完成と可用性のための総人件費を評価する必要があります。



• 信頼性の要件



データ配信の信頼性を確保するための要件、配信の確認が必要かどうか、以前に送信されたデータの再配信が可能かどうか、信頼性を確保するために使用されるメカニズムがサポートされているかどうかを評価する必要があります。



• アプリケーションの接続性



選択した統合モデルに応じて、アプリケーションは、さまざまな程度の結合剛性を持つ統合ループに関与します。 所定の結合剛性を提供する能力を評価する必要があります。 たとえば、リモート関数を呼び出すことでアプリケーション統合を使用する場合、コンシューマシステムがないためにデータを転送できない場合に、アプリケーションが回路で動作する準備ができているかどうかを理解する必要があります。



• データ配信の時間遅延



選択した統合のタイプと送信される情報の形成へのアプローチにより、データ転送の頻度と速度に制限が課せられます。 データ配信の遅延が企業のビジネスプロセスに与える影響を評価する必要があります。



• データ保護要件



システム統合中のデータ保護の要件を評価する必要があります。 保護は、データを暗号化するか、安全な伝送チャネルを使用して実行できます。

結論

以前に検討した統合パターンに選択基準を適用する場合、次の結論を定式化できます。



•ファイル交換は、低い交換レートと統合回路に含まれる少数のシステムを備えた統合モデルで使用できます。 統合可能なシステムの数、交換の強度と複雑さの増加に伴い、そのようなアプローチは適用しないほうがよいでしょう。



•共通データベースを介した共有の使用により、ファイル共有の問題の一部が取り除かれますが、多くの理由により、複雑で集中的な統合環境での使用は推奨されません。統合データベースでは、平均データ交換レート。 さらに、統合データベース自体がスキーム全体のボトルネックになる可能性があります。



•リモート関数呼び出しは、単一の技術スタックで交換を編成するのに適しています。 ほとんどの場合、新しいデータを使用して作業するためには、システムの改良が必要です。 イベントモデルの形成中の高速データ交換。 さらに、このアプローチの特徴は、メンテナンスとスケーリングが非常に複雑であることです。



•エンタープライズサービスバスを介したメッセージングは​​、少数のシステムと単純な統合環境でも、本質的に最もバランスが取れています。 交換レートが高く、アプリケーションの接続性が低いため、このようなスキームは、多数のアプリケーションをその後のソリューションのスケーリングに統合するのに適しています。



したがって、サービスバスによって実装されるメッセージメカニズムを介したデータ交換は、データ交換を整理し、統合スキームの作成に関与する開発者の注意を引くのに最も適していると断言できます。 適切なサービスタイヤが選択されていれば、このような選択は時間、コスト、神経を大幅に節約できます。



スタニスラフ・ピゴルキン