WebSphere Application Server Network Deployment, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

アプリケーション設計に関する考慮事項

このトピックでは、設計でのアーキテクチャーに関する提案と、アプリケーションの調整方法について説明します。

アプリケーションの設計のトピックでは、 特に Java 2 Platform, Enterprise Edition (J2EE) 仕様に対する WebSphere 拡張の領域に関して、 WebSphere アプリケーションの設計のベスト・プラクティスを見つけるための、 Web サイトおよびその他のアイデアを中心に説明しているので、参考にしてください。

アプリケーションの設計トピックには、 アーキテクチャーに関する提案と、アプリケーションのインプリメンテーションが含まれています。これらの提案では、既存のアプリケーションの場合、既存のインプリメンテーションの変更が必要になることがあります。 アプリケーション・サーバーおよびリソース・パラメーターを調整すると、 適切に設計されているアプリケーションのパフォーマンスに大きな効果が得られる場合があります。

ベスト・プラクティス: アプリケーションをインプリメントする際には、 アーキテクチャーに関するガイドとして以下の情報をご利用ください。 bprac

パーシスタンス

Java 2 Platform, Enterprise Edition (J2EE) アプリケーションは、 リレーショナル・データベースのデータをロード、保管、作成、および除去しますが、 このプロセスを一般にパーシスタンス と呼びます。ほとんどのエンタープライズ・アプリケーションでは、 かなりのデータベース・アクセスが発生します。 パーシスタンス層のアーキテクチャーおよびパフォーマンスは、 アプリケーションのパフォーマンスに重大な影響を与えます。 したがって、 パフォーマンスのトレードオフが必要なアーキテクチャー上の選択を行う場合には、 パーシスタンスを考慮することがきわめて重要であると言えます。 このガイドでは、まず、クリーンなアーキテクチャーを持つソリューションに焦点を合わせることを お勧めします。クリーンなアーキテクチャーは、データの整合性、セキュリティー、 保守、移植性、およびソリューションのパフォーマンスを考慮します。 この方法では、前述のようなサービスの品質に配慮しないソリューションを手動でコーディングして得られる 最大のパフォーマンスを出すことはできませんが、データの整合性、保守容易性、 移植性、セキュリティー、およびパフォーマンスの間に適切なバランスを保つことができます。

J2EE では、パーシスタンスに関して複数のオプションが使用できます。 Entity Bean (コンテナー管理パーシスタンス (CMP) または Bean 管理パーシスタンス (BMP) を含む) を使用した Session Bean、 Java Database Connectivity (JDBC) を使用した Session Bean、 そして JDBC を使用した Java Bean です。前述の理由で、 CMP エンティティー・パーシスタンスを検討してください。 最大のセキュリティー、保守、および移植性が得られるためです。 CMP は、パフォーマンスの点でもお勧めできます。 Enterprise Bean、特に CMP の調整については、 アプリケーション・サーバーの調整 トピックの『EJB コンテナーの調整』セクションを参照してください。

アプリケーションで、EJB エンティティーではなく Enterprise Bean を使用する必要がある場合は、 そのパーシスタンス・メカニズムには通常 JDBC API が組み込まれています。JDBC では、 手動コーディング、すなわちデータベース・インスタンスに対して実行される構造化照会言語 (SQL) が必要になるため、 アプリケーション内で使用される SQL ステートメントの最適化が重要です。 また、データベース・サーバーを、この SQL ステートメントの最良のパフォーマンスをサポートするように、 構成する必要もあります。 最後に、準備済みステートメントおよびバッチなど、特定の JDBC API の使用について検討する必要があります。

どのパーシスタンス・メカニズムを検討するにしても、 コンテナー管理のトランザクション (Bean がトランザクションの管理をコンテナーに委任する) を使用してください。 JDBC を使用するアプリケーションでは、セッション・ファサード・パターン (すべての JDBC 機能を ステートレス・セッション Bean でラップする) を使用することで、これを簡単に実行できます。

最後に、EJB Entity Bean または JDBC の通信に使用する接続の調整に関する情報が、 アプリケーション・サーバーの調整 トピックの『データ・ソースの調整』セクションに記載されています。

Model-View-Controller パターン

標準 J2EE プログラミング・アーキテクチャーの 1 つである Model-View-Controller (MVC) アーキテクチャーでは、 コントローラー・サーブレットの呼び出しに、 ビューを構成するための 1 つ以上の子 JavaServer Pages (JSP) ファイルが含まれる場合があります。 MVC パターンは、 アプリケーション・アーキテクチャーに推奨されるパターンです。 このパターンでは、 ビュー (JSP ファイルまたは表示ロジック)、コントローラー (サーブレット)、 およびモデル (ビジネス・ロジック) を明確に分離する必要があります。 MVC パターンを使用すると、 パフォーマンスの最適化、および各層の個別のスケーラビリティーが可能になります。

