上級システムアーキテクト向けソフトウェア試験 Enterprise Application Integration EAI

概要

企業の情報化構築の過程では、統一された計画や全体的なレイアウトが欠如しているため、複数の情報アイランドが形成されることがよくあります。情報がサイロ化するとデータの一貫性が保証されず、情報の共有やフィードバックができず、繰り返しの収集と入力が必要になります。情報アイランドは企業の情報化における重要なマイナス要因であり、その主な原因には、技術的要因と管理的要因、およびビジネスプロセスと標準的要因が含まれます。さまざまなシステムが情報を交換できるように、多数の情報アイランドをどのように接続するかは、多くの企業が現在直面している問題です。

このとき、時代の要請に応じて、ソフトウェア、ハードウェア、ネットワークの統合、およびソフトウェアレベルの統合技術であるエンタープライズアプリケーションインテグレーション (EAI) などの統合技術が登場しました。

EAI テクノロジーは、情報の孤島を排除し、複数の企業情報システムを接続し、シームレスな統合を実現して、それらを全体として機能させることができます。EAI は企業情報システムの発展とともに発生し、進化し、企業の価値志向が EAI 技術開発の原動力となり、EAI の実現が企業の競争優位性の向上を促進します。

プレゼンテーション統合、データ統合、制御統合、アプリケーション統合などを含み、電子商取引や企業間のアプリケーション統合を実装するほとんどの企業に適しています。データ統合の前に、まずデータを識別してカタログ化する必要があります。データ統合はホワイトボックス統合ですが、表現統合と制御統合はブラックボックス統合です。

EAIで接続されるアプリケーションには、各種電子商取引システム、ERP、CRM、SCM、OA、データベースシステム、データウェアハウスなどが含まれます。単一企業の観点から見ると、EAI にはプレゼンテーション統合、データ統合、制御統合、ビジネスプロセス統合などの複数のレベルと側面が含まれる場合があります。もちろん、複数の企業間でアプリケーションの統合を行うこともできます。

プラットホーム

エンタープライズ統合プラットフォームは、ハードウェア、ソフトウェア、ソフトウェアツール、システムなどの複雑な情報環境における情報システムの開発、統合、および共同運用をサポートするソフトウェアサポート環境です。基本的な機能は次のとおりです。

通信サービス: 分散環境で透過的な同期/非同期通信サービス機能を提供するため、ユーザーとアプリケーションは特定のオペレーティングシステムやアプリケーションが配置されているネットワークの物理的な場所を気にする必要がなく、透過的な通信を通じてタスクを完了できます。関数呼び出しまたはオブジェクトサービス必要な通信サービス要件
情報統合サービス: アプリケーションに対して透過的な情報アクセスサービスを提供し、異種データベースシステム間のデータ交換、相互運用性、分散データ管理、共有情報モデル定義(または共有情報データベースの構築)を実現することで、アプリケーション、サービス上で統合プラットフォームを実行可能またはクライアントは、一貫したセマンティクスとインターフェイスを使用してデータ (データベース、データファイル、アプリケーションインタラクション情報) にアクセスして制御できます。
アプリケーション統合サービス: 対応するアプリケーションへのアクセスは、高レベルのアプリケーションプログラミングインターフェイスを通じて実現されます。これらの高レベルのアプリケーションプログラミングインターフェイスは、さまざまなアプリケーションを接続するために使用されるさまざまなアダプターまたはプロキシに含まれています。これらのインターフェイスは、機能またはオブジェクトサービスの形式でプラットフォームのコンポーネントモデルに情報を提供し、ユーザーが元のシステムを変更せずに（元のシステムの機能に影響を与えることなく）新しい機能を元のシステムに追加できるようにします。対応するアクセスインターフェイスは相互接続できます。さまざまなテクノロジーで実装された既存のシステムを統合し、アプリケーションのデータ交換とアクセス操作を提供することで、さまざまなシステムが相互に連携できるようにします。
二次開発ツール: ユーザーが特定のアプリケーションを開発するのを支援するために、統合プラットフォームによって提供される一連のサポートツール (データ変換用アダプターやアプリケーションパッケージサービスなど)。目的は、ユーザーによるエンタープライズ統合プラットフォームの実装プロセスを簡素化することです。 (特定のアプリケーション)、インターフェース) 開発作業
プラットフォーム運用管理ツール: エンタープライズ統合プラットフォームの運用管理および制御モジュール。エンタープライズ統合プラットフォームシステムの静的および動的構成、統合プラットフォームアプリケーションの運用管理と保守、イベント管理とエラー管理などを担当します。ネーミングサービス、ディレクトリサービス、プラットフォームの動的・静的構成、主要データの定期的なバックアップなどにより、サービスプラットフォーム全体のシステム構成と安定稼働を維持します。

