WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド
|
 |
 |
|
以下の節では、weblogic 固有の XML 文書型定義 (DTD) ファイル、weblogic-ejb-jar.xml ファイルの EJB 2.0 デプロイメント記述子要素について説明します。これらの定義を使用して、EJB デプロイメントを構成する WebLogic 固有の weblogic-ejb-jar.xml ファイルを作成します。
EJB 1.1 デプロイメント記述子要素については、「EJB 1.1 ユーザへの重要な情報」を参照してください。
XML ファイルの内容および要素の配置は、使用する各ファイルの文書型定義 (DTD) に従っている必要があります。WebLogic Server では、XML デプロイメント ファイルの DOCTYPE ヘッダ内部に埋めこまれた DTD は無視され、代わりにサーバと一緒にインストールされた DTD の場所が使用されます。ただし、DOCTYPE ヘッダ情報には、パーサ エラーを避けるために有効な URL 構文を指定する必要があります。
XML デプロイメント ファイルの編集、作成時に、各デプロイメント ファイルに対して正しい DOCTYPE ヘッダを指定することが重要です。特に、DOCTYPE ヘッダ内部に不正な PUBLIC 要素を使用すると、原因究明が困難なパーサ エラーになることがあります。
このヘッダは、デプロイメント記述子の文書型定義 (DTD) ファイルの場所およびバージョンを表します。このヘッダは外部 URL の java.sun.com を参照していますが、WebLogic Server には独自の DTD ファイルが用意されているので、ホスト サーバがインターネットにアクセスする必要はありません。ただし、この要素の DTD のバージョンはデプロイメント記述子のバージョンの識別に使用されるので、<!DOCTYPE...> 要素を weblogic-ejb-jar.xml ファイルおよび weblogic-cmp-jar.xml ファイルに含めて、外部 URL を参照させる必要があります。
XML の解析ツール (appc など) でヘッダ情報が不正な XML ファイルを解析すると、次のようなエラー メッセージが表示されることがあります。
WebLogic Server 固有の weblogic-ejb-jar.xml ファイルの PUBLIC 要素に適切なテキストは、表 A-1 に WebLogic Server のバージョン別で示してあります。
表 A-1 weblogic-ejb-jar.xml の PUBLIC 要素
WebLogic Server 固有の weblogic-cmp-jar.xml ファイルのPUBLIC要素に適切なテキストは、表 A-2 に WebLogic Server のバージョン別で示してあります。
表 A-2 weblogic-cmp-jar.xml の PUBLIC 要素
weblogic-cmp-jar.xml ファイルの詳細については、「weblogic-cmp-jar.xml デプロイメント記述子のリファレンス」を参照してください。
Sun Microsystems 固有の ejb-jar.xml ファイルの PUBLIC 要素に適切なテキストは、表 A-3 にエンタープライズ JavaBean のバージョン別で示してあります。
|
|
||
|
|
WebLogic Server の weblogic-ejb-jar.xml デプロイメント記述子ファイルには、WebLogic Server 固有の要素を記述します。
WebLogic Server 8.1 の weblogic-ejb-jar.xml の最上位要素は次のとおりです。
descriptionweblogic-versionweblogic-enterprise-beanejb-name
WebLogic Server 8.1 では、weblogic-ejb-jar.xml に対して以下の変更が加えられました。
False を持つように変更された。
weblogic-ejb-jar.xml の要素のこのリストには、WebLogic Server 8.1 のサービス パックでサポートされていたすべての要素が含まれています。前節「WebLogic Server 8.1 での weblogic-ejb-jar.xml の変更点」では、WebLogic Server 8.1 またはそれ以降のサービス パックで追加、変更、または非推奨化された要素がリストされています。
ステートフル セッション 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 コンテナはトランザクションをロールバックします。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>
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 (デフォルト) に設定します。通常、この設定によって不要な更新を防ぐことができるため、パフォーマンスが向上します。ただし、データベース トランザクション内のデータベース更新の順序は保持されません。
データベースがアイソレーション レベルとして TransactionReadCommittedUncommitted を使用している場合は、進行中のトランザクションに関する中間結果を他のデータベースのユーザに表示することもできます。この場合、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>
<dscription>親要素の説明</description>
WebLogic Server JNDI ツリーにデプロイされている実際の JMS キューまたはトピックにメッセージ駆動型 Bean を関連付けるために使用する JNDI 名を指定します。
「message-driven-descriptor」を参照してください。
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 の値の組み合わせによって指定されます。
maxConcurrentMDBs = Min(max-beans-free-pool, default-thread-pool-size/2+1).
デフォルトのスレッド プールで実行される MDB では、同時実行性がスレッド プール サイズの半分に 1 つを追加したものに制限されています。これにより、他のサービス、およびデフォルト スレッド プールを共有するアプリケーションとのデッドロックが回避されます。
<dispatch-policy>queue_name</dispatch-policy>
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 デプロイメント ファイル内に配置する参照です。
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>
</reference-descriptor>
デフォルトでは、EJB 実装クラスは他の EJB クラスと同じクラスローダにロードされます。enable-bean-class-redeploy 要素が有効化されていると、実装クラスは、スーパー クラスと共に、EJB モジュール クラスローダの子クラスローダにロードされます。これにより、EJB 実装クラスは EJB モジュール全体を再デプロイしなくても再デプロイできるようになります。
Bean クラスを子クラスローダにロードすると、いくつかの問題が発生する可能性があります。まず、Bean クラスが親クラスローダにロードされたどのクラスからも見えなくなってしまうため、これらのクラスが Bean クラスを参照できなくなったり、エラーが発生したりします。また、Bean クラスは別のクラスローダにロードされたクラスに対しては、パッケージ保護されたメソッドを呼び出せなくなります。したがって、Bean クラスが同じパッケージ内のヘルパー クラスを呼び出した場合、ヘルパー クラス メソッドは public として宣言する必要があります。そうしないと、IllegalAccessErrors が発生します。
注意 : この機能を有効化するには、2 フェーズ デプロイメントの使用が必要です。2 フェーズ デプロイメントが使われていないと、WebLogic Server は、enable-bean-class-redeploy 設定を無視します。2 フェーズ デプロイメントについては、『WebLogic Server アプリケーションのデプロイメント』の「2 フェーズ デプロイメント プロトコル」を参照してください。
次の XML スタンザでは、単独の Bean クラスの再デプロイメントが可能です。
<enable-bean-class-redeploy>True</enable-bean-class-redeploy>
enable-call-by-reference が False の場合、EJB メソッドのパラメータは EJB がリモートから呼び出されるか、同じ EAR から呼び出されるかに関係なくコピーされます (または値で渡される)。
注意 : false, に設定しても、次の目的で使用する場合は call-by-reference が使用されます:
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.0 CMP Bean を使用しているときのみ使えます。
<enable-dynamic-queries>True</enable-dynamic-queries>
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 スタンザの構造を示します。
<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-servside-stubs>True</use-servside-stubs>
</entity-clustering>
エンティティ Bean に適用する以下のデプロイメント パラメータを指定します。
poolentity-cache (または entity-cache-ref)persistenceentity-clusteringinvalidation-targetenable-dynamic-queries<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 要素のセットの代わりに、指示を行うプレースホルダとして使用されます。
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>
global-role 要素は非推奨となっており、WebLogic の将来のバージョンでは削除される予定です。代わりに externally-defined 要素を使用してください。
global-role 要素は、セキュリティ レルム内で特定のセキュリティ ロールが「グローバルに」定義されていることを示します。セキュリティ ロールおよびその principal-name のマッピングが別のところで定義されているため、principal-name はデプロイメント記述子内では指定されません。このタグは、principal-name 要素のセットの代わりに、指示を行うプレースホルダとして使用されます。
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 のキャッシュとパッシベーション」を参照してください。
idle-timeout-seconds は entity-cache スタンザで使用しますが、WebLogic Server 8.1 SP1 と SP2 では、エンティティ EJB のライフサイクルの管理にその値を使用しません。それらのサービス パックでは、idle-timeout-seconds はエンティティ Bean がいつキャッシュから削除されるのかに影響を与えません。weblogic-ejb-jar.xml デプロイメント記述子の <entity-cache> でタグを介して指定された個々のエンティティ Bean キャッシュでは、<concurrency-strategy> が Database、ReadOnly Optimistic、または Exclusive のいずれかに設定されているエンティティ Bean に限り、既存の <idle-timeout-seconds> 要素が有効化されます。 次のエントリでは、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>
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>
EJB の転送の整合性の要件を指定します。integrity 要素を使用すると、クライアントとサーバ間で、データが途中で変化することなく転送されるようになります。
「transport-requirements」を参照してください。
コンテナ管理による永続性エンティティ EJB が変更された場合に、無効化する読み込み専用エンティティ EJB を指定します。
対象の ejb-name は読み込み専用エンティティ EJB でなければならないので、この要素は EJB 2.0 のコンテナ管理による永続性エンティティ 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.0 仕様に基づく 2.0 CMP エンティティ EJB では不要ですが、BMP および 1.1 CMP の EJB では有効です。コンテナ管理の永続性を使用して EJB 2.0 エンティティ Bean をデプロイする場合、WebLogic Server によって、変更されている EJB フィールドが自動的に検出され、そのフィールドのみが基底のデータストアに書き込まれます。
<entity-descriptor>
<persistence>
<is-modified-method-name>semidivine</is-modified-method-name>
</persistence>
</entity-descriptor>
EJB のメソッドレベルのトランザクション アイソレーション設定を定義します。有効な値は以下のとおり。
TRANSACTION_SERIALIZABLE - このトランザクションを同時に複数回実行すると、トランザクションを順番に複数回実行することと同じことになります。TRANSACTION_READ_COMMITTED - トランザクションはコミットされた他のトランザクションの更新だけを参照できます。TRANSACTION_READ_UNCOMMITTED - トランザクションはコミットしていない他のトランザクションの更新を参照できます。TRANSACTION_REPEATABLE_READ - トランザクションでデータの一部を読み取ると、そのデータが他のトランザクションで変更されても、最初の読み取り時と同じ値が返されます。以下の追加の値は、Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされています。
TRANSACTION_READ_COMMITTED_FOR_UPDATE - Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされています。この値を使用すると、アイソレーション レベルは TRANSACTION_READ_COMMITTED に設定され、トランザクションの間、メソッドで実行される SQL SELECT 文はすべて FOR UPDATE が付加されて実行されます。この結果、隔離された行が更新用にロックされます。Oracle でクエリの影響を受ける行をすぐにロックできない場合は、それらの行が解放されるまで待ちします。この状況は、トランザクションで COMMIT または ROLLBACK が実行されるまで続きます。このアイソレーション レベルを使用すると、次のエラーを防止できます。
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
このエラーは、Oracle データベースで TRANSACTION_SERIALIZABLE アイソレーション レベルを使用したときに発生します。
TRANSACTION_READ_COMMITTED_FOR_UPDATE_NO_WAIT - Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされています。 この値を使用すると、アイソレーション レベルは TRANSACTION_READ_COMMITTED に設定され、トランザクションの間、メソッドで実行される SQL SELECT 文はすべて FOR UPDATE NO WAIT が付加されて実行されます。この結果、選択された行が更新用にロックされます。
TRANSACTION_READ_COMMITTED_FOR_UPDATE 設定とは違って、必要なときロックがすぐに達成されない場合、TRANSACTION_READ_COMMITTED_FOR_UPDATE_NO_WAIT では 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 リンクの使用」を参照してください。
「resource-description」および「ejb-reference-description」を参照してください。
Bean のローカル ホームの JNDI 名。Bean がリモート ホームとローカル ホームを持つ場合は、それぞれのホームに 1 つずつの JNDI 名を割り当てることもできます。
<local-jndi-name>weblogic.jndi.WLInitialContext</local-jndi-name>
メモリの許容範囲内で、このクラスのオブジェクトの最大数を指定します。max-bean-in-cache の値に達すると、WebLogic Server では、最近クライアントに使用されていない EJB の一部に対してパッシベーションが行われます。また、「ステートフル セッション EJB のキャッシュとパッシベーション」で説明されているように、max-beans-in-cache の値は、EJB を WebLogic Server のキャッシュからいつ削除するかにも影響を与えます。
注意 :使用可能なメモリ量と必要なメモリ量を正しく評価してください。極端に大きい値を max-beans-in-cache パラメータに割り当てると、OutOfMemoryError が発生する可能性があります。必要なメモリ キャッシュ量は、キャッシュに格納される Bean の数と EJB のサイズを掛けることで算出できます。
<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>
WebLogic Server は、すべてのエンティティ Bean、ステートレス セッション Bean、およびメッセージ駆動型 Bean クラスについて EJB のフリー プールを保持します。max-beans-in-free-pool 要素は、このフリー プールのサイズを定義します。
「pool」を参照してください。
メッセージ駆動型 Bean を WebLogic Server の JMS 送り先に関連付けます。
次の例では、message-driven-descriptor スタンザの構造を示します。
<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>
</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>
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>
エンティティ 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>
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>
ejb-jar.xml ファイル内の参照を、WebLogic Server で実際に使用可能なリソース ファクトリと EJB の JNDI 名にマップします。
reference-descriptor スタンザには、リソース ファクトリ参照および EJB 参照を定義するために 1 つまたは複数のスタンザが追加されます。次の例に、これらの要素の構造を示します。
<reference-descriptor>
<resource-description>
...
</resource-description>
<resource-env-description>
...
</resource-env-description>
<ejb-reference-description>
...
</ejb-reference-description>
<ejb-local-reference-description>
...
</ejb-local-reference-description>
</reference-descriptor>
リモート 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」を参照してください。
ejb-jar.xml に定義されているリソース参照を WebLogic Server 内に用意されている実際のリソースの JNDI 名にマップします。
<reference-descriptor>
<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>
</reference-descriptor>
ejb-jar.xml に定義されているリソース環境参照を WebLogic Server 内に用意されている実際のリソースの JNDI 名にマップします。
<reference-descriptor>
<resource-env-description>
<res-env-ref-name>. . .</res-env-ref-name>
<jndi-name>...</jndi-name>
<reference-env-description>
</reference-descriptor>
jndi-name が有効な URL でない場合、WebLogic Server はそれを URL に対応し、すでに JNDI ツリーにバインドされているオブジェクトとして取り扱い、LinkRef とその jndi-name をバインドします。
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-names の run-as-principal-names へのマッピングがどのようにして生じるかの説明は、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」パーミッションを与え、それが上書きされるのを防止するには、次の手順を行います。
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 コンテナがパッシベーションされたステートフル セッション 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-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-authorization>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 2.0 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-ejb-jar は、EJB デプロイメント記述子の weblogic コンポーネントのルート要素です。
|
|
|