4. EJBアプリケーション

4.1. コンテナ管理による永続性(CMP)Entity Beanの使用法

この文書ではWebOTX内でコンテナ管理による永続性(CMP)Entity Beanを動作させる方法についてを説明します。

以下のトピックがあります。

CMPに関する詳細な仕様はEnterprise JavaBeans Specification, v2.1の10章、11章、14章を参照してください。

4.1.1. WebOTXのCMPサポート

WebOTXのCMPでは以下をサポートしています。

4.1.2. コンテナ管理による永続性(CMP)マッピング

CMPを使用するEntity Beanを実装する場合、CMPフィールドとデータベースのCMRフィールド(リレーション)のマッピングが問題となります。この章ではマッピングに関する以下の項目について説明します。

4.1.2.1. マッピング配備記述子ファイル

CMP Beanを含んだモジュールには、以下のファイルが含まれている必要があります。

nec-cmp-mappings.xmlファイルはCMPフィールドとデータベースのCMRフィールド(リレーション)をマッピングします。それぞれのCMPに対して、主テーブルが選択される必要があります。そしてオプションとして複数の副テーブルがあります。CMPフィールドは主テーブルまたは副テーブルの列にマッピングされます。CMRフィールドは列リストのペアにマッピングされます。(通常、列リストとは主キーと外部キーのペアに関連付けられた列のリストです)

nec-cmp-mappings.xmlファイルはnec-cmp-mapping_1_1.dtdファイルのフォーマットに従っています。ユーザが定義したBeanクラスと一緒にEJB-JARファイルにパッケージされます。META-INFディレクトリ配下に存在します。

otxadminコマンドや統合運用管理ツールを使用して配備を行う場合、nec-cmp-mappings.xmlがすでに存在していなければ、配備中に自動的にnec-cmp-mappings.xmlというファイル名でマッピングを作成します。

nec-cmp-mappings.xmlファイルの自動生成はnec-ejb-jar.xmlファイル中または配備時に指定されるオプションによって動作を変えることができます([ 4.1.2.3. 自動マッピングのオプション ]を参照してください)。自動マッピングを使用する場合、開発者はJavaプログラミング言語だけを知っていればよく、データベーススキーマのことを理解したり知っていたりする必要はありません。

nec-cmp-mappings.xml配備記述子を直接編集することでEntity Beanのフィールドとリレーションのマッピングを手動で行うこともできます。開発者がXML編集に熟練している場合のみこの方法を取ってください。

CMP配備記述子中のマッピング要素のリストは[ 4.2. nec-cmp-mappings.xmlファイル ]に記述されています。XMLファイルのサンプルは[ 4.2.2. データベーススキーマ定義のサンプル ]に記述されています。

マッピング情報はデータベーススキーマファイル(.dbschema)ファイルと連動して作られます。データベーススキーマファイルはBeanが配備されるときに自動的にキャプチャすることができます。([ 4.1.2.7. データベーススキーマの自動キャプチャ ]参照)。また、キャプチャスキーマユーティリティを使用して手動でスキーマを作成することもできます。([ 4.1.2.8. キャプチャスキーマユーティリティの使用法 ]参照)。

4.1.2.2. マッピングの機能

マッピングとはオブジェクト指向モデルデータとリレーショナルモデルデータ(通常はリレーショナルデータベースのスキーマ)を結びつける機能のことです。CMP実装はデータを含み、動作が関連付けられた、相互関係を持つBeanの集合と、スキーマとの結びつけを提供します。これによって開発者はJavaアプリケーションの一部分としてデータベースを表現したオブジェクトを使用できます。開発者は必要に応じて、これらBeanの最適化のためにマッピングをカスタマイズすることもできます。結果、永続的なデータベース情報と通常の一時的なプログラムデータの両方にアクセスすることができる単独データモデルになります。WebOTXによって提供されるマッピングの機能とは以下のとおりです。

4.1.2.3. 自動マッピングのオプション

開発者は自動マッピングを、配備記述子要素やコマンドラインオプションを使うことにより以下のようにコントロールすることができます。

nec-ejb-jar.xmlファイル中のcmp-resource要素の副要素である、以下の選択的データは配備時のデータベースの表自動作成をコントロールします。cmp-resource要素についての詳細は[ 4.1.3. リソースマネージャの設定方法 ]を参照してください。

要素 デフォルト 説明
create-tables-at-deploy false trueの場合、EJBコンテナによって自動的にマッピングされたBeanのためのデータベーステーブルが作成されます。falseの場合、テーブルは作られません。
drop-tables-at-undeploy false trueの場合、Beanの配備解除時、Beanが最後に配備されたときに自動的に作成されたデータベーステーブルが削除されます。falseの場合、テーブルは削除されません。
database-vendor-name なし テーブルを作成するデータベースベンダの名前を指定します。指定できる値はdb2、derby、mssql、oracle、sybaseです。大文字小文字は区別されません。値が指定されなければ、コネクションはnec-ejb-jar.xmlファイルの中でcmp-resource要素のjndi-name副要素による指定に従って作成されます。そして、データベースベンダ名を読み込みます。コネクションの確立ができない、または値を認識できない場合、SQL-92遵守が仮定されます。
schema-generator-properties なし property副要素によりフィールド指定の型マッピングを指定できます。 またuse-unique-table-namesプロパティを指定することもできます。これがtrueの場合、生成されたテーブル名がそれぞれのアプリケーションサーバドメインの中でユニークであることを意味します。

<schema-generator-properties>
        <property>
                <name>
                Employee.firstName.jdbc-type
                </name>
                <value>char</value>
        </property>
        <property>
                <name>
                Employee.firstName.jdbc-maximum-length
                </name>
                <value>25</value>
        </property>
        <property>
                <name>
                use-unique-table-names
                </name>
                <value>true</value>
        </property>
