Oracle® Fusion Middleware

Oracle WebLogic Server RMIアプリケーションの開発

12c (12.2.1)

E70022-01(原本部品番号:E55160-01)

2015年10月

このドキュメントは、Remote Method Invocation (RMI)とInternet Inter-ORB Protocol (IIOP)の機能を使用してe- コマース・アプリケーションを構築するアプリケーション開発者を対象としています。

Oracle Fusion Middleware Oracle WebLogic Server RMIアプリケーションの開発, 12c (12.2.1)

E70022-01

Copyright © 2007, 2015, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サンプルとチュートリアル

- Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

- WebLogic Server配布キットのサンプル

- このリリースでの新機能と変更された機能

2 WebLogic RMIの理解

- WebLogic RMIとは

- WebLogic RMIの機能

3 WebLogic RMIの機能

- WebLogic RMIクライアント

- WebLogic RMIのセキュリティのサポート

- WebLogic RMIのトランザクションのサポート

- RMIオブジェクトのフェイルオーバーとロード・バランシング

- クラスタリングされたRMIアプリケーション

- RMIオブジェクトのロード・バランシング

- クラスタリングされたオブジェクトのパラメータ・ベースのルーティング

- カスタム呼出しルーティングと連結の最適化

- リクエスト・タイムアウト

- 接続タイムアウトの使用

- 読取りタイムアウトの使用

- タイムアウトを含むrtd.xmlファイルの例

- タイムアウトを含むweblogic-ejb-jar.xmlファイルの例

- 固定サービスの作成

- RMIの動的プロキシ

4 WebLogic RMIアノテーションの使用

- WebLogic RMIアノテーションの概要

- WebLogic RMIのアノテーション

- Rmi

- 説明

- 属性

- RmiMethod

- 説明

- 属性

- 例外処理

- アプリケーションの例外

- システム例外

- クラスタ・フェイルオーバー

- RMIコールバック・オブジェクト

- アノテーションとWebLogic RMI記述子のマージ

5 WebLogic RMIコンパイラの使い方

- WebLogic RMIコンパイラの概要

- WebLogic RMIコンパイラの機能

- ホット・コード生成

- プロキシの生成

- WebLogic RMIコンパイラのその他の機能

- WebLogic RMIコンパイラのオプション

- レプリケートされないスタブの生成

- 永続的なコンパイラ・オプションの使用

- Java SEの拡張

6 WebLogic RMIでのT3プロトコルの使い方

- WebLogic ServerにおけるRMI通信

- 接続の可用性の判断

- WebLogic T3/T3sクライアント・プロキシの使い方

7 WebLogic RMIの実装方法

- リモートで呼び出すことができるクラスの作成

- 手順1: リモート・インタフェースの作成

- 手順2: リモート・インタフェースの実装

- 手順3: リモート・メソッドを呼び出すクライアントの作成

- クライアント・タイムアウトの設定

- HelloClient.javaクライアントの例

- 手順4: Javaクラスのコンパイル

- RMI Helloサンプル・コードの実行

- 前提条件

- RMI Helloサンプルの設定

- 起動クラスの構成

- examplesServerの再起動

- サンプルの実行

8 ロード・バランサとのWebLogic RMIの統合

- WebLogic Serverでのロード・バランサのサポート

- HTTPトンネリングT3ロード・バランシング

- 外部リスニング・アドレスの構成方法

- ロード・バランサのカスタム・チャネル構成の例

- セッション・フェイルオーバー

- Cookieの永続性

- 確保済オブジェクト

- ステートフル・セッションEJB

- ネイティブT3ロード・バランシング

- フェイルオーバー・サポート

9 RMI over IIOPの使い方

- RMI over IIOPとは

- WebLogic RMI-IIOPの概要

- RMI (Java)クライアント使用型RMI-IIOPのサポート

- Tuxedoクライアント使用型RMI-IIOPのサポート

- CORBA/IDLクライアント使用型RMI-IIOPのサポート

10 WebLogic ServerのRMI-IIOP用構成

- リスニング・アドレスの設定

- ネットワーク・チャネル・アドレスの設定

- プロキシおよびファイアウォールに関する考慮事項

- 複数の接続を持つクライアントに関する考慮事項

- IIOPSシン・クライアント・プロキシの使用

- RMI-IIOPとSSLおよびJavaクライアントの併用

- 委任を通じたCORBAクライアントからWebLogic Serverオブジェクトへのアクセス

- 委任の概要

- 委任の例

- CSIv2認証の構成

- ハードウェア・ロード・バランサとRMI over IIOPの併用

- WebLogic RMI-IIOPの制約事項

- クライアントでRMI-IIOPを使用する際の制約

- Java IDLクライアントの開発上の制約

- オブジェクトの値渡しに関する制約

- クライアントIDの伝播

11 アプリケーション設計のベスト・プラクティス

- java.rmiの使用

- PortableRemoteObjectの使用

- WebLogicワーク・コンテキストの使用

- セキュリティ・コンテキストにおける変更の処理方法

A WebLogic ServerでのCORBAのサポート

- 仕様リファレンス

- サポートされる仕様の詳細

- ツール

はじめに

ここでは、このガイド『Oracle WebLogic Server RMIアプリケーションの開発』で使用されるドキュメントのアクセシビリティ機能と表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、『Oracle WebLogic Server RMIアプリケーションの開発』の内容と構成について説明します。

この章には次の項が含まれます:

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サンプルとチュートリアル

- このリリースでの新機能と変更された機能

ドキュメントのスコープと対象読者

このドキュメントは、Remote Method Invocation (RMI)とInternet Inter-ORB Protocol (IIOP)の機能を使用してe- コマース・アプリケーションを構築するアプリケーション開発者を対象としています。Web技術、オブジェクト指向プログラミング技術、およびJavaプログラミング言語について読者が精通していることを前提としています。このドキュメントでは、WebLogic Serverが提供する付加価値の高い機能を紹介し、RMIを用いたアプリケーションを開発する際のWebLogic Server機能の使い方について主要な情報を示します。

このドキュメントの手引き

このマニュアルでは、Remote Method Invocation (RMI)仕様に基づいたOracle WebLogic Server RMI実装について説明します。Oracleの実装をWebLogic RMIと呼びます。

- 第1章「概要とロードマップ」 では、このドキュメントの構成を紹介します。

- 第2章「WebLogic RMIの理解」はWebLogic RMIの機能とアーキテクチャの概要です。

- 第3章「WebLogic RMIの機能」では、WebLogic Server用RMIをプログラミングするときに使用する機能について説明します。

- 第4章「WebLogic RMIアノテーションの使用」では、WebLogic RMIアノテーションを使用してプレーンJavaオブジェクトへのリモート・アクセスを提供する方法について説明します。

- 第5章「WebLogic RMIコンパイラの使い方」では、WebLogic RMIコンパイラについて説明します。

- 第6章「WebLogic RMIでのT3プロトコルの使い方」では、RMIおよびT3プロトコルの使い方について説明します。

- 第7章「WebLogic RMIの実装方法」では、WebLogic RMIの実装方法について、簡単な例を用いて手順を追って説明します。

- 第9章「RMI over IIOPの使い方」では、RMI over IIOPの定義と、Weblogic ServerのRMI-IIOPの実装の概要について説明します。

- 第10章「WebLogic ServerのRMI-IIOP用構成」では、WebLogic ServerでのRMI-IIOPアプリケーションのサポートに関連する概念、問題および手順について説明します。

- 第11章「アプリケーション設計のベスト・プラクティス」では、RMIおよびRMI over IIOPアプリケーションを開発するときの推奨設計パターンについて説明します。

- 「付録A WebLogic ServerでのCORBAのサポート」では、WebLogic ServerでのCORBAのサポートについて説明します。

関連ドキュメント

WebLogic RMIに関連するトピックの情報は、以下のドキュメントを参照してください。

- http://docs.oracle.com/javase/6/docs/technotes/guides/rmi/のJava RemoteMethod Invocation (RMI)は、Remote Method Invocationに関する基本的なチュートリアルのリンクです。

- 『Oracle WebLogic Serverアプリケーションの開発』。WebLogic Serverアプリケーションの開発ガイドです。

- 『Oracle WebLogic Server JNDIアプリケーションの開発』は、WebLogic Java Naming and Directory Interfaceの使用に関するガイドです。

- 『Oracle WebLogic Serverスタンドアロン・クライアントの開発』は、WebLogic Serverと相互運用する共通スタンドアロン・クライアントの開発に関するガイドです。

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』には、WebLogic Serverアプリケーションのパフォーマンスを監視して改善するための情報が掲載されています。

- http://www.oracle.com/technetwork/java/javase/tech/corba-135898.htmlでは、CORBAとJavaプラットフォームの概要が説明されています。

- http://docs.oracle.com/javase/6/docs/technotes/guides/idl/index.htmlには、標準IDL (Object Management Group Interface Definition Language)とIIOPの使用に関する情報が掲載されています。

- http://www.omg.org Object Management Groupのホームページです。

- http://www.omg.org/technology/documents/index.htmのCORBA言語マッピング仕様

サンプルとチュートリアル

このドキュメントの他にも、様々なサンプル・コードやチュートリアルが開発者向けに用意されています。それらのサンプルとチュートリアルはWebLogic Serverの動作を例示し、主要な開発タスクを実行する実際的な手順を示します。

独自のアプリケーションを開発する前に、まずRMIサンプルの一部またはすべてを実行することをお薦めします。

Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

MedRecはWebLogic Serverに付属したエンドツーエンドのサンプルJava Platform, Enterprise Edition (Java EE)アプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者に対して、様々なクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRecはWebLogic ServerとJava EEの機能を例示し、Oracle推奨のベスト・プラクティスを重要点として示します。MedRecは、WebLogic Serverインストールでオプションでインストールされます。MedRecはORACLE_HOME\user_projects\domains\medrecディレクトリから起動できます。ORACLE_HOMEは、Oracle WebLogic ServerをインストールしたときにOracleホームとして指定したディレクトリです。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

MedRecには、Webアプリケーション、Webサービス、ワークフロー・アプリケーション、および将来のクライアント・アプリケーションからのリクエストを連携して処理する複数のエンタープライズJava Bean (EJB)で主に構成されるサービス層があります。このアプリケーションには、メッセージドリブンEJB、ステートレス・セッションEJB、ステートフル・セッションEJB、およびエンティティEJBが含まれます。

WebLogic Server配布キットのサンプル

WebLogic Serverでは、オプションで、APIサンプル・コードをORACLE_HOME\wlserver\samples\server\examples\src\examplesディレクトリにインストールします(ORACLE_HOMEは、WebLogic Serverをインストールしたディレクトリを表します)。WebLogic Serverのサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

このリリースでの新機能と変更された機能

この項では、WebLogic Serverの最新パッチ・セットで新機能と変更された機能を説明します。

- プレーンJavaオブジェクトへのリモート・アクセスを提供する新しいWebLogic RMIアノテーション。「WebLogic RMIアノテーションの使用」を参照してください。

- 新しい接続属性WLContext.CONNECT_TIMEOUT。ブートストラップと再確立の対象となるサーバーへの接続をクライアントが待機する時間を定義します。WLContext.REQUEST_TIMEOUTは非推奨です。「接続タイムアウトの使用」を参照してください。

- 新しい接続属性WLContext.RESPONSE_READ_TIMEOUT。クライアントがサーバーからのレスポンスの受信を待機する時間を定義します。WLContext.RMI_TIMEOUTは非推奨です。「読取りタイムアウトの使用」を参照してください。

このリリースで導入されたWebLogic Serverの新機能の一覧については、『Oracle WebLogic Serverの新機能』 12.2.1を参照してください。

2 WebLogic RMIの理解

この章では、WebLogic RMIの機能について説明します。

この章には次の項が含まれます:

- WebLogic RMIとは

- WebLogic RMIの機能

WebLogic RMIとは

RMI (Remote Method Invocation)は、Javaでの分散オブジェクト・コンピューティングの標準規格です。RMIを使用すると、アプリケーション側では、ネットワーク内の別の場所に存在するオブジェクトへの参照を取得した後、そのオブジェクトのメソッドを、そのオブジェクトがあたかもクライアントの仮想マシンにローカルに存在するかのように呼び出すことができます。RMIは、分散Javaアプリケーションが複数のJava仮想マシン上でどのように動作するかを規定するものです。

このドキュメントはWebLogic RMIの使い方について説明したものですが、リモート・オブジェクトや分散アプリケーションの記述方法についての初心者向けチュートリアルではありません。RMIの学習を開始する場合は、http://docs.oracle.com/javase/6/docs/technotes/guides/rmi/を参照し、RMIチュートリアルを確認します。

WebLogic RMIの機能

次の表に、RMIのWebLogic実装の重要な機能を示します。

表2-1 WebLogic RMIの機能

機能

WebLogic RMI

全体的なパフォーマンス

