|
|
開発ガイド 05/16/03 09:21:28 |
この章では、「J2EEまたはWebサービスアプリケーション」のライフサイクルについて説明します。また、開発プロセスの各フェーズを考察して、Novell exteNd Workbenchがどのように役立つかについても説明します。このプロセスは、次の項目から成り立ちます。
包括的な設計フェーズは、アーキテクチャおよび技術において適切な選択を行えるようにし、プロジェクトを成功させるために推奨されています。このようなフェーズには、次の項目が含まれます。
アプリケーションを手動で設計したり、自動化された設計およびモデリングツールを使用して設計したりした後、その設計をWorkbenchを使用して実装できます。
J2EE (Java 2 Platform, Enterprise Edition)サーバに対してアプリケーションを設計する場合は、従うべきプログラミングモデルを十分に考慮してください。MVC (Model-View-Controller)アーキテクチャなどの良いモデルは、J2EEアプリケーションの潜在的な複雑さを処理するために使用できます。Jakarta Strutsプロジェクトは、よく知られているMVC実装です。
アプリケーション設計では、必要なJ2EE技術を指定する必要もあります。このような技術には、次のものが含まれます。
「コンポーネント技術」: アプリケーションクライアント、サーブレット、JSPページ(JavaServer Pages)、EJB (Enterprise JavaBeans)など
「サービス技術」: JNDI (Java Naming and Directory Interface)、JDBC (Java Database Connectivity)、Connectorアーキテクチャ(リソースアダプタ)、JTA (Java Transaction API)、JAAS (Java Authentication and Authorization Service)、JavaMail、JMS (Java Messaging Service)、JAXP (Java API for XML Parsing)など
J2EEアプリケーション設計の詳細については、次の表を参照してください。
|
学習内容 |
参照 |
|---|---|
|
J2EEアプリケーションの設計 |
Sun Blueprints ( java.sun.com/blueprints)から入手できる『Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition』 |
|
MVCアーキテクチャのStruts実装の使用 |
|
|
Novell推奨のJ2EE開発の最良実施例 |
Webサービスの設計には、次のようないくつかの標準技術が関連します。
SQAP (Simple Object Access Protocol) : 開発プラットフォームとソース言語の違いにかかわらず、ソフトウェアコンポーネントの通信を可能にするXMLベースのメッセージングプロトコル
WSDL (Web Services Description Language) : Webサービスの特徴を表すXMLベースの言語
UDDI (Universal Description, Discovery and Integration) : ビジネスおよびWebサービスに関する情報の中央のネットワークアクセス可能なリポジトリを発行して照会できるようにするレジストリ
Webサービスプロバイダは、一般的に注意深くハードウェアおよびソフトウェアの設計を選択することにより、サービスの可用性、信頼性、およびスケーラビリィティが高いことを保証しなければなりません。Workbenchで作成されたWebサービスは、J2EE技術を使用して実装されるので、J2EEの最良実施例は設計にも適用されます。
Webサービス設計の詳細については、次の表を参照してください。
|
学習内容 |
参照 |
|---|---|
|
Webサービスを実装するアプリケーションの設計 |
|
|
Webサービスにアクセスするアプリケーションの設計 |
J2EEアプリケーションまたはWebサービスを開発するためのWorkbenchの使用には、次の操作が含まれます。
Workbenchでは、「プロジェクト」は、作成するJ2EEモジュールを通常は表します。次の「J2EEアーカイブ」を作成するWorkbenchプロジェクトを作成できます。
これらのWorkbenchプロジェクトでは、開発のJ2EEコンポーネントモデルをサポートしています。これにより、企業アプリケーションまたはアプリケーション全体の小さな部分を作成、変更、および構築することが可能になります。
基本手順 WorkbenchでのJ2EE開発プロジェクトの一般的なセットアッププロセスには、次の手順が含まれます。
ファイルシステムでの ソースディレクトリおよびファイルの整理
必要なJ2EEアーカイブに対するWorkbenchでの プロジェクトおよびサブプロジェクトの作成
Workbenchでの プロジェクトへの既存のソースディレクトリおよびファイルの追加
たとえば、企業アプリケーションを表す単一のトップレベルのプロジェクトを作成した後、ユーザインタフェースに対するWebモジュール、ビジネス論理およびデータベースアクセスに対するEJBモジュールなど、アプリケーションを構成するさまざまなモジュールに対してサブプロジェクトを作成することができます。
Workbenchのプロジェクトやサブプロジェクトの詳細については、『ツールガイド』の「
プロジェクトおよびアーカイブ」を参照してください。
Webサービスプロジェクトのセットアップ Workbenchでは、WebサービスはWAR (Web Archive)として配備されます。Webサービスプロジェクトをセットアップするには、WARプロジェクトを作成するときと同じ手順に従います。
最初のセットアップ手順は、プロジェクトを最初から作成するか、または既存のJ2EEソースをWorkbenchにインポートするかによって異なります。
Workbenchには、作成するアーカイブの各タイプに対してプロジェクトを作成できるようにするNew Projectウィザードがあります。たとえば、Enterprise Archiveを作成する場合、プロジェクトとしてEARを選択し、プロジェクト名、ファイルシステムの場所、およびJ2EEバージョンを指定できます。Workbenchでは、プロジェクトの場所に「プロジェクトファイル」(拡張子はSPF)を作成します。
アプリケーションのJ2EEモジュール(WAR、RAR、EJB JAR、クライアントJAR)に対してプロジェクトを作成すると、EARプロジェクトにサブプロジェクトとして追加できます。
プロジェクトおよびサブプロジェクトの整理の詳細については、『ツールガイド』の「
プロジェクトの整理」を参照してください。
プロジェクトに対するJ2EEバージョンの選択の詳細については、『お使いになる前に』の
J2EEバージョンの処理方法に関する章を参照してください。
アプリケーションアーキテクチャをWorkbenchプロジェクトおよびサブプロジェクトで表したら、既存のソースディレクトリおよびファイルをそれらに追加できます。たとえば、一部のアプリケーションコンポーネントに対するJavaクラスがすでに存在している場合があります。また、他のアプリケーションから再使用するいくつかの標準リソース(グラフィックなど)が存在する場合もあります。
可能な限り、個々のファイルではなく、ファイルを含む「ディレクトリ」を追加します。プロジェクトにディレクトリを追加すると、そのディレクトリのファイルはすべてプロジェクトに自動的に含まれます。個々のファイルを指定する場合は、そのディレクトリに作成された新しいファイルをプロジェクトに手動で追加しなければなりません。
プロジェクトへのディレクトリおよびファイルの追加の詳細については、『ツールガイド』の「
プロジェクトの追加」を参照してください。
Workbenchには、プロジェクトに対してJ2EEコンポーネントを作成して維持できるようにする「コンポーネントウィザード」および「ソースエディタ」があります。WorkbenchはJ2EE標準に準拠しているため、Workbenchプロジェクトのコンポーネントを開発するためにサードパーティ製ツールを使用するオプションもあります。
Workbenchで新しいファイルを要求するたびに、ウィザードを使用して、J2EEコンポーネントや希望する他の項目の種類を作成できます。Workbenchには、JSPページとタグライブラリ、サーブレット、EJB、JavaBeansとJavaクラス、XMLファイル、WSDLファイル、テキストファイル、Webサービスなどに対するウィザードが装備されています。 Web Serviceウィザードでは、Webサービス(WARプロジェクトに対するSOAP対応のサーブレットおよびサポートクラス)、またはWebサービスコンシューマ(Webサービスにアクセスするためのクラス)を作成できます。
各ウィザードでは、要求された項目に関する情報を収集し、その項目に対するファイルとディレクトリを作成して(存在する場合はJavaソースを含む)、適切なプロジェクトにその項目を追加します。
詳細については、『ツールガイド』の「
ソースファイルの作成」および「
コンポーネントウィザード」を参照してください。
Workbenchには、プロジェクトのソースファイルをさらに開発するために使用できるさまざまなエディタ(次を参照)があります。
ファイルを開くと、Workbenchでは、そのファイルタイプに適切なエディタを自動的に呼び出します。エディタの機能には、アーカイブへの対応性、さまざまなコーディングの利便性、およびバージョン制御アクセスが含まれます。
このようなエディタの使用の詳細については、『ツールガイド』の「
ソースエディタ」を参照してください。
バージョン制御アクセスの詳細については、『ツールガイド』の
Workbenchの基礎に関する章を参照してください。
Workbenchでは、作成方法にかかわらず、J2EEモジュールまたはコンポーネントをサポートします。つまり、希望のサードパーティ製ツール(別のIDEやエディタなど)を使用してモジュールやコンポーネントを開発し、それらをWorkbenchにインポートすることができます( プロジェクトへの既存のソースディレクトリおよびファイルの追加の説明を参照)。
Workbenchでは、作成する任意のJ2EEプロジェクトまたはサブプロジェクトに適切な配備記述子を生成します。プロジェクトのコンテンツを変更すると、Workbenchでは、対応する配備記述子を自動的に更新します。
Workbenchには、配備記述子ファイルを手動で編集できるようにする「配備記述子エディタ」が装備されています。このエディタでは、配備記述子情報をグラフィックベースおよびテキストベースの両方で表示できます。
『ツールガイド』の「
配備記述子エディタ」を参照してください。
Workbenchではプロジェクトがファイルシステムで維持されるため、複数の開発者の間で作業を共有することは簡単です。この節では、プロセスフローをスムーズにするためのヒントを紹介します。
プロジェクトを変更すると(ファイル、ディレクトリ、コンポーネント、またはモジュールの追加など)、Workbenchでは、必要に応じてプロジェクトのSPFと配備記述子を更新します。複数の開発者がプロジェクトファイルの同じセットを操作する場合、このような変更から問題がいくつか発生することがあります。正しいソース制御プロセスに従うと、通常は、プロジェクト構造やコンテンツにおける変更が適切に処理されます。
プロジェクトレベルの変更を行う場合は、該当するプロジェクトファイルへの書き込みアクセスが必要です。これは、SPF、配備記述子、およびコンポーネントファイルをバージョン制御システムからチェックアウトすることを通常は意味します。チームの他の人とプロジェクトレベルの変更を共有するには、プロジェクトファイルをチェックインする必要があります。チームの他のメンバーは、変更されたプロジェクト構造やコンテンツを反映させるために、自分たちの作業領域を更新しなければなりません。
Workbenchでコンポーネントまたはモジュールを作成する場合は、アーカイブおよびディレクトリに対するパスを指定します。複数の開発者が1つのプロジェクトを操作する状況では、このようなパスをプロジェクトディレクトリに関連して指定することができます。
相対パスを使用する利点は、プロジェクトファイルがドライブ文字や他の絶対パス構造に依存しないことです(ファイルシステム間では問題となることがあります)。たとえば、コンピュータにマップされた「Z:」ドライブは、別の開発者のコンピュータには存在しないことがあります。プロジェクトにアクセスするすべての開発者がドライブの既知のセットを持つことを保証できない限り、相対パスを使用することが推奨されます。
不利な点は、ディレクトリ構造が深いと、相対パスは解読するのが難しい場合があることです(たとえば、ファイルが..\..\..\..\beans\classes\checker.classとして指定されている場合など)。
Workbenchでは、プロジェクトファイルの作成およびJ2EEアーカイブの作成において柔軟性が与えられます。このため、次のことが行えます。
作成操作は、Workbench IDEまたはコマンドラインから実行できます。いずれの場合も、プロジェクト設定は、作成の詳細(クラスファイルおよびアーカイブを生成する場所など)を指定するために使用されます。
詳細については、『ツールガイド』の「
コンパイル、作成、およびアーカイブ」を参照してください。
プロジェクトアーカイブの検証 Workbenchは、 プロジェクト(およびそのサブプロジェクト)に対して生成されたアーカイブを検証できるようにもします。検証は、配備前に行うと良いチェックです。これにより、アーカイブの配備記述子が適切なJ2EE配備記述子DTDおよびアーカイブのコンテンツに一致することを確認します。
詳細については、『ツールガイド』の「
アーカイブの検証」を参照してください。
Workbenchプロジェクトのアーカイブは、生成したらJ2EEサーバに配備できます。配備方法は次から選択できます。
Workbenchには、さまざまなJ2EEサーバへの配備に対する組み込みサポートがあります。
基本手順 これらのサーバの1つにWorkbenchからプロジェクトアーカイブを配備するには、次の操作を実行します。
ターゲットJ2EEサーバでアーカイブが実行されるべき方法を説明した「サーバ固有の配備情報」を準備します。
この情報は、標準のJ2EE配備記述子と同様に、通常はXMLで表されます。たとえば、exteNd Application Serverに配備する場合は、「配備計画」(Workbenchに含まれている「配備計画エディタ」で編集できる)と呼ばれるXMLファイルを提供します。
配備する方法と場所をWorkbenchに通知する「配備設定」を指定します。
これらの設定には、すばやく変更を配備してテストするために開発フェーズ中に役立つ「高速配備」オプションが含まれます。
Workbenchからの配備の詳細については、『ツールガイド』の「
アーカイブ配備」を参照してください。
Workbenchで生成されたアーカイブを取得し、他のJ2EE互換ツール(J2EEサーバによって提供される配備機能など)を使用して配備することも可能です。この方法により、標準のJ2EEサーバに配備することが可能になります。
J2EEまたはWebサービスアプリケーションは、運用のためにリリースする前に、正しく動作し、許容レベルのパフォーマンスが得られることを確認する必要があります。品質管理プロセスには、次の作業が含まれます。
テストサーバに配備すると、アプリケーションの問題をエンドユーザまたは他のグループに知られることなく発見できます。テストサーバの一般的なシナリオは次のとおりです。
|
シナリオ |
操作 |
|---|---|
|
独自の開発作業をテストする個人である |
ローカルマシンのJ2EEサーバに配備する |
|
開発作業をチームの作業に組み込んでいる |
チームの統合テストマシンをセットアップし、そのマシンのJ2EEサーバに配備する |
|
チームが開発作業を運用段階に移行する準備をしている |
品質保証のための運用前ステージングマシンをセットアップし、そのマシンのJ2EEサーバに配備する |
可能な限り、テスト環境は、アプリケーションが実行される運用環境に類似するように設定する必要があります。テストサーバのセットへの配備は、Workbenchでそれらのサーバにサーバプロファイルを定義することにより促進できます。
『ツールガイド』の
サーバプロファイルの説明を参照してください。
多くの場合、Webブラウザを使用してJ2EEサーバから特定のURLを要求することにより、配備済みのJ2EEアプリケーションがどのように実行されるかをテストできます。この方法は、「JSPページ」および「サーブレット」をテストする場合だけでなく、これらのJSPページやサーブレットによってアクセスされる他のコンポーネントやサービス(Webサービス、EJB、リソースアダプタ、タグライブラリ、フィルタ、JavaBeans、サポートクラスなど)をテストする場合にも適用されます。
配備済みのJ2EE「アプリケーションクライアント」のテストでは、異なる方法が必要です。これには、クライアントコンテナの呼び出しと、クライアントコンテナへのクライアントの開始の要求が基本的に含まれます(ただし、正確なプロセスは、クライアントコンテナのJ2EEサーバの実装によって異なります)。
特定タイプのJ2EEコンポーネントの実行の詳細については、
J2EEコンポーネントの作成の該当する章を参照してください。
WebサービスまたはWebサービスコンシューマのテストの詳細については、
Webサービスの作成および使用の該当する章を参照してください。
アプリケーションを実行し始めたら、プログラムの実行を制御し、プログラムのステータスを監視するためのデバッグツールを使用できます。このツールは、ランタイムエラーを検索して修正することを可能にします。Workbenchには、J2EEおよび他のJavaアプリケーション(ローカルまたはリモートマシンのクライアント側またはサーバ側のオブジェクト)をデバッグするために起動できる「デバッガ」が装備されています。
詳細については、『ツールガイド』の章「
デバッガ」を参照してください。
|
|
開発ガイド 05/16/03 09:21:28 |
Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.