</schema-generator-properties>

表4.1.2.3-1

以下のotxadmin deployまたはotxadmin deploydirコマンドのオプションは、配備時のデータベーステーブル自動生成をコントロールします。

オプション デフォルト 説明
--createtables なし trueの場合、Beanが使用するデータベーステーブルを配備時に作成します。falseの場合、テーブルは作られません。指定されない場合、nec-ejb-jar.xmlファイル中のcreate-tables-ant-deploy属性の値が使用されます。
--dropandcreatetables なし trueでかつこのアプリケーションが最後に配備されたときテーブルが自動的に作成されていた場合、最後の配備時に作られたテーブルは削除され、新しいテーブルが作成されます。 trueでかつ最後にこのアプリケーションを配備したとき自動的にテーブルを作成しなかった場合、テーブルの削除は行われません。もし自動的に作成されるものと同じ名前のテーブルが見つかったなら、配備は続行されますが、テーブル作成ができなかったことを警告します。 falseの場合、nec-ejb-jar.xmlファイル中のcreate-tables-at-deployまたはdrop-tables-at-undeployの設定が上書きされます。
--uniquetablenames なし trueの場合、テーブル名がそれぞれのアプリケーションサーバドメインの中でユニークであると指定します。指定されない場合、nec-ejb-jar.xmlファイル中のuse-unique-table-namesプロパティの値が使用されます。
--dbvendorname なし テーブルを作成するデータベースベンダの名前を指定します。指定できる値はdb2、derby、mssql、oracle、sybaseです。大文字小文字は区別されません。指定されなければ、nec-ejb-jar.xmlファイル中のdatabase-vender-name属性の値が使用され、それも指定されなければ、コネクションはnec-ejb-jar.xmlファイルの中でcmp-resource要素のjndi-name副要素による指定に従って作成されます。そして、データベースベンダ名を読み込みます。コネクションの確立ができない、または値を認識できない場合、SQL-92遵守が仮定されます。

表4.1.2.3-2

モジュール中のBeanの一つ、または複数を手動でマッピングしたうえで、otxadmin deployやotxadmin deploydirのオプションを指定した場合、配備はどの方法でも問題なく行われますが、オプションは無効になり、サーバログに警告が出力されます。

Beanの一つまたは複数のマッピングに統合運用管理ツールを使用した場合、otxadmin deployまたはotxadmin deploydir実行時の--uniquetablenamesオプションは無効になります。統合運用管理ツールがマッピングを生成した時、テーブル名がユニークであることが保障されます。

otxadmin undeployコマンドの以下のオプションは配備解除時にデータベーステーブルの自動削除をコントロールします。

オプション デフォルト 説明
--droptables なし trueの場合、Beanが配備解除されたとき、そのBeanが最後に配備されたときに自動的に作成されたデータベーステーブルを削除します。falseの場合、テーブルの削除は行いません。 指定されない場合、nec-ejb-jar.xmlファイル中のdrop-tables-at-undeploy属性の値が使用されます。

表4.1.2.3-3

otxadmin deploy, otxadmin deploydir, otxadmin undeployについて詳しくは、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス ]を参照してください。

コマンドラインとnec-ejb-jar.xmlオプション両方が指定されたとき、otxadminオプションの方が優先されます。

4.1.2.4. マッピングでサポートしているデータ型

CMPはJavaデータフィールドからSQL型へのマッピングに使用されるJDBCのデータ型をサポートします。サポートされるJDBCデータ型は以下のとおりです。

以下の表は推奨されたJavaの型とJDBC型のマッピングを示します。

Java型 JDBC型 nullを許容するか
boolean BIT No
java.lang.Boolean BIT Yes
byte TINYINT No
java.lang.Byte TINYINT Yes
double DOUBLE No
java.lang.Double DOUBLE Yes
float REAL No
java.lang.Float REAL Yes
int INTEGER No
java.lang.Integer INTEGER Yes
long BIGINT No
java.lang.Long BIGINT Yes
short SMALLINT No
java.lang.Short SMALLINT Yes
java.math.BigDecimal DECIMAL Yes
java.math.BigInteger DECIMAL Yes
char CHAR No
java.lang.char CHAR Yes
java.lang.StringBuffer VARCHAR Yes
java.lang.String VARCHAR Yes
java.lang.String CLOB Yes
Serializable BLOB Yes
byte[] BLOB Yes
java.util.Date TIMESTAMP Yes
java.sql.Time TIME Yes
java.sql.Date DATE Yes
java.sql.Timestamp TIMESTAMP Yes

表4.1.2.4-1

Caution
CMPフィールドにアサインされるJava型はJavaプリミティブ型、Java Serializable型、java.util.Date、java.sql.Date、java.sql.Time、java.sql.Timestampに制限されます。Entity Beanのローカルインタフェース型(またはそれのコレクション)はCMRフィールドの型にすることが可能です。

以下の表はデータベースベンダの特定の型へのJDBCタイプの推奨されたマッピングを示しています。