分類

統合を示します

インターフェイス統合としても知られる表現統合は、比較的原始的で最も浅いレベルですが、一般的に使用される統合です。ユーザーインターフェイスはパブリック統合ポイントとして使用され、元々散在していたシステムインターフェイスを新しいインターフェイスに集約して入り口を統一します。
ここに画像の説明を挿入します
下図に示すモデルは、統合がブラックボックス統合であることを示しており、プログラムやデータベースの内部構造を理解する必要はありません。一般的に使用される統合テクノロジには、主に画面キャプチャおよび入力シミュレーションテクノロジが含まれます。表現の統合は通常、次の状況で使用されます。

既存の端末ベースのアプリケーションシステム上で PC ベースのユーザーインターフェイスを構成する
見た目は統一されているが複数のシステムで構成されているアプリケーションシステムをユーザーに提供する
表示インターフェース上でのみ統合が可能な場合

これは、統合の実装が非常に単純かつ不完全であることを意味し、単なる外部の装飾であり、追加の統合インターフェイスがシステムのパフォーマンスのボトルネックになる可能性もあります。

データ統合

アプリケーション統合とビジネスプロセス統合の基礎。さまざまなソース、形式、特性からのデータが論理的または物理的に有機的に集中され、企業に包括的なデータ共有を提供します。ETL、データウェアハウス、フェデレーテッドデータベースはすべてデータ統合とみなすことができます。

制御統合とビジネスプロセス統合を完了するには、まずデータとデータベースの統合問題を解決する必要があります。統合する前に、まずデータを識別してカタログ化する必要があり、さらに、データがデータベースシステム内で確実に分散および共有されるようにメタデータモデルを決定する必要があります。したがって、データ統合はホワイトボックス統合であり、そのモデルは図に示されています。
ここに画像の説明を挿入します
データ統合に使用できるさまざまなミドルウェアツールが多数あります。たとえば、バッチファイル転送、つまり、元のシステムと新しく開発されたアプリケーションシステムの間で特定の方法またはあらかじめ決められた方法でファイルを転送すること、さまざまな種類のデータベースシステムにアクセスするための ODBC (Open DataBase Connectivity) 標準インターフェイス: データベースアクセスミドルウェア技術分散データベースなどへの接続を提供します。通常、データ統合は次の場合に使用されます。

複数の情報源から生成されたデータを総合的に分析し、意思決定を行うことが必要です。
何かを処理するには、複数のアプリケーションが共通のリポジトリにアクセスする必要があります。
あるデータソースからデータを取得して別のデータソースを更新する必要がある場合、特にデータソース間のデータ形式が異なる場合。

比較的に、データ統合はプレゼンテーション統合よりも柔軟です。ただし、ビジネスロジックが頻繁に変更される場合、データ統合は困難に直面します。

企業は、社内データベースのデータを統合したいと考えています。統合システムのビジネスロジックが比較的単純で、データベース内のデータの単一テーブルのみを使用してビジネス機能を実装できる場合は、データ交換と処理にアクティブな記録を使用し、テーブルをレコード; 統合システムのビジネスロジックの場合は比較的複雑であり、ビジネス機能を実現するにはデータベース内のさまざまなテーブルの接続操作を通じてデータを取得する必要があります。現時点では、データ交換とデータマッピングにデータマッピングを使用する方が適切です。処理。

制御統合

機能統合、アプリケーション統合、API 統合とも呼ばれ、ビジネスロジック層でのアプリケーションシステムのブラックボックス統合です。統合を制御する統合ポイントはプログラムコードに格納されており、パブリック API を使用するだけで統合ポイントにアクセスできる場合もありますが、実装するには追加のコードの追加が必要な場合もあります。制御統合はブラックボックス統合であり、そのモデルは図 1 に示すとおりです。
ここに画像の説明を挿入します
制御統合を実装する場合、リモートプロシージャコール、リモートメソッドコール、メッセージ指向ミドルウェア、分散オブジェクトテクノロジ、およびトランザクション処理モニタの助けを借りて実現できます。。プレゼンテーション統合やデータ統合と比較して、コントロール統合はより柔軟かつ複雑です。表現統合とデータ統合が適用できる場合、制御統合も適用できます。ただし、制御の統合はビジネスロジック層で行われるため、複雑度は高くなります。さらに、多くのシステムではビジネスロジック部分の API が提供されていないため、統合がより困難になります。

