| Oracle Containers for J2EEサービス・ガイド 10g（10.1.3.5.0） B56027-01 |
|
 戻る |
 次へ |
この章には、次の項目が含まれます。
Java Remote Method Invocation（RMI）を使用すると、分散Javaベース間アプリケーションを作成できます。この種のアプリケーションでは、リモートJavaオブジェクトのメソッドを、異なるホスト上にあるものも含め、他のJava仮想マシン（JVM）から起動できます。
OC4Jは、独自仕様のOracle Remote Method Invocation（ORMI）プロトコルを介したRMIと、標準のInternet Inter-ORB Protocol（IIOP）を介したRMIの両方をサポートします。RMI/ORMIを使用すると、OC4Jインスタンス内で稼働するオブジェクトを相互起動できます。RMI/IIOPを使用すると、異なるJ2EEコンテナ間（OC4JとBEA WebLogicサーバー間など）でオブジェクトを相互起動できます。
追加ドキュメント
次のサイトにあるHow-Toドキュメント「How-To Propagate a transaction context between OC4J instances」とZIPファイルには、ORMIを使用するOC4Jインスタンス間でのトランザクション・コンテキストの伝播に関する情報および使用例が含まれます。
次のサイトにあるHow-Toドキュメントでは、OC4Jの機能に関する追加情報（各機能の概要や機能に関連するコードの抜粋など）を提供しています。
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.html
RMI/ORMIとRMI/IIOPの選択基準は、次のとおりです。
OC4Jインスタンス内またはOC4Jインスタンス間でリモート・オブジェクトのメソッドを起動するには、RMI/ORMIを使用します。
詳細は、「Oracle Remote Method Invocation（RMI/ORMI）の使用方法」を参照してください。
OC4JとOracle以外のJ2EEコンテナ（BEA WebLogicなど）間でリモート・オブジェクトのメソッドを起動するには、RMI/IIOPを使用します。
詳細は、「ORMIからIIOPトランスポートへの切替え」を参照してください。
この項では、独自仕様のOracle RMI（ORMI）プロトコルを介したRemote Method Invocation（RMI）を使用して、Oracle Containers for J2EE（OC4J）のサーバー・インスタンス間でEJBなどのオブジェクトを相互起動できるようにするOC4Jのサポート機能について説明します。
この項には、次の項目が含まれます。
Oracle Remote Method Invocation（ORMI）は、OC4J用に最適化された、RMIプロトコルのOracle固有の実装です。
デフォルトでは、OC4Jサーバー・インスタンス内のEJBは、ORMIを介してRMIコールを交換します。かわりに、IIOPを介してRMIコールを交換するようEJBを変換して、異なるベンダーのEJBコンテナ間（OC4JとBEA WebLogicなど）でEJBを相互起動することも可能です。詳細は、「ORMIからIIOPトランスポートへの切替え」を参照してください。
|
注意: OC4J 10g（10.1.3.5.0）の実装では、ロード・バランシングとフェイルオーバーがサポートされるのはORMIの場合のみで、IIOPの場合はサポートされません。 |
ORMIはOC4J向けに拡張されており、次の機能が用意されています。
ORMIを使用すると、OC4Jは高トランザクション・レートで処理できます。これは、OracleのSpecJ Application Serverベンチマークに反映されています。http://www.spec.org/を参照してください。
一方向ORMIは、IIOPメッセージよりも小さいメッセージを使用して、このパフォーマンスを達成します。メッセージが小さいため、送受信用の帯域幅が小さく、エンコードとデコードの処理時間が短縮されます。
ORMIのメッセージ・サイズは、クライアントとサーバーの間でやり取りされる状態情報の量を最適化することで、さらに小さくなります。ORMIを使用すると、一部の状態はサーバー上でキャッシュされるため、RMIコールのたびに送信する必要がありません。フェイルオーバー時には、クライアント・コードにより新規サーバーに必要な状態情報がすべて再送されるため、これはステートレスであるというRMI要件に違反しません。
ORMIはOC4Jのスレッド化モデルと密結合され、そのキューイング、プーリングおよびステージング機能を最大限に利用します。
ORMIはクライアントごとに1つずつスレッドを使用します。マルチスレッド化されたクライアントの場合、OC4Jは1つの接続を介して各コールを多重化します。ただし、OC4Jは各コールをシリアライズしないため、複数のスレッドが相互をブロックすることはありません。
この機能により、各クライアント（単一スレッドまたはマルチスレッド）からリモート・サーバーに対する接続は必ず1つになります。
同じ場所に配置されているオブジェクトの場合、RMI/ORMIは同じ場所に配置された使用例を検出し、余分で不要なソケット・コールを回避します。
これは、JNDIレジストリが同じ場所に配置されている場合にも当てはまります。
OC4J RMI実装はリリースごとに異なります。そのため、起動元のオブジェクトと起動先のオブジェクトがそれぞれ異なるリリースのOC4J上で実行されている場合、リモート・オブジェクトのメソッドを起動するにはパッチが必要です。旧リリースから新規リリースのメソッドを起動する場合でも、新規リリースから旧リリースのメソッドを起動する場合でも、パッチが旧リリースにインストールされている必要があります。
例:
OC4Jリリース9.0.4.3上で稼働するサーブレットが、OC4Jリリース10.1.3上で稼働するEJBのメソッドを起動する場合。
OC4Jリリース10.1.3上で稼働するEJBが、OC4Jリリース10.1.2.0.2上で稼働するJMSオブジェクトを起動する場合。
OC4Jリリース10.1.2上で稼働するJSPが、OC4Jリリース10.1.3上で稼働するEJBのメソッドを起動する場合。
|
注意: リリース9.0.4.3と10.1.2.2間での起動操作には、パッチは必要ありません。これらのリリースには互換性があります。 |
パッチは、http://metalink.oracle.comからダウンロードできます。次の表に、パッチの適用対象となる旧リリースと、対応するパッチ識別子を示します。
| パッチ適用対象のOC4Jリリース | パッチ識別子 |
|---|---|
| 9.0.4.x | スタンドアロンOC4J用の9.0.4.2パッチ・セット（Patch 4365154 for iASまたはPatch 4504763）
Patch 4676768 |
| 10.1.2.0.0および10.1.2.0.2 | Patch 4676768 |
スタンドアロンOC4Jインストール環境では、RMI構成ファイルのrmi.xmlにRMIサーバー・データを指定する必要があります。また、このファイルの場所をOC4J構成ファイルのserver.xmlに指定する必要があります。
rmi.xmlファイルとserver.xmlファイルは、デフォルトでORACLE_HOME/j2ee/home/configにインストールされます。
RMI構成ファイルrmi.xmlへのパスを、OC4Jサーバー構成ファイルのserver.xmlの<rmi-config>要素に指定します。
構文は次のとおりです。
<rmi-config path="RMI_PATH" />
通常、RMI_PATHの値は./rmi.xmlです。
リモートRMIサーバーと通信し、接続を取得するために使用するホスト、ポート、ユーザー名およびパスワードを指定する<rmi-server>要素をOC4Jインスタンスのrmi.xmlファイルに追加します。このファイルは、デフォルトでORACLE_HOME/j2ee/home/configにインストールされます。
例:
<rmi-server host="hostname" port="port"> </rmi-server>
<rmi-server>要素の属性は、次のとおりです。
host: RMIサーバーがRMIリクエストを受信するホスト名またはIPアドレス。この属性を省略すると、MRIサーバーは、すべてのホストでRMIリクエストを受信します。
port: RMIサーバーがRMIリクエストをリスニングするポート番号。OC4Jスタンドアロン環境では、この属性を省略すると、デフォルトの23791が使用されます。
オプションで、アプリケーションからRMI経由で接続できるリモート（Point-to-Point）RMIサーバーを個別に指定する1つ以上の<server>要素で、<rmi-server>要素を構成します。
例:
<rmi-server host="hostname" port="port"> <server host="serverhostname" username="username" port="serverport" password="password"/> </rmi-server>
host属性は必須、その他の属性はオプションです。server要素のユーザーが置き換えることができる属性は次のとおりです。
serverhostname: リモートRMIサーバーがRMIリクエストをリスニングするホスト名またはIPアドレス
username: リモートRMIサーバーの有効なプリンシパルのユーザー名
serverport: リモートRMIサーバーがRMIリクエストをリスニングするポート番号
password: プリンシパルusernameが使用するパスワード
ORMIとORMISでは、<access-mask>要素を使用してrmi.xml内にACLマスクを定義することで、受信IPアクセスを制限できます。
アクセス制御には、排他モードと包含モードがあります。
排他モードでは、アクセス権をIPアドレスまたはホスト名に明示的に付与します。アクセス・マスクdefault="deny"のデフォルト・モードは、アクセス制御が排他的であることを示します。
包含モードでは、アクセス権がすべてのオブジェクトに付与されるため、例外を個別に指定する必要があります。アクセス・マスクdefault="allow"のデフォルト・モードは、アクセス制御が包含的であることを示します。
デフォルトのアクセス・モードに対する例外を指定するには、<host-access>および<ip-access>サブ要素を使用します。
詳細は、『Oracle Containers for J2EE開発者ガイド』の付録A「Webモジュールの管理」を参照してください。
次に、localhostと192.168.1.*サブネットのみにアクセスを許可する排他モード構成の例を示します。
<rmi-server
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation=
"http://xmlns.oracle.com/oracleas/schema/rmi-server-10_0.xsd"
port="23791"
ssl-port="23943"
schema-major-version="10"
schema-minor-version="0">
<access-mask default="deny" >
<host-access domain="localhost" mode="allow"/>
<ip-access ip="192.168.1.0" netmask="255.255.255.0" mode="allow"/>
</access-mask>
<log>
<file path="../log/rmi.log" />
</log>
<ssl-config
keystore="../wallets/wallet-server-a/ewallet.p12"
keystore-password="serverkey-a"
/>
</rmi-server>
この項では、OracleおよびJ2EE標準のJARファイルをインストールするためのZIPファイルのリストを示します。これらのファイルにより、RMI/ORMIを使用したEJBとJMSのルックアップが可能になります。
次のZIPファイルは、http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.htmlで入手できます。
ORMIを使用したEJBのルックアップを可能にするには、oc4j_client_<version>.zipをダウンロードして解凍します。
JMSなどの他のルックアップを可能にするには、oc4j_client.zipのかわりにoc4j_extended.zipをダウンロードして解凍します。
適切なZIPファイルを解凍したら、必ずoc4jclient.jarをCLASSPATHに含めます。
ZIPファイルには、クライアントに必要なすべてのJARファイルが含まれます。これらのJARファイルには、クライアントの対話に必要なクラスが格納されています。クライアントに必要な他のすべてのJARファイルは、oc4jclient.jarのマニフェスト・クラスパスで参照されるため、oc4jclient.jarのみをCLASSPATHに追加する必要があります。
EJBのルックアップを可能にするには、次のJARファイルをクライアント・サイドに含めます。
表6-1 EJBのルックアップに必要なクライアント・サイドのJARファイル
| JAR | ORACLE_HOMEパス |
|---|---|
|
|
|
|
|
|
リソース・アダプタのルックアップを可能にするには、次のJARファイルをクライアント・サイドに含めます。
表6-2 JMSコネクタのルックアップに必要なクライアント・サイドのJARファイル
| JAR | ORACLE_HOMEパス |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
内部的なOEMS JMSのメモリー内およびファイル・ベースのルックアップを可能にするには、表6-3「OEMS JMSのメモリー内およびファイル・ベースのルックアップに必要なクライアント・サイドのJARファイル」にリストされているJARファイルをクライアント・サイドに含めます。
表6-3 OEMS JMSのメモリー内およびファイル・ベースのルックアップに必要なクライアント・サイドのJARファイル
| JAR | ORACLE_HOMEパス |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（ |
|
アプリケーション・クライアントから内部的なOEMS JMSのデータベース・オプションの直接ルックアップを可能にするには、表6-4「OEMS JMSのデータベース・オプションのルックアップに必要なクライアント・サイドのJARファイル」にリストされているJARファイルをクライアント・サイドに含めます。
表6-4 OEMS JMSのデータベース・オプションのルックアップに必要なクライアント・サイドのJARファイル
| JAR | ORACLE_HOMEパス |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（ |
|
Oracle Application Server環境では、opmn.xmlファイルを編集して、ローカルRMIサーバーがRMIリクエストをリスニングするポート範囲を指定する必要があります。
Oracle Application Server環境の構成ファイルの変更内容は、OC4Jインスタンスごとに手動で更新する必要があります。
opmn.xmlファイルを構成する手順は、次のとおりです。
opmn.xmlファイルから抜粋した次の例のように、port id="rmi"要素を使用してrmiのポート範囲を構成します。
<ias-component id="OC4J">
<process-type id="home" module-id="OC4J">
<port id="default-web-site" range="12501-12600" protocol="ajp" />
<port id="rmi" range="12401-12500" />
<port id="rmis" range="12801-12900" />
<port id="jms" range="12601-12700" />
<process-set id="default_group" numprocs="1"/>
</process-type>
</ias-component>
opmn.xmlファイルの構成方法は、『Oracle Application Server管理者ガイド』を参照してください。
次のopmnctlコマンドを実行して変更を適用します。
opmnctl reload
オブジェクトのメソッドを起動するには、最初にオブジェクトの場所を検索できる必要があります。
次のRMI/ORMIプロパティをクライアントのjndi.propertiesファイルに指定します。
java.naming.provider.url（「Javaネーミング・プロバイダURLの設定」を参照）
java.naming.factory.initial（「コンテキスト・ファクトリの指定」を参照）
次の構文を使用して、java.naming.provider.urlの値として1つ以上のOC4Jホストを定義します。
<protocol>://<host>:[<port>]:<oc4j_instance>/<appName>
たとえば、Oracle Application Server内で稼働するアプリケーションの場合、次のように指定します。
java.naming.provider.url=opmn:ormi://myHost:home/ejbsamples
表6-5に、この構文で使用される引数を示します。
|
注意:
|
表6-5 ネーミング・プロバイダURL
| パラメータ | 説明 |
|---|---|
|
|
|
|
|
|
|
|
ポートは省略可能であり、その場合はプロトコルによって決定されます。ORMIプロトコルのデフォルト・ポートは、 |
|
|
|
|
|
アプリケーション名です。 |
Oracle Application Serverでは、opmn.xmlファイルで構成されているnotification-server要素のport要素のrequest属性に定義されたポートを指定できます（デフォルトは6003です）。opmnがrequestポートでRMIリクエストを受信すると、それを該当するOC4Jインスタンス用に選択したRMIポートに転送します。
たとえば、次のopmn.xmlファイルの抜粋を考えてみます。
<notification-server>
<port local="6100" remote="6200" request="6004"/>
<log-file path="$OLE_HOME/opmn/logs/ons.log" level="4" rotation-size="1500000"/>
<ssl enabled="true" wallet-file="$OLE_HOME/opmn/conf/ssl.wlt/default"/>
</notification-server>
この例では、notification-server要素のport要素のrequest属性に定義されたポートは6004であるため、JNDIネーミング・プロバイダURLのポートとして6004を使用します。
このURLの使用例は、「Oracle Application ServerでのOC4J」を参照してください。
Oracle Application Serverの旧リリースの場合、OC4Jインスタンスごとにopmnによって割り当てられたRMIポートを指定します。割り当てられたRMIポートを取得するには、OC4Jホストで次のopmnctlコマンドを使用します。
opmnctl status -l
これにより、OC4Jインスタンスごとに1行を含むデータ表が出力されます。
次に例を示します（読みやすいように一部の列は省略されています）。
Processes in Instance: server817.company.us.com -------------------+--------------------+-------+ ... +------ ias-component | process-type | pid | ... | ports -------------------+--------------------+-------+ ... +------ OC4J | home | 2012 | ... | iiop:12701,jms:12601,rmi:12401 HTTP_Server | HTTP_Server | 28818 | ... | http2:7200,http1:7778,http:7200
この例では、OC4JインスタンスのRMI用として、opmnによってポート12401が選択されています。このOC4JインスタンスのJNDIネーミング・プロバイダURLのポートには、この値を使用します。
初期コンテキスト・ファクトリは、クライアント用の初期コンテキスト・クラスを作成します。
java.naming.factory.initialプロパティを次のいずれかに設定してください。
|
注意: 次の初期コンテキスト・ファクトリは非推奨です。
|
ApplicationClientInitialContextFactoryは、スタンドアロン・アプリケーション・クライアントからリモート・オブジェクトをルックアップするときに使用されます。このコンテキスト・ファクトリは、application-client.xmlおよびorion-application-client.xmlで検出したrefsおよびref-mappingsを使用します。これは、初期コンテキストがJavaアプリケーションでインスタンス化される場合のデフォルトの初期コンテキスト・ファクトリです。
RMIInitialContextFactoryは、ORMIプロトコルを使用して異なるOC4Jサーバー・インスタンス間でリモート・オブジェクトをルックアップするときに使用されます。
使用する初期コンテキスト・ファクトリのタイプは、次のようにクライアントに応じて異なります。
クライアントがOC4Jコンテナ外部のPure Javaクライアントの場合は、ApplicationClientInitialContextFactoryクラスを使用します。
クライアントがOC4Jコンテナ内のEJBまたはサーブレット・クライアントの場合は、ApplicationInitialContextFactoryクラスを使用します。これはデフォルト・クラスであるため、初期コンテキスト・ファクトリ・クラスを指定せずに新規InitialContextを作成するたびに、クライアントではApplicationInitialContextFactoryクラスが使用されます。
クライアントがJNDIツリーを操作または横断する管理クラスの場合は、RMIInitialContextFactoryクラスを使用します。
クライアントがDNSロード・バランシングを使用する場合は、RMIInitialContextFactoryクラスを使用します。
OC4Jでは、クラスタ化された複数のOC4JインスタンスにデプロイされたEJBに対するクライアントORMIリクエストのロード・バランシングがサポートされます。
デフォルトの動作では、クライアントは、コールのたびに同じOC4Jインスタンスに接続します。具体的には、クライアントが同じuser/password/provider URLの組合せを使用してInitialContext()をコールするたびに、クライアントの最初の起動時に作成されたキャッシュ済のContextオブジェクトが戻されます。そのため、クライアントは、このContextオブジェクトによって定義される同じOC4Jインスタンスにリクエストを送信することになります。
クライアント・コールの数が明らかに少ない状況では、この方法での接続は効率的であり、最大のパフォーマンスを得ることができます。
ただし、大量のリクエストが予想される状況では、OC4Jインスタンス間でリクエストのロード・バランシングを実行する方が適切である可能性があります。ロード・バランシングは、oracle.j2ee.rmi.loadBalanceプロパティを使用して構成できます。このプロパティは、クライアントのjndi.propertiesファイル、またはクライアント・コードのハッシュテーブルで設定します。次の表に、このプロパティの値とその説明を示します。
表6-6 oracle.j2ee.rmi.loadBalanceプロパティの値
| 値 | 説明 |
|---|---|
|
|
指定した場合、クライアントは、通信全体に対する最初のルックアップで初期選択されたOC4Jプロセスと対話します。 |
|
|
クラスタ化されたOC4J環境のEJBにアクセスするWebクライアント（サーブレットまたはJSP）で使用されます。 指定した場合、 |
|
|
クラスタ化されたOC4J環境のEJBにアクセスするスタンドアロン・クライアントで使用されます。 指定した場合、クライアントが |
次に、Hashtableでこのプロパティをlookupに設定する例を示します。
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.evermind.server.rmi.RMIInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "jazn.com/admin");
env.put(Context.SECURITY_CREDENTIALS, "password");
env.put(Context.PROVIDER_URL,"opmn:ormi://<hostname>:oc4j_inst1/ejbsamples");
env.put("oracle.j2ee.rmi.loadBalance","lookup");
この項では、次の環境でORMIを使用してEJBをルックアップする例を示します。
次の例に、スタンドアロンOC4JインスタンスにデプロイされたJ2EEアプリケーションejbsamplesでMyCartというEJBをルックアップする方法を示します。アプリケーションは、RMIポート23792でリスニングするよう構成されたノード上に配置されています。
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"oracle.j2ee.rmi.RMIInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "admin");
env.put(Context.SECURITY_CREDENTIALS, "password");
env.put(Context.PROVIDER_URL, "ormi://<hostname>:23792/ejbsamples");
Context context = new InitialContext(env);
Object homeObject = context.lookup("MyCart");
CartHome home = (CartHome)PortableRemoteObject.narrow(homeObject,CartHome.class);
Oracle Application Serverでは、Oracle Application Server環境のEJBをルックアップする場合、URLで次のタイプのルックアップを使用できます。
次の例に、Oracle Application Server環境のJ2EEアプリケーションejbsamplesでMyCartというEJBをルックアップする方法を示します。この起動とスタンドアロンの起動の違いは、ormiに対するopmn接頭辞、EJBアプリケーションがデプロイされているOC4Jインスタンス名oc4j_inst1の指定、およびRMIポートの指定が不要という点です。
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"oracle.j2ee.rmi.RMIInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "jazn.com/admin");
env.put(Context.SECURITY_CREDENTIALS, "password");
env.put(Context.PROVIDER_URL,"opmn:ormi://<hostname>:oc4j_inst1/ejbsamples");
Context context = new InitialContext(env);
Object homeObject = context.lookup("MyCart");
CartHome home = (CartHome)PortableRemoteObject.narrow(homeObject,CartHome.class);
Oracle Application Server環境のOC4Jインスタンスでは、RMIポートが動的に割り当てられます。デフォルトのユーザー・マネージャは、JAZNUserManagerです。
Oracle Application Serverの旧リリースでは、Oracle Application ServerのEJBにアクセスする場合、opmnによって割り当てられたRMIポートを確認する必要があります。OC4Jインスタンス用のJVMが1つのみの場合は、RMIのポート範囲を特定の番号（3101〜3101など）に限定する必要があります。
次の例に、J2EEアプリケーションejbsamplesでMyCartというEJBをルックアップする方法を示します。アプリケーションは、RMIポート12401でリスニングするよう構成されたノード上に配置されています。
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.evermind.server.rmi.RMIInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "jazn.com/admin");
env.put(Context.SECURITY_CREDENTIALS, "welcome");
env.put(Context.PROVIDER_URL, "ormi://<hostname>:12401/ejbsamples");
Context context = new InitialContext(env);
Object homeObject = context.lookup("MyCart");
CartHome home = (CartHome)PortableRemoteObject.narrow(homeObject,CartHome.class);
ファイアウォールを通じたEJBとの通信を可能にするため、ORMIでは、HTTPトンネリングを使用してHTTP POSTリクエスト内にRMIコールをラップします。このリクエストは、ターゲットOC4Jインスタンス内のdefault Webアプリケーションに転送されます。トンネリングは、RMI/ORMIでのみサポートされます。RMI/IIOPを使用したHTTPトンネリングは実行できません。
java.naming.provider.urlの値として設定されるHTTPトンネリングURLの構文は、次のとおりです。
ormi:http[s]://<hostname>:<port>/<appName>
表6-7 HTTPトンネリングURLの構文
| パラメータ | 説明 |
|---|---|
|
|
リクエストを受信するサーバー・ホスト名。 |
|
|
サーバーのポート。この値はオプションです。省略すると、デフォルトの Oracle Application Server環境に接続する際には、OPMNに登録されているのと同じポートを使用します。 |
|
|
ターゲット・アプリケーションの名前。 |
HTTPトラフィックがプロキシWebサーバーを経由する場合は、次のようにコマンドラインでproxyHostおよび（オプションで）proxyPortを指定し、EJBクライアントを起動します。
-Dhttp.proxyHost=<proxy_host> -Dhttp.proxyPort=<proxy_port>
proxy_portを省略すると、デフォルトの80が使用されます。
ORMI over SSL（ORMIS）は、Oracle Application Server 10g（10.1.3.5.0）の新機能です。この機能により、OC4Jでは、複数のOC4Jサーバー・インスタンスのオブジェクト間通信でSecure Sockets Layer（SSL）を介したRMIがサポートされます。
ORMISは、OC4Jではデフォルトで無効化されています。この機能を使用するには、クライアントおよびサーバーでキーストアを作成する必要があります。
詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』で次の内容に関する情報を参照してください。
キーストアおよびウォレットの作成
OC4JでのORMI/SSL（ORMIS）の有効化
ORMISを使用するためのOC4Jの構成
ORMISを使用するためのクライアントの構成
EJBサーバー・セキュリティのプロパティ（internal-settings.xml）
CSIv2セキュリティのプロパティ
CSIv2セキュリティのプロパティ（internal-settings.xml）
CSIv2セキュリティのプロパティ（ejb_sec.properties）
CSIv2セキュリティのプロパティ（orion-ejb-jar.xml）
EJBクライアント・セキュリティのプロパティ（ejb_sec.properties）
この項では、標準のInternet Inter-Orb Protocol（IIOP）を介したRemote Method Invocation（RMI）を使用して、異なるJ2EEコンテナ間（OC4JとBEA WebLogicサーバー間など）でEJBやその他のオブジェクトを相互起動できるようにするOC4Jのサポート機能について説明します。
この項には、次の項目が含まれます。
Java RMIを使用すると、分散Javaベース間アプリケーションを作成できます。この種のアプリケーションでは、リモートJavaオブジェクトのメソッドを、異なるホスト上にあるものも含め、JVM間で起動できます。
バージョン2.0のEJB仕様では、異なるコンテナ間でEJBベースのアプリケーションを容易に相互起動できる機能が導入されました。既存のEJBを、コード行を変更せずに、Beanのプロパティを編集して再デプロイするのみで相互運用可能にできます。再デプロイの詳細は、「ORMIからIIOPトランスポートへの切替え」を参照してください。
EJB相互運用性は、次のもので構成されています。
トランスポート相互運用性: CORBA IIOP（Internet Inter-ORB Protocol。ORBはObject Request Broker）を使用
ネーミング相互運用性: CORBA CosNaming Service（OMG CORBA Object Service仕様の一部であるCORBA Object Service Naming）を使用
セキュリティ相互運用性: Common Secure Interoperability Version 2（CSIv2）を使用
OC4Jは、トランスポート相互運用性、ネーミング相互運用性およびセキュリティ相互運用性を提供します。
デフォルトでは、OC4JのEJBは、独自仕様のプロトコルであるRMI/Oracle Remote Method Invocation（ORMI）を使用して通信を行います（「Oracle Remote Method Invocation（RMI/ORMI）の使用方法」を参照）。
ただし、異なるEJBコンテナ間でEJBを相互起動するため、RMI/IIOPを使用するようEJBを変換することも簡単です。この項では、RMI/IIOPを構成および使用する方法について説明します。
|
注意: OC4J 10g（10.1.3.5.0）の実装では、ロード・バランシングとフェイルオーバーがサポートされるのはORMIの場合のみで、IIOPの場合はサポートされません。 |
OC4Jは、CORBA CosNamingサービスをサポートします。OC4Jでは、EJBHomeオブジェクト参照をCosNamingサービスで公開できます。また、アプリケーションがCORBAを使用してJNDI名をルックアップできるJNDI CosNaming実装が提供されます。JNDI APIまたはCosNaming APIのいずれかを使用してアプリケーションを作成できます。
OC4JはCommon Secure Interoperability Version 2（CSIv2）をサポートします。CSIv2は、様々な準拠レベルを指定します。OC4Jは、準拠レベル0（ゼロ）を必要とするEJB仕様に準拠しています。
セキュリティの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』の「CSIv2」を参照してください。
EJBに相互運用性サポートを追加するには、相互運用性プロパティを指定する必要があります。これらのプロパティの一部はOC4Jの起動時に指定され、その他はデプロイメント・ファイルに指定されています。
次のOC4J起動フラグにより、RMIの相互運用性がサポートされます。
-DGenerateIIOP=true: アプリケーションが再デプロイされるたびに、新規のスタブとスケルトンを生成します。
-Diiop.debug=true: デプロイ時のデバッグ・メッセージを生成します。その大部分はコード生成に関連しています。
-Diiop.runtime.debug=true: 実行時のデバッグ・メッセージを生成します。
EJBによる通信を可能にするには、表6-8に示す構成ファイルのパラメータを構成する必要があります。
表6-8 相互運用性構成ファイル
| コンテキスト | ファイル | 説明 |
|---|---|---|
|
サーバー |
|
このファイルの
|
|
|
このファイルでは、RMI/IIOP固有のサーバー拡張プロバイダのプロパティを指定します。 |
|
|
アプリケーション |
|
|
|
|
このファイルでは、EJBに対するクライアント・サイド・セキュリティのプロパティを指定します。 |
|
|
|
このファイルでは、クライアントが使用する初期ネーミング・コンテキストのURLを指定します。詳細は、「相互運用に関するJNDIプロパティ（jndi.properties）」を参照してください。 |
セキュリティの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』の「CSIv2」を参照してください。
次のRMI/IIOPプロパティは、クライアントのjndi.propertiesファイルで制御されます。
Beanを相互運用可能にするには、java.naming.provider.urlにOPMNまたはcorbanameのURLを使用できます。
クライアントのJNDIプロパティjava.naming.provider.urlを構成してOPMNのURLを使用する場合、OPMNによる割当てポートはOC4Jにレポートされないため、そのクライアントではssl-portポートやssl-client-server-auth-portポートに接続できません。
corbaname URLの詳細は、「corbanameのURLの指定」を参照してください。OPMNのURLの詳細は、「OPMN URLの指定」を参照してください。
contextFactoryは、ApplicationClientInitialContextFactoryまたはクラスIIOPInitialContextFactoryです。
アプリケーションにapplication-client.xmlファイルがある場合は、contextFactoryをApplicationClientInitialContextFactoryに設定したままにします。アプリケーションにapplication-client.xmlファイルがない場合は、contextFactoryをIIOPInitialContextFactoryに変更します。
oracle.j2ee.naming.ApplicationClientInitialContextFactoryは、スタンドアロン・アプリケーション・クライアントからリモート・オブジェクトをルックアップするときに使用されます。このコンテキスト・ファクトリは、application-client.xmlおよびorion-application-client.xmlで検出したrefsおよびref-mappingsを使用します。これは、初期コンテキストがJavaアプリケーションでインスタンス化される場合のデフォルトの初期コンテキスト・ファクトリです。
oracle.j2ee.iiop.IIOPInitialContextFactoryは、IIOPプロトコルを使用して異なるコンテナ間でリモート・オブジェクトをルックアップするときに使用されます。
この項では、OracleおよびJ2EE標準のJARファイルをインストールするためのZIPファイルのリストを示します。これらのファイルにより、RMI/IIOPを使用したEJBとJMSのルックアップが可能になります。
次のZIPファイルは、http://www.oracle.com/technology/software/products/ias/index.htmlで入手できます。
IIOPを使用したEJBのルックアップを可能にするには、oc4j_iiop_client.zipをダウンロードして解凍します。
JMSなどの他のルックアップを可能にするには、oc4j_extended.zipもダウンロードして解凍します。
これらのZIPファイルを解凍したら、必ずoc4jclient.jarをCLASSPATHに含めます。
ZIPファイルには、クライアントに必要なすべてのJARファイルが含まれます。これらのJARファイルには、クライアントの対話に必要なクラスが格納されています。クライアントに必要な他のすべてのJARファイルは、oc4jclient.jarのマニフェスト・クラスパスで参照されるため、oc4jclient.jarのみをCLASSPATHに追加する必要があります。
IIOPクライアントを実行する場合、IIOPクライアント用に次のプロパティを設定する必要があります。
-Dorg.omg.CORBA.ORBInitialHost=${orb.host}
-Dorg.omg.CORBA.ORBInitialPort=${orb.port}
-Djavax.rmi.CORBA.PortableRemoteObjectClass=com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject
-Dcom.oracle.CORBA.OrbManager=com.oracle.corba.ee.impl.orb.ORBManagerImpl
OC4Jでは、EJBは独自仕様のプロトコルであるRMI/ORMIを使用して通信を行います（「Oracle Remote Method Invocation（RMI/ORMI）の使用方法」を参照）。ただし、異なるベンダーのEJBコンテナ間（OC4JとBEA WebLogicなど）でEJBを相互起動するため、RMI/IIOPを使用するようEJBを変換することも可能です。
|
注意: RMI/IIOPのサポートはCORBA 2.3.1仕様に基づいています。以前のリリースのCORBAを使用してコンパイルされたアプリケーションは、正しく動作しない可能性があります。 |
次の項で、この変換について詳しく説明します。
スタンドアロンOC4J環境でRMI/IIOPを使用するようEJBを変換する手順は、次のとおりです。
orion-ejb-jar.xmlおよびinternal-settings.xmlで、BeanのCSIv2セキュリティ・ポリシーを指定します。
セキュリティの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』の「CSIv2」を参照してください。
-DGenerateIIOP=trueフラグを指定してOC4Jを再起動します。
admin.jarを使用してアプリケーションをデプロイします。-iiopClientJarスイッチを使用して、クライアントのスタブJARファイルを取得する必要があります。次に例を示します。
java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deploy -file filename -deployment_name application_name -iiopClientJar stub_jar_filename
|
注意: デプロイするアプリケーションで相互運用性（IIOP）を有効化するために、-iiopClientJarスイッチを使用する必要があります。OC4Jでは、相互運用性はアプリケーションごとに有効化されます。 |
-iiopClientJarスイッチを指定してadmin.jarを実行し、クライアントのclasspathを変更して、デプロイ中に取得されたスタブJARファイルを組み込みます。
OC4Jにより生成されたスタブJARファイルのコピーは、次のようにサーバーのデプロイメント・ディレクトリに置かれている場合もあります。
application_deployment_directory/appname/ejb_module/_iiopClient.jar
|
注意: 実行時に行われるORMIスタブの生成とは異なり、IIOPスタブおよびTieクラス・コードの生成はデプロイ時に行われます。このため、管理者自身がJARファイルをclasspathに追加する必要があります。 |
ormiのURLのかわりにcorbanameのURLを使用するように、クライアントのJNDIプロパティjava.naming.provider.urlを編集します。corbaname URLの詳細は、「corbanameのURLの指定」を参照してください。
（オプション）CORBAアプリケーションからBeanにアクセスできるようにするには、rmic.jarを実行して、そのインタフェースを記述するIDLを生成します。
この項では、Oracle Application Server環境でRMI/IIOPを使用するようEJBを変換する方法について説明します。
orion-ejb-jar.xmlおよびinternal-settings.xmlで、BeanのCSIv2セキュリティ・ポリシーを指定します。
セキュリティの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』の「CSIv2」を参照してください。
デフォルトでは、Oracle Application Server環境でRMI/IIOPは無効化されています。RMI/IIOPを有効化するには、OPMNの構成ファイルJ2EE_HOME/opmn/conf/opmn.xmlで、OPMNの管理対象となるOC4Jインスタンスごとに一意のiiop、iiops1およびiiops2ポート（またはポート範囲）が存在することを確認します。これらは次のポートを意味します。
iiop: 標準IIOPポート
iiops1: サーバー・サイド認証専用のIIOP/SSLポート
iiops2: クライアント・サイドおよびサーバー・サイド認証用のIIOP/SSLポート
|
注意: CSIv2を使用した相互運用性を有効化するOC4Jインスタンスごとに、iiop、iiops1およびiiops2ポート（またはポート範囲）を指定する必要があります。これを指定しないと、OC4JではIIOPリスナーが構成されないため、OC4Jのinternal-settings.xmlファイルでの構成に関係なく、相互運用性は自動的に無効化されます。 |
次に例を示します。
<ias-component id="OC4J">
<process-type id="home" module-id="OC4J">
<port id="ajp" range="3000-3100"/>
<port id="rmi" range="23791-23799"/>
<port id="jms" range="3201-3300"/>
<port id="iiop" range="3401-3500"/>
<port id="iiops1" range="3501-3600"/>
<port id="iiops2" range="3601-3700"/>
<process-set id="default_group" numprocs="1"/>
</process-type>
</ias-component>
|
注意: クライアントのJNDIプロパティjava.naming.provider.urlを構成してOPMNのURLを使用することを選択した場合、OPMNによる割当てポートはOC4Jにレポートされないため、そのクライアントではiiops1ポートやiiops2ポートに接続できません。 |
opmnctlを使用して、OPMNで管理されるOC4Jインスタンスをすべて再起動します。-DGenerateIIOP=trueフラグを使用します。
opmnctl -DGenerateIIOP=true startall
-enableIIOPオプションを指定してアプリケーションをデプロイします。デプロイの詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
クライアントのclasspathを変更して、OC4Jによって生成されたスタブJARファイルを組み込みます。通常、このファイルはサーバーのデプロイメント・ディレクトリにあります。
application_deployment_directory/appname/ejb_module/_iiopClient.jar
|
注意: 実行時に行われるORMIスタブの生成とは異なり、IIOPスタブおよびTieクラス・コードの生成はデプロイ時に行われます。このため、管理者自身がJARファイルをclasspathに追加する必要があります。 |
ormiのURLのかわりにOPMNまたはcorbanameのURLを使用するように、クライアントのJNDIプロパティjava.naming.provider.urlを編集します。corbaname URLの詳細は、「corbanameのURLの指定」を参照してください。OPMNのURLの詳細は、「OPMN URLの指定」を参照してください。
（オプション）CORBAアプリケーションからBeanにアクセスできるようにするには、rmic.jarを実行して、そのインタフェースを記述するIDLを生成します。
相互運用を可能にするには、EJBでCosNamingを使用して他のBeanをルックアップする必要があります。つまり、ルートNamingContextをルックアップするためのURLには、ormiのURLスキームのかわりに、corbanameのURLスキームを使用する必要があります。この項では、EJB開発者が一般的に使用するcorbanameのサブセットについて説明します。corbanameスキームの詳細は、CORBA Naming Service仕様の第2.5.3項を参照してください。corbanameスキームは、corbalocスキームに基づいています。これについては、CORBA仕様の第13.6.10.1項で説明されています。
corbanameのURLスキームの最も一般的な形式は、次のとおりです。
corbaname::host[:port]
このcorbanameのURLによって、従来型のDNSホスト名またはIPアドレスとポート番号が指定されます。次に例を示します。
corbaname::example.com:8000
corbanameのURLでは、ホストとポートの後に#および文字列表現によるNamingContextを記述することによって、ネーミング・コンテキストを指定することもできます。指定したホストのCosNamingサービスが、ネーミング・コンテキストを解析します。
corbaname::host[:port]#namingcontext
例:
corbaname::example.com:8000#Myapp
この項では、RMI/IIOP固有のOPMNのURLの詳細を説明します。OPMNのURLの概要は、「RMI用のJNDIプロパティの設定」を参照してください。
Oracle Application Server環境では、各Oracle Application Serverインスタンス内のすべてのOC4JプロセスのIIOPポートは、OPMNにより動的に管理されます。このため、OC4JプロセスがアクティブにIIOPリクエストをリスニングしているポートをクライアントが認識することはできません。Oracle Application Server環境のクライアントが、すべてのアクティブなOC4JプロセスのIIOPポートを認識することなく、RMI/IIOPリクエストを正常に発行できるようにするには、次の形式のURLを使用して（クライアントのjndi.propertiesファイルの）jndi.naming.provider.urlプロパティを変更します。
opmn:corbaname::host[:port][#instance-name]#appname
例:
opmn:corbaname::dlsun74:6003#oc4j_inst1#ejbsamples
|
注意:
|
EJBがIIOPを介して起動される場合、OC4Jではシステム例外をCORBA例外にマップする必要があります。表6-9に、例外マッピングを示します。
表6-9 Java例外とCORBA例外のマッピング
| OC4Jシステム例外 | CORBAシステム例外 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