JDBC型 Oracle DB2 Derby Sybase ASE 12.5 MS-SQL Server
BIT SMALLINT SMALLINT SMALLINT BIT BIT
BOOLEAN SMALLINT SMALLINT SMALLINT TINYINT BIT
TINYINT SMALLINT SMALLINT SMALLINT TINYINT TINYINT
SMALLINT SMALLINT SMALLINT SMALLINT SMALLINT SMALLINT
INTEGER INTEGER INTEGER INTEGER INTEGER INT
BIGINT NUMBER BIGINT BIGINT NUMERIC DECIMAL
REAL REAL REAL REAL REAL REAL
FLOAT FLOAT FLOAT FLOAT FLOAT FLOAT
DOUBLE DOUBLE DOUBLE DOUBLE PRECISION DOUBLE PRECISION DOUBLE PRECISION
NUMERIC(p,s) NUMBER(p,s) DECIMAL(p,s) NUMERIC(p,s) NUMERIC(p,s) NUMERIC(p,s)
DECIMAL(p,s) NUMBER(p,s) DECIMAL(p,s) DECIMAL(p,s) DECIMAL(p,s) DECIMAL(p,s)
VARCHAR VARCHAR2 VARCHAR VARCHAR VARCHAR VARCHAR
DATE DATE DATE DATE DATETIME, SMALLDATETIME DATETIME, SMALLDATETIME
TIME DATE TIME TIME DATETIME, SMALLDATETIME DATETIME, SMALLDATETIME
TIMESTAMP TIMESTAMP TIMESTAMP TIMESTAMP DATETIME DATETIME
BLOB BLOB BLOB BLOB IMAGE IMAGE
CLOB CLOB CLOB CLOB TEXT TEXT

表4.1.2.4-2

Caution
上記の表のマッピングは提案であり、サポートするものではありません。これらマッピングがうまく機能しない場合、使用しているデータベースとJDBCドライバのドキュメントを参照してください。

4.1.2.5. BLOBサポート

Binary Large Object(BLOB)は複雑なオブジェクトフィールドを保存し、検索するのに使用するデータ型です。BLOBは画像のようなバイナリかSerializableオブジェクトで、CMPフィールドにシリアライズ(直列化)されるとき巨大なバイト配列に変換されます。

CMPフィールドがSerializableとして定義されている場合、データベースに保存される前にbyte[]にシリアライズされます。同様に、データベースから値をフェッチするとき、デシリアライズされます。しかし、CMPフィールドがbyte[]として定義されるなら、シリアライズ、デシリアライズは行われず、直接保存またはフェッチされます。

WebOTX環境においてBLOBサポートを有効にする為に、CMPフィールドの型をbyte[]かjava.io.Serializableインタフェースを実装したユーザ定義型に定義してください。CMP Beanをすでに存在するデータベーススキーマにマッピングするなら、フィールドをBLOBタイプのカラムへマッピングしてください。

自動マッピングを使用する場合、開発者はnec-ejb-jar.xmlファイル中のschema-generator-properties要素を使って生成されたスキーマのために、デフォルトのBLOBカラム長を変更する必要がある可能性があります。使用するデータベースベンダのドキュメントを参照し、長さを指定する必要があるかどうかを確認してください。

<schema-generator-properties>
        <property>
                <name>Employee.voiceGreeting.jdbc-type</name>
                <value>BLOB</value>
        </property>
        <property>
                <name>Employee.voiceGreeting.jdbc-maximum-length</name>
                <value>10240</value>
        </property>
...
</schema-generator-properties>

4.1.2.6. CLOBサポート

Character Large Object(CLOB)は非常に長いテキストフィールドを保存し、検索するのに使われるデータ型です。CLOBは長い文字列に変換されます。

WebOTX環境でCLOBサポートを有効にするには、java.lang.String型のCMPフィールドを定義してください。CMP Beanを既存のデータベーススキーマにマッピングする場合、そのフィールドをCLOB型のカラムにマッピングしてください。

自動マッピングを使用する場合、生成されたスキーマのためにnec-ejb-jar.xmlのschema-generator-properties要素を使用します。デフォルトCLOBカラム長を変える必要がある可能性があります。 データベースベンダのドキュメントを参照し、長さの指定が必要であるか決定してください。

<schema-generator-properties>
        <property>
                <name>Employee.resume.jdbc-type</name>
                <value>CLOB</value>
        </property>
        <property>
                <name>Employee.resume.jdbc-maximum-length</name>
                <value>10240</value>
        </property>
        ...
</schema-generator-properties>

4.1.2.7. データベーススキーマの自動キャプチャ

CMP Beanに対して統合運用管理ツールまたはotxadminコマンドによる配備を行うときに、自動的にデータベースのメタデータをキャプチャし、.dbschemaファイルで保存して設定することができます。

nec-cmp-mappings.xmlファイルが<schema/>空エントリを含んでいる場合、nec-ejb-jar.xmlファイル中のcmp-resourceエントリがデータベースとのコネクションを得るのに使用されます、そして、スキーマの自動生成が実行されます。nec-cmp-mappings.xmlファイルが自動生成されるとき、デフォルトで<schema/>エントリを含んでいます。 データベーステーブル構造を変えるなら、CMPフィールドとリレーションの自動的再マッピングのためにBeanを再配備しなければなりません。

4.1.2.8. キャプチャスキーマユーティリティの使用法

手動でデータベースメタデータ(.dbschema)ファイルを生成するためにはキャプチャスキーマコマンドを使用します。

Caution
キャプチャスキーマコマンドを実行するOracleデータベースのユーザがそのスキーマを所有していなければ、ANALYZE ANY TABLE特権を必要とします。これらの特権はデータベース管理者によってユーザに与えられます。 キャプチャスキーマユーティリティはテーブルを変更することはありません。 唯一の目的はデータベース(スキーマ)の構造に関する情報を永続化エンジンに提供することです。 .dbschemaファイルの名前はドメイン内のすべての配備されたモジュールに対して一意でなければなりません。
書式

capture-schema -username name -password password -dburl url -driver jdbcdriver -out filename [-schemaname schemaname] [-table tablename]*

