第2章

J2EEアーカイブ展開

この章では、J2EE互換アーカイブファイルをNovell exteNd Application Serverに展開するための要件について説明します。この章のトピックは次のとおりです。

exteNd Directorの使用この章では、アプリケーションサーバ展開ツールを使用した展開について説明します。Novell exteNd Directorを使用した開発、パッケージ化、および展開の詳細については、exteNd Directorヘルプを参照してください。

アーカイブの展開

J2EEアーカイブをアプリケーションサーバに展開するには、次の操作を実行します。

手順	アクション	アーカイブタイプ	参照先
1	アプリケーションをアーカイブファイルにパッケージ化する	クライアントアプリケーション、EJB、EAR、およびWAR	Sunでは、各アプリケーションタイプに対して要件を設定しています。J2EEアプリケーションの作成およびパッケージ化についての詳細は、Sun Java Webサイトで公開されている仕様を参照してください。 http://java.sun.com/j2ee/docs.html
1	アプリケーションをアーカイブファイルにパッケージ化する	RAR	RARの作成およびパッケージ化についての詳細は、Sun Java Webサイトで入手可能なJ2EEコネクタアーキテクチャ仕様を参照してください。 http://jcp.org/jsr/detail/016.jsp
2	展開計画を作成する	クライアントアプリケーション	クライアントJAR展開計画DTDを参照してください。注記: 展開計画は、アプリケーションでEJB、環境エントリ、またはその他の外部リソース(データベースなど)を参照する場合にのみ必要です。アプリケーションに外部参照が含まれない場合、展開計画は必要ありません。
		EJB	を参照してください。
		EAR
		RAR
		WAR
3	アーカイブを展開する	クライアントアプリケーション	DeployCARを参照してください。
		EJB	DeployEJBを参照してください。
		EAR	DeployEARを参照してください。
		RAR	DeployRARを参照してください。
		WAR	DeployWARを参照してください。

EJB展開のヒント

この節では、特にEJBアーカイブの展開に関連する次の機能について説明します。

Updating EJB 1.1 Finderメソッドの更新

既存のEJB 1.1 Beanがある場合、正しいDTDを使用するために展開計画を更新する必要があります。EJB展開計画の詳細については、EJB JAR展開計画DTDを参照してください。

Novell exteNd Director展開計画エディタを使用して、展開計画を変換できます。展開計画エディタ使用して展開計画を変換する方法の詳細については、exteNd Directorヘルプを参照してください。

exteNd Directorを使用してCMPエンティティBeanの展開計画を更新する場合、Finderメソッドの定義はwhereClause要素からsqlWhereClause要素に変換されます。

展開計画エディタは、EJB 1.1 Finderメソッドを、SQLステートメントのWHERE句と入力パラメータを含む簡単な式に変換します。Finderの最初の入力パラメータは?1に、2番目は?2にというように変換されます。

例は次のとおりです。

  <sqlWhereClause>
     WHERE COL1=?1
  </sqlWhereClause>

sqlWhereClause要素でWHEREを指定しないと、コンテナはユーザに代わって前にWHERE句を付けます。したがって、

  <sqlWhereClause>
     WHERE PRICE>1
  </sqlWhereClause>

および

  <sqlWhereClause>
     PRICE>1
  </sqlWhereClause>

は、両方とも有効です。

findAll()メソッドを指定するには、sqlWhereClause要素に空の文字列を指定するだけです。

For more information アップグレードの詳細については、exteNd Directorヘルプを参照してください。

EJB展開計画を完了するためのヒント

この節では、展開計画を完了するためのいくつかのヒントと例について説明します。この章の節は次のとおりです。

自動増分のサポート

コンテナは、展開計画のautoInc要素を使用して自動増分をサポートします。autoIncにcmp-fieldのマークが付いている場合は、次に示すように、マップ先のデータベースカラムで自動増分がサポートされている必要があります。

データベース	要件
Oracle	autoIncSequenceName要素を使用してシーケンス名を提供する必要があります。
Sybase、Microsoft、およびIBM DB2	カラムはIDENTITYカラムである必要があります。
Informix	カラムはSERIALタイプである必要があります。
IBM Cloudscape	カラムタイプはAUTOINCREMENTタイプである必要があります。

CMPエンティティBeanのテーブルへのマッピング

CMPエンティティBeanを1つの(そして唯一の)テーブルにマップします。展開計画のbeanPersistenceInfo要素を使用してBeanをテーブルにマップします。

次のように、エンティティBeanのエントリを指定した展開記述子があるとします。

  <entity>
      <ejb-name>BEAN_NAME</ejb-name>
      . . . 
  </entity>

展開計画内で対応するエントリはbeanPersistenceInfoノードにあります。次のようになります。

  <beanPersistenceInfo>
      <beanName>BEAN_NAME</beanName>
      <dataSourceName>DATABASE_OR_POOL_NAME</dataSourceName>
      <sqlHandler>SQL_HANDLER</sqlHandler>
      <isolationLevel>ISOLATION_LEVEL</isolationLevel>
      <table>
          <name>DB_TABLE</name>
          . . . 
      </table>
  </beanPersistenceInfo>

展開計画についての注意点:

beanPersistenceInfoノードのbeanName要素は、展開記述子(この例では、BEAN_NAME)のejb-name要素と一致している必要があります。
dataSourceName要素は、テーブル(この例では、DB_TABLE)が存在するデータベースまたは接続プールの名前です。

展開計画のsqlHandler要素は、次のいずれかになります。

データベースまたはクラス	有効なsqlHandler要素の値
Oracle	Oracle
IBM Cloudscape	Cloudscape
Sybase Adaptive Server Anywhere	AdaptiveServerAnywhere
Sybase Adaptive Server Enterprise	AdaptiveServerEnterprise
Informix	Informix
Microsoft SQL Server	MicrosoftSQLServer
IBM DB2	DB2
MYSQL	MySQL
com.sssw.shr.ejb2.api.AgiEJBSqlHandlerを実装するクラス	クラスの完全修飾された名前