WebLogic Serverフレームワークとの統合により、WebLogic RMIのパフォーマンスが向上します。WebLogic Serverは、通信の基底のサポート、スケーラビリティ、スレッドとソケットの管理、効率的なガベージ・コレクション、およびサーバー関連サポートを提供します。

標準への準拠

Java Platform Standard Edition 6.0 API仕様に準拠しています。

アノテーション

リモートJavaオブジェクト内に組込み可能なアノテーションのサポートを提供します。

フェイルオーバーとロード・バランシング

WebLogic ServerはRMIオブジェクトのフェイルオーバーとロード・バランシングをサポートします。

リクエスト・タイムアウト

リモート・コールが完了するタイムアウト期間を指定できます。

WebLogic RMIコンパイラ

スタブとスケルトンは実行時にWebLogic RMIによって動的に生成されます。このため、クラスタ化可能クライアントやIIOP (Internet Inter-ORB Protocol)クライアント以外では、明示的にweblogic.rmicを実行する必要はありません。

動的プロキシ

リモート・オブジェクトのクライアントが使用するクラス。RMIの場合はスケルトン・クラスとスタブ・クラスが使用されます。スタブ・クラスは、クライアントのJava仮想マシン(JVM)で呼び出されるインスタンス。スケルトン・クラスはリモートJVMに存在し、リモートJVM上で呼び出されたメソッドと引数のマーシャリングを解除し、リモート・オブジェクトのインスタンスのメソッドを呼び出した後、結果をマーシャリングしてクライアントに返します。

セキュリティのサポート

セキュリティ・マネージャは不要。WebLogic Serverは認証、認可、およびJava EEのセキュリティ・サービスを実装しています。

トランザクションのサポート

WebLogic Serverでは、Java Platform, Enterprise Edition (Java EE)プログラミング・モデルのトランザクションがサポートされています。

Internet Protocol version 6 (IPv6)のサポート

128ビット・アドレッシング空間のサポート。

3 WebLogic RMIの機能

この章では、WebLogic Serverで使用するためのRMIのプログラミングに必要なWebLogic RMIの機能とガイドラインについて説明します。

この章には次の項が含まれます:

- WebLogic RMIクライアント

- WebLogic RMIのセキュリティのサポート

- WebLogic RMIのトランザクションのサポート

- RMIオブジェクトのフェイルオーバーとロード・バランシング

- リクエスト・タイムアウト

- 固定サービスの作成

- RMIの動的プロキシ

WebLogic RMIクライアント

WebLogic RMIはクライアントとサーバーのフレームワークに分けられています。実行時のクライアントはサーバーのソケットを持たないため、接続をリスニングしていません。クライアントはサーバーを介して接続を取得します。サーバーだけがクライアントのソケットを認識します。このため、クライアントにあるリモート・オブジェクトをホストする場合、クライアントはWebLogic Serverに接続していなければなりません。WebLogic Serverはクライアントへのリクエストを処理して、クライアントへ情報を渡します。つまり、クライアント側のRMIオブジェクトには、クラスタ内であっても単一のWebLogic Serverを介してのみアクセスできます。クライアント側のRMIオブジェクトがJNDIネーミング・サービスにバインドされている場合、そのオブジェクトへのアクセスは、そのバインドを実行したサーバーにアクセスできる場合に限り可能です。

WebLogic RMIのセキュリティのサポート

WebLogic Serverは認証、認可、およびJava EEのセキュリティ・サービスを実装しています。詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。

WebLogic RMIのトランザクションのサポート

WebLogic Serverでは、Java Platform, Enterprise Edition (Java EE)プログラミング・モデルのトランザクションがサポートされています。WebLogic RMIアプリケーションでのトランザクションの使用の詳細は、以下を参照してください。

- 『Oracle WebLogic Server JTAアプリケーションの開発』のWebLogic Server RMIアプリケーションのトランザクションに関する項では、WebLogic RMIアプリケーションでのトランザクションの実装の概要について説明します。

- 『Oracle WebLogic Server JTAアプリケーションの開発』のRMIアプリケーションのトランザクションに関する項では、WebLogic ServerのRMIアプリケーションでトランザクションを実装する場合の一般的なガイドラインを示します。

RMIオブジェクトのフェイルオーバーとロード・バランシング

以下の節では、WebLogic ServerでサポートされるRMIオブジェクトのフェイルオーバーとロード・バランシングについて説明します。

- クラスタリングされたRMIアプリケーション

- RMIオブジェクトのロード・バランシング

- クラスタリングされたオブジェクトのパラメータ・ベースのルーティング

- ロード・バランサとのWebLogic RMIの統合

クラスタリングされたRMIアプリケーション

クラスタリングされたRMIアプリケーションのフェイルオーバーは、オブジェクトのレプリカ対応スタブを使用して行われます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼出しを再試行します。

クライアントでJava EEサービスを利用できるようにするために、WebLogicは、特定のサービスのRMIスタブを、特定の名前でJNDIツリーにバインドします。RMIオブジェクトの他のインスタンスがクラスタ内の他のサーバーにデプロイされると、RMIスタブはその場所で更新されます。クラスタ内のサーバーに障害が発生すると、他のサーバーのJNDIツリー内のRMIスタブが更新されてサーバーの障害を反映します。

特定のRMIオブジェクトのレプリカ対応スタブを生成するには、WebLogic RMIコンパイラの-clusterableオプションを指定します(表5-1「WebLogic RMIコンパイラのオプション」を参照)。例:

$ java weblogic.rmic -clusterable classes

詳細は、『Oracle WebLogic Serverクラスタの管理』のEJBとRMIのレプリケーションとフェイルオーバーに関する項を参照してください。

RMIオブジェクトのロード・バランシング

RMIオブジェクトのロード・バランシング・アルゴリズムは、クラスタリングされたオブジェクトで取得されるレプリカ対応スタブに保持されます。特定のRMIオブジェクトに対してロード・バランシング・アルゴリズムを、WebLogic RMIコンパイラの-loadAlgorithm <algorithm>オプションを使用して指定します。オブジェクトに構成したロード・バランシング・アルゴリズムは、クラスタのデフォルトのロード・バランシング・アルゴリズムをオーバーライドします。WebLogic Server RMIコンパイラでは、以下のロード・バランシング・アルゴリズムをサポートしています。

- 「ラウンドロビンのロード・バランシング」

- 「重みベースのロード・バランシング」

- 「ランダム・ロード・バランシング」

- 「サーバー・アフィニティ・ロード・バランシング・アルゴリズム」

たとえば、RMIオブジェクトのロード・バランシングをラウンドロビンに設定するには、次のrmicオプションを使用します。

$ java weblogic.rmic -clusterable -loadAlgorithm round-robin classes

RMIオブジェクトのロード・バランシングを重みベースのサーバー・アフィニティに設定するには、次のrmicオプションを使用します。

$ java weblogic.rmic -clusterable -loadAlgorithm weight-based -stickToFirstServer classes

詳細は、『Oracle WebLogic Serverクラスタの管理』のEJBとRMIオブジェクトのロード・バランシングに関する項を参照してください。

クラスタリングされたオブジェクトのパラメータ・ベースのルーティング

パラメータ・ベースのルーティングでは、ロード・バランシング動作をより詳細なレベルで制御できます。クラスタリングされたオブジェクトを、weblogic.rmi.cluster.CallRouterインタフェースを使用してCallRouterに割り当てることができます。これはパラメータにより各呼出しの前に呼び出されるクラスです。CallRouterはそのパラメータを自由に調べ、呼出しの送り先となるネーム・サーバーを返します。

weblogic.rmi.cluster.CallRouter.

Class java.lang.Object
Interface weblogic.rmi.cluster.CallRouter
(extends java.io.Serializable)

パラメータ・ベースのルーティングを可能にするには、このインタフェースを実装するクラスをRMIコンパイラ(rmic)に与える必要があります。以下のオプションを使って(すべて1行に入力します)、サービス実装時にrmicを実行します。

$ java weblogic.rmic -clusterable -callRouter <callRouterClass> <remoteObjectClass>

リモート・メソッドが呼び出されるたびに、クラスタリング可能なスタブからコール・ルーターを呼び出します。コール・ルーターは、その呼出しの宛先のサーバーの名前を返します。

クラスタ内の各サーバーは、WebLogic Serverコンソールで定義された名前で固有に識別されます。これらの名前は、メソッド・ルーターがサーバーを識別するための名前となります。

ExampleImplというクラスを例に説明します。このクラスは、メソッドfooでリモート・インタフェースExampleを実装します。

public class ExampleImpl implements Example {
public void foo(String arg) { return arg; }
}

このCallRouterを実装したExampleRouterでは、'arg' < "n"の場合にすべてのfoo呼出しがserver1 (server1に届かない場合はserver3)に送られ、'arg' >= "n"の場合にすべての呼出しがserver2 (server2に届かない場合はserver3)に送られます。

public class ExampleRouter implements CallRouter {
private static final String[] aToM = { "server1", "server3" };
private static final String[] nToZ = { "server2", "server3" };

public String[] getServerList(Method m, Object[] params) {
if (m.GetName().equals("foo")) {
if (((String)params[0]).charAt(0) < 'n') {
return aToM;
} else {
return nToZ;
}
} else {
return null;
}
}
}

次のrmic呼出しは、ExampleRouterとExampleImplを関連付けて、パラメータ・ベースのルーティングを有効にします。

$ rmic -clusterable -callRouter ExampleRouter ExampleImpl

カスタム呼出しルーティングと連結の最適化

オブジェクトがレプリカを呼び出している同じサーバー・インスタンス上にレプリカがある場合、ローカル・レプリカを使用する方が効率的なので、その呼出しはロード・バランシングの対象にはなりません。詳細は、『Oracle WebLogic Serverクラスタの管理』の連結されたオブジェクトの最適化に関する項を参照してください。

リクエスト・タイムアウト

リモート・コールが完了するタイムアウト期間を指定できます。あるいは、クライアントがweblogic.rmi.extensions.RequestTimeoutExceptionを受信します。

WebLogic Serverには、次の接続タイムアウトと読取りタイムアウトがあります。

- 接続タイムアウトの使用

- 読取りタイムアウトの使用

接続タイムアウトの使用

接続タイムアウトを使用して、ブートストラップと再確立の対象となるサーバーへの接続をクライアントが待機する時間を定義します。次の表で、このタイムアウトの設定方法について説明します。

表3-1 接続タイムアウトの設定

説明

スコープ

システム・プロパティ: -Dweblogic.ConnectTimeout=milliseconds

サーバー

KernelMBean.ConnectTimeoutプロパティを設定します

サーバー

NetworkAccessPointMBean.connectTimeoutプロパティを設定します。デフォルト以外のチャネルの場合のみ、サーバー・スコープ設定をオーバーライドします。このチャネル定義を使用して確立された接続のみがこのタイムアウトの影響を受けます。

チャネル

WLContext.CONNECT_TIMEOUTを設定して、サーバーへの接続を確立します。(コンテキストのスコープ内で、接続のブートストラップと失われた接続の再確立の両方に使用されます。)

スレッド

読取りタイムアウトの使用

読取りタイムアウトを使用して、クライアントがサーバーからのレスポンスの受信を待機する時間を定義します。次の表で、このタイムアウト値を設定する様々な方法について説明します。

表3-2 読取りタイムアウトの設定

説明

スコープ

リモート・スタブのルックアップに使用されるJNDI (InitialContext)環境でWLContext.RESPONSE_READ_TIMEOUTを設定します。

インタフェース(スタブ)

リモート・オブジェクト実装クラスでメソッド・レベル・アノテーション(@RmiMethod(timeout=<値>))を指定します。

メソッド

非アノテーション付きクラスのrtd.xmlファイルのメソッド定義でタイムアウト属性を設定します。「タイムアウトを含むrtd.xmlファイルの例」を参照してください。

メソッド

EJB Bean実装クラスでメソッド・レベル・アノテーション(@TransactionTimeoutSeconds(<timeout>)))を指定します。

メソッド

EJB記述子(weblogic-ejb-jar.xml)でリモート・クライアント・タイムアウトを指定します。「タイムアウトを含むweblogic-ejb-jar.xmlファイルの例」を参照してください。

メソッド

読取りタイムアウトを実装する際は次のことを考慮します。

- WebLogic Server EJB Bean実装では、トランザクション・タイムアウト(@TransactionTimeoutSeconds)がremote-client-timeoutよりも大きい場合、トランザクション・タイムアウトが優先されます。

- 複数の読取りタイムアウトの優先順位は、次のルールで決まります。

- クライアントのrtd.xmlで指定されたタイムアウトは、他のどの読取りタイムアウトよりも優先されます。

- RmiMethodアノテーションを使用して指定されたタイムアウトは、WLContext.RESPONSE_READ_TIMEOUTよりも優先されます。

タイムアウトを含むrtd.xmlファイルの例

次のコードでは、タイムアウトを含むrtd.xmlファイルの例を示します。

<rmi Name="foo">
<method
name="methodname"
timeout="timeoutinmilliseconds">
</method>
</rmi>