-username name
データベースへのアクセスが承認されているユーザ名を指定します。
-password password
選択されたデータベースへのアクセスのためのパスワードを指定します。
-dburl url
データベースにアクセスする為のドライバのJDBC URLを指定します。
-driver jdbcdriver
JDBCドライバのクラス名を指定してください。このクラスはCLASSPATHに指定されている必要があります。
-out filename
出力する対象を指定します。出力ファイル名に拡張子がない場合、.dbschemaが付けられます。出力ファイル名が.dbschema以外の拡張子である場合、指定された拡張子に加え.dbschemaが付けられ、警告が表示されます。 CMPマッピングのために、-outパラメータはnec-cmp-mappings.xmlファイル中のnec-cmp-mapping要素のschema副要素に相互関連します。このxml中では、出力ファイル名は.dbschemaサフィックスを付けない文字列を指定します。

<schema>RosterSchema</schema>
-schemaname schemaname:
キャプチャされるユーザスキーマの名前を指定します。指定されない場合、デフォルトでユーザがアクセスできるすべてのスキーマから全テーブルのメタデータをキャプチャします。

注意:ユーザが複数のスキーマにアクセス可能である場合、このパラメータが未指定の時同じ名前の複数のテーブルがキャプチャされることを意味します。

-table tablename
テーブル名を指定します。複数回このパラメータを使用することにより、複数のテーブルに対するメタデータをキャプチャすることができます。指定されない場合、データベーススキーマ中のすべてのテーブルがキャプチャされます。

capture-schema -dburl jdbc:oracle:thin:@localhost:1521:orcl -username scott -password tiger -driver oracle.jdbc.driver.OracleDriver -out RosterSchema.dbschema

4.1.3. リソースマネージャの設定方法

リソースマネージャはCMP実装であるPersistenceManagerFactoryによって使用されています。 「統合運用管理ツール」を使用して設定します。

ドメインツリーから、「リソース」−「永続化リソース」を選択し、右クリックメニューから「永続化リソースの登録」を実行してください。 ここで入力したリソースのJNDI名はnec-ejb-jar.xmlのcmp-resource要素の副要素のjndi-nameに指定されます。

4.1.4. EJB 1.1ファインダークエリ設定方法

このセクションは以下のトピックを含んでいます。

4.1.4.1. JDOQLクエリについて

EJB仕様v1.1では、ファインダーメソッド記述フォーマットは指定されていませんでした。WebOTXではファインダーおよびセレクタメソッド実装のためにJava Data Objects Query Language(JDOQL)クエリの拡張を使用します。EJB2.1ではコンテナは自動的にEJBQLクエリからJDOQLにマッピングされます。EJB1.1では、このマッピングは開発者が行っていました。基本的なJDOQLクエリの以下の要素を指定することができます。

WebOTX固有の配備記述子(nec-ejb-jar.xml)はEJB1.1ファインダーメソッド設定へ以下の要素の保存を提供します。

WebOTXはEJB1.1Entity BeanのJDOQLクエリを構成します。開発者がJDOQLクエリによって指定することにより、フィルタ、パラメータ宣言、変数宣言の追加および並び替えが行われます。ファインダーメソッドパラメタを使用することでクエリが実行されます。JDOQLクエリリザルトセットからのオブジェクトはEJB1.1ejbFindメソッドで返却される主キーのインスタンスに変換されます。

JDO仕様(JSR12を見てください)はJDOQLの包括的な記述を提供します。 以下の情報はEJB1.1ファインダーを定義するのに使用される要素を要約しています。

4.1.4.2. クエリフィルタ式

フィルタ式は候補のクラスの各インスタンスのために評価されたboolean式を含むStringです。フィルタが指定されなければ、デフォルト値はtrueになります。有効な式を構成するための規則はJava言語に従いますが以下の違いがあります。

memo
浮動小数点値同士の比較は不正確なものとなります。それゆえ浮動小数点値との等価比較(==,!=)は注意して使う必要があります。式における識別子は宣言しているパラメータと変数に加え、候補のクラスの名前空間にあると考えられます。 Java言語のように、これは、予約語であり、評価される現在のインスタンスを参照します。

以下の式はサポートされています。

4.1.4.3. クエリパラメータ

パラメータ宣言はカンマで区切られた一つあるいは複数の型宣言子を含むStringです。これはメソッドのシグネチャのためのJava文法に従います。

4.1.4.4. クエリ変数

型の宣言はローカル変数宣言のJava文法に従います。

例1

以下のクエリはMichaelと呼ばれるすべてのプレイヤーに返却します。nameフィールドと文字列リテラルを比較するフィルタを定義します。

name == "Michael"

nec-ejb-jar.xmlファイルのfinder要素はこのようになります。

<finder>
        <method-name>findPlayerByName</method-name>
        <query-filter>name == "Michael"</query-filter>
</finder>

例2

このクエリは指定されたpriceの範囲のすべての製品を返却します。priceの上限と下限の二つのパラメータを定義します。つまりdouble lowとdouble highになります。フィルタは二つのクエリパラメータとpriceフィールドを比較します。

low < price && price < high

Query orderingは price ascendingにセットします。

nec-ejb-jar.xmlファイルのfinder要素は次のようになります。

<finder>
        <method-name>findInRange</method-name>
        <query-params>double low, double high</query-params>
        <query-filter>low &lt; price &amp;&amp; price &lt; high</query-filter>
        <query-ordering>price ascending</query-ordering>
</finder>

例3

このクエリは指定したnameを持つプレイヤーよりも、高いsalaryのプレイヤーをすべて返却します。nameのクエリパラメータをjava.lang.String nameと定義します。その上で、プレイヤーが比較する変数を定義します。Beanに対応した永続化可能クラスの型があります。