注記: sqlHandler要素値は大文字と小文字を区別しません。

isolationLevel要素は、使用される分離レベルを識別します。コンテナは、TRANSACTION_READ_COMMITTEDまたはTRANSACTION_SERIALIZABLEをサポートします。TRANSACTION_ READ_COMMITTED分離レベルが使用された場合、コンテナはコミットの際に他のユーザによって値が変更されていないかどうか確認するためのチェックを行い、変更があった場合には、コンテナは並行違反例外をスローします。

異なる分離レベルを使用している複数のBean(同一データベース内の別々のテーブルにマップされる)がある場合は、Oracleデータベースを除いて、複数のプールが必要になります(次を参照)。

デッドロックが起こる可能性が高くなるため、TRANSACTION_SERIALIZABLEは注意して使用してください。

Oracleの例外 Oracleデータベースの場合は、TRANSACTION_SERIALIZABLEに対するすべてのREAD SQLステートメントにFOR UPDATEが追加され、行に対して明示的に書き込みロックを配置します。

永続的フィールドのマッピング

展開記述子にリストされている永続的フィールド(cmpフィールド要素)は、展開計画のデータベーステーブルのデータベースカラムにマップされる必要があります。これによりコンテナは、適切にフィールドを保持することができます。展開記述子は次のようになっているとします。

  <entity>
      <ejb-name>BEAN_NAME</ejb-name>
      <cmp-field>field1</cmp-field>
      <cmp-field>field2</cmp-field>
      <cmp-field>field3</cmp-field>
      . . . 
  </entity>

展開記述子のcmpフィールドは、展開計画のテーブルノードに対応する要素があります。例は次のとおりです。

      <table>
          <name>DB_TABLE</name>
          <field>
              <cmpFieldName>field1</cmpFieldName>
              <columnName>COLUMN1</columnName>
          </field>
          <field>
              <cmpFieldName>field2</cmpFieldName>
              <columnName>COLUMN2</columnName>
          </field>
          . . . 
      </table>

展開計画についての注意点:

展開計画の cmpFieldNames は、展開記述子内のcmp-field要素と一致する必要があります。
columnNameは、データベース内の実際のカラム名です。このフィールドでは大文字と小文字が区別されるため、JDBC getColumns()が返すデータベースカラム名と完全に一致する必要があります。コンテナは、カラムを検索するために正しいカラム名が必要です。

TRANSACTION_READ_COMMITTED分離レベルの使用

分離レベルとしてTRANSACTION_READ_COMMITTEDを指定する場合、パフォーマンスを高めるため、展開計画の中のいくつかのカラムをdeltaTypeカラムとして指定できます。

deltaType要素では、カラムデータを使用してカウントまたは合計(たとえば、総カウント数または売上合計)のどちらを保持するかを指定します。この要素を使用する場合は、オーバーフロー/アンダーフローに対する保護のためにデータベース制約を設定する必要があります。たとえば、特定の製品の残量を含むカラムがあるとします。この場合、多くのトランザクションがこの量を増減させようとする可能性があります。次のようなSQLがあるとします。

  UPDATE table SET quantity = ?WHERE col1=old_col1_value AND col2 = old_col2_value

および

  quantity = old_quantity

2人のユーザが同時に変更した場合、これらのSQLでは並行違反が発生します。これらのSQLの変わりに、コンテナは次のSQLを生成します。

  UPDATE table SET quantity = quantity + ?WHERE col1=old_col1_value 
  AND col2 = old_col2_value

この例では、数量がゼロより小さくなることを許可せず、カラムにNULLを許可しない制約を適用しています。

適切にdeltaType要素を使用することによって、CONCURRENCY_VIOLATION例外の発生する可能性を大幅に低減させ、パフォーマンスを向上させることができます。deltaType要素の使用法は、次のとおりです。

カラムは数量を表す必要があります。使用可能なデータタイプは、整数、ショート、ロング、浮動、倍精度、BigDecimalなどの数量タイプに限られるからです。
フィールドをヌルにすることはできません。
TRANSACTION_SERIALIZABLEへの影響はありません。

関係のマッピング

CMPを保有している2つのエンティティBeanの間に関係を存在させることができます。この関係は、展開記述子のrelationshipsノードを介して表され、展開記述子のrelationsListノードを介して実際のテーブルにマップされます。

展開記述子と展開計画の内容に基づいて、コンテナはテーブルを検索し、適切な値を取得したり設定したりするための適切なSQLコードを生成することができます。SQLを生成するために、コンテナは次の質問に対する回答が必要です。

関係が存在するかどうか。
関係にどのようなBeanが含まれているか。
関係の多様性はどのようになっているか。
関係の方向はどのようになっているか (双方向性または一方向)。一方向性の場合、他のBeanにアクセスできるのはどのBeanか。
関係をどのようにナビゲートするか。
外部キーとプライマリキーの関係はどのようになっているか。
関係でカスケード削除をサポートするかどうか。

コンテナは、これらすべての情報(外部キーマッピングを除く)を展開記述子のrelationshipsノードから取得します。relationshipsノードには、次の要素が含まれています。

  <relationships>
      <ejb-relation>
          <ejb-relationship-role>
              <multiplicity></multiplicity>
              <relationship-role-source>
                  <ejb-name></ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name></cmr-field-name>
                  <cmr-field-type></cmr-field-type>
              </cmr-field>
          </ejb-relationship-role>
          <ejb-relationship-role>
              <multiplicity></multiplicity>
              <relationship-role-source>
                  <ejb-name></ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name></cmr-field-name>
                  <cmr-field-type></cmr-field-type>
              </cmr-field>
          </ejb-relationship-role>
      </ejb-relation>
      . . . 
  </relationships>

