サービスタイヤを使用した情報ランドスケープの構築

統合ランドスケープの主な問題



今日の世界では、ビジネスアプリケーションは他のアプリケーションとの統合がなければほとんど存在できません。 統合により、最も単純なデータ交換を実装し、複雑な複合アプリケーションを構築できます。



ただし、蓄積されたアプリケーションパークには、そのアーキテクチャ、プラットフォーム、および「年齢」の違いにより、統合レベルの問題が多数あります。



このタイプの主な問題は次のとおりです。



•さまざまなアプリケーション統合メカニズム

•データ形式の不一致または部分的な重複、データ転送の冗長性

•単一の管理ポイントの欠如

•統合スキームのスケーリングの難しさ

•サブスクライバーアプリケーションを変更する必要性。



A.さまざまな統合メカニズム



ほとんどの設計アプリケーションには、1つまたは別の統合インターフェイスがあります。 ただし、各ベンダーは、統合スキームにおけるアプリケーションの役割を独自に理解しています。 そして、多くの場合、彼はアプリケーションを統合環境の中心に置いています（特に金融システムプロバイダーの罪）。 このビジョンに基づいて、アプリケーションの統合部分のアーキテクチャが構築されます。 ただし、アプリケーションはさまざまな時間間隔で開発されるため、通常、一定の期間で優位を占める統合テクノロジを受け取ります。 また、「エゴセントリック」アーキテクチャのため、最も一般的な技術の1つまたは2つが最も頻繁に配置されます。 その結果、すべての統合が、それらに組み込まれた統合モデルに基づいて構築されることを期待する「エゴイストアプリケーション」のセットがあります。



B.一致しないデータ形式



この問題には、上記で説明したものと同じ根源があります。 各アプリケーションは、統合環境の中心に位置し、独自のルールでプレイすることを計画しています。 アプリケーションは、データモデルとアルゴリズムベースに基づいて、データの形式と構成を記述します。 ほとんどの場合、送信されるデータは、フォーマットを変更するオーバーヘッドを回避するために、アプリケーションの内部データモデルとの完全な同一性を導こうとしています。 その結果、データが部分的または完全に、異なるメディア形式までの形式で一致しない状況があります。 多くの場合、単純な統合スキームでは、同じデータを異なる形式で複数回送信する必要が生じます。



C.単一の管理ポイントの欠如



単一のコントロールポイントが存在しないことは、統合ランドスケープの構築における基盤の1つです。 各アプリケーションが独自の観点から統合を管理しようとすると、状況はすぐに管理が不十分になります。 監視と保守のために、場合によっては相互に関係のない一連の対策を計画する必要があります。 特定のアプリケーションに関連する能力の中心があります。 ただし、単一プラットフォーム、共通プロトコル、共通フォーマット、エンドツーエンドのドキュメントなど、企業の完全自動化への統合アプローチにより、問題の一部を解決できることに注意する必要があります。 しかし、メソッドの透明性と有限性にもかかわらず、実際にはこれは非常にまれです。



D.統合スキームのスケーリングの難しさ



集中管理に関連する問題は、統合スキームのスケーリングの問題にスムーズに発展します。 スケーリングを計画するには、情報をリンクする必要があります。誰が、いつ、どのボリュームおよび構成でデータを送信および予測し、どのフォーマットを使用し、プロトコルをサポートするか。 このような状況では、情報パッケージの1つでもフォーマットを変更すると、人件費とダウンタイムが増加する可能性があります。



E.サブスクライバーアプリケーションを変更する必要がある



データのロードとアンロードを保証するには、サブスクライバアプリケーションの変更が必要になることがよくあります。 これにより、統合環境を拡張しながらアプリケーションを絶えず変更する必要が生じ、変更を行っている間はアプリケーションのダウンタイムが発生し、アプリケーションの計算負荷が増加して統合が保証されます。 サブスクリプションアプリケーションが実装されている各プラットフォームの専門家が必要です。 また、アプリケーションプロジェクトチームによる変更を計画する際には、統合モデルに必要な改善を考慮して計画する必要があるため、サブスクライバシステムの変更も複雑になります。 同時に、プロジェクトチームは、統合関係のアーキテクチャに突入するか、この知識を持つ専門家を追加で関与させる必要があります。



