|
以下の節では、WebLogic 固有のデプロイメント記述子である weblogic-ejb-jar.xml
の要素について説明します。このリリースの WebLogic Server では、weblogic-ejb-jar.xml
は XML スキーマ (XSD) に基づいています。旧リリースでは、weblogic-ejb-jar.xml
は文書型定義 (DTD) に基づいていました。下位互換性を保持するために、このリリースの WebLogic Server は XSD ベースと DTD ベースの EJB 記述子をサポートしています。また、このリリースでは、EJB コンテナは従来の DTD ベースの記述子もすべてサポートしているので、DTD ベースのデプロイメント記述子を使用するアプリケーションも記述子を変更せずにデプロイできます。
weblogic-ejb-jar.xml
に必要な XML スキーマ定義とネームスペース宣言、および文書型定義と DOCTYPE ヘッダについては、「デプロイメント記述子スキーマおよび文書型定義リファレンス」を参照してください。weblogic-cmp-jar.xml
については、「weblogic-cmp-jar.xml デプロイメント記述子のリファレンス」を参照してください。
WebLogic Server の weblogic-ejb-jar.xml
デプロイメント記述子ファイルには、WebLogic Server 固有の要素を記述します。
WebLogic Server の weblogic-ejb-jar.xml
の最上位要素は次のとおりです。
description
weblogic-enterprise-bean
ejb-name
以下の weblogic-ejb-jar.xml
要素のリストには、このリリースの WebLogic Server でサポートされているすべての要素が含まれています。このリリースの WebLogic Server で追加、変更、または非推奨になった要素については、こちらを参照してください。
ステートフル セッション Bean インスタンスがメソッドの同時呼び出しを許可するかどうかを指定します。デフォルトでは、EJB の仕様に従って allows-concurrent-calls
は False
であり、ステートフル セッション Bean のインスタンスでメソッド呼び出しを処理しているときにまた別の (同時) メソッド呼び出しがサーバに到着すると WebLogic Server から RemoteException
が送出されます。
True
に設定すると、EJB コンテナはメソッドの同時呼び出しをブロックするため、前の呼び出しが完了してから次のメソッドが呼び出されるようになります。
「stateful-session-descriptor」を参照してください。
ステートフル セッション Bean の remove
メソッドをトランザクション コンテキスト内で呼び出すことができることを指定します。
注意 : | Synchronization インタフェースを実装しているステートフル セッション Bean では、このタグを使用し、その後トランザクション終了前に remove を呼び出すことがないようにしてください。それが行われた場合、EJB コンテナは同期コールバックを呼び出しません。 |
「stateful-session-descriptor」を参照してください。
以前の db-is-shared
要素に相当し、EJB コンテナがエンティティ Bean の永続データをトランザクション間でキャッシュするかどうかを指定します。
EJB コンテナによるデータの長期キャッシングの実行を有効にする場合、True
を指定します。EJB コンテナによるデータの短期キャッシングの実行を有効にする場合、False
を指定します。
読み込み専用 Bean の場合、WebLogic Server はこれの長期キャッシングを常に実行するので、cache-between-transactions
要素の値は無視されます。
詳細については、「cache-between-transactions によるデータベース読み込みの制限 (長期キャッシング)」を参照してください。
「persistence」を参照してください。
EJB がキャッシュから削除される順番を指定します。値は次のとおりです。
NRU の最小キャッシュ サイズは 8 です。max-beans-in-cache が 3 より小さい場合、WebLogic Server では max-beans-in-cache
の値に 8 が使用されます。
<stateful-session-cache><cache-type>NRU</cache-type>
</stateful-session-cache>
EJB がクライアント認証をサポートするか、または、必要とするかを指定します。
「iiop-security-descriptor」を参照してください。
EJB が転送レベルでのクライアント証明書認証をサポートするか、または、必要とするかを指定します。
「transport-requirements」を参照してください。
EJB がデプロイされた際、WebLogic Server がこの EJB に JNDI の通知を送るかどうかが指定されます。この属性が False
(デフォルト) の場合、WebLogic Server クラスタでは、ある特定のサーバ上にあるこの EJB の場所を示すために、自動的に JNDI ツリーを更新します。これにより、そのクライアントが同じサーバ上で連結されてなくても、すべてのクライアントがこの EJB にアクセスできるようになります。
EJB にアクセスするクライアントのすべてが、その Bean がデプロイされているのと同じサーバ上からアクセスすることが分かっている場合には、clients-on-same-server
を True
に設定できます。この場合、EJB がデプロイされる際、WebLogic Server クラスタは JNDI の通知をこの EJB に送信しません。クラスタ内の JNDI の更新ではマルチキャスト トラフィックが利用されるため、clients-on-same-server
を True
に設定することにより大容量のクラスタでの起動時間を短縮できます。
連結された EJB の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「連結されたオブジェクトの最適化」を参照してください。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
...
<clients-on-same-server>True</clients-on-same-server>
</weblogic-enterprise-bean>
コンテナがエンティティ Bean への同時アクセスを管理する方法を指定します。以下の 4 つの値のいずれかに設定します。
Exclusive
を指定すると、Bean がトランザクションに関連付けられている場合、WebLogic Server はキャッシュされたエンティティ EJB インスタンスを排他的にロックする。EJB インスタンスに対する要求は、トランザクションが完了するまでブロックされます。このオプションは、WebLogic Server 3.1 ~ 5.1 までのデフォルトのロック動作です。Database
を設定すると、WebLogic Server はエンティティ EJB に対する要求のロックを基底のデータストアに委ねる。Database
同時方式では、WebLogic Server は、独立したエンティティ Bean インスタンスを割り当て、ロックとキャッシングをデータベースが処理できるにようにします。これは現在のデフォルト オプションです。ReadOnly
は、読み込み専用エンティティ Bean で使用される。複数の要求が並行して処理されるように各トランザクションで新しいインスタンスをアクティブ化します。WebLogic Server は、read-timeout-seconds
パラメータに基づいて ReadOnly
Bean の ejbLoad()
を呼び出します。Optimistic
では、トランザクションの間に EJB コンテナまたはデータベースでロックを行わない。EJB コンテナは、トランザクションをコミットする前に、あるトランザクションが更新したデータが変化していないことを確かめます。更新データのどれかが変わっていた場合、EJB コンテナはトランザクションをロールバックします。注意 : | concurrency-strategy が Optimistic である Bean がクラスタにデプロイされており、クラスタのメンバーがその Bean を更新した場合、EJB コンテナは、クラスタ内のすべてのサーバに存在するその Bean のすべてのコピーを無効にしようとします。この動作を無効にするには、weblogic-cmp-jar.xml の cluster-invalidation-disabled を True に設定します。詳細については、「クラスタ内のオプティミスティックな同時方式の無効化オプション」を参照してください。 |
Exclusive
および Database
のロック動作の詳細については、「同時方式の選択」を参照してください。read-only
エンティティ Bean の詳細については、「読み書き対応エンティティ Bean と読み込み専用エンティティ Bean」を参照してください。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<concurrency-strategy>ReadOnly</concurrency-strategy>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>
EJB における転送の機密性の要件を指定します。confidentiality
要素を使用すると、他のエンティティに内容を見られることなく、クライアントとサーバ間でデータが送信されるようになります。
「transport-requirements」を参照してください。
メッセージ駆動型 EJB がキューとトピックを作成するためにルックアップする JMS 接続ファクトリの JNDI 名を指定します。「送り先を考慮した MDB のコンフィグレーション」および「connection-factory-jndi-name の設定方法」を参照してください。
<message-driven-descriptor><connection-factory-jndi-name>
java:comp/env/jms/MyConnectionFactory
</connection-factory-jndi-name>
</message-driven-descriptor>
ejb-jar.xml
に定義されている JMS モジュール内のリソースを WebLogic Server の実際の JMS モジュール参照にマップします。
WebLogic Server 8.1 SP01 で導入され、本来は ejbCreate
が匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。
create-as-principal-name
が設定されている場合
そのプリンシパルを使用します。
あるいは
ejb-jar.xml
で Bean に対して run-as
ロールが指定されている場合
run-as-role-assignment
を設定するためのルールに従ってプリンシパルを使用します。
あるいは
ejbCreate
を匿名プリンシパルとして実行します。
create-as-principal-name
要素は、ejbCreate
内の処理が匿名プリンシパルよりも高レベルのパーミッションを必要とする場合にのみ指定する必要があります。
この要素は、ステートレス セッション Bean とメッセージ駆動型 Bean の ejbCreate
メソッドに影響します。
「remove-as-principal-name」、「passivate-as-principal-name」、および「principal-name」も参照してください。
トランザクションの完了時にトランザクションですべての Bean の永続ストレージを更新するには、delay-updates-until-end-of-tx
要素を True
(デフォルト) に設定します。通常、この設定によって不要な更新を防ぐことができるため、パフォーマンスが向上します。ただし、データベース トランザクション内のデータベース更新の順序は保持されません。
データベースがアイソレーション レベルとして TransactionReadUncommitted
を使用している場合は、進行中のトランザクションに関する中間結果を他のデータベースのユーザに表示することもできます。この場合、delay-updates-to-end-of-tx
を False
に設定して、各メソッド呼び出しの完了時に Bean の永続ストレージを更新するように指定します。詳細については、「ejbLoad() と ejbStore() の動作について」を参照してください。
注意 : | delay-updates-until-end-of-tx を False に設定しても、各メソッド呼び出しの後にデータベース更新が「コミットされた」状態になるわけではありません。更新はデータベースに送信されるだけです。更新は、トランザクションの完了時にのみデータベースにコミットまたはロールバックされます。 |
<entity-descriptor><persistence>
...
...
<delay-updates-until-end-of-tx>False</delay-updates-until-end-of-tx>
</persistence>
</entity-descriptor>
<description>Contains a description of parent element</description>
WebLogic Server JNDI ツリーにデプロイされている実際の JMS キューまたはトピックにメッセージ駆動型 Bean を関連付けるために使用する JNDI 名を指定します。
「message-destination-descriptor」および「message-driven-descriptor」を参照してください。
ejb-jar.xml
に定義されている JMS モジュール内のリソースを WebLogic Server の実際の JMS モジュール参照にマップします。
ID を指定した警告メッセージを WebLogic Server が無効化するように指定します。以下の 4 つの値のいずれかに設定します。
BEA-010001
- 警告メッセージ「EJB class loaded from system classpath during deployment.」を無効化する。BEA-010054
- 警告メッセージ「EJB class loaded from system classpath during compilation.」を無効化する。BEA-010200
- 警告メッセージ「EJB impl class contains a public static field, method or class.」を無効化する。BEA-010202
- 警告メッセージ「Call-by-reference not enabled.」を無効化する。
警告メッセージ「Call-by-reference not enabled」を無効にするには、次のように <disable-warning> を設定します。
<disable-warning>BEA-010202</disable-warning>
EJB が実行されるべきスレッド プールをどのサーバが実行するかを指定します。ディスパッチ ポリシーは、エンティティ、セッション、メッセージ駆動型など、すべての種類の Bean でサポートされています。
dispatch-policy
が指定されていないか、指定された dispatch-policy
が存在しないサーバ実行スレッド プールを参照していた場合、代わりにサーバのデフォルトの実行スレッド プールが使用されます。
WebLogic Server は、対応する名前を持つ実行スレッド キューがホスト サーバ インスタンスになければ、dispatch-policy
を無視します。
メッセージ駆動型 Bean (MDB) が外部の (WebLogic 以外の) 送り先ソースによって駆動されている場合、MDB は外部プロバイダのスレッド メカニズムで実行される可能性があるので、WebLogic Server は dispatch-policy
を無視することがあります。たとえば、IBM WebSphere MQSeries メッセージング ソフトウェアの場合、dispatch-policy
は非トランザクション キューについては対応されていません。アプリケーション コードは MQSeries スレッド内で実行されます。MQSeries トランザクション キュー、および非トランザクションとトランザクションの両トピックにおいては、dispatch-policy
は受け付けられます。
同時に実行中の MDB インスタンスの最大数は、max-beans-in-free-pool と dispatch-policy
の値の組み合わせによって指定されます。『WebLogic Server パフォーマンス チューニング ガイド』の「MDB スレッド管理」を参照してください。
<dispatch-policy>queue_name</dispatch-policy>
WebLogic Server 9.0 で導入された要素で、MDB がアンデプロイまたは削除されるときに恒久トピック サブスクリプションが自動的に削除されるようにするかどうかを指定します。
<durable-subscription-deletion>True</durable-subscription-deletion>
Bean が ejb-local-ref
要素で参照する WebLogic Server インスタンスの EJB の JNDI 名をマップします。
<ejb-local-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-local-reference-description>
ejb-jar.xml
で指定された同じ名前を使用して、エンタープライズ Bean の名前を指定します。エンタープライズ Bean のコードは名前に左右されないので、アプリケーション アセンブリ処理中に名前を変更してもエンタープライズ Bean の機能には影響しません。デプロイメント記述子の ejb-name
と、デプロイヤがエンタープライズ Bean のホームに割り当てる JNDI 名との間には、構築された関係はありません。
注意 : | weblogic-enterprise-bean では推奨されていません。詳細については、「EJB リンクの使用」を参照してください。 |
「method」を参照してください。
WebLogic Server の EJB の JNDI 名を、ejb-jar.xml
の ejb-ref-name
要素でそれを指定するのに使われる名前にマップします。
<ejb-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>
リソース参照名を指定します。この要素は、EJB プロバイダが ejb-jar.xml
デプロイメント ファイル内に配置する参照です。
<ejb-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>
デフォルトでは、EJB 実装クラスは他の EJB クラスと同じクラスローダにロードされます。enable-bean-class-redeploy
要素が有効化されていると、実装クラスは、スーパー クラスと共に、EJB モジュール クラスローダの子クラスローダにロードされます。これにより、EJB 実装クラスは EJB モジュール全体を再デプロイしなくても再デプロイできるようになります。
Bean クラスを子クラスローダにロードすると、いくつかの問題が発生する可能性があります。まず、Bean クラスが親クラスローダにロードされたどのクラスからも見えなくなってしまうため、これらのクラスが Bean クラスを参照できなくなったり、エラーが発生したりします。また、Bean クラスは別のクラスローダにロードされたクラスに対しては、パッケージ保護されたメソッドを呼び出せなくなります。したがって、Bean クラスが同じパッケージ内のヘルパー クラスを呼び出した場合、ヘルパー クラス メソッドは public として宣言する必要があります。そうしないと、IllegalAccessErrors
が発生します。
次の XML 要素では、単独の Bean クラスの再デプロイメントが可能です。
<enable-bean-class-redeploy>True</enable-bean-class-redeploy>
enable-call-by-reference
が False
の場合、EJB メソッドのパラメータは EJB がリモートから呼び出されるか、同じ EAR から呼び出されるかに関係なくコピーされます (または値で渡される)。
enable-call-by-reference
が True
の場合、同じ EAR ファイル内またはスタンドアロンの JAR ファイルから呼び出された EJB メソッドは引数を参照で渡します。パラメータはコピーされないので、これによってメソッド呼び出しのパフォーマンスが向上します。
注意 : | メソッドのパラメータは、EJB がリモートで呼び出されたときには常に値で渡されます。 |
<weblogic-enterprise-bean><entity-descriptor>
<ejb-name>AccountBean</ejb-name>
...
<enable-call-by-reference>False</enable-call-by-reference>
</entity-descriptor>
</weblogic-enterprise-bean>
True
に設定すると、動的クエリが有効になります。動的クエリは、EJB 2.x CMP Bean を使用している場合にのみ使用できます。
<enable-dynamic-queries>True</enable-dynamic-queries>
WebLogic Server 9.0 で導入された要素で、エンティティ Bean が常にトランザクションを使用しなければならないかどうかを指定します。WebLogic Server 9.0 より前では、エンティティ Bean が不特定のトランザクションで動作している場合、EJB コンテナはそのエンティティ Bean のトランザクションを作成しました。現在は、エンティティ Bean が不特定のトランザクションで動作している場合、EJB コンテナはトランザクションを作成しません。この動作を無効にし、EJB コンテナが不特定のトランザクションで動作するエンティティ Bean のトランザクションを作成するようにする場合、この要素の値を True
に設定します。
WebLogic Server 内のエンティティ EJB インスタンスのキャッシュに使用する以下のオプションを定義します。
詳細については、「エンティティのキャッシングについて」を参照してください。
<entity-descriptor>
<entity-cache>
<max-beans-in-cache>...</max-beans-in-cache>
<idle-timeout-seconds>...</idle-timeout-seconds>
<read-timeout-seconds>...<read-timeout-seconds>
<concurrency-strategy>...</concurrency-strategy>
</entity-cache>
<persistence>...</persistence>
<entity-clustering>...</entity-clustering>
</entity-descriptor>
エンティティ Bean が使用する、アプリケーション レベルのエンティティ キャッシュを参照します。アプリケーション レベルのキャッシュは、同じアプリケーション内の複数エンティティ Bean によって共有されるキャッシュです。entity-cache-name
で指定する値は、weblogic-application.xml
ファイルでアプリケーション レベルのエンティティ キャッシュに当てた名前と一致させる必要があります。
weblogic-application.xml
ファイルの詳細については、『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。
「entity-cache-ref」を参照してください。
同じアプリケーションに属する複数のエンティティ Bean のインスタンスをキャッシュできるアプリケーション レベルのエンティティ キャッシュを表します。アプリケーション レベルのエンティティ キャッシュは、weblogic-application.xml
ファイルで宣言されます。
concurrency-strategy を使用し、その Bean に使用させたい同時方式のタイプを定義します。同時方式はアプリケーション レベル キャッシュのキャッシュ戦略と適合していなくてはなりません。たとえば、
Exclusive
キャッシュは、concurrency-strategy
が Exclusive
である Bean だけをサポートします。MultiVersion
キャッシュは、Database
、ReadOnly
、および Optimistic
同時方式をサポートします。
<entity-cache-ref>
<entity-cache-name>AllEntityCache</entity-cache-name>
<read-timeout-seconds>600</read-timeout-seconds>
<cache-between-transactions>true</cache-between-transactions>
<concurrency-strategy>ReadOnly</concurrency-strategy>
<estimated-bean-size>20</estimated-bean-size>
</entity-cache-ref>
エンティティ Bean が WebLogic クラスタでどのようにレプリケートされるのかを指定します。
<entity-clustering>
<home-is-clusterable>True</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
<home-call-router-class-name>beanRouter</home-call-router-
class-name>
<use-serverside-stubs>True</use-serverside-stubs>
</entity-clustering>
エンティティ Bean に適用する以下のデプロイメント パラメータを指定します。
<entity-descriptor>
<entity-cache>...</entity-cache>
<persistence>...</persistence>
<entity-clustering>...</entity-clustering>
<invalidation-target>...</invalidation-target>
<enable-dynamic-queries>...</enable-dynamic-queries>
</entity-descriptor>
エンティティ Bean のインスタンスの推定平均サイズ (バイト単位) を指定します。各インスタンスが消費するメモリのバイト数の平均値です。
estimated-bean-size
要素は、Bean をキャッシュするのに使用する、アプリケーション レベルのキャシュがともにバイト数や MB 単位で指定されている場合に併せて使用します。
エンティティ Bean インスタンスが消費する正確なバイト数が分からなくても、サイズを指定することにより、ある一時点でキャッシュを共有する Bean に対し相対的な重みを与えることができます。
たとえば、Bean A と Bean B が 1000 バイトのキャッシュを共有し、A のサイズが 10 バイト、B のサイズが 20 バイトであるとします。その場合、キャッシュに格納できるのは、最大で、A のインスタンスで 100、B のインスタンスで 50 です。A のインスタンスが 100 個キャッシュされた場合、B のインスタンスは 0 個キャッシュされたことになります。
「entity-cache-ref」を参照してください。
特定のセキュリティ ロールが、デプロイメント記述子の外の、セキュリティ レルム内で外部定義されていることを示します。セキュリティ ロールおよびその principal-name のマッピングが別のところで定義されているため、principal-name はデプロイメント記述子内では指定されません。このタグは、principal-name
要素のセットの代わりに、指示を行うプレースホルダとして使用されます。この要素は、非推奨になって WebLogic Server 9.0 で削除されたグローバル ロールの代わりに使用します。
CMP エンティティ EJB でのみ有効です。finders-load-bean
は、ファインダ メソッドの呼び出しによって Bean への参照が返されてから WebLogic Server が EJB をキャッシュにロードするかどうかを指定します。この要素を True
に設定した場合、Bean への参照がファインダによって返されると、WebLogic Server はすぐにその Bean をキャッシュにロードします。この要素を False
に設定した場合、WebLogic Server は、最初のメソッドが呼び出されるまで Bean を自動的にロードしません。この動作は、EJB 1.1 の仕様と一致しています。
<entity-descriptor>
<persistence>
<finders-load-bean>True</finders-load-bean>
</persistence>
</entity-descriptor>
EJB コンテナが MDB のインスタンスごとにユニークなクライアント ID を生成するかどうかを指定します。これにより、恒久 MDB を WebLogic Server の複数のサーバ インスタンスに簡単にデプロイできるようになります。
global-role
要素は非推奨となっており、WebLogic Server 9.0 で削除されました。代わりに externally-defined 要素を使用してください。
Bean のメソッド呼び出しのルーティングに使用するカスタム クラスの名前を指定します。このクラスは weblogic.rmi.cluster.CallRouter()
を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼び出しの前に呼び出されます。ルータ クラスでは、メソッドのパラメータを基に、ルーティングするサーバを選択できます。このクラスは、サーバ名を返すか、または現在のロード アルゴリズムがサーバを選択する必要があることを示す null を返します。
「entity-clustering」および「stateful-session-clustering」を参照してください。
home-is-clusterable
が True
の場合、クラスタ内の複数の WebLogic Server から EJB をデプロイできます。ホーム スタブの呼び出しは、Bean がデプロイされるサーバ間で負荷が分散されます。Bean のホスト サーバにアクセスできなかった場合、呼び出しは、Bean を提供する他のサーバに自動的にフェイルオーバします。
「entity-clustering」を参照してください。
クラスタ内の EJB ホームのレプリカ間のロード バランシングに使用するアルゴリズムを指定します。この要素を定義しない場合、WebLogic Server はサーバ要素、weblogic.cluster.defaultLoadAlgorithm
で指定されたアルゴリズムを使用します。
home-load-algorithm
は以下のいずれかの値に定義できます。
round-robin
- Bean のホスト サーバ間で順番にロード バランシングを実行する。random
- Bean のホスト サーバ間で EJB ホームのレプリカがランダムにデプロイされる。weight-based
- ホスト サーバの現在の負荷に従って、EJB ホームのレプリカをデプロイするサーバが決まる。round-robin-affinity
- サーバ アフィニティが外部 Java クライアントとサーバ インスタンスの接続を管理し、ラウンドロビン ロード バランシングがサーバ インスタンス間の接続に使用される。weight-based-affinity
- サーバ アフィニティが外部 Java クライアントとサーバ インスタンスの接続を管理し、重みベース ロード バランシングがサーバ インスタンス間の接続に使用される。random-affinity
- サーバ アフィニティが外部 Java クライアントとサーバ インスタンスの接続を管理し、ランダム ロード バランシングがサーバ インスタンス間の接続に使用される。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「EJB と RMI オブジェクトのロード バランシング」を参照してください。
「entity-clustering」および「stateful-session-clustering」を参照してください。
同じメソッドを同じ引数で繰り返し呼び出したとしても、1 回呼び出したときとまったく同じ結果になるように記述される、クラスタ化された EJB のメソッドのリストを定義します。これにより、フェールオーバ ハンドラは、失敗したサーバ上で実際に呼び出しがコンパイルされるかどうかを知らなくても、失敗した呼び出しを再試行できるようになります。あるメソッドに対し多重呼び出し不変メソッドを有効にした場合、EJB スタブは、EJB のホスト サーバに接続できるかぎり、あらゆる失敗から自動的に回復することができます。
EJB でクラスタリングが有効である必要があります。クラスタ化を有効にするには、「entity-clustering」、「stateful-session-clustering」、および「stateless-clustering」を参照してください。
ステートレス セッション Bean ホームおよび読み込み専用エンティティ Bean のメソッドは、自動的に多重呼び出し不変に設定されます。これらについては多重呼び出し不変を明示的に設定する必要はありません。
<idempotent-method>
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
</idempotent-method>
EJB が ID アサーションをサポートするか、または、必要とするかを指定します。
「iiop-security-descriptor」を参照してください。
EJB がキャッシュに保持される最長時間を定義します。この時間を過ぎると、キャッシュ内の Bean の数が max-beans-in-cache
で指定した値を超えている場合、WebLogic Server では Bean インスタンスが削除されます。削除された Bean インスタンスに対してはパッシベーションが行われます。詳細については、「ステートフル セッション EJB のキャッシュとパッシベーション」および「エンティティ Bean のプールとキャッシュの管理」を参照してください。
また、フリー プール内の EJB が削除されるまでの最長アイドル時間を定義します。この時間の経過後、WebLogic Server は Bean の数が initial-beans-in-free-pool の値を下回らない限り、その Bean をフリー プールから削除します。
注意 : | idle-timeout-seconds は entity-cache 要素で使用しますが、WebLogic Server 8.1 SP1 と SP2 では、エンティティ EJB のライフサイクルの管理にその値を使用しません。それらのサービス パックでは、idle-timeout-seconds はエンティティ Bean がいつキャッシュから削除されるのかに影響を与えません。 |
次のエントリでは、max-beans-in-cache
の値に達し、Bean がキャッシュに 20 分保持されている場合、ステートフル セッション EJB AccountBean
が削除の対象になります。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<stateful-session-descriptor>
<stateful-session-cache>
<max-beans-in-cache>200</max-beans-in-cache>
<idle-timeout-seconds>1200</idle-timeout-seconds>
</stateful-session-cache>
</stateful-session-descriptor>
</weblogic-enterprise-bean>
Bean レベルのセキュリティ コンフィグレーション パラメータを指定します。これらのパラメータにより、IOR に含まれる IIOP セキュリティ情報が決定します。
<iiop-security-descriptor>
<transport-requirements>...</transport-requirements>
<client-authentication>supported<client-authentication>
<identity-assertion>supported</identity-assertion>
</iiop-security-descriptor>
EJB コンテナが JMS リソースの停止を検出したときに MDB の JMS 接続を中断する初期秒数を指定します。詳細については、「JMS リソース停止中のメッセージ配信の中断のコンフィグレーション」を参照してください。
initial-beans-in-free-pool
の値を指定する場合は、プールの初期サイズを設定することになります。WebLogic Server は起動時に、Bean クラスごとに指定された数の Bean インスタンスをフリー プールに格納します。この方法で Bean インスタンスをフリー プールに格納しておくと、要求が来てから新しいインスタンスを生成せずに Bean に対する初期要求が可能になるため、EJB の初期応答時間が短縮されます。
「pool」を参照してください。
JMS プロバイダが初期コンテキストの作成に使用する初期コンテキスト ファクトリを指定します。「送り先を考慮した MDB のコンフィグレーション」および「initial-context-factory の設定方法」を参照してください。
<message-driven-descriptor>
<initial-context-factory>fiorano.jms.rtl.FioranoInitialContextFactory
</initial-context-factory>
</message-driven-descriptor>
「message-destination-descriptor」を参照してください。
EJB の転送の整合性の要件を指定します。integrity
要素を使用すると、クライアントとサーバ間で、データが途中で変化することなく転送されるようになります。
「transport-requirements」を参照してください。
コンテナ管理による永続性エンティティ EJB が変更された場合に、無効化する読み込み専用エンティティ EJB を指定します。
対象の ejb-name
は読み込み専用エンティティ EJB でなければならないので、この要素は EJB 2.x のコンテナ管理による永続性エンティティ EJB に対してのみ指定できます。
<invalidation-target>
<ejb-name>StockReaderEJB</ejb-name>
</invalidation-target>
EJB の保存時に WebLogic Server によって呼び出されるメソッドを指定します。指定したメソッドはブール値を返す必要があります。メソッドを指定しない場合、WebLogic Server では、EJB は常に変更されていると見なされて保存されます。
メソッドを指定して適切な値を設定すると、EJB 1.1 準拠の Bean、および Bean 管理の永続性を使用する Bean のパフォーマンスが向上します。ただし、メソッドの戻り値にエラーがあると、データに矛盾が発生する場合があります。
注意 : | isModified() は、EJB 2.x 仕様に基づく 2.x CMP エンティティ EJB では必要ありません。しかし、BMP および 1.1 CMP EJB には引き続き適用されます。コンテナ管理の永続性を使用して EJB 2.x エンティティ Bean をデプロイする場合、WebLogic Server によって、変更されている EJB フィールドが自動的に検出され、そのフィールドのみが基底のデータストアに書き込まれます。 |
<entity-descriptor>
<persistence>
<is-modified-method-name>semidivine</is-modified-method-name>
</persistence>
</entity-descriptor>
EJB のメソッドレベルのトランザクション アイソレーション設定を定義します。有効な値は以下のとおりです。
TransactionSerializable
- このトランザクションを同時に複数回実行すると、トランザクションを順番に複数回実行することと同じことになる。注意 : | Oracle データベースの場合は、TransactionSerializable アイソレーション レベルの代わりに TransactionReadCommittedForUpdate アイソレーション レベルを使用することをお勧めします。Oracle データベースは、TransactionSerializable アイソレーション レベルではデータの読み取りをロックしないためです。また、TransactionSerializable アイソレーション レベルでは、Oracle データベースに対する現在のトランザクションが、Oracle 例外 ORA-08177「このトランザクションのアクセスをシリアル化できません 」を送出せずに続行することが可能です。TransactionReadCommittedForUpdate アイソレーション レベルの詳細については、「Oracle のみのアイソレーション レベル」を参照してください。 |
TransactionReadCommitted
- コミットした他のトランザクションの更新のみをトランザクションで表示できる。TransactionReadUncommitted
- コミットしていない他のトランザクションの更新をトランザクションで表示できる。TransactionRepeatableRead
- トランザクションでデータの一部を読み取ると、そのデータが他のトランザクションで変更されても、最初の読み取り時と同じ値が返される。
以下の追加の値は、Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされています。
TransactionReadCommittedForUpdate
- Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされる。この値を使用すると、アイソレーション レベルは TransactionReadCommitted
に設定され、トランザクションの間、メソッドで実行される SQL SELECT
文はすべて FOR UPDATE
が付加されて実行されます。この結果、隔離された行が更新用にロックされます。Oracle でクエリの影響を受ける行をすぐにロックできない場合は、それらの行が解放されるまで待ちます。この状況は、トランザクションで COMMIT
または ROLLBACK
が実行されるまで続きます。
このアイソレーション レベルを使用すると、次のエラーを防止できます。
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
このエラーは、Oracle データベースで TransactionSerializable
アイソレーション レベルを使用したときに発生することがあります。
注意 : | Oracle データベースの場合は、TransactionSerializable アイソレーション レベルの代わりにこのアイソレーション レベル (TransactionReadCommittedForUpdate ) を使用することをお勧めします。Oracle データベースは、TransactionSerializable アイソレーション レベルではデータの読み取りをロックしないためです。 |
TransactionReadCommittedForUpdateNoWait
- Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされる。
この値を使用すると、アイソレーション レベルは TransactionReadCommitted
に設定され、トランザクションの間、メソッドで実行される SQL SELECT
文はすべて FOR UPDATE NO WAIT が付加されて実行されます。この結果、選択された行が更新用にロックされます。
TransactionReadCommittedForUpdate
設定とは違って、必要なときロックがすぐに達成されない場合、TransactionReadCommittedForUpdateNoWait
では Oracle DBMS が NOT WAIT
になります。このため、影響を受ける SELECT
クエリは失敗し、コンテナから例外が送出されます。
異なるアイソレーション レベルのサポートの詳細については、各データベースのドキュメントを参照してください。
「transaction-isolation」を参照してください。
JMS 送り先に接続するときの MDB のクライアント ID を指定します。JMS トピックに対する恒久サブスクリプションで必須です。
connection-factory-jndi-name で MDB が使用する接続ファクトリを指定した場合、クライアント ID は config.xml
内の関連付けられている JMSConnectionFactory
要素の ClientID
要素で定義できます。
config.xml
の JMSConnectionFactory
で ClientID
を指定しないか、デフォルト接続ファクトリを使用する (connection-factory-jndi-name を指定しない) 場合、メッセージ駆動型 Bean は jms-client-id
値をそのクライアント ID として使用します。
<jms-client-id>MyClientID</jms-client-id>
JMS 送り先に再接続しにいく間隔の秒数を指定します。各メッセージ駆動型 Bean は、関連付けられている JMS 送り先でリスンします。JMS 送り先が別の WebLogic Server インスタンスまたは外部 JMS プロバイダに配置されている場合には、JMS 送り先にアクセスできなくなることもあります。この場合、EJB コンテナは自動的に JMS サーバに再接続しようとします。JMS サーバが再び起動した時点で、メッセージ駆動型 Bean は再びメッセージを受信できるようになります。
<jms-polling-interval-seconds>5</jms-polling-interval-seconds>
WebLogic Server で使用可能な実際の EJB、リソース、または参照の JNDI 名を指定します。
注意 : | JNDI 名を Bean に割り当てるのは望ましくありません。グローバル JNDI 名は、クラスタ化されたサーバの起動時に大量のマルチキャスト トラフィックを引き起こします。より適切なプラクティスについては、「EJB リンクの使用」を参照してください。 |
注意 : | EJB を含む EAR ライブラリがある場合、JNDI 名の衝突が起きるため、そのライブラリを参照するアプリケーションを複数デプロイすることはできません。これは、EAR ライブラリ内の個々の EJB に対してグローバル JNDI 名を設定できないからです。グローバル JNDI 名はライブラリ全体に対してのみ設定できます。 |
「resource-description」および「ejb-reference-description」を参照してください。
Bean のローカル ホームの JNDI 名です。Bean がリモート ホームとローカル ホームを持つ場合は、それぞれのホームに 1 つずつの JNDI 名を割り当てることもできます。
注意 : | JNDI 名を Bean に割り当てるのは望ましくありません。より適切なプラクティスについては、「EJB リンクの使用」を参照してください。 |
<local-jndi-name>weblogic.jndi.WLInitialContext
</local-jndi-name>
メモリの許容範囲内で、このクラスのオブジェクトの最大数を指定します。max-bean-in-cache
の値に達すると、WebLogic Server では、最近クライアントに使用されていない EJB の一部に対してパッシベーションが行われます。また、「ステートフル セッション EJB のキャッシュとパッシベーション」で説明されているように、max-beans-in-cache
の値は、EJB を WebLogic Server のキャッシュからいつ削除するかにも影響を与えます。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<max-beans-in-cache>200</max-beans-in-cache>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>
MDB のトランザクションに入れることができるメッセージの最大数を指定します。
WebLogic Server は、すべてのエンティティ Bean、ステートレス セッション Bean、およびメッセージ駆動型 Bean クラスについて EJB のフリー プールを保持します。max-beans-in-free-pool
要素は、このフリー プールのサイズを定義します。
「pool」を参照してください。
WebLogic Server 9.0 で導入された要素です。Bean レベルでキャッシュできる読み込み専用エンティティ クエリの最大数を指定します。アプリケーション レベルでの読み込み専用エンティティ クエリのキャッシュについては、
EJB コンテナが JMS リソースの停止を検出したときに MDB の JMS 接続を中断する最大秒数を指定します。EJB コンテナが JMS リソースの停止を検出したときに JMS 接続が中断しないようにするには、この要素の値を 0
に設定します。詳細については、「JMS リソース停止中のメッセージ配信の中断のコンフィグレーション」を参照してください。
ejb-jar.xml
ファイル内のメッセージ送り先の参照を、WebLogic Server の実際のメッセージ送り先 (JMS キュー、トピックなど) にマップします。
<message-destination-descriptor>
<message-destination-name>...</message-destination-name>
<destination-jndi-name>...</destination-jndi-name>
<resource-link>...</resource-link>
<initial-context-factory>...</initial-context-factory>
<provider-url>...</provider-url>
</message-destination-descriptor>
メッセージ定義参照の名前を指定します。これは、EJB プロバイダによって ejb-jar.xml
デプロイメント記述子ファイル内に記載される参照です。
「message-destination-descriptor」を参照してください。
メッセージ駆動型 Bean を WebLogic Server の JMS 送り先に関連付けます。
<message-driven-descriptor>
<pool>...</pool>
<destination-jndi-name>...</destination-jndi-name>
<initial-context-factory>...</initial-context-factory>
<provider-url>...</provider-url>
<connection-factory-jndi-name>...</connection-factory-jndi-name>
<jms-polling-interval-seconds>...</jms-polling-interval-seconds>
<jms-client-id>...</jms-client-id>
<generate-unique-jms-client-id>...</generate-unique-jms-client-id>
<durable-subscription-deletion>...</durable-subscription-deletion>
<max-messages-in-transaction>...</max-messages-in-transaction>
</message-driven-descriptor>
エンタープライズ Bean のホームまたはリモート インタフェースのメソッドあるいはメソッドのセットを定義します。
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
WebLogic Server がアイソレーション レベルのプロパティを適用する EJB のインスタンスを指定します (メソッドが複数のインタフェースで同じシグネチャを持つ場合)。
「method」を参照してください。
WebLogic Server がアイソレーション レベルのプロパティを適用する個々の EJB メソッドの名前を指定します。アスタリスク (*) を使用すると EJB のホームおよびリモート インタフェースの全メソッドを指定できます。
method-name
を指定する場合、そのメソッドは指定の ejb-name
になければなりません。
「method」を参照してください。
メソッド パラメータの完全修飾 Java タイプ名を指定します。
「method-params」を参照してください。
各メソッド パラメータの Java タイプ名を定義する 1 つまたは複数の要素があります。
method-params
要素には、次のように 1 つまたは複数の method-param
要素が含まれます。
<method-params>
<method-param>java.lang.String</method-param>
...
</method-params>
EJB でネットワーク通信に使用されるカスタム ネットワークを割り当てます。ネットワーク チャネルによって、一連の接続属性が定義されます。詳細については、『WebLogic Server 環境のコンフィグレーション』の「ネットワーク リソースのコンフィグレーション」を参照してください。
<weblogic-enterprise-bean>
<network-access-point>SSLChannel</network-access-point></weblogic-enterprise-bean>
WebLogic Server 8.1 SP01 で導入された passivate-as-principal-name
要素は、本来は ejbPassivate
が匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。
passivate-as-principal-name
が設定されている場合
そのプリンシパルを使用します。
あるいは
ejb-jar.xml
で Bean に対して run-as
ロールが指定されている場合
run-as-role-assignment
を設定するためのルールに従ってプリンシパルを使用します。
あるいは
ejbPassivate
を匿名プリンシパルとして実行します。
passivate-as-principal-name
要素は、ejbPassivate
内の処理が匿名プリンシパルよりも高レベルのパーミッションを必要とする場合にのみ指定する必要があります。
この要素は、キャッシュのタイムアウトでパッシベーションが行われたときにステートレス セッション Bean の ejbPassivate
メソッドに影響します。
「remove-as-principal-name」、「create-as-principal-name」、および「principal-name」も参照してください。
コンテナ管理の永続性サービスを使用するエンティティ EJB でのみ必須です。persistence
要素は、WebLogic Server のエンティティ EJB に対する永続性タイプ、トランザクション コミット動作、ejbLoad()
動作、および ejbStore()
動作を決定するプロパティを定義します。
<entity-descriptor>
<persistence>
<is-modified-method-name>...</is-modified-method-name>
<delay-updates-until-end-of-tx>...</delay-updates-until-end-of-tx>
<finders-load-beand>...</finders-load-bean>
<persistence-use>...</persistence-use>
</persistence>
</entity-descriptor>
コンテナ管理の永続性サービスを使用するエンティティ EJB でのみ必須です。persistence-use
要素は、この特定の Bean に使用する永続性タイプの識別子を格納します。
<persistence-use>
<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
<type-version>5.1.0</type-version>
<type-storage>META-INF/weblogic-cmp-jar.xml</type-storage>
</persistence-use>
パッシベーションされたステートフル セッション Bean インスタンスの状態を WebLogic Server が格納するファイル システム ディレクトリを指定します。詳細については、「パッシベーションされた Bean の永続ストア ディレクトリの指定」を参照してください。
<stateful-session-descriptor>
<stateful-session-cache>...</stateful-session-cache>
<allow-concurrent-calls>...</allow-concurrent-calls>
<persistent-store-dir>MyPersistenceDir</persistent-store-dir>
<stateful-session-clustering>...</stateful-session-clustering>
<allow-remove-during-transaction>
</stateful-session-descriptor>
WebLogic Server がタイマー オブジェクトを格納する、サーバのファイル システム上の永続ストアの名前を指定します。この要素で永続ストアの名前を指定しない場合、タイマー オブジェクトはデフォルト ストアに格納されます。
エンティティ EJB、ステートレス セッション EJB、およびメッセージ駆動型 EJB の WebLogic Server フリー プールの動作をコンフィグレーションします。オプションは以下のとおりです。
<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>500</max-beans-in-free-pool>
<initial-beans-in-free-pool>250</initial-beans-in-free-pool>
</pool>
</stateless-session-descriptor>
指定した role-name
に適用される実際の WebLogic Server プリンシパルの名前を指定します。security-role-assignment 要素に少なくとも 1 つの principal-name
が必要です。各 role-name に対して複数の principal-name
を定義することもできます。
「security-role-assignment」を参照してください。
InitialContext
で使用される URL を指定します。「送り先を考慮した MDB のコンフィグレーション」および「provider-url の設定方法」を参照してください。
<message-driven-descriptor><provider-url>WeblogicURL:Port</provider-url>
</message-driven-descriptor>
「message-destination-descriptor」を参照してください。
Read-Only
エンティティ Bean で ejbLoad
を呼び出す間隔の秒数を指定します。値を 0 にすると、WebLogic Server は Bean がキャッシュに送られたときだけ ejbLoad()
を呼び出します。
次の例では、インスタンスが最初にキャッシュされた場合にのみ WebLogic Server が AccountBean
クラスのインスタンスに対して ejbLoad()
を呼び出します。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<read-timeout-seconds>0</read-timeout-seconds>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>
リモート RMI クライアントがタイムアウトするまでの待機時間を指定します。『WebLogic RMI プログラマーズ ガイド』の「RMI タイムアウトの使用」を参照してください。
以下のエントリの場合、リモート RMI クライアントは 5 秒待機してからタイムアウトします。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
...
<remote-client-timeout>5</remote-client-timeout>
</weblogic-enterprise-bean>
このパラメータは、ejbRemove
内の処理が匿名プリンシパル以上のパーミッションを必要とする場合にのみ指定する必要があります。
WebLogic Server 8.1 SP1 で導入された remove-as-principal-name
要素は、本来は ejbRemove
が匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。
remove-as-principal-name
が設定されている場合
そのプリンシパルを使用します。
あるいは
ejb-jar.xml
で Bean に対して run-as
ロールが指定されている場合
run-as-role-assignment
を設定するためのルールに従ってプリンシパルを使用します。
あるいは
ejbRemove
を匿名プリンシパルとして実行します。
remove-as-principal-name
要素は、ejbRemove
内の処理が匿名プリンシパルよりも高レベルのパーミッションを必要とする場合にのみ指定する必要があります。
この要素は、ステートレス セッション Bean とメッセージ駆動型 Bean の ejbRemove
メソッドに影響します。
「passivate-as-principal-name」、「create-as-principal-name」、および「principal-name」も参照してください。
クラスタ内の WebLogic Server インスタンスのステートフル セッション EJB の状態を WebLogic Server がレプリケートするかどうかを指定します。InMemory
を指定した場合、EJB の状態はレプリケートされます。None
を指定した場合、状態はレプリケートされません。
「stateful-session-clustering」を参照してください。
「resource-description」を参照してください。
resourcefactory
参照の名前を指定します。これは、EJB プロバイダによって ejb-jar.xml
デプロイメント記述子ファイル内に記載される参照です。EJB が ejb-jar.xml
のリソース参照を指定する場合にのみ必須になります。
「resource-description」を参照してください。
この MDB がメッセージを受け取るリソース アダプタを指定します。
ejb-jar.xml
に定義されているリソース参照を WebLogic Server 内に用意されている実際のリソースの JNDI 名にマップします。
<resource-description>
<res-ref-name>. . .</res-ref-name>
<jndi-name>...</jndi-name>
</resource-description>
<ejb-reference-description>
<ejb-ref-name>. . .</ejb-ref-name>
<jndi-name>. . .</jndi-name>
</ejb-reference-description>
ejb-jar.xml
に定義されているリソース環境参照を WebLogic Server 内に用意されている実際のリソースの JNDI 名にマップします。
<resource-env-description>
<res-env-ref-name>. . .</res-env-ref-name>
<jndi-name>...</jndi-name>
</reference-env-description>
jndi-name
が有効な URL でない場合、WebLogic Server はそれを URL に対応し、すでに JNDI ツリーにバインドされているオブジェクトとして取り扱い、LinkRef
とその jndi-name
をバインドします。
ejb-jar.xml
に定義されている JMS モジュール内のリソースを WebLogic Server の実際の JMS モジュール参照にマップします。
「message-destination-descriptor」を参照してください。
|
|||
EJB コンテナが、ロールバックされたコンテナ管理によるトランザクション メソッドを自動的に再試行する回数を指定します。
ここで指定したメソッドに対して、EJB コンテナはロールバックされたコンテナ管理によるトランザクションを自動的に再試行します。自動的なトランザクションの再試行は、コンテナ管理のトランザクションの境界設定を使用するセッション Bean およびエンティティ Bean について、サポートされています。また、この要素で指定されたメソッドに関わらず、EJB コンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。
EJB プロバイダが ejb-jar.xml
デプロイメント記述子に指定したアプリケーションのロール名を示します。要素の次の principal-name 要素で、WebLogic Server プリンシパルを、指定した role-name
にマップします。
「security-role-assignment」を参照してください。
注意 : | run-as-identity-principal 要素は、このリリースの WebLogic Server では非推奨となりました。代わりに run-as-principal-name を使用します。 |
run-as-identity-principal
要素は、ejb-jar.xml
デプロイメント記述子で、セキュリティ ID run-as-role-name
を指定した Bean の run-as プリンシパルとして使用されるセキュリティ プリンシパル名を指定します。
run-as role-name の run-as-identity-principal または run-as-principal-name へのマッピングがどのようにして生じるかの説明は、run-as-role-assignment 要素のコメントを参照してください。
<run-as-identity-principal>Fred
</run-as-identity-principal>
ejb-jar.xml
デプロイメント記述子で、security-identity
run-as role-name
を指定した Bean の run-as プリンシパルとして使用されるセキュリティ プリンシパル名を指定します。
run-as role-name
の run-as-principal-name
へのマッピングがどのようにして生じるかの説明は、run-as-role-assignment 要素のコメントを参照してください。
<run-as-principal-name>Fred
</run-as-principal-name>
ejb-jar.xml
デプロイメント記述子ファイルで指定された security-identity run-as role-name
を run-as-principal-name
にマップします。
ここで指定した特定の role-name に対する run-as-principal-name
の値は、ejb-jar.xml
デプロイメント記述子内のすべての Bean を対象とし、role-name を security-identitiy run-as-role-name
として指定したすべての Bean に適用されます。
ここで指定した run-as-principal-name
値は、その Bean の weblogic-enterprise-bean
要素の下で run-as-principal-name を指定することによって、個々の Bean レベルでオーバーライドできます。
注意 : | 特定の Bean について、run-as-role-assignment または Bean 固有の run-as-principal-name タグで run-as-principal-name が指定されていない場合、EJB コンテナは weblogic-enterprise-bean security-role-assignment のセキュリティ ユーザの最初の principal-name を role-name として選択し、その principal-name を run-as-principal-name として使用します。 |
ejb-jar.xml
デプロイメント記述子ファイルが、次のような状況であると仮定します。
対応するデプロイメント記述子ファイル weblogic-ejb-jar.xml
から抜粋した次のコードを検討してください。
<weblogic-ejb-jar><weblogic-enterprise-bean>
<ejb-name>
A_EJB_with_runAs_role_x
</ejb-name>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>
B_EJB_with_runAs_role_X
</ejb-name>
<run-as-principal-name>
Joe
</run-as-principal-name>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>
C_EJB_with_runAs_role_Y
</ejb-name>
</weblogic-enterprise-bean>
<security-role-assignment>
<role-name>
runAs_role_Y
</role-name>
<principal-name>
first_principal_of_role_Y
</principal-name>
<principal-name>
second_principal_of_role_Y
</principal-name>
</security-role-assignment>
<run-as-role-assignment>
<role-name>
runAs_role_X
</role-name>
<run-as-principal-name>
Fred
</run-as-principal-name>
</run-as-role-assignment>
</weblogic-ejb-jar>
各 Bean は、その run-as-principal-name
として異なるプリンシパル名を選択します。
この Bean の run-as-role-name は「runAs_role_X」です。使用するプリンシパルの名前のルックアップには、jar スコープの <run-as-role-assignment>
マッピングが使用されます。
<run-as-role-assignment>
マッピングにより、<role-name>
「runAs_role_X」に対して、<run-as-principal-name>
「Fred」を使用すべきであることが指定されます。
この Bean の run-as-role-name も「runAs_role_X」です。この Bean は使用するプリンシパルの名前のルックアップに jar スコープの <run-as-role-assignment>
を使用することはありません。なぜなら、この値はこの Bean の <weblogic-enterprise-bean> <run-as-principal-name>
値である「Joe」でオーバーライドされているからです。
この Bean の run-as-role-name は「runAs_role_Y」です。「runAs_role_Y」の run-as プリンシパル名としての明示的なマッピングはありません。つまり、「runAs_role_Y」に対する jar スコープの <run-as-role-assignment>
も、Bean スコープの <run-as-principal-name>
も、この Bean の weblogic-enterprise-bean
では指定されていません。
使用するプリンシパル名を決定するには、<role-name>
「runAs_role_Y」の <security-role-assignment>
を検証します。ユーザ (つまり、グループではない) に対応する最初の <principal-name>
が選択されます。
「first_principal_of_role_Y」が、使用されるプリンシパル名です。
J2EE Sandbox と関連するセキュリティ パーミッションを指定します。
詳細については、Sun によるセキュリティ パーミッション仕様の実装を参照してください。
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
<security-permission>
<description>任意指定の説明がここに入る</description>
<security-permission-spec>
...
</security-permission-spec>
</security-permission>
セキュリティ ポリシー ファイル構文に基づいて単一のセキュリティ パーミッションを指定します。
詳細については、Sun によるセキュリティ パーミッション仕様の実装を参照してください。
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
「java.vm.version」に「read」パーミッションを与え、それが上書きされるのを防止するには、次の手順に従います。
security-permission-spec
を設定します。
<security-permission>
<description>任意指定の説明がここに入る</description>
<security-permission-spec> grant { permission java.util.PropertyPermission "java.vm.version", "read"; };
</security-permission-spec>
</security-permission>
startWeblogic
スクリプトを修正します。
JAVA_OPTIONS=-Djava.security.manager
lib
という名前のディレクトリを作成します。 %WL_HOME%\server\lib\weblogic.policy
ファイルに追加します。
add grant codeBase "file:/<Your user_projects dir>/YourDomain/lib/-" { permission java.security.AllPermission; };
ejb-jar.xml
ファイルのアプリケーション ロールを WebLogic Server のセキュリティ プリンシパルの名前にマップします。
<security-role-assignment>
<role-name>PayrollAdmin</role-name>
<principal-name>Tanya</principal-name>
<principal-name>system</principal-name>
<externally-defined>True</externally-defined>
...
</security-role-assignment>
ejb-jar.xml
内の Web サービス送り先の参照を、WebLogic Server の実際の Web サービスにマップします。
<service-reference-description><service-ref-name>service/WebServiceBroker</service-ref-name>
<wsdl-url>http://@PROXY_SERVER@/webservice/
BrokerServiceBean?wsdl</wsdl-url>
<call-property>...</call-property>
<port-info>
<port-name>BrokerServiceIntfPort</port-name>
<stub-property>
<name>javax.xml.rpc.service.endpoint.address</name>
<value>http://@PROXY_SERVER@/webservice/BrokerServiceBean<;/value>
</stub-property>
</port-info>
</service-reference-description>
EJB コンテナがパッシベーションされたステートフル セッション Bean をどのくらいディスクに置いておくのかを指定します。コンテナは、Bean インスタンスをディスクにパッシベーションした後にパッシベーションされた EJB の session-timeout-seconds
を削除します。session-timeout-seconds
を指定しない場合、デフォルトは idle-timeout-seconds
で指定された値です。
<stateful-session-descriptor>
<stateful-session-cache>
<max-beans-in-cache>4</max-beans-in-cache> <idle-timeout-seconds>5</idle-timeout-seconds> <session-timeout-seconds>120</session-timeout-seconds>
<cache-type>LRU</cache-type>
</stateful-session-cache>
</stateful-session-descriptor>
ステートフル セッション EJB インスタンスのキャッシュに使用する以下のオプションを定義します。
ステートフル セッション Bean のキャッシュの詳細については、「ステートフル セッション EJB のキャッシュとパッシベーション」を参照してください。
次の例では、stateful-session-cache
要素の指定方法を示します。
<stateful-session-cache>
<max-beans-in-cache>...</max-beans-in-cache>
<idle-timeout-seconds>...</idle-timeout-seconds>
<session-timeout-seconds>...</session-timeout-seconds>
<cache-type>...</cache-type>
</stateful-session-cache>
WebLogic Server がクラスタ内のステートフル セッション EJB インスタンスをレプリケートする方法を決める以下のオプションを指定します。
<stateful-session-clustering><home-is-clusterable>True</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
<home-call-router-class-name>beanRouter</home-call-router-class-name>
<replication-type>InMemory</replication-type>
</stateful-session-clustering>
WebLogic Server のステートレス セッション EJB に対するキャッシュ、クラスタ化、および永続性などのデプロイメント動作を定義します。
<stateful-session-descriptor>
<stateful-session-cache>...</stateful-session-cache>
<allow-concurrent-calls>...</allow-concurrent-calls>
<allow-remove-during-transaction>...
</allow-remove-during-transaction>
<persistent-store-dir>/myPersistenceStore</persistent-store-dir>
<stateful-session-clustering>...</stateful-session-clustering>
</stateful-session-descriptor>
Bean のメソッド呼び出しのルーティングに使用するカスタム クラスの名前を指定します。このクラスは weblogic.rmi.cluster.CallRouter()
を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼び出しの前に呼び出されます。ルータ クラスでは、メソッドのパラメータを基に、ルーティングするサーバを選択できます。このクラスは、サーバ名を返すか、または現在のロード アルゴリズムがサーバを選択する必要があることを示す null を返します。
「stateless-clustering」を参照してください。
stateless-bean-is-clusterable
が True
の場合、EJB をクラスタ内の複数の WebLogic Server からデプロイできます。ホーム スタブの呼び出しは、Bean がデプロイされるサーバ間で負荷が分散されます。Bean のホスト サーバにアクセスできなかった場合、呼び出しは、Bean を提供する他のサーバに自動的にフェイルオーバします。
「stateless-clustering」を参照してください。
EJB ホームのレプリカ間のロード バランシングに使用するアルゴリズムを指定します。
stateless-bean-load-algorithm
を以下のいずれかの値で定義できます。
round-robin
- Bean のホスト サーバ間で順番にロード バランシングを実行する。random
- Bean のホスト サーバ間で EJB ホームのレプリカがランダムにデプロイされる。weight-based
- ホスト サーバの現在の負荷に従って、EJB ホームのレプリカをデプロイするサーバが決まる。round-robin-affinity
- サーバ アフィニティが外部 Java クライアントとサーバ インスタンスの接続を管理し、ラウンドロビン ロード バランシングがサーバ インスタンス間の接続に使用される。weight-based-affinity
- サーバ アフィニティが外部 Java クライアントとサーバ インスタンスの接続を管理し、重みベース ロード バランシングがサーバ インスタンス間の接続に使用される。random-affinity
- サーバ アフィニティが外部 Java クライアントとサーバ インスタンスの接続を管理し、ランダム ロード バランシングがサーバ インスタンス間の接続に使用される。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「EJB と RMI オブジェクトのロード バランシング」を参照してください。
「stateless-clustering」を参照してください。
注意 : | この要素はこのリリースでは非推奨になりました。 |
同一引数での同一メソッドの多重呼び出しが 1 回だけの呼び出しとまったく同じになるように設計されている Bean に対してのみ、stateless-bean-methods-are-idempotent
を True
に設定します。これによって、フェイルオーバ ハンドラは、失敗した呼び出しが失敗したサーバで実際に完了していたかどうかがわからなくても失敗した呼び出しを再試行できます。このプロパティを True
に設定すると、Bean を提供する他のサーバが使用できるようになっている限り、Bean スタブは障害から自動的に回復できます。
「stateless-clustering」を参照してください。
WebLogic Server がクラスタ内のステートレス セッション EJB インスタンスをレプリケートする方法を決めるオプションを指定します。
<stateless-clustering><stateless-bean-is-clusterable>
True
</stateless-bean-is-clusterable>
<stateless-bean-load-algorithm>
random</stateless-bean-load-algorithm>
<stateless-bean-call-router-class-name>
beanRouter
</stateless-bean-call-router-class-name>
<stateless-bean-methods-are-idempotent>
True
</stateless-bean-methods-are-idempotent>
</stateless-clustering>
WebLogic Server のステートレス セッション EJB に対するキャッシュ、クラスタ化、および永続性などのデプロイメント パラメータを定義します。
<stateless-session-descriptor>
<pool>...</pool>
<stateless-clustering>...</stateless-clustering>
</stateless-session-descriptor>
WebLogic Server のトランザクション動作を定義するオプションを指定します。現在、この要素には trans-timeout-seconds
という子要素だけがあります。
<transaction-descriptor>
<trans-timeout-seconds>20</trans-timeout-seconds>
</transaction-descriptor>
EJB のメソッドレベルのトランザクション アイソレーション設定を定義します。
<transaction-isolation>
<isolation-level>...</isolation-level>
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
</transaction-isolation>
詳細については、「isolation-level」を参照してください。
<iiop-security-descriptor>
<transport-requirements>
<confidentiality>supported</confidentiality>
<integrity>supported</integrity>
<client-cert-authentication>suppoted
</client-cert-authentication>
</transport-requirements>
</iiop-security-descriptor>
EJB のコンテナで初期化されたトランザクションの最長継続時間を指定します。トランザクションの継続時間が trans-timeout-seconds
の値を超えると、WebLogic Server によってトランザクションがロールバックされます。
「transaction-descriptor」を参照してください。
コンテナ管理の永続性サービスを使用するエンティティ EJB でのみ必須です。エンティティ EJB の永続性タイプを指定します。WebLogic Server RDBMS ベースの永続性では、WebLogic_CMP_RDBMS
という識別子を使用します。別の永続性ベンダを使用している場合の正しい type-identifier
についてはベンダのドキュメントを参照してください。
WebLogic Server RDBMS ベースの永続性に関する完全な永続性タイプの定義の例については、「persistence-use」を参照してください。
コンテナ管理の永続性サービスを使用するエンティティ EJB でのみ必須です。この永続性タイプのデータを格納するファイルの絶対パスを定義します。パスは、EJB のデプロイメント JAR ファイルまたはデプロイメント ディレクトリの最上位を基準にしたファイルの場所を指定する必要があります。
WebLogic Server RDBMS ベースの永続性では通常、Bean の永続性データを格納するのに weblogic-cmp-jar.xml
という XML ファイルを使用します。このファイルは、JAR ファイルの META-INF
サブディレクトリにあります。
WebLogic Server RDBMS ベースの永続性に関する完全な永続性タイプの定義の例については、「persistence-use」を参照してください。
同じ永続性タイプの複数バージョンがインストールされている場合に、コンテナ管理による永続性サービスを使用するエンティティ EJB の場合に必須です。指定した永続性タイプのバージョンを指定します。たとえば、WebLogic 1.1 CMP の永続性の場合は、次の値を使用します。
WebLogic 1.1 CMP の永続性の場合は、次の値を使用します。
この要素は、同じ永続性タイプの複数のバージョンがインストールされている場合に必須です。
WebLogic Server の RDBMS ベースの永続性を使用する場合、指定したバージョンは、WebLogic Server の RDBMS 永続性バージョンと完全に一致させる必要があります。バージョンが一致していないと、次のエラーが発生します。
weblogic.ejb.persistence.PersistenceSetupException: Error initializing the CMP Persistence Type for your bean: No installed Persistence Type matches the signature of (identifier `Weblogic_CMP_RDBMS', version `version_number').
WebLogic Server RDBMS ベースの永続性に関する完全な永続性タイプの定義の例については、「persistence-use」を参照してください。
Bean ホームがサーバのコンテキストでサーバサイド スタブを使用するようにします。
「entity-clustering」の例を参照してください。
WebLogic Server 9.0 で導入された要素で、互換性フラグを指定する要素が含まれます。
weblogic-ejb-jar
は、EJB デプロイメント記述子の weblogic コンポーネントのルート要素です。
WebLogic Server 内で利用可能な Bean に関するデプロイメント情報が含まれます。
EJB の作業要求を管理するワーク マネージャを指定します。
ワーク マネージャの詳細については、『WebLogic Server 環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。