関係についてのメモ

各関係に対して、必ず2つのejb-relationship-roleノードがあります。
multiplicity要素によって、関係が1対1、1対多、多対1、または多対多かどうかが決まります。
Beanクラスには、展開記述子の各cmr-field要素ごとに、対応するsetメソッドまたはgetメソッドがあります。したがってcmr-field要素の有無によって、方向(一方向性または双方向性)が決まります。
<ejb-relation-name>要素はオプションです(EJB仕様に準拠)。
多対多関係の場合、(展開計画の)linkTable要素は必須です。コンテナでは、1対多関係でlinkTable要素を使用できますが、お勧めしません。

展開記述子の用意ができたら、新規の展開計画を作成するか、または既存の展開計画を完了することができます。

1対1の双方向性関係の表し方

この例は、CustomerEJB (CUSTOMERテーブルにマップ)とAddressEJB (ADDRESSテーブルにマップ)の1対1の双方向性関係の表し方を説明しています。プライマリキーはそれぞれCustomerIDとAddressIDです。

展開記述子は、次のようになります。

      <ejb-relation>
          <ejb-relationship-role>
              <multiplicity>One</multiplicity>
              <relationship-role-source>
                  <ejb-name>CustomerEJB</ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name>address</cmr-field-name>
              </cmr-field>
          </ejb-relationship-role>
          <ejb-relationship-role>
              <multiplicity>One</multiplicity>
              <relationship-role-source>
                  <ejb-name>AddressEJB</ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name>customer</cmr-field-name>
              </cmr-field>
          </ejb-relationship-role>
      </ejb-relation>

展開記述子に関する注意点:

両方のejb-relationship-roleのmultiplicity要素は、1対1の関係を指定するOneです。
両方のejb-relationship-role要素はcmr-field-nameをリストします。これは関係が双方向性であることを示しています。cmr-field-nameは、関連するテーブルの実際のカラムまたは外部キーを表しているわけではありません。ターゲットカラムの実際の名前は展開が終了するまで分からないので、cmr-field-nameは、単に関係の方向を示すエントリです。

EJB JARを展開する準備が整い、CustomerEJBおよびAddressEJB EJBを表す展開計画を作成する必要があるとします。CustomerEJBとAddressEJBを、ADDRESSテーブルへの外部キーがCUSTOMERテーブルに含まれるターゲットデータベースにマップします。外部キーフィールドの名前はADDRESS_IDです。展開計画のrelationノードは、次のようになります。

      <relation>
          <relationRole>
              <beanName>CustomerEJB</beanName>
              <cmrFieldName>address</cmrFieldName>
              <columnNames>
                  <el>ADDRESS_ID</el>
              </columnNames>
          </relationRole>
          <relationRole>
              <beanName>AddressEJB</beanName>
              <cmrFieldName>customer</cmrFieldName>
          </relationRole>
      </relation>

展開計画についての注意点:

展開計画のbeanName は、展開記述子内のejb-name要素と完全に一致する必要があります。
展開計画のcmrFieldNameの有無は、展開記述子内のcmr-field-name要素と完全に一致する必要があります。
展開計画のcolumnName要素は、マップされるテーブル (CUSTOMER)の外部キーのカラム名です。つまり、customerから関連するaddress (またはその逆)にナビゲートできるようにコンテナがSQLを作成することを示しています。
AddressEJBのcmrFieldNameは、カラム名にマップされません。これは、ADDRESSテーブルにはCUSTOMERテーブルへの外部キーが含まれていない(含まれていてはならない)からです。
関係の方向は、外部キーの場所では決まりません。

ADDRESSテーブルに外部キー CUSTOMER_ID が含まれるようにデータベースをセットアップする必要がある場合、展開計画は次のようになります。

      <relation>
          <relationRole>
              <beanName>CustomerEJB</beanName>
              <cmrFieldName>address</cmrFieldName>
          </relationRole>
          <relationRole>
              <beanName>AddressEJB</beanName>
             <cmrFielName>customer</cmrFieldName>
              <columnNames>
                  <el>CUSTOMER_ID</el>
              </columnNames>
          </relationRole>
      </relation>

1対1の一方向性性関係の表し方

この例は、CustomerEJB (CUSTOMERテーブルにマップ)とAddressEJB (ADDRESSテーブルにマップ)の1対1の一方向性関係の表し方を説明しています。プライマリキーはそれぞれCustomerIDとAddressIDです。

展開記述子は、次のようになります。

      <ejb-relation>
          <ejb-relationship-role>
              <multiplicity>One</multiplicity>
              <relationship-role-source>
                  <ejb-name>CustomerEJB</ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name>address</cmr-field-name>
              </cmr-field>
          </ejb-relationship-role>
          <ejb-relationship-role>
              <multiplicity>One</multiplicity>
              <relationship-role-source>
                  <ejb-name>AddressEJB</ejb-name>
              </relationship-role-source>
          </ejb-relationship-role>
      </ejb-relation>

展開記述子に関する注意点:

両方のejb-relationship-roleのmultiplicity 要素は、1対1の関係を指定するOneです。
CustomerEJBにはcmr-field-name要素(この場合はaddress)が含まれますが、AddressEJBには含まれません。これは関係が一方向性になるように指定するもので、CustomerEJBからAddressEJBを参照することはできますが、その逆はできません(CustomerEJBには、ADDRESS EJBのgetメソッドおよびsetメソッドが含まれます)。
cmr-field-nameアドレスは、AddressEJB の実際のカラムを表しているわけではありません。展開計画を作成する際に、アドレスcmr-field を実際の外部キーカラムにマップする必要があります。

