第6章
この章では、Novell exteNd Application Serverに関する実装の詳細をいくつか説明します。トピックは次のとおりです。
J2EEコンポーネントモデルの中心となるのがコンテナです。コンテナは、Novell exteNd Application ServerなどのJ2EEプラットフォームプロバイダによって提供されるランタイム環境です。コンテナはライフサイクル管理およびその他のサービスを提供し、アプリケーション開発者がアプリケーションのプレゼンテーションとビジネス論理に集中できるようにします。
アプリケーションサーバは、次の3種類の各J2EEコンテナを実装します。
Webコンテナには、WAR(Web Archive)ファイルにパッケージ化された「Webアプリケーション」が含まれています。アプリケーションサーバに展開する各WARは、完全なスタンドアロンアプリケーションとして機能します。WARファイルには、アプリケーションで使用するすべてのJSPページ、サーブレット、JavaBeansコンポーネント、ユーティリティクラス、スタティックHTMLページ、およびサウンドが含まれている必要があります。
JSPページおよびサーブレット WARをサーブレットに展開した後は、WAR内の各JSPページはサーブレットのように動作します。ページはURLと関連付けられています。WebクライアントまたはサーバサイドオブジェクトがそのURLに対する操作を実行すると、サーバは関連付けられたサーブレットを検索してインスタンスを生成し、サーブレットに関連付けられているinit()およびservice()メソッドをコールします。サーブレットがアンロードされるときは、サーバはdestroy()メソッドをコールします。
WAR内のJSPページ(またはサーブレット)のサーブレットコンテキストは、WAR自身です。つまり、WARでアプリケーションの境界を定義しているため、JSPページまたはサーブレットを、別のWARに存在するJSPページまたはサーブレットに転送する(または含める)ことはできません。
永続性 アプリケーションサーバ上で実行されるJSPページは、永続的ではありません。JSPページの新規のインスタンスは、HTTP要求ごとに作成される場合があります(展開記述子でJSPページがスレッドセーフとして定義されているかどうかによります)。
応答 アプリケーションサーバは、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です。
同じWAR内に存在する任意の他のJSPページまたはサーブレットに、JSPページまたはサーブレットを転送する(あるいは含める)ことができます。
<jsp:forward>アクションまたは<jsp:include>アクションを使用する場合、ターゲットURLは、コンテキスト相対あるいはページ相対にすることができます。コンテキスト相対URLはスラッシュ(/)で始まり、WARに対して相対的であると解釈されます。ページ相対URLはスラッシュ(/)で始まらず、現在のページに対して相対的であると解釈されます。
JSPページに対する完全なURLがhttp://localhost/myDatabase/jsptests/myjsps/test.jspで、展開時にWARに指定したURLがjsptestsであるとします。この場合、同じWAR内のJSPページに次のタグを埋め込んで、ページに要求を送信することができます。
<jsp:forward page="/myjsps/test.jsp"/>
サーブレットでは、ServletContextオブジェクトのgetRequestDispatcher()メソッドを使用してターゲットURLを指定すると、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()メソッドコールは、暗黙の「要求」および「応答」オブジェクトを引数として渡します。
アプリケーションサーバは、クッキーまたはURLリライトを使用してセッションを追跡できます。ブラウザでクッキーがサポートされている場合はクッキーを使用し、サポートされていない場合はURLリライトを使用します。
詳細については、『管理者用ガイド』のサーバ設定に関する章の節を参照してください。
EJBコンテナは、EJB2.0 およびEJB 1.1Bean用のランタイム環境を提供します。ランタイム環境には、ネーミング、リモートアクセス、セキュリティ、およびトランザクションサポートなどの低レベルのサービスが含まれます。
この節では、EJBコンテナの機能について説明します。トピックは次のとおりです。
EJBコンテナでサポートされているEJBは、次のとおりです。
「メッセージ駆動型Bean」 - メッセージ駆動型Beanを使用すると、JMSメッセージサーバによって管理されているキューまたはトピックからメッセージにアクセスできます。
「エンティティBean」 - BMP(Bean管理)エンティティBeanとCMP(コンテナ管理)エンティティBeanの両方をサポートします。次のエンティティBean機能がサポートされています。
この節では、アプリケーションサーバを展開する際に提供されるサービスについて説明します。
EJBコンテナでは、「展開時」と「ランタイム時」の両方でデバッグサポートが提供されています。
展開デバッグのサポート 展開デバッグのサポートは、コマンドラインツールSilverCmdによって提供されます。次の表は、デバッグに役に立つコマンドについて説明しています。
ランタイムデバッグのサポート ランタイムデバッグのサポートは、サーバの起動スイッチまたはサーバコンソールのコマンドシェルによって提供されます。次の表は、スイッチとその使用方法について説明しています。
EJBコンテナは、エンティティ、ステートレスセッション、およびメッセージ駆動型Beanのインスタンスプールをサポートします。プールはBeanごとにあり、展開計画の中で指定されます。プールサイズを再設定するには、更新された展開計画を使用してBeanを再展開します。
エンティティBeanとセッションBeanに対しては、次の方法で値を指定します。
|
展開計画の項目 |
手順 |
|---|---|
|
initialPoolSize |
プールを事前に割り当てるには、この値をゼロより大きい数字に設定します。 |
|
maxPoolSize |
プール内にある未使用のインスタンスの最大数を指定します。 デフォルトは次のとおりです。 |
|
poolingPolicy |
最大プールサイズに達した場合の処理を定義します。 指定できる値はCREATEとFAILです(次を参照)。 |
エンティティBeanおよびステートレスセッションBeanのプールポリシー Beanを展開する際に、EJBコンテナはインスタンスプールを作成しません。代わりに、インスタンスの必要性が増加したときにプールを作成します。
「メッセージ駆動型Bean」に対しては、コンテナはServerSessionPoolインタフェースを実装することによってインスタンスプールを提供します。
ステートフルセッションBeanの非活性化 アプリケーションサーバは、GC(ガベージコレクション)レートを計測することによって、メモリの使用状況を監視します。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仕様の推奨事項に従ってオブジェクトを別々のサブコンテキストに格納できますが、こられの命名規則はアプリケーションサーバでは適用されません。つまり、ユーザ独自の運用環境に最適な命名規則を使用できます。
アプリケーションサーバは、Novell exteNd ORB (Object Request Broker)を使用したRMI/IIOP経由でのEJBへのアクセスをサポートしています。exteNd ORBはエンタープライズクラスのJavaベースのCORBA ORBで、Novell exteNd メッセージングプラットフォームの一部です。
exteNd ORBの詳細については、Novell exteNd メッセージングプラットフォームヘルプを参照してください。
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のディスク上の場所をクライアントのクラスパスに指定します。EJBを変更して再展開するたびに、必ず新しいバージョンのEJBクライアントJARをダウンロードしてください。
ローカルBeanの使用状況を確認するには、次を使用します。
EJBLocalHome/beanName
EJBコンテナは、次のものを使用してランタイム時にセキュリティを管理します。
EJBをコールすると、サーバはユーザを認証し、そのサーバ上でコール側のセッションが有効な間は、コール側IDを使用します。すべてのメソッドコールは、そのセッションのIDを使用して実行されます。展開計画で役割名をプリンシパル(ユーザ、グループ、あるいはプリンシパルのリスト)にマップできます。
アクセス権限は、展開記述子で指定されているsecurity-role要素およびmethod-permission要素によって定義されます。EJB JARに含まれるBeanの少なくとも1つのメソッドを保護する場合は、すべてのメソッドを保護する必要があります。そうしないと、コンテナは、セキュリティが指定されていないメソッドはすべて制限されていて、どのユーザもコールできないと想定します。また、展開記述子でexclude-list要素を使用して、コールできないメソッドのセットを指定することもできます。制限されたメソッドがコールされると、コンテナはAccessRightsViolation例外をスローします。または、どのメソッドも保護しないことで、安全でないモードを選択することもできます。
SSLを使用してEJBクライアントとアプリケーションサーバの間に安全な通信を確立できます。Novell exteNd ORBは、RSAに対してのみIIOP over SSLのサポートを提供します。
HTTPSが実行されている必要はありません。必要条件は次のとおりです。
安全なEJBへのアクセスのサポートで説明されているように、クライアントにagrootca.jarも必要です。
EJBクライアントとアプリケーションサーバの間に安全な通信を確立する場合の詳細については、『管理者用ガイド』のセキュリティのセットアップに関する章を参照してください。
EJBコンテナは、JTS (Java Transaction Service)を完全に実装しているNovell exteNd JTSサーバを介して、分散トランザクションをサポートします。
展開記述子でトランザクション属性が指定されていない場合、コンテナはデフォルトのトランザクション属性としてSupports属性を使用します。
「J2EEアプリケーションクライアント」は、ユーザコンピュータ上で動作してJ2EEサーバにアクセスするJavaベースのクライアントを提供するための標準的な方法です。J2EEアプリケーションクライアントは、少なくともJNDIネームスペースアクセスを提供するクライアントコンテナによってホストされます。その他にも、J2EE仕様では、基本的なものから強力なものまで、幅広いクライアントコンテナの実装が可能です。
アプリケーションサーバでは、サーバに展開されたJ2EEアプリケーションクライアントを実行するためにユーザが呼び出すことができるSilverJ2EEClientというクライアントコンテナが提供されています。SilverJ2EEClientには、次のものを含む強力なサポートサービスのセットが提供されています。
アプリケーションは、Webアプリケーション(WAR)およびステートフルセッションBean(EJB JAR)のセッションレベルフェールオーバーをサポートしています。「セッションレベルフェールオーバー」とは、クラスタ内のサーバに障害が発生した際に、アプリケーションが一時的なユーザデータ(ステート)を保持する機能のことを指します。データは、永続的なストレージレポジトリ(クラスタ内のサーバによって共有されているデータベースやファイルシステムなど)に保存されるため、サーバ障害が発生した場合は、クラスタ内の任意のサーバで回復できます。
セッションレベルフェールオーバーをサポートするには、クラスタのディスパッチャとしてハードウェアディスパッチャをインストールしておく必要があります。セッションレベルフェールオーバー用に設定されているアプリケーションにアクセスするすべてのクライアントは、クラスタの(ハードウェア)ディスパッチャを介してアプリケーションにアクセスする必要があります。
フェールオーバーサポートは、単一のセッションに属するEJBを複数のサーバに負荷分散するためのメカニズムではありません。
EJBコンテナは、ステートフルセッションBean(ローカルおよびリモート)のセッションレベフェールオーバーをサポートします。ステートフルセッションBeanは、次の要件を満たす必要があります。
セッションBeanは、EJB2.0仕様のインスタンスの非活性化と対話処理ステートに関する節で説明されているように、活性および非活性をサポートする必要があります。
セッションBeanのメソッドはトランザクションである必要があります(展開記述子で指定)。システムがクラッシュした場合、トランザクション外部で行われたセッションBeanステートへの変更は回復不可能です。トランザクションのコンテキスト内で行われたセッションBeanステートへの変更は回復可能です。
先にリストされている要件をセッションBeanが満たしていて、障害が発生した場合、回復は次のように行われます。
回復可能な1つまたは複数のステートフルセッションBeanが含まれる各トランザクションの最後に、EJBコンテナは、トランザクションで使用された回復可能なBeanをすべて非活性化およびシリアル化して、データベース(SilverMasterデータベースのAgSessBeansテーブル)に保存します。
回復可能なセッションBeanがejbActivate()メソッドで大量の処理を実行していた場合は、EJBアプリケーションのパフォーマンスに影響を及ぼすことがあります。たとえば、セッションBeanがデータベース接続を割り当ててキャッシュする場合などです。
IIOP over SSLを使用している場合にセッションレベルフェールオーバーをサポートするには、IIOP SSL通信に使用する一定範囲のポートをサーバに設定する必要があります。
広範なポートの設定の詳細については、『管理者用ガイド』のORB設定の指定に関する章を参照してください。
WARコンテナは、セッションレベフェールオーバーをサポートしています。Webアプリケーションは次の要件を満たす必要があります。
先にリストされている要件をWebアプリケーションが満たしていて、障害が発生した場合、回復は次のように行われます。
Webアプリケーションへの各HTTP要求に対して、サーバは、各要求の最後にHTTPSessionステートをデータベース(SilverMasterのAgSessBeansテーブル)にシリアル化します。
コンテナは、各HTTP要求の最後にHTTPSessionステートを非活性化してシリアル化し、データベースに保存するため、アプリケーションの全体的なパフォーマンスに影響を及ぼす可能性があります。
要求間で障害が発生し、ハードウェアディスパッチャが使用されている場合、ディスパッチャはサーバ障害を検出して、次の要求を別のサーバに送信します。
ハードウェアディスパッチャの代わりにアプリケーションサーバのソフトウェアディスパッチャを使用している場合、ユーザアプリケーションは、障害後に手動でディスパッチャに戻り、再ディスパッチされる必要があります。再ディスパッチされた場合、セッションIDクッキーが異なるため、新しいサーバによって自動的にステートが復元されることはありません。
HTTPSessionステートはトランザクションではないため、特定の状況では、要求中に行われたHTTPSessionへの更新は失われます。たとえば、要求の処理中に要求が保存される前にサーバがクラッシュした場合などです。ただし、ステートが保存された後で応答を返す前にサーバがクラッシュした場合は、ステートを回復できます。
前のセッションレベルフェールオーバーに対するWebアプリケーションサポートで説明されているように、J2EEクライアントアプリケーションは、WebコンポーネントとEJBがセッションレベルフェールオーバーの要件を満たしている限り、セッションレベルフェールオーバーをサポートするWebアプリケーションコンポーネントまたはEJBにアクセスすることができます。次のように、J2EEクライアントは、まずクラスタの(ハードウェア)ディスパッチャに接続する必要があります。
SilverJ2EEClient dispatcher-name:port database-name application-name
SilverJ2EEClientの詳細については、を参照してください。
アプリケーションサーバにはNovell exteNd ORBが含まれています。exteNd ORBは、エンタープライズクラスのJavaベースのCORBA ORBです。exteNd ORBは、アプリケーションサーバ、SilverJ2EEClient、または任意のブラウザから使用できます。exteNd ORBを使用して、JavaベースのCORBAアプリケーションの開発、展開、および管理を行うことができます。アプリケーションサーバは、次の機能のサブセットを使用します。
exteNd ORBの詳細については、Novell exteNdメッセージングプラットフォームヘルプを参照してください。
XML (eXtensible Markup Language)を使用することで、異なるタイプのコンピュータシステムや、Web上でアプリケーション間でデータを交換するために使用できるXMLドキュメントを作成できます。この節では、アプリケーションサーバでのXMLドキュメントの使用およびサポートについて説明します。トピックは次のとおりです。
アプリケーションサーバは次のものに対してXMLドキュメントを使用します。
詳細については、次の章を参照してください。
XMLの初心者の場合、または特定のXMLトピックについてのみ調べる必要がある場合は、次の学習リソースにアクセスしてみてください。
|
リソース |
説明 |
場所 |
|---|---|---|
|
Novell exteNd 開発者サイト |
多くのドキュメントやWebサイトへのリンクを含む、XML習得のためのインデックスおよび参考資料 |
|
|
XML.orgサイト |
XMLに関するニュースや情報についてのディレクトリ |
この節では、次の各国対応トピックについて説明します。
アプリケーションサーバでの使用が認定されているすべてのJDBCドライバは、西ヨーロッパ/東ヨーロッパ言語およびアジアの言語をサポートするように完全にテストされています。
JDBC-ODBCブリッジドライバのマルチバイトバージョンを使用する
アプリケーションサーバには、簡字体中国語、繁体字中国語、英語、フランス語、ドイツ語、イタリア語、日本語、韓国語、ポルトガル語、ロシア語、およびスペイン語用のランタイム言語ライブラリが含まれています。
SilverJ2EEClientでフォントマッピングの問題が発生し、文字が正しく表示されない場合は、JREのfont.propertiesファイルを編集することによって問題を解決できます。Novell exteNd Common\\jre\\libディレクトリにあるfont.properties.XXファイルを編集する必要があります(XXは、使用する言語の2文字の言語エンコードです)。たとえば、韓国語の場合は、font.properties.koを編集します。
ファイルの2つのセクション このファイルには、前後して2つのセクションが記述されています。各セクションには、name aliasesおよびfor backward compatibilityというラベルが付いています。
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
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...