クライアントでrtd.xml fileを生成するには、クライアントとサーバーの両方で-Dweblogic.RefreshClientRuntimeDescriptor=trueを設定します。フラグがtrueの場合、rtd.xmlファイルをクラスパスで使用できるかどうかの確認が行われます。使用可能な場合、ファイルは読み取られ、指定された値が使用されます。

タイムアウトを含むweblogic-ejb-jar.xmlファイルの例

次のコードでは、weblogic-ejb-jar.xmlファイルでremote-client-timeoutを指定する方法の例を示します。

<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
. . .
<remote-client-timeout>5</remote-client-timeout>
</weblogic-enterprise-bean>

固定サービスの作成

weblogic.rmicを使って、レプリケートされないスタブをクラスタ内に生成することもできます。このようなスタブは、「固定」サービスと呼ばれています。これらのスタブは登録されたホストからのみ使用可能であり、透過的なフェイルオーバーやロード・バランシングは提供しません。固定サービスはレプリケートされたクラスタ全体のJNDIツリーにバインドされるので、クラスタ全体で使用可能になります。ただし、固定サービスをホストする各サーバーが故障しても、クライアントは別のサーバーにフェイルオーバーすることはできません。

特定のRMIオブジェクトのレプリケートされないスタブを生成するには、WebLogic RMIコンパイラの-clusterableオプションは指定しません(表5-1「WebLogic RMIコンパイラのオプション」を参照)。例:

$ java weblogic.rmic classes

RMIの動的プロキシ

動的プロキシまたはプロキシは、リモート・オブジェクトのクライアントで使用されるクラスです。このクラスには、実行時にクラスが作成されたときに指定されるインタフェースのリストが実装されます。RMIでは、動的に生成されたバイトコードとプロキシ・クラスが使用されます。プロキシ・クラスは、クライアントのJava仮想マシン(JVM)で呼び出されるインスタンスです。プロキシ・クラスは、呼び出されたメソッド名とその引数をマーシャリングして、リモートのJVMに転送します。リモート呼出しが終了して戻された後に、プロキシ・クラスはクライアント上でその結果のマーシャリングを解除します。生成されたバイトコード(リモートJVMに存在)は、リモートJVM上で呼び出されたメソッドと引数のマーシャリングを解除し、リモート・オブジェクトのインスタンスのメソッドを呼び出した後、結果をマーシャリングしてクライアントに戻します。

4 WebLogic RMIアノテーションの使用

この章では、プレーンJavaオブジェクトへのリモート・アクセスを提供するWebLogic RMIアノテーションについて説明します。

WebLogic RMIは、各種セキュリティ、トランザクション、クラスタリングおよびタイムアウト属性をリモート・クラスやそのメソッドに関連付けるリッチ記述子フレームワークを備えています。これらの属性は、リモート・オブジェクト実装がWebLogic JNDIツリーにバインドされる場合、リモート以外のインタフェースを含むプレーンJava実装クラスでアノテーションとして指定できます。Oracle WebLogic Server Java APIリファレンスのweblogic.rmi.annotationに関する項を参照してください。

この章には次の項が含まれます:

- WebLogic RMIアノテーションの概要

- WebLogic RMIのアノテーション

- 例外処理

- クラスタ・フェイルオーバー

- RMIコールバック・オブジェクト

- アノテーションとWebLogic RMI記述子のマージ

WebLogic RMIアノテーションの概要

WebLogic RMIでは、リモートJavaオブジェクト内に組込み可能なアノテーションのサポートが提供され、コンパイル済クラスでのweblogic.rmicツールの実行を回避できることで、開発が簡素化されます。

プレーンJavaオブジェクトにリモートでアクセスできるようにするには、次の操作を実行します。

1. クライアントでアクセスするインタフェースを作成します。このインタフェースはjava.rmi.Remoteを拡張する必要があります。例4-1を参照してください。

2. 手順1のインタフェースを実装する実装クラスを作成します。

3. 目的のアノテーション@Rmiまたは@RmiMethodを、手順2で追加された実装クラスに追加します。アノテーションはインタフェースではなく、実装クラスやメソッドに指定する必要があります。

4. アプリケーションのクラスをコンパイルしてバンドルします。

5. アプリケーションをデプロイします。

6. WebLogic JNDIツリーで、アノテーション付きプレーンJavaオブジェクトをバインドします。

7. クライアントは、WebLogic JNDIツリーのリモート・オブジェクトとしてプレーンJavaオブジェクトをルックアップし、それをリモート・インタフェースとしてアノテーションが付けられたプレーン・インタフェースに絞り込みます。対応するスタブは、クライアントで生成されるか、ダウンロードされるか、WebLogic RMIコンパイラを使用して事前生成されるかのいずれかになり、クライアントで利用可能になります。

注意:
Sun RMIコンパイラに基づいてスタブやスケルトンを生成する場合、WebLogic RMICオプションは使用しないでください。

例4-1 RMIアノテーションの例

package myrmi.example;

import java.rmi.RemoteException;
import java.util.concurrent.Future;
import java.util.concurrent.FutureTask;

import weblogic.rmi.annotation.Rmi;
import weblogic.rmi.annotation.RmiMethod;

@Rmi(remoteInterfaces={MyRemoteInterface.class})
public class RmiMethodAnnotations implements MyRemoteInterface{
public RmiMethodAnnotations() {
}

public int getIndex() throws RemoteException {
return 0;
}

@RmiMethod(asynchronousResult=true)
public Future<String> ejbAsynchronousSayHello(String name) {
return new FutureTask(new MyRunnable(), new Object());
}

class MyRunnable implements Runnable {

public void run() {
}
}
}

これにより、WebLogic RMIレイヤーは、RmiMethodAnnotationsオブジェクトがWLS JNDIツリーにバインドされる場合、それをリモート・オブジェクトとして扱うことができます。

例4-2に、アノテーションを使用せずに同じメソッドを実装するコード例を示します。

例4-2 アノテーションを使用しないRMIの例

package myrmi.example;

import java.rmi.Remote;
import java.rmi.RemoteException;

import java.util.concurrent.Future;

public interface MyRemoteInterface extends Remote {

int getIndex() throws RemoteException;

public Future<String> ejbAsynchronousSayHello(String name);

public String sayBye();

}

WebLogic RMIのアノテーション

次のトピックでは、WebLogic RMIアノテーションに関するリファレンス情報を提供します。

- Rmi

- RmiMethod

Rmi

以降の節では、このアノテーションについて詳しく説明します。

説明

リモート実装クラスを指定するリモート・オブジェクトにクラスレベルのアノテーション・サポートを提供します。

「weblogic.rmi.annotation.Rmi」を参照してください。

属性

次の表で属性について簡単に説明します。

表4-1 Rmiアノテーションの属性

名前

説明

データ型

デフォルト値

callRouterClassname

コールのパラメータで各呼出し前にコールされるCallRouterクラス。コールのルーティング先のネーム・サーバーを返します。パラメータベースのルーティングにより、詳細なロード・バランシング動作を指定できます。

String

""

clusterable

リモート・オブジェクトがクラスタ可能かどうかを示します。

boolean

false

defaultRMIMethodParams

デフォルトのRMIメソッドのアノテーション。メソッド・アノテーションでオーバーライドできます。

RmiMethod

@weblogic.rmi.annotation.RmiMethod

loadAlgorithm

クラスタ化されるリモート・オブジェクトのロード・アルゴリズム。有効値は、次のとおりです。

- RANDOM

- ROUND_ROBIN

- WEIGHT_BASED

- SERVER_AFFINITY

- ROUND_ROBIN_AFFINITY

- RANDOM_AFFINITY

- WEIGHT_BASED_AFFINITY

- DEFAULT

デフォルトはROUND_ROBINです。

LoadAlgorithmType

weblogic.rmi.annotation.LoadAlgorithmType.DEFAULT

stickToFirstServer

スティッキーなロード・バランシングを有効にします。最初のリクエストをサービスするために選ばれたサーバーが、後続のすべてのリクエストにも使用されます。クラスタ可能なリモート・オブジェクトにのみ使用されます。

boolean

false

remoteInterfaces

リモート・インタフェースとして扱われるインタフェース・クラス名のカンマ区切りリスト。

Class

""

RmiMethod

以降の節では、このアノテーションについて詳しく説明します。

説明

リモート実装クラスを指定するリモート・オブジェクトにメソッドレベルのアノテーション・サポートを提供します。

「weblogic.rmi.annotation.RmiMethod」を参照してください。

属性

次の表で属性について簡単に説明します。

表4-2 RmiMethodアノテーションの属性

名前

説明

データ型

デフォルト値

asynchronousResult

trueの場合、非同期処理するメソッドをマークします。通常、メソッドを呼び出す場合、メソッド実行が完了するとすぐに結果が返されます。asynchronousResult=trueの場合、メソッドの戻りタイプはvoidまたはFutureオブジェクトのいずれかになります。タイプがFutureオブジェクトの場合、それをポーリングして、結果が利用可能かどうかを確認できます。タイプがvoidの場合、メソッドは非同期の一方向コールとして扱われます。

boolean

false

dispatchPolicy

リモート・オブジェクト・リクエストのスケジュールに使用されるワーク・マネージャを指定します。

String

""

idempotent

多重呼出し不変メソッドを指定します。

boolean

false

oneway

一方向のコールを指定します。

boolean

false

timeout

リモート・コールのタイムアウトを指定します。

int

0

transactional

トランザクション・メソッドを指定します。指定しない場合、RMIコールを行う前にトランザクションを中断し、コールが完了した後にトランザクションを再開します。

boolean

false

例外処理

次の項では、WebLogic RMIアノテーションの例外処理について説明します。

- アプリケーションの例外

- システム例外

アプリケーションの例外

クライアントは、確認されたすべてのアプリケーション例外を受信します。

システム例外

クライアントは、リモート・メソッドの呼出し時に発生したすべてのエラーとランタイム例外を受信します。

リモート例外は次のように処理されます。

- 確認された例外は、クライアントに直接スローされます。

- 未確認の例外はRuntimeExceptionにラップされてから、クライアントにスローされます。

- 生成されたEJB 3.0オブジェクトは、すべてのEJBメソッドのEJBExceptionになるようにremoteExceptionWrapperにアノテーションを付けます。クライアントは、EJBExceptionにラップされたすべてのリモート例外を受信します。

remoteExceptionWrapperアノテーションは、実装クラス全体に対して、または指定したランタイム例外にすべてのリモート例外をラップする特定のメソッドに対して指定してから、クライアントに戻すことができます。remoteExceptionWrapperアノテーションを指定しない場合、リモート例外は、表4-3に示すようにラップされます。

表4-3 WebLogicクライアントでの例外のラップ

クライアント

例外のラップ

WLフル・クライアント

RemoteRuntimeException脚注1は、RemoteExceptionをラップします。

WLシンT3クライアント

RemoteRuntimeException脚注2は、RemoteExceptionをラップします。

WLS-IIOPクライアント脚注3

RemoteRuntimeExceptionは、RemoteExceptionをラップするjava.rmi.ServerExceptionをラップします。

または

RemoteRuntimeExceptionはRemoteExceptionをラップします

シン・クライアント

java.lang.RuntimeExceptionは、RemoteExceptionをラップするServerExceptionをラップします。

または

RuntimeExceptionはRemoteExceptionをラップします

Java SEクライアント

java.lang.RuntimeExceptionは、RemoteExceptionをラップするServerExceptionをラップします。

または

RuntimeExceptionはRemoteExceptionをラップします

脚注1weblogic.rmi.extensions.RemoteRuntimeExceptionは、RuntimeExceptionのサブクラスです。

脚注2weblogic.rmi.extensions.RemoteRuntimeExceptionは、RuntimeExceptionのサブクラスです。

脚注3既存のT3プロトコル・レイヤーは、常にRemoteExceptionをjava.rmi.ServerExceptionとしてラップしませんが、IIOPプロトコルはサーバーで常にこれをラップします。

クラスタ・フェイルオーバー

クラスタ化されたスタブは、受信した例外のタイプに基づき、クラスタの別のノードへのリモート・コールのフェイルオーバーを自動で処理します。スタブのRuntimeExceptionのようなリモート例外をラップしても、リモート・オブジェクトのフェイルオーバー動作は変わりません。

RMIコールバック・オブジェクト

アノテーション付きリモート・オブジェクトを含むコールバック・オブジェクトを渡すには、extend java.rmi.Remoteインタフェースへのコールバック・リモート・オブジェクトが必要です。

注意:
一部のクライアント・タイプでは、WebLogicクラスにアクセスできないため、コールバック・オブジェクトをサポートできません。たとえば、Java SEクライアントなどがあります。

アノテーションとWebLogic RMI記述子のマージ

実装クラスで指定されたアノテーションは、サーバーでオーバーライドできません。アプリケーション記述子とデプロイメント・プランをマージして、記述子の値の正しいセットが使用されるようにする必要があります。

5 WebLogic RMIコンパイラの使い方