統合ランドスケープを構築するための主なアプローチ



ESB（Enterprise Service Bus）クラスの最新製品が、統合ランドスケープのリストされている問題に対する包括的なソリューションを正確に目指していることは周知の事実です。



さまざまなアプローチとコンポーネントベースにもかかわらず、それらはすべて次の基本原則を公言しています。



•形式の標準化

•コネクタのライブラリを介した単一ネットワークへの加入者システムの接続の確保

•メッセージ配信の保証

•処理およびルーティングルールのグローバルレベルへの転送

•統合されたロギングおよびモニタリングメカニズム

•高度なスケーリングツール。



これらの原則に従って、統合を構築するには、通常、多少標準的な作業を実行します。 最初の段階では、送信データの構造の分析的研究と標準化が実行されます。 次のアプローチを使用できます。ソースシステムからのすべてのデータを均一な構造にする方法、または配信前にサブスクライブシステムの構造にデータを減らす方法。 多くの場合、データ構造への混合アプローチが使用されます。 最初のオプションでは、受信後すぐに、送信されたデータを標準に戻し、将来このデータを使用できます（たとえば、その内容に基づいたデータの動的なルーティングのため）。 必要に応じて、情報パケットテンプレートが生成されます。 このアプローチのもう1つの利点は、この場合、統合プロセスのすべての参加者が統合境界のデータ構造を等しく理解することです。



2番目のアプローチでは、データ変換のオーバーヘッドを削減し、それを必要とするサブスクライブシステムに対してのみ受信時に実行することができます。 混合スキームでは、変換はデータ型で分割されるか、データ配信ルートのすべてのポイントで常に実行されます。 これは、統合ランドスケープの後続のメンテナンスを簡素化するために行われます。 計画されたデータ構造を知っており、監視ツールと自動検証で明確に追跡できるため。



フォーマットとデータ構造を決定した後、情報移動のプロセスが形成されます。 「ルーティング」と「ストリーミング」のデータ配信スキームを区別します。 それらは互いに非常に似ていますが、いくつかの違いがあります。



ルートパターン。



このスキームは、送信側システムがデータコンシューマーを認識してはならないことを前提としています。 コンシューマシステムは、データプロバイダーに依存しないようにします。 ネットワーク内で発生したという事実に基づいて、購読しているデータを単に受信します。 これにより、データをバッファリングおよび集約する機能を備えた疎結合回路を構築できます。 このスキームは、データを取得、処理、およびロードするためのメカニズムが別のプロセスに割り当てられ、ルーティング手順に直接関係しないという点でも異なります。



このスキームを実装するには、以下を決定する必要があります。



•抽出のデータ型と方法

•受信者のリストおよび指定された受信者へのこのタイプのデータの配信条件

•ルートリスト

•一連の変換手順。



各オブジェクトについて、このオブジェクトのみに関連するアクションが実行されることを理解することが重要です。 つまり、ソースシステムの場合、提供するデータの種類と、それらを抽出する方法を決定します。 取得したデータの変換メカニズムが決定されます（必要な場合）。 次に、サブスクライバーシステムは、受信するデータの種類、読み込みメカニズム、および予備変換スキーム（必要な場合）も決定します。 ルートは、各サブスクライバシステムへのさまざまなタイプのデータの配信条件を記述します。 このアプローチにより、発生する変更に合わせて統合スキームを簡単に拡張できます。



このスキームの欠点には、データ通過の履歴のエンドツーエンドの透明性の低下が含まれます。 このシステムの欠陥は、ほとんどの場合、監視ツールによって解決されます。



ストリーミングスキーム。



このアプローチにより、統合スペシャリストはデータフローの全フローを説明します。 ソースシステムとレシーバシステムは、フロー内で厳密に相互接続されています。



フローを完全に説明するには、次のオブジェクトとメカニズムが必要です。



•利用可能なソースシステムのリスト

•ソースシステムへの接続方法

•各ソースシステムのデータ抽出方法

•データ変換方法

•データを分割および追加する方法

•サブスクライバシステムのリスト

•サブスクライバシステムへの接続方法