次の展開計画は、CUSTOMERテーブルに外部キーADDRESS_IDが含まれている場合にcmr-field-nameをマップする方法を示しています。

      <relation>
          <relationRole>
              <beanName>CustomerEJB</beanName>
              <cmrFieldName>address</cmrFieldName>
              <columnNames>
                  <el>ADDRESS_ID</el>
              </columnNames>
          </relationRole>
          <relationRole>
              <beanName>AddressEJB</beanName>
          </relationRole>
      </relation>

展開計画についての注意点:

展開計画の beanName は、展開記述子内の ejb-name要素と完全に一致する必要があります。
展開計画の cmrFieldName は、展開記述子のcmr-field-nameと完全に一致する必要があります(つまり、展開記述子にcmr-field-nameがない場合は展開計画にもcmrFieldNameがあってはなりません)。
展開計画の columnName要素は、マップされるテーブル(CUSTOMER)の外部キーのカラム名です。これは、customer から関連するaddressにナビゲートできるようにコンテナがSQLを作成することを示しています。
ADDRESSテーブルにはCUSTOMERテーブルへの外部キーが含まれていない(含まれていてはならない)ため、AddressEJB には、cmrFieldName要素もcolumnNames要素もありません。

既存のデータベースで異なる構造を使用していて、ADDRESSテーブルに外部キーCUSTOMER_IDが含まれているとします。展開計画は次のようになります。

      <relation>
          <relationRole>
              <beanName>CustomerEJB</beanName>
              <cmrFieldName>address</cmrFieldName>
          </relationRole>
          <relationRole>
              <beanName>AddressEJB</beanName>
              <columnNames>
                  <el>CUSTOMER_ID</el>
              </columnNames>
          </relationRole>
      </relation>

展開計画についての注意点:

すでに説明したように、relationRoleとcmrFieldNameは展開記述子のエントリと完全に一致する必要がありますが、ここでは、columnNamesはrelationRole要素のこのノードに含まれていません。これはCUSTOMERテーブルに外部キーがないためです(外部キーはADDRESSテーブルにあります)。
存在するcmrFieldName要素は1つだけなので、関係は一方向性のままです。
属するテーブルに外部キーを指定します。外部キーは関係の方向とは関係ありません。

1対多の双方向性関係の表し方

この例では次のものを使用します。

OrderEJB (ORDERテーブルにマップします)

および
LineItemEJB (LINEITEMテーブルにマップします)

各OrderEJBに対して複数のLineItemを使用できます。ORDERテーブルからLINEITEMテーブルに移動したり、LINEITEMテーブルからORDERテーブルに戻ることができます。

展開記述子は、次のようになります。

      <ejb-relation>
          <ejb-relationship-role>
              <multiplicity>One</multiplicity>
              <relationship-role-source>
                  <ejb-name>OrderEJB</ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name>lineItems</cmr-field-name>
                  <cmr-field-type>java.util.Collection</cmr-field-type>
              </cmr-field>
          </ejb-relationship-role>
          <ejb-relationship-role>
              <multiplicity>Many</multiplicity>
              <relationship-role-source>
                  <ejb-name>LineItemEJB</ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name>order</cmr-field-name>
              </cmr-field>
          </ejb-relationship-role>
      </ejb-relation>

展開記述子に関する注意点:

OrderEJBにはcmr-field-name要素(この場合はlineitems)が含まれていて、LineItemEJBにもcmr-field-name要素(この場合はorder)が含まれます。これは関係が双方向性であることを示しています。
2つ以上の項目が返される可能性があるため、lineitems cmr-field-name要素のデータタイプには、データタイプ仕様(java.util.Collection)が含まれています。

次の条件で展開記述子を作成しているとします。

OrderEJB BeanはORDERSテーブル (プライマリキーはORDERID) にマップされる
LineItemEJB BeanはLINEITEMテーブル (プライマリキーはLINEITEMID) にマップされる
LINEITEMテーブルには外部キーORDER_IDがある

この場合、展開計画は次のようになります。

      <relation>
          <relationRole>
              <beanName>OrderEJB</beanName>
              <cmrFieldName>lineItems</cmrFieldName>
          </relationRole>
          <relationRole>
              <beanName>LineItemEJB</beanName>
              <cmrFieldName>order</cmrFieldName>
              <columnNames>
                  <el>ORDER_ID</el>
              </columnNames>
          </relationRole>
      </relation>

展開計画についての注意点:

ここでも、beanNameは展開記述子のejb-nameと同じで、cmrFieldNameは展開記述子のcmr-field-nameと同じでなければなりません。
LineItemEJBには、外部キーにマップされるcolumnName要素が含まれています。
1対1の関係では、外部キーはどちらのテーブルにも配置できます。1対多の関係では、外部キーは常に多側に常駐します。関係の方向は、外部キーの場所では決まりません。

1対多の一方向性関係の表し方

次の例は、1対多の一方向性関係の表し方を説明しています。この例では、ProductEJB (PRODUCTテーブルにマップ)およびLineItemEJB (LINEITEMテーブルにマップ)を使用します。各ProductEJBに対して複数のLineItemEJBを使用できます。LINEITEMテーブルからPRODUCTテーブルに移動することはできますが、PRODUCTテーブルからLINEITEMテーブルに戻ることはできません。

展開記述子は、次のようになります。

      <ejb-relation>
          <ejb-relationship-role>
              <multiplicity>One</multiplicity>
              <relationship-role-source>
                  <ejb-name>ProductEJB</ejb-name>
              </relationship-role-source>
          </ejb-relationship-role>
          <ejb-relationship-role>
              <multiplicity>Many</multiplicity>
              <relationship-role-source>
                  <ejb-name>LineItemEJB</ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name>product</cmr-field-name>
              </cmr-field>
          </ejb-relationship-role>
      </ejb-relation>