この章では、WebLogic RMIコンパイラの機能とオプションの使用方法について説明します。

この章には次の項が含まれます:

- WebLogic RMIコンパイラの概要

- WebLogic RMIコンパイラの機能

- WebLogic RMIコンパイラのオプション

- Java SEの拡張

WebLogic RMIコンパイラの概要

WebLogic RMIコンパイラ(weblogic.rmic)は、リモート・オブジェクトを生成してコンパイルするためのコマンド行ユーティリティです。weblogic.rmicは、クライアント側でアプリケーションのカスタム・リモート・オブジェクト・インタフェースに対して動的プロキシを生成し、サーバー側オブジェクトにホット・コード生成を提供します。

クラスタ化可能クライアントまたはIIOPクライアントの場合は、明示的にweblogic.rmicを実行するだけです。WebLogic RMI over IIOPを使用すると、クライアントは、Internet Inter-ORB Protocol (IIOP)を介してRMIリモート・オブジェクトにアクセスできるため、RMIプログラミング・モデルが拡張されます。第9章「RMI over IIOPの使用」を参照してください。

WebLogic RMIコンパイラの機能

以下の節では、このリリースのWebLogic RMIコンパイラの機能について説明します。

- ホット・コード生成

- プロキシの生成

- WebLogic RMIコンパイラのその他の機能

ホット・コード生成

rmicを実行すると、WebLogic Serverのホット・コード生成機能により、メモリー内にサーバー・クラス用のバイトコードが自動生成されます。バイトコードは、リモート・オブジェクトの必要に応じて、動的に生成されます。現在のバージョンのWebLogic Serverでは、weblogic.rmicを実行しても、オブジェクトのスケルトン・クラスは生成されません。

ホット・コード生成では、クライアント上の動的プロキシからのリクエストを処理する、サーバー側のクラスのバイト・コードを作成します。動的に生成されたバイト・コードはクライアント・リクエストをデシリアライズし、実装クラスに対して実行します。次に結果をシリアライズしてクライアントのプロキシへ送り返します。クラスの実装は、Weblogic ServerのJNDIツリーの名前にバインドされます。

プロキシの生成

Weblogic RMIコンパイラでは、デフォルトの動作でリモート・インタフェース用のプロキシとそのプロキシを共有するリモート・クラス用のプロキシが作成されます。プロキシは、リモート・オブジェクトのクライアントが使用するクラスです。RMIでは、動的に生成されたバイトコードとプロキシ・クラスが使用されます。

たとえば、example.hello.HelloImplとcounter.example.CiaoImplは、単一のプロキシ・クラスとバイトコード、つまりリモート・オブジェクト(このケースではexample.hello.Hello)によって実装されたリモート・インタフェースに適合するプロキシで表わされます。

リモート・オブジェクトが複数のインタフェースを実装する場合、プロキシの名前とパッケージは1組のインタフェースをエンコードすることによって決定されます。WebLogic RMIコンパイラの-nomanglednamesというオプションを使って、デフォルトの動作をオーバーライドできます。このオプションを使用すると、コンパイル時にリモート・クラスに固有のプロキシが作成されます。クラス固有のプロキシが検出された場合は、そのプロキシはインタフェース固有のプロキシに優先します。

さらに、WebLogic RMIのプロキシ・クラスでは、プロキシはfinalではありません。同じ場所に配置されたリモート・オブジェクトへの参照は、プロキシではなくオブジェクトそのものへの参照です。

動的プロキシ・クラスは、クライアントに渡されるシリアライズ可能クラスです。クライアントは、WebLogic JNDIでクラスをルックアップすることによって、そのクラスのプロキシを取得します。クライアントは、あたかもローカルなクラスであるかのようにプロキシのメソッドを呼び出します。プロキシは、リクエストをシリアライズしてWebLogic Serverに送ります。

WebLogic RMIコンパイラのその他の機能

WebLogic RMIコンパイラには、他にも以下のような機能があります。

- リモート・メソッドのシグネチャはRemoteExceptionをスローする必要がありません。

- リモートの例外はRuntimeExceptionにマップできます。

- リモート・クラスは、非リモート・インタフェースも実装できます。

WebLogic RMIコンパイラのオプション

WebLogic RMIコンパイラは、Javaコンパイラがサポートしているオプションをすべて受け入れます。たとえば、コマンド行のコンパイラ・オプションに-d \classes examples.hello.HelloImplを追加できます。ほかにも、Javaコンパイラがサポートしているすべてのオプションを使用でき、これらのオプションは直接Javaコンパイラに渡されます。

次の表にjava weblogic.rmicオプションを示します。これらのオプションは、java weblogic.rmicの後、リモート・クラス名の前に入力します。

$java weblogic.rmic [options] <classes>...

表5-1 WebLogic RMIコンパイラのオプション

オプション

説明

-help

オプションの説明を表示します。

-version

バージョン情報を出力します。

-d <dir>

コンパイルの対象(最上位)ディレクトリを指定します。

-dispatchPolicy <queueName>

サービスがWebLogic Serverの実行スレッドを取得するために使用する、構成済の実行キューを指定します。

-oneway

すべての呼出しが一方向呼出しであることを指定します。

-idl

リモート・インタフェース用のIDLを生成します。

-idlOverwrite

既存のIDLファイルを上書きします。

-idlVerbose

IDL情報についての冗長な情報を表示します。

-idlDirectory <idlDirectory>

IDLファイルを作成するディレクトリを指定します(デフォルトは現在のディレクトリ)。

-idlFactories

値タイプ用にファクトリ・メソッドを生成します。

-idlNoValueTypes

値タイプ、およびそれを含むメソッドと属性が生成されないようにします。

-idlNoAbstractInterfaces

抽象インタフェース、およびそれを含むメソッドと属性が生成されないようにします。

-idlStrict

OMG規格に従ってIDLを生成します。

-idlVisibroker

Visibroker 4.5 C++との互換性があるIDLを生成します。

-idlOrbix

Orbix 2000 2.0 C++との互換性があるIDLを生成します。

-iiopTie

Sunバージョンのrmicを使用してCORBAスケルトンを生成します。

-iiopSun

Sunバージョンのrmicを使用してCORBAスタブを生成します。

-nontransactional

RMI呼出しを行う前にトランザクションをサスペンドし、呼出しが完了した後に再開します。

-compiler <javac>

Javaコンパイラを指定します。指定されない場合、-compilerclassオプションが使用されます。

-compilerclass <com.sun.tools.javac.Main>

呼び出すコンパイラ・クラス。

-clusterable

そのサービスをクラスタ化可能(WebLogicクラスタ内の複数のサーバーがホストできます)として指定します。各ホスティング・オブジェクト、またはレプリカは、共通名でネーミング・サービスにバインドされます。そのサービス・スタブがネーミング・サービスから取り出される場合、それはレプリカのリストを保持するレプリカ対応参照を含み、レプリカ間のロード・バランシングやフェイルオーバーを行います。

-loadAlgorithm <algorithm>

-clusterableと組み合せた場合だけ使用可能。ロード・バランシングおよびフェイルオーバーに使用する、サービス固有のアルゴリズムを指定します(デフォルトはweblogic.cluster.loadAlgorithm)。ラウンドロビン、ランダム、重みベースの中から1つ選択できます。

-callRouter <callRouterClass>

このクラスタ固有のオプションは、-clusterableと組み合せて使用され、ルーティング・メソッド呼出し用に使われるクラスを指定します。このクラスはweblogic.rmi.cluster.CallRouterを実装する必要があります。指定した場合、各メソッド呼出しの前にそのクラスのインスタンスが呼び出され、そのメソッド・パラメータに基づいてルーティングするサーバーを指定できます。サーバー名またはnullが返されます。nullは現在のロード・アルゴリズムが使用されることを示します。

-stickToFirstServer

このクラスタ固有のオプションは、-clusterableと組み合せて使用され、セッション維持型ロード・バランシングを有効にします。最初のリクエストをサービスするために選ばれたサーバーが、後続のすべてのリクエストにも使用されます。

-methodsAreIdempotent

このクラスタ固有のオプションは、-clusterableと組み合せて使用され、このクラスのメソッドが多重呼出し不変であることを示します。これにより、リモート・メソッドが呼び出される前に起きた障害かどうか確認できなくても、通信障害があれば、スタブはそのリカバリを試みることができるようになります。デフォルトでは(このオプションが使われなければ)、スタブは、リモート・メソッドが呼び出された前に起きたことが確認されている障害に関してだけ再試行します。

-iiop

サーバーからIIOPスタブを生成します。

-iiopDirectory

IIOPプロキシ・クラスが作成されるディレクトリを指定します。

-timeout

remote-client-timeoutと組み合せて使用されます。

-commentary

アノテーションを出力します。

-nomanglednames

コンパイル時にリモート・クラスに固有のプロキシが作成されます。

-g

デバッグ情報をクラスにコンパイルします。

-O

最適化しながらコンパイルします。

-nowarn

警告なしでコンパイルします。

-verbose

冗長情報を出力してコンパイルします。

-verboseJavac

Javaコンパイラによる冗長情報の出力を有効にします。

-nowrite

.classファイルが生成されないようにします。

-deprecation

非推奨となった呼出しについて警告します。

-classpath <path>

使用するクラス・パスを指定します。

-J<option>

Java実行時にフラグを渡すために使用します。

-keepgenerated

WebLogic RMIコンパイラを実行するときに、生成したスタブ・クラスとスケルトン・クラスのソースを保持できます。

-disableHotCodeGen

コンパイル時にスタブおよびスケルトン・クラスが作成されます。

レプリケートされないスタブの生成

weblogic.rmicを使って、レプリケートされないスタブをクラスタ内に生成することもできます。このようなスタブは、「固定」サービスと呼ばれています。これらのスタブは登録されたホストからのみ使用可能であり、透過的なフェイルオーバーやロード・バランシングは提供しません。固定サービスはレプリケートされたクラスタ全体のJNDIツリーにバインドされるので、クラスタ全体で使用可能になります。ただし、固定サービスをホストする各サーバーが故障しても、クライアントは別のサーバーにフェイルオーバーすることはできません。

永続的なコンパイラ・オプションの使用

デプロイメントの際には、appcとejbcによりRMIコンパイラを使用して各EJBコンテナ・クラスが実行され、スタブとスケルトンを動的に生成するのに必要なRMI記述子が作成されます。weblogic-ejb-jar.xmlファイルを使用して、iiop-security-descriptor要素を永続化できます。詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のweblogic-ejb-jar.xml要素に関する項を参照してください。

Java SEの拡張

Java RMIのJava SE拡張の詳細は、http://docs.oracle.com/javase/6/docs/technotes/guides/rmi/を参照してください。

6 WebLogic RMIでのT3プロトコルの使い方

この章では、WebLogic RMIでのT3プロトコルの使用方法について説明します。

この章には次の項が含まれます:

- WebLogic ServerにおけるRMI通信

- 接続の可用性の判断

- WebLogic T3/T3sクライアント・プロキシの使い方

WebLogic ServerにおけるRMI通信

WebLogic ServerのRMI通信では、WebLogic Serverと他のJavaプログラム(クライアントおよび他のWebLogic Serverインスタンスを含む)との間のデータを、T3プロトコルを使用してトランスポートします。サーバー・インスタンスは、接続された個々のJava仮想マシン(JVM)を追跡して、JVMに対するすべてのトラフィックを実行できる単一のT3接続を作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのT3プロトコルの構成に関する項を参照してください。

たとえば、JavaクライアントがWebLogic Server上のエンタープライズBeanおよびJDBC接続プールにアクセスすると、1つのネットワーク接続がWebLogic ServerのJVMとクライアントのJVMとの間に確立されます。T3プロトコルは1つの接続上のパケットを見えない形で多重化するため、EJBおよびJDBCのサービスでは、専用のネットワーク接続を単独で使用しているかのように記述することができます。

接続の可用性の判断

有効なT3接続を備える任意の2つのJavaプログラム(2つのサーバー・インスタンス、またはサーバー・インスタンスとJavaクライアントなど)では、定期的なポイントツーポイントの「ハートビート」を使って、継続的な可用性の通知と判断を行います。各エンド・ポイントは、定期的にピアへのハートビートを発行し、また同様に、ピアから継続的にハートビートが受信されていることに基づき、ピアがまだ使用可能であることを判断します。

- サーバー・インスタンスがハートビートを発行する頻度は、ハートビート間隔によって決定されます。これはデフォルトでは60秒です。

- ピアが使用できなくなっていると判断するまでにサーバー・インスタンスが待機する、ピアから届かなかったハートビートの数は、ハートビート周期によって決定されます。これはデフォルトでは4です。したがって、各サーバー・インスタンスは、ピアがアクセス不能であると判断する前に、240秒間すなわち4分間まで、メッセージ(ハートビート、またはその他の通信)のない状態で待機します。

- タイムアウトのデフォルトを変更することは推奨しません。

WebLogic T3/T3sクライアント・プロキシの使い方

