
	機能ガイド 05/21/03 11:36:28

第3章配備計画DTD

この章では、Novell exteNd アプリケーションサーバ配備計画DTDの参照マニュアルについて説明します。トピックは次のとおりです。

はじめにこの章ではXMLについて、基本的な知識が必要です。

配備計画DTDについて

配備計画DTDファイルは、J2EEアーカイブをアプリケーションサーバに配備する際に使用されます。これらのDTD (XML Document Type Definitions)では、特定の種類のアーカイブの配備計画を作成する際に従わなければならない構造について記述します。

DTDおよびサンプルXMLファイルこれらのファイルの名前と場所の要約は次のとおりです。

検索	サーバのインストールで次を参照
配備計画DTDファイル	\resources\DTDCatalogディレクトリ
DTDを使用するサンプル配備計画XMLファイル	\samples\SilverCmdディレクトリ

DTDマニュアル次のものを参照することでDTDについて学ぶことができます。

DTDファイルそのもの -定義した要素についてのコメント
この章 -詳細、ヒント、および要素のサブセットの例

配備計画の編集配備計画を作成し

たり編集したりするには、次のものを使用できます。

exteNd Workbenchの配備計画エディタ
ユーザ自身で選択したXMLエディタまたはテキストエディタ

クライアントJAR配備計画DTD

この節では、アプリケーションサーバのクライアントJAR配備計画DTDに関する参照情報について説明します。

DTDファイルクライアントJAR配備計画DTDはdeploy-car_1_3.dtdです。

選択した要素クライアントJAR配備計画DTDによって定義された要素のサブセットの説明は、次のとおりです(アルファベット順)。

beanLink element
```
  <!ELEMENT beanLink (#PCDATA)>
```
アプリケーションクライアントによって参照されるEJBのJNDI名を指定します。参照されるEJBは、アプリケーションクライアントが配備されているサーバ以外のサーバに配備することができます。

「beanLink用サーバホストの指定」クライアントJAR 自体で配備するかあるいはEAR内に配備するいずれの場合でも、SilverJ2EEClientを呼び出す際に入力するホスト名は、配備計画のbeanLink要素で表示されるホスト名と「完全に一致」していなければならないため、マップするEJB参照に対するアプリケーションサーバホスト名の指定方法については十分に注意する必要があります。
- 「ガイドライン」たとえば、beanLinkのhost nameの部分にmyserverを指定すると、次のようになります。
```
  <beanLink>sssw://myserver/RMI/sbOrderSummary</beanLink>
```
  SilverJ2EEClientコマンド行でもその名前を指定する必要があります。
```
  SilverJ2EEClient myserver snuckerby appclient Sam
```
  または、両方ともそのサーバのIPアドレスを指定できます。あるいは、両方ともlocalhostを指定できます(一般的にはlocalhostを使用しないことをお薦めします)。片方にサーバのポート番号(myserver:80など)を指定した場合は、両方に指定する必要があります。
- 「トラブルシューティング」完全一致しない場合は(片方でサーバのホスト名を指定し、もう片方ではIPアドレスを指定した場合など)、クライアントがEJBにアクセスしようとした際にランタイムエラーが発生します。
```
  java.rmi.RemoteException: Unable to get a valid session for a request
```
- 「EARについて」クライアントJARをEAR内に配備するよう決めた場合にも、この一致要件は適用されます。EAR配備計画で指定するホスト名は、SilverCmd DeployEARコマンド行で指定するホスト名と同じでなければなりません。
clientDataSource要素
```
  <!ELEMENT clientDataSource (jdbcURL?, jdbcDriver?,
     jdbcUsername?,jdbcPassword?)> 
```
アプリケーションクライアントによってアクセスされるa javax.sql.DataSourceへのアクセスについて記述しているコンテナ要素。クライアントはデータソースリソースに直接アクセスするため、クライアントにはアクセスする必要のあるデータソースに対して適切なJDBCDドライバがインストールされている必要があります。これらの値は文字列として渡されます。 jdbcURL、jdbcDriver、jdbcUsername、およびjdbcPasswordの正しい構文については、特定のデータソースについてのマニュアルを参照してください。

mailRefProperties要素

  <!ELEMENT mailRefProperties (el+)>

JavaMail仕様によって定められているとおりに、タイプjavax.mail.Sessionのリソース参照を関連付けるために名前/値の組み合せのセットを指定します。