•各サブスクライバシステムのデータ転送方法。



最も一般的に使用されるアプローチは、単一のスレッドが単一のデータ型で動作する場合です。 ただし、1つのデータ型を操作するために従来のストリームモデルは必要ないことを理解することが重要です。 そのようなシステムの設計は、フローのリストの定義、各ストリーム内の情報の構造化によって実行されます。 次に、情報の発信元、受信者のリスト、および受信者に必要な変換が決定されます。



ストリームの各記述では、上記のオブジェクトとメカニズムのリストを再構成する必要があることを理解することが重要です。



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



•さまざまなストリームのデータによる部分的な交差の可能性。

•いくつかのタイプのデータで動作するストリームは、完全なスキームの理解を複雑にし、ストリーム内のデータ管理スキーム（ストリーム内のストリーム）を必要とします。 スレッドのネストレベルが増加すると、難易度は高まります。

•各ストリームには、隣接するストリームで同様の手順が使用されている場合でも、すべての抽出、変換、接続などの手順の説明が必要です。 統合モデルの規模を変更する複雑さが増しています。



いずれのアプローチでも、データ変換スキームは統合モデルの重要なコンポーネントです。 これらのスキームが説明されている場所のみが異なります。 最初のケースでは、変換スキームはシステム（ソースシステムの出力、サブスクライバーシステムの入力）に関して説明され、このソースの単一のデータ処理手順を表します。 2番目の場合、変換スキームはデータストリーム内で記述され、いくつかの独立したセクションに分割できます。 ポイントツーポイント統合モデルとは異なり、変換手順を使用すると、アプリケーションの負荷を大幅に削減できることに注意してください。 実際には、変換スキームを備えたESBを使用すると、クライアントアプリケーションは交換を提供するというすべての非典型的な負担から解放されます。 典型的な問題の1つであるサブスクライバシステムを改良する必要が解決されます。



通常、変換スキームには次の機能があります。



•送信データの形式の変更

•送信データの構造の変更

•データの強化

•ボリュームを減らすためのデータの枯渇

•情報パッケージをいくつかに分割

•複数の情報パッケージを1つにマージする

•適用されたビジネスルールによるデータの検証。



また、変換スキームの開発により、送信されるデータの量を大幅に削減できます。 これは、データがアトミックに必要なボリュームに一度だけアップロードされるという事実により実現されます。 この場合、アンロードイニシエーターは、データ変更イベント、またはデータ強化を実行するために必要な量の変換スキームからのデータ要求です。



データの抽出、変換、および読み込みのすべてのアクションは、さまざまな形式のログに記録および記録されます。 最も一般的なアプローチは、このようなログを保存するために別のサーバーを割り当てることです。 これにより、特殊な監視システムを接続して、人間が読める形式のデータを迅速に取得できます。



ログストレージは、運用とアーカイブに分かれています。 オンラインストレージの場合、循環的に書き換え可能なログファイルがよく使用されます。ログファイルは、いっぱいになるとアーカイブストレージにダンプされます。



ESBオブジェクトの状態と機器のパフォーマンスカウンターは別々に記録されます。 これにより、データの通過とシステム全体の現在の状態の完全な運用状況を構築できます。 最も高度なソリューションには、ネットワークステータスの事前診断が含まれます。 この診断により、潜在的な脅威を排除するために、統合ネットワークのメンテナンスを実行する従業員に問題の可能性について事前に通知することができます。



その結果、明確で透過的なデータモデルがあり、単一のポイントから管理され、集中監視のさまざまな手段が提供されています。



***

情報ランドスケープを構築すると、ポイント統合に存在する多くの問題を解決できますが、ソリューションの設計と選択には思慮深いアプローチが必要です。 実装されたアプローチの長所と短所を評価し、コネクタ、変換ブロックを備えた将来のランドスケープのカバレッジを最大化し、監視システムと予防的診断を開発した製品を選択する必要があります。 次に、データ伝送スキームの設計へのアプローチを選択し、どのアプローチがあなたの場合に最も望ましいかを評価します。 その結果、完全かつ一元化されたプロセス制御を備えた安定したスケーラブルな統合モデルが得られます。



テクニカルディレクター、スタニスラフピゴルキン