WebLogic T3/T3sクライアント・プロキシを使用すると、アウトバウンド・クライアント・リクエストをプロキシWebLogic T3サーバーにルーティングできます。この場合、各クライアントはすべてのアウトバウンド・リクエストをプロキシ・サーバーにルーティングします。次に、プロキシ・サーバーが、リクエストを処理するWebLogic Serverインスタンスにリクエストを転送します。クライアント側とサーバー側の両方で、T3接続をクライアントとして使用するすべてのアプリケーションにこの構成が影響します。たとえば、アプリケーションがT3接続を作成してWebLogic T3サーバーにアクセスする場合(WebLogic RMIを使用するリモート・オブジェクトでのメソッドの呼出しなど)、プロキシ構成が接続ロジックに適用されます。

クライアント・プロキシを有効にするには、以下のプロパティを設定します。

T3:

-Dhttp.proxyHost=<proxy hostname>
-Dhttp.proxyPort=<proxy port>
-Dhttp.nonProxyHosts=<hostnames>

T3s:

-Dhttps.proxyHost=<proxy hostname>
-Dhttps.proxyPort=<proxy port>
-Dhttps.nonProxyHosts=<hostnames>

説明:

- proxy hostnameはユーザーのプロキシ・サーバーのネットワーク・アドレス。

- proxy portはポート番号。明示的に設定しない場合、ポート番号の値は80に設定されます。

- hostnamesは、WebLogic Serverがプロキシ構成から除外する1つ以上のホスト名を「|」で区切ったリスト。照合のためにワイルドカード文字「*」を使用できます。たとえば、「-Dhttp.nonProxyHosts="*.oracle.com|localhost"」と指定します。

7 WebLogic RMIの実装方法

この章では、すべてのリモート・オブジェクトの基本的な構成要素であるjava.rmi.Remoteインタフェースについて説明します(ただし、このインタフェースにはメソッドは含まれません)。この「タグ付け」インタフェースを拡張し(リモート・クラスを識別するタグとして機能するように)、リモート・オブジェクトの構造を作成するメソッド・スタブを使って、使用するリモート・インタフェースを作成します。次に、リモート・クラスを使ってリモート・インタフェースを実装します。この実装はレジストリ内の名前にバインドされ、クライアントやサーバーはそこからオブジェクトをルックアップしてリモートで使用できます。

すでにRMIクラスを記述している場合は、リモート・インタフェースとそれを拡張するクラスでimport文を変えるだけでWebLogic RMIをインストールできます。クライアント・アプリケーションにリモート呼出しを追加するには、レジストリ内でオブジェクトを名前でルックアップします。Weblogic RMI例外はjava.rmi例外と同じ機能を備えているので、既存のインタフェースと実装で例外の処理方法を変える必要がありません。

この章には次の項が含まれます:

- リモートで呼び出すことができるクラスの作成

- RMI Helloサンプル・コードの実行

リモートで呼び出すことができるクラスの作成

独自のWebLogic RMIクラスを簡単な手順で記述できます。

- 手順1: リモート・インタフェースの作成

- 手順2: リモート・インタフェースの実装

- 手順3: リモート・メソッドを呼び出すクライアントの作成

- 手順4: Javaクラスのコンパイル

ステップ1. リモート・インタフェースの作成

リモートで呼び出せるすべてのクラスは、リモート・インタフェースを実装します。次のガイドラインに従って、リモート・インタフェースを作成します。

- リモート・インタフェースは、java.rmi.Remoteインタフェースを拡張する必要がありますが、これにはメソッド・シグネチャは含まれません。インタフェースを実装する各リモート・クラスで実装されるメソッド・シグネチャを含めます。

- リモート・インタフェースはパブリックでなければなりません。パブリックでない場合、クライアントはリモート・インタフェースを実装するリモート・オブジェクトをロードしようとするとエラーを受け取ります。

- インタフェース内の各メソッドがそのthrowsブロックでjava.rmi.RemoteExceptionを宣言する必要はありません。アプリケーションがスローする例外は、アプリケーション固有の例外である可能性があり、RuntimeException.WebLogic RMI subclasses java.rmi.RemoteExceptionを拡張する場合があります。したがって、すでにRMIクラスがある場合、例外処理を変更する必要はありません。

- リモート・インタフェースにはコードがあまり記述されていない場合もあります。必要なのは、リモート・クラスで実装するメソッドのメソッド・シグネチャだけです。
以下の例に、メソッド・シグネチャsayHello()を持つリモート・インタフェースを示します。

例7-1 Hello.javaリモート・インタフェース

package examples.rmi.hello;

import java.rmi.RemoteException;
/**
* This interface is the remote interface.
*
* Copyright (c) 1999,2012, Oracle and/or its affiliates. All Rights Reserved.
*/
public interface Hello extends java.rmi.Remote {
String sayHello() throws RemoteException;
}

WebLogic RMIは、柔軟性の高い実行時のコード生成をサポートします。つまり、WebLogic RMIは、型さえ正しければ、そのほかはインタフェースを実装するクラスに依存しない動的プロキシと動的に生成されるバイトコードもサポートします。クラスが単一のリモート・インタフェースを実装する場合、コンパイラが生成したプロキシとバイトコードは、リモート・インタフェースと同じ名前になります。クラスが複数のリモート・インタフェースを実装する場合、コンパイルから生じたプロキシとバイトコードの名前は、コンパイラが使用する名前マングリングによって決まります。

ステップ2. リモート・インタフェースの実装

リモートで呼び出すクラスを作成します。このクラスは、ステップ1で記述したリモート・インタフェースを実装する必要があります。これは、インタフェースに含まれるメソッド・シグネチャを実装することを意味します。WebLogic RMIで行われるコード生成はすべて、このクラス・ファイルに依存します。

- クラスは、複数のリモート・インタフェースを実装できます。また、クラスにはリモート・インタフェースにないメソッドも定義できますが、このようなメソッドはリモートで呼び出せません。

- 例7-2では、HelloImplを作成するクラスを実装し、それをレジストリ内の一意の名前HelloServerにバインドします。メソッドsayHello()により、挨拶が表示されます。

- main()メソッドは、リモート・オブジェクトのインスタンスを作成し、それを名前(オブジェクトの実装を指し示すURL)にバインドすることによってWebLogic JNDIツリーに登録します。リモートでオブジェクトを使用するためにプロキシを取得しようとするクライアントは、オブジェクトを名前でルックアップできます。

例7-2 HelloImpl.javaリモート・インタフェースの実装

package examples.rmi.hello;

import javax.naming.*;
import java.rmi.RemoteException;

/**
* Copyright (c) 1999,2012, Oracle and/or its affiliates. All Rights Reserved.
*/
public class HelloImpl implements Hello{
private String name;

/**
* Constructs a HelloImpl with the specified string.
*
* @param s                 String message
*/
public HelloImpl(String s) throws RemoteException {
super();
name = s;
}

/**
* Returns a string.
*
* @return                  String message
* @exception               java.rmi.RemoteException
*/
public String sayHello() throws java.rmi.RemoteException {
return  "Hello World!";
}

/**
* Allows the WebLogic Server to instantiate this implementation
* and bind it in the registry.
*/
public static void main(String args[]) throws Exception {

try {
HelloImpl obj = new HelloImpl("HelloServer");
Context ctx = new InitialContext();
ctx.bind("HelloServer", obj);
System.out.println("HelloImpl created and bound in the registry " +
"to the name HelloServer");

}
catch (Exception e) {
System.err.println("HelloImpl.main: an exception occurred:");
System.err.println(e.getMessage());
throw e;
}
}
}

WebLogic RMIでは、アプリケーションにセキュリティを統合するためにセキュリティ・マネージャを設定する必要はありません。セキュリティは、WebLogicのSSLとACLのサポートによって処理されます。

手順3: リモート・メソッドを呼び出すクライアントの作成

一般に、初期コンテキストを作成すると、リモート・オブジェクトの参照を取得する単一行のコードのみが取得されます。これは、Naming.lookup()メソッドで行います。次の項では、クライアント作成に関するその他の情報について説明します。

- クライアント・タイムアウトの設定

- HelloClient.javaクライアントの例

クライアント・タイムアウトの設定

初期コンテキストを構成しながら、クライアント側のタイムアウトを設定できます。

- リクエストが接続レスポンスを待機する時間を設定するには、weblogic.jndi.connectTimeoutを使用します。

- 接続の確立後に、リモート・サーバーからのレスポンスをリクエストが待機する時間を設定するには、weblogic.jndi.responseReadTimeoutを使用します。

- 「リクエスト・タイムアウト」を参照してください。

例:

. . .
// Get an InitialContext
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, url);
env.put("weblogic.jndi.connectTimeout", new Long(15000));
env.put("weblogic.jndi.responseReadTimeout", new Long(15000));
return new InitialContext(env);
. . .

HelloClient.javaクライアントの例

次に、例7-2で作成したオブジェクトを使用する短いWebLogicクライアント・アプリケーションを示します。

例7-3 HelloClient.javaクライアントの例

package examples.rmi.hello;

import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

/**
* This client uses the remote HelloServer methods.
*
* @author Copyright (c) 1999,2012, Oracle and/or its affiliates. All Rights Reserved.
*/
public class HelloClient
{
// Defines the JNDI context factory.
public final static String JNDI_FACTORY="weblogic.jndi.WLInitialContextFactory";
int port;
String host;

private static void usage() {
System.err.println("Usage: java examples.rmi.hello.HelloClient " +
"<hostname> <port number>");
}

public HelloClient() {}

public static void main(String[] argv) throws Exception {
if (argv.length < 2) {
usage();
return;
}
String host = argv[0];
int port = 0;
try {
port = Integer.parseInt(argv[1]);
}
catch (NumberFormatException nfe) {
usage();
throw nfe;
}

try {
InitialContext ic = getInitialContext("t3://" + host + ":" + port);
Hello obj = (Hello) ic.lookup("HelloServer");
System.out.println("Successfully connected to HelloServer on " +
host + " at port " +
port + ": " + obj.sayHello() );
}
catch (Exception ex) {
System.err.println("An exception occurred: "+ex.getMessage());
throw ex;
}
}

private static InitialContext getInitialContext(String url)
throws NamingException
{
Hashtable<String,String> env = new Hashtable<String,String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
env.put(Context.PROVIDER_URL, url);
return new InitialContext(env);
}

}

ステップ4. Javaクラスのコンパイル

javacまたは他のJavaコンパイラを使用して.javaファイルをコンパイルし、リモート・インタフェースとそれを実装するクラス用の.classファイルを作成します。

例7-4に、WebLogic Server examplesServerに構成されるserverclassesディレクトリとclientclassesディレクトリに対して、.javaファイルをコンパイルしたり.classファイルをインストールする場合にWebLogic Serverのサンプル環境で使用できるAntスクリプトを示します。

例7-4 Javaクラスをコンパイルするbuild.xmlファイルの例

<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="rmi.hello" default="all" basedir=".">
<property environment="env"/>
<property file="../../../examples.properties"/>
<property name="build.compiler" value="${compiler}"/>
<!-- set global properties for this build -->
<property name="source" value="${basedir}"/>
<target name="all" depends="build"/>
<target name="build" depends="compile.server, compile.client"/>
<!-- Compile server classes into the serverclasses directory -->
<target name="compile.server">
<javac srcdir="${source}"
destdir="${server.classes.dir}"
includes="Hello.java, HelloImpl.java"
classpath="${ex.classpath};${server.classes.dir}"
deprecation="${deprecation}" debug="${debug}" debugLevel="${debugLevel}"
/>
</target>
<!-- Compile client classes into the clientclasses directory -->
<target name="compile.client">
<javac srcdir="${source}"
destdir="${client.classes.dir}"
includes="HelloClient.java"
classpath="${ex.classpath};${server.classes.dir}"
deprecation="${deprecation}" debug="${debug}" debugLevel="${debugLevel}"
/>
</target>
</project>

RMI Helloサンプル・コードの実行

次の手順を使用して、WebLogic RMI Helloサンプルを実行します。

- 前提条件

- RMI Helloサンプルの設定

- 起動クラスの構成

- examplesServerの再起動

- サンプルの実行

前提条件

サンプルを含むWebLogicサーバーをインストールします。examplesServerの起動方法と、シェルに環境を設定してサンプルを実行する方法を把握していることが前提になります。

RMI Helloサンプルの設定

次の手順を使用して、Helloサンプルを設定します。

1. シェルを開き、サンプル環境を設定します。

2. ORACLE_HOME\wlserver\samples\server\examples\src\examplesディレクトリに移動します(ORACLE_HOMEは、WebLogic Serverをインストールしたディレクトリを表します)。WebLogic Serverのサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

3. helloというサブディレクトリを含むrmiディレクトリを作成します。

4. 例7-1のコンテンツをコピーして、Hello.javaという名前のファイルでhelloディレクトリに保存します。

