トピック

概論ページの先頭へ

アプリケーションの実行時アーキテクチャーは、システムの並行要素を記述するアーキテクチャー上のビューである、プロセス・ビューで記述されます。 このガイドラインでは、J2EE アプリケーションに対するプロセス・ビューのモデリング方法についての特定のガイダンスを提供します。

概念: プロセス・ビュー』も参照してください。

プロセス・ビューのモデリングページの先頭へ

J2EE コンポーネント (『概念: J2EE の概要: J2EE コンポーネント』) は、コンテナーと呼ばれる環境に配置されます。 J2EE で定義されるコンテナーの各種類の説明については、『概念: J2EE の概要: J2EE コンテナー』を参照してください。

各コンテナーは並行要素であり、アーキテクチャーのプロセス・ビューで表示されます。 通常ハイレベルなプロセス・ビューで表示される重要な並行要素には、このほかに、外部システムがあります。

次のダイアグラムは、J2EE アプリケーションのハイレベルなプロセス・ビューの典型的なダイアグラムです。

前後の本文を説明するダイアグラム

実際の例では、特定のベンダーの メッセージ指向ミドルウェア (MOM)、特定のレガシー・システムやアプリケーション・クライアントが使用されます。 しかし、Web コンテナーや EJB コンテナーは、すべての J2EE プロセス・ビューに表示される標準コンテナーです。

このダイアグラムは、具体的なハードウェア・ノード上でのこれらのシステムの物理的な分散を示しているのではないことに注意してください。物理的な分散は、配置モデルで表示されます(『ガイドライン: J2EE アプリケーションの分配性の記述』を参照)。

この例には、コンテナー間で採用される、選択されたプロセス間通信メカニズムがあります。J2EE は、固有のプロセス間通信メカニズムを提供します。次のものがあります。

  • Java クラス間の同期通信用の Java Remote Method Invocation (RMI)
  • CORBA クライアント (通常、レガシー・アプリケーション) と相互操作するための RMI-IIOP
  • Web ベース・クライアントとの通信用の HTTP/HTTPS (XML Web サービスとの相互作用時など、ほかの Web プロトコルもサポートされている場合があります)
  • メッセージ指向ミドルウェア (MOM) でのメッセージングと相互作用のための Java Message Service (JMS)

プロセス・ビュー定義時の重要な決定事項の 1 つは、JMS と RMI または RMI-IIOP を使用するタイミングです。この例では、アプリケーション・クライアント、EJB コンテナー、ほかのレガシー・システムは、メッセージングを使用して通信します。ただし、どの要素がどの要素と通信するかは明確ではありません。あいまいさを解消するために、ダイアグラムから MOM システムを除去し、メッセージングで通信する要素間の関連として JMS と表示することもできます。

また、EJB どうしがメッセージングを介して通信するかどうかもあいまいです。これは、EJB コンテナーからそのコンテナー自体への JMS の関連を表示することによって明確になります。最終的なダイアグラムは、次のようになります。

前後の本文を説明するダイアグラム

しかし、プロセス・ビューは、単なるコンテナーとハイレベル・システムの組み合わせではありません。 それらのコンテナーとシステムの並行性も扱います。

プロセス・ビューは、次の種類のアクティブ・クラスを識別してモデリングします。

  • Java スレッド
  • メッセージの宛先
  • メッセージ駆動型 Bean (メッセージを介して非同期に呼び出されるため)。 メッセージ駆動型 Bean のモデリングに使用される特定のステレオタイプについては、『ガイドライン: Enterprise JavaBeans の識別』を参照してください。
  • システム設計全体の一部である追加プロセス。例えば、独立したタイマー・プロセスなど。

JMS を使用する場合は、メッセージのプロデューサーとコンシューマーを直接関連付けることも、トピックとキューをモデリングによってさらに厳密に関係をモデリングすることもできます。

相互作用図は、設計の要素間の同期通信と非同期通信の両方を示すために使用されます。性能や論理の問題について、並行する振る舞いを分析するためにも使用できます。特に、ソフトウェア・アーキテクトが、ネットワーク間の高頻度のメッセージングや大量のデータ転送を発見することができます。これにより、アーキテクトは、インターフェースを再設計したり、制御スレッド間、サーバー間、クライアントとサーバー間の設計の要素を再割り当てしたりできます。

EJB コンテナー内では、スレッドとプロセスは EJB コンテナーによって管理されます (EJB ではスレッドを作成または管理できません)。論理的にはすべての EJB がアクティブ・クラスと見なされますが、セッション Bean とエンティティー Bean への呼び出しは同期ブロックの呼び出しなので、これらは通常、アクティブ・クラスとしてはモデリングされません。EJB コンテナーのプロセス・ビューは、通常、利用可能な 1 つの並行性メカニズム (JMS メッセージ駆動型 Bean での JMS) に制限されています。

セッション Bean とエンティティー Bean は、通常はアクティブ・クラスとしてモデリングされませんが、並行性の問題が存在します (ある EJB が読み込んでいるデータベースにほかの EJB が書き込みをするなど)。これらの問題には、トランザクションを使用して対処します。トランザクションを使用するアプローチは、プロジェクト固有のガイドラインで文書化します。

アクティブ・クラスへの設計の要素の割り当てページの先頭へ

プロセスとスレッドへの設計要素の割り当ての必要性については、『作業: 実行時アーキテクチャーの記述 』に記述されています。J2EE アプリケーションでは、すべての Web コンポーネントは Web コンテナーに割り当てられ、すべての EJB は EJB コンテナーに割り当てられます。このように単純な関係であるため、この割り当てをモデリングする必要はありません。

ただし、設計に追加の並行プロセス (2 つの異なるアプリケーション・クライアントなど) が含まれている場合、各アプリケーション上でどの設計の要素が実行されるかを指定すると役に立つことがあります。

Java スレッド、メッセージ駆動型 Bean、JMS のトピックとキューに関する問題は、デッドロック、データの不整合などを防ぐための相互通信方法だけではありません。 これについては、これらの要素を含むユース・ケースの実現を確認することによって最も効率よく調べられます。

代案のモデリングページの先頭へ

プロセス・ビューと配置ビューは類似しているため、多くの場合、これらのビューに対する上位レベルのダイアグラムは結合されます。

また、各 J2EE コンテナーはプロセスだけでなく実行環境でもあるため、アクティブ・クラスとしてではなく「論理ノード」としてモデリングされる場合もあります。



Rational Unified Process   2003.06.15