アプリケーション設計に関する考慮事項
このトピックでは、アプリケーションを設計および調整するためのアーキテクチャーに関する提案について説明します。
アプリケーションの設計情報では、アーキテクチャーに関する提案とアプリケーションの実装について説明しています。既存のアプリケーションの場合、これらの提案では、既存の実装の変更が必要になることがあります。アプリケーション・サーバーおよびリソースのパラメーターを調整すると、適切に設計されているアプリケーションのパフォーマンスに大きな効果が得られます。
このトピックのアプリケーション設計上の考慮事項をヒントにして、アプリケーションの設計および調整を慎重に行ってください。こうした考慮事項には、WebSphere® アプリケーションの設計 (特に Java™ Platform, Enterprise Edition (Java EE) 仕様に対する WebSphere 拡張の領域) に関するベスト・プラクティスを見つけるための Web サイトやその他のアイデアが含まれます。

Java EE アプリケーションは、リレーショナル・データベースのデータをロード、保管、作成、および除去しますが、このプロセスを一般にパーシスタンス と呼びます。ほとんどのエンタープライズ・アプリケーションでは、かなりのデータベース・アクセスが発生します。パーシスタンス層のアーキテクチャーおよびパフォーマンスは、アプリケーションのパフォーマンスに重大な影響を与えます。 したがって、パフォーマンスのトレードオフが必要なアーキテクチャー上の選択を行う場合、パーシスタンスは考慮する必要がある非常に重要な分野です。 このガイドでは、まず、クリーンなアーキテクチャーを持つソリューションに焦点を合わせることをお勧めします。クリーンなアーキテクチャーは、データの整合性、セキュリティー、保守、移植性、およびそのソリューションのパフォーマンスを考慮します。この方法では、前述のようなサービスの品質を無視したソリューションを手動でコーディングすることによって得られる絶対的なピーク・パフォーマンスを実現することはできませんが、データの整合性、保守容易性、移植性、セキュリティー、およびパフォーマンスの間に適切なバランスを保つことができます。
Java EE では、パーシスタンスに関して複数のオプションを選択できます。すなわち、エンティティー Bean (コンテナー管理パーシスタンス (CMP) または Bean 管理パーシスタンス (BMP) を含む) を使用したセッション Bean、Java Database Connectivity (JDBC) を使用したセッション Bean、および JDBC を使用した Java Bean です。前述の理由で、CMP エンティティーのパーシスタンスを検討してください。最大のセキュリティー、保守、および移植性が得られるためです。CMP は、パフォーマンスの点でもお勧めできます。エンタープライズ Bean (より具体的にいえば CMP) の調整については、『アプリケーション・サーバーの調整』トピックの『EJB コンテナーの調整』セクションを参照してください。
アプリケーションで、EJB エンティティーではなくエンタープライズ Bean を使用する必要がある場合、そのパーシスタンス・メカニズムには通常 JDBC API が組み込まれています。JDBC では、手動コーディング、すなわちデータベース・インスタンスに対して実行される構造化照会言語 (SQL) が必要になるため、アプリケーション内で使用される SQL ステートメントを最適化することが重要です。 また、データベース・サーバーを、この SQL ステートメントの最良のパフォーマンスをサポートするように、構成する必要もあります。最後に、準備済みステートメントやバッチ処理など、特定の JDBC API の使用について検討する必要があります。
どのパーシスタンス・メカニズムを検討するにしても、コンテナー管理トランザクション (Bean がトランザクションの管理をコンテナーに委任する) を使用してください。JDBC を使用するアプリケーションでは、セッション・ファサード・パターン (すべての JDBC 機能をステートレス・セッション Bean でラップする) を使用することで、これを簡単に実行できます。
最後に、EJB エンティティー Bean または JDBC の通信に使用する接続の調整に関する情報が、『アプリケーション・サーバーの調整』トピックの『データ・ソースの調整』セクションに記載されています。
標準 Java EE プログラミング・アーキテクチャーの 1 つにモデル・ビュー・コントローラー (MVC) アーキテクチャーがあります。このアーキテクチャーでは、コントローラー・サーブレットの呼び出しに、ビューを構成するための 1 つ以上の子 JavaServer Pages (JSP) ファイルが含まれる場合があります。MVC パターンは、アプリケーション・アーキテクチャーに推奨されるパターンです。このパターンでは、ビュー (JSP ファイルまたは表示ロジック)、コントローラー (サーブレット)、およびモデル (ビジネス・ロジック) を明確に分離する必要があります。MVC パターンを使用すると、パフォーマンスの最適化、および各層の個別のスケーラビリティーが可能になります。
クライアント・ユーザー状態スケールの保管を避け、最高のパフォーマンスを得る実装。状態を保管しないような実装を設計します。状態の保管が必要な場合は、状態データのサイズと状態を保管する時間の値を、できるだけ小さくするようにしてください。また、状態の保管が必要な場合は、障害発生時に、複製によって状態フェイルオーバーを保証するのではなく、状態の再構成が可能かどうかについても検討してください。
- セッション管理の調整
- EJB の調整のヒント
- キャッシュ・モニターを使用した動的キャッシュの調整
ほとんどの Java EE アプリケーション・ワークロードでは、書き込み操作より読み取り操作の方が頻繁に行われます。読み取り操作では、複数のトポロジー・レベル (フロントエンド Web サーバー、アプリケーション・サーバーの Web コンテナー、アプリケーション・サーバーの EJB コンテナー、およびデータベースで構成される) を介して要求を渡す必要があります。WebSphere Application Server には、Web サービスが含まれるネットワーク・トポロジーと Java EE プログラミング・モデルのすべてのレベルで、結果をキャッシュに入れる機能が用意されています。
アプリケーションの設計者は、アプリケーション・アーキテクチャーを設計する際に、キャッシングのことを考慮する必要があります。キャッシングは、プログラミング・モデルのほとんどのレベルに組み込まれるためです。キャッシングは、アプリケーションで MVC パターンを実行するもう 1 つの理由になっています。キャッシングと MVC を結合すると、表示テクノロジーから独立して、アプリケーションのクライアントに対する表示が存在しない場合でも、キャッシングを提供することができます。
ネットワークの設計者は、ネットワーク計画を実行する際に、キャッシングのことを考慮する必要があります。キャッシングは、ネットワーク・トポロジーのほとんどのレベルに組み込まれるためです。公衆インターネット上で入手できるアプリケーションの場合、ネットワーク設計者は、WebSphere Application Server キャッシングを公衆インターネットまで拡張する場合に、Edge Side Include (ESI) キャッシングを検討することもできます。ネットワーク・キャッシング・サービスは、WebSphere Application Server、WebSphere Edge Component Caching Proxy、および WebSphere プラグインのプロキシー・サーバーで利用できます。
Java EE ワークロードは、通常は 2 つのタイプの操作で構成されています。システム要求に応答するためには、 第 1 のタイプの操作を実行する必要があります。2 番目のタイプの操作は、その操作を開始したユーザー要求が満たされた後、非同期で実行できます。
この違いの一例が、購入注文を送信し、システムが注文を確認している間も処理を継続できるようにするアプリケーションです。このアプリケーションはまた、リモート・システムへの照会を行って、後で購入注文の状況を通知します。この例は、応答を待機しているクライアントと同期で実装することができます。同期実装にはアプリケーション・サーバー・リソースが必要なため、操作がすべて完了するまで待たされることになります。結果が非同期で計算されている間にプロセスを継続することができれば、アプリケーション・サーバーは、他の要求との関係で最適な時期に処理が行われるようにスケジュールを組むことができます。ユーザーへの通知は、アプリケーション内の E メールやその他のインターフェースによって起動できます。
非同期アプローチは、ワークロードの最適なスケジューリングおよび最小のサーバー・リソースをサポートするため、非同期アーキテクチャーの使用を検討してください。WebSphere Application Server は、非同期プログラミングを、 Java EE Java Message Service (JMS) およびメッセージ駆動型 Bean (MDB) を通してだけでなく、Concurrency Utilities for Java EE を通してもサポートします (これらについては、『Java Message Service の調整』および『MDB の調整』トピックに説明があります)。
アプリケーションが使用するすべてのライブラリーが、サーバー・サイド・パフォーマンス向けにも設計されていることを確認してください。ライブラリーの中には、クライアント・アプリケーション内で十分に機能するように設計されているものの、サーバー・サイド・パフォーマンス (例えばメモリーの使用効率、同期、プーリングなど) については考慮されていないものもあります。アプリケーションの一部として開発されていないライブラリーはすべて、そのアプリケーションで使用されているのと同じテスト方法を使用して、パフォーマンス・テストを実施することをお勧めします。
追加の参照先:IBM® WebSphere Developer Technical Journal: The top 10 Java EE best practicesImprove performance in your XML applications, Part 2