exteNd Application Server 5.0

コアヘルプ


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

第2章 J2EEアーカイブ配備

この章では、J2EE互換アーカイブファイルをNovell exteNd アプリケーションサーバに配備するための要件について説明します。この章のトピックは次のとおりです。

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

アーカイブの配備

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.1Beanがある場合、正しいDTDを使用するために配備計画を更新する必要があります。 EJB配備計画の詳細については、 EJB JAR配備計画DTDを参照してください。

Novell exteNd Workbench Deployment Plan Editorを使用して、配備計画を変換できます。配備計画エディタの使用の詳細については、次のトピックを参照してください。

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

Workbenchは、EJB 1.1 Finderメソッドを、SQLステートメントのWHERE句と1つまたは複数の入力パラメータを含む簡単な表現に変換します。 Finderの最初の入力パラメータは?1に、2番目は?2にというように変換されます。

次に例を示します。

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

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

  <sqlWhereClause>
     WHERE PRICE>1
  </sqlWhereClause>

および

  <sqlWhereClause>
     PRICE>1
  </sqlWhereClause>

両方とも有効です。

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

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

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
DB2DB2	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が追加され、明示的に行に対してWRITEロックを取得します。

永続的フィールドのマップ

配備記述子にリストされている永続的フィールド(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を作成します。

  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が含まれていますか?
関係の多様性は何ですか?
関係の方向は何ですか(双方向性または一方向)? 一方向性の場合、他のＢｅａｎにアクセスできるのはどのＢｅａｎですか?
関係はどのようにナビゲートしますか?
外部キーとプライマリキーの関係は何ですか?
関係ではカスケード削除をサポートしていますか?

コンテナは、配備記述子の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要素によって関係が一対一、一対多、多対一、あるいは多対多かどうかが決まります。
配備記述子の各cmr-field要素ごとに、Beanクラスには対応するsetメソッドまたはgetメソッドがあります。したがってcmr-field要素(またはこの要素は欠落)によって、方向(一方向性または双方向性)が決まります。
<ejb-relation-name>要素は、オプションです(EJB仕様に準拠)。
多対多関係の場合、(配備計画の)linkTable要素は必須です。コンテナでは、一対多関係でlinkTable要素を使用できますが、お勧めしません。

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

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

CustomerEJB (CUSTOMERテーブルにマップ)とAddressEJB (ADDRESSテーブルにマップ)の一対一の双方向性関係の表し方の例を次に示します。プライマリキーはそれぞれ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-rolesのmultiplicity要素によって、一対一の関係であることが指定されます。
両方のejb-relationship-role要素はcmr-field-namesをリストします。これは関係が双方向性であることを示しています。 cmr-field-namesは、関連するテーブルの中で実際の列または外部キーを表しているわけではありません。配備が終了するまでターゲット列の実際の名前は分かりません。cmr-field-namesは、関係の方向を示すただのエントリです。

EJB JARを配備する準備が整い、CustomerEJBおよびAddressEJB EJBを表す配備計画を作成する必要があります。 CustomerEJBとAddressEJBを、CUSTOMERテーブルにADDRESSテーブルへの外部キーが含まれているターゲットデータベースにマップします。外部キーフィールドの名前は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>

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

CustomerEJB (CUSTOMERテーブルにマップ)とAddressEJB (ADDRESSテーブルにマップ)の一対一の一方向性関係の表し方の例を次に示します。プライマリキーはそれぞれ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-rolesのmultiplicity要素によって、一対一の関係であることが指定されます。
CustomerEJBにはcmr-field-name要素が含まれます(この場合はaddress)が、AddressEJBには含まれません。これは関係が一方向性であることを示しています。CustomerEJBからAddressEJBを参照することはできますが、その逆はできません (CustomerEJBは、ADDRESS EJBのgetメソッドおよびsetメソッドを含みます)。
cmr-field-namesアドレスは、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とcmrFieldNamesは配備記述子のエントリと完全に一致する必要がありますが、今回columnNameは、relationRole elementのこのノードには含まれていません。これはCUSTOMERテーブルに外部キーがないからです(ADDRESSテーブルにあります)。
1つのcmrFieldName要素だけが存在しているため、関係は一方向性のままです。
従属するテーブルに外部キーを指定します。外部キーは関係の方向とは関係ありません。

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

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

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

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

各OrderEJBに対して、多数のLineItemsをがあります。 ORDERテーブルからLINEITEMテーブルに移動して、戻ることができます。

配備記述子は、次のようになります。

      <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)。これは関係が双方向性であることを示しています。
lineitems cmr-field-name要素のデータタイプには、2つ以上の項目を戻すことができるため、データタイプ仕様(java.util.Collection)が含まれています。

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