ビジネスプロセスの統合

プロセス統合とも呼ばれ、データとシステムを超えて、標準と統一されたデータ形式に基づいた一連のワークフローで構成されます。ビジネスプロセスを統合する場合、企業は業務を改善し、コストを削減し、応答速度を向上させるために、さまざまなビジネス情報の交換を定義、承認、管理する必要があります。

ビジネスプロセス統合では、基盤となるアプリケーションサポートシステム間の相互接続を提供するだけでなく、企業内のアプリケーション間、および企業と他のパートナー間のエンドツーエンドのビジネスプロセス管理も実装する必要があります。これには、アプリケーション統合、B2B 統合、自動化されたビジネスプロセス管理が含まれます。、手動プロセス管理、エンタープライズポータル、すべてのアプリケーションシステムとプロセスの管理と監視など。

他の

その他の統合:

メッセージ統合: データ量は少ないが、頻繁かつ即時の非同期データ交換が必要な状況に適しています。
共有データベース: 強力なリアルタイムパフォーマンス、頻繁な対話、データ交換は同期的
ファイル転送: データ量が多く、交換頻度が少なく、即時性の要件が低い状況に適しています。

統合モード

市場には、次の 3 つの主流の統合モデルがあります。

情報指向統合技術

データ統合レベルでは、情報統合テクノロジーは依然として必要なソリューションです。情報統合で使用される主なデータ処理テクノロジには、データレプリケーション、データ集約、インターフェイス統合などがあります。その中でもインターフェース統合は今でも主流の技術です。統合は、統合エージェントを通じて実現されます。つまり、アプリケーションシステム用に独自のエージェントとしてアダプターが作成され、アダプターはオープンまたはプライベートインターフェイスを通じてアプリケーションシステムから情報を抽出し、開発を通じて外部システムとリアルタイムで対話します。インターフェース。特定の標準をサポートするアダプタ構造を追加すると、統合の複雑さが大幅に簡素化され、標準化が促進されます。これは、インターフェイス指向の統合方法の利点の主な源泉でもあります。標準化されたアダプターテクノロジーにより、企業はサードパーティベンダーからアダプターを入手できるため、統合が簡素化されます。

プロセス指向の統合技術

実際、これはユーザーインターフェイスの開発、データベースロジック、トランザクションロジックなどを扱う必要のないプロセスフロー統合のアイデアです。システム間のプロセスロジックのみを処理し、コアのビジネスロジックから分離されます。
構造的には、プロセス指向の統合メソッドは、迷信インターフェイスの統合メソッドの最上部に別のプロセスロジック層を定義し、この層の最下部では、アプリケーションサーバーとメッセージミドルウェアがデータ送信とクロスドメインプロセス調整のサポートを提供します。基本的なサービス。統合エージェント、メッセージミドルウェア、およびアプリケーションサーバーを提供するメーカーにとって、ビジネスプロセス統合の提供は自社製品の重要な拡張であり、現在のアプリケーション統合市場における重要な需要でもあります。

サービス指向統合テクノロジー

SOA および Web テクノロジに基づくアプリケーション統合は、ビジネス統合テクノロジにおける重要な変化であり、新世代のアプリケーション統合テクノロジとみなされます。統合オブジェクトは、Web サービス、または Web サービスにカプセル化されたビジネス処理です。Web サービステクノロジは、最も広く受け入れられているオープンな技術標準に基づいているため、サービスインターフェイスの記述とサービス処理の分離、サービス記述の集中保存とリリース、サービスの自動検索と動的バインディング、およびサービスの組み合わせがサポートされています。新世代のサービス指向アプリケーションのビルディングブロックとアプリケーションシステム統合用。

企業情報の統合

異なるアプリケーションシステム間での企業間のデータ共有の実現、つまり、異なるデータ形式や保存方法の間でのデータ変換の実現、および異なるソース、異なる形式、異なるコンテンツからの情報リソースの体系的な分析を行い、正しさを識別することを指します。類似した情報を統合して、統一されたデータ形式で価値のある情報を生成するプロセス。企業の情報統合は非常に複雑な問題であり、組織の範囲に応じて、企業の内部情報統合と外部情報統合に分けられます。企業内の情報統合は、統合内容に応じて、一般に次の 4 つの側面に分類できます。