mypackage.PlayerEJB_170160966_JDOState player

フィルタは指定されたnameのプレイヤーのsalaryとこのキーワードによって指示された現在のプレイヤーのsalaryを比較します:

(this.salary > player.salary) && (player.name == name)

nec-ejb-jar.xmlファイルのfinder要素は以下のようになります。

<finder>
        <method-name>findByHigherSalary</method-name>
        <query-params>java.lang.String name</query-params>
        <query-filter>
        (this.salary &gt; player.salary) &amp;&amp; (player.name == name)
        </query-filter>
        <query-variables>mypackage.PlayerEJB_170160966_JDOState player</query-variables>
</finder>

4.1.5. CMPの最適化

このセクションではCMP Entity Beanを使用する際の最適化方法について論じます。

4.1.5.1. フィールドステートのローディング

デフォルトでは、抽象的BeanのejbLoadメソッドを呼び出す前に、EJBコンテナはすべてのCMPフィールド(ただし、BLOBとCLOBフィールドは除く)のステートをロードします。 このアプローチは巨大なステートを持ったエンティティオブジェクトにとって、大部分のビジネスメソッドがステートの一部だけとアクセスする場合、最適ではないかもしれません。 これが問題になるようならば、あまり頻繁に使われないフィールドのためにnec-cmp-mapping.xmlのfetched-with要素を使用してください。

4.2. nec-cmp-mappings.xmlファイル

この文書ではnec-cmp-mappings.xmlファイルのXML要素について説明し、データベーススキーマとXMLファイルのサンプルを提示します。

4.2.1. nec-cmp-mappings.xmlファイルのXML要素

nec-cmp-mappings.xmlファイルのXML要素について説明します。

nec-cmp-mappings.xmlファイルでは、nec-cmp-mappings要素がすべての要素の親要素となります。 [ 4.2.3. nec-cmp-mappings.xmlファイルのサンプル ]を参照してください。

以下の目次は、nec-cmp-mappings.xmlの階層構造を表しています。

4.2.1.1. check-modified-at-commit

コミット時にBeanのコンカレントな修正をチェックします。

副要素

なし

4.2.1.2. cmp-field-mapping

cmp-field-mapping要素はあるフィールドとそれとマッピングする1つあるいは複数のカラムとの関連付けを行います。カラムはBeanの主テーブルのもの、または定義された副テーブルのものであっても構いません。フィールドが複数のカラムにマッピングされるならこの要素で最初に書かれたカラムが、データベースから値を得るソースとして使用されます。カラムは表示順に更新されます。 ejb-jar.xmlファイル中で定義されるcmp-field要素に対して、それぞれ1つのcmp-field-mappingが存在します。

副要素

cmp-field-mapping要素の副要素は以下のとおりです。

副要素 必要性 説明
field-name 1つのみ フィールドのJava識別子を指定します。識別子はマッピングされるcmp-field副要素のfield-name値と一致しなければなりません
column-name 1つ以上 主テーブルからのカラムの名前を指定するか、副テーブル、あるいは関連付けられたテーブルからのカラムのテーブル修飾名(TABLE.COLUMN)を指定します。
read-only 0か1つ フィールドが読み取り専用であることを指定します。
fetched-with 0か1つ このCMPフィールドのマッピングのフェッチグループを指定します。

表4.2.1.2

4.2.1.3. cmr-field-mapping

コンテナ管理によるリレーション(CMR)フィールドはリレーションを定義したnameと1つまたは複数のカラムのペアを持ちます。ejb-jar.xmlファイルにはそれぞれのcmr-fieldに一つのcmr-field-mapping要素が存在します。リレーションはフェッチグループに参加することもできます。

副要素

cmr-field-mapping要素の副要素は以下のとおりです

副要素 必要性 説明
cmr-field-name 1つのみ フィールドのJava識別子を指定します。ejb-jar.xmlファイル中のcmr-field-name副要素の値と一致する必要があります。
column-pair 1つ以上 2個のデータベーステーブルの間のリレーションを決定するカラムの組を指定します。
fetched-with 0か1つ このCMRフィールドのリレーションのフェッチグループを指定します。

表4.2.1.3

4.2.1.4. cmr-field-name

フィールドのJava識別子を指定します。ejb-jar.xmlファイル中のcmr-field-name副要素の値と一致する必要があります。

副要素

なし

4.2.1.5. column-name

主テーブルからのカラムの名前を指定するか、副テーブル、あるいは関連付けられたテーブルからのカラムのテーブル修飾名(TABLE.COLUMN)を指定します。

副要素

なし

4.2.1.6. column-pair

2つのデータベーステーブルのリレーションを決定するカラムのペアを指定します。column-pairにはかならず2つのcolumn-name副要素が必要です。最初のcolumn-name要素はこのBeanがマッピングされたテーブルのカラム名を示します。2番目のcolumn-nameは関連付けられたテーブルのカラム名を示します。

副要素

column-pair要素の副要素は以下のとおりです。

副要素 必要性 説明
column-name 2つ 主テーブルからのカラムの名前を指定するか、副テーブル、あるいは関連付けられたテーブルからのカラムのテーブル修飾名(TABLE.COLUMN)を指定します。

表4.2.1.6

4.2.1.7. consistency

Bean中のデータのトランザクション一貫性の保障のためのコンテナの動作を指定します。

副要素

consistency要素の副要素は以下のとおりです。

副要素 必要性 説明
check-modified-at-commit どれか1つを指定 コミット時にBeanのコンカレント修正をチェックします。
lock-when-loaded データがロードされたとき排他的ロックを行います。
none 一貫性チェックを行いません。

表4.2.1.7

