前へ
目次
索引
DocHome
次へ
|
| iPlanet Application Server 開発者ガイド |
第 1 章 アプリケーションの開発
この章では、アプリケーションの設計プロセスの概要を説明し、iPlanet Application Server の効果的な開発のためのガイドラインを提供します。
アプリケーションの要件
アプリケーションの要件
iPlanet Application Server アプリケーションの開発では、まず、アプリケーションの要件を明確にします。つまり、高速かつ安全であり、新規ユーザの追加条件について信頼性の高い処理が期待できる、広範囲に配置可能なアプリケーションとしての分散アプリケーションの開発を意味します。iPlanet Application Server は、J2EE API だけでなく既存の高性能機能もサポートしており、これらのニーズを満たしています。たとえば、オンラインバンキングアプリケーションでは、次の条件を満たすことができます。
パフォーマンスの向上
特定機能の導入時間の短縮。口座振替、会計報告、オンライン取引、資格のあるお客様に対する特別サービスなど
さまざまなタイプのエンドユーザの管理。個人、法人、社内ユーザ (銀行の従業員) など
EIS (Enterprise Information System : 企業情報システム) の接続性。既存のデータベースに格納されている情報へのアクセスを提供
アプリケーションプログラミングモデルについて
分散アプリケーションモデルでは、さまざまなアプリケーション領域を個々の機能要素に集中させることができるため、パフォーマンスが向上します。たとえば、セキュリティ条件の設計がアプリケーションモデルの 1 つ以上のレイヤに影響を与えることがあります。プレゼンテーションレイヤでは、ユーザの ID を確認する必要があります。これによって、アプリケーションは匿名ユーザ用のページと登録済みユーザ用のページを個別に表示できます。さらに、制限された機能にアクセスできない理由を説明し、メンバー登録を勧めるページを表示します。同様に、上得意の顧客は、一般の顧客がアクセスできない一部のページにアクセスできます。
ビジネスロジックレイヤでは、アプリケーションは登録されているユーザと照合してログインを認証し、特定のアプリケーション機能へのアクセス基準をユーザが満たしているかどうかを確認する必要があります。
データアクセスレイヤでは、アプリケーションはエンドユーザのカテゴリに基づいてデータベースへのアクセスを制限する必要があります。
プレゼンテーションレイヤ
プレゼンテーションレイヤでは、ユーザインタフェースがダイナミックに生成されます。アプリケーションには、次のアプリケーション要素が必要です。
Servlet
Servlet は、アプリケーションのプレゼンテーションロジックを処理します。Servlet は、ページ間移動ディスパッチャ、セッション管理、および簡単な入力確認を処理します。また、ビジネスロジックの要素を互いに関連付けます。したがって、Servlet 開発者は、HTTP リクエスト、セキュリティ、国際化、および Web の状態のないこと (セッション、cookie、タイムアウトなど) に関するプログラミングの問題を理解する必要があります。iPlanet Application Server アプリケーションでは、Servlet を Java で記述する必要があります。Servlet は、JSP、EJB、および JDBC オブジェクトを呼び出します。したがって、Servlet 開発者はこれらのアプリケーション要素の開発者と緊密に協力して作業します。
JSP
JSP は、ほとんどのアプリケーション表示タスクを処理し、Servlet とともに動作することによって、アプリケーションの表示画面およびページ移動を定義します。JSP は、EJB および JDBC オブジェクトを呼び出します。EJB は通常、ビジネスロジックの機能をカプセル化して、計算や繰り返し要求されるほかのタスクを実行します。JDBC オブジェクトをは、データベースに接続し、クエリを実行し、クエリ結果を返します。
HTML ページ
適切に設計された HTML ページでは、次の効果が得られます。
クライアントサイド JavaScript
クライアントサイド JavaScript は、サーバにデータを送る前の簡単な入力確認を処理したり、ユーザインタフェースをより機能的なものにしたりします。クライアントサイド JavaScript 開発者は、Servlet 開発者および JSP 開発者と緊密に協力して作業します。
ビジネスロジックレイヤ
ビジネスロジックレイヤは通常、ビジネスルールおよびほかのビジネス機能をカプセル化した配置エンティティを含んでいます。
セッション Beans
セッション Beans で、ビジネスプロセスおよびルールロジックをカプセル化します。たとえば、セッション Beans で請求書の税金を計算できます。頻繁に変更が加えられる複雑なビジネスルールの場合 (新しい商慣習、政府規制など)、通常、アプリケーションはエンティティ Beans よりもセッション Beans を多く使うので、セッション Beans を絶えず改訂する必要があります。セッション Beans は、ほかの EJB だけでなく、あらゆる JDBC インタフェースを呼び出します。セッション Beans に状態がない場合、アプリケーションは快適に動作します。たとえば、状態のあるセッション Beans で税金を計算すると仮定しましょう。アプリケーションは、その Bean のステート情報が保存されている特定のサーバにアクセスする必要があります。サーバがダウンすると、アプリケーション処理が遅れます。
詳細については、第 4 章「Enterprise JavaBeans の紹介」を参照してください。
エンティティ Beans
エンティティ Beans は、データベース行などのパーシスタントオブジェクトを表します。エンティティ Beans はあらゆる JDBC インタフェースを呼び出します。ただし、ほかの EJB を呼び出すことはありません。エンティティ Beans 開発者の役割は、組織のビジネスデータのオブジェクト指向ビューを設計することです。多くの場合、オブジェクト指向ビューを作成することは、エンティティ Beans へデータベーステーブルをマッピングすることです。たとえば、開発者は、Customer テーブル、Invoice テーブル、および Order テーブルを、対応する顧客オブジェクト、請求書オブジェクト、および注文書オブジェクトに変換できます。エンティティ Beans 開発者は、セッション Beans 開発者および Servlet 開発者と協力して、アプリケーションでのパーシスタントビジネスデータへの高速でスケーラブルなアクセスを実現します。
詳細については、第 4 章「Enterprise JavaBeans の紹介」を参照してください。
メッセージ駆動 Beans
メッセージ駆動 Beans は、Enterprise JavaBeans によって提供されるフレームワークをサポートするという点で、セッション Beans とエンティティ Beans に似ています。ただし、メッセージ駆動 Beans は JMS (Java Messaging Service) のリスナでもあり、JMS メッセージの形式でクライアントから受信するリクエストに基づいてタスクを実行します。セッション Beans やエンティティ Beans と異なり、メッセージ駆動 Beans はメッセージキューを非同期的に処理するので、サーバリソースを効率的に使用します。メッセージ駆動 Beans は多くのクライアントリクエストを同時に処理できるので、メッセージキューのボトルネックは生じません。
詳細については、第 7 章「メッセージ駆動 Beans の使用」を参照してください。
データアクセスレイヤ
データアクセスレイヤでは、カスタムコネクタはiPlanet Application Serverの UIF (Unified Integration Framework) を使って、IBM の CICS などのレガシー EIS との通信を可能にします。コネクタ開発者は C++ を使うことが多いため、JNI (Java Native Interfaces) などの Java への C++ の組み込みや UIF に関する事項も理解する必要があります。
UIF は、アプリケーションサーバから EIS データベースへの情報の送信を可能にする API フレームワークです。コネクタ開発者は次のシステムへのアクセスを統合します。
UIF の詳細については、『iPlanet Unified Integration Framework Developerﾕs Guide』および次の URL に掲載されているリリースノートを参照してください。
http://docs.iplanet.com/docs/manuals/ias.html#uifsp1
iPlanet アプリケーションの効果的なガイドライン
この節では、iPlanet Application Server アプリケーションの設計および開発時に考慮する必要があるガイドラインについて簡単に説明します。詳細については、このマニュアルの後半の章を参照してください。
Servlet および JSP を使ったデータ表示
Servlet および JSP を使ったデータ表示
Servlet はプレゼンテーションロジックによく使われ、ユーザ入力およびデータ表示のセントラルディスパッチャとして機能します。JSP は、プレゼンテーションレイアウトをダイナミックに生成します。Servlet および JSP を使うと、条件に応じてさまざまなページを生成できます。ページのレイアウトが主な特徴であり、ページを作成するための処理がほとんどないか、またはまったくない場合は、対話に JSP のみを使った方が簡単な場合があります。
たとえば、オンラインブックストアアプリケーションでは、ユーザを認証すると、共通画面である「入口」というフロントページを表示します。このページでユーザは、本の検索や選択した本の購入などのタスクを選択できます。この「入口」自体で処理が行われることはほとんどないので、JSP として単独で実行できます。
JSP と Servlet を 1 枚のコインの表と裏と考えてください。JSP のタスクは Servlet でも実行でき、その逆の操作も可能です。しかし、JSP のタスクは JSP に最適化されており、Servlet のタスクは Servlet に最適化されています。Servlet の利点は処理能力と適合性にあり、また Java ファイルであるため、ファイルを作成するときに統合開発環境を利用できます。ただし、Java ファイルから HTML の出力を実行すると、扱いにくい println ステートメントが多量に発生します。JSP は HTML ファイルなので、計算や処理タスクの実行には不向きですが、HTML エディタで編集できるので、レイアウト作業に優れています。
JSP の詳細については、第 3 章「JavaServer Pages によるアプリケーションページの表示」を参照してください。
再利用可能なアプリケーションコードの作成
オブジェクト指向の最適な設計方針が使われている場合を除き、再利用性を最大限にするためには、アプリケーション開発時に次の点を考慮する必要があります。
コードツリーを移動した場合でもリンクが無効にならないように、相対パスと相対 URL を使います。
JSP 内での Java の使用を最小限に抑え、Servlet およびヘルパークラス内で Java を使います。JSP 設計者は、Java に関する高度な知識がなくても JSP を修正できます。
データソース名、テーブル名、カラム名、JNDI オブジェクト名、ほかのアプリケーションプロパティ名などのハードコードされた文字列の保存には、プロパティファイルまたはグローバルクラスを使います。
ドメイン固有のビジネスルールや入力確認などの頻繁に変更されるビジネスルールの保存には、Servlet や JSP でなく、セッション Beans を使います。
パーシスタントオブジェクトにはエンティティ Beans を使います。エンティティ Beans を使うと、ユーザ 1 人あたり複数の Bean を管理できます。
パフォーマンスの向上
アプリケーションを iPlanet Application Server に配置した場合にパフォーマンスを向上させるいくつかのヒントがあります。
多くの場合、Servlet および JSP は iPlanet Web Server にではなく iPlanet Application Server に配置します。アプリケーションにトランザクションが多い場合、セッションデータを保持するためのフェールオーバーサポートが必要な場合、またはレガシーデータにアクセスする場合には、iPlanet Application Server が最適です。アプリケーションの大部分が状態なし、読み取り専用、およびトランザクションなしの場合は、iPlanet Web Server が適しています。
エンティティ Beans と状態のないセッション Beans を使います。同じ場所に配置できるように設計して、時間のかかるリモートプロシージャコールを回避します。
アプリケーションを配置したら、必要な EJB および JSP がレプリケートされ、Servlet を呼び出したプロセスと同じプロセスに読み込むことができることを確認します。
複数行にわたる情報を返す場合は、可能であれば JDBC の RowSet オブジェクトを使います。複雑なデータをデータベースにコミットする場合は、JDBC バッチ更新やダイレクト SQL オペレーションなどの効率的なデータベース機能を使います。
スケーラビリティの計画
顧客の要求の増加に合わせて簡単にスケーリングできるアプリケーションを作成するには、次の点に注意します。
情報分散用に設定した HttpSession オブジェクトにスケーリング情報や直列化情報を保存するようにアプリケーションを開発します。
アプリケーションのモジュール化
J2EE アプリケーションをモジュール化するときは、次の主要な要素を考慮する必要があります。5 つのパッケージサンプル (A 〜 E) は、ここで説明するパッケージ化の概念の例です。これらのサンプルの概要については、次のサイトを参照してください。
http://developer.iplanet.com/appserver/samples/pkging/docs/index.html
アプリケーションのパッケージ化の詳細については、第 11 章「配置のためのパッケージ化」を参照してください。
機能の分離
各モジュールには、特定の処理だけを割り当てる必要があります。たとえば給与システムでは、401k アカウントにアクセスする Enterprise JavaBeans と給与データベースにアクセスする Enterprise JavaBeans とは、分離する必要があります。タスクを機能別に分離することによって、ビジネスロジックは物理的に 2 つの Bean に分離されます。異なる開発チームがこれらの Bean を作成する場合、各チームは EJB JAR パッケージを個別に開発する必要があります。
シナリオ 1
UI 開発チームが、2 つの Bean 開発チームと協力して作業するとします。この場合、UI 開発チームは、Servlet、JSP、およびスタティックファイルを 1 つの WAR ファイルにパッケージ化する必要があります。次のようにします。給与システム EAR ファイル = 給与 EJB jar
+ 401k ejb JAR
+ UI チームの 1 つの共通 warEAR ファイル内でこのように機能を分離しても、各モジュール間で対話することができます。これらの Bean は、個別の EJB JAR ファイルから相互にビジネスメソッドを呼び出すことができます。このパッケージ化の例は、サンプル A にあります。
シナリオ 2
Bean の各開発チームに、UI 開発チームが個別に存在するとします。この場合、各 Web 開発チームは、Servlet、JSP、およびスタティックファイルを個別の WAR ファイルにパッケージ化する必要があります。次のようにします。給与システム EAR ファイル = 給与 EJB jar
+ 401k ejb JAR
+ 1 つの給与 UI チームの war + 1 つの 401k UI チームの warこのように設定すると、各 WAR ファイルのコンポーネントからほかの WAR ファイルのコンポーネントにアクセスできます。このパッケージ化の例は、サンプル B にあります。
シナリオ 3
各モジュールが共有ライブラリから関数にアクセスするとします。いくつかのモジュールが共有ライブラリからメソッドにアクセスする場合は、共有ライブラリを EAR ファイルの特定のモジュールに追加する必要があります。この場合の例については、サンプル C を参照してください。
パッケージ化の式
モジュールとアプリケーションをパッケージ化するときの式は、通常、次のようになります。
再利用可能なコード
コンポーネントの再利用は、アプリケーションではなくモジュールをパッケージ化および配置するときに、特に有効です。ある開発者チームが開発したコードが、複数のアプリケーション (EAR ファイルが異なる場合) からアクセスされる再利用可能なコンポーネントである場合、次のコマンドを使ってそのコードをモジュールとしてパッケージ化および登録する必要があります。iasdeploy deploymodule module_name
パッケージ済みコンポーネント
アプリケーションを最初から作成したくない場合は、パッケージ済みコンポーネントを利用できます。J2EE コンポーネントの主なベンダーは、サービスを全体的に管理するためのモジュールで構成される、さまざまなパッケージ済みコンポーネントを提供しています。パッケージ済みコンポーネントでは、アプリケーションに必要な標準コンポーネントの最大 60% を提供することを目標としています。iPlanet Application Server では、パッケージ済みの標準コンポーネントで構成したアプリケーションを簡単にパッケージ化できます。
一意の名前
各モジュール、アプリケーション、および EJB に対して一意の名前を割り当てることは、重要な要素です。いくつかの命名規則を作成すれば、2 つのエンティティに同じ名前を割り当てることがなくなります。たとえば、すべてのモジュールに確実に一意名を割り当てるには、アプリケーション名をモジュール名の接頭辞にします。この命名規則に従えば、アプリケーション pkging.ear 内の WAR モジュールの最適な名前は、pkgingWar.war になります。EJB の JNDI 検索名も一意でなければなりません。この場合も、一貫した命名規則を作成すると有効です。たとえば、EJB 名にアプリケーション名とモジュール名を追加すると、確実に一意な名前になります。この場合、モジュール pkgingEJB.jar 内の EJB の JNDI 名は、アプリケーション pkging.ear にパッケージ化されているため、mycompany.pkging.pkgingEJB.MyEJB になります。
共有フレームワーククラス
LDAP SDK、Cocobase CMP ランタイムなどのアプリケーションでは、1 つのモジュール化ライブラリにアクセスする必要があります。この場合、次の 2 つの理由から、J2EE アプリケーションごとにライブラリを含めることはお勧めできません。
ライブラリのサイズ : ほとんどのフレームワークライブラリはサイズが大きいため、アプリケーションに含めると、パッケージ化したときのアプリケーションサイズが大きくなります。
このライブラリを iPlanet Application Server 実行時環境に含める方法の 1 つとして、このライブラリをシステムクラスパス (NT の場合は install_dir/ias/env ディレクトリにある iasenv.ksh スクリプト内と iPlanet Application Server レジストリ内) に追加する方法があります。この場合、フレームワークがシステムクラスローダによって読み込まれます。システムクラスローダについては、「クラスローダの階層」を参照してください。複数のインスタンス : クラスローダが個別に各アプリケーションを読み込むため、実行時に複数のフレームワーククラスのコピーが生成されます。
セッションとセキュリティの問題
セッションを共有する必要がある場合は、セッションにアクセスするすべてのコンポーネントを同じアプリケーションに含める必要があります。アプリケーションの境界にまたがったセッションの共有は、iPlanet Application Server ではサポートされていないうえ、J2EE 仕様書に違反しています。HTTP セッションを EAR ファイル内の 2 つの WAR ファイル間で共有する場合は、そのセッションが分散することを配置記述子に記述する必要があります。この例はサンプル B にあります。
クラス、EJB などのリソースに対する認証されていない実行時アクセスは、禁止してください。モジュールは、そのモジュールに含まれるほかのリソースに対してアクセス権を持つクラスだけで構成してください。また、重要なタスクには、J2EE 標準の宣言セキュリティ (第 13 章「安全なアプリケーションの作成」を参照) を使用する必要があります。
前へ 目次 索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
最新更新日 2002 年 3 月 6 日