5. 例7-2のコンテンツをコピーして、HelloImpl.javaという名前のファイルでhelloディレクトリに保存します。

6. 例7-3のコンテンツをコピーして、HelloClient.javaという名前のファイルでhelloディレクトリに保存します。

7. 例7-4のコンテンツをコピーして、build.xmlという名前のファイルでhelloディレクトリに保存します。

8. サンプル・ファイルをコピーしたシェルから次のコマンドを実行します。
ant build

起動クラスの構成

exampleServerのインスタンスを起動します。起動クラスを次の情報で作成します。

- 名前: MyHello

- クラス名: examples.rmi.hello.HelloImpl

- ターゲット: examplesServer

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの起動クラスの構成に関する項を参照してください。

注意:
このサンプルでは、ビルド・スクリプトは、起動クラスがサーバーのクラスパスの場所にあるかどうかを確認します。

examplesServerの再起動

examplesServerを再起動します。サーバーが起動したら、サーバー・ログで次の内容を確認する必要があります。

HelloImpl created and bound in the registry to the name HelloServer

サーバーが実行すると、JNDIを表示してHelloServerが登録されていることを確認できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJNDIツリーでのオブジェクトの表示に関する項を参照してください。

サンプルの実行

サンプル・ファイルをコピーしたシェルから次のコマンドを実行します。

java examples.rmi.hello.HelloClient localhost 7001

結果は次のようになります。

Successfully connected to HelloServer on localhost at port 7001: Hello World!

8 ロード・バランサとのWebLogic RMIの統合

この章では、ハードウェア・ロード・バランサなどのロード・バランサと、Webサーバー・プラグインを含むWebサーバーに対するWebLogic RMIサポートについて説明します。

この章には次の項が含まれます:

- WebLogic Serverでのロード・バランサのサポート

- HTTPトンネリングT3ロード・バランシング

- ネイティブT3ロード・バランシング

- フェイルオーバー・サポート

WebLogic Serverでのロード・バランサのサポート

RMIを使用するWebLogic Serverクライアントは、次のメカニズムを使用してロード・バランサと相互運用できます。

- HTTP/HTTPSでT3をトンネリングする場合、WebLogic Clusterへのリクエスト転送メカニズムでスティッキーなセッション・ルーティングの使用が構成されているかぎり、WebLogic Serveでは、ハードウェア・ロード・バランサ、またはWebサーバー・プラグインを含むWebサーバーによるルーティングがサポートされます。「HTTPトンネリングT3ロード・バランシング」を参照してください。

- T3を直接使用する場合、JNDI InitialContextの作成時にロード・バランサを指し示すPROVIDER_URLを指定することで、WebLogic Serverでは、クラスタへの初期T3接続をブートストラップするハードウェア・ロード・バランサの使用がサポートされます。「ネイティブT3ロード・バランシング」を参照してください。

注意:
WebLogic RMIでハードウェア・ロード・バランサを使用するその他の方法は、それらが機能するかどうかに関係なくサポートされません。

HTTPトンネリングT3ロード・バランシング

HTTP(またはHTTPS)でT3をトンネリングする場合、WebLogic Serverランタイムは、RMIセッションごとにHttpSessionを作成し、通常のHTTPメカニズムを使用して、クライアントとサーバー間でセッションIDの受渡しを行います。これにより、Webサーバー・プラグインまたはハードウェア・ロード・バランサは、該当セッションの期間中に、クラスタ内の同じサーバーに特定のクライアントからのすべてのRMIリクエストをルーティングできます。

注意:
外部ロード・バランサは、T3およびデフォルト・チャネルを介して、Javaクライアントからの初期コンテキスト・リクエストを分散します。ただし、ロード・バランサ経由で初期コンテキスト・リクエストに続くクライアント・リクエストをルーティングしないでください。外部ロード・バランサとT3プロトコルを併用するとき、初期コンテキスト・リクエストのみがロード・バランサを通してルーティングされ、後続のリクエストがWebLogic Serverのロード・バランシングを使用してルーティングおよび制御されていることを確認する必要があります。

外部リスニング・アドレスの構成方法

WebLogic Serverには、クライアントがNetwork Address Translating (NAT)ファイアウォール経由でサーバーに接続できるように、RMIスタブで使用するIPアドレスを提供する「外部リスニング・アドレス」があります。NATファイアウォールが一意の外部IPアドレスを、サーバーの一意の内部IPアドレスにマップしているかぎり、クライアントに配信される各スタブは、プロキシ対象のオブジェクトを保持するクラスタ・メンバーを一意に識別します。「外部リスニング・アドレス」は、デフォルトおよびカスタムのネットワーク・チャネルに対して個別に設定されます。

- デフォルト・チャネルの場合、ServerMBeanでExternalDNSName属性を使用します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのExternalDNSNameに関する項を参照してください。

- カスタム・チャネルの場合、NetworkAccessMBeanでPublicAddressとPublicPortを使用します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのNetworkAccessPointMBeanに関する項を参照してください。

ロード・バランサのカスタム・チャネル構成の例

クラスタのすべてのWebLogic ServerインスタンスでT3ネットワーク・チャネルを構成します。ネットワーク・チャネルは、ロード・バランサからトンネリングされたトラフィックを受け入れます。すべてのクライアント・リクエストがロード・バランサ経由でルーティングされるようにするには、ロード・バランサ(Webサーバー)がクライアントからトラフィックを受け入れるエンド・ポイントに「外部リスニング・アドレス」を設定します。HTTPプロトコルを有効にして、tunneling-enabled=trueを設定します。WebLogic Serverにhttpトラフィックをルーティングするように、ロード・バランサまたはWebサーバーを構成します。Oracle HTTP Server (OHS)をWebサーバーとして使用する場合は、httpd.conf構成ファイルを変更してください。例:

WebLogic Serverのconfig.xml:

<network-access-point>
<name>tunnelChannel</name>
<protocol>t3</protocol>
<listen-address>foo.bar.Company.com</listen-address>
<listen-port>11001</listen-port>
<http-enabled-for-this-protocol>true</http-enabled-for-this-protocol>
<tunneling-enabled>true</tunneling-enabled>
<outbound-enabled>false</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
</network-access-point><network-access-point>
. . .

OHS/Web層のhttpd.confファイル

<LocationMatch ^/bea_wls_internal/>
SetHandler weblogic-handler
WeblogicCluster foo.oracle.com:11001
</LocationMatch>
. . .

セッション・フェイルオーバー

セッション・フェイルオーバーは、クライアントに対して透過的です。サーバーが停止すると、クライアントのRJVMはPeerGone例外を受信します。このため、HTTPClientJVMConnectionが終了します。次のリクエストが同じクライアントから生じると、ステートレスBeanとステートフルBeanのどちらの場合も、リクエストはクラスタの次のメンバーにフェイルオーバーされます。例外がリクエストの処理中に生じた場合、そのリクエストはフェイルオーバーされず、例外がクライアントに伝播されます。

Cookieの永続性

トンネリング・クライアントは、初期リクエストの後に受信するCookieをキャッシュし、後続リクエストが発生するたびにそれを戻します。

確保済オブジェクト

クラスタでは、オブジェクトが確保されていてreplicate_bindings!= falseの場合でも、スタブはクラスタのすべてのメンバーにレプリケートされます。トンネリングは、正常な確保済オブジェクトの動作に影響を与えません。

ステートフル・セッションEJB

「外部リスニング・アドレス」を設定していない場合、クライアントに戻されるスタブには、ルーティング先の使用可能なホストのリストがあり、動作はt3リクエストを直接送信する場合と同様になります。

「外部リスニング・アドレス」を設定すると、プライマリ・ホストとセカンダリ・ホストがexternalDNSNameに設定され、ロード・バランサは自身へのルーティングを試みてハングするため、フェイルオーバーは機能しません。

ネイティブT3ロード・バランシング

クラスタ・メンバーに障害が発生した場合、ファイアウォールが別のクラスタ・メンバーにリクエストをリダイレクトしようとしないため、非クラスタ対応のスタブに対するクライアントの呼出しも失敗します。クラスタ対応のスタブ呼出しの場合、クラスタ対応のスタブに含まれる「外部リスニング・アドレス」を使用して、障害を回避するための透過的なリクエスト・ルーティングの実行や別のクラスタ・メンバーの呼出しを行う必要があります。「外部リスニング・アドレスの構成方法」を参照してください。

ハードウェア・ロード・バランサを使用して、JNDIのInitialContextの作成時に初期T3接続リクエストをロード・バランシングするには、ロード・バランサを指し示すPROVIDER_URLを指定します(「外部リスニング・アドレス」がハードウェア・ロード・バランサを指し示している場合を除く)。初期TCP接続リクエストをいずれかの管理対象サーバーにルーティングする際にのみハードウェア・ロード・バランサが呼び出されるため、この構成は機能します。　接続が確立されると、スタブがプロキシしているサーバーを一意に識別するサーバーのListenAddress (NATファイアウォールの場合は「外部リスニング・アドレス」)が、すべてのRMIスタブに含められます。

フェイルオーバー・サポート

WebLogic RMIは、ハードウェア・ロードバランサで使用される場合、フェイルオーバーをサポートしません。

WebLogic Server RMIによるフェイルオーバーの処理については、「RMIオブジェクトのフェイルオーバーとロード・バランシング」を参照してください。

9 RMI over IIOPの使い方

この章では、RMI over IIOP (RMI-IIOP)の概要と、このリリースと以前のWebLogic ServerリリースでのRMI-IIOPの相互運用性について説明します。

この章には次の項が含まれます:

- RMI over IIOPとは

- WebLogic RMI-IIOPの概要

RMI over IIOPとは

RMI over IIOPは、IIOPプロトコルを介して動作するようにRMIを拡張したものです。この拡張には役に立つメリットが2つあります。まず、Java-to-Javaパラダイムでは、これによって、標準IIOP (Internet Inter-ORB Protocol)に対応したプログラムを作成できるようになります。一方、Java単独の環境以外で作業している場合には、この拡張によって、JavaプログラムからCORBA (Common Object Request Broker Architecture)クライアントとやり取りし、CORBAオブジェクトを実行できるようになります。CORBAクライアントは、C++などの様々な言語で記述でき、インタフェース定義言語(IDL : Interface-Definition-Language)を使用してリモート・オブジェクトと対話できます。

WebLogic RMI-IIOPの概要

WebLogic Serverには、独自のORB実装が用意されています。このORBは、プログラムでORB.init()が呼び出されたとき、またはJNDIで"java:comp/ORB"がルックアップされたときにデフォルトでインスタンス化されます。Weblogic ServerがJava SEでCORBAをサポートするために準拠している仕様については、付録A「WebLogic ServerでのCORBAのサポート」を参照してください。

WebLogic ServerでのRMI-IIOP実装の機能は以下のとおりです。

- 標準IIOPプロトコルを使用してJava RMIクライアントをWebLogic Serverに接続できます。

- CORBA/IDLクライアント(C++で記述されたものを含む)をWebLogic Serverに接続できます。

- WebLogic ServerとTuxedoクライアントの間で相互運用できます。

- WebLogic ServerをホストとするEJBに、様々なクライアントを接続できます。

RMI-IIOPアプリケーションをどのように開発するかは、どのようなサービスやクライアントを統合するかによって決まります。RMIとRMI-IIOPを使用する各種クライアント・タイプのアプリケーションを作成する方法の詳細は、『Oracle WebLogic Serverスタンドアロン・クライアントの開発』を参照してください。

以下の図はIIOPを使用するオブジェクトのRMIオブジェクトの関係を示します。

図9-1 RMIオブジェクトの関係

RMI (Java)クライアント使用型RMI-IIOPのサポート

標準IIOPプロトコルを活用して、RMI-IIOPをJava/RMIクライアントで使用することができます。WebLogic Serverでは、新しい小規模クライアントjarに基づいた新しいJava EEアプリケーション・クライアント(シン・クライアント)など、Java-to-Java環境でRMI-IIOPを使用する複数の方法を用意しています。この新しいシン・クライアントを使用するには、クライアント側のCLASSPATHにwlclient.jar(WL_HOME/server/libにあります)を追加する必要があります。RMI-IIOPクライアント・オプションの詳細は、『Oracle WebLogic Serverスタンドアロン・クライアントの開発』を参照してください。

Tuxedoクライアント使用型RMI-IIOPのサポート

WebLogic ServerはWebLogic Tuxedo Connectorの実装も備えています。これは、Tuxedoサーバーとの相互運用を可能にする基底の技術です。WebLogic Tuxedo Connectorを使用すると、TuxedoをORBとして活用したり、WebLogic Server上で開発したアプリケーションと従来のTuxedoシステムを統合することができます。詳細は、『Oracle WebLogic Server Oracle WebLogic Tuxedo Connectorアプリケーションの開発』を参照してください。

CORBA/IDLクライアント使用型RMI-IIOPのサポート