4.2.1.8. ejb-name

コンテナ管理による永続性(CMP)Beanに対応するejb-jar.xmlファイル中のEntity Beanのejb-nameを指定します。

副要素

なし

4.2.1.9. entity-mapping

Beanのデータベースのカラムへのマッピングを指定します。

副要素

entity-mapping要素の副要素は以下のとおりです。

副要素 必要性 説明
ejb-name 1つのみ コンテナ管理による永続性(CMP)Beanに対応するejb-jar.xmlファイル中のEntity Beanのejb-nameを指定します。
table-name 1つのみ データベーステーブルの名前を指定します。テーブルはデータベーススキーマファイル中に存在している必要があります。
cmp-field-mapping 1つ以上 フィールドと、マッピングする1つまたは複数のカラムを関連付けます。
cmr-field-mapping 0以上 コンテナ管理によるリレーション(CMR)フィールドはリレーションを定義したnameと1つまたは複数のカラムのペアを持ちます。
secondary-table 0以上 Beanの主テーブルと副テーブルのリレーションを記述します。
consistency 0か1 Bean中のデータのトランザクション一貫性の保障のためのコンテナの動作を指定します。

表4.2.1.9

4.2.1.10. fetched-with

フィールドとリレーションのフェッチグループの設定を指定します。fetched-with要素は親要素に従って、異なったデフォルト値を持ちます。

cmp-field-mappingの副要素としてのfetched-with副要素がないなら、デフォルト値は次のように仮定されます。

<fetched-with><level>0</level></fetched-with>

CMPフィールドはデフォルトのフェッチグループにおかれます。これはデータベースからBeanがロードされたとき、いつもフェッチされることを示します。

cmr-field-mappingの副要素としてのfetched-with副要素がないなら、デフォルト値は次のように仮定されます。

<fetched-with><none/></fetched-with>

CMRフィールドは別々のフェッチグループに置かれます。それは、トランザクション内でそれが初めてアクセスされるときデータベースからロードされることを意味します。

副要素

fetched-with要素の副要素は以下のとおりです。

副要素 必要性 説明
level どれか1つを指定 階層的なフェッチグループの名前を指定します。
named-group 独立したフェッチグループの名前を指定します。
none このフィールド、またはリレーションが自分自身によってフェッチされることを指定します。

表4.2.1.10

4.2.1.11. field-name

フィールドのJava識別子を指定します。この識別子は、ejb-jar.xmlファイルのcmp-field要素中のfield-name副要素の値と一致する必要があります。

副要素

なし

4.2.1.12. level

階層的なフェッチグループの名前を指定します。名前は整数でなければなりません。指定された値と等しいか、より小さい階層的フェッチグループに所属するフィールドとリレーションが同時にフェッチされます。値は0よりも大きくなくてはなりません。1つしか許容されません。

副要素

なし

4.2.1.13. lock-when-loaded

Beanがロードされたときいつも、Beanに対応した列にデータベースが更新ロックをかけます。ロックがどのように行われるかはデータベース依存になります。ロックはトランザクションが終了したとき(コミットやロールバック)に解放されます。ロックが掛けられている間、他のデータベースユーザはBeanへの読み取りアクセスが行えます。

副要素

なし

4.2.1.14. named-group

独立したフェッチグループの名前を指定します。指定されたグループの一部であるすべてのフィールドとリレーションは同時にフェッチされます。フィールドはフェッチグループのタイプに関わらず、1つのフェッチグループにのみ所属できます。1つのみ許容されます。

副要素

なし

4.2.1.15. nec-cmp-mapping

特定のデータベーススキーマへマッピングされるBeanを指定します。

Caution
たとえBeanが同じEJB JARファイル内で配備されても、異なったデータベーススキーマへマップされたBeanとリレーションを持つことはできません。
副要素

nec-cmp-mapping要素の副要素は以下のとおりです。

副要素 必要性 説明
schema 1つのみ データベーススキーマの記述を含むファイルを指定します。
entity-mapping 1つ以上 データベースのカラムへのBeanのマッピングを指定します。

表4.2.1.15

4.2.1.16. nec-cmp-mappings

EJB JARコレクション内でマッピングされるすべてのBeanのnec-cmp-mapping要素の集合を指定します。

副要素

nec-cmp-mappings要素の副要素は以下のとおりです。

副要素 必要性 説明
nec-cmp-mapping 1つ以上 特定のデータベーススキーマにマッピングされるBeanを指定します。

表4.2.1.16

4.2.1.17. none

fetched-with要素の副要素の場合、フィールドまたはリレーションが、ほかのフィールドやリレーションではなく、自分自身によってフェッチされることを指定します。

consistency要素の副要素の場合、トランザクションの一貫性チェックを行わないことを指定します。

副要素

なし

4.2.1.18. read-only

フィールドが読み取り専用であることを指定します。

副要素

なし

4.2.1.19. schema

nec-cmp-mappings.xmlファイルの中のBeanがマッピングされるデータベーススキーマの記述を含むファイルを指定します。この要素が空ならば、配備時に自動的にデータベーススキーマファイルが生成されます。空でなければ、schema要素はnec-cmp-mapping.xmlファイルを含むディレクトリとの相対的なパス名がついた.dbschemaファイルを拡張子なしで指定してください。

<schema/> <!-- 自動スキーマ生成機能を使用します -->
<schema>CompanySchema</schema> <!-- "CompanySchema.dbschema"ファイルを使用します -->

[ 4.1.2.7. データベーススキーマの自動キャプチャ ]を参照

副要素

なし

4.2.1.20. secondary-table

Beanの副テーブルを指定します。

副要素

secondary-table要素の副要素は以下のとおりです。