ProductEJB のmultiplicity 要素はOne、LineItemEJBのmultiplicity 要素はMany になっており、1つのProductEJBで関連する複数のLineItemEJBを使用できるように指定しています。
CustomerEJBにはcmr-field-name要素(この場合はaddress)が含まれますが、AddressEJBには含まれません。これは、関係がLineItemからProductへの単一方向であることを示しています。

次の条件で、上の展開記述子用の展開計画を作成しているとします。

ProductEJB BeanはPRODUCTテーブル(プライマリキーはPRODUCTID)にマップされる
LineItemEJB BeanはLINEITEMテーブル(プライマリキーはLINEITEMID)にマップされる
LINEITEMテーブルには外部キーPRODUCT_IDがある

この場合、展開計画は次のようになります。

      <relation>
          <relationRole>
              <beanName>ProductEJB</beanName>
          </relationRole>
          <relationRole>
              <beanName>LineItemEJB</beanName>
              <cmrFieldName>product</cmrFieldName>
              <columnNames>
                  <el>PRODUCT_ID</el>
              </columnNames>
          </relationRole>
      </relation>

展開計画についての注意点:

ここでも、beanNameは展開記述子のejb-nameと同じで、cmrFieldNameは展開記述子のcmr-field-nameと同じである必要があります。
LineItemEJBには、外部キーにマップされるcolumnNames要素が含まれています。

リンクテーブルの使用

リンクテーブルを使用することができます(ただしお勧めしません)。たとえば、PRODUCT_IDとLINEITEM_IDの列があり、それぞれがPRODUCTIDとLINEITEMIDにマップされているPROD_LINEITEMがリンクテーブルであるとします。

この場合、展開計画は次のようになります。

      <relation>
          <linkTable>PROD_LINEITEM</linkTable>
          <relationRole>
              <beanName>ProductEJB</beanName>
              <columnNames>
                  <el>PRODUCT_ID</el>
              </columnNames>
          </relationRole>
          <relationRole>
              <beanName>LineItemEJB</beanName>
              <cmrFieldName>product</cmrFieldName>
              <columnNames>
                  <el>LINEITEM_ID</el>
              </columnNames>
          </relationRole>
      </relation>

多対多の一方向性関係の表し方

この例は、OrderEJB (ORDERテーブルにマップ)とProductEJB (PRODUCTテーブルにマップ)の多対多の一方向性関係の表し方を説明しています。プライマリキーはそれぞれOrderIDとProductIDです。多対多の関係では、常にlinkTableを使用します。

展開記述子は、次のようになります。

      <ejb-relation>
          <ejb-relationship-role>
              <multiplicity>Many</multiplicity>
              <relationship-role-source>
                  <ejb-name>OrderEJB</ejb-name>
              </relationship-role-source>
              <cmr-field>
                  <cmr-field-name>products</cmr-field-name>
                  <cmr-field-type>java.util.Collection</cmr-field-type>
              </cmr-field>
          </ejb-relationship-role>
          <ejb-relationship-role>
              <multiplicity>Many</multiplicity>
              <relationship-role-source>
                  <ejb-name>ProductEJB</ejb-name>
              </relationship-role-source>
          </ejb-relationship-role>
      </ejb-relation>

展開記述子に関する注意点:

両方のejb-relationship-roleのmultiplicity要素は、Manyです。

次の条件で展開計画を作成する必要があるとします。

ProductEJB BeanはPRODUCTテーブル(プライマリキーはPRODUCTID)にマップされる。
OrderEJB BeanはORDERSテーブル(プライマリキーはORDERID)にマップされる。
リンクテーブルはPROD_ORDERである。PROD_ORDERテーブルのプライマリキーは、PRODUCT_IDとORDER_IDです(これらは、PRODUCTおよびORDERテーブルの外部キーでもあります)。

この場合、展開計画は次のようになります。

      <relation>
          <linkTable>PROD_ORDER</linkTable>
          <relationRole>
              <beanName>OrderEJB</beanName>
              <cmrFieldName>products</cmrFieldName>
              <columnNames>
                  <el>ORDER_ID</el>
              </columnNames>
          </relationRole>
          <relationRole>
              <beanName>ProductEJB</beanName>
              <columnNames>
                  <el>PRODUCT_ID</el>
              </columnNames>
          </relationRole>
      </relation>

展開計画についての注意点:

ここでも、beanNameは展開記述子のejb-nameと同じで、cmrFieldNameは展開記述子のcmr-field-nameと同じである必要があります。
relationノードには、実際のデータベーステーブルの名前を指定するlinkTable要素が含まれます。
OrderEJBとProductEJBの両方のrelation役割には、linkTableへの外部キーマッピング(columnNames要素経由)が含まれます。

関係のマッピングに関する一般的な制約

次の点に注意してください。

1つのカラムをcmp-fieldとcmr-fieldの両方として使用できますが、1つのカラムがcmp-fieldとcmr-fieldの両方である場合、cmp-fieldは読み込み専用にしておく必要があります。この場合、cmp-fieldでsetメソッドをコールすると、例外が発生します。
同じデータベースカラムを複数のcmp-fieldまたはcmr-fieldに対して使用することはできません。
関係を変更するには、cmp-fieldではなくcmr-fieldを使用します。

プライマリキーのマッピング

エンティティのプライマリキーを指定するには、primkey-fieldまたはprim-key-class要素を使用します(EJB仕様では、prim-key-class要素は必須ですが、primkey-fieldは任意です)。

単一フィールドのプライマリキーの場合、primkey-fieldは、cmp-fieldの1つである必要があります。

プライマリキーがマルチフィールドキーの場合は、次のとおりです。

