|
| Sun ONE Application Server 7 開発者ガイド |
アプリケーションの設計moduleアプリケーションの設計プロセスの概要を説明し、Sun ONE Application Server の効果的な開発のためのガイドラインを提供します。
module次の節があります。
アプリケーションの要件
Sun ONE Application Server アプリケーションを開発するときは、まず、アプリケーションの要件を明確にします。通常、高速かつ安全であり、新規ユーザーによる追加要求に対して信頼性の高い処理が期待できる、広範囲に配備可能なアプリケーションを開発することを意味します。
Sun ONE Application Server は、J2EE API だけでなく既存の高性能機能もサポートしており、これらの要件を満たしています。たとえば、オンラインバンキングアプリケーションでは、次の機能を提供することができます。
- セキュリティ
- 特定機能の導入時間の短縮。口座振替、会計報告、オンライン取引、特定の条件を満たしたお客様に対する特別サービスなど
- さまざまなタイプのエンドユーザーの管理。個人、法人、社内ユーザー (銀行の従業員) など
- 内部レポート
- EIS (Enterprise Information System : 企業情報システム) との接続性。従来のデータベースに格納されている情報へのアクセスを提供
J2EE プログラミングモデルについて
次の図では、クライアントマシンが Web ブラウザ、Web サービス、RMI/IIOP、または JMS クライアントを稼動し、J2EE サーバーマシンが Sun ONE Application Server を稼動しています。データベースとレガシーアプリケーションは、EIS サーバーマシンによって稼動されます。JSP とサーブレットはクライアントレイヤにインタフェースを提供し、EJB コンポーネントはビジネスレイヤに含まれます。レガシーアプリケーションへのインタフェースは、コネクタによって提供されます。
J2EE のアプリケーションレイヤ
分散アプリケーションモデルでは、個々の異なるアプリケーションレイヤを別々の機能要素に集中させることができるため、パフォーマンスが向上します。
これらのアプリケーションレイヤについては、次の節で説明します。
クライアントレイヤ
クライアントレイヤは、ユーザーがアプリケーションにアクセスするレイヤです。アプリケーションには、次のいずれかのタイプのクライアントが必要な場合があります。
クライアントレイヤ内のコンポーネントに関する詳細は、『Sun ONE Application Server Developer's Guide to Clients』を参照してください。
ブラウザクライアント
多くの場合、クライアントはブラウザです。
シンプルな CORBA クライアント
CORBA (Common Object Request Broker Architecture) と互換性のあるクライアントであれば、どれでも Sun ONE Application Server に配備された EJB コンポーネントにアクセスできます。クライアントは、Java、C、C++、Visual Basic など、CORBA に対応している言語で記述できます。CORBA クライアントは、スタンドアロンプログラムまたは別のアプリケーションサーバーを、Sun ONE Application Server に配備したアプリケーションのクライアントとして動作させる場合に使用します。
Sun ONE Application Server では、『Enterprise JavaBeans Specification, V2.0』および『Enterprise JavaBeans to CORBA Mapping』仕様書で指定されている IIOP プロトコルを使用した EJB コンポーネントへのアクセスをサポートしています。
ACC (Application Client Container) を使用しないシンプルな CORBA クライアントには、次の制限があります。
- JNDI がサポートされない。ただし、名前を変換し、標準の COSNaming バインドを使って検索できる
- RMI/IIOP を介した SSL がサポートされない
- sun-application-client.xml ファイルと sun-acc.xml ファイルで設定する機能を利用できない
ACC クライアント
Sun ONE Application Server では、Java で記述され、RMI/IIOP を介してサーバーと通信する ACC (Application Client Container) CORBA クライアントをサポートしています。
Sun ONE Application Server は、ACC クライアントプログラムを実行可能にするシステムサービスを提供します。ACC クライアントは、JNDI (Java Naming and Directory Interface) を使って EJB コンポーネント、JDBC リソース、JavaMail などのサービスを特定します。特別な機能の設定には、application-client.xml と sun-application-client.xml という配備記述子ファイルを使います。
このマニュアルで説明するすべての CORBA クライアントは、特に明記されていない限り ACC クライアントでもあります。
Web サービスクライアント
通常、ビジネスアプリケーションは、HTTP を介した SOAP プロトコルを使用して、所定の URL で Web サービスへリクエストを送信します。サービスはそのリクエストを受信し、処理した後、応答を返します。よく引用される Web サービスの例として、株式相場サービスがありますが、その場合、指定した株式の現在値をリクエストすると、その株価を応答するというサービスです。
Sun ONE Application Server では、Apache SOAP バージョン 2.2 および JAX RPC 1.1 をサポートしています。Apache SOAP Web サービスのサポートは、Sun ONE Studio 4 にも組み込まれています。
Web サービスの詳細は、『Sun ONE Application Server Developer's Guide to Web Services』を参照してください。
JMS クライアント
JMS (Java Message Service) を使用する Java アプリケーションは、JMS クライアントと呼ばれます。JMS クライアントは、メッセージの作成、送信、受信、および読み取りが可能です。メッセージを送信するクライアントはプロデューサと呼ばれ、メッセージを受信するクライアントはコンシューマと呼ばれます。JMS の詳細は、『Sun ONE Message Queue 開発者ガイド』を参照してください。
プレゼンテーションレイヤ
プレゼンテーションレイヤでは、ユーザーインタフェースが動的に生成されます。アプリケーションには、プレゼンテーションレイヤ内に、次の J2EE コンポーネントが必要です。
さらに、アプリケーションには、プレゼンテーションレイヤ内に、次の J2EE 以外の HTTP サーバーベースのコンポーネントが必要になる場合があります。
プレゼンテーションレイヤ内のコンポーネントに関する詳細は、『Sun ONE Application Server Web アプリケーション開発者ガイド』を参照してください。
サーブレット
サーブレットは、アプリケーションのプレゼンテーションロジックを処理します。サーブレットは、ページ間移動ディスパッチャ、セッション管理、および簡単な入力確認を処理します。また、ビジネスロジックの要素を互いに関連付けます。
したがって、サーブレット開発者は、HTTP リクエスト、セキュリティ、国際化、および Web のステートレス (セッション、cookie、タイムアウトなど) に関するプログラミングの問題を理解する必要があります。Sun ONE Application Server アプリケーションでは、サーブレットは Java で記述する必要があります。サーブレットは、JSP、EJB コンポーネント、および JDBC オブジェクトを呼び出します。したがって、サーブレット開発者はこれらのアプリケーション要素の開発者と緊密に協力して作業する必要があります。
JSP
JSP は、ほとんどのアプリケーション表示タスクを処理し、サーブレットとともに動作することによって、アプリケーションの表示画面およびページ移動を定義します。JSP は、EJB コンポーネントおよび JDBC オブジェクトを呼び出します。EJB コンポーネントは、通常、ビジネスロジック機能をカプセル化します。EJB は、このようにして、計算やその他の繰り返し要求されるタスクを実行します。JDBC オブジェクトは、データベースに接続し、クエリを実行し、クエリ結果を返します。
静的なコンテンツ
画像や HTML ページなどの静的なコンテンツも利用できます。適切に設計された HTML ページでは、次の効果が得られます。
- ブラウザが異なっていても外観が統一される
- 低速モデムによる接続でも HTML が効果的に読み込まれる
- サーブレットまたは JSP がディスパッチした、動的に生成されたページが表示される
SHTML
SHTML (サーバー解析 HTML) ファイルとは、サーバー上で実行されるタグを含んだ HTML ファイルのことです。SSI などの標準サーバーサイドタグをサポートするほかに、Sun ONE Application Server 7 は、サーブレットを埋め込んだり、独自のサーバーサイドタグを定義することができます。
CGI
CGI (Common Gateway Interface) プログラムは、サーバー上で動作し、リクエストを送信したクライアントに返す応答を生成します。CGI プログラムは、シェルスクリプトとして、C、C++、Java、Perl などさまざまな言語で記述されます。CGI プログラムは、URL を呼び出すことにより、起動します。Sun ONE Application Server は、CGI バージョン 1.1 仕様に準拠しています。
ビジネスロジックレイヤ
ビジネスロジックレイヤには通常、ビジネスルールおよびその他のビジネス機能を、次のコンポーネントにカプセル化する EJB コンポーネントが配備されています。
ビジネスロジックレイヤ内のコンポーネントに関する詳細は、『Sun ONE Application Server Enterprise JavaBeans 開発者ガイド』を参照してください。
セッション Beans
セッション Beans で、ビジネスプロセスおよび規則のロジックをカプセル化します。たとえば、セッション Beans では請求書の税金を計算できます。頻繁に変更が加えられる複雑なビジネスルールの場合 (新しい商慣習、政府規制など)、通常、アプリケーションはエンティティ Beans よりもセッション Beans を多く使うので、セッション Beans を絶えず改訂する必要があります。
セッション Beans は、ほかの EJB コンポーネントだけでなく、あらゆる JDBC インタフェースを呼び出します。アプリケーションは、本来ステートフルなセッション Beans がステートレスであっても、十分に動作するようになっています。ショッピングカートなど、ユーザー固有の状態をサーバー側で維持する必要がある場合は、ステートフルセッション Bean が必要です。
エンティティ Beans
エンティティ Beans は、データベース行などの持続的オブジェクトを表します。エンティティ Beans はあらゆる JDBC インタフェースを呼び出します。ただし、ほかの EJB コンポーネントを呼び出すことはありません。エンティティ Beans 開発者の役割は、組織のビジネスデータのオブジェクト指向ビューを設計することです。多くの場合、オブジェクト指向ビューを作成することは、エンティティ Beans へデータベーステーブルをマッピングすることです。たとえば、開発者は、顧客テーブル、インボイステーブル、および注文書テーブルを、対応する顧客オブジェクト、請求書オブジェクト、および注文書オブジェクトに変換します。
エンティティ Beans 開発者は、セッション Beans 開発者および サーブレット開発者と協力して、アプリケーションでの持続性ビジネスデータへの高速でスケーラブルなアクセスを実現します。
エンティティ Bean の持続性には次の 2 種類があります。
- コンテナ管理による持続性 (CMP) - ビジネスロジックとデータベースの間のやり取りは、EJB コンテナによって維持される
- Bean 管理による持続性 (BMP) - データベースとのやり取りを制御するコードの記述は開発者に任される
メッセージ駆動型 Beans
メッセージ駆動型 Beans は、エンティティ Beans と同様に、あらゆる JDBC インタフェースを呼び出す持続性のあるオブジェクトです。ただし、その他の EJB コンポーネントとは異なり、メッセージ駆動型 Beans はローカルインタフェースやリモートインタフェースを持ちません。また、Beans へのアクセス方法も他のエンティティ Beans とは異なります。
メッセージ駆動型 Bean は、待ち行列または永続的なサブスクリプションからのメッセージを確実にコンシュームできるメッセージリスナーです。アプリケーションクライアント、別の EJB コンポーネント、Web コンポーネントなどの J2EE コンポーネントから送信されるメッセージや、J2EE テクノロジを使用しないアプリケーションやシステムから送信されるメッセージを処理できます。
たとえば、在庫エンティティ Beans は、在庫数が設定された下限を下回ったら、在庫注文メッセージ駆動型 Beans へメッセージを送信します。
データアクセスレイヤ
データアクセスレイヤでは、JDBC (Java database connectivity) を使用して、データベースへの接続、クエリの実行、およびクエリ結果の返送を行います。また、IBM の CICS のようなレガシー EIS システムと Sun ONE Application Server の通信を可能にするために、カスタムコネクタが使われます。
開発者は、J2EE CA (コネクタアーキテクチャ) を使って、次のシステムへのアクセスを統合します。
- 企業リソース管理システム
- メインフレームシステム
- サードパーティ製のセキュリティシステム
JDBC の詳細については、『Sun ONE Application Server Developer's Guide to J2EE Features and Services』を参照してください。
コネクタの詳細については、『Sun ONE J2EE CA Service Provider Implementation 管理者ガイド』および該当するリリースノートを参照してください。
J2EE アプリケーションの最適な設計方法
この節では、Sun ONE Application Serverアプリケーションの設計および開発時に考慮する必要があるガイドラインについて簡単に説明します。『Core J2EE Patterns: Best Practices and Design Strategies』 (Deepak Alur、John Crupi、and Dan Malks 著) も参考になります。
このガイドラインは次の目的に分類されます。
サーブレットおよび JSP を使ったデータ表示
サーブレットはプレゼンテーションロジックによく使われ、ユーザー入力およびデータ表示のセントラルディスパッチャとして機能します。JSP は、プレゼンテーションレイアウトをダイナミックに生成します。サーブレットおよび JSP を使うと、条件に応じてさまざまなページを生成できます。
ページのレイアウトが主であり、ページを作成するための処理が最小限の場合は、対話に JSP を使った方が簡単な場合があります。
たとえば、オンライン書店のアプリケーションではユーザーの認証後に、ユーザーが、本の検索、選択したアイテムの購入などのいくつかのタスクを行うためのポータルフロントページを提供します。このポータルページは処理をほとんど行わないため、JSP で実装することができます。
JSP と サーブレットを 1 枚のコインの表と裏と考えてください。JSP のタスクはサーブレットでも実行でき、その逆の操作も可能です。しかし、JSP のタスクは JSP に最適化されており、サーブレットのタスクはサーブレットに最適化されています。サーブレットは処理能力と適応性に優れています。ただし、Java ファイルから HTML の出力を行うと、扱いにくい println 文が多量に発生します。JSP は HTML ファイルなので、複雑な計算や処理タスクの実行には不向きですが、HTML エディタで編集できるので、レイアウト作業に優れています。JSP とサーブレットを併用することで、両者の長所を生かすことができます。
サーブレットと JSP に関する詳細は、『Sun ONE Application Server Web アプリケーション開発者ガイド』を参照してください。
再利用可能なアプリケーションコードの作成
オブジェクト指向の最適な設計方針が使われている場合を除き、再利用性を最大限にするためには、アプリケーション開発時に次の点を考慮する必要があります。
- コードツリーを移動した場合でもリンクが無効にならないように、相対パスと相対 URL を使う
- JSP 内での Java の使用を最小限に抑え、サーブレットおよびヘルパークラス内で Java を使う。JSP 設計者は、Java に関する高度な知識がなくても JSP を修正できる
- データソース名、テーブル名、カラム名、JNDI オブジェクト名、ほかのアプリケーションプロパティ名などのハードコードされた文字列の保存には、プロパティファイルまたはグローバルクラスを使う
- ドメイン固有のビジネスルールや入力確認などの頻繁に変更されるビジネスルールの保存には、サーブレットや JSP でなく、セッション Beans を使う
- 持続オブジェクトにはエンティティ Beans を使う。エンティティ Beans を使うことで、各ユーザーが複数の Bean を使用することができる
- 柔軟性を最大限に高めるために、Java クラスでなく Java インタフェースを使う
- レガシーデータにアクセスするには、J2EE CA を使う
アプリケーションのモジュール化
J2EE アプリケーションを設計するときは、次の主要な要素を考慮する必要があります。
モジュールおよびアプリケーションのアセンブル方法の詳細は、「J2EE アプリケーションのアセンブルと配備」を参照してください。
機能の分離
各コンポーネントには、特定の処理だけを割り当てる必要があります。たとえば給与システムでは、401k アカウントにアクセスする EJB コンポーネントと給与データベースにアクセスする EJB コンポーネントとは、分離する必要があります。タスクを機能別に分離することによって、ビジネスロジックは物理的に 2 つの Bean に分離されます。異なる開発チームがこれらの Bean を作成する場合、各チームは EJB JAR パッケージを個別に開発する必要があります。
シナリオ 1
ユーザーインタフェース開発チームが、2 つの Bean 開発チームと協力して作業するとします。この場合、UI 開発チームは、サーブレット、JSP、および静的ファイルを 1 つの WAR ファイルにアセンブルする必要があります。次に例を示します。
給与システム EAR ファイル = 給与 EJB jar
+ 401k EJB JAR
+ UI チームの 1 つの共通 warEAR ファイル内でこのように機能を分離しても、各コンポーネント間で対話することができます。これらの Bean は、個別の EJB JAR ファイルから相互にビジネスメソッドを呼び出すことができます。
シナリオ 2
Bean の各開発チームに、UI 開発チームが個別に存在するとします。この場合、各 Web 開発チームは、サーブレット、JSP、および静的ファイルを個別の WAR ファイルにアセンブルする必要があります。次に例を示します。
給与システム EAR ファイル = 給与 EJB jar
+ 401k EJB JAR
+ 1 つの給与 UI チームの war
+ 1 つの 401k UI チームの warこのように設定すると、各 WAR ファイルのコンポーネントからほかの WAR ファイルのコンポーネントにアクセスできます。
アセンブリ式
モジュールおよびアプリケーションをアセンブルするときは、いくつかの一般的なアセンブリ式に従う必要があります。
次の表は、アセンブリ式の概要を示しています。左の列は開発グループのタイプ、真中の列はグループ内のチーム、右の列はモジュール化の式を示しています。
アセンブリ式
開発グループのタイプ
グループ内のチーム
モジュール化の式
小規模なワークグループ
1 Web チーム + 1 EJB チーム
1 EAR = 1 EJB + 1 WAR
企業のワークグループ
2 EJB チーム + 1 Web チーム + 1 コンポーネント
1 EAR = 2 EJB + 1 WAR + 1 つの個別コンポーネント
再利用可能なコード
コンポーネントの再利用は、アプリケーションよりもモジュールをアセンブルしたり配備したりするときに、特に有効です。ある開発者チームが開発したコードが、複数のアプリケーション (EAR ファイルが異なる場合) からアクセスされる再利用可能なコンポーネントである場合、そのコードを個別モジュールとして配備する必要があります。詳細は、「J2EE アプリケーションのアセンブルと配備」を参照してください。
パッケージ済みコンポーネント
アプリケーションを最初から作成したくない場合は、パッケージ済みコンポーネントを利用できます。J2EE コンポーネントの主なベンダーは、一連のサービスが用意されたさまざまなパッケージ済みコンポーネントを提供しています。パッケージ済みコンポーネントでは、アプリケーションに必要な標準コンポーネントの最大 60% を提供することを目標としています。Sun ONE Application Server では、これらのコンポーネントを利用して、アプリケーションを簡単にアセンブルできます。
共有フレームワーククラス
複数のアプリケーションが単一のモジュールライブラリにアクセスしなければならないこともあります。この場合、次の理由から、各 J2EE アプリケーションにライブラリを含めることはお勧めできません。
- ライブラリサイズ : ほとんどのフレームワークライブラリはサイズが大きいため、アプリケーションに含めると、アセンブルしたときのアプリケーションサイズが大きくなる
- 異なるバージョン: 複数のクラスローダーが個別に各アプリケーションを読み込むため、実行時に複数のフレームワーククラスのコピーが生成される
複数のアプリケーションが共有できるようにライブラリを設定する方法については、「クラスローダー分離の回避」を参照してください。
セッションとセキュリティの問題
セッションを共有する必要がある場合は、セッションにアクセスするすべてのコンポーネントを同じアプリケーションに含める必要があります。
注 複数のアプリケーションによるセッションの共有は、Sun ONE Application Server ではサポートしていません。また、J2EE 仕様書に違反しています。
HTTP セッションを EAR ファイル内の 2 つの WAR ファイル間で共有する場合は、そのセッションを分散させることを配備記述子に記述する必要があります。
クラス、EJB コンポーネントなどのリソースに対する認証されていない実行時アクセスは、禁止してください。コンポーネントは、そのコンポーネントに含まれるほかのリソースに対してアクセス権を持っているクラスだけで構成してください。また、重要なタスクには、J2EE 標準の宣言セキュリティ (「J2EE アプリケーションのセキュリティ」を参照) を使用する必要があります。