副要素 必要性 説明
table-name 1つのみ データベーステーブルの名前を指定します。
column-pair 1つ以上 2つのデータベーステーブルの間のリレーションを決定するカラムのペアを指定します。

表4.2.1.20

4.2.1.21. table-name

データベーステーブルの名前を指定します。このテーブルはデータベーススキーマファイルに存在していなければなりません。[ 4.1.2.7. データベーススキーマの自動キャプチャ ]参照。

副要素

なし

4.2.2. データベーススキーマ定義のサンプル

create table TEAMEJB (
        TEAMID varchar2(256) not null,
        NAME varchar2(120) null,
        CITY char(30) not null,
        LEAGUEEJB_LEAGUEID varchar2(256) null,
        constraint PK_TEAMEJB primary key (TEAMID)
)
create table PLAYEREJB (
        POSITION varchar2(15) null,
        PLAYERID varchar2(256) not null,
        NAME char(64) null,
        SALARY number(10, 2) not null,
        constraint PK_PLAYEREJB primary key (PLAYERID)
)
create table LEAGUEEJB (
        LEAGUEID varchar2(256) not null,
        NAME varchar2(256) null,
        SPORT varchar2(256) null,
        constraint PK_LEAGUEEJB primary key (LEAGUEID)
)
create table PLAYEREJBTEAMEJB (
        PLAYEREJB_PLAYERID varchar2(256) null,
        TEAMEJB_TEAMID varchar2(256) null
)
alter table TEAMEJB
        add constraint FK_LEAGUE foreign key (LEAGUEEJB_LEAGUEID)
        references LEAGUEEJB (LEAGUEID)
alter table PLAYEREJBTEAMEJB
        add constraint FK_TEAMS foreign key (PLAYEREJB_PLAYERID)
        references PLAYEREJB (PLAYERID)
alter table PLAYEREJBTEAMEJB
        add constraint FK_PLAYERS foreign key (TEAMEJB_TEAMID)
        references TEAMEJB (TEAMID)

4.2.3. nec-cmp-mappings.xmlファイルのサンプル

以下のマッピングは配備可能なEJB JARファイルの META-INF/nec-cmp-mappings.xmlファイルです

<?xml version="1.0" encoding="UTF-8"?>
<nec-cmp-mappings>
        <nec-cmp-mapping>
                <schema>Roster</schema>
                <entity-mapping>
                        <ejb-name>TeamEJB</ejb-name>
                        <table-name>TEAMEJB</table-name>
                        <cmp-field-mapping>
                                <field-name>teamId</field-name>
                                <column-name>TEAMEJB.TEAMID</column-name>
                        </cmp-field-mapping>
                        <cmp-field-mapping>
                                <field-name>name</field-name>
                                <column-name>TEAMEJB.NAME9</column-name>
                        </cmp-field-mapping>
                        <cmp-field-mapping>
                                <field-name>city</field-name>
                                <column-name>TEAMEJB.CITY</column-name>
                        </cmp-field-mapping>
                        <cmr-field-mapping>
                                <cmr-field-name>league</cmr-field-name>
                                <column-pair>
                                        <column-name>TEAMEJB.LEAGUEEJB_LEAGUEID</column-name>
                                        <column-name>LEAGUEEJB.LEAGUEID</column-name>
                                </column-pair>
                                <fetched-with>
                                        <none/>
                                </fetched-with>
                        </cmr-field-mapping>
                        <cmr-field-mapping>
                                <cmr-field-name>players</cmr-field-name>
                                <column-pair>
                                        <column-name>TEAMEJB.TEAMID</column-name>
                                        <column-name>PLAYEREJBTEAMEJB.TEAMEJB_TEAMID</column-name>
                                </column-pair>
                                <column-pair>
                                        <column-name>PLAYEREJBTEAMEJB.PLAYEREJB_PLAYERID</column-name>
                                        <column-name>PLAYEREJB.PLAYERID</column-name>
                                </column-pair>
                                <fetched-with>
                                        <none/>
                                </fetched-with>
                        </cmr-field-mapping>
                </entity-mapping>
                <entity-mapping>
                        <ejb-name>PlayerEJB</ejb-name>
                        <table-name>PLAYEREJB</table-name>
                        <cmp-field-mapping>
                                <field-name>position</field-name>
                                <column-name>PLAYEREJB.POSITION9</column-name>
                        </cmp-field-mapping>
                        <cmp-field-mapping>
                                <field-name>playerId</field-name>
                                <column-name>PLAYEREJB.PLAYERID</column-name>
                        </cmp-field-mapping>
                        <cmp-field-mapping>
                                <field-name>name</field-name>
                                <column-name>PLAYEREJB.NAME9</column-name>
                        </cmp-field-mapping>
                        <cmp-field-mapping>
                                <field-name>salary</field-name>
                                <column-name>PLAYEREJB.SALARY</column-name>
                        </cmp-field-mapping>
                        <cmr-field-mapping>
                                <cmr-field-name>teams</cmr-field-name>
                                <column-pair>
                                        <column-name>PLAYEREJB.PLAYERID</column-name>
                                        <column-name>PLAYEREJBTEAMEJB.PLAYEREJB_PLAYERID</column-name>
                                </column-pair>
                                <column-pair>
                                        <column-name>PLAYEREJBTEAMEJB.TEAMEJB_TEAMID</column-name>
                                        <column-name>TEAMEJB.TEAMID</column-name>
                                </column-pair>
                                <fetched-with>
                                        <none/>
                                </fetched-with>
                        </cmr-field-mapping>
                </entity-mapping>
                <entity-mapping>
                        <ejb-name>LeagueEJB</ejb-name>
                        <table-name>LEAGUEEJB</table-name>
                        <cmp-field-mapping>
                                <field-name>leagueId</field-name>
                                <column-name>LEAGUEEJB.LEAGUEID</column-name>
                        </cmp-field-mapping>
                        <cmp-field-mapping>
                                <field-name>name</field-name>
                                <column-name>LEAGUEEJB.NAME9</column-name>
                        </cmp-field-mapping>
                        <cmp-field-mapping>
                                <field-name>sport</field-name>
                                <column-name>LEAGUEEJB.SPORT</column-name>
                        </cmp-field-mapping>
                        <cmr-field-mapping>
                                <cmr-field-name>teams</cmr-field-name>
                                <column-pair>
                                        <column-name>LEAGUEEJB.LEAGUEID</column-name>
                                        <column-name>TEAMEJB.LEAGUEEJB_LEAGUEID</column-name>
                                </column-pair>
                                <fetched-with>
                                        <none/>
                                </fetched-with>
                        </cmr-field-mapping>
                </entity-mapping>
        </nec-cmp-mapping>
