 |
|
機能ガイド 05/21/03 11:36:28 |
この章では、Novell exteNd アプリケーションサーバに関する実装の詳細をいくつか紹介します。 トピックは次のとおりです。
J2EEコンポーネントモデルの中心となるのがコンテナです。 コンテナは、Novell exteNd アプリケーションサーバなどのJ2EEプラットフォームプロバイダによって提供されるランタイム環境です。 コンテナは、アプリケーション開発者がプレゼンテーションやアプリケーションのビジネス論理に集中できるようにするための、ライフサイクル管理およびその他のサービスを提供します。
アプリケーションサーバによって、それぞれ3つの種類のJ2EEコンテナが実装されます。
Webコンテナには、WAR(Web archive)ファイルにパッケージ化されている「Webアプリケーション」が含まれています。 アプリケーションサーバに配備する各WARは、完全な、スタンドアロンのアプリケーションとして機能します。 WARファイルには、アプリケーションで使用するすべてのJSPページ、サーブレット、JavaBeanコンポーネント、ユーティリティクラス、静的HTMLページ、およびサウンドが含まれている必要があります。
JSPページおよびサーブレット WARをサーブレットに配備した後は、WAR内の各JSPページはサーブレットのように動作します。 ページはURLと関連付けられています。 Webクライアントまたはサーバ側のオブジェクトがそのURLで操作を実行する際、サーバは関連付けられたサーブレットを検索し、これをインスタンス化して、サーブレットに関連付けられているinit()および service()メソッドを呼び出します。 サーブレットをアンロードしようとする際、サーバはdestroy()メソッドを呼び出します。
WAR内のJSPページ(またはサーブレット)のサーブレットコンテキストは、WAR自身です。 これはすなわち、WARでアプリケーションの境界を定義しているため、JSPページまたはサーブレットは別のWARに常駐するJSPページまたはサーブレットに転送する(あるいは含める)ことはできないことを意味します。
持続性 アプリケーションサーバ上で実行しているJSPページは、持続的ではありません。 各HTTPリクエストに対して、JSPページの新規のインスタンスが作成されます(配備記述子の中でJSPページがthreadsafeとして定義されているかどうかによります)。
応答 アプリケーションサーバは、Servlet APIを使用して応答バッファリングを実装します。 応答データをバッファに格納するため、ServletResponseインタフェースの次のメソッドが使用されます。
長さ サーブレットで、setContentLength()を呼び出してコンテンツの長さを指定していない場合は、サーバはHTTP 1.1チャンキングを使用してコンテンツを一連のチャンクとして転送します。
Webクライアントまたはサーバ側のオブジェクトがWARのリソースをリクエストすると、サーバはリクエストされたURLをいくつかのコンポーネントに分割します。
myWarに配備されたWARファイルに対するURLのコンポーネントの例を次に示します。
http://host/db/path/to/war/myWar/foo.jsp/pathinfo/for/jsp
ここで、コンテキストパスは/db/path/to/war、サーブレットパスは/myWar/foo.jsp、そしてpathinfoは/pathinfo/for/jspです。
JSPページまたはサーブレットは同一WARに常駐する任意の他のJSPページまたはサーブレットに転送する(あるいは含める)ことができます。
<jsp:forward>アクションまたは<jsp:include>アクションを使用すると、ターゲットURLはコンテキスト相対あるいはページ相対になることができます。 コンテキスト相対のURLはスラッシュ(/)で始まり、WARに対して相対になるように解釈されます。 コンテキスト相対のURLはスラッシュ(/)で始まり、WARに対して相対になるように解釈されます。
JSPページに対する完全なURLはhttp://localhost/myDatabase/jsptests/myjsps/test.jspで、配備時にWARに指定したURLはjsptestsであるとします。 この場合、同一WARのJSPページに次のタグを埋め込んでページにリクエストを送信することができます。
<jsp:forward page="/myjsps/test.jsp"/>
サーブレットでは、ServletContextオブジェクトのgetRequestDispatcher()メソッドを使用してターゲットURLを指定すると、URLはコンテキスト相対となります。 スラッシュ(/)で始まる必要があり、WARに対して相対になるように解釈されます。 リクエストをhttp://localhost/myDatabase/jsptests/myjsps/test.jspに送信するには、同一WAR内のサーブレットに次のコードを埋め込みます。
ServletConfig sconfig = getServletConfig();
ServletContext sc = sconfig.getServletContext();
RequestDispatcher rd =
sc.getRequestDispatcher("/myjsps/test.jsp");
rd.forward(req, res);
forward()メソッド呼び出しでは、暗黙の「リクエスト」および「応答」オブジェクトを引数として渡します。
アプリケーションサーバは、セッションを追跡するためにクッキーまたはＵＲＬリライトを使用できます。 ブラウザでクッキーがサポートされている場合はクッキーを使用し、ブラウザでクッキーがサポートされていない場合はＵＲＬリライトを使用します。
詳細については、『管理者ガイド』の
サーバ設定に関する章の節を参照してください。
EJBコンテナではEJB2.0BeanおよびEJB 1.1Bean用のランタイム環境が提供されています。 ランタイム環境には、ネーミングサービス、リモートアクセス、セキュリティ、およびトランザクションサポートなど低いレベルのサービスが含まれます。
この節では、EJBコンテナの機能について説明します。トピックは次のとおりです。
「メッセージ駆動型Bean」 - メッセージ駆動型BeanではJMSメッセージサーバによって管理されているキューまたはトピックからメッセージにアクセスできます。
「エンティティBean」 - BMP(bean-managed)とCMP(container-managed)エンティティBeanの両方をサポートします。 次のエンティティBean機能がサポートされています。
この節では、アプリケーションサーバを配備する際に提供されるサービスについて説明します。
EJBコンテナでは「配備時」と「ランタイム時」の両方でデバッギンサポートが提供されています。
配備デバッグのサポート 配備デバッグのサポートは、コマンドラインツールSilverCmdを通して提供されます。 次の表は、デバッグでもっとも役に立つコマンドについての説明です。
ランタイムデバッグサポート ランタイムデバッグサポートは、サーバの起動スイッチまたはサーバコンソールのコマンドシェルを通して提供されます。 次の表は、スイッチとその使用法についての説明です。
EJBコンテナは、エンティティ、ステートレスセッション、およびメッセージ駆動型Beanに対するインスタンスプールをサポートします。 プールはBeanごとにあり、配備計画の中で指定されます。 プールサイズを設定するには、アップデートされた配備計画を使用してBeanを再配備します。
「エンティティBeanおよびセッションBean」については、次の方法で値を指定します。
|
配備計画の項目 |
手順 |
|---|---|
|
initialPoolSize |
プールを事前割り当てするには、この値をゼロより大きい数字に設定しておきます。 |
|
maxPoolSize |
プールで未使用のインスタンスの最大数を指定します。 デフォルトは次のとおりです。 |
|
poolingPolicy |
プールサイズが最大値を超えた場合の処置を定義します。 指定できる値はCREATEとFAILです(次を参照)。 |
エンティティおよびステートレスセッションBeanのプールポリシー Beanを配備する際に、EJBコンテナではインスタンスプールを作成しません。その代わりに、インスタンスが増大する必要性に応じてプールを作成します。
「メッセージ駆動型Bean」の場合は、コンテナはServerSessionPoolインタフェースを実装することによってインスタンスプールを提供します。
ステートフルセッションBeanの非活性化 アプリケーションサーバは、GC(Garbage Collection)レートを計測することによってメモリの使用状況を監視します。 GCレートが急激に増加すると、サーバはステートフルセッションBean非活性化を開始します。 監視および非活性化を無効にするには、次の行をhttpd.propsファイルに追加します。
http-server.com.sssw.srv.disableMemMonitor=false
httpd.propsファイルは、サーバの\resources ディレクトリにあります。
負荷バランスの単位はセッションです。 単一セッション内で使用されるすべてのEJBは、クラスタ内の単一サーバ上に常駐します。 負荷バランスはユーザに透過的で、クライアントは通常のJNDIルックアップを行うことができ、ネーミングサーバーは実行するBeanのサーバを選択します。
クラスタ内でEJBを使用する場合は、別のネームサービスポートからサーバを起動する必要があります。 デフォルトのネームサービスポートは54890です。SMCを介してネームサービスポートを設定できます。
アプリケーションサーバクラスタリングメカニズムの詳細については、『管理者ガイド』の
クラスタの管理に関する章を参照してください。
EJBはJNDI(Java Naming and Directory Interface)のルートコンテキストに登録されています。 配備計画の中でJNDI名、Bean参照、リソース参照、環境変数、あるいはUserTransactionsに対して階層的なネーミング構造を指定した場合、コンテナはまだ存在していない中間サブコンテキストを作成します。
デフォルトにより、サーバはBean参照、環境変数、およびリソース参照を java:comp/ envコンテキストに登録します。 EJB仕様の推奨に従って、オブジェクトを別々のサブコンテキストに格納できますが、アプリケーションサーバではこられのネーミング規則を強制しているわけではありません。 すなわちこれはユーザ独自の運用環境にもっとも適したネーミング規則を使用できるということです。
アプリケーションサーバは、ORB (jBroker Object Request Broker)を使用しているRMI/IIOPを介してEJBへのアクセスをサポートしています。jBroker isはエンタープライズクラスのJavaベースのCORBA ORBです。
「EJBのポータブルルックアップ」については、次のようなCORBAのネーム構文を使用します。
corbaname:iiop:host:port#name
corbaname:iiop:MyMachine:54520#MyEJB
クライアントアクセス クライアントがEJBにアクセスするためには、EJBのインタフェース(コンパイル時の参照用)とコンテナ生成のスタブ(ランタイム用)を含むJARが必要です。
EJBの開発者は、EJBクライアントJARを作成し、配備記述子にejb-client-jar要素が含まれていることを確認する必要があります。 この要素が存在する場合は、コンテナはスタブクラスを生成し、スタブをクライアントJARに格納し、そしてクライアントJARをサーバにアップロードします。
EJBクライアントJARはコンテナによって生成され、サーバ上に常駐するため、JARをサーバからディスク上の適切な場所にダウンロードする必要があります。 EJBクライアントJARのディスク上の場所をクライアントのclasspathに指定します。 EJBを変更して再配備するたびに毎回新しいバージョンのEJBクライアントJARをダウンロードすることを確認してください。
EJBLocalHome/beanName
jBrokerの詳細については、サーバの\jBrokerディレクトリにあるマニュアルを参照してください。
EJBコンテナは、次のものを使用してランタイム時のセキュリティ管理を行います。
EJBを呼び出すと、サーバはユーザを認証し、呼び出し側のセッション中はサーバ上で呼び出し側のIDを使用します。 すべてのメソッド呼び出しはそのセッションのIDを使って実行されます。 ロール名を配備計画のプリンシパル(ユーザ、グループ、あるいはプリンシパルのリスト)にマップできます。
アクセス許可は、配備記述子で指定されているsecurity-role要素およびmethod-permission要素によって定義されます。 EJB JARで最低でも1つのBeanメソッドのセキュリティを設定する場合は、すべてのメソッドのセキュリティを設定する必要があります。そうしないと、コンテナはセキュリティが設定されていないすべてのメソッドは制限されているものと見なし、ユーザはメソッドの呼び出しを一切できなくなってしまいます。 また、配備記述子のexclude-list要素を使用して一連のメソッドの呼び出しができないように設定することも可能です。 制限されたメソッドが呼び出されると、コンテナはAccessRightsViolation Exceptionを発行します。 または、メソッドに対して一切のセキュリティ設定をしない非セキュリティモードを選択することもできます。
SSLを使用してEJBクライアントとアプリケーションサーバ間に安全な通信を確立できます。 jBroker ORBは、RSAに対してのみIIOP over SSLサポートを提供します。
HTTPSを実行する必要はありません。 次のことが必要となります。
安全なEJBへのアクセスのサポートに記されているように、クライアントではagrootca.jarも必要です。
EJBクライアントとアプリケーションサーバ間に安全な通信を確立する詳細については、『管理者ガイド』のセキュリティのセットアップに関する章を参照してください。
EJBコンテナは、JTS(Java Transaction Service)を完全に実装している、jBroker Transaction Managerを介して分散トランザクションをサポートします。
配備記述子でトランザクション属性が指定されていない場合、コンテナはデフォルトのトランザクション属性としてSupports属性を使用します。
「J2EEアプリケーションクライアント」は、ユーザマシン上で実行され、J2EEサーバにアクセスするJavaベースのクライアントを提供する標準的な方法です。 J2EEアプリケーションクライアントは、 JNDI名前空間アクセス(最小限)を提供するクライアントコンテナによってホストされます。 その他、J2EE仕様では、基本的なものから強力なものまで、幅広いクライアントコンテナの実装が可能です。
アプリケーションサーバでは、サーバに配備されたJ2EEアプリケーションクライアントを呼び出して起動させることのできるSilverJ2EEClientと呼ばれるクライアントコンテナが提供されています。 SilverJ2EEClientには、次のものを含む強力なサポートサービスのセットが提供されています。
アプリケーションでは、WAR (Web applications)のセッションレベルフェイルオーバおよびステートフルセッションBean(EJB JAR)をサポートしています。 「セッションレベルフェイルオーバ」は、クラスタ内でサーバに障害が発生した際にユーザの一時データ(state)を保持する機能のことを指します。 データは、クラスタ内のどこかのサーバで障害が発生した場合に回復できるようにするため、永続的なストレージレポジトリ(クラスタ内のサーバ間で共用しているデータベースやファイルシステムなど)に格納されます。
セッションレベルフェイルオーバをサポートするため、クラスタのディスパッチャとしてハードウェアディスパッチャをインストールしておく必要があります。 セッションレベルフェイルオーバの設定がされているアプリケーションにアクセスするすべてのクライアントは、クラスタの(ハードウェア)ディスパッチャを介してアプリケーションにアクセスする必要があります。
フェイルオーバサポートは、複数のサーバにまたがる1つのセッションに属するEJBの負荷バランスのためのメカニズムではありません。
EJBコンテナは、ステートフルセッションBean(ローカルとリモート)のセッションレベフェイルオーバをサポートします。 ステートフルセッションBeanは、次の要件を満たす必要があります。
セッションBeanは、EJB2.0仕様のインスタンス非活性化および対話型ステートに関する節で説明されているように活性および非活性の両方をサポートする必要があります。
セッションBeanのメソッドはトランザクションである必要があります(配備計画で指定)。 システムクラッシュが発生した場合など、トランザクション外部で発生したセッションBeanステートへの変更は回復不能です。トランザクションのコンテキスト内で発生したセッションBeanステートへの変更は回復できます。
セッションBeanが先にリストされている要件を満たしていて、障害が発生した場合、回復は次のようにして行われます。
1つまたは複数の回復可能なステートフルセッションBeanを含む各トランザクションの最後に、EJBコンテナはトランザクションで使用された回復可能なすべてのBeanを非活性化、シリアル化して、これをデータベースに保存します(SilverMasterデータベースのAgSessBeansテーブル)。
クライアントはリモート呼び出しで通信障害があった場合、サーバに障害があったものと判断します。
トランザクション間で障害が発生した場合は、クライアントは自動的にクラスタ内の他のサーバを選択し、それに対して呼び出しを再試行します(ハードウェアディスパッチャは必要ありません)。 次にセッションBeanのステートは、Beanが前に非活性化されたときと同じようにデータベースから新しいサーバ上に回復されます。
トランザクション処理の実行中に障害が発生した場合は、呼び出しは自動的には再試行されません。 代わりに、トランザクションはロールバックされて、クライアントは例外を受け取ります。 ロールバックされたトランザクションを回復するのはクライアントの責任です(たとえば、クライアントは呼び出しを再試行することができます)。
回復可能なセッションBeanがejbActivate()メソッドで大量の作業をしていた場合には、EJBアプリケーションのパフォーマンスに影響を与える可能性があります。 たとえば、セッションBeanでデータベース接続の割り振りを行い、キャッシュに入れていた場合などです。
セッションレベルフェイルオーバをサポートするためのサーバ設定 IIOP over SSLを使用している場合のセッションレベルフェイルオーバをサポートするには、サーバにIIOP SSL通信用の幅広い範囲のポートを設定する必要があります。
広範なポートの設定の詳細については、『管理者ガイド』の
ORB設定の指定に関する章を参照してください。
WARコンテナでは、セッションレベフェイルオーバをサポートしています。 Webアプリケーションは次の要件を満たす必要があります。
Webアプリケーションが先にリストされている要件を満たしていて、障害が発生した場合、回復は次のようにして行われます。
Webアプリケーションへの各HTTPリクエストに対して、サーバは各リクエストの最後にHTTPSessionステートをデータベース(SilverMasterのAgSessBeansテーブル)にシリアル化します。
コンテナは、各HTTPリクエストの最後にHTTPSessionステートをデータベースに非活性化してシリアル化し、保存するため、これはアプリケーション全体のパフォーマンスに影響を与える可能性があります。
リクエスト間で障害が発生し、ハードウェアディスパッチャが備わっていた場合には、ディスパッチャはサーバの障害を検出して、次のリクエストを別のサーバに送信します。
ハードウェアディスパッチャがない場合 アプリケーションサーバのソフトウェアディスパッチャを使用している場合は(ハードウェアディスパッチャの代わり)、ユーザアプリケーションは障害が発生した後再びディスパッチされるために、手動でディスパッチャまで戻る必要があります。 再びディスパッチされると、セッションIDクッキーが異なるため、新しいサーバによって自動的にステートが復元されることはありません。
フェイルオーバが動作しない場合 HTTPSessionステートはトランザクションではないため、リクエスト中にアップデートされたHTTPSessionの内容は特定の状況下では消失されます。たとえば、リクエスト中にサーバがクラッシュした場合です(ただしリクエスト前の場合は、ステートは保存されます)。 しかし、ステートが保存された後で応答を返す前にサーバがクラッシュした場合、ステートは回復されます。
J2EEクライアントアプリケーションは、先ほど セッションレベルフェイルオーバに対するWebアプリケーションサポートで説明されているとおり、WebコンポーネントとEJBがセッションレベルフェイルオーバの要件を満たしている限り、セッションレベルフェイルオーバをサポートするWebアプリケーションコンポーネントまたはEJBにアクセスすることができます。 J2クライアントは、次のとおりまず初めにクラスタの(ハードウェア)ディスパッチャに接続する必要があります。
SilverJ2EEClient dispatcher-name:port database-name application-name
SilverJ2EEClientの詳細については、
を参照してください。
アプリケーションサーバにはjBroker ORBが含まれています。jBroker ORBは、エンタープライズクラスJavaベースのCORBA ORBです。 アプリケーションサーバ、SilverJ2EEClient、あるいはその他のブラウザからjBroker ORBを使用できます。 jBroker ORBを使用してJavaベースのCORBA ORBアプリケーションの開発、配備、および管理を行うことができます。 アプリケーションサーバでは、次のフィーチャのサブセットを使用します。
jBrokerの詳細については、アプリケーションサーバヘルプの『機能ガイド 』の
jBrokerドキュメンテーションに関する節を参照してください。
XML (eXtensible Markup Language)では、異機種のコンピュータシステム間およびWebのアプリケーション上でデータ交換するために使用できるXMLドキュメントを作成できます。 この節では、XMLドキュメントに対するアプリケーションサーバの使用およびサポートについて説明します。トピックは次のとおりです。
アプリケーションサーバは次のものに対してXMLドキュメントを使用します。
XMLの初心者あるいは特定のXMLトピックについてのみ調べる必要がある場合は、次の学習リソースにアクセスしてみてください。
|
リソース |
説明 |
入手先 |
|---|---|---|
|
Novell exteNd開発者サイト |
多数のドキュメントおよびWebサイトにリンクされているXML習得のためのインデックスおよび参照マニュアル。 |
|
|
XML.orgサイト |
XMLニュースおよび情報についてのディレクトリ |
アプリケーションサーバでの使用が認可されているJDBCドライバはすべて英語/ヨーロッパ言語およびアジアの言語をサポートするため完全にテスト済みです。
JDBC-ODBCブリッジドライバのマルチバイトバージョンを使用する。
アプリケーションサーバには、簡字体および繁体字の中国語、英語、フランス語、ドイツ語、イタリア語、日本語、韓国語、ポルトガル語、ロシア語、そしてスペイン語用のランタイム言語ライブラリが含まれています。
SilverJ2EEClientで文字が正しく表示されないフォントマッピングの問題が発生した場合は、JREのfont.propertiesファイルを編集することによって問題を解決できます。 サーバのインストールディレクトリのjre/libサブディレクトリのfont.properties.XXファイルを編集する必要があります。XXは、使用する言語の2文字の言語エンコードです。たとえば、韓国語の場合はfont.properties.koを編集します。
ファイルの2つのセクション ファイルには前後して2つのセクションが表示されます。 それぞれのセクションには、ラベルname aliasesとラベルfor backwardcompatibilityが付いています。
font.properties.koの元のバージョンは次のとおりです。
# name aliases # # alias.timesroman=serif # alias.helvetica=sansserif # alias.courier=monospaced # for backward compatibility timesroman.0=Times New Roman,ANSI_CHARSET helvetica.0=Arial,ANSI_CHARSET courier.0=Courier New,ANSI_CHARSET zapfdingbats.0=WingDings,SYMBOL_CHARSET
処理方法 name aliasesセクションは、存在しないフォント名をファイルに定義されているフォントマッピングにマップします。 これらのエイリアスの行のコメントを外す必要があります。 (これはマップを処理する方法として推奨されます。 セクションfor backward compatibilityは、存在しないフォント名をファイルで定義されているフォントにマップする古いやり方です。
注記: このセクションの最初の3行のコメントを外す必要があります。
# name aliases # alias.timesroman=serif alias.helvetica=sansserif alias.courier=monospaced # for backward compatibility # timesroman.0=Times New Roman,ANSI_CHARSET # helvetica.0=Arial,ANSI_CHARSET # courier.0=Courier New,ANSI_CHARSET zapfdingbats.0=WingDings,SYMBOL_CHARSET
|
|
機能ガイド 05/21/03 11:36:28 |
Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.