開発者にとっては、CORBA/IDLクライアントからJava EEサービスにアクセスできることが必要です。しかし、JavaとCORBAは非常に異なるオブジェクト・モデルに基づいています。このため、この2つのプログラミング・パラダイムに基づいて作成されたオブジェクト間でのデータ共有は、最近までは、RemoteとCORBAのプリミティブ・データ型だけに限られていました。CORBAの構造体もJavaのオブジェクトも、異なるオブジェクト間で簡単にやり取りすることはできませんでした。この制限を解消するために、Object Management Group (OMG)によってhttp://www.omg.org/technology/documents/index.htm Objects-by-Value仕様が策定されました。この仕様では、Javaオブジェクト・モデルをCORBA/IDLプログラミング・モデルにエクスポートでき、Java、CORBAの2つのモデル間での複合データ型の交換が可能になります。Objects-by-Value仕様が正しく実装されているCORBA ORBを使用すれば、WebLogic ServerでもObjects-by-Valueをサポートできます。

10 WebLogic ServerのRMI-IIOP用構成

この章では、RMI over IIOP (RMI-IIOP)を使用して相互運用するようにWebLogic Serverを構成するために必要な概念と手順を説明します。

この章には次の項が含まれます:

- リスニング・アドレスの設定

- ネットワーク・チャネル・アドレスの設定

- IIOPSシン・クライアント・プロキシの使用

- RMI-IIOPとSSLおよびJavaクライアントの併用

- 委任を通じたCORBAクライアントからWebLogic Serverオブジェクトへのアクセス

- CSIv2認証の構成

- ハードウェア・ロード・バランサとRMI over IIOPの併用

- WebLogic RMI-IIOPの制約事項

- クライアントIDの伝播

リスニング・アドレスの設定

IIOPを容易に使用できるようにするには、構成ファイル(config.xml)のリスニング・アドレス属性に常に有効なIPアドレスまたはDNS名を指定して、接続をリスニングできるようにしておきます。

リスニング・アドレスがデフォルト値のnullである場合は、構成されたネットワーク・インタフェースのすべてをリスニングできます。ただし、この機能を使用できるのはT3プロトコルのみです。IIOPプロトコルで使用する複数のリスニング・アドレスを構成する必要がある場合は、ネットワーク・チャネル機能を使用します。『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。

ネットワーク・チャネル・アドレスの設定

以下の節では、シン・クライアント用にIIOPネットワーク・チャネルのアドレスを実装する場合に、考慮すべき事項を説明します。

プロキシおよびファイアウォールに関する考慮事項

一般的な環境ではファイアウォール、プロキシ、または他のデバイスを使用することが多く、その場合アプリケーション・サーバーの真のIPアドレスは隠蔽されます。IIOPは、ホストおよびポートを各オブジェクトに含むオブジェクトごとのアドレッシング方式に依存しているため、サーバーの真のIPアドレスがマスクされると、外部クライアントとの接続を維持できなくなります。サーバーのIIOPネットワーク・チャネルのPublicAddressに仮想IPを設定し、クライアントがその仮想IPを識別するようにすると、このような状況を回避できます。

複数の接続を持つクライアントに関する考慮事項

IIOPのクライアントは、アプリケーション・サーバーで使用されるアドレッシング情報をパブリッシュして接続を確立します。VPNの実行時でクライアントが複数の接続を持つ場合などには、クライアントからパブリッシュされたIPアドレスをサーバーで識別できないことがあります。次の2つのうちどちらかの方法によって、こうした状況を回避できます。

- 双方向IIOPを使用します。次のWebLogicのフラグを使用します。

-Dweblogic.corba.client.bidir=true

この場合、サーバーはアウトバウンド・リクエストのためにインバウンド接続を使用するので、クライアントからパブリッシュされたIPアドレスを必要としません。

- 次のJDKのプロパティを使用して、サーバーがアウトバウンド接続のために使用するアドレスを設定します。

-Dcom.sun.CORBA.ORBServerHost=client_ipaddress

ここでclient_ipaddressは、クライアントからパブリッシュされたアドレスを示します。

IIOPSシン・クライアント・プロキシの使用

IIOPSシン・クライアント・プロキシを使用すると、WebLogicシン・クライアントはアウトバウンド・リクエストをサーバーにプロキシできます。その場合、各ユーザーはすべてのアウトバウンド・リクエストをプロキシ経由でルーティングします。ユーザーのプロキシはそのリクエストをWebLogic Serverに転送します。ネットワーク・チャネルの実装が適当でない場合は、この方法を使用してください。プロキシを有効にするには、以下のプロパティを設定します。

-Diiops.proxyHost=<host>
-Diiops.proxyPort=<port>

説明:

- hostnameは、ユーザーのプロキシ・サーバーのネットワーク・アドレス。

- portはポート番号。明示的に設定しない場合、ポート番号の値は80に設定されます。

- hostnameとportには次のような識別名を使用できます。

-Diiops.proxyHost=https.proxyHost
-Diiops.proxyPort=https.proxyPort

以下のようなセキュリティの影響を考慮してください。

- この機能によってWebLogic Serverの動作が変わることはありません。ただし、この機能を使用すると、クライアントのファイアウォールがあってもIPアドレスが公開されます。接続の両端には信頼性があり、送信される情報は暗号化されるので、ほとんどの環境で許容できるレベルのセキュリティです。

- 本番環境によっては、プロキシ・サーバーのCONNECT属性を有効にできない場合もあります。そのような環境ではHTTPSトンネリングを使用してください。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のHTTPトンネリングのためのWebLogic Serverの設定に関する項を参照してください。

RMI-IIOPとSSLおよびJavaクライアントの併用

SSLをサポートするJavaクライアントは、シン・クライアントとWLS-IIOPクライアントです。これらのクライアントでは、ssl URLを指定するだけでSSLを使用できます。

委任を通じたCORBAクライアントからWebLogic Serverオブジェクトへのアクセス

WebLogic Serverには、CORBAクライアントからRMIリモート・オブジェクトにアクセスできるようにするサービスが用意されています。また、それ以外の方法として、WebLogic ServerにCORBA ORB (Object Request Broker)をホストし、発着信メッセージをそのORBに委任することで、サーバー内でバインド可能なあらゆるオブジェクトをCORBAクライアントから間接的に呼び出せるようにすることもできます。

委任の概要

WebLogic ServerをホストとするオブジェクトにCORBA呼出しを委任するには、いくつかのオブジェクトが連携してそれを実行する必要があります。それらのオブジェクトを作成する主な手順を以下に示します。

1. WebLogic Serverを実行しているJVMと共存するようにORBを作成し初期化する起動クラスを作成します。

2. そのORBから着信するメッセージを受け付けるオブジェクトを作成するためのIDL (インタフェース定義言語)を作成します。

3. そのIDLをコンパイルします。これによって多数のクラスが生成されますが、そのうちの1つがTieクラスです。Tieクラスは、着信呼出しを処理するためにサーバー側で用いられ、それらの呼出しをしかるべき実装クラスにディスパッチします。その実装クラスは、CORBAクライアントにかわって、サーバーの接続、適切なオブジェクトのルックアップ、およびそのオブジェクトに対するメソッドの呼出しを行います。

以下の図 に、サーバーに接続してEJB上で動作する実装クラスに、EJBの呼出しを委任するCORBAクライアントを示します。同様のアーキテクチャを使用すると、これとは逆の状況でも機能します。起動クラスを使用すると、ORBを起動し、対象となるCORBA実装オブジェクトへの参照を取得できます。このクラスは、JNDIツリー内の別のWebLogicオブジェクトで使用できるようにして、CORBAオブジェクトへの適切な呼出しを委任することも可能です。

図10-1 委任された呼出しでEJBを呼び出すCORBAクライアント

委任の例

以下のサンプル・コードでは、サーバーへの接続、JNDIツリー内のFooオブジェクトのルックアップ、およびbarメソッドの呼出しを行う実装クラスを作成しています。このオブジェクトはまた、以下の処理によってCORBA環境の初期化を行う起動クラスでもあります。

- ORBの作成

- Tieオブジェクトの作成

- 実装クラスとTieオブジェクトの関連付け

- ORBへのTieオブジェクトの登録

- ORBのネーミング・サービス内へのTieオブジェクトのバインド

import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
import java.rmi.*;
import javax.naming.*;
import weblogic.jndi.Environment;

public class FooImpl implements Foo
{
public FooImpl() throws RemoteException {
super();
}
public void bar() throws RemoteException, NamingException {
// look up and call the instance to delegate the call to...
weblogic.jndi.Environment env = new Environment();
Context ctx = env.getInitialContext();
Foo delegate = (Foo)ctx.lookup("Foo");
delegate.bar();
System.out.println("delegate Foo.bar called!");
}
public static void main(String args[]) {
try {
FooImpl foo = new FooImpl();

// Create and initialize the ORB
ORB orb = ORB.init(args, null);

// Create and register the tie with the ORB
_FooImpl_Tie fooTie = new _FooImpl_Tie();
fooTie.setTarget(foo);
orb.connect(fooTie);

// Get the naming context
org.omg.CORBA.Object o = \
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(o);

// Bind the object reference in naming

NameComponent nc = new NameComponent("Foo", "");
NameComponent path[] = {nc};
ncRef.rebind(path, fooTie);

System.out.println("FooImpl created and bound in the ORB registry.");
}
catch (Exception e) {
System.out.println("FooImpl.main: an exception occurred:");
e.printStackTrace();
}
}
}

CSIv2認証の構成

Common Secure Interoperability仕様バージョン2 (CSIv2)は、相互運用可能な認証、委任および権限のためのCommon Object Request Broker Architecture (CORBA)セキュリティの要件に応えるOpen Management Group (OMG)仕様です。『Oracle WebLogic Serverのセキュリティの理解』のCommon Secure Interoperability Version 2 (CSIv2)に関する項を参照してください。

次の手順に従って、CSIv2を使用してリモート・ドメインからのインバウンド呼出しを認証します。

1. IDアサーション・プロバイダを更新します。『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のIDアサーション・プロバイダの構成に関する項を参照してください。

2. ユーザー名マッパーを更新します。『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のユーザー名マッパーの構成に関する項を参照してください。

3. アプリケーションで必要なリモート・ドメイン内のすべてのユーザーをWebLogic認証プロバイダに追加します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーの作成に関する項を参照してください。

ハードウェア・ロード・バランサとRMI over IIOPの併用

注意:
この機能は、ハードウェア・ロード・バランサを使用してブート・ストラップを行っている場合にのみ正常に動作します。

WebLogic ServerのOracle ORBを拡張すると、ブート・ストラップ時の再接続の強制によるハードウェア・ロード・バランシングをサポートできます。これにより、ハードウェア・ロード・バランサによる接続試行のバランシングが可能になります。

ほとんどの場合、いったん接続が確立されると、元の接続を使用して次のNameServiceルックアップが実行されます。しかし、この機能はハードウェア・ロード・バランサにエンド・ポイントの再ネゴシエーションを強制するため、既存の接続で処理中のリクエストはすべて破棄されます。

-Dweblogic.system.iiop.reconnectOnBootstrapシステム・プロパティを使用すると、Oracle ORBの接続動作を設定できます。有効な値は以下のとおりです。

- true: エンド・ポイントの再ネゴシエーションを強制します。

- false - デフォルト値

ハードウェア・ロード・バランサを必要とする環境では、このプロパティをtrueに設定する必要があります。

WebLogic RMI-IIOPの制約事項

以下の各節では、WebLogic RMI-IIOPに関する様々な問題点の概要を説明します。

クライアントでRMI-IIOPを使用する際の制約

WebLogic Serverと一緒に使用するJDKは、バージョン1.3.1_01またはそれ以降でなければなりません。それ以前のバージョンはRMI-IIOPに準拠していません。これら旧バージョンのJDKには以下の問題点があることに注意してください。

- GIOP 1.0メッセージとGIOP 1.1プロファイルをIORで送信します。

- EJB 2.0相互運用性を実現するのに必要なコンポーネント(GIOP 1.2、コード・セット・ネゴシエーション、UTF-16)をサポートしていません。

- マングルされたメソッド名の取扱いにバグがあります。

- 未検査の例外が正しくアンマーシャリングされません。

- 値タイプのエンコーディングに関してわずかなバグがあります。

これらの多くは、両方でサポートすることが不可能なものです。選択肢がいくつかある場合には、WebLogicでは仕様に準拠する方をサポートしています。

Java IDLクライアントの開発上の制約

RMI-IIOPを使用する予定であれば、RMIクライアント・モデルを用いてJavaクライアントを開発することを強くお薦めします。Java IDLクライアントを開発する場合には、名前の競合やクラス・パスの問題が発生するおそれがあり、サーバー側とクライアント側のクラスを分離しておく必要があります。RMIオブジェクトとIDLクライアントのタイプ・システムはそれぞれ異なるので、サーバー側のインタフェースを定義するクラスは、クライアント側のインタフェースを定義するクラスとは非常に異なるものになります。

オブジェクトの値渡しに関する制約