プライマリキーを指定するには、prim-key-classを使用します。
すべてのprim-key-classのフィールドは、パブリックである必要があります。
prim-key-classのフィールド名は、エンティティBeanクラスのフィールド名と対応している必要があります。

primkey-field要素が指定されておらず、prim-key-class要素がjava.lang.Objectの場合、クラスは不明のプライマリキーになります(EJB 2.0 仕様のセクション10.8.3を参照)。不明のプライマリキーに対しては、EJBコンテナによって固有のキーが生成されます。不明のプライマリキーをサポートするため、展開計画primaryKey要素が次のように使用されます。

primaryKey要素に対してprimaryKeyClass要素を指定する必要があります。

コンテナは、primaryKeyClass用のjava.lang.String、java.lang.Integer、またはjava.lang.Longをサポートします。
- primaryKeyClassがjava.lang.Stringの場合、autoInc要素は無視されます。また、カラムは32バイト長のStringデータを格納できる必要があります。
- primaryKeyClassがjava.lang.Integerまたはjava.lang.Longの場合は、自動増分カラムを使用して固有のプライマリキーを作成できるようにするため、autoInc要素は必須です(自動増分をサポートするカラムにマップする必要があります)。
- 一般的には、自動増分カラムを指定した方がパフォーマンスが向上します。次に、展開計画におけるプライマリキークラスエントリの内容の例を示します。
```
      <primaryKey>
          <primaryKeyClass>java.lang.Integer</primaryKeyClass>
          <columnName>AUTO_INC_COL</columnName>
          </autoInc>
      </primaryKey>
```

メッセージ駆動型Beanのマッピング

メッセージ駆動型Beanでは、JMSサーバを使用してメッセージを送信および消費します。コンテナがJMSサーバを検索できるよう、少なくともdestinationName要素とConnectionFactoryName要素を指定する必要があります。例は次のとおりです。

      <message>
          <destinationName>
             corbaname:iiop:JMSServer:53506#queue/queueName
          </destinationName>
          <connectionFactoryName>
             corbaname:iiop:JMSServer:53506#queue/xaConnectionFactory
          </connectionFactoryName>
      </message>

注記: 指定されているConnectionFactoryがグローバルトランザクションをサポートしている必要があります。

EJBセキュリティのIOR設定

この節では、安全なEJB呼び出しをサポートするために展開計画で指定する必要がある情報について説明します。これらの情報は、展開計画のiorSecurityConfig要素を介して指定します。iorSecurityConfigノードは、エンティティおよびセッション要素の一部です。

IOR (Interoperable Object Reference)

CORBAを使用してリモートでアクセス可能なすべてのオブジェクトは、IOR(Interoperable Object Reference)を介して参照されます。IORはオブジェクトのリモート参照で、CORBAまたはJNDIネーミングサービスなどに格納し、その後、リモートオブジェクトのコールに使用可能なスタブに変換することができます。したがって、IORには、リモートオブジェクトのスタブを作成し、そのスタブに対してリモートメソッドコールを発行するためにクライアントORBが必要とする「すべて」の情報が含まれている必要があります。情報には次のものが含まれます。

情報項目	説明
リモートオブジェクトをコールできる1つまたは複数のアドレス(ホストのIPアドレスとTCPポート番号)	Novell exteNd ORBは、このアドレスでリッスンします。
オブジェクトの作成時にサーバORBによってリモートオブジェクトに割り当てられるオブジェクト識別子	ORBは、この情報を使用してオブジェクトを検索します。
オブジェクトのタイプ(オブジェクトが実装するリモートインタフェースのリスト)	クライアントは、この情報を使用して、作成するスタブの種類を判別します。
オブジェクトのセキュリティ情報	クライアントは、オブジェクトへのコールに安全な(暗号化された)接続を使用するかどうか、およびクライアント証明書、ユーザ名とパスワード、またはその他のコール側IDや資格情報をコールのたびにオブジェクトに渡すかどうかを、この情報を使用して判断します。この情報は、展開時に<iorSecurityConfig>要素によって指定されます(詳細については、次のIORセキュリティ設定の内容を参照してください)。
オブジェクトのトランザクション情報	クライアントは、この情報を使用して、2段階コミットのトランザクション情報をオブジェクトに伝達するかどうかを決定します。

クライアントがネーミングサービス(JNDI経由など)でリモートのCORBAオブジェクト(EJBなど)を検索したとき、戻されるのがオブジェクトのIORです。クライアントは、PortableRemoteObject.narrow()をコールしてIORをスタブに変換します。クライアントがスタブに対してメソッドをコールしようとすると、クライアントのORBはIORから取得した情報を使用して、作成する接続のタイプ(暗号化またはプレーン)、接続するサーバアドレスとポート番号、およびクライアント識別子、資格情報、コールに関するトランザクション情報をエンコードして送信するかどうかを決定します。次にサーバは、提供された情報がIORの要求した情報と一致するかどうかを検証してから、コールをリモートオブジェクトに送信します。

IORセキュリティ設定の内容

iorSecurityConfig要素に指定されたIORセキュリティ設定には、次の3つのセクションがあります。

セクション	定義内容
トランスポートの設定	暗号化された通信チャネルを使用するかどうかを決定します。使用する場合には、必要な暗号化パラメータと認証情報を定義します。
認証コンテキストの設定	このオブジェクトへのコールに対してどの種類の認証メカニズム(ユーザ名とパスワードなど)を提供するか、およびオブジェクトへの匿名コールを許可するかどうかを定義します。
セキュリティ属性コンテキストの設定	このオブジェクトに対して、コール側IDの伝達をサポートするかどうかを定義します。

トランスポート設定

トランスポート設定はtransportConfig要素で指定します。トランスポート設定は、オブジェクトへのコールに暗号化された通信チャネル(SSLまたはTLS)を使用するかどうかをクライアントに通知します。使用する場合は、使用する暗号化アルゴリズム、および認証のためにクライアントがクライアント証明書を提供する必要があるかどうかを指定します。