次に例を示します。

  mail.host
  mail.from
  mail.user
  mail.store.protocol
  mail.transport.protocol
  mail.debug
  mail.[protocol].host (for example, mail.http.host)
  mail.[protocol].user (for example, mail.http.user)

name要素
```
  <!ELEMENT name (#PCDATA)>
```
環境エントリ、リソース参照、あるいはEJB参照の名前を指定します。名前は、配備記述子の中の同一タイプのエントリの名前と一致する必要があります(一致していないと、配備の際に警告メッセージを受け取ります)。
resourceEnvReference
```
  <!ELEMENT resourceEnvReference (name, resourceJNDIName)>
```
リソース環境参照名をJNDI名にマップします。配備記述子内のresource-env-refの各オカレンスは、JNDI名を指定するために配備計画の中に対応するresource EnvReferenceが1つなければなりません。 name要素は、配備記述子内の対応するresource-env-ref-nameと同じでなければなりません。
resourceJNDIName要素
```
  <!ELEMENT resourceJNDIName (#PCDATA)>
```
リソース参照用のJNDI名を指定します。 javax.sql.DataSourceとjava.net.URLのリソース参照を除いて、すべてのリソース参照にはJNDI名が含まれている必要があります。

JNDI名は、アプリケーションクライアントが配備されているサーバ以外のサーバに配備することができます。 resourceJNDINameを検索するには、次の構文を使用します。
```
  <resourceJNDIName>sssw://server:port/RMI/JNDINameOfResource
     </resourceJNDIName>
```
resourceReference要素
```
  <!ELEMENT resourceReference(name,(clientDataSource|resourceURL|resourceJNDIName|mailRefProperties))>
```
リソース参照用のコンテナ要素。リソース参照名(配備記述子にある)と次のいずれか1つを指定する必要があります。
- タイプjavax.sql.DataSourceの参照用の「データソース」
- タイプjava.net.URLの参照用の「URL」
- タイプjavax.jms.QueueConnectionFactoryまたはjavax.jms.TopicConnection Factoryの参照用の「JNDI 名」
- タイプtype javax.mail.Sessionの参照用の「文字列配列」 (名前/値の組み合せの配列として扱われます)
resourceURL要素
```
  <!ELEMENT resourceURL (#PCDATA)>
```
特定のJNDI名に対してランタイム時に検索されるURLを指定します。

EJB JAR配備計画DTD

この節では、EJB JAR配備計画DTDに関する参照情報について説明します。

DTDファイル EJB JAR配備計画はdeploy-ejb_2_0.dtdです。

選択された要素 EJB JAR配備計画DTDによって定義された要素のサブセットの説明は、次のとおりです(アルファベット順)。

alternateColumn要素
```
  <!ELEMENT alternateColumn (#PCDATA)>
```
isolationLevelがTRANSACTION_READ_COMMITTEDの場合、タイプBLOBのデータの処理を管理するためSQLタイプBIGINTを指定して代替カラムを指定します。
autoInc要素
```
  <!ELEMENT autoInc (autoIncSequenceName?, (schemaName?, autoIncTableName, columnName)?)>
```
自動増分がサポートされる列を指定します。
- 自動増分がサポートされているデータベース(ほとんどのデータベース)の場合、空のautoInc要素はすべて自動増分がサポートされる列と見なされます。
- Oracleデータベースの場合は、autoIncSequenceName要素は、使用されるシーケンス名を指定します。
- 自動増分をサポートしていないデータベースの場合は、schemaName要素、autoIncTableName要素、および columnName要素を使用して固有の番号を生成できます。
beanJNDIName要素
```
  <!ELEMENT beanJNDIName (#PCDATA)>
```
EJBのJNDI名を指定します。 JNDI名は、JNDI名前空間内部のBeanを登録するためにコンテナによって使用されます。 Beanを呼び出すすべてのコードは、最初にJNDI名を使用して検索する必要があります。 JNDI名は、サーバ内およびクラス内のサーバの中で一意である必要があります。 Beanの命名をする際には階層構造の使用を検討する必要があります。 EJBが一意であることを保証するために階層内部に会社名(またはイニシャル)を含めたい場合があります。次に例を示します。
```
  abccorp/samples/SalesDemo/Customers
  com/sssw/samples/BankDemo/SessionBeans/AddCustomer
  com/sssw/samples/BankDemo/EntityBeans/Customer
```
これらの例を検索するJNDIは、それぞれ次のとおりです。
```
  contextEnv.lookup(\x93 RMI/abccorp/samples/SalesDemo/Customers\x94 );
  contextEnv.lookup(\x93 RMI/com/sssw/samples/BankDemo/SessionBeans/
     AddCustomer\x94 );
  contextEnv.lookup(\x93 RMI/com/sssw/samples/BankDemo/EntityBeans/
     Customer\x94 );
```
beanLink要素
```
  <!ELEMENT beanLink (#PCDATA)>
```
参照されるEJBのJNDI名を指定します。 EJBは別のサーバに配置することができます。

