4. EJBアプリケーション

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

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

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

WebOTXのCMPサポート
コンテナ管理による永続性(CMP)マッピング
リソースマネージャの設定方法
EJB1.1ファインダークエリ設定方法
CMPの最適化

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

4.1.1. WebOTXのCMPサポート

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

EJB 2.1仕様で定義されている、トランザクションにおけるコミットオプションBとC
CMPを使用するBeanを含むEJB JARファイルのための配備記述子を生成する、オブジェクト／リレーショナル(O/R)マッピングツール
複合(複数の列を持つ)主キー
高度なカスタムファインダーメソッド
スタンダード準拠のクエリ言語(EJB QL)

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

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

マッピング配備記述子ファイル
マッピングの機能
自動マッピングのオプション
マッピングでサポートしているデータ型
BLOBサポート
CLOBサポート
データベーススキーマの自動キャプチャ
キャプチャスキーマユーティリティの使用法

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

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

ejb-jar.xml: コンテナに管理されるBeanと、Beanのトランザクション属性に関する情報を含みます。
nec-ejb-jar.xml: Enterprise Beanをアセンブルするのに用いられる、WebOTX独自の設定ファイルです。
nec-cmp-mappings.xml: CMPマッピングのためのファイルです。このファイルは自動的に作成可能で、配備の前に準備しておく必要はありません。詳しくは[ 4.2. nec-cmp-mappings.xmlファイル ]を参照してください。

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によって提供されるマッピングの機能とは以下のとおりです。

単一または複数のテーブルへのCMP Beanマッピング
単一または複数のカラムへのCMPフィールドマッピング
様々な型のカラムへのCMPフィールドマッピング
複合した主キーを持つテーブルへのマッピング
外部キーカラムへのリレーションを持つCMPマッピング
主キーと外部キーをオーバーラップしたテーブルのマッピング

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

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

配備時にテーブルを作成する
配備解除時にテーブルを削除する
再配備時にテーブルを削除し作成する
データベースベンダを指定する
ユニークなテーブル名を指定する
個別のCMPフィールドのマッピングのタイプを指定する

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データ型は以下のとおりです。

BIGINT
BIT
BLOB
CHAR
CLOB
DATE
DECIMAL
DOUBLE
FLOAT
SMALLINT
LONGVARBINARY
LONGVARCHAR
NUMERIC
REAL
SMALLINT
TIME
TIMESTAMP
TINYINT
VARCHAR

以下の表は推奨された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ファインダークエリ設定方法

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

JDOQLクエリについて
クエリフィルタ式
クエリパラメータ
クエリ変数

4.1.4.1. JDOQLクエリについて

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

フィルタ式：Javaに似た式により、クエリによって返却されるそれぞれのオブジェクトの状態を指定します。EJB QLでのWHERE節に対応するものです。
クエリパラメータ宣言：1つ以上のクエリ入力パラメータの名前とタイプを指定します。 Java言語における仮引数の構文に従います。クエリ変数は結合の実装のためのフィルタに使われる可能性があります。
クエリ並び順宣言：クエリの並び順式を指定します。EJBQLのORDER BY節に相当します。

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

query-filter
query-params
query-variables
query-ordering

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

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

4.1.4.2. クエリフィルタ式

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

プリミティブ型とラッパクラスのインスタンスとの同値比較、大小比較は有効です。
DateフィールドとDateパラメータの同値比較、大小比較は有効です。
StringフィールドとStringパラメータの同値比較は有効です。
ホワイトスペース(スペース、タブ、キャリッジリターン、ラインフィード)は分割文字であり、その他は無視されます。
以下の代入演算子はサポートされません
- =,+=など
- 前置、または後置インクリメント
- 前置、または後置デクリメント
オブジェクト作成を含むメソッドはサポートされません。ただし以下を除きます
- Collection.contains(Object o)
- Collection.isEmpty()
- String.startsWith(String s)
- String.endsWith(String e)
くわえてWebOTXは以下の標準的ではないJDOQLメソッドをサポートします。
- String.like(String pattern)
- String.like(String pattern, char escape)
- String.substring(int start, int length)
- String.indexOf(String str), String.indexOf(String str, int start)
- String.length()
- Math.abs(numeric n), and Math.sqrt(double d)
null値フィールドを通過するナビゲーションは、NullPointerExceptionをスローし、副式はfalseを返すように扱われるでしょう。

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

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

Java言語の中で定義されているすべての型へ適用される演算子
- 関係演算子(==, !=, >, <, >=, <=)
- 論理演算子(&, &&, |, ||, ~, !)
- 算術演算子(+, -, *, /)
文字列の結合は String + String のみサポートします。
演算の順序を明示する為の括弧
キャスト演算子
数値オペランド
比較と数値演算のための数値オペランドの型の昇格。これはJava言語の昇格のルールに従います。(詳しくはJava language specification)BigDecimal, BigInteger, そして数値ラッパクラスにも拡張されます。

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ファイルのサンプルを提示します。

nec-cmp-mappings.xmlファイルのXML要素
データベーススキーマ定義のサンプル
nec-cmp-mappings.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の階層構造を表しています。

nec-cmp-mappings
- nec-cmp-mapping
  - entity-mapping
  - schema

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オプションとして使われます。