テクノロジープラットフォームの統合
データ統合
アプリケーションシステムの統合: 異なるシステム間の相互運用性を実現し、異なるアプリケーションシステム間でのデータとメソッドの共有を可能にします。
ビジネスプロセスの統合: 異なるアプリケーションシステムのプロセスをシームレスに接続し、プロセスの調整された運用とプロセス情報の共有を実現します。

データ統合
アプリケーション統合とプロセス統合を完了するには、まずデータとデータベースの統合問題を解決する必要があります。統合する前に、まずデータを表現してカタログ化する必要があり、さらに、データベースシステム内でのデータの分散と共有を確実にするためにメタデータタイプを決定する必要があります。

データ統合パターンには次のものが含まれます。

データフェデレーション
データ複製モード
構造ベースのデータ統合パターン

制御統合
この統合により、2 つのアプリケーションからのデータと機能がほぼリアルタイムで統合されます。アプリケーション統合は、基礎となるネットワーク統合とデータ統合に基づいて、異種アプリケーションシステム間のアプリケーションレベルの相互運用性を実現します。

アプリケーション統合の主なパターンは次のとおりです。

統合アダプターモード
統合されたメッセンジャーモード
統合パネルモード
統合プロキシモード

統合されたテクノロジー

さまざまなカテゴリにさまざまなテクノロジーが存在します

統合を示します

EP

エンタープライズポータル、エンタープライズポータル。
分類

コーポレートサイト：一方的な情報発信が中心でインタラクション性が低い
企業情報ポータル: さまざまなアプリケーションシステム、データリソース、インターネットリソースを企業ポータルに統合する EIP
エンタープライズナレッジポータル: EKP、エンタープライズ Web サイトに基づいてナレッジコンテンツを追加
エンタープライズアプリケーションポータル: EAP は実際にはエンタープライズビジネスプロセスの統合です。ビジネスプロセスとエンタープライズアプリケーションをコアとし、ポータルテクノロジを通じてビジネスプロセス内のさまざまな機能を持つアプリケーションモジュールを統合します。
エンタープライズユニバーサルポータル: 上記 4 つを 1 つに結合します。

EP 実装における重要な問題

シングルサインオンSSO
ビジネスプロセスの統合
パーソナライズされた構成
エンタープライズアプリケーションシステムとの統合
知識の変革

アプリケーションの統合

5つのカテゴリーがあります

ウェブサービス

WS と呼ばれる Web サービスでは、インターネットアプリケーションが徐々に B2B アプリケーションプラットフォームになるにつれて、さまざまなコンポーネント間の「戦争」、さまざまなプログラミング言語間の「戦争」、およびファイアウォールなど、アプリケーション統合が直面する問題がますます顕著になってきています。プロトコルの不一致など。Web サービスは、標準の HTTP/S プロトコルを使用して XML 表現とカプセル化されたコンテンツを送信する、緩やかで粗粒な分散コンピューティングモデルを定義します。

Web サービスの一般的なテクノロジには次のようなものがあります。

SOAP: Simple Object Access Protocol、情報の転送に使用される単純なオブジェクトアクセスプロトコル
WSDL: Web サービス記述言語、サービスを記述するために使用される Web サービス記述言語
UDDI: Universal description Discovery and Integration。Web サービス登録の統一された記述、検出、統合に使用されます。
XML: データ交換用

Web サービスの主な目標は、WS の使用に適したクロスプラットフォームの操作性です。

ファイアウォールを越えて
アプリケーションの統合
B2B統合
ソフトウェアの再利用

場合によっては、Web サービスによってアプリケーションのパフォーマンスが低下することもあります。次の状況は Web サービスの使用に適していません。

スタンドアロンアプリケーション
LAN上の同種アプリケーション

J2EEアーキテクチャ

J2EE (Java 2 Platform Enterprise Edition) は、Sun が主導し、さまざまなメーカーが共同開発した業界標準であり、広く認知されています。IBMやOracleなどの業界大手ミドルウェアベンダーは、この規格の普及と適用を積極的に推進している。完全な J2EE 技術仕様は、J2EE プラットフォーム、J2EE アプリケーションプログラミングモデル、J2EE 互換性テストスイート、および J2EE リファレンス実装の 4 つの部分で構成されています。J2EE アプリケーションサーバーの動作環境は、コンポーネント、コンテナ、サービスの 3 つの部分で構成されます。コンポーネントはアプリケーションロジックを表すコード、コンテナはコンポーネントの実行環境、サービスはシステムリソースと対話できるアプリケーションサーバーによって提供されるさまざまな機能インターフェイスです。