オブジェクトを値で渡すには、値タイプを使用する必要があります(http://www.omg.org/cgi-bin/doc?formal/01-02-33を参照)、値タイプは、それが定義または参照されるプラットフォームごとに実装します。この節では、WebLogic Server上のエンティティBeanにアクセスするC++クライアントのケースを具体的に取り上げながら、複合的な値タイプを渡す際の問題点について説明します。

Javaプログラマが直面する問題の1つは、常に可視とは限らない派生データ型の使用に関することです。たとえば、EJBファインダにアクセスする際に、JavaプログラマはCollectionやEnumerationを目にすることになりますが、その基底の実装には注意を払いません。これは、JDKランタイムがネットワークを通じてこれらのクラスをロードするためです。しかし、C++やCORBAのプログラマであれば、ネットワークを通じて送られてくるデータ型を把握している必要があります。そうすれば、それに応じた値タイプ・ファクトリを登録でき、またORBでそのデータ型をアンマーシャリングできるようになります。

これらの定義はインタフェースに現れないため、定義されたEJBインタフェースでejbcを実行するのみでは生成されません。このため、ejbcには、リモート・インタフェース以外のJavaクラスも指定できるようになっています(これは特に、そうしたインタフェースのIDLの生成を目的としています)。なお、値タイプ・ファクトリを登録する方法については、/iiop/ejb/entity/cppclientサンプルを参照してください。

シリアライズ可能でありながらwriteObject()を定義するJava型は、IDLで記述されるカスタム値タイプにマップされます。値タイプを手動でアンマーシャリングするC++コードを書く必要があります。

注意:
Tuxedoを使用する場合には、IDLコンパイラに-i修飾子を指定することで、FileName_i.hおよびFileName_i.cppという実装ファイルを作成できます。たとえば、次の構文の場合、TradeResult_i.hおよびTradeResult_i.cppという実装ファイルが作成されます。

idl -IidlSources -i   idlSources\examples\iiop\ejb\iiop\TradeResult.idl

結果として生成されるソース・ファイルには、値タイプに対するアプリケーション定義の操作が実装されています。実装ファイルは、CORBAクライアント・アプリケーションに組み込まれます。

クライアントIDの伝播

最近まで、CORBAクライアントからのクライアントIDの伝播に関する標準が十分ではありませんでした。外部ORBのクライアントIDに関して問題がある場合は、以下のいずれかの方法を実装する必要があります。

- IIOPを通じてWebLogic Serverに接続するすべてのクライアントのIDは、デフォルトで<anonymous>になります。以下の例に示すように、config.xmlファイルにユーザー名とパスワードを設定することで、IIOPを通じてWebLogic Serverの個々のインスタンスに接続するすべてのクライアント用に単一のIDをセット・アップできます。

<Server
Name="myserver"
NativeIOEnabled="true"
DefaultIIOPUser="Bob"
DefaultIIOPPassword="Gumby1234"
ListenPort="7001">

- また、config.xmlにはIIOPEnabled属性を設定することもできます。この属性のデフォルト値は"true"ですが、IIOPのサポートを無効にする場合のみ、"false"に設定します。すべてのリモート・オブジェクトがJNDIツリーにバインドされてクライアントからアクセスできるようにしているのであれば、RMI over IIOPを使用するために追加のサーバーを構成する必要はありません。RMIオブジェクトは通常、起動クラスによってJNDIツリーにバインドされます。EJBホームは、デプロイメント時にJNDIツリーにバインドされます。WebLogic Serverは、JNDIツリーのルックアップ呼出しをすべて委任することにより、CosNaming Serviceを実装します。

- このリリースでは、corbanameおよびcorbalocの各RMI-IIOP JNDI参照をサポートしています。http://www.omg.org/cgi-bin/doc?formal/01-02-33を参照してください。これらの参照の特徴の1つは、あるWebLogic ServerをホストとするEJBなどのオブジェクトをIIOPを介して他のアプリケーション・サーバーから利用可能にできるということです。そのため、たとえばejb-jar.xmlに以下の内容を追加することもできます。

<ejb-reference-description>
<ejb-ref-name>WLS</ejb-ref-name>
<jndi-name>corbaname:iiop:1.2@localhost:7001#ejb/javaee/interop/foo</jndi-name>
</ejb-reference-description>

reference-descriptionスタンザは、ejb-jar.xmlに定義されているリソース参照をWebLogic Server内に用意されている実際のリソースのJNDI名にマップするものです。ejb-ref-nameではリソース参照名を指定します。これは、EJBプロバイダによってejb-jar.xmlデプロイメント記述子ファイル内に記載される参照です。jndi-nameでは、WebLogic Serverに用意されている実際のリソース・ファクトリのJNDI名を指定します。

注意:
iiop:1.2は、<jndi-name>セクションに含まれています。このリリースには、GIOP (General-Inter-Orb-Protocol) 1.2の実装が用意されています。GIOPは、相互運用するORB間で交換されるメッセージのフォーマットを規定するものです。これによって、他の多数のORBやアプリケーション・サーバーとの相互運用が可能になります。GIOPのバージョンは、corbanameまたはcorbaloc参照内のバージョン番号で指定できます。

これらの方法は、RMIクライアントでWLInitialContextFactoryを使用する場合には必要ありません。また、WebLogic C++クライアントを使用することによって回避することもできます。

11 アプリケーション設計のベスト・プラクティス

この章では、RMIおよびRMI over IIOPを使用してプログラミングを行う際の推奨設計パターンについて説明します。

この章には次の項が含まれます:

- java.rmiの使用

- PortableRemoteObjectの使用

- WebLogicワーク・コンテキストの使用

- セキュリティ・コンテキストにおける変更の処理方法

java.rmiの使用

RMIユーザーはjava.rmiを使用することをお薦めします。http://docs.oracle.com/javase/6/docs/api/java/rmi/package-summary.htmlを参照してください。Weblogic APIにはweblogic.rmi APIが含まれていますが、これは非推奨となっており、互換性APIとしてのみ提供されています。互換性APIとして提供されているその他のWebLogic APIは以下のとおりです。

- weblogic.rmi.registry

- weblogic.rmi.server

- weblogic.rmi.extensions

PortableRemoteObjectの使用

コードの移植性を保持するために、ホーム・インタフェースをキャストするときには常にPortableRemoteObjectを使用してください。例:

Propshome home = (PropsHome)
PortableRemoteObject.narrow(
ctx.lookup( "Props" ),
PropsHome.class );

WebLogicワーク・コンテキストの使用

ベスト・プラクティスは、ワーク・エリアを使用する方法です。

- Java EEの開発者は、ワーク・コンテキストを使用してプロパティをアプリケーション・コンテキストとして定義できます。アプリケーション・コンテキストは複数のリモート・リクエストにわたって暗黙的にフローされるので、ダウンストリームのコンポーネントが呼出し側のクライアントのコンテキストで作業できるようになります。ワーク・コンテキストの使用により、プロパティをリモート呼出しに含めずに渡すことが可能です。ワーク・コンテキストは各リモート呼出しで伝播されるので、呼び出されたコンポーネントではワーク・コンテキストに定義されたプロパティを追加したり変更したりできます。同様に、呼出し側のコンポーネントでもワーク・コンテキストにアクセスして、新しいプロパティや更新されたプロパティを取得できます。

- ワーク・コンテキストは、こうした情報をリモート・コンポーネント(診断モニター、アプリケーション・トランザクション、アプリケーション・ロード・バランシングなど)に渡す必要がある機能の実装と管理を容易にします。また、ワーク・コンテキストは、サード・パーティ・コンポーネントに情報を提供するための便利なメカニズムです。

- ワーク・コンテキストは、WebLogic Serverによってサポートされるすべてのリクエスト・スコープにユーザー定義のプロパティを伝播できます。このため、ワーク・コンテキストは要求スコープ内に存在するすべてのオブジェクト(RMI呼出しを含む)で使用できます。詳細は、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。

セキュリティ・コンテキストにおける変更の処理方法

WLS RMIでは、スタブにおいてセキュリティ・コンテキストは引き継がれません。スタブを確立するスレッドは、そのスレッド・コンテキスト内に適切なサブジェクトを持ちます。その後スタブが別のスレッドで使用されたり、現在のスレッド・コンテキストが何らかの処理により変更された後にスタブが使用された場合、以降のスタブを使用した呼出しは「SecurityException」によって失敗する可能性があります。スレッドのコンテキストを変更する可能性のある処理としては、新たなイニシャル・コンテキストの確立やWLSTのプログラム的な実行などが挙げられます。JMS、JTA、またはMDBを複数ドメイン構成で使用している場合にスレッド・コンテキストを変更すると、クロス・ドメイン・セキュリティに関する問題が頻繁に発生します。

RMIスタブが別のスレッドで使用される予定である場合は、アプリケーションでJSR-237ワーク・マネージャを使用して、スレッド・コンテキストが新しいスレッドに伝播されるよう、スタブが作成されるスレッドのコンテキスト内で新しいスレッドをスケジューリングできます。これが不可能である場合、または元のスレッドのコンテキストが何らかの形で変更された場合、アプリケーションはJAASでスタブを呼び出すためのコンテキストを再確立します。以下のパブリックAPIを使用すると、セキュリティ・コンテキストを再確立できます。

- weblogic.security.Security.getCurrentSubject() - スレッドの現在のオブジェクトを取得します。

- weblogic.security.Security.runAs() - サブジェクトを再開します。

A WebLogic ServerでのCORBAのサポート

この付録では、このリリースのWebLogic Serverが準拠しているCORBAサポート用の公式仕様を示します。

この付録の内容は次のとおりです。

- 仕様リファレンス

- サポートされる仕様の詳細

- ツール

仕様リファレンス

一般的に、このリリースのWebLogic ServerはJava EEによって要求されるOMG仕様に準拠しています。このリリースでは、WebLogic ORBは以下の仕様に準拠しています。

- CORBA 2.6: http://www.omg.org/cgi-bin/doc?formal/01-12-01のformal/01-12-01

- CORBA 2.3.1: http://www.omg.org/cgi-bin/doc?formal/99-10-07のformal/99-10-07

- IDL to Java language mapping: http://www.omg.org/cgi-bin/doc?ptc/03-09-04のptc/03-09-04

- Revised IDL to Java language mapping 1.3: http://www.omg.org/cgi-bin/doc?formal/00-11-03のformal/00-11-03

- Java to IDL language mapping: http://www.omg.org/cgi-bin/doc?ptc/00-01-06のptc/00-01-06

- Interoperable Naming Service: http://www.omg.org/cgi-bin/doc?ptc/00-08-07のptc/00-08-07

- Transaction Service 1.2.1: http://www.omg.org/cgi-bin/doc?formal/2001-11-03のformal/2001-11-03

注意:
上に示したリンクから仕様を参照できない場合、OMGがURLを変更した可能性があります。正しい仕様については(http://www.omg.org)を参照してください。

サポートされる仕様の詳細

このリリースでは、上に示した仕様のすべてがWebLogic ORBに実装されているわけではありません。以下の節では、サポートされている仕様を章または節ごとに詳しく示します。

- CORBA 2.6の1 - 3、6 - 7、13、および15章。

- 改訂IDL-to-Java言語マッピングの1.21.8.2節、orb.propertiesファイル。

- CORBA 2.6の第4章および第5章、ただし他の章の除外された機能(PortableInterceptorsなど)に関連する詳細を除きます。

- CORBA 2.6の10.6.1および10.6.2節(リポジトリIDのサポート)。

- CORBA 2.6の10.7節(TypeCode API用)。

- CORBA 2.6の第11章、Portable Object Adapter (POA)、ただし他の章の除外された機能(PortableInterceptorsなど)に関する詳細を除きます。

- CORBA 2.6の第26章、準拠レベル0プラス・ステートフル。

- Interoperable Naming Service。

- 改訂IDL-to-Java言語マッピング仕様(ptc/00-11-03)の1.21.8節は、IDL-to-Java言語マッピング仕様(ptc/00-01-08)から変更されました。

- Transaction Service 1.2.1 (EJB 2.1仕様の定義のとおり)。

ツール

このリリースでは、WebLogic ORBは以下のツールに準拠しています。

- Java SEにバンドルされているIDL-to-Javaコンパイラ(idlj)は、次の仕様に準拠しています。

- CORBA 2.3.1の第3章(IDLの定義)。

- CORBA 2.3.1の第5および6章(値型のセマンティクス)。

- CORBA 2.3.1の10.6.5節(pragma)。

- IDL-to-Java言語マッピング仕様。

- 改訂IDL-to-Java言語マッピング仕様の1.12.1節(ローカル・インタフェース)。

- Java-to-IDLコンパイラ(rmic用のIIOPバックエンド)は、以下の仕様に準拠しています。

- CORBA 2.6の5および6章(値型)。

- Java-to-IDL言語マッピング。これは、IDL-to-Java言語マッピングの1.21節を暗黙的に参照しています。

- -idlフラグによって生成されるIDLはCORBA 2.6の第3章に準拠しています。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。