</nec-cmp-mappings>

4.3. アプリケーションクライアント

appclientコマンドはアプリケーションクライアントコンテナを起動し、JARファイルにパッケージされたクライアントアプリケーション(クライアントアプリケーションJarファイル) を実行するために使用します。クライアントアプリケーションJarファイルは統合運用管理ツールや、otxadmin deployコマンドによる配備時に作成されます。 WebOTX Developerからも作成可能です。

アプリケーションクライアントコンテナとは、Java仮想マシン(JVM)上で動く第1層アプリケーションクライアントの実行に必要なJavaのクラスや ライブラリ、その他ファイルの集まりのことです。アプリケーションクライアントコンテナはRMI-IIOPを利用してWebOTXと通信を行います。

クライアントアプリケーションJarファイルは配備記述子(application-client.xml)を含む必要があります。 配備記述子から指定することにより、環境エントリ、EJB参照やリソース参照を使用することができます。詳しくはJava 2 Platform Enterprise Edition Specification, v1.4 の10章を参照してください。

4.3.1. 使用方法

appclient -client appjar [-mainclass appClass-name|-name display-name] [-xml xml] [-noauth | -textauth] [-jndiurl JNDI server URL] [-appcpath specify class search path like java -classpath] [-nodesc] [アプリケーション引数]

4.3.1.1. オプションの説明

オプション 説明
-client クライアントアプリケーションJarファイルの名前と場所を指定します。このオプションは必須です。
-mainclass アプリケーションクライアントコンテナが起動させるmain()メソッドを持つクラスの完全なクラス名を指定します。指定しない場合はマニフェストに書かれたMain-Classの値が使用されます。 クラス名はcom.nec.test.AppClientのように完全に書く必要があります。
-name クライアントアプリケーションの表示名を指定します。表示名とはapplication-client.xmlのdisplay-name 要素で指定された名前のことです。複数のクライアントアプリケーションJarの入ったEARファイルに対し、どのJarを起動するかを指定する際に使用します。
-xml クライアントコンフィグレーションXMLファイルの名前と場所を指定します。指定しない場合は、(WebOTXディレクトリ)/config/asenv.conf(Windowsの場合は asenv.bat)のAS_ACC_CONFIGの値が使用されます。
-noauth ログインを行ないません。-noauth、-textauthどちらも指定しない場合はGUIからログインを行います。
-textauth テキストベースのログインを行います。-noauth、-textauthどちらも指定しない場合はGUIからログインを行います。
-jndiurl JNDIサーバのURLを指定します。
-jndiurl rmiiiop://jndiserver
-appcpath クライアントアプリケーションの実行に必要なクラスを含むJarファイルのパスを指定します。javaコマンドの-classpathオプションと同じように指定してください。

表4.3.1.1

4.3.1.2. 使用例

> appclient -client client.jar -appcpath /usr/lib/mylib1.jar;mylib2.jar -jndiurl rmiiiop://host2 test

4.3.2. クラスパスの指定

appclientからクライアントアプリケーションを起動する際に、実行に必要なクラスを含むJarファイルのパスを指定する方法は 2つあります。1つは前述の-appcpathオプションです。もう1つはAPPCPATH環境変数です。javaコマンドにおけるCLASSPATH環境変数と同様に指定します。

-appcpathオプションとAPPCPATH環境変数は同時に使用できますが、その場合注意すべき点があります。クラスローダの階層構造の関係により、 APPCPATHで指定されたJarのクラスから、-appcpathで指定されたJarのクラスを参照しようとすると、ロードに失敗します。 逆(つまり、-appcpathで指定されたJarのクラスから、APPCPATH環境変数で指定されたJarのクラスへの参照)については問題ありません。

同様に、APPCPATH環境変数で指定されたJarのクラスから-clientで指定されたクライアントアプリケーションJarファイル内のクラスを参照することもできません

4.3.3. アプリケーションが使用するJNDIサーバの指定方法

-jndiurlオプションが指定された場合、オプションの引数に指定されたURLで示されるJNDIサーバを使用します。

-jndiurlオプションが指定されていない場合、クライアントコンフィグレーションXMLファイルのtarget-server 要素で指定されたJNDIサーバを使用します。

クライアントコンフィグレーションXMLファイルの設定を用いる場合、必ずrmiiiop形式のJNDIサーバ指定になります。 corbaname形式のJNDIサーバ指定を行いたい場合は、-jndiurlオプションを使用してください。

4.3.4. アプリケーションクライアントのJava VMオプション

環境変数"VMARGS"に指定された値が、アプリケーションクライアントのJava VMオプションとして使われます。