EJBのJNDI名を指定する例を2つ示します。
- 同一サーバー上
```
  <beanLink>SBBankATM</beanLink>
```
- 別のサーバ上
```
  <beanLink>sssw://myServer:80/RMI/SBBankATM</beanLink>
```
別のサーバに常駐するEJBへのリンクを指定する場合、参照されるBeanのリモートJARを参照元のサーバにコピーする必要があります。
classpathJars要素
```
  <!ELEMENT classpathJars (excludeJ2EEXMLJars?, userlibJars?)>
```
この要素では、JARファイルのリストをサーバに配備しないでアプリケーションで使用することができます。また、この要素によってユーザはCTSテストを渡すために使用されるデフォルトXML JARをインクルードできないようにすることもできます。
columnName要素
```
  <!ELEMENT columnName (#PCDATA)>
```
cmp-field (永続フィールド)をデータベース列にマップします。名前は、JDBCDataMetaData.getColumns()によって戻されるCOLUMN_NAMEプロパティと一致している必要があります。

delayInstantiation要素

  <!ELEMENT delayInstantiation (#PCDATA)>

CMPエンティティBeanは、直ちにインスタンス化される(FALSE - デフォルト)、または必要なときにだけインスタンス化される(TRUE)、のいずれかを指定します。

この要素では、検索メソッド実行中のデータの取り出し方法およびキャッシュへの入れ方を決定します。インスタンス化が遅延されるBeanはレイジーBeanと呼ばれます。

想定されるシナリオの例は次のとおりです。

シナリオ	説明
インスタンス化の遅延はTRUEに設定しますが、検索メソッドはトランザクションコンテキスト(指定されていないコンテキスト)の一部ではありません。	サーバは設定を無視します。検索メソッドを呼び出すと、サーバはプライマリキーを取り出して、データはキャッシュに入れません。 Beanで引き続きこのデータを使用する必要がある場合、サーバはその時点でデータを取り出す必要があります。
インスタンス化の遅延をTRUEに設定し、検索メソッドはトランザクションコンテキストの一部です。	サーバは、それぞれの検索メソッドに対してプライマリキーだけを取り出します。そのBeanに対して引き続きメソッドを呼び出す場合、サーバは再度そのデータベースにアクセスしてデータを取り出し、そのBeanのフィールドを生成します。これによってデータベースへのアクセスは多くなりますが、データベースが大きかったりあるいはアプリケーションで必要なのは1レコードだけの場合にはこの方がより効率的です。アプリケーションではどのレコードが必要であるかを判別するための処理を実行することができます。 1つのBeanにのみアクセスするアプリケーションの場合、すべてのBeanを初期ロードする時間は無駄なことです。
インスタンス化の遅延をFALSEに設定し、検索メソッドはトランザクションコンテキストの一部です。	サーバはプライマリキーを取り出し、さらに各Beanに対してマップされるすべての永続フィールドの値も取り出します。サーバはこのデータをキャッシュに入れます。クライアントで引き続き任意のフィールドに対してメソッドを呼び出す場合、サーバはデータベースから追加データを取り出す必要はありません(すでにすべてのレコードがキャッシュに入っているからです)。データによって、これはパフォーマンスを向上させる場合と低下させる場合があります。 Beanに多くのフィールドがある場合あるいはフィールドに大量のデータが含まれている場合には、パフォーマンスを低下させる可能性があります。たとえば、取り出すBeanにはBLOBフィールドが含まれていて、すべてのレコードにアクセスする必要がない場合には、これはアプリケーションにとって適当な方法ではありません。

シナリオ

説明

インスタンス化の遅延はTRUEに設定しますが、検索メソッドはトランザクションコンテキスト(指定されていないコンテキスト)の一部ではありません。

サーバは設定を無視します。

検索メソッドを呼び出すと、サーバはプライマリキーを取り出して、データはキャッシュに入れません。 Beanで引き続きこのデータを使用する必要がある場合、サーバはその時点でデータを取り出す必要があります。

インスタンス化の遅延をTRUEに設定し、検索メソッドはトランザクションコンテキストの一部です。

サーバは、それぞれの検索メソッドに対してプライマリキーだけを取り出します。

そのBeanに対して引き続きメソッドを呼び出す場合、サーバは再度そのデータベースにアクセスしてデータを取り出し、そのBeanのフィールドを生成します。

これによってデータベースへのアクセスは多くなりますが、データベースが大きかったりあるいはアプリケーションで必要なのは1レコードだけの場合にはこの方がより効率的です。アプリケーションではどのレコードが必要であるかを判別するための処理を実行することができます。

1つのBeanにのみアクセスするアプリケーションの場合、すべてのBeanを初期ロードする時間は無駄なことです。

インスタンス化の遅延をFALSEに設定し、検索メソッドはトランザクションコンテキストの一部です。

サーバはプライマリキーを取り出し、さらに各Beanに対してマップされるすべての永続フィールドの値も取り出します。サーバはこのデータをキャッシュに入れます。

クライアントで引き続き任意のフィールドに対してメソッドを呼び出す場合、サーバはデータベースから追加データを取り出す必要はありません(すでにすべてのレコードがキャッシュに入っているからです)。

データによって、これはパフォーマンスを向上させる場合と低下させる場合があります。 Beanに多くのフィールドがある場合あるいはフィールドに大量のデータが含まれている場合には、パフォーマンスを低下させる可能性があります。たとえば、取り出すBeanにはBLOBフィールドが含まれていて、すべてのレコードにアクセスする必要がない場合には、これはアプリケーションにとって適当な方法ではありません。

deployedObject要素
```
  <!ELEMENT deployedObject (#PCDATA)>
```
アプリケーションサーバ上に作成するEJB配備されたオブジェクトの名前を指定します。これはオプションで、コマンド行でも指定できます(SilverCmd DeployEJBを使用して配備する場合)。

この要素が指定されていないと、配備ではejbJarName要素の値にDeployedという用語を追加した名前を生成します。
destinationName要素
```
  <!ELEMENT destinationName (#PCDATA)>
```
QueueまたはTopic Nameを指定します。次のように指定する必要があります。
```
  corbaname:iiop:JMSServer:3506#queue/queueName
```
CMPフィールドをデータベース列にマップすることを指定します。

mailRefProperties要素

  <!ELEMENT mailRefProperties (el+)>

JavaMail仕様によって定められているとおりに、タイプjavax.mail.Sessionのリソース参照を関連付けるために名前/値の組み合せのセットを指定します。

次に例を示します。

  mail.host
  mail.from
  mail.user
  mail.store.protocol
  mail.transport.protocol
  mail.debug
  mail.[protocol].host (for example, mail.http.host)
  mail.[protocol].user (for example, mail.http.user)

relationRole要素
```
  <!ELEMENT relationRole (beanName, cmrFieldName?, columnNames?)>
```
リレーション内部のロールを定義し、次のものが含まれます。
- 関係に参加するロールのソースの「Bean名」(配備記述子で指定されている)。これは、ejb-relationship-rolesノードのrelationship-role-source要素と一致する必要があります。
- ロールの「CMRフィールド名」(配備記述子で指定されている)。これはcmr-field-nameと一致する必要があります(この要素が存在するはずのないcmr-field-nameがない場合)。配備の際にはbeanNameとcmrFieldNameを使用して関係を一致させます。
- 関係を管理するためにコンテナで使用する「列名のリスト」(ほとんどの場合1つの要素しか含まれていません)。これらは、通常外部キーとなります。多対多の関係では、これらはBeanのプライマリキーと対応するリンクテーブルの外部キーの列名です。
resourceEnvReference要素
```
  <!ELEMENT resourceEnvReference (name, resourceJNDIName)>
```
リソース環境参照名をJNDI名にマップすることを指定します。配備記述子内のresource-env-refの各オカレンスは、JNDI名を指定するために配備計画の中に対応するresourceEnvReferenceが1つなければなりません。 name要素は、配備記述子内の対応するresource-env-ref-nameと同じでなければなりません。

WAR配備計画DTD

この節では、WAR配備計画DTDに関する参照情報について説明します。

DTDファイル WAR配備計画DTDはdeploy-war_2_3.dtdです。

選択した要素 WAR配備計画DTDによって定義された要素のサブセットの説明は、次のとおりです(アルファベット順)。

beanLink要素
```
  <!ELEMENT beanLink (#PCDATA)>
```
参照されるEJBへのリンクを指定します。これは、EJBが同一JARにある場合は内部名、または別のJARにある場合はJNDI名となります。 EJBは別のサーバに配置することができます。

EJBのJNDI名を指定する例を2つ示します。
- 同一サーバ上
```
  <beanLink>SBBankATM</beanLink>
```
- 別のサーバ上
```
  <beanLink>sssw://myServer:80/RMI/SBBankATM</beanLink>
```
classpathJars要素
```
  <!ELEMENT classpathJars (excludeJ2EEXMLJars?, userlibJars?)>
```
この要素では、JARファイルのリストをサーバに配備しないでアプリケーションで使用することができます。また、この要素によってユーザはCTSテストを渡すために使用されるデフォルトXML JARをインクルードできないようにすることもできます。
deployedObject要素
```
  <!ELEMENT deployedObject (#PCDATA)>
```
アプリケーションサーバ上に作成する配備済みオブジェクトの名前を指定します。この要素が指定されていないと、配備ではwarJarName要素の値にDeployedという用語を追加した名前を生成します。
deployToFilesystem要素
```
  <!ELEMENT deployToFilesystem (#PCDATA)>
```
アプリケーションをアプリケーションサーバ上のファイルシステムに配備するかどうかを指定します。デフォルトはFALSE(ファイルシステムの配備なし)です。
excludedJSPs要素
```
  <!ELEMENT excludedJSPs (el+)>
```
コンパイルしてはならないJSPリソースのリスト。 (通常、他のJSPページにインクルードされることとなっているJSPページはそれ自身でコンパイルしてはなりません。)

mailRefProperties要素

  <!ELEMENT mailRefProperties (el+)>

JavaMail仕様によって定められているとおりに、タイプjavax.mail.Sessionのリソース参照を関連付けるために名前/値の組み合せのセットを指定します。

次に例を示します。

  mail.host
  mail.from
  mail.user
  mail.store.protocol
  mail.transport.protocol
  mail.debug
  mail.[protocol].host (for example, mail.http.host)
  mail.[protocol].user (for example, mail.http.user)

name要素
```
  <!ELEMENT name (#PCDATA)>
```
環境エントリ、リソース参照、EJB参照、ロールマッピング、あるいはコンテキストパラメータエントリの名前を指定します。名前は、配備記述子の中の同一タイプのエントリの名前と一致する必要があります(一致していないと、配備の際に警告メッセージを受け取ります)。
resourceJNDIName要素
```
  <!ELEMENT resourceJNDIName (#PCDATA)>
```
リソース参照用のJNDI名を指定します。 javax.sql.DataSourceあるいはjava.net.URLのリソース参照を除いて、すべてのリソース参照にはJNDI名が含まれている必要があります。

JNDI名は、WARを含むサーバ以外のサーバに配備することができます。別のサーバにアクセスする際にも、この構文を使用します。
```
  <resourceJNDIName>sssw://server:port/RMI/JNDINameOfResource
     </resourceJNDIName>
```
resourceReference要素
```
  <!ELEMENT resourceReference (name, (dataSource | resourceURL |
     resourceJNDIName | mailRefProperties))>
```
リソース参照用のコンテナ要素。リソース参照名(配備記述子にある)と次のいずれか1つを指定する必要があります。
- タイプjavax.sql.DataSourceの参照用の「データソース」
- タイプjava.net.URLの参照用の「URL」
- タイプjavax.jms.QueueConnectionFactoryまたはjavax.jms.TopicConnection Factoryの参照用の「JNDI 名」
- タイプtype javax.mail.Sessionの参照用の「文字列配列」 (名前/値の組み合せの配列として扱われる)
sessionTimeout要素
```
  <!ELEMENT sessionTimeout (#PCDATA)>
```
セッションタイムアウトを分単位で設定します。セッションタイムアウトの階層を、優先度の高いものから低いものに順に示します。
- タイムアウトは、HttpSession.setMaxInactiveInterval()を使用してプログラムで指定します(分単位)。
- 配備計画(分単位)。
- 配備記述子(分単位)。
- サーバのデフォルトセッションタイムアウト

RAR配備計画DTD

この節では、RAR(resource adapter archive)配備計画DTDに関する参照情報について説明します。

DTDファイル RAR配備計画DTDはdeploy-rar_1_0.dtdです。

選択された要素 RAR配備計画DTDによって定義された要素のサブセットの説明は、次のとおりです(アルファベット順)。

idleTimeout
```
  <!ELEMENT idleTimeout (#PCDATA)>
```
プール内で未使用の接続がサーバによって切断されるまでの時間を秒数で指定します。デフォルトは60秒です。指定する値は、接続プールを使用しているアプリケーションのタイプによって異なります。タイムアウトの時間を短く設定すると、サーバは頻繁に接続を作成しなければならないこととなります。接続を作成することは負荷の高い操作です。しかしタイムアウトの時間を非常に長く設定すると、他のアプリケーションは接続が使用可能になるまで待たされてしまう可能性があります。
isEnabled
```
  <!ELEMENT isEnabled (#PCDATA)>
```
RARを有効にする(デフォルト)かどうかを指定します。このフラグをFALSEに設定してRARを再配備すると、配備済みのRARは「無効」となります。
name
```
  <!ELEMENT name (#PCDATA)>
```
ManagedConnectionFactoryの名前を指定します。
password
```
  <!ELEMENT password (#PCDATA)>
```
プールで作成されたデフォルト接続のパスワードを指定します。デフォルト接続は、ユーザがConnectionFactory.getConnection()を呼び出した際に作成されます。これは、サーバで効率的に接続をプールできるため、接続を取得するために適した方法です。
poolName
```
  <!ELEMENT poolName (#PCDATA)>
```
サーバに追加された接続プールの名前を指定します。接続プールを管理する際にはこの名前を使用します。
resourceAdapterName
```
  <!ELEMENT resourceAdapterName (#PCDATA)>
```
アプリケーションサーバでリソースアダプタが配備される先の名前を指定します。これは論理名です。
user
```
  <!ELEMENT user (#PCDATA)>
```
プールで作成されたデフォルト接続のユーザ名を指定します。デフォルト接続は、ユーザがConnectionFactory.getConnection()を呼び出した際に作成されます。これは、サーバで効率的に接続をプールできるため、接続を取得するために適した方法です。

EAR配備計画DTD

この節では、EAR配備計画DTDに関する参照情報について説明します。

DTDファイル EAR配備計画DTDはdeploy-ear_1_3.dtdです。

選択した要素要素のサブセットの説明は、次のとおりです(アルファベット順)。

alternateDeplDesc要素
```
  <!ELEMENT alternateDeplDesc (#PCDATA)>
```
指定されたモジュールで使用するための配備記述子を識別します。この要素は指定されたモジュールのアーカイブの配備記述子を使用したくない場合に使用します。指定する代替配備記述子はEARの中にある必要があります。

この要素を使用したい場合の2つのシナリオは、次のとおりです。
- 同一モジュールを2度使用したいが、2つの使用を別々に設定したい場合。
- EAR内にはモジュールの2つのインスタンスがあり(2つのEJB JARなど)、2つのモジュールを別々に設定したい場合。
classpathJars要素
```
  <!ELEMENT classpathJars (excludeJ2EEXMLJars?, userlibJars?)>
```
この要素では、JARファイルのリストをサーバに配備しないでアプリケーションで使用することができます。また、この要素によってユーザはCTSテストを渡すために使用されるデフォルトXML JARをインクルードできないようにすることもできます。
deployAs要素
```
  <!ELEMENT deployAs (#PCDATA)>
```
モジュールが通常配備される先の名前を上書きします。デフォルトにより、EAR配備のプロセスではEAR名とモジュール名を組み合せた配備名を作成します。 EJBモジュールでは、この名前(指定されている場合)はリモートJARのベース名としても使用されます。使用時には注意が必要です。
earJarName要素
```
  <!ELEMENT earJarName (#PCDATA)>
```
配備するEARの名前を指定します。これは配備計画の中であるいはコマンド行で指定できます(SilverCmd DeployEARを使用して配備する場合)。コマンドラインで指定された値が優先されます。フルパス(EARがディスク上にある場合)または名前だけで指定できます。名前だけを指定してEARが現在のディレクトリにない場合、EARは配備されている同じデータベースおよび同じサーバ内にすでに存在するものと見なされます。
module要素
```
  <!ELEMENT module (ejbJar | warJar | carJar)>
```
EAR内の特定のJ2EEモジュールについて記述します。

この要素に含まれている情報は、特定のモジュールの配備計画です。このセクションを完了するためにアプリケーションクライアントJAR、EJB JAR、あるいはWARから配備計画を切り取り、貼り付けます。

EJBの場合、Bean要素のbeanNameコンポーネントはEAR内で一意である必要があります。そうでないと、EARを配備する際にエラーを受け取ります(Bean名はEAR内部のBean参照を解決するために使用されるためです)。
name要素
```
  <!ELEMENT name (#PCDATA)>
```
ユーザ名またはグループ名にマップされる必要のあるロール参照の名前を指定します。名前は、配備記述子の中のロール参照エントリの名前と一致する必要があります(一致していないと、配備の際に警告メッセージが生成されます)。
order要素
```
  <!ELEMENT order (#PCDATA)>
```
モジュールの配備の順序を識別します。数字が小さいほど配備の優先順位は高くなります。 order要素が指定されていないモジュールは指定されているモジュールの後に配備されます。
roleMap要素
```
  <!ELEMENT roleMap (roleMapping+)>
```
EARレベルのロープマップに対するコンテナ

セキュリティロールは、個別モジュール(EJB JAR、WAR、その他)のレベルではなくEARレベルでマップすることを検討してください。これによって、J2EEモジュール構成のセキュリティ設定を組み合せたり簡易化したりできます。

基本的な規則は次のとおりです。
- 個別モジュールにロールマップが含まれていない場合、EARレベルのロールマップが使用されます。
- 一部または全ての個別モジュールとEARの両方にロールマップが含まれていて、
  
  「ロールマップが一意の場合」各モジュールで使用されるロールマップは、EARレベルのロールマップとモジュールの単位となります。
  
  「1つまたは複数のロールマップが一致でない場合」モジュールレベルのロールマップは重複したロールに優先され、一意のロールはロールマップに追加されます。
ロールが一意でない場合にロールマップが決定される方法の例は次のとおりです。 EARレベルのロールマップに次の値が含まれている場合、次のとおりです。

このロールは

このuserOrGroupNameにマップされます。

EJBAdmin

Zack

User

Mary

EAR内のEJBモジュールにこのロールマップが含まれている場合は、次のとおりです。

このロールは

このuserOrGroupNameにマップされます。

Admin

Joe

User

Helen

EJBで使用されるロールマップは次のようになります。

このロールは

このuserOrGroupNameにマップされます。

Admin

Joe

User

Helen

EJBAdmin

Zack

この場合、EJBモジュールのUserロールが優先されます。 Adminロールは、EARのロールマップから継承されるため、EJBのロールマッピングに追加されます。
userOrGroupName要素
```
  <!ELEMENT userOrGroupName (#PCDATA)>
```
セキュリティポリシードメイン内のプリンシパルの名前または運用環境のユーザグループの名前を指定します。これは、配備記述子からロール参照名にマップされます。アプリケーションサーバでサポートされている任意のセキュリティドメインにロール参照をマップできます。
userlibJars要素
```
  <!ELEMENT userlibJars (el+)>
```
アプリケーションで使用可能となっていなければならない追加のJARファイルをすべてリストします。 JARはサーバのuserlibディレクトリに常駐する必要があります。値はJAR名のStringArrayで、userlibディレクトリに相対して(その中に含まれて)います。

このロールは	このuserOrGroupNameにマップされます。
EJBAdmin	Zack
User	Mary

このロールは	このuserOrGroupNameにマップされます。
Admin	Joe
User	Helen

このロールは	このuserOrGroupNameにマップされます。
Admin	Joe
User	Helen
EJBAdmin	Zack


	機能ガイド 05/21/03 11:36:28

第3章 配備計画DTD

配備計画DTDについて

クライアントJAR配備計画DTD

EJB JAR配備計画DTD

WAR配備計画DTD

RAR配備計画DTD

EAR配備計画DTD

第3章配備計画DTD