<transportConfig>要素の内容は、次の4つの属性から構成されます。

属性	説明
Integrity	少なくともメッセージの整合性を保証する暗号化をオブジェクトでサポートするか、それとも必須にするかを指定します(メッセージの破損を検出できます)。 REQUIREDに設定されている場合、コール側はSSL (またはTLS)を使用して適切な暗号を選択します。 SUPPORTEDに設定されている場合、コール側はSSLを使用できます(クライアントでの決定方法の詳細については、次の情報を参照してください)。
Confidentiality	少なくともメッセージの機密性を保証する暗号化アルゴリズムを使用した暗号化をオブジェクトでサポートするか、それとも必須にするかを指定します。これによってメッセージの漏えいを防ぐことができます。 REQUIREDに設定されている場合、コール側はSSL (またはTLS)を使用して適切な暗号を選択します。 SUPPORTEDに設定されている場合、コール側はSSLを使用できます。
establishTrustInClient	クライアントがクライアント証明書(x.509)を使用して認証することをオブジェクトで要求するかどうかを指定します。 REQUIREDに設定されている場合、クライアントは、このオブジェクトに対してSSL接続を設定する際に、クライアント証明書を提供する必要があります。この場合、SSL (またはTLS)を使用する必要もあります。 SUPPORTEDに設定されている場合、コール側はクライアント証明書を提供できます。
establishTrustInServer	オブジェクトのサーバがクライアントに対して自身を認証できる必要があるかどうかを指定します。現在のところ、サーバがクライアントに対して自身を認証する唯一のメカニズムは、SSL (またはTLS)を使用する方法です。したがって、このフラグはSSLの使用を制御することと同等です。 REQUIREDに設定されている場合、クライアントはこのオブジェクトへのコールに対してSSL (またはTLS)を使用する必要があります。 SUPPORTEDに設定されている場合、クライアントはSSLを使用できます。

これらのフラグは互いに関係し合っています。たとえば、いずれかのフラグがREQUIREDに設定されている場合、クライアントはSSL (またはTLS)を使用する必要があります。同様に、establishTrustInClientをREQUIREDに設定することでSSLを使用するように指定できますが、integrityとconfidentialityの両方をnoneに設定することで特定の暗号を指定することはできません。

SSLを選択するためのクライアントアルゴリズム 4つのtransportConfigフラグのいずれかがREQUIREDに設定されている場合、クライアントはオブジェクトへのコールにSSLを使用する必要があります。どのフラグもREQUIREDに設定されていなくても、少なくとも1つのフラグがSUPPORTEDに設定されている場合は、クライアントはSSLを使用するかどうかを選択する必要があります。クライアントは、SilverJ2EEClientの-AS_USE_SSLフラグに基づいてこれを決定します。このフラグがtrueに設定されている場合はSSLが使用され、trueに設定されていない場合はSSLは使用されません。

暗号メッセージの整合性およびメッセージの保護に使用される一連の暗号は、それぞれintegrityCipherSuites要素とconfidentialityCipherSuites要素を使用して、展開計画で明示的に指定することができます。これらの要素が指定されている場合、各要素は暗号名のString配列になります。

状況	処理内容
integrityCipherSuites要素が指定されている	指定されたリスト内の暗号は、整合性をサポートまたは要求しているものの、機密性はサポートまたは要求していないオブジェクトへのコールに使用されます。
confidentialityCipherSuites要素が指定されている	指定されたリスト内の暗号は、機密性をサポートまたは要求するオブジェクトへのコールに使用されます。
いずれの要素も指定されていない	該当するカテゴリに対する暗号のデフォルトリストがサーバによって提供されます。

認証コンテキストの設定 asContext要素は、オブジェクトに対する各メソッドコールの一部としてクライアントからサーバに渡される認証情報を記述します。この情報は、SSL接続が確立される際に渡されるクライアント証明書とは別のものです。asContext要素には、次の3つのサブ要素があります。

サブ要素	説明
authMethod	コール側に対してサポートされている認証方式。指定できる値は次のとおりです。 NONE - このオブジェクトへのコールに対して、コール側の認証を提供することはできません。 USERNAME_PASSWORD - 各コールに対して、ユーザ名とパスワードの文字列を提供できます。
realm	defaultという名前の一般的なレルムをサポートします。デフォルトレルムは、サーバでサポートされている任意のレルムと一致します。デフォルトとしてrealmが指定されている場合、ユーザ名とパスワードは修飾名として渡されるため、サーバはLDAPユーザ名とNTユーザ名を区別することができます。
asContextRequired	コール側がユーザ名とパスワードを提供する必要があるかどうかを示すブール。trueの場合、authMethod要素をNONEに設定することはできず、コール側は、オブジェクトに対する各コールでユーザ名とパスワードを提供する必要があります。

サブ要素

説明

authMethod

コール側に対してサポートされている認証方式。指定できる値は次のとおりです。

NONE - このオブジェクトへのコールに対して、コール側の認証を提供することはできません。
USERNAME_PASSWORD - 各コールに対して、ユーザ名とパスワードの文字列を提供できます。

realm

defaultという名前の一般的なレルムをサポートします。デフォルトレルムは、サーバでサポートされている任意のレルムと一致します。

デフォルトとしてrealmが指定されている場合、ユーザ名とパスワードは修飾名として渡されるため、サーバはLDAPユーザ名とNTユーザ名を区別することができます。

asContextRequired

コール側がユーザ名とパスワードを提供する必要があるかどうかを示すブール。trueの場合、authMethod要素をNONEに設定することはできず、コール側は、オブジェクトに対する各コールでユーザ名とパスワードを提供する必要があります。