OrderEJB BeansはORDERSテーブル(プライマリキーはORDERID)をマップします。
LineItemEJB Beansは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要素が含まれています。
一対一の関係では、外部キーの場所はどちらかのテーブルになります。一対多の関係では、外部キーは常に多側に常駐します。外部キーの場所によって関係の方向は決まりません。

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

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

配備記述子は、次のようになります。

      <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要素が一で、LineItemEJBのmultiplicity要素が多となります。1つのProductEJBを指定すると、関連付けられた多数のLineItemEJBがあります。
CustomerEJBにはcmr-field-name要素が含まれますが(この場合はaddress)、AddressEJBには含まれません。これは関係がLineItemからProductへの単一方向であることを示しています。

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

ProductEJB BeansはPRODUCTテーブル(プライマリキーはPRODUCTID)をマップします。
LineItemEJB Beansは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要素が含まれています。

リンクテーブルの使用

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

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

      <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-rolesのmultiplicity要素は、Manyです。

次の条件で配備計画を作成しなければならないとします。

ProductEJB BeansはPRODUCTテーブル(プライマリキーはPRODUCTID)をマップします。
OrderEJB Beansは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として使用することはできません。
関係を変更するには、cmr-field (cmp-fieldではなく)を通して行います。

プライマリキーのマップ

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

単一フィールドのプライマリキーの場合、primkey-fieldはcmp-fieldsの中のどれか1つでなければなりません。

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

プライマリキーを指定するには、prim-key-classを使用します。
すべてのprim-key-classのフィールドは、パブリックでなければなりません。
prim-key-classのフィールド名は、エンティティBeansクラスのフィールド名と対応していなければなりません。

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>
```

メッセージ駆動型Beansのマップ

メッセージ駆動型Beansでは、JMSサーバを使用してメッセージを送信したり消費したりします。 JMSサーバを検索するコンテナに対しては、最低でもdestinationName要素とConnectionFactoryName要素を指定する必要があります。例は次のとおりです。

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

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

EJBセキュリティのIOR設定

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

相互操作可能なオブジェクトの参照

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

情報項目	説明
「1つまたは複数のアドレス」(ホストIPアドレスとTCPポート番号)これによってリモートオブジェクトを呼び出すことができます。	サーバ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	オブジェクトで、クライアントがクライアント証明書を使って認証することを要求するかどうかを指定します。 REQUIREDに設定されていると、クライアントはこのオブジェクトに対してSSL接続をセットアップする際、クライアント証明書を提示しなければなりません。これはSSL(あるいはTLS)も使用する必要があります。 SUPPORTEDに設定されていると、呼び出し側はクライアント証明書を提示します。
establishTrustInServer	オブジェクトのサーバはクライアントに対して自分自身を認証できなければならないかどうかを指定します。現在のところ、サーバがクライアントに対して自分自身を認証する唯一の方法は、SSL(またはTLS)を介して行うことです。したがって、このフラグはSSLの使用を制御するのと同じことです。 REQUIREDに設定されていると、クライアントはこのオブジェクトの呼び出しに対してSSL (またはTLS)を使用しなければなりません。 SUPPORTEDに設定されていると、クライアントはSSLを使用できます。

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

SSLを選択するためのクライアントアルゴリズム 4つのtransportConfigフラグのいずれかがREQUIREDに設定されていると、クライアントはオブジェクトへの呼び出しに対してSSLを使用する必要があります。 REQUIREDが1つも指定されていなくて、最低でも1つのSUPPORTEDが指定されている場合は、クライアントはSSLを使用するかどうかを選択する必要があります。クライアントは、SilverJ2EEClientへの-SS_ USE_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>要素で指定されます。属性は、このオブジェクトでcaller identity propagationをサポートするかどうかを示します。呼び出し側のIDを伝達することは、クライアントはパスワードなどのアカウント情報を使用しないで呼び出し側のIDをサーバに伝達できる機能です。これは、サーバはクライアントを信頼しており、そしてクライアントはすでに呼び出し側のIDを検証済みである場合にのみ有用です。たとえば、呼び出し側は、クライアントのパスワードがすでに検証済みである組織によって所有されている別のアプリケーションサーバである場合などです。可能な値は次のとおりです。

値	意味
NONE	このオブジェクトに対して、呼び出し側の伝達はサポートされていません。
SUPPORTED	呼び出し側はIDを伝達できます(呼び出し側が信頼できる相手であるとのサーバの検証に基づきます)。
REQUIRED	呼び出し側はIDを伝達しなければなりません。

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

呼び出しに対して複数の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>

サーバ上でのclasspath JARの指定

EJB 2.0、WAR 2.3、およびEAR 1.3用の配備計画では、アプリケーションのクラスパスにあるJARファイルのリストを調整するために使用できるclasspathJars 要素をサポートしています。これによって、サーバにコピーしたユーザ定義の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
```


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