ステートレス

クライアント・ユーザー状態スケールの保管を避け、最高のパフォーマンスを得るインプリメンテーション。 状態を保管しないような実装を設計します。 状態の保管が必要な場合は、 状態データのサイズと状態を保管する時間の値を、できるだけ小さくするようにしてください。また、 状態の保管が必要な場合は、障害発生時に、複製によって状態フェイルオーバーを保証するのではなく、状態の再構成が可能かどうかについても検討してください。

状態の特定の調整は、HTTP セッション状態、動的キャッシング、 およびエンタープライズ Bean に影響を与えます。 状態保管のサイズ、複製、および時間の調整については、 以下の調整ガイドを参照してください。

キャッシング

ほとんどの J2EE アプリケーション・ワークロードでは、書き込み操作より読み取り操作の方が頻繁に行われます。 読み取り操作では、複数のトポロジー・レベル (フロントエンド Web サーバー、 アプリケーション・サーバーの Web コンテナー、アプリケーション・サーバーの EJB コンテナー、 データベースで構成される) を介して要求を渡す必要があります。WebSphere Application Server には、 Web サービスが含まれるネットワーク・トポロジーと J2EE プログラミング・モデルのすべてのレベルで、 結果をキャッシュに入れる機能が用意されています。

アプリケーションの設計者は、アプリケーション・アーキテクチャーを設計する際に、 キャッシングのことを考慮する必要があります。キャッシングは、 プログラミング・モデルのほとんどのレベルに組み込まれるためです。 キャッシングは、アプリケーションで MVC パターンを実行するもう 1 つの理由になっています。 キャッシングと MVC を結合すると、表示テクノロジーから独立して、 アプリケーションのクライアントに対する表示が存在しない場合でも、キャッシングを提供することができます。

ネットワークの設計者は、ネットワーク計画を実行する際に、キャッシングのことを考慮する必要があります。 キャッシングは、ネットワーク・トポロジーのほとんどのレベルにも組み込まれるためです。 公衆インターネット上で入手できるアプリケーションの場合、ネットワーク設計者は、 WebSphere Application Server のキャッシングを公衆インターネットまで拡張する場合に、 Edge Side Include (ESI) キャッシングを検討することもできます。 ネットワーク・キャッシング・サービスは、 WebSphere Application Server、WebSphere Edge Component Caching Proxy、 および WebSphere プラグインのプロキシー・サーバーで利用できます。

非同期に関する考慮事項

J2EE ワークロードは、通常は 2 つのタイプの操作で構成されています。 システム要求に応答するためには、 第 1 のタイプの操作を実行する必要があります。2 番目のタイプの操作は、 その操作を開始したユーザー要求が満たされた後、非同期に実行できます。

この違いの一例が、購入注文を送信し、システムが注文を確認している間も処理を継続できるようにするアプリケーションです。このアプリケーションはまた、 リモート・システムへの照会を行って、後で購入注文の状況を通知します。この例は、応答を待機しているクライアントと同期してインプリメントすることができます。 同期インプリメンテーションにはアプリケーション・サーバー・リソースが必要なため、 操作がすべて完了するまで待たされることになります。結果が非同期に計算されている間にプロセスを継続することができれば、 アプリケーション・サーバーは、他の要求との関係で最適の場合に処理が行われるように、スケジュールを組むことができます。 ユーザーへの通知は、アプリケーション内の E メールなどのインターフェースによって起動することができます。

非同期アプローチは、ワークロードの最適なスケジューリングと最小のサーバー・リソースに対応しているので、 非同期アーキテクチャーを検討してください。WebSphere Application Server は、J2EE Java Message Service (JMS)、 メッセージ・ドリブン Bean (MDB) だけでなく、『Java Message Service の調整』、 『MDB の調整』の両トピックで説明している非同期 Bean による非同期プログラミングもサポートしています。

サード・パーティーのライブラリー

アプリケーションが使用するライブラリーがすべて、 サーバー・サイド・パフォーマンス向けにも設計されていることを確認してください。 ライブラリーの中には、クライアント・アプリケーション内で十分に機能するように設計されているものの、 サーバー・サイド・パフォーマンス (例えばメモリーの使用効率、同期、プーリングなど) については考慮されていないものもあります。アプリケーションの一部として開発されていないライブラリーはすべて、 そのアプリケーションで使用されているのと同じテスト方法を使用して、 パフォーマンス・テストを実施することをお勧めします。

その他の参照情報:

IBM WebSphere Developer Technical Journal: The top 10 (more or less) J2EE best practices

Improve performance in your XML applications, Part 2




関連タスク
アプリケーション・サービス提供環境のチューニング
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:13:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cprf_appdesign.html