セキュリティ属性コンテキストの設定

セキュリティ属性コンテキストの設定は、callerPropagationを介して<sasContext>要素で指定されます。これは、このオブジェクトがコール側IDの伝達をサポートするかどうかを示します。コール側IDの伝達は、クライアントがパスワードなどの資格情報を使用せずにサーバにコール側IDを伝達する機能です。これは、サーバがクライアントを信頼しており、クライアントがすでにコール側IDを検証済みである場合にのみ役立ちます。たとえば、コール側が、クライアントのパスワードをすでに検証済みの組織によって所有されている別のアプリケーションサーバである場合などです。指定できる値は次のとおりです。

値	意味
NONE	このオブジェクトに対して、コール側の伝達はサポートされません。
SUPPORTED	コール側はIDを伝達できます(コール側が信頼されていることをサーバが検証することが条件です)。
REQUIRED	コール側はIDを伝達する必要があります。

サーバは、信頼するクライアントのリストを使用して、コール側が信頼されているかどうかを判別します。信頼するクライアントのリストは、SMCを使って設定できます。

コールで複数のIDが提供されているとします(たとえば、IDの伝達によってアサートされたクライアント証明書とID)。この場合、IDは次のようにして決定されます。

クライアント証明書が提供されている場合は、クライアント証明書を使用してコール側IDを取得します。
IDがコール側の伝達によってアサートされた場合は、そのIDをコール側IDとして使用します。
コールでユーザ名とパスワードが渡された場合は、そのユーザ名とパスワードを使用してコール側IDを取得します。
それ以外の場合は、コール側をAnonymous (匿名)として扱います。

IOR設定の例

例1 この例は、次のようなオブジェクトのIOR設定を示しています。

SSLを使用して、メッセージの機密性(暗号化)を保持した状態でコールされる

クライアント証明書、またはユーザ名とパスワードのいずれかを介してコール側IDを渡す処理をサポートする

  <iorConfig>
     <transportConfig>
       <integrity>NONE</integrity>
       <confidentiality>REQUIRED</confidentiality>
       <establishTrustInClient>SUPPORTED</establishTrustInClient>
       <establishTrustInServer>SUPPORTED</establishTrustInServer>
     </transportConfig>
    <asConfig>
       <authMethod>USERNAME_PASSWORD</authMethod>
       <realm>default</realm>
       <asContextRequired>FALSE</asContextRequired>
     </asConfig>
     <sasConfig>
       <callerPropagation>NONE</callerPropagation>
     </sasConfig>
  </iorConfig>

例2 この例は、次のようなオブジェクトのIOR設定を示しています。

SSLを使用しないでコールされる

ただし、ユーザ名とパスワードを使用したコール側の認証を要求する

  <iorConfig>
     <transportConfig>
       <integrity>NONE</integrity>
       <confidentiality>NONE</confidentiality>
       <establishTrustInClient>NONE</establishTrustInClient>
       <establishTrustInServer>NONE</establishTrustInServer>
     </transportConfig>
     <asConfig>
       <authMethod>USERNAME_PASSWORD</authMethod>
       <realm>default</realm>
       <asContextRequired>TRUE</asContextRequired>
     </asConfig>
     <sasConfig>
       <callerPropagation>NONE</callerPropagation>
     </sasConfig>
  </iorConfig>

例3 この例は、次のようなオブジェクトのIOR設定を示しています。

SSLを使用して、メッセージの機密性が保護された状態でコールされる

クライアント証明書を渡すが、サーバ間でのコールに対してはコール側の伝達をサポートする

  <iorConfig>
     <transportConfig>
       <integrity>NONE</integrity>
       <confidentiality>REQUIRED</confidentiality>
       <establishTrustInClient>REQUIRED</establishTrustInClient>
       <establishTrustInServer>NONE</establishTrustInServer>
     </transportConfig>
     <asConfig>
       <authMethod>NONE</authMethod>
       <realm>default</realm>
       <asContextRequired>FALSE</asContextRequired>
     </asConfig>
     <sasConfig>
       <callerPropagation>SUPPORTED</callerPropagation>
     </sasConfig>
  </iorConfig>

サーバでのクラスパスJARの指定

EJB 2.0、WAR 2.3、およびEAR 1.3用の展開計画では、classpathJars 要素がサポートされており、この要素を使用して、アプリケーションのクラスパスにあるJARファイルのリストを調整することができます。これによって、サーバにコピーしたユーザ指定のJARにアクセスすることができます。

頻繁に使用される1つまたは複数のJARを、複数のアプリケーションに展開するのではなく直接サーバ上に配置したい場合があります。このようなJARは、サーバの\userlibディレクトリにコピーしてから、必要に応じて、classpathJarsとそのuserlibJarsサブ要素を使用してアーカイブの展開計画にリストすることができます。

例は次のとおりです。

  <classpathJars>
    <userlibJars>
      <el>MyJarA.jar</el>
      <el>MyJarB.jar</el>
    </userlibJars>
  </classpathJars>

これによって、展開済みのアーカイブは、リストされているuserlib JARの中のクラスをランタイム時に検索できるようになります。

For more information classpathJars要素の構文の詳細については、を参照してください。

展開に対するスレッド使用の制御

オブジェクトをサーバにアップロードするために展開プログラムが使用するスレッドの数を指定できます。デフォルトでは、展開プログラムはパフォーマンスを向上させるために4つのスレッドを使用します。

Procedure スレッドの数を変更する

user.prefsファイルを編集します。

user.prefsファイルは、サーバの\Resources\Preferencesディレクトリにあります。
次の行を最後のendobjの前に追加して、スレッドの数を設定します(この例では1つのスレッドだけを使用するように指定しています)。
```
     DEPLOYER
     /ThreadNumber 1
     endobj
```