.NETアーキテクチャ

Microsoft の .NET は、一連のオープンインターネットプロトコルに基づく一連の製品、テクノロジ、およびサービスです。.NET 開発フレームワークは、共通言語実行環境に基づいた完全な基本クラスライブラリ、データベースアクセス技術、ネットワーク開発技術を開発者に提供し、開発者は複数の言語を使用してネットワークアプリケーションを迅速に構築できます。.NET 開発共通言語ランタイム (Common Language Runtime) は、.NET 開発フレームワークの最下位レベルにあり、フレームワークの基盤です。複数の言語に統合された実行環境とプログラミングモデルを提供し、リリースとアップグレードを大幅に簡素化します。アプリケーションの管理、複数言語間の対話、メモリとリソースの自動管理など。基本クラスライブラリ (Hase クラスライブラリ) は、統合されたオブジェクト指向、階層型、拡張可能なプログラミングインターフェイスを開発者に提供し、開発者が次世代インターネットに基づいたネットワークアプリケーションを効率的かつ迅速に構築できるようにします。

ワークフロー

International Workflow Management Coalition (WfMC) の定義によると、ワークフローは完全または部分的に自動化できるビジネスプロセスの一種であり、一連のプロセスルールに基づいて、ドキュメント、情報、またはタスクをさまざまな実行者が実行できるようにします。納品から実行までの間。ワークフローはプロセスの統合を可能にするテクノロジーです。

ワークフローは、ワークフローのコンピューティングモデルです。つまり、ワークフロー内の作業がどのようにまとめられるかに関するロジックとルールが、コンピューター内の適切なモデルで表現され、計算されます。ワークフローが解決する必要がある主な問題は、特定のビジネス目標を達成するために、コンピューターを使用して、あらかじめ決められたルールに従って複数の参加者間でドキュメント、情報、またはタスクを自動的に転送することです。

ユーザーのビジネスプロセスが頻繁に変更される場合は、ワークフローテクノロジを最初に検討する必要があります。

効果：

すべての特殊なビジネスアプリケーションシステムを統合し、ワークフローシステムを使用して、柔軟で自動化された EAI (Enterprise Application Integration) プラットフォームを構築します。
複数の人が関わるタスクの生産性向上に貢献
ファームウェアの再利用性を向上させ、ビジネスプロセスの改善を促進します
要件を設計に変換する作業負荷を軽減し、メンテナンスを簡素化し、開発リスクを軽減します。
集中・一元管理が実現し、業務プロセスがさまざまなシステムに分散することがなくなります。プロセスの制御と管理を改善する
顧客対応の予測可能性が向上し、ビジネスの変化に応じてユーザーが便利な二次開発が可能

データベース

データウェアハウスは、歴史的な変化を反映し、経営上の意思決定をサポートするために使用される、主題指向の統合された比較的安定したデータコレクションです。第一に、データウェアハウスは意思決定支援に使用され、分析データ処理を指向しています。第二に、データウェアハウスは複数の異種データソース (履歴データを含む) を効果的に統合します。統合後、データはテーマおよびデータごとに再編成されます。データウェアハウスに保存されているデータは、通常は変更されません。運用データベースと比較したデータウェアハウスの主な特徴は次のとおりです。主題指向、統合、比較的安定しており、歴史的な変化を反映しています。

共有データベース

共有データベースはエンタープライズアプリケーション統合の重要な方法であり、通常はアプリケーションデータを共有データベースに保存し、統一されたデータベーススキーマを定式化することでさまざまなアプリケーションの統合ニーズに対応します。共有データベースは、さまざまなアプリケーションに統一されたデータストレージとフォーマット定義を提供するため、データセマンティクスの不一致の問題をある程度軽減できますが、問題を完全に解決できるわけではありません。共有データベース統合では、複数のアプリケーションが共有データベースを通じて同じデータを頻繁に読み取り、変更する可能性があり、データベースがパフォーマンスのボトルネックになる可能性があります。共有データベース統合方法の重要な制限は、外部のパッケージ化されたアプリケーションに起因します。これらのパッケージ化されたアプリケーションは、独自に定義されたデータベーススキーマのみを使用できるため、調整や統合の余地が少なくなります。