Java EE勉強会

EIP / Ch2 Introduction

Introduction †

一言要約 †

統合アプローチをざっと紹介するけど、メッセージングいいよメッセージング。

要約 †

EIとは、機能の統一セットを作り出すのに、異なるアプリケーションを連携させるもの。
次のような問題によって、アプリケーションの統合が難しくなる。

  • 自家製であったり、サードパーティーベンダーから購入したものであったり。
  • 複数のプラットフォームからなるものだったり、地理的に分散されてたり。
  • ビジネスパートナーや顧客によって企業外で動いてたり。
  • 統合を想定していなかったり、変更しづらかったり。
この章では、これら困難の克服の助けとなる、統合アプローチを探索する。

Application Integration Criteria †

何が良いアプリケーション統合を果たす？

  • ニーズが常に同じなら1つの統合スタイルだけ。
  • アプリケーション統合は考慮されるべき要件と結果の範囲を伴う。


他から独立した単体のアプリケーションを開発するなら、統合に関するすべての問題を避けられる。
実際には小さな企業でさえ、連携する必要のある複数のアプリケーションを持つ。


以下、他の主要な決定基準。

  • Application coupling
    • 統合されたアプリケーションは、問題が波及しないよう相互依存を最小限にすべき。
    • アプリケーション統合のインターフェイスは、十分な機能を実装するが、必要なだけ修正できるように明確であるべき。
  • Intrusiveness
    • 企業でアプリケーションを統合する際、アプリケーションの修正と統合に必要なコード量を最小限に抑えるべき。
    • それでも修正と新しいコードは必要なので、悪影響を抑えるアプローチでは良い結果にならないかも。
  • Technology selection
    • 異なる統合技術は特殊なソフトとハードを増やす必要がある。
    • それらは高価で、ベンダーにロックインされ、開発者の学習負荷の増大をもたらす。
    • 一方、スクラッチで統合ソリューションを作るのは、当初の想定よりも大変で、車輪の再発明になりがち。
  • Data format
    • 統合されたアプリケーションは交換し合うデータフォーマットに従うべき。
    • 既存のアプリケーションを統一されたデータフォーマットを使うよう修正するのは難しいか不可能。
    • それに対し、中間のトランスレーターは異なるデータフォーマットを扱うアプリケーションを統一可能。
    • 関連する問題として、データフォーマットの進化と拡張性がある。
      • どのようにフォーマットが時間をかけて変わるか。
      • どのようにその変化がアプリケーションに影響を与えるか。
  • Data timeliness
    • あるアプリケーションがデータを共有してから他がそれを使うまでにかかる時間を、統合によって最小化すべき。
    • データ共有の呼び出し時間は統合デザイン時に考慮すべき。
    • 共有に時間がかかるほど、同期が取れなくなっていき、統合が複雑化していく。
  • Data or functionality
    • 多くの統合ソリューションはデータだけでなく機能も共有する。
    • リモートのアプリケーションの機能を呼び出すのは、ローカルとは全く異なった働きをする。
  • Remote Communication
    • コンピューターの処理は典型的には同期したものである。
    • でも、リモートサブプロシージャの呼び出しはローカルよりも非常に遅いので、サブプロシージャが処理を終るまで待ちたくなくなるかも。
    • 非同期は非常に効果的なソリューションではあるが、設計、開発、デバッグが非常に複雑になる。
  • Reliability
    • リモートコネクションは遅いだけでなく、ローカルの機能呼び出しよりも信頼性に欠ける。
    • 単一のアプリケーション内でプロシージャがサブプロシージャを呼び出すとき、サブプロシージャが利用できるのは当然。
    • が、リモートの場合には必ずしも真ではない。
      • リモートアプリケーションが動いていないかもしれないし、ネットワークが利用できなくなってるかもしれない。


見てきた通り、統合アプローチを選んで設計する際、考慮すべき異なる基準がいくつかある。
ここでの疑問は、これらの基準のどれにどの統合が最適であるか、というもの。

Application Integration Options †

すべての基準に等しく適用できる統合アプローチは存在しない。
なので、アプリケーション統合の複数のアプローチが時間とともに進化した。
いろいろなアプローチは以下の4つの主要な統合スタイルに要約される。

  1. File Transfer
    • それぞれのアプリケーションが、他で消費する共有データを生産し、他で生産された共有データを消費するもの。
  2. Shared Database
    • 共通データベースに共有したいデータを保存するもの。
  3. Remote Procedure Invocation
    • それぞれのアプリケーションがそのプロシージャをリモートから実行できるよう外部に公開し、他のアプリケーションがそれらを実行するもの。
  4. Messaging
    • それぞれのアプリケーションが共通のメッセージングシステムに接続し、データを交換し、メッセージを使用してふるまいを実行するもの。


この章ではパターンとしてそれぞれのスタイルを表現。

  • 4つのパターンはアプリケーションの統合を要するという同じ問題と非常に類似したコンテキストを共有する。
  • それらを区別するのはよりエレガントなソリューションを探すというフォースである。
  • それぞれのパターンは、前のパターンの欠点に対処するより洗練されたもの。
  • 従ってパターンの順序は洗練された順であるが、より複雑な順でもある。


毎回ひとつのスタイルを選択するのではなく、特定の統合にベストなスタイルを選択するのが秘訣。

  • それぞれに長所と短所がある。
  • それぞれの統合のポイントが最も合うスタイルを利用するために、複数のスタイルを使って統合するとか。
  • その結果、多くの統合アプローチは複数の統合スタイルの混成としてみられる。
  • 多くの統合とEAIミドルウェア製品ではスタイルの組み合わせを使用してそれらをうまく隠蔽している。


この本の残りのパターンはMessaging統合スタイルを詳述したもの。

  • メッセージングにフォーカスを当てているのは、統合基準間の良いバランスを提供するが、機能するのが最も難しいスタイルだから。
    • 結果として、メッセージングが統合スタイルとしてあまり認知されてない。
  • メッセージングは多くの商用EAI製品の基礎なので、メッセージングの使い方を説明するのは製品の使い方を教えるのにもうまくいく。
このセクションの焦点は、アプリケーション統合に関わる問題とメッセージングがいかにしてフィットするか。

担当者のつぶやき †

ところどころ意味不明なところがありましたねー。

みんなの突っ込み †

Menu