Oracle® Fusion Middleware

Oracle WebLogic Serverスタンドアロン・クライアントの開発

12c (12.1.2)

E48086-02(原本部品番号:E27184-03)

2014年2月

このドキュメントは、WebLogic Serverと相互運用するスタンドアロン・クライアント・アプリケーションを開発する開発者を対象としています。

Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントの開発, 12c (12.1.2)

E48086-02

Copyright © 2007, 2014, 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の登録商標です。

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

目次

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

はじめに

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

- 表記規則

1 概要とロードマップ

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

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

- 関連ドキュメント

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

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

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

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

2 スタンドアロン・クライアントの概要

- クライアントJarファイルの配布

- WebLogic T3クライアント

- WebLogicシンT3クライアント

- WebLogicフル・クライアント

- WebLogicインストール・クライアント

- RMI-IIOPクライアント

- CORBAクライアント

- JMXクライアント

- JMSクライアント

- Webサービス・クライアント

- WebLogic Tuxedo Connectorクライアント

- クライアントと機能

3 WebLogicシンT3クライアントの開発

- WebLogicシンT3クライアントの理解

- WebLogicシンT3の機能

- 制限事項と考慮事項

- 相互運用性

- WebLogic Serverの旧リリース

- 外部アプリケーション・サーバー

- セキュリティ

- 接続に関する考慮事項

- 基本的なWebLogicシンT3クライアントの開発

- 外部サーバー・アプリケーション

- デプロイメントの考慮事項

- OC4Jとの相互運用

- WebLogic Serverリソースへのアクセス

- JMSとWLSとの相互運用性

4 WebLogicフル・クライアントの開発

- WebLogicフル・クライアントの理解

- WebLogicフル・クライアントの開発

- 管理モードでのサーバーとの通信

- 非フォーク対象VMでのWebLogicフル・クライアントの実行

5 シン・クライアントの開発

- シン・クライアントの概要

- 制限

- シン・クライアントの開発方法

- プロトコルの互換性

6 WebLogic JMSシン・クライアント

- JMSシン・クライアントの概要

- JMSシン・クライアントの機能

- JMSシン・クライアントの使用に関する制限

- JMSシン・クライアントのデプロイ

7 JMS SAFクライアントによる確実なメッセージ送信

- JMSクライアントでのストア・アンド・フォワードの使い方の概要

- クライアント側のSAFを使用するためのJMSクライアントの構成

- JMS SAFクライアントの構成ファイルの生成

- JMS SAFクライアントの構成ファイルの仕組み

- JMSモジュールからJMS SAFクライアントの構成ファイルを生成するための手順

- ClientSAFGenerateユーティリティの構文

- JMS SAFクライアントの構成での有効なSAF要素

- JMS SAFクライアントのデフォルト・ストア・オプション

- リモートJMS SAFコンテキストのパスワードの暗号化

- 暗号化されたパスワードの生成手順

- ClientSAFEncryptユーティリティの構文

- クライアント・マシンへのJMS SAFクライアントのJARファイルのインストール

- JMS SAFクライアントの初期JNDIプロバイダを使用できるようにJMSクライアント・アプリケーションの変更

- JMS SAFクライアントに必要なJNDIコンテキスト・ファクトリ

- JMS SAFクライアントの任意指定のJNDIプロパティ

- JMS SAFクライアント管理ツール

- JMS SAFクライアントの初期化API

- クライアント側のストア管理ユーティリティ

- JMS SAFクライアントでのJMSプログラミングの考慮事項

- JMS SAFクライアント・メッセージでのJMSReplyToフィールドの処理方法

- JMS SAFクライアントのコンテキストとサーバーのコンテキストは混在できない

- JMS SAFクライアントでのトランザクション・セッションの使用

- JMS SAFクライアントの相互運用のガイドライン

- Javaランタイム

- WebLogic Serverのバージョン

- JMS C API

- JMS SAFクライアントのチューニング

- JMS SAFクライアントの使用に関する制限

- JMS SAFクライアントのメッセージ格納動作の変更

- アップグレード・プロセス、ツールおよびシステム・プロパティ

- JMS SAFクライアント検出ツール

- JMS SAFクライアント移行プロパティ

8 Java SEクライアントの開発

- Java SEクライアントの基本

- Java SEクライアントの開発方法

9 WLS-IIOPクライアントの開発

- WLS-IIOPクライアントの機能

- WLS-IIOPクライアントの開発方法

10 CORBA/IDLクライアントの開発

- CORBA/IDLクライアント開発のガイドライン

- CORBA/IDLクライアントの作業

- IDLクライアント(CORBAオブジェクト)の関係

- Java-to-IDLマッピング

- WebLogic RMI over IIOPオブジェクトの関係

- Objects-by-Value

- CORBA/IDLクライアントの開発手順

11 CORBAオブジェクトを使用するクライアントの開発

- CORBAオブジェクト・タイプの拡張と制限事項

- 発信CORBA呼出しの実行:主な手順

- JNDIでホストされるWebLogic ORBの使用

- JNDIからORB

- ORBを直接作成する

- JNDIを使用する

- 着信CORBA呼出しのサポート

12 Tuxedo ORBを使用するWebLogic C++クライアントの開発

- WebLogic C++クライアントの利点と制限事項

- WebLogic C++クライアントの動作について

- WebLogic C++クライアントの開発

13 Java EEクライアント・アプリケーション・モジュールの使用

- クライアント・アプリケーションの展開

- クライアント・アプリケーションの実行

14 セキュリティ対応クライアントの開発

- JAASを使用するクライアントの開発

- JNDI認証を使用するクライアントの開発

- SSLを使用するクライアントの開発

- シン・クライアントでJAASおよびSSLを使用する際の制約

- セキュリティのサンプル・コード

15 RMI-IIOPクライアントでのEJBの使用

- JavaクライアントによるEJBへのアクセス

- CORBA/IDLクライアントによるEJBへのアクセス

- IDL生成の例

A クライアント・アプリケーションのデプロイメント記述子の要素

- クライアント・アプリケーションのデプロイメント記述子の要素の概要

- application-client.xmlデプロイメント記述子の要素

- application-client

- weblogic-appclient.xml記述子の要素

- application-client

B WebLogic JarBuilderツールの使用

- JDK 1.7クライアント・アプリケーション用のwlfullclient.jarの作成

- JDK 1.6クライアント・アプリケーション用のwlfullclient.jarの作成

はじめに

ここでは、このガイド『Oracle WebLogic Serverスタンドアロン・クライアントの開発』で使用されるドキュメントのアクセシビリティ機能および規則について説明します。

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

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スタンドアロン・クライアントの開発』の内容と構成について説明します。

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

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

- 関連ドキュメント

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

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

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

このドキュメントは、WebLogic Serverと相互運用するスタンドアロン・クライアント・アプリケーションを開発する開発者を対象としています。

このドキュメントでは、ソフトウェア・プロジェクトの設計および開発段階に関連する情報を提供します。また、プロジェクトのテストおよび本番前の段階で見つかるアプリケーションの問題の解決策も含まれています。

ここでは、Java Platform、Enterprise Edition (Java EE)の概念に精通している読者を対象としています。このドキュメントでは、WebLogic Serverで提供される付加価値の高い機能と、スタンドアロン・クライアントの開発時に使用するWebLogic Server機能の主な使い方を重点的に扱います。

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

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

- 第2章「スタンドアロン・クライアントの概要」では、基本的なクライアント - サーバー機能を説明します。

- 「WebLogicシンT3クライアントの開発」では、WebLogicシンT3クライアントの作成方法について説明します。

- 第4章「WebLogicフル・クライアントの開発」では、WebLogicフル・クライアントを作成する方法について説明します。

- 第5章「シン・クライアントの開発」では、シン・クライアントを作成する方法について説明します。

- 第6章「WebLogic JMSシン・クライアント」では、WebLogic JMSシン・クライアントを作成する方法について説明します。

- 第7章「JMS SAFクライアントによる確実なメッセージ送信」では、ストア・アンド・フォワード・クライアントを作成する方法について説明します。

- 第8章「Java SEクライアントの開発」では、JSEクライアントを作成する方法について説明します。

- 第9章「WLS-IIOPクライアントの開発」では、WebLogic Server-IIOPクライアントを作成する方法について説明します。

- 第10章「CORBA/IDLクライアントの開発」では、CORBA/IDLクライアントを作成する方法について説明します。

- 第11章「CORBAオブジェクトを使用するクライアントの開発」では、CORBAオブジェクトと相互運用するクライアントを作成する方法について説明します。

- 第12章「Tuxedo ORBを使用するWebLogic C++クライアントの開発」では、Tuxedo ORB用のC++クライアントを作成する方法について説明します。

- 第13章「Java EEクライアント・アプリケーション・モジュールの使用」では、アプリケーション・モジュールを使用する方法について説明します。

- 第14章「セキュリティ対応クライアントの開発」では、セキュリティ対応クライアントを作成する方法について説明します。

- 第15章「RMI-IIOPクライアントでのEJBの使用」では、RMI-IIOPクライアントでEJBを使用する方法について説明します。

- 付録A「クライアント・アプリケーションのデプロイメント記述子の要素」は、標準のJava EEクライアント・アプリケーションのデプロイメント記述子であるapplication-client.xmlおよびweblogic-appclient.xmlのリファレンスです。

- 付録B「WebLogic JarBuilderツールの使用」では、JarBuilderツールを使用したwlfullclient.jarの作成について説明します。

関連ドキュメント

WebLogic Serverアプリケーションを開発、デプロイ、およびモニターするための包括的なガイドラインについては、以下のドキュメントを参照してください。

- 『Oracle WebLogic Server RMIアプリケーションの開発』は、Remote Method Invocation (RMI)機能およびInternet Interop-Orb-Protocol (IIOP)機能の使用に関するガイドです。

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

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』。WebLogic Serverアプリケーションのデプロイについての情報を提供する主要なドキュメントです。

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』は、WebLogic Serverアプリケーションのパフォーマンスをモニターして改善するための情報を提供します。

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

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

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

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

MedRecはWebLogic Serverに付属したエンドツーエンドのサンプル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 Homeと指定したディレクトリです。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

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

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

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

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

このリリースには、次の新しい機能と変更された機能が含まれています。

- WebLogicシンT3クライアントに対応したWebLogicストア・アンド・フォワード・サービスのサポート。

- WebLogicシンT3クライアントを対象としたHTTPS上のRMI (SSLを介したHTTPトンネリング)のサポート。

- WebLogicシンT3クライアントに対応したネットワーク・クラスロードのサポート。

WebLogic Serverのこのリリースに追加された新機能の一覧については、「Oracle WebLogic Serverの新機能」を参照してください。

2 スタンドアロン・クライアントの概要

この章では、スタンドアロン・クライアントの内容、クライアントの種類、クライアントの機能、クライアントの配布方法について説明します。このドキュメントの文脈で使用する「スタンドアロン・クライアント」という言葉は、WebLogic Serverから独立した実行時環境を持つクライアントを指します。(Webサービスなどの管理対象クライアントは、サーバーへのアクセスに必要な実行時環境を提供するうえで、サーバー側のコンテナに依存します。)WebLogic Serverアプリケーションにアクセスするスタンドアロン・クライアントは、標準のI/Oを使用する単純なコマンド・ライン・ユーティリティから、Java Swing/AWTクラスを使用して構築された高度な対話型のGUIアプリケーションまで様々です。

- クライアントJarファイルの配布

- WebLogic T3クライアント

- RMI-IIOPクライアント

- CORBAクライアント

- JMXクライアント

- JMSクライアント

- Webサービス・クライアント

- WebLogic Tuxedo Connectorクライアント

- クライアントと機能

クライアントJarファイルの配布

Oracle WebLogic Serverスタンドアロン・クライアントの作成に提供されているクライアントJarおよび他のリソースを使用する場合のライセンス要件の詳細は、『Oracle® Fusion Middlewareライセンス情報』のスタンドアロンWebLogicクライアントに関する項を参照してください。

WebLogic T3クライアント

WebLogic T3クライアントは、OracleのT3プロトコルを使用してWebLogic Serverと通信するJava RMIクライアントです。T3クライアントは、他の種類のクライアントよりもパフォーマンスに優れており、最も推奨されるクライアントです。

WebLogicシンT3クライアント

WebLogicシンT3 Javaクライアントは、WebLogicインストール・クライアント、フル・クライアント、およびシンIIOPクライアントにかわる軽量のクライアントです。このクライアントは、フル・クライアントを使用した場合と同じパフォーマンスを実現しますが、利用するJARファイルははるかに小さくなります。シンT3クライアントでは、フル・クライアントを使用できるユース・ケースのほとんどがサポートされています。

シンT3クライアントは、スタンドアロン・アプリケーションで使用でき、WebLogic以外の外部サーバーで実行するアプリケーションで使用できるように設計されています。一般的なユース・ケースの1つは、WebLogic JMS宛先との統合です。

- 第3章「WebLogicシンT3クライアントの開発」

- 『Oracle WebLogic Server RMIアプリケーションの開発』のT3プロトコルによるWebLogic RMIの使用に関する項

WebLogicフル・クライアント

WebLogicフル・クライアントは、スタンドアロン・クライアントの中で最大サイズのJARファイル(wlfullclient.jar)を必要としますが、最も多くの機能を備え、総合的なパフォーマンスに優れています。3種類のT3クライアントのパフォーマンスはすべて同じです。wlfullclient.jarは、IIOPサポートも提供します。次を参照してください:

- 第4章「WebLogicフル・クライアントの開発」

- 『Oracle WebLogic Server RMIアプリケーションの開発』のT3プロトコルによるWebLogic RMIの使用に関する項

注意:

Antスクリプトで起動される<java>タスクからWebLogicフル・クライアントを実行する場合、wlfullclient.jarマニフェスト・クラスパスに含まれているRSA Crypto-Jライブラリに関する重要な情報は、「非フォーク対象VMでのWebLogicフル・クライアントの実行」を参照してください。

WebLogicインストール・クライアント

インストール・クライアントはWebLogic Serverのフル・インストールで使用できます。WL_HOME/server/libにあるweblogic.jarファイルを使用し、すべてのWebLogic Server固有の拡張機能のクライアント側のサポートを提供します。次などのサーバー側の操作をサポートする唯一のクライアントです。

- ejbcコンパイラなど、デプロイメント目的に必要な操作。

- デプロイメントなどの管理操作。

- サーバー側の操作を呼び出すWLSTおよびクライアント側のJSR 88アプリケーション。

RMI-IIOPクライアント

IIOPは、Java RMIで記述されたインタフェースを持つ分散アプリケーション向けのトランスポート・プロトコルです。IIOPクライアントの使用が任意の場合には、IIOPクライアントではなくT3クライアントを使用することをお薦めします。詳細は、次を参照してください:

- 第5章「シン・クライアントの開発」

- 第6章「WebLogic JMSシン・クライアント」

- 第7章「JMS SAFクライアントによる確実なメッセージ送信」

- 第8章「Java SEクライアントの開発」

- 第9章「WLS-IIOPクライアントの開発」

詳細は、『Oracle WebLogic Serverアプリケーションの開発』のIIOPを介したRMIの使用に関する項を参照してください。

CORBAクライアント

Java単独の環境以外で作業している場合には、IIOPを使用してJavaプログラムをCORBA (Common Object Request Broker Architecture)クライアントに接続し、CORBAオブジェクトを実行できます。IIOPは、インタフェースがJava RMIまたはインタフェース定義言語(Interface Definition Language: IDL)で記述された分散アプリケーション用のトランスポート・プロトコルです。ただし、この2つのモデルは、異種システム間での相互運用可能な環境を作成する方法が明確に異なります。プログラムを作成する際は、IDLまたはRMIのどちらのインタフェースを使用するか決定する必要があります。両方を混在させることはできません。WebLogic Serverでは、以下のCORBAクライアント・モデルをサポートしています。

- 第10章「CORBA/IDLクライアントの開発」

- 第11章「CORBAオブジェクトを使用するクライアントの開発」

- 1第12章「Tuxedo ORBを使用するWebLogic C++クライアントの開発」

JMXクライアント

JMXクライアントを使用すると、WebLogic Server MBeanにアクセスできます。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。

JMSクライアント

WebLogic Serverには、Java EEおよびWebLogic JMSの機能を提供するJMSクライアントが数多く用意されています。

ヒント:

T3プロトコル対応の効率的なJavaクライアント(インストール・クライアント、フル・クライアント、シンT3クライアントのいずれか)を使用してください。シンJavaクライアントは低速のIIOPプロトコルを使用するため、実際のユース・ケースでシンT3クライアントが大きすぎると思われる場合にしかお薦めできません。

- WebLogicシンT3クライアント。「WebLogicシンT3クライアントの開発」を参照してください。

- WebLogicフル・クライアント。「WebLogicフル・クライアントの開発」を参照してください。

- WebLogicインストール・クライアント。「WebLogicインストール・クライアント」を参照してください。

- JMSシン・クライアント。第6章「WebLogic JMSシン・クライアント」を参照してください。

- JMS SAFクライアント。第7章「JMS SAFクライアントによる確実なメッセージ送信」を参照してください。

- JMS Cクライアントは、Oracle WebLogic Server JMSアプリケーションの開発のWebLogic JMS C APIに関する項を参照してください。

- JMS .NETクライアントは、『Oracle WebLogic Server JMS .NETクライアント・アプリケーションの開発』を参照してください。

- WebLogic AQ JMSクライアントは、『Oracle WebLogic Server JMSリソースの管理』のスタンドアロンのWebLogic AQ JMSクライアントに関する項を参照してください。WebLogic AQ JMSクライアントは、WebLogic Server JNDIを使用して宛先の情報を取得でき、組込みドライバを使用してOracleデータベースAQ JMSの宛先に直接アクセスをサポートしています。WebLogic Server JMS宛先にアクセスできません。

Webサービス・クライアント

スタンドアロンのWebサービス・クライアント(wseeclient.jar)は、WebLogicクライアント・クラスを使用して、WebLogic Serverまたは他のアプリケーション・サーバー上でホストされているWebサービスを呼び出します。『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebサービス起動時のスタンドアロン・クライアントのJARファイルの使用に関する項を参照してください。

WebLogic Tuxedo Connectorクライアント

WebLogic Tuxedo Connectorでは、WebLogic ServerアプリケーションとTuxedoサービスとの相互運用が実現されます。次を参照してください:

- 『Oracle WebLogic Server Oracle WebLogic Tuxedo Connectorアプリケーションの開発』のOracle WebLogic Tuxedo ConnectorクライアントEJBの開発に関する項

- 『Oracle WebLogic Server Oracle WebLogic Tuxedo Connectorアプリケーションの開発』のWebLogic Tuxedo Connectorに対応したRMI/IIOPアプリケーションを開発する方法に関する項

- 『Oracle WebLogic Server Oracle WebLogic Tuxedo Connectorアプリケーションの開発』のCORBA Java APIを使用したOracle WebLogic Tuxedo Connector Client Beanを開発する方法に関する項

クライアントと機能

次の表に、WebLogic Server環境でサポートされるクライアントの種類と、それぞれの特徴、機能、および制約についてまとめます。

注意:

複数のクライアントを組み合せて拡張機能セットを作成することはサポートされていません。環境に最も適したクライアントを1つ選択し、その種類のクライアントに指定されているクライアント・クラスのみを使用してください。

表2-1 WebLogic Serverクライアントの種類と機能

クライアント

種類

言語

プロトコル

クライアント・クラス要件

主な機能

WLフル・クライアント(T3)

RMI

Java

T3

wlfullclient.jar

- ほとんどのWebLogic Server固有の機能をサポートします。

- WebLogic Serverクラスタリングをサポートします。

- IIOPクライアントよりも高速で、スケーラビリティでも優れています。

- ほとんどのJava EE機能をサポートします。

- 第4章「WebLogicフル・クライアントの開発」を参照してください。

WLシンT3クライアント

RMI

Java

T3

wlthint3client.jar

- 小さいフットプリント

- WebLogic Serverクラスタリングをサポートします。

- JSSE SSLをサポートします(HTTPトンネリングを伴うものを除く)。

- IIOPクライアントよりも高速で、スケーラビリティでも優れています。

- WebLogic Server JMSのほとんどをサポートします(JMS SAF機能などを除く)。

- ほとんどのJavaEE機能をサポートします。

- 第3章「WebLogicシンT3クライアントの開発」を参照してください。

WLS-IIOP

(WebLogic Server 7.0で導入)

RMI

Java

IIOP

wlfullclient.jar

- WebLogic Server固有の機能をサポートします。

- WebLogic Serverクラスタリングをサポートします。

- IIOPシン・クライアントよりも高速で、スケーラビリティでも優れています。

- 非ORBベース。

- WebLogic Server JMSはサポートしません(かわりに同じJarでT3プロトコルを使用)。

- 第9章「WLS-IIOPクライアントの開発」を参照してください。

シン・クライアント

RMI

Java

IIOP

wlclient.jar

JDK 1.6以降

- WebLogic Serverクラスタリングをサポートします。

- セキュリティやトランザクションを始めとするJava EEの様々な機能をサポートします。

- SSLをサポートします。

- CORBA 2.4 ORBを使用します。

- 第5章「シン・クライアントの開発」を参照してください。

CORBA/IDL

CORBA

OMG IDLからマップする言語(C++、C、Smalltalk、COBOLなど)

IIOP

WebLogicクラスは不要

- CORBA 2.3 ORBを使用します。

- WebLogic Server固有の機能をサポートしません。

- Javaをサポートしません。

- 第10章「CORBA/IDLクライアントの開発」を参照してください。

Java SE

RMI

Java

IIOP

WebLogicクラスは不要

- WebLogic Server環境への接続を提供します。

- WebLogic Server固有の機能をサポートしません。Java EEの多数の機能をサポートしません。

- CORBA 2.3 ORBを使用します。

- com.sun.jndi.cosnaming. CNCtxFactoryの使用が必須です。

- 第8章「Java SEクライアントの開発」を参照してください。

JMSシン・クライアント

RMI

Java

IIOP

wljmsclient.jar

wlclient.jar

JDK 1.6以降

- シン・クライアントの機能。

- WebLogic JMS (マルチキャスト・セッションおよびJMSHelperクラス・メソッドのクライアント側XMLの選択を除く)。

- SSLをサポートします。

- 第6章「WebLogic JMSシン・クライアント」を参照してください。

- T3クライアントの選択肢のうち、高速なものを使用することを検討してください。

JMS SAFクライアント

(WebLogic Server 9.2で導入)

RMI

Java

IIOP

- wlsafclient.jar

- wljmsclient.jar

- wlclient.jar

- JDK 1.6以降

- メッセージをクライアント上でローカルに格納し、クライアントの接続時にサーバー側のJMS宛先に転送します。

- SSLをサポートします。

- 第7章「JMS SAFクライアントによる確実なメッセージ送信」を参照してください。

- T3クライアントの選択肢のうち、高速なものを使用することを検討してください。

JMS Cクライアント

(WebLogic Server 9.0で導入)

JNI

C

任意

WebLogic JMS対応の任意のJavaクライアント(wlfullclient.jarなど)

- WebLogic JMSアプリケーションおよびリソースにアクセスできるCクライアント・アプリケーション。

- SSLをサポートします。

- 「WebLogic JMS C API」を参照してください。

JMS .NETクライアント

(WebLogic Server 10.3で導入)

T3

.NET

T3

WebLogic.Messaging.dll動的ライブラリ

- WebLogic JMSアプリケーションおよびリソースにアクセスできる、C#で作成されたMicrosoft .NETクライアント・アプリケーション。

- 『Oracle WebLogic Server JMS .NETクライアント・アプリケーションの開発』を参照してください。

WebLogic AQ JMSクライアント

(WebLogic Server 10.3.1で導入)

JNDI/

Java

IIOP/T3 +

aqapi.jar、o6.jar、orai18n.jarおよびwlclient.jar、wlfullclient.jar、weblogic.jar(インストーラ・クライアント)またはwlthint3client.jar

『Oracle WebLogic Server JMSリソースの管理』のスタンドアロンのWebLogic AQ JMSクライアントに関する項を参照してください。

JMX

RMI

Java

IIOP

wljmxclient.jar

『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。

Webサービス

SOAP

Java

HTTP/S

wseeclient.jar

『Oracle WebLogic Server JAX-WS Webサービスの開発』のスタンドアロン・クライアントからのWebサービスの起動に関する項を参照してください。

C++クライアント

CORBA

C++

IIOP

Tuxedoライブラリ

- WebLogic ServerアプリケーションとTuxedoクライアント/サービスとの相互運用性。

- SSLをサポートします。

- CORBA 2.3 ORBを使用します。

- 第12章「Tuxedo ORBを使用するWebLogic C++クライアントの開発」を参照してください。

TuxedoサーバーおよびネイティブCORBAクライアント

CORBAまたはRMI

C++

Tuxedo-General-Inter-Orb-Protocol

(TGIOP)

Tuxedoライブラリ

- WebLogic ServerアプリケーションとTuxedoクライアント/サービスとの相互運用性。

- SSLおよびトランザクションをサポートします。

- CORBA 2.3 ORBを使用します。

- 第11章「CORBAオブジェクトを使用するクライアントの開発」を参照してください。

3 WebLogicシンT3クライアントの開発

この章では、WebLogicシンT3クライアントを開発および使用する方法について説明します。

- WebLogicシンT3クライアントの理解

- 基本的なWebLogicシンT3クライアントの開発

- 外部サーバー・アプリケーション

WebLogicシンT3クライアントの理解

WebLogicシンT3クライアントのjar (wlthint3client.jar)は、wlfullclient.jarおよびwlclient.jar (IIOP)リモート・クライアントのjarの軽量かつ高パフォーマンス版です。シンT3クライアントは、サイズを最小限に抑えながら、クライアントでの使用に適した豊富なAPI群へのアクセスを実現します。その名前が示すように、WebLogic T3プロトコルを使用し、IIOPプロトコルを使用するwlclient.jarに勝る大幅なパフォーマンス向上をもたらします。

シンT3クライアントは、リモート・クライアントのほとんどのユース・ケースで推奨される方式です。シンT3クライアントには、次に示すような制限があります。これらの数少ないユース・ケースでは、フル・クライアントまたはIIOPシン・クライアントを使用する必要があります。

シンT3クライアントは、スタンドアロン・アプリケーションで使用でき、WebLogic以外の外部サーバーで実行するアプリケーションで使用できるように設計されています。一般的なユース・ケースの1つは、WebLogic JMS宛先との統合です。

WebLogicシンT3の機能

このリリースでは、次の機能をサポートしています。

- Oracle WebLogicのRemote Method Invocation (RMI)用のT3/T3Sプロトコル(RMI over HTTP (HTTPトンネリング)およびをRMI over HTTPS (SSLを介したHTTPトンネリング)含む)。WebLogic T3通信の詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』のT3プロトコルを実装したWebLogic RMIの使用に関する項を参照してください。

- WebLogic Serverで使用可能なJMS、JMX、JNDI、およびEJBの各リソースへのアクセス。

- wlsaft3client.jarを使用したWebLogicストア・アンド・フォワード(SAF)サービス。

- JTAを使用したトランザクションの開始と終了(ロールバックまたはコミット)。

- WebLogicクライアントJMS機能。順序単位、作業ユニット、メッセージ圧縮、XMLメッセージ、JMS自動クライアント再接続、Destination Availability Helper APIなどがあります。

- クライアント側のクラスタリングを使用すると、クライアント・アプリケーションはフェイルオーバーやWebLogic Serverインスタンスのロード・バランシングに関与できます。『Oracle WebLogic Server RMIアプリケーションの開発』のクラスタ化されたRMIアプリケーションに関する項を参照してください。

- JAAS認証とJSSE SSL。「セキュリティ」を参照してください。

- ネットワーク・クラスのロード。デフォルトでは、シンT3クライアントのネットワーク・クラスのロードは無効化されています。次のシステム・プロパティを使用して、ネットワークのクラスロードを有効化します。
-Dweblogic.rmi.networkclassloadingenabled=true

制限事項と考慮事項

このリリースでは、次の機能はサポートしていません。

- Mbeanベースのユーティリティ(JMSヘルパー、JMSモジュール・ヘルパーなど)、およびJMSマルチキャストはサポートされていません。MbeanベースのヘルパーのかわりにJMX呼出しを使用できます。

- WebLogic JDBC拡張をはじめとするJDBCリソース。

- クライアントでのWebLogic RMIサーバーの実行。

シンT3クライアントでは、ホストへの接続にJDKクラスを使用します(デュアル・スタック・マシンへの接続を含む)。ホスト上に複数のアドレスが存在する場合、ホストが正しく構成されていないと、間違ったアドレスへの接続が試行され、接続に失敗する可能性があります。

相互運用性

このリリースのWebLogicシンT3クライアントは、相互運用性を次のようにサポートしています。

- WebLogic Serverの旧リリース

- 外部アプリケーション・サーバー

WebLogic Serverの旧リリース

WebLogicシンT3クライアントにおける旧WebLogicリリースとの通信のサポートについては、『Oracle WebLogic Serverの理解』のプロトコルの互換性に関する項を参照してください。

外部アプリケーション・サーバー

WebLogicシンT3クライアントのjarは、次のアプリケーション・サーバーでサポートされています。

- GlassFish: バージョン3.1以降

- Oracle OC4J: バージョン10g以降

- IBM WebSphere Application Server: バージョン6.xおよび7.x

- Red Hat JBoss Application Server: バージョン5.xおよび6.x

セキュリティ

クライアントのセキュリティに関する一般情報は、次の項を参照してください。

- 『Oracle WebLogic Serverセキュリティの理解』のJava Secure Socket Extension (JSSE)に関する項。

- 『Oracle WebLogic Serverセキュリティの理解』のJava Authentication and Authorization Services (JAAS)に関する項。

- 『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaクライアントにおけるSSL認証に関する項。

- 『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaクライアントにおけるJAAS認証に関する項。

接続に関する考慮事項

WebLogicシンT3クライアントでは、ホストへの接続にJDKクラスを使用します。ホスト上に複数のアドレス(デュアル・スタック)が存在する場合、ホストが正しく構成されていないと、クライアントが間違ったIPアドレスに接続してしまう可能性があります。

基本的なWebLogicシンT3クライアントの開発

基本的なWebLogicシンT3クライアントを作成するには、次の手順に従います。

1. リモート・オブジェクトへの参照を取得します。

1. t3://ip address:portまたはt3s://ip address:portという形式のT3 URLを使用して、サービスをホストするサーバーの初期コンテキストを取得します。

2. 初期コンテキストを使用してルックアップを実行することで、サービス・オブジェクトのインスタンスを取得します。このインスタンスは、ローカル・オブジェクト参照と同じように使用できます。

2. リモート・オブジェクト・メソッドを呼び出します。

3. クライアントのクラスパスにwlthint3client.jarを追加します。このファイルは、WebLogic ServerがインストールされているWL_HOME\server\libディレクトリにあります。

注意:

複数のクライアントを組み合せて拡張機能セットを作成することはサポートされていません。wlfullclient.jar、wlthint3client.jarまたはwlclient.jarを、WebLogic ServerのクラスパスやWebLogicフル・インストールのweblogic.jarファイルを参照するクラスパスに追加しないでください。追加した場合の動作は不明です。WebLogic Serverアプリケーションは、すでにWebLogicクライアントの機能をすべて利用できます。

例3-1に、基本的なWebLogicシンT3クライアントのサンプル・コードを示します。

例3-1 WebLogic初期コンテキストの作成および使用

Hashtable env = new Hashtable();
env.put("java.naming.factory.initial",
"weblogic.jndi.WLInitialContextFactory");
env.put("java.naming.provider.url","t3://host:7001");
env.put("java.naming.security.principal","user");
env.put("java.naming.security.credentials","password");
Context ctx = new InitialContext(env);
try {
Object homeObject =
context.lookup("EmployeeBean");
//use the EmployeeBean
}
catch (NamingException e) {
// a failure occurred
}
finally {
try {ctx.close();}
catch (Exception e) {
// a failure occurred
}
}

外部サーバー・アプリケーション

外部サーバーにホストされているアプリケーションは、wlthint3client.jarを使用すると、WebLogic Serverインスタンスのリモート・クライアントとして機能できます。JMS、サーブレット、EJB、起動クラスなどのリモート・サービスへのアクセスを可能にするには、必要なアプリケーション・コードをwlthint3client.jarとともにアプリケーション・サーバーにデプロイします。

JNDIを使用して外部アプリケーション・サーバーからWebLogic Serverリソースに接続し、アクセスするには、ガイドラインとして次の手順に従ってください。

1. クライアントのクラスパスにwlthint3client.jarを追加します。

2. クライアント・アプリケーションで、WebLogic初期コンテキストを作成してから、そのコンテキストを使用してリソースをルックアップし、使用します。詳細は、例3-1「WebLogic初期コンテキストの作成および使用」を参照してください。

3. 初期コンテキスト・ファクトリをクライアント・コードのシステム・プロパティとして次の値に明示的に設定することが必要な場合もあります。
env.put("java.naming.factory.initial", "weblogic.jndi.WLInitialContextFactory");

4. wlthint3client.jarファイルをサーブレットに埋め込んだり、共有ライブラリを使用したりするなど、標準Java EEメソッドを使用してwlthint3client.jarファイルと共に必要なアプリケーション・コードをアプリケーション・サーバーにデプロイします。「デプロイメントの考慮事項」を参照してください。

5. クライアントを起動またはデプロイします。

次の項では、外部サーバーと相互運用する際に考慮すべき事項について概説します。

- デプロイメントの考慮事項

- OC4Jとの相互運用

デプロイメントの考慮事項

wlthint3client.jarは、Java EEの標準的な方法でデプロイできます。ただし、使用するデプロイメント方法を決める際には、クライアントのサイズ、クラスのロード、パフォーマンス、およびコードの不整合が発生するリスクへの許容度を考慮する必要があります。例:

- wlthint3client.jarをサーブレットなどのアプリケーションに埋め込んだ場合、アプリケーションのサイズはwlthint3client.jarのサイズだけ増えますが、コードの不整合が発生するリスクはアプリケーションの範囲に限定されます。

- wlthint3client.jarをlibディレクトリにデプロイした場合、アプリケーションのサイズに影響はありませんが、コードの不整合が発生するリスクは外部サーバー・コンテナ全体に及びます。

OC4Jとの相互運用

OC4J内で実行されているアプリケーションのうち、WebLogic Serverリソースを必要とするもののクラスパスにwlthint3client.jarファイルを追加します。http://docs.oracle.com/docs/cd/E14101_01/doc.1013/e13979/classload.htm#CIHDGJGDで、OC4Jにおける共有ライブラリのインストールと公開に関する項を参照してください。

次の項では、WebLogic Serverリソースのリモート・クライアントとして機能するOracle OC4Jアプリケーション・サーバーと相互運用する際の重要な考慮事項について概説します。

- トランザクションの伝播: サーバー間でのトランザクション・コンテキスト・オブジェクトの伝播はサポートされていません。

- セキュリティ・コンテキストの伝播: サーバー間でのセキュリティ/アイデンティティ情報の伝播はサポートされていません。

OC4Jの詳細は、『Java EEアップグレード・ガイド』のOC4Jユーザー用Oracle WebLogic Serverの紹介に関する項を参照してください。

WebLogic Serverリソースへのアクセス

次の項では、JNDIを使用してOC4JからWebLogic Serverリソースに接続およびアクセスする方法について、例をあげて説明します。

1. クライアント・アプリケーションで、WebLogic初期コンテキストを作成してから、そのコンテキストを使用してリソースをルックアップし、使用します。詳細は、例3-1「WebLogic初期コンテキストの作成および使用」を参照してください。

2. OC4J URLコンテキスト・ファクトリ・プロパティを設定します。http://docs.oracle.com/docs/cd/E14101_01/doc.1013/e13975/jndi.htmで、サーバー側のURLコンテキスト・ファクトリの有効化に関する項、またはリモート・クライアントのURLコンテキスト・ファクトリの有効化に関する項を参照してください。

3. クライアントのクラスパスにwlthint3client.jarを追加します。

4. JARファイルをOC4J共有ライブラリとして追加します。http://docs.oracle.com/docs/cd/E14101_01/doc.1013/e13980/ascontrol.htm#BABFDHGBで、共有ライブラリの作成および管理に関する項を参照してください。

5. クライアントを起動またはデプロイします。

JMSとWLSとの相互運用性

ContextScanningResourceProviderリソース・プロバイダを使用してWebLogicサーバーのJMS宛先にアクセスする際には、resource.namesプロパティを使用して、外部サーバーが要求するJMSリソースのJNDI名のカンマ区切りリストを明示的に設定する必要があります。ContextScanningResourceProviderリソース・プロバイダを使用してサード・パーティのJMS宛先にアクセスする方法の詳細は、http://docs.oracle.com/docs/cd/E14101_01/doc.1013/e13975/jms.htmでOracleエンタープライズ・メッセージ・サービスの使用に関する項を参照してください。

注意:

resource.namesの構文では、JNDI名のカンマ区切りリストのカンマと次のJNDI名との間にスペースを入れることはできません。

次の例は、orion-application.xmlファイルにresource.namesプロパティを設定する方法を示しています。resource.namesプロパティは、TopicOne,QueueOne,TopicTwoに設定されます。この値は、ContextScanningResourceProviderリソース・プロバイダが外部WebLogicサーバーからルックアップしようとするJMS宛先のJNDI名のリストを表しています。

例3-2 resource.namesプロパティの設定

<resource-provider class="com.evermind.server.deployment.ContextScanningResourceProvider" name="WebLogicRP">
<property name="java.naming.factory.initial"    value="weblogic.jndi.WLInitialContextFactory"/>
<property name="java.naming.provider.url" value="t3://localhost:7001/"/>
<property name="java.naming.security.principal" value="user_name"/>
<property name="java.naming.security.credentials" value="user_password"/>
...
<!-- configure the set of known JMS destinations that are required for this application -->
<property name="resource.names" value="TopicOne,QueueOne,TopicTwo"/>
...
</resource-provider>

4 WebLogicフル・クライアントの開発

この章では、WebLogicフル・クライアントを開発および使用する方法について説明します。

- WebLogicフル・クライアントの理解

- WebLogicフル・クライアントの開発

- 管理モードでのサーバーとの通信

- 非フォーク対象VMでのWebLogicフル・クライアントの実行

WebLogicフル・クライアントの理解

WebLogic Server 10.0以降のリリースでは、クライアント・アプリケーションはweblogic.jarのかわりにwlfullclient.jarファイルを使用する必要があります。WebLogicフル・クライアントは、Oracle独自のT3プロトコルを使用してWebLogic Serverと通信するJava RMIクライアントであり、分散コンピューティングのJava-to-Javaモデルを使用します。WebLogic T3通信の詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』のT3プロトコルを実装したWebLogic RMIの使用に関する項を参照してください。

注意:

WebLogicフル・クライアントは、各種クライアントの中で最大サイズのJARファイルを必要としますが、最も多くの機能を備え、IIOPクライアントよりもスケーラビリティに優れています。T3プロトコルのサポートを提供するJARがIIOPサポートも提供します。

WebLogicフル・クライアントの特徴は以下のとおりです。

- クラス・パスにwlfullclient.jarが必要となる。

- 初期コンテキストでは、URLはt3://ip address:portの形式で使用します。

- IIOPクライアントよりも高速で、スケーラビリティでも優れています。

- ほとんどのWebLogic Server固有の機能をサポートします。

- WebLogic Serverクラスタリングをサポートします。

- ほとんどのJavaEE機能をサポートします。

- WebLogic JMS、JMS SAFクライアント、およびJMS Cクライアントをサポートします。

- Oracle WebLogicのRemote Method Invocation (RMI)用のT3/T3Sプロトコル(RMI over HTTP (HTTPトンネリング)およびをRMI over HTTPS (SSLを介したHTTPトンネリング)含む)。WebLogic T3通信の詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』のT3プロトコルを実装したWebLogic RMIの使用に関する項を参照してください。

注意:

weblogic.jarで利用できた機能がwlfullclient.jarでは利用できない場合があります。たとえば、wlfullclient.jarではWebサービスはサポートされません。Webサービスにはwseeclient.jarが必要になります。また、wlfullclient.jarでは、ejbcなどの開発用に必要な操作やデプロイメントなどの管理操作もサポートされません。これらの操作には、依然としてweblogic.jarの使用が必要がです。

WebLogicフル・クライアントの開発

基本的なWebLogicフル・クライアントを作成する手順は次のとおりです。

1. JarBuilderツールを使用して、クライアント・アプリケーションのwlfullclient.jarファイルを生成します。付録B「WebLogic JarBuilderツールの使用」を参照してください。

2. リモート・オブジェクトへの参照を取得します。

1. T3 URLを使用してサービスをホストするサーバーの初期コンテキストを取得します。

2. 初期コンテキストを使用してルックアップを実行することで、サービス・オブジェクトのインスタンスを取得します。このインスタンスは、ローカル・オブジェクト参照と同じように使用できます。

3. リモート・オブジェクト・メソッドを呼び出します。

例4-1に、簡単なWebLogicフル・クライアントのサンプル・コードを示します。

例4-1 簡単なWebLogicフルhelloクライアント

package examples.rmi.hello;

import java.io.PrintStream;
import weblogic.utils.Debug;
import javax.naming.*;
import java.util.Hashtable;

/**
* This client uses the remote HelloServer methods.
*
* @author Copyright (c) Oracle. All Rights Reserved.
*/
public class HelloClient {

private final static boolean debug = true;

/**
* 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>");
System.exit(-1);
}

public HelloClient() {}
public static void main(String[] argv) throws Exception {
if (argv.length < 2) {
usage();
}
String host = argv[0];
int port = 0;
try {
port = Integer.parseInt(argv[1]);
}
catch (NumberFormatException nfe) {
usage();
}
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 (Throwable t) {
t.printStackTrace();
System.exit(-1);
}

}

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

管理モードでのサーバーとの通信

管理モードでサーバー・インスタンスと通信するには、クライアントで以下のフラグを設定して通信チャネルを構成する必要があります。

-Dweblogic.AdministrationProtocol=t3

非フォーク対象VMでのWebLogicフル・クライアントの実行

fork=true属性が設定されていないAntスクリプトから起動した<java>タスクを使用するなど、WebLogicフル・クライアントが非フォーク対象VMで実行されている場合、次のエラーが発生する可能性があります。

java.lang.SecurityException: The provider self-integrity check failed.

このエラーは、RSA Crypto-Jライブラリの読込み時に自動的に実行される自己整合性チェックによって発生します。(Crypto-Jライブラリとcryptoj.jarは、wlfullclient.jarマニフェスト・クラスパスにあります。)

この自己整合性チェック・エラーは、次に示す状況のような、クライアントが非フォーク対象VMで起動され、Crypto-J APIを直接または間接的に使用する場合に発生します。

- クライアントがCrypto-Jライブラリを直接起動します。

- クライアントが、基盤となるクライアントSSL実装をトリガーしてCrypto-J APIを起動するT3S接続を試行する場合。

自己整合性チェックが失敗した場合、Crypto-J APIの以降の呼び出しが失敗します。このエラーの発生を回避するには、Antスクリプトから起動される<java>タスクでフル・クライアントを実行する場合は、必ずfork属性をtrueに設定します。

自己整合性チェックの詳細は、次のURLにある『Java(tm) Cryptography Architectureでのプロバイダの実装方法』のプロバイダにより自己整合性チェックの実行方法に関する項を参照してください。

http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/HowToImplAProvider.html#integritycheck

5 シン・クライアントの開発

この章では、WebLogicシン・クライアントを開発および使用する方法について説明します。

- シン・クライアントの概要

- シン・クライアントの開発方法

- プロトコルの互換性

シン・クライアントの概要

シン・クライアントはJavaアプリケーションですが、Java EEコンポーネントであるため、スタンドアロンのJavaアプリケーション・クライアントとは異なります。したがって、他のJava EE準拠のサーバーへ移植できるという利点があり、Java EEサービスにアクセスできます。

以下のアプリケーション・クライアントJARファイルが用意されています。

- Java EE機能を提供する標準クライアントJAR (wlclient.jar)。「シン・クライアントの開発方法」を参照してください。

- JMSクライアントJAR (wljmsclient.jar)は、wlclient.jarと共にデプロイするとき、Java EE機能とWebLogic JMS機能を提供します。第6章「WebLogic JMSシン・クライアント」を参照してください。

- JMS SAFクライアントJAR (wlsafclient.jar)は、wljmsclient.jarおよびwlclient.jarと共にデプロイするとき、一時的に宛先にアクセスできない場合でも、スタンドアロンのJMSクライアントはサーバー側のJMS宛先にメッセージを確実に送信できるようになります。送信メッセージは、クライアント上でローカルに格納され、宛先が使用可能になったときに転送されます。第7章「JMS SAFクライアントによる確実なメッセージ送信」を参照してください。

これらのアプリケーション・クライアントJARファイルは、WebLogic Serverのインストール・ディレクトリのWL_HOME/server/libサブディレクトリに格納されています。

シン・クライアントでは、RMI-IIOPプロトコル・スタックを使用し、Java SEの機能を活用します。また、JDK ORBのサポートも必要とします。RMIリクエストの作成は基本的にJDKで処理されるため、非常に小さいクライアントを実現できます。クライアント側の開発は、WebLogic Server APIではなく標準のJava EE APIを使用して実行されます。

シン・クライアント・アプリケーションの開発プロセスは、他のJava EEアプリケーションにおけるプロセスと同じです。クライアントではInitialContext、UserTransaction、EJBなどの標準Java EEアーティファクトを活用できます。WebLogic Serverシン・クライアントでは、URLのプロトコル部分の値としてIIOP、IIOPS、HTTP、HTTPS、T3、およびT3Sがサポートされています。InitialContextで異なるURLを使用することで、それぞれを選択できます。URLに関係なく、IIOPが使用されます。URLにT3を指定するとIIOPが使用され、T3Sを指定するとIIOPSが使用されます。HTTPはトンネリングされたIIOPであり、HTTPSはHTTPS上でトンネリングされたIIOPです。

サーバー側コンポーネントは、通常の方法でデプロイされます。クライアント・スタブは、デプロイメント時または実行時に生成できます。デプロイ時にスタブを生成するには、-iiopおよび-basicClientJarオプションを付けてappcを実行し、シン・クライアントでの使用に適したクライアントjarを作成します。この手順を実行しない場合、WebLogic Serverで必要に応じて実行時にスタブが生成され、クライアントに提供されます。クライアントでスタブをダウンロードするには、適切なセキュリティ・マネージャがインストールされている必要があります。シン・クライアントでは、デフォルトで軽量のセキュリティ・マネージャが提供されます。強固なセキュリティが必要な場合は、コマンド・ライン・オプションの-Djava.security.manager、-Djava.security.policy==policyfileを使用して、別のセキュリティ・マネージャをインストールできます。アプレットでは、スタブのダウンロードを可能にする別のセキュリティ・マネージャが使用されます。

シン・クライアントをデプロイする際には、クライアントのファイル・システムにwlclient.jarファイルがインストールされていること、クライアントのCLASSPATHにwlclient.jarファイルへの参照が指定されていることが必要です。

制限

シン・クライアントには次の制限が適用されます。

- wlfullclient.jarファイルのJDBCまたはJMXの機能は提供されません。

- クライアントにjava.sql.ResultSetを戻すことのできるWebLogic Server CMP 2.x拡張がサポートされていません。

- JDK ORBでのみサポートされます。

シン・クライアントの開発方法

シン・クライアントを開発するには:

1. リモート・オブジェクトのパブリック・メソッドを、java.rmi.Remoteを拡張するインタフェースに定義します。
このリモート・インタフェースには、コードをあまり記述する必要がない場合もあります。必要なのは、リモート・クラスで実装するメソッドのメソッド・シグネチャだけです。例:

public interface Pinger extends java.rmi.Remote {
public void ping() throws java.rmi.RemoteException;
public void pingRemote() throws java.rmi.RemoteException;

2. interfaceNameImplというクラスにインタフェースを実装し、それをJNDIツリー内にバインドしてクライアントから利用できるようにします。
このクラスには、記述済みのリモート・インタフェースを実装する必要があります。これにより、インタフェースに含まれるメソッド・シグネチャを実装したことになります。すべてのコード生成はこのクラス・ファイルに依存します。通常は、実装クラスをWebLogic起動クラスとして構成し、そのオブジェクトをJNDIツリー内にバインドするmainメソッドをインクルードします。以下に、上記のPingのサンプルを基に開発した実装クラスからの抜粋を示します。

public static void main(String args[]) throws Exception {
if (args.length > 0)
remoteDomain = args[0];
Pinger obj = new PingImpl();
Context initialNamingContext = new InitialContext();
initialNamingContext.rebind(NAME,obj);
System.out.println("PingImpl created and bound to "+ NAME);
}

3. リモート・インタフェースと実装クラスをJavaコンパイラでコンパイルします。RMI-IIOPアプリケーションにおけるこれらのクラスの開発は、通常のRMIでの開発と同じです。RMIオブジェクト開発の詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』を参照してください。

4. 実装クラスに対してWebLogic RMIまたはEJBコンパイラを実行して、必要なIIOPスタブを生成します。スタブをダウンロードする場合は、rmicを実行する必要はありません。

$ java weblogic.rmic -iiop nameOfImplementationClass

デプロイ時にスタブを生成するには、-iiopおよび-clientJarオプションを付けてappcを実行し、シン・クライアントでの使用に適したクライアントJARを作成します。この手順を実行しない場合、WebLogic Serverで必要に応じて実行時にスタブが生成され、クライアントに提供されます。

スタブはリモート・オブジェクト用のクライアント側プロキシで、個々のWebLogic RMI呼出しを対応するサーバー側スケルトンに転送します。続いてサーバー側スケルトンが、その呼出しを実際のリモート・オブジェクト実装に転送します。

5. ここまでで作成したファイル、すなわち、リモート・インタフェース、それを実装するクラス、およびスタブがWebLogic ServerのCLASSPATHに含まれていることを確かめます。

6. 初期コンテキストを取得します。
RMIクライアントでは、初期コンテキストを作成しリモート・オブジェクトをルックアップして(次のステップを参照)、そのオブジェクトにアクセスします。続いて、このオブジェクトが適切な型にキャストされます。

初期コンテキストの取得では、JNDIコンテキスト・ファクトリを定義する際にweblogic.jndi.WLInitialContextFactoryを使用する必要があります。新しいInitialContext()にパラメータとして渡すContext.INITIAL_CONTEXT_FACTORYプロパティの値を設定する際には、このクラスを使用します。

javax.rmi.PortableRemoteObject.narrow()メソッドと組み合せてルックアップを実行するように、クライアントのコードを修正します。

RMI over IIOP RMIクライアントが通常のRMIクライアントと異なるのは、初期コンテキストを取得する際にプロトコルとしてIIOPが定義されるという点です。このため、ルックアップとキャストは、javax.rmi.PortableRemoteObject.narrow()メソッドと組み合せて行われます。たとえばRMIクライアントは、初期コンテキストを作成し、EJBeanホームをルックアップしてEJBeanへの参照を取得し、EJBean上でメソッドを呼び出します。

通常ならオブジェクトを特定のクラス型へキャストするような状況ではすべて、javax.rmi.PortableRemoteObject.narrow()メソッドを使用する必要があります。CORBAクライアントからは、リモート・インタフェースを実装しないオブジェクトが返されることがあります。そのため、リモート・インタフェースを実装するようオブジェクトを変換するためにORBからnarrowメソッドが提供されます。たとえば、EJBeanホームをルックアップして、その結果をHomeオブジェクトにキャストするクライアント・コードは、以下に示すように、javax.rmi.PortableRemoteObject.narrow()を使用するように修正する必要があります。

例5-1 ルックアップの実行:

.
.
.
/**
* RMI/IIOP clients should use this narrow function
*/
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref, c);
}
/**
* Lookup the EJBs home in the JNDI tree
*/
private TraderHome lookupHome()
throws NamingException
{
// Lookup the beans home using JNDI
Context ctx = getInitialContext();
try {
Object home = ctx.lookup(JNDI_NAME);
return (TraderHome) narrow(home, TraderHome.class);
} catch (NamingException ne) {
log("The client was unable to lookup the EJBHome.  Please
make sure ");
log("that you have deployed the ejb with the JNDI name
"+JNDI_NAME+" on the WebLogic server at "+url);
throw ne;
}
}
/**
* Using a Properties object will work on JDK130
* and higher clients
*/
private Context getInitialContext() throws NamingException {
try {
// Get an InitialContext
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
} catch (NamingException ne) {
log("We were unable to get a connection to the WebLogic
server at "+url);
log("Please make sure that the server is running.");
throw ne;
}
}
.
.
.

urlでは、プロトコル、ホスト名、WebLogic Serverインスタンス用のリスニング・ポートを定義し、それらがコマンド・ライン引数として渡されます。

public static void main(String[] args) throws Exception {
log("\nBeginning statelessSession.Client...\n");
String url = "iiop://localhost:7001";

7. 次のようなコマンドでクライアントを実行することで、IIOPを通じてクライアントをサーバーに接続します。

$ java -Djava.security.manager -Djava.security.policy=java.policy    examples.iiop.ejb.stateless.rmiclient.Client iiop://localhost:7001

プロトコルの互換性

このWebLogic Serverリリースと以前のWebLogic Serverリリースとの相互運用性についての詳細は、『Oracle WebLogic Serverの理解』のWebLogic Serverの互換性に関する項を参照してください。

6 WebLogic JMSシン・クライアント

この章では、WebLogic JMSシン・クライアントを開発、使用およびデプロイする方法について説明します。

- JMSシン・クライアントの概要

- JMSシン・クライアントの機能

- JMSシン・クライアントの使用に関する制限

- JMSシン・クライアントのデプロイ

JMSシン・クライアントの概要

JMSシン・クライアント(wlclient.jarとともにデプロイされたwljmsclient.jar)を使用すると、WebLogicインストール・クライアントまたはフル・クライアントよりもはるかに小さく、シンT3クライアントよりもいくぶん小さいクライアント・サイズで、Java EEおよびWebLogic JMSの機能を提供できます。クライアント・サイズの小ささは、次のものを使用することで実現されています。

- クライアント側プログラムで必要なサポート・ファイルのセットのみを含んだクライアント側ライブラリ。

- JREで使用可能なRMI-IIOPプロトコル・スタック。RMIリクエストはJREによって処理されるため、非常に小さいクライアントを実現できます。

- 標準Java EE API。WebLogic Server APIは使用しません。

WebLogic Serverのシン・クライアント・アプリケーションの開発の詳細は、「シン・クライアントの開発」を参照してください。

JMSシン・クライアントの機能

JMSシン・クライアント(wljmsclient.jarおよびwlclient.jar)は、WebLogicフル・クライアントやWebLogicインストール・クライアントよりもはるかに小さいサイズでありながら、クライアント・アプリケーションおよびアプレットに次の機能を提供します。

- 完全なWebLogic JMSの機能、つまり標準JMSおよびWebLogic拡張機能の両方(マルチキャスト・セッションでのクライアント側XMLの選択とJMSHelperクラス・メソッドを除く)

- EJB (Enterprise JavaBeans)へのアクセス

- JNDIへのアクセス

- RMIへのアクセス(JMSによる間接的な使用)

- SSLアクセス(JREのJSSEを使用)

- トランザクション機能

- クラスタリング機能

- HTTP/HTTPSトンネリング

- 完全な国際化

JMSシン・クライアントの使用に関する制限

JMSシン・クライアントには以下の制限が適用されます。

- wlfullclient.jarファイルのJDBCまたはJMXの機能は提供されません。

- クライアント側のストア・アンド・フォワード(クライアントSAF)はサポートしていません。「JMS SAFを使用したメッセージの確実な送信」を参照してください。

- クライアントにjava.sql.ResultSetを戻すことのできるWebLogic Server CMP 2.x拡張がサポートされていません。

- JDK ORBでのみサポートされます。

- T3プロトコル対応のクライアント(インストール・クライアント、シンT3クライアント、フル・クライアント)に比べて、特に非永続メッセージングでのパフォーマンスが劣ります。

- WebLogic Server 9.2より前のリリースでは自動クライアント再接続はサポートされていません。

JMSシン・クライアントのデプロイ

wljmsclient.jarとwlclient.jarは、WebLogic Serverインストール・ディレクトリのWL_HOME\server\libサブディレクトリにあります。WL_HOMEは、最上位のWebLogic Serverインストール・ディレクトリ(たとえば、c:\Oracle\Middleware\Oracle_Home\wlserver\server\lib)です。

JMSシン・クライアントのデプロイメントには以下の要件があります。

- JMSシン・クライアントでは、クラスタリング、セキュリティ、およびトランザクションのための基本クライアント・サポートを含む標準シン・クライアントが必要になります。このため、wljmsclient.jarとwlclient.jarがクライアント・ファイル・システムのどこかにインストールされている必要があります。ただし、wljmsclient.jarはwlclient.jarを参照するので、クライアントのCLASSPATHにはどちらか一方のJarを指定するだけでかまいません。

- クライアント - サーバー通信にRMI-IIOPが必要になります。

- t3またはt3sを使用するURLでは、透過的にiiopまたはiiopsが使用されます。

- httpまたはhttpsを使用するURLでは、透過的にiiopトンネリングが使用されます。

- IIOPを容易に使用できるようにするには、リスニング・アドレス属性に常に有効なIPアドレスまたはDNS名を指定して、接続をリスニングできるようにしておきます。

注意:

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

- 各クライアントにJRE 1.4.x以降がインストールされている必要があります。

- アプリケーションは、Java EEプログラミングのガイドラインに準拠している必要があります。特に、キャストではなく、PortableRemoteObject.narrow()を使用する必要があります。

WebLogic Serverのシン・クライアント・アプリケーションの開発の詳細は、「シン・クライアントの開発」を参照してください。

7 JMS SAFクライアントによる確実なメッセージ送信

この章では、JMS SAFクライアント機能を構成および使用して、スタンドアロンのJMSクライアントからサーバー側のJMS宛先にメッセージを確実に送信する方法について説明します。

- JMSクライアントでのストア・アンド・フォワードの使い方の概要

- クライアント側のSAFを使用するためのJMSクライアントの構成

- JMS SAFクライアント管理ツール

- JMS SAFクライアントでのJMSプログラミングの考慮事項

- JMS SAFクライアントの相互運用のガイドライン

- JMS SAFクライアントのチューニング

- JMS SAFクライアントの使用に関する制限

- JMS SAFクライアントのメッセージ格納動作の変更

JMSクライアントでのストア・アンド・フォワードの使い方の概要

JMS SAFクライアント機能は、WebLogic Server 9.0で導入したJMSストア・アンド・フォワード・サービスをスタンドアロンJMSクライアントに拡張したものです。この機能を使用することで、JMSクライアントは(一時的なネットワーク接続の障害などが原因で)サーバー側のJMS宛先にアクセスできない場合でも、メッセージを宛先に確実に送信できるようになります。サーバーとの接続が切断されている間、JMS SAFクライアントによって送信されたメッセージはクライアントのファイル・システム上でローカルに格納され、クライアントが再接続したら、サーバー側のJMS宛先に転送されます。

JMS SAFクライアント機能は、主にJMS SAFクライアント実装とSAFフォワーダで構成されています。前者は、ローカルのファイル・システムにあるクライアント側の永続ストアにメッセージを直接書き込むために使用され、後者は、永続ストアに書き込まれたメッセージを取得してWebLogic Serverインスタンスに送信するために使用されます。また、必要に応じてJMS SAFクライアントがSAFフォワーダ・メカニズムを使用するかしないかを設定できるSAFClient初期化API (weblogic.jms.extensions)も用意されています。詳細については、「JMS SAFクライアントの初期化API」を参照してください。

注意:

サーバー側のWebLogic JMS SAFによって、アクセスできない可能性のある宛先にJMSメッセージを確実に送信する方法の詳細は、『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のJMSメッセージに対するSAFの構成に関する項を参照してください。

クライアント側のSAFを使用するためのJMSクライアントの構成

サーバー側では構成を行う必要がありませんが、クライアント側では各クライアントで構成を行う必要があります。以下の節では、クライアント側のSAFを使用するためのJMSクライアントの構成方法について説明します。

- JMS SAFクライアントの構成ファイルの生成

- リモートJMS SAFコンテキストのパスワードの暗号化

- クライアント・マシンへのJMS SAFクライアントのJARファイルのインストール

- JMS SAFクライアントの初期JNDIプロバイダを使用できるようにJMSクライアント・アプリケーションの変更

JMS SAFクライアントの構成ファイルの生成

各クライアント・マシンには、JMS SAFクライアントの構成ファイルが必要です。構成ファイルには、JMS SAFクライアント環境での処理に必要なサーバー側の接続ファクトリと宛先に関する情報を指定します。指定のJMSモジュールの構成ファイルからJMS SAFクライアントの構成ファイルを生成するには、インストールしたWebLogicに付属しているClientSAFGenerateユーティリティを使用します。

JMSモジュールからJMS SAFクライアントの構成ファイルを生成するための手順で説明しているように、ClientSAFGenerateユーティリティはソースのJMS構成ファイルで見つかったすべての接続ファクトリ、スタンドアロン宛先および分散宛先用にエントリを作成します。JMS SAFクライアントの初期JNDIプロバイダを使用できるようにJMSクライアント・アプリケーションの変更に記述された初期のJNDIコンテキストを通してJMS SAFクライアントが直接相互作用する接続ファクトリおよびインポート済み宛先が、生成されたファイルで定義されます。しかも、SAFエクスポート・ポリシーがAllに設定されたJMS宛先のみが、ファイルに追加されます(宛先のデフォルト設定)。

JMS SAFクライアントの構成ファイルの仕組み

JMS SAFクライアントのXMLファイルは、JMSモジュールがWebLogic Server weblogic-jms.xsdスキーマに準拠し、ルート要素weblogic-client-jmsを持っています。weblogic-jms.xsdスキーマには、サーバー側のWebLogic SAF JMS機能に対応する最上位要素がいくつかあります。詳細については、「JMS SAFクライアントの構成での有効なSAF要素」を参照してください。

ファイルの最上位要素には、JMS SAFクライアントが直接対話する接続ファクトリとインポート済み宛先の要素が記述されています。SAF送信エージェント、リモートSAFコンテキスト、およびSAFエラー処理の要素には、SAFフォワーダの機能が記述されています。永続ストアの要素は、JMS SAFクライアントAPIとSAFフォワーダの両方で使用されます。

JMSモジュールからJMS SAFクライアントの構成ファイルを生成するための手順

ClientSAFGenerateユーティリティを使用して、WebLogicドメインのJMSモジュール構成ファイルからJMS SAFクライアントの構成ファイルを生成します。また、構成ファイルは既存のJMS SAFクライアントの構成ファイルから生成することもできます。詳細については、「ClientSAFGenerateユーティリティの構文」を参照してください。

注意:

クライアント・マシン上でClientSAFGenerateユーティリティを実行して、既存のJMS SAFクライアントの構成ファイルから構成ファイルを生成する場合、シンJMSクライアントやJMS SAFクライアントではなく、CLASSPATH内のwlfullclient.jarを使用する必要があります。「クライアント・マシンへのJMS SAFクライアントのJARファイルのインストール」を参照してください。

次の手順は、ClientSAFGenerateユーティリティを使用して、インストールしたWebLogic Serverに付属しているexamples-jms.xmlモジュール・ファイルからJMS SAFクライアントの構成ファイルを生成する方法を示しています。

1. JMS SAFクライアントの構成ファイルのベースとして使用するJMSモジュール・ファイルが存在するWebLogicドメインのディレクトリに移動します。

c:\Oracle\Middleware\wlserver_12.1\samples\domains\wl_server\config\jms

2. Javaコマンド・ラインでClientSAFGenerateユーティリティを実行します。

> java weblogic.jms.extensions.ClientSAFGenerate -url http://10.61.6.138:7001 -username weblogic -moduleFile examples-jms.xml -outputFile d:\temp\ClientSAF-jms.xml

表7-1に、有効なClientSAFGenerateの引数を示します。

3. SAFClient-jms.xmlという構成ファイルがカレント・ディレクトリに作成されます。以下に、その主な内容の例を示します。

<weblogic-client-jms xmlns="http://www.bea.com/ns/weblogic/100" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<connection-factory name="exampleTrader">
<jndi-name>jms.connection.traderFactory</jndi-name>
<transaction-params>
<xa-connection-factory-enabled>false
</xa-connection-factory-enabled>
</transaction-params>
</connection-factory>
<saf-imported-destinations name="examples">
<saf-queue name="exampleQueue">
<remote-jndi-name>weblogic.examples.jms.exampleQueue
</remote-jndi-name>
<local-jndi-name>weblogic.examples.jms.exampleQueue
</local-jndi-name>
</saf-queue>
<saf-topic name="quotes">
<remote-jndi-name>quotes</remote-jndi-name>
<local-jndi-name>quotes</local-jndi-name>
</saf-topic>
</saf-imported-destinations>
<saf-remote-context name="RemoteContext0">
<saf-login-context>
<loginURL>t3://localhost:7001</loginURL>
<username>weblogic</username>
</saf-login-context>
</saf-remote-context>
</weblogic-client-jms>

ヒント:

クラスタまたはドメインにデプロイされた他のJMSモジュールからリモートSAF接続ファクトリと宛先を追加するには、これらのJMSモジュールに対してClientSAFGenerateユーティリティを再実行します。その際、-outputFileパラメータに同じJMS SAF構成ファイル名を指定します。「ClientSAFGenerateユーティリティの構文」を参照してください。

4. 生成された構成ファイルには、SAFリモート・コンテキストがリモート・サーバーに接続する際に使用する暗号化されたパスワードが含まれていません。暗号化されたリモートSAFコンテキストのパスワードを作成して、構成ファイルに追加するには、「リモートJMS SAFコンテキストのパスワードの暗号化」の説明に従ってください。

5. JMS SAFクライアント・アプリケーションが実行されるクライアント・マシンに、生成された構成ファイルをコピーします。「クライアント・マシンへのJMS SAFクライアントのJARファイルのインストール」を参照してください。

注意:

デフォルトでは、JMSクライアントの現在の作業ディレクトリにClientSAF.xmlが作成されます。ただし、JMSクライアントに引数を渡すことによってファイル名を明示的に指定することもできます。詳細については、「JMS SAFクライアントの初期JNDIプロバイダを使用できるようにJMSクライアント・アプリケーションの変更」を参照してください。

ClientSAFGenerateユーティリティの構文

weblogic.jms.extensions.ClientSAFGenerateユーティリティは、JMSモジュール・ファイルまたは既存のJMS SAFクライアントの構成ファイルを使用して、JMS SAFクライアントの構成ファイルを生成します。

java [ weblogic.jms.extensions.ClientSAFGenerate ]
[ -url server-url ]
[ -username name-of-user ]
[ -existingClientFile file-path ]
[ -moduleFile file-path ['@' plan-path ]]*
[ -outputFile file-path  ]

表7-1 ClientSAFGenerateの引数

引数

定義

url

JMS SAFクライアントが接続するWebLogic ServerインスタンスのURL。

username

このJMS SAFクライアント・インスタンスがメッセージを転送する際に使用する有効なユーザーの名前。

existingClientFile

既存のJMS SAFクライアントの構成ファイルの名前。このパラメータを指定すると、既存のファイルが読み取られ、新しいエントリが追加されます。追加される項目とすでにJMS SAFクライアントの構成ファイルに存在する項目との間で競合が検出された場合は、警告が発生して新しい項目は追加されません。指定されたJMS SAFクライアントの構成ファイルが見つからない場合は、エラーが出力されてユーティリティは終了します。

moduleFile

JMSモジュール構成ファイルとプラン・ファイル(オプション)の名前。

outputFile

stdout

デフォルトでは、JMSクライアントの現在の作業ディレクトリにClientSAF.xmlが作成されます。ただし、JMSクライアントに引数を渡すことによってファイル名を明示的に指定することもできます。

JMS SAFクライアントの構成での有効なSAF要素

weblogic-jms.xsdスキーマのweblogic-client-jmsルート要素には、サーバー側のWebLogic SAF JMS機能に対応する最上位要素がいくつか含まれています。表7-2に、スキーマの最上位要素とそれらに対応する管理MBeanを示します。

表7-2 weblogic-client-safの要素

weblogic-client-jms要素

WebLogic Serverの管理Bean

connection-factory

JMSConnectionFactoryBean

saf-agent

SAFAgentMBean

saf-imported-destinations

SAFImportedDestinationsBean

saf-remote-context

SAFRemoteContextBean

saf-error-handling

SAFErrorHandlingBean

persistent-store

詳細については、「JMS SAFクライアントのデフォルト・ストア・オプション」を参照してください。

注意:

JMS SAFクライアントの構成ファイルで指定できるのは、1つのpersistent-storeおよびsaf-agent要素のみです。

これらの管理MBeanのすべてのプロパティは、JMS SAFクライアント実装でもサーバー側のSAF JMS構成の場合と同じように機能します。ただし、次の表に示すものは除きます。

表7-3に、標準のSAFAgentMBeanフィールドとJMS SAFクライアントの構成ファイルのフィールドとの相違点を示します。

表7-3 SAFAgentMBeanフィールドの変更点

サーバー側のSAFフィールド

JMS SAFクライアントの構成ファイルとの相違点

PersistentStore

使用不可。定義される永続ストアは1つのみです。

ServiceType

使用不可。これは送信エージェントにしかなれません。

BytesThresholdHigh

しきい値プロパティは使用不可です。

BytesThresholdLow

しきい値プロパティは使用不可です。

MessagesThresholdHigh

しきい値プロパティは使用不可です。

MessagesThresholdLow

しきい値プロパティは使用不可です。

ConversationIdleTimeMaximum

使用不可。このフィールドはメッセージの受信でのみ有効です。

AcknowledgeInterval

使用不可。このフィールドはメッセージの受信でのみ有効です。

IncomingPausedAtStartup

使用不可。休止を解除する方法はありません。JMS SAFクライアント・プロパティを設定しないことにより、同じ効果を得られます。

ForwardingPausedAtStartup

使用不可。休止を解除する方法はありません。JMS SAFクライアント・プロパティを設定しないことにより、同じ効果を得られます。

ReceivingPausedAtStartup

使用不可。休止を解除する方法はありません。JMS SAFクライアント・プロパティを設定しないことにより、同じ効果を得られます。

注意:

JMS SAFクライアントの構成ファイルで指定できるのは、1つのsaf-agent要素のみです。

表7-4に、標準のJMSConnectionFactoryBeanフィールドとJMS SAFクライアントの構成ファイルのフィールドとの相違点を示します。

表7-4 JMSConnectionFactoryBeanフィールドの変更点

サーバー側のSAFフィールド

JMS SAFクライアントの構成ファイルとの相違点

SubDeploymentName

無視されます。これらの接続ファクトリはターゲットになりません。

ClientParamsBean: MulticastOverrunPolicy

無視されます。このクライアントはマルチキャスト受信を実行できません。

TransactionParamsBean: XAConnectionFactoryEnabled

無視されます。JMS SAFクライアントはXAトランザクションを実行できません。

FlowControlParamsBean

すべてのフィールドが無視されます。JMS SAFクライアントはメッセージを受信できません。

LoadBalancingParamsBean

すべてのフィールドが無視されます。JMS SAFクライアントはサーバーに接続されてないため、ロード・バランシングができません。

表7-5に、標準のSAFImportedDestinationsBeanフィールドとJMS SAFクライアントの構成ファイルのフィールドとの相違点を示します。

表7-5 SAFImportedDestinationsBeanフィールドの変更点

サーバー側のSAFフィールド

JMS SAFクライアントの構成ファイルとの相違点

SubDeploymentName

無視されます。これらは、このファイルで定義される1つのSAFエージェントをターゲットにしています。

UnitOfOrderRouting

無視されます。メッセージ順序単位はサポートしません。

JMS SAFクライアントのデフォルト・ストア・オプション

各JMS SAFクライアントは、構成を必要としないデフォルト・ストアを持っており、このストアは複数のJMS SAFクライアントで共有できます。デフォルト・ストアはファイル・ベースのストアで、JMS SAFクライアントの構成ディレクトリ直下のファイル・グループにデータを保持します。

persistent-store要素を使用すると、デフォルト・ストアに別の場所を指定でき、次の要素をJMS SAFクライアントの構成ファイルに指定することによって、デフォルトの書込みポリシーを変更することもできます。

表7-6 persistent-storeの要素

要素名

機能

directory-path

ファイル・ストアを保持するディレクトリのファイル・システム上のパス名を指定します。

synchronous-write-policy

ファイル・ストアがディスクにレコードをフラッシュする方法を定義します。指定できる値は、「Direct-Write」 (デフォルト)、「Cache-Flush」、および「Disabled」です。

注意:

JMS SAFクライアントの構成ファイルで指定できるのは、1つのpersistent-store要素のみです。

次に、JMS SAFクライアントの構成ファイルにおけるカスタマイズされたJMS SAFクライアントのデフォルト・ストアの例を示します。

<persistent-store>
<directory-path>config/jms/storesdom</directory-path>
<synchronous-write-policy>Disabled</synchronous-write-policy>
</persistent-store>

ファイル・ストアに対して同期書込みポリシーを使用する方法の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用方法に関する項を参照してください。

リモートJMS SAFコンテキストのパスワードの暗号化

生成されたSAF構成ファイルには、ソースJMSモジュール・ファイルに構成されているかどうかに関係なく、暗号化されたSAFリモート・コンテキストのパスワードが含まれていません。JMS SAFクライアントの構成ファイルで定義されるリモートのクラスタまたはサーバーのコンテキストに対しセキュリティ資格証明が構成される場合、リモートのサーバーまたはクラスタに接続する際に、暗号化されたパスワードが必要になります。

暗号化されたリモートSAFコンテキストのパスワードを作成するには、インストールしたWebLogicに付属しているClientSAFEncryptユーティリティを使用する必要があります。このユーティリティを使用すると、クリア・テキストの文字列をJMS SAFクライアント用に暗号化することができます。

注意:

既存のweblogic.security.Encryptコマンド・ライン・ユーティリティは、ドメイン・セキュリティ・ファイルへのアクセスが想定されるため、クライアントでは使用できません。

暗号化されたパスワードの生成手順

以下に、ClientSAFEncryptを使用して暗号化されたパスワードを生成する手順を示します。

1. Javaコマンド・ラインでClientSAFEncryptユーティリティを実行します。

> java -Dweblogic.management.allowPasswordEcho=true weblogic.jms.extensions.ClientSAFEncrypt [ key-password ] [ remote-password ]*

2. key-passwordフィールドまたはremote-passwordフィールドが指定されていない場合は、key-passwordとremote-passwordを指定するよう対話形式で求められます。

3. 次に、暗号化されたパスワードを取得する例を示します。

Password Key ("quit" to end):
Password ("quit" to end):
<password-encrypted>{Algorithm}PBEWithMD5AndDES{Salt}9IsTPAuZdcQ={Data}d6SSPp3GwPAfEXn8izyZA0IRCV/izT8H</password-encrypted>
Password ("quit" to end):

4. JMS SAFクライアントの構成ファイルに定義されているリモート・コンテキストに必要な数だけリモート・パスワードを生成します。

5. 暗号化されたリモート・パスワードをコピーして、JMS SAFクライアントの構成ファイルの</saf-login-context>スタンザの前に貼り付けます。例:

<saf-remote-context name="RemoteContext0">
<saf-login-context>
<loginURL>http://10.61.6.138:7001</loginURL>
<username>weblogic</username>
<password-encrypted>{Algorithm}PBEWithMD5AndDES{Salt}dWENfrgXh8U={Data}u8xZ968dElHckso/ZYm2LQ6xVNBPpBGQ</password-encrypted>
</saf-login-context>
</saf-remote-context>

JMS SAFクライアントの構成ファイルに定義されているリモート・コンテキストで必要になるすべてのパスワードに対して、同じkey-passwordを指定してClientSAFEncryptユーティリティを使用します。クライアントがJMS SAFクライアントの使用を開始する際、ClientSAFEncryptユーティリティに指定した同じkey-passwordを使用する必要があります。

6. quitと入力して、ClientSAFEncryptユーティリティを終了します。

ClientSAFEncryptユーティリティの構文

weblogic.jms.extensions.ClientSAFEncryptユーティリティは、クリア・テキストの文字列をJMS SAFクライアント用に暗号化して、リモートSAFコンテキストにアクセスできるようにします。

java [ -Dweblogic.management.allowPasswordEcho=true ]  weblogic.jms.extensions.ClientSAFEncrypt [ key-password ]  weblogic.jms.extensions.ClientSAFEncrypt [ remote-password ]

表7-7 ClientSAFEncryptの引数

引数

定義

weblogic.management.allowPasswordEcho

オプション。コマンド・ラインで入力した文字がエコー表示されるようにします。weblogic.jms.extensions.ClientSAFEncryptでは表示されないことを想定しているため、表示する場合は、このプロパティをtrueに設定します。

key-password

JMS SAFクライアントの構成ファイルに定義されているリモート・コンテキストに必要なすべてのリモート・パスワードを暗号化する際に使用するキー。

コマンド・ラインで省略した場合は、key-passwordの入力を求められます。

remote-password

暗号化するクリア・テキストの文字列。1つのセッションで生成される各リモート・コンテキストに対する複数のパスワード。

コマンド・ラインで省略した場合は、remote-passwordの入力を求められます。

クライアント・マシンへのJMS SAFクライアントのJARファイルのインストール

WebLogic Serverでは、JMS SAFクライアントを次の3種類から選択できます。

- weblogic.jar(「WebLogicインストール・クライアント」を参照)

- wlfullclient.jar(「WebLogicフル・クライアント」を参照してください)

- wlsafclient.jar、wljmsclient.jarおよびwlclient.jarを使用するシン・クライアント

必要なJARファイルは、WebLogic Serverインストール・ディレクトリのWL_HOME\server\libサブディレクトリにあります。WL_HOMEは、インストールしたWebLogic製品全体の最上位インストール・ディレクトリ(たとえば、c:\Oracle\Middleware\Oracle_Home\wlserver\server\lib)です。

JARのサイズの小ささが重要視される場合を除き、パフォーマンスの高いWebLogicフル・クライアントまたはインストール・クライアントを使用することをお薦めします。wlfullclient.jarを使用するには、これをクライアント・マシンのファイル・システム上のディレクトリにコピーし、クライアント・マシンのCLASSPATHに追加します。また、JMSモジュールからJMS SAFクライアントの構成ファイルを生成するための手順で説明しているように、wlfullclient.jarファイルを使用してClientSAFGenerateユーティリティをクライアント・マシン上で実行して、既存のJMS SAFクライアント構成ファイルから構成ファイルを生成できます。シン・クライアント用にサイズのより小さいJARが必要な場合、JMS SAFクライアントのファイル・システム上のディレクトリに次のJARファイルをインストールし、それらをCLASSPATHに追加する必要があります。

- wlsafclient.jar

- wljmsclient.jar

- wlclient.jar

wljmsclient.jarはwlclient.jarを参照するので、CLASSPATHにはどちらか一方のJARを指定するだけでかまいません。

シン・クライアントのデプロイの詳細は、「シン・クライアントの概要」を参照してください。

注意:

WebLogicシンT3クライアントは、wlsafclient.jarおよびwljmsclient.jarを使用するJMS SAFクライアントをサポートしません。WebLogicシンT3クライアントを使用するJMS SAFクライアントを作成する方法は、「WebLogicシンT3クライアントの理解」を参照してください。

JMS SAFクライアントの初期JNDIプロバイダを使用できるようにJMSクライアント・アプリケーションの変更

JMS SAFクライアントには、JMSモジュールからJMS SAFクライアントの構成ファイルを生成するための手順で生成したJMS SAFクライアントの構成ファイルに指定されたサーバー側のJMS接続ファクトリと宛先をルックアップするために、初期JNDIプロバイダが必要になります。

JMS SAFクライアントに必要なJNDIコンテキスト・ファクトリ

JMSクライアント・アプリケーションを変更して、標準のサーバー初期コンテキストのかわりにJMS SAFクライアントのJNDIコンテキスト・ファクトリを使用するようにします。JMS SAFクライアントのJNDIプロパティjava.naming.factory.initialに使用する名前は、weblogic.jms.safclient.jndi.InitialContextFactoryImplです。

JMS SAFクライアント・アプリケーションのJNDI初期コンテキスト・ファクトリの例は、次のようになります。

public final static String JNDI_FACTORY="weblogic.jms.safclient.jndi.InitialContextFactoryImpl";

標準のJNDIルック・アップを使用して、JMS SAFクライアントは自動的に起動され、構成ファイルに指定されたサーバー側のJMS接続ファクトリと宛先をルック・アップします。デフォルトでは、JMSクライアントの現在の作業ディレクトリにClientSAF.xmlという構成ファイルが作成されます。ただし、JMSクライアントに引数を渡すことによって構成ファイルの名前を明示的に指定することもできます。

JMS SAFクライアントで作成された初期コンテキストから返される項目は、サード・パーティのJMSプロバイダからのJMS呼出しでは処理できません。また、JMS SAFクライアントの初期コンテキストとサーバーの初期コンテキストを混在させることはできません。詳細については、「JMS SAFクライアントのコンテキストとサーバーのコンテキストは混在できない」を参照してください。

また、JMSクライアント・アプリケーションを更新して「weblogic.jms.extensions.ClientSAF」拡張クラスを使用可能にすることができます。これによって、JMSクライアントがJMS SAFクライアント・システムの使用を制御することができるようになります。「JMS SAFクライアントの初期化API」を参照してください。

JMS SAFクライアントの任意指定のJNDIプロパティ

次のような2つの任意指定のJMS SAFクライアントのJNDIプロパティがあります。

- Context.PROVIDER_URL - これは、JMS SAFクライアントの構成ファイルを指すURLでなければなりません。このプロパティを指定しない場合は、JVMの現在の作業ディレクトリにClientSAF.xmlというファイルがデフォルトで作成されます。

- Context.SECURITY_CREDENTIALS - セキュリティを使用する場合、構成ファイルのリモート・コンテキスト・パスワードを暗号化するのに使用するキー・パスワードを指定します。

ローカルJNDIプロバイダでは、lookup(String) APIおよびclose() APIしかサポートされていません。その他のAPIではすべて、機能がサポートされていない旨の例外がスローされます。

JMS SAFクライアント管理ツール

次の管理機能は、JMS SAFクライアント実装で使用できます。

- JMS SAFクライアントの初期化API

- クライアント側のストア管理ユーティリティ

JMS SAFクライアントの初期化API

weblogic.jms.extensions.ClientSAF拡張クラスを使用すると、JMSクライアントがJMS SAFクライアント・システムの使用を制御することができるようになります。JMSクライアントではこの拡張メカニズムを使用する必要はありませんが、これを使用すると、JMS SAFクライアント・システムをきめ細かく制御することができます。たとえば、close()メソッドを使用すると、JMSクライアントがメッセージを転送しないようにすることができます。

クライアント側のストア管理ユーティリティ

JMS SAFクライアントには、JMS SAFクライアントが使用するデフォルトのファイル・ストアを管理するユーティリティが用意されています。サーバー側のWebLogicストア・ユーティリティと同様に、JMS SAFクライアント・ストアのトラブルシューティングを行ったり、データを抽出したりできます。このユーティリティは、Javaコマンド・ラインからでもWebLogic Scripting Tool (WLST)からでも実行することができます。ストア・ユーティリティで操作できるのは、実行中のJMS SAFクライアントが現在開いていないストアのみです。

ストア管理の最も一般的な使用例は、サイズを減らすためにファイル・ストアを圧縮する場合や、トラブルシューティングの目的でファイル・ストアの内容をXMLファイルにダンプする場合です。詳細は、『Oracle WebLogic Serverサーバー環境の管理』の永続ストアの管理に関する項を参照してください。

JMS SAFクライアントでのJMSプログラミングの考慮事項

JMS SAFクライアントを使用する場合、次のJMSプログラミングの考慮事項が適用されます。

- JMS SAFクライアント・メッセージでのJMSReplyToフィールドの処理方法

- JMS SAFクライアントのコンテキストとサーバーのコンテキストは混在できない

- JMS SAFクライアントでのトランザクション・セッションの使用

JMS SAFクライアント・メッセージでのJMSReplyToフィールドの処理方法

一般的に、JMSアプリケーションはJMSReplyToヘッダー・フィールドを使用して、一時的な宛先の名前を他のアプリケーションに対して公開できます。ただし、サーバー側のJMS SAFインポート済み宛先の場合と同様に、JMSReplyToフィールドを持つ一時的な宛先の使用はJMS SAFクライアントでサポートされていません。

JMS一時宛先の使用方法の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の一時的な宛先の使用に関する項を参照してください。

JMS SAFクライアントのコンテキストとサーバーのコンテキストは混在できない

JMS SAFクライアントのネーミング・コンテキストから返される項目をサーバーの初期コンテキストから返される項目と一緒に使用すると、JMS APIが失敗し、その旨の例外メッセージが表示されます。同様に、サーバーの初期コンテキストから返される項目をJMS SAFクライアントのネーミング・コンテキストから返される項目と一緒に使用すると、JMS APIが失敗し、その旨の例外メッセージが表示されます。

JMS SAFクライアントでのトランザクション・セッションの使用

JMS SAFクライアントでのトランザクション・セッションはサポートされていますが、クライアントSAF操作は、グローバル(XA)トランザクションへ一切参加しません。XAトランザクションがある場合、メッセージ送信処理はXAトランザクションの外部で行われ、例外はスローされません。

JMS SAFクライアントの相互運用のガイドライン

相互運用のガイドラインは、JMS SAFクライアントを使用してサーバー側のWebLogic JMSにメッセージを転送する場合に適用されます。

- Javaランタイム

- WebLogic Serverのバージョン

- JMS C API

Javaランタイム

各クライアント・マシンには、Java SE 1.4以降のランタイムがインストールされている必要があります。

WebLogic Serverのバージョン

WebLogicのJMS SAFクライアント・システムは、WebLogic Server 9.2以降でのみ機能します。

クライアント側のJMS SAFクライアント・コードは、リリース9.2以降のWebLogic Server JARファイルで実行される必要があります。WebLogic Server JARファイルのインストールの詳細は、「クライアント・マシンへのJMS SAFクライアントのJARファイルのインストール」を参照してください。

JMS C API

クライアント側のSAFは、JMS C APIを使用するC環境から使用できます。このJMS C APIの実装では、Java仮想マシン(JVM)へのアクセスにJNIを使用します。ただし、JMS C APIは、非標準のJMS APIあるので、「weblogic.jms.extensions.ClientSAF」インタフェースを使用できません。

JMS C APIでSAFを使用するには、SAFコンテキストをjndiFactoryに設定します。デフォルトでは、jndiFactoryとしてNULLを渡すと、通常のWebLogic Serverコンテキストを取得できます。例:

int JmsContextCreate(JmsString *uri, JmsString *jndiFactory, JmsString *username, JmsString *password, JmsContext **context, JMS64I flags)

詳細は、Oracle WebLogic Server JMSアプリケーションの開発のWebLogic C APIに関する項を参照してください。

JMS SAFクライアントのチューニング

JMS SAFクライアントでは、サーバー側のSAFサービスで使用可能なパラメータのチューニングを利用することができます。詳細は、Oracle WebLogic ServerのパフォーマンスのチューニングのWebLogic JMSストア・アンド・フォワードのチューニングに関する項を参照してください。

JMS SAFクライアントの使用に関する制限

JMS SAFクライアントでは、「JMS SAFクライアントの構成での有効なSAF要素」で説明したフィールド・レベルの制限のほか、次の制限も適用されます。

- JMSメッセージ順序単位および作業単位JMSメッセージ・グループ機能はサポートされません。

- インポート済みSAF宛先の宛先コンシューマはサポートされません。JMS SAFクライアント環境でこのようなコンシューマを作成しようとすると、例外がスローされます。

- インポート済みSAF宛先の宛先ブラウザはサポートされません。JMS SAFクライアント環境でこのようなブラウザを作成しようとすると、例外がスローされます。

- ユーザー(XA)トランザクションを除き、トランザクション・セッションはサポートされません。クライアントSAF操作は、グローバル・トランザクションへ一切参加しません。「JMS SAFクライアントでのトランザクション・セッションの使用」を参照してください。

- JMS SAFクライアントはJavaアプレットではサポートされません。

- JMS SAFクライアントの構成ファイルで指定できるのは、1つのpersistent-storeおよびsaf-agent要素のみです。

- クライアントにjava.sql.ResultSetを戻すことのできるWebLogic Server CMP 2.x拡張がサポートされていません。

JMS SAFクライアントのメッセージ格納動作の変更

Weblogic JMS SAFクライアントでは、メッセージはローカル記憶域に格納されてから、リモート宛先に転送されます。リモート宛先はそれぞれ、カーネル・キューと呼ばれるローカル記憶域ユニットに対応しています。WebLogic Server 10.3.3.0より前のリリースでは、JMS SAFクライアント・インスタンスを閉じて再度開くたびに、異なるカーネル・キューが使用されます。この動作は、1つの宛先に対して複数のカーネル・キューが対応する原因となっていました。宛先の種類によって、次のような問題が考えられます。

- 単一のリモート宛先の場合: 状況によっては、JMS SAFクライアントからメッセージが転送されない、または誤った順序で転送される可能性があります。

- 分散した宛先: 状況によっては、メッセージが永久に失われる、または重複して送信される可能性があります。

このリリースでは、JMS SAFクライアントを何度開いて閉じても、1つのリモート宛先に対して同じカーネル・キューが使用されます。JMSクライアントのSAFインスタンスを一度しか開かないアプリケーション環境では、動作に変更はありません。

アップグレード・プロセス、ツールおよびシステム・プロパティ

この後の項では、JMS SAFクライアントのアップグレードに使用するプロセス、ツールおよびシステム・プロパティについて説明します。アップグレードを行うことで、クライアントがカーネル・キューを何度開いて閉じても、各宛先に対して1つのカーネル・キューが使用されるようになります。

- JMS SAFクライアントを一度しか開かないアプリケーション環境では、操作は不要です。

- 新しいJMS SAFクライアントは変更不要です。

- JMS SAFクライアントを複数回開いて閉じるアプリケーション環境では、既存のメッセージがクライアントの複数のカーネル・キューに存在する可能性があります。オラクル社は、アップグレード後初めてJMS SAFクライアントが起動したときに、メッセージを複数のカーネル・キューから単一のカーネル・キューに移行するプロセスを用意しており、このプロセスはユーザーによる調整が可能です。移行の際に、メッセージが失われないことは保証されていますが、メッセージの重複が発生する可能性がわずかにあります。移行されたメッセージはすべて、通常のSAF QoSを維持しています。ローカル・ストアを削除するか、weblogic.jms.safclient.MigrateExistingMessages=falseと指定すれば、既存のメッセージが移行されないようにすることができます。第7章「JMS SAFクライアント移行プロパティ」を参照してください。メッセージの移行が何らかの原因で失敗した場合、JMS SAFクライアントは起動できなくなります。

JMS SAFクライアント検出ツール

検出ツールは、WLS JMSクライアント・ライブラリにパッケージ化されたJavaプログラムで、アップグレード前に既存のローカルSAFメッセージを調査する目的で使用できます。各リモート宛先と対応するカーネル・キューのチェックなど、クライアント構成の確認を行い、各カーネル・キューのメッセージ数、および各カーネル・キューの最初のメッセージのヘッダー情報(メッセージID、相関ID、SAFシーケンス名、SAFシーケンス番号、順序単位など)を出力します。調査の結果は、アップグレード・システム・プロパティのチューニングに利用できます。第7章「JMS SAFクライアント移行プロパティ」を参照してください。

使用方法: java weblogic.jms.extensions.ClientSAFDiscover options

optionsについては、次の表で説明します。

オプション

説明

-help

使用方法に関する情報を出力します。

-clientSAFRootDir <client-saf-root-directory>

オプション。デフォルトは現在のディレクトリです。

検出するターゲットとなるSAFクライアントのルート・ディレクトリ。SAFクライアント構成ファイル内の相対パスは、このディレクトリを基準としています。

-configurationFile <configuration-file>

オプション。デフォルトはClientSAF.xmlです。

ターゲットとなるJMS SAFクライアントが使用する構成ファイルの場所。このオプションは、clientSAFRootDirオプションを指定した場合に必要です。clientSAFRootDirオプションまたはこのオプションを指定すると、現在の作業ディレクトリにあるClientSAF.xmlファイルが使用されます。指定した構成ファイルが存在しない場合は、例外がスローされます。

-cutoffFormat <pattern>

オプション。デフォルトはyyyy-MM-dd'T'HH:mm:ss.SSSZです。

オプションで使用するカットオフ時間の日時パターン。詳細は、http://docs.oracle.com/javase/7/docs/api/java/text/DateFormat.htmlを参照してください。

-cutoffTime <cutoff-time>

オプション。デフォルトはnullです。

weblogic.jms.safclient.MigrationCutoffTimeが設定されている場合に、アップグレード中に破棄されるメッセージのデータを出力します。メッセージは破棄されません。カットオフ時間フォーマットは、-cutoffFormatに依存します。指定したカットオフ時間がcutoffFormatパターンに一致しない場合、例外がスローされます。カットオフ時間が指定されていない場合は、メッセージは破棄も出力もされません。

-discoveryFile <discovery-file>

オプション。デフォルトはSAF_DISCOVERYです。

ClientSAFDiscoverによって生成された出力を格納するファイル。絶対パスを指定しないかぎり、このファイルはルート・ディレクトリを基準とする相対的な場所に配置されます。指定したファイルがすでに存在する場合、そのファイルは削除され、新しいファイルが作成されます。

例

次のコマンドを使用してJMS SAFクライアントを作成したとします。

ClientSAFFactory.getClientSAF(new File("c:\\foo"), new FileInputStream("c:\\ClientSAF-jms.xml"));

JMS SAFクライアントをアップグレードする前に、ClientSAFDiscoverツールを使用して既存のメッセージを調査できます。例:

java weblogic.jms.client.ClientSAFDiscover -clientSAFRootDir c:\foo -configurationFile c:\ClientSAF-jms.xml

検出情報は、デフォルトの場所であるc:\foo\SAF_DISCOVERYに書き込まれます。

JMS SAFクライアント移行プロパティ

メッセージの移行は自動化されていても複雑な問題であるため、移行プロセスを管理するための次のシステム・プロパティが用意されています。

- weblogic.jms.safclient.MigrateExistingMessages: falseの場合、複数のキューから単一のキューへのメッセージの移行は行われません。デフォルトはtrueです。

- weblogic.jms.safclient.MigrationCutoffTime: メッセージが単一のカーネル・キューに移行された後、時間と、weblogic.jms.safclient.MigrationCutoffTimeFormatで指定された形式を指定するために使用します。残っているメッセージはすべて破棄されます。指定しない場合、すべての既存メッセージがアップグレードされます。
たとえば、カットオフ形式がデフォルトの場合、有効なカットオフ時間は2009-12-16T10:34:17.887-0800です。指定した時間が形式のパターンに一致しない場合は例外がスローされ、JMS SAFクライアントはメッセージの処理をすべて停止します。

- weblogic.jms.safclient.MigrationCutoffTimeFormat: weblogic.jms.safclient.MigrationCutoffTimeの形式を指定します。デフォルトはyyyy-MM-dd'T'HH:mm:ss.SSSZです。詳細は、java.text.SimpleDateFormatクラスのjavadocを参照してください。

8 Java SEクライアントの開発

この章では、Java SEクライアントの開発方法と使用方法について説明します。Java SEクライアントはJava EEプログラミング・モデルを指向しており、WebLogic ServerクラスなしでRMIの機能とIIOPプロトコルが一体化されています。

- Java SEクライアントの基本

- Java SEクライアントの開発方法

Java SEクライアントの基本

Java SEクライアントは、Java EEまたはJava SEコンテナ(ほとんどの場合、JDK 1.6以降)をホストとするRMI-IIOP対応ORBを実行します。Java SEクライアントには次の特性があります。

- 業界標準であるIIOPを使用する軽量な接続クライアントを提供します。

- Java EE準拠モデルではなくJava SE準拠モデル。このため、エンタープライズ・レベルのアプリケーションで提供される多数の機能はサポートしていません。また、セキュリティ、トランザクション、JMSもサポートしていません。

- クライアントのEJB 2.1リモート・クライアント・ビューを通じて、EJB 3.0仕様に基づくEJBの分散相互運用がWebLogic Serverによってサポートされます。

Java SEクライアントの開発方法

RMIクライアント使用型RMI-IIOPを用いてアプリケーションを開発するには:

1. リモート・オブジェクトのパブリック・メソッドを、java.rmi.Remoteを拡張するインタフェースに定義します。
このリモート・インタフェースには、コードをあまり記述する必要がない場合もあります。必要なのは、リモート・クラスで実装するメソッドのメソッド・シグネチャだけです。例:

public interface Pinger extends java.rmi.Remote {
public void ping() throws java.rmi.RemoteException;
public void pingRemote() throws java.rmi.RemoteException;
public void pingCallback(Pinger toPing) throws java.rmi.RemoteException;
}

2. interfaceNameImplというクラスにインタフェースを実装し、それをJNDIツリー内にバインドしてクライアントから利用できるようにします。
このクラスには、記述済みのリモート・インタフェースを実装する必要があります。これにより、インタフェースに含まれるメソッド・シグネチャを実装したことになります。すべてのコード生成はこのクラス・ファイルに依存します。通常は、実装クラスをWebLogic起動クラスとして構成し、そのオブジェクトをJNDIツリー内にバインドするmainメソッドをインクルードします。例:

public static void main(String args[]) throws Exception {
if (args.length > 0)
remoteDomain = args[0];
Pinger obj = new PingImpl();
Context initialNamingContext = new InitialContext();
initialNamingContext.rebind(NAME,obj);
System.out.println("PingImpl created and bound to "+ NAME);
}

3. リモート・インタフェースと実装クラスをJavaコンパイラでコンパイルします。RMI-IIOPアプリケーションにおけるこれらのクラスの開発は、通常のRMIでの開発と同じです。RMIオブジェクト開発の詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』を参照してください。

4. 実装クラスに対してWebLogic RMIまたはEJBコンパイラを実行して、必要なIIOPスタブを生成します。以下に示すように、IIOPスタブの生成に-iiopオプションを使用する必要はありません。

$ java weblogic.rmic nameOfImplementationClass

スタブはリモート・オブジェクト用のクライアント側プロキシで、個々のWebLogic RMI呼出しを対応するサーバー側スケルトンに転送します。続いてサーバー側スケルトンが、その呼出しを実際のリモート・オブジェクト実装に転送します。なお、WebLogic RMIコンパイラで作成されるIIOPスタブは、JDKのORBで使用するためのものです。他のORBを使用する場合、それぞれのORBベンダーのドキュメントを参照して、これらのスタブが適切かどうかを判断してください。

5. ここまでで作成したファイル、すなわち、リモート・インタフェース、それを実装するクラス、およびスタブをWebLogic ServerのCLASSPATHに指定します。

6. 初期コンテキストを取得します。
RMIクライアントでは、初期コンテキストを作成しリモート・オブジェクトをルックアップして(次のステップを参照)、そのオブジェクトにアクセスします。続いて、このオブジェクトが適切な型にキャストされます。

初期コンテキストの取得では、JNDIコンテキスト・ファクトリを定義する際にcom.sun.jndi.cosnaming.CNCtxFactoryを使用する必要があります。新しいInitialContext()にパラメータとして渡すContext.INITIAL_CONTEXT_FACTORYプロパティの値を設定する際には、com.sun.jndi.cosnaming.CNCtxFactoryを使用します。

注意:

Sun JNDIクライアントでは、ネームスペースからリモート・オブジェクト参照を読み込む機能はサポートされていますが、シリアライズされた汎用Javaオブジェクトの読込みはサポートされていません。つまり、ネームスペースからEJBHomeなどを読み込むことはできますが、DataSourceオブジェクトを読み込むことはできません。この構成では、クライアントで開始されたトランザクション(JTA API)もサポートされません。また、セキュリティもサポートされていません。次のステートレス・セッションBeanのRMIクライアントのサンプルでは、以下のコードで初期コンテキストを取得します。

例8-1 InitialContextの取得

.
.
.
* Using a Properties object as follows will work on JDK13
* and higher clients.
*/
private Context getInitialContext() throws NamingException {
try {
// Get an InitialContext
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.cosnaming.CNCtxFactory");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
} catch (NamingException ne) {
log("We were unable to get a connection to the WebLogic server at   "+url);
log("Please make sure that the server is running.");
throw ne;
}
/**
* This is another option, using the Java2 version to get an * InitialContext.
* This version relies on the existence of a jndi.properties file in
* the application's classpath. See
* "Programming JNDI for Oracle WebLogic Server" for more information
private static Context getInitialContext()
throws NamingException
{
return new InitialContext();
}
.
.
.

7. javax.rmi.PortableRemoteObject.narrow()メソッドと組み合せてルックアップを実行するように、クライアントのコードを修正します。
RMI-IIOPクライアントが通常のRMIクライアントと異なるのは、クライアントが初期コンテキストを取得する際にプロトコルとしてIIOPが定義されるという点です。このため、ルックアップとキャストは、javax.rmi.PortableRemoteObject.narrow()メソッドと組み合せて行われます。

たとえばRMIクライアントは、初期コンテキストを作成し、EJBeanホームをルックアップしてEJBeanへの参照を取得し、EJBean上でメソッドを呼び出します。

通常ならオブジェクトを特定のクラス型へキャストするような状況ではすべて、javax.rmi.PortableRemoteObject.narrow()メソッドを使用する必要があります。CORBAクライアントからは、リモート・インタフェースを実装しないオブジェクトが返されることがあります。そのため、リモート・インタフェースを実装するようオブジェクトを変換するためにORBからnarrowメソッドが提供されます。たとえば、EJBeanホームをルックアップして、その結果をHomeオブジェクトにキャストするクライアント・コードは、以下に示すように、javax.rmi.PortableRemoteObject.narrow()を使用するように修正する必要があります。

例8-2 ルックアップの実行

.
.
.
/**
* RMI/IIOP clients should use this narrow function
*/
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref, c);
}
/**
* Lookup the EJBs home in the JNDI tree
*/
private TraderHome lookupHome()
throws NamingException
{
// Lookup the beans home using JNDI
Context ctx = getInitialContext();
try {
Object home = ctx.lookup(JNDI_NAME);
return (TraderHome) narrow(home, TraderHome.class);
} catch (NamingException ne) {
log("The client was unable to lookup the EJBHome. Please
make sure ");
log("that you have deployed the ejb with the JNDI name
"+JNDI_NAME+" on the WebLogic server at "+url);
throw ne;
}
}
/**
* Using a Properties object will work on JDK130
* and higher clients
*/
private Context getInitialContext() throws NamingException {
try {
// Get an InitialContext
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.cosnaming.CNCtxFactory");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
} catch (NamingException ne) {
log("We were unable to get a connection to the WebLogic
server at "+url);
log("Please make sure that the server is running.");
throw ne;
}
}
.
.
.

urlでは、プロトコル、ホスト名、WebLogic Server用のリスニング・ポートを定義し、それらがコマンド・ライン引数として渡されます。

public static void main(String[] args) throws Exception {
log("\nBeginning statelessSession.Client...\n");
String url = "iiop://localhost:7001";

8. 次のようなコマンドでクライアントを実行することで、IIOPを通じてクライアントをサーバーに接続します。

$ java -Djava.security.manager -Djava.security.policy=java.policy examples.iiop.ejb.stateless.rmiclient.Client iiop://localhost:7001

9. 以下のようにして、クライアント側にセキュリティ・マネージャを設定します。

java -Djava.security.manager -Djava.security.policy==java.policy myclient

クライアント側のRMIインタフェースをナロー変換するには、サーバーからそのインタフェースに適したスタブが提供される必要があります。このクラスのロードは、JDKネットワーク・クラスローダーの使用を前提としており、デフォルトでは有効になっていません。これを有効にするには、適切なJavaポリシー・ファイルを使用して、クライアントにセキュリティ・マネージャを設定します。Java SEセキュリティの詳細は、Oracle Technology Networkのhttp://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.htmlを参照してください。java.policyファイルのサンプルを以下に示します。

grant {
// Allow everything for now
permission java.security.AllPermission;
}

9 WLS-IIOPクライアントの開発

この章では、WebLogic Server-IIOPクライアントを開発および使用する方法について説明します。WLS-IIOPクライアントは、WebLogic Server固有の機能を提供する、ORBベースでないJS2Eクライアントです。

- WLS-IIOPクライアントの機能

- WLS-IIOPクライアントの開発方法

WLS-IIOPクライアントの機能

WLS-IIOPクライアントでは、以下のようなWebLogic Server固有の機能がサポートされます。

- クラスタリング

- SSL

- スケーラビリティ

注意:

WebLogic Server-IIOPクライアントはJava Authentication and Authorization Service (JAAS)をサポートしていません。JNDI認証を使用してください(「JNDI認証を使用するクライアントの開発」を参照)。

詳細は、「クライアントと機能」を参照してください。

WLS-IIOPクライアントの開発方法

WLS-IIOPクライアントの開発手順は、次の追加手順以外は「Java SEクライアントの開発」で説明した手順と同じです。

- 完全wlfullclient.jar (WL_HOME/server/libに存在)をクライアントのCLASSPATHに指定します。

- JNDIコンテキスト・ファクトリを定義する際にweblogic.jndi.WLInitialContextFactoryを使用します。新しいInitialContext()にパラメータとして渡す「Context.INITIAL_CONTEXT_FACTORY」プロパティの値を設定する際には、このクラスを使用します。

- クライアントの起動時に-D weblogic.system.iiop.enableClient=trueコマンド・ライン・オプションを使用して、クライアント・アクセスを有効にする必要はありません。wlfullclient.jarを使用する場合、enableClientはデフォルトでtrueに設定されています。

10 CORBA/IDLクライアントの開発

この章では、様々な分散アプリケーションで使用するクライアントの開発方法について説明します。CORBA/IDLクライアントを使用したRMI over IIOP (CORBA/IDLクライアント使用型RMI over IIOP)には、ORB (Object Request Broker)と共に、IDLと呼ばれる相互運用のための言語を作成するコンパイラが必要になります。ORBでIDLにコンパイル可能な言語の例としては、C、C++、COBOLなどがあります。CORBAのプログラマは、CORBAインタフェース定義言語(Interface Definition Language : IDL)のインタフェースを使用して、CORBAオブジェクトの定義、実装、およびJavaプログラミング言語からのアクセスが可能です。

- CORBA/IDLクライアント開発のガイドライン

- CORBA/IDLクライアントの開発手順

CORBA/IDLクライアント開発のガイドライン

CORBA/IDLクライアント使用型RMI-IIOPを用いると、Java以外のクライアントとJavaオブジェクトとを相互運用できます。CORBAアプリケーションが既に存在する場合には、CORBA/IDLクライアント使用型RMI-IIOPモデルでプログラムを作成する必要があります。基本的に、IDLインタフェースはJavaから生成します。クライアント・コードとWebLogic Serverとの通信は、これらのIDLインタフェースを介して行われます。これが基本的なCORBAプログラミングです。

以下の節では、CORBA/IDLクライアント使用型RMI-IIOPアプリケーションを開発するためのガイドラインを示します。

詳細については、Object Management Group (OMG)による以下の仕様を参照してください。

- Java-to-IDL言語マッピング仕様(http://www.omg.org/cgi-bin/doc?formal/01-06-07)

- CORBA/IIOP 2.4.2仕様(http://www.omg.org/cgi-bin/doc?formal/01-02-33)

CORBA/IDLクライアントの作業

CORBAでは、リモート・オブジェクトへのインタフェースは、プラットフォームに依存しないインタフェース定義言語(IDL)で記述されます。IDLを特定の言語にマップするには、IDLコンパイラでIDLをコンパイルします。IDLコンパイラによって、スタブやスケルトンといった多くのクラスが生成されます。これらのクラスは、クライアントやサーバーで、リモート・オブジェクトへの参照の取得、リクエストの転送、および受信した呼出しのマーシャリングに使用されます。IDLクライアントを使用する場合でも、以降の各節で示すように、まずJavaリモート・インタフェースおよび実装クラスの作成からプログラミングを始めて、その後でIDLを生成し、WebLogicクライアントおよびCORBAクライアントとの相互運用性を実現することを強くお薦めします。IDLでコードを記述した後で、その逆マッピングによってJavaコードを作成することもできますが、その方法は難しく、バグも多数発生するのでお薦めしません。

IDLクライアント(CORBAオブジェクト)の関係

Java-to-IDLマッピング

WebLogic RMIでは、リモート・オブジェクトへのインタフェースは、java.rmi.Remoteを拡張したJavaリモート・インタフェースに記述されます。Java-to-IDLマッピング仕様では、IDLがJavaリモート・インタフェースからどのように作成されるのかを定義しています。WebLogic RMI over IIOP実装では、-idlオプションを付けてWebLogic RMIコンパイラまたはWebLogic EJBコンパイラで実装クラスを実行します。このプロセスによって、リモート・インタフェースのIDL相当部分が作成されます。その後、このIDLをIDLコンパイラでコンパイルして、CORBAクライアントに必要なクラスを生成します。

クライアントは、リモート・オブジェクトへの参照を取得し、スタブを介してメソッド呼出しを転送します。WebLogic Serverには、着信したIIOPリクエストを解析しRMI実行時環境に直接ディスパッチするCosNamingサービスが実装されています。

WebLogic RMI over IIOPオブジェクトの関係

Objects-by-Value

Objects-by-Value仕様により、2つのプログラミング言語間で複合データ型をやり取りできるようになります。IDLクライアントでObjects-by-Valueをサポートするには、Objects-by-ValueをサポートするORB (Object Request Broker)と組み合せてそのクライアントを開発する必要があります。現在のところ、Objects-by-Valueを正確にサポートしているORBは比較的少数です。

IDLを使用するRMI over IIOPアプリケーションを開発する際には、IDLクライアントでObjects-by-Valueをサポートするかどうかを検討し、それに応じてRMIインタフェースを設計します。クライアントORBでObjects-by-Valueがサポートされない場合、RMIインタフェースを制限して、他のインタフェースかCORBAプリミティブ・データ型のみを渡すようにする必要があります。Objects-by-Valueのサポート状況に関してOracleで検証したORBとその結果を以下の一覧表に示します。

表10-1 Objects-by-ValueサポートについてテストされたORB

ベンダー

バージョン

Objects-by-Value

Oracle

Tuxedo 8.x C++クライアントORB

サポートされます

Borland

VisiBroker 3.3、3.4

サポートされません

Borland

VisiBroker 4.x、5.x

サポートされます

Iona

Orbix 2000

サポートされます(Oracleは、この実装での問題をいくつか発見しました)

Objects-by-Valueの詳細は、Oracle WebLogic Server RMIアプリケーションの開発のオブジェクトの値渡しの制限に関する項を参照してください。

CORBA/IDLクライアントの開発手順

CORBA/IDLを使用したRMI over IIOPアプリケーションを開発するには:

1. 第8章「Java SEクライアントの開発」のステップ1 - 3を実行します。

2. -idlオプションを使用してWebLogic RMIコンパイラまたはWebLogic EJBコンパイラを実行し、IDLファイルを生成します。
IDLファイルをコンパイルすると、必要なスタブ・クラスが生成されます。これらのコンパイラについては、Oracle WebLogic Server RMIアプリケーションの開発およびWebLogic RMIの理解に関する項を参照してください。また、Java Language Mapping to OMG IDL Specification(http://www.omg.org/technology/documents/formal/java_language_mapping_to_omg_idl.htm)のJava IDL仕様も参照してください。

以下のコンパイラ・オプションは、RMI over IIOPに固有のものです。

表10-2 RMI-IIOPコンパイラ・オプション

オプション

機能

-idl

コンパイルされている実装クラスのリモート・インタフェース用のIDLを作成します。

-idlDirectory

生成されたIDLの保存先ディレクトリを指定します。

-idlFactories

値タイプのファクトリ・メソッドを生成します。クライアントORBでファクトリの値タイプがサポートされていない場合に役立ちます。

-idlNoValueTypes

値タイプに応じたIDLが生成されないようにします。

-idlOverwrite

同名のIDLファイルが存在する場合には、コンパイラにより上書きされます。

-idlStrict

Objects-By-Value仕様に厳密に準拠したIDLを生成します(appcでは使用できません)。

-idlVerbose

IDL生成についての詳細な情報を表示します。

-idlVisibroker

VisiBroker 4.1 C++とある程度の互換性があるIDLを生成します。

オプションの適用例を、次のRMIコンパイラの実行例で示します。

> java weblogic.rmic -idl -idlDirectory /IDL rmi_iiop.HelloImpl

このコンパイラでは、実装クラスのパッケージに従って、IDLファイルを、idlDirectoyのサブディレクトリ内に生成します。たとえば、上記のコマンドの場合には、Hello.idlファイルが/IDL/rmi_iiopディレクトリに生成されます。idlDirectoryオプションが使用されない場合には、IDLファイルは、スタブ・クラスやスケルトン・クラスの生成先からの相対パスに生成されます。

3. IDLファイルをコンパイルして、IDLクライアントでリモート・クラスと通信するのに必要なスタブ・クラスを作成します。IDLコンパイラはORBベンダーにより提供されています。

4. WebLogicコンパイラで生成されたIDLファイルには、#include orb.idlディレクティブが含まれています。このIDLファイルは各ORBベンダーから提供されます。orb.idlファイルは、WebLogic配布キットの\libディレクトリにあります。このファイルは、JDKに含まれているORBで使用するためのみに用意されているものです。

5. IDLクライアントを開発します。
IDLクライアントは、純粋なCORBAクライアントで、WebLogicクラスはまったく必要としません。ORBベンダーによっては、リモート・クラスへの参照を解決し、ナロー変換して、取得するためのクラス群が生成されることもあります。以下のVisiBroker 4.1 ORB向けに開発されたクライアントの例では、クライアントでネーミング・コンテキストが初期化され、リモート・オブジェクトへの参照が取得されて、そのリモート・オブジェクトに対するメソッドが呼び出されます。

RMI-IIOPサンプルのC++クライアントからの抜粋コード

// string to object
CORBA::Object_ptr o;
cout << "Getting name service reference" << endl;
if (argc >= 2 && strncmp (argv[1], "IOR", 3) == 0)
o = orb->string_to_object(argv[1]);
else
o = orb->resolve_initial_references("NameService");
// obtain a naming context
cout << "Narrowing to a naming context" << endl;
CosNaming::NamingContext_var context = CosNaming::NamingContext::_narrow(o);
CosNaming::Name name;
name.length(1);
name[0].id = CORBA::string_dup("Pinger_iiop");
name[0].kind = CORBA::string_dup("");
// resolve and narrow to RMI object
cout << "Resolving the naming context" << endl;
CORBA::Object_var object = context->resolve(name);
cout << "Narrowing to the Ping Server" << endl;
::examples::iiop::rmi::server::wls::Pinger_var ping =
::examples::iiop::rmi::server::wls::Pinger::_narrow(object);
// ping it
cout << "Ping (local) ..." << endl;
ping->ping();
}

ネーミング・コンテキストを取得する前に、標準のオブジェクトURL (CORBA/IIOP 2.4.2仕様の13.6.7節を参照)を使用して初期参照が解決されている点に注意します。サーバーでのルックアップが、COSネーミング・サービスAPIを実装するJNDIのラッパーによって解決されています。

このネーミング・サービスにより、WebLogic Serverアプリケーションで論理名を使ってオブジェクト参照が公開できるようになっています。CORBAネーム・サービスから提供されるものは以下のとおりです。

- Object Management Group (OMG)のInteroperable Name Service (INS)仕様の実装

- オブジェクト参照を階層型ネーミング構造(この場合はJNDI)にマップするためのアプリケーション・プログラミング・インタフェース(API)

- バインドを表示したり、ネーミング・コンテキスト・オブジェクトやアプリケーション・オブジェクトをネームスペースにバインドまたはアンバインドしたりするためのコマンド

6. IDLクライアント・アプリケーションでは、WebLogic ServerのJNDIツリー内の名前をルックアップするようにCORBAネーミング・サービスに依頼することで、オブジェクトを見つけられます。上記の例では、以下のコマンドを使ってクライアントを実行します。

Client.exe -ORBInitRef NameService=iioploc://localhost:7001/NameService

11 CORBAオブジェクトを使用するクライアントの開発

この章では、CORBAオブジェクトを使用してクライアントを開発するためのCORBA APIの使い方について説明します。

- CORBAオブジェクト・タイプの拡張と制限事項

- 発信CORBA呼出しの実行:主な手順

- JNDIでホストされるWebLogic ORBの使用

- 着信CORBA呼出しのサポート

CORBAオブジェクト・タイプの拡張と制限事項

RMI-IIOPランタイムが拡張され、すべてのCORBAオブジェクト・タイプ(RMI値タイプではなく)とCORBAスタブがサポートされるようになりました。拡張された点は次のとおりです。

- outおよびin-outパラメータをサポートします

- トランザクションおよびセキュリティを使用したWebLogic ServerからCORBAサービスへの呼出しのサポート

- 旧リリースで使用されていたJDK ORBのインスタンスではなく、JNDIでホストされるWebLogic ORBのサポート

CORBAオブジェクト・タイプのサポートには以下の制限があります。

- WebLogic Serverインスタンスから別のWebLogic Serverインスタンスへの呼出しには使用できません。

- クラスタリングはサポートされません。クラスタリングされたオブジェクト参照が検出されると、WebLogic Serverでは内部RMI-IIOPサポートによって呼出しが行われます。outおよびin-outパラメータはサポートされません。

- ORB.connect()によって作成されたCORBAサービスは、サーバー内でホストされる別のオブジェクトとなります。オブジェクトが不要になった場合、ORB.disconnect()を使用して削除する必要があります。

発信CORBA呼出しの実行:主な手順

次に、発信呼出し用にCORBA APIを使用する顧客向けに、典型的な開発モデルを実装する手順を示します。

1. JDKのIDLコンパイラであるidljを使用して、IDLからCORBAスタブを生成します。

2. javacを使用してスタブをコンパイルします。

3. jar内の生成済みスタブを含むEJBをビルドします。

4. JNDIでホストされるWebLogic ORBを使用して、外部サービスを参照します。

JNDIでホストされるWebLogic ORBの使用

この節では、WebLogic ORBにアクセスするいくつかのメカニズムの例を示します。これらのメカニズムは同じ効果を持つので、ある程度はそれらの構成要素を組合せられます。narrow()で返されるオブジェクトは、外部ORBサービスを表すCORBAスタブであり、通常のCORBA参照で呼び出せます。以下の各サンプル・コードでは、CORBAインタフェースがMySvcで、サービスはexthost:extportにある外部ORBのCosNamingサービスの「where」でホストされるものとします。

JNDIからORB

次の例は、JNDIからWebLogic ORBにアクセスする方法を示しています。

例11-1 JNDIからWebLogic ORBへのアクセス

.
.
.
ORB orb = (ORB)new InitialContext().lookup("java:comp/ORB");
NamingContext nc = NamingContextHelper.narrow(orb.string_to_object("corbaloc:iiop:exthost:extport/NameService"));
MySvc svc = MySvcHelper.narrow( nc.resolve(new NameComponent[] { new NameComponent("where", "")}));
.
.
.

ORBの直接作成

次の例は、WebLogic ORBの作成方法を示しています。

例11-2 ORBの直接作成

.
.
.
ORB orb = ORB.init();
MySvc svc = MySvcHelper.narrow(orb.string_to_object("corbaname:iiop:exthost:extport#where"));
.
.
.

JNDIの使用

次の例は、JNDIを使用してWebLogic ORBにアクセスする方法を示しています。

例11-3 JNDIを使用したWebLogic ORBへのアクセス

.
.
.
MySvc svc = MySvcHelper.narrow(new InitialContext().lookup("corbaname:iiop:exthost:extport#where"));
.
.
.

WebLogic ORBでは、DII (Dynamic Invocation Interface)を始めとするほとんどのクライアントORB機能がサポートされます。このサポートを利用するには、外部ORBをサーバー内でインスタンス化しないようにする必要があります。インスタンス化すると、WebLogic ORBによる統合メリットを活かせなくなります。

着信CORBA呼出しのサポート

WebLogic Serverでは、サーバー内でORBをホストする以外の方法として、基本的な着信CORBA呼出しもサポートされています。この方法では、CORBAインタフェースを実装するRMIオブジェクトを記述し、ORB.connect()を使用してCORBAサーバーがWebLogic Server内部にパブリッシュされるようにします。上記のMySVCサンプルの場合、次のようになります。

例11-4 着信CORBA呼出しのサポート

.
.
.
class MySvcImpl implements MvSvcOperations, Remote
{
public void do_something_remote() {}

public static main() {
MySvc svc = new MySvcTie(this);
InitialContext ic = new InitialContext();
((ORB)ic.lookup("java:comp/ORB")).connect(svc);
ic.bind("where", svc);
}
}
.
.
.

起動クラスとして登録すると、CORBAサービスを「where」に指定されたWebLogic ServerのCosNamingサービスで使用できるようになります。

12 Tuxedo ORBを使用するWebLogic C++クライアントの開発

この章では、WebLogic C++クライアントは、Tuxedo 8.1以降のC++クライアントORBを使用して、WebLogic Serverで実行しているEJBに対してIIOPリクエストを生成する方法について説明します。このクライアントでは、object-by-valueおよびCORBA Interoperable Naming Service (INS)がサポートされます。以下の節では、Tuxedo ORBを使用するWebLogic C++クライアントの開発について説明します。

- WebLogic C++クライアントの利点と制限事項

- WebLogic C++クライアントの動作について

- WebLogic C++クライアントの開発

WebLogic C++クライアントの利点と制限事項

WebLogic C++クライアントを使用する利点は以下のとおりです。

- サード・パーティ製品を使用せずに開発プロセスを簡略化できる

- 既存のC++クライアントを開発または修正するためのクライアント側ソリューションを提供できる

- Tuxedo C++クライアントORBはTuxedo 8.1以降にパッケージ化されています。

WebLogic C++クライアントには、次のような制限があります。

- WebLogic Server Securityサービスを使用してセキュリティを提供します。

- サーバー側のトランザクション境界設定のみを提供します。

WebLogic C++クライアントはどのように動作するか

WebLogic C++クライアントでは、リクエストが次のように処理されます。

- WebLogic C++クライアント・コードでWebLogic Serverサービスをリクエストします。

- Tuxedo ORBでIIOPリクエストを生成します。

- 最初にORBオブジェクトがインスタンス化され、Object-by-Valueデータ型がサポートされます。

クライアントでは、CORBA Interoperable Name Service (INS)を使用して、JNDIネーミング・サービスにバインドされているEJBオブジェクトをルックアップします。Interoperable Naming Serviceを使用してNameServiceなどの初期オブジェクトへのオブジェクト参照を取得する方法の詳細は、Oracle Tuxedo 8.0のCORBAプログラミング・リファレンス(http://www.oracle.com/technology/documentation/bea_tuxedo.html)のInteroperable Naming Serviceブートストラップ処理メカニズムに関する項を参照してください。

例12-1 WebLogic C++クライアントとWebLogic Serverの相互運用性

WebLogic C++クライアントの開発

C++クライアントを開発するには、次の手順に従います。

1. C++クライアントと相互運用するEJBを、ejbcコンパイラで-idlオプションを指定してコンパイルします。これにより、EJBのIDLスクリプトが生成されます。

2. C++ IDLコンパイラを使用してIDLスクリプトをコンパイルし、CORBAクライアント・スタブ、サーバー・スケルトンおよびヘッダー・ファイルを生成します。C++ IDLコンパイラの使用方法については、Oracle Tuxedo 8.0の『CORBAプログラミング・リファレンス』(http://www.oracle.com/technology/documentation/bea_tuxedo.html)のOMG IDL構文とC++ IDLコンパイラに関する項を参照してください。

3. EJBでサーバー側実装を表現したら、サーバー・スケルトンを破棄します。

4. EJBをCORBAオブジェクトとして実装するC++クライアントを作成します。CORBAクライアント・アプリケーションの作成方法に関する一般情報は、Oracle Tuxedo 8.0の『CORBAクライアント・アプリケーションの作成』(http://www.oracle.com/technology/documentation/bea_tuxedo.html)を参照してください。

5. Tuxedoのbuildobjclientコマンドを使用してクライアントをビルドします。

13 Java EEクライアント・アプリケーション・モジュールの使用

この章では、Java EEはクライアント・アプリケーション・コード(クライアント・モジュール)の標準をEARファイルで指定する方法について説明します。これにより、アプリケーションのクライアント側を他のモジュールとともにパッケージ化したアプリケーションを作成できます。

クライアント・モジュールは、EARのMETA-INF/application.xmlファイルで<javaタグを使用して宣言します。『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

注意:

<java>タグを、サーバー側モジュールで使用できるJavaコードの宣言と混同しないよう注意してください。これは、その目的ではなく、サーバー側コンテナの外で実行するクライアント側コードを宣言する目的で使用します。

クライアント・モジュールは、基本的にはMETA-INF/application-client.xmlという特別なデプロイメント記述子を含むJARファイルです。このクライアントJARファイルのMETA-INF/MANIFEST.MFファイルには、プログラムのエントリ・ポイントを指定するMain-Classエントリも含まれます。application-client.xmlファイルの詳細は、付録A「クライアント・アプリケーションのデプロイメント記述子の要素」を参照してください。

次の項では、クライアント・アプリケーション・モジュールの使用について説明します。

- クライアント・アプリケーションの展開

- クライアント・アプリケーションの実行

クライアント・アプリケーションの展開

WebLogic Serverは、クライアント・モジュールの使用を容易にするためのユーティリティを備えています。このようなユーティリティには以下の2つがあります。

- weblogic.ClientDeployer - EARからクライアント・モジュールを展開し、これを実行するための準備を行います。

- weblogic.j2eeclient.Main - クライアント・コードを実行します。

Java EE EARファイルからクライアント側JARファイルを展開して、デプロイ可能なJARファイルを作成するには、weblogic.ClientDeployerユーティリティを使用します。weblogic.ClientDeployerクラスは、Javaコマンド・ラインで次の構文を使用して実行します。

java weblogic.ClientDeployer ear-file client1 [client2 client3 ...]

ear-file引数は、拡張子.earを持つJavaアーカイブ・ファイルか、1つまたは複数のクライアント・アプリケーションJARファイルが格納されている展開されたディレクトリです。

client引数には、展開するクライアントを指定します。weblogic.ClientDeployerユーティリティは、ここに指定したクライアントごとに、指定した名前のJARファイル(拡張子.jarを含む)をEARファイル内から検索します。

次に、コマンドの例を示します。

java weblogic.ClientDeployer app.ear myclient

このコマンドでは、app.earからmyclient.jarが展開されます。weblogic.ClientDeployerユーティリティでは、展開時に他の2つの操作も実行されます。

- JARファイルにMETA-INF/application-client.xmlファイルが含まれていることを確認します。含まれていない場合は例外がスローされます。

- myclient.runtime.xmlというファイルから読取りを行い、展開されたJARファイル内にweblogic-application-client.xmlファイルを作成します。このファイルは、weblogic.j2eeclient.Mainユーティリティで、クライアント・アプリケーションのコンポーネント環境(java:comp/env)を初期化するために使用します。runtime.xmlファイルの形式の詳細は、「クライアント・アプリケーションのデプロイメント記述子の要素」を参照してください。

注意:

モジュールのMETA-INF/application-client.xmlデプロイメント記述子のエントリのバインディングを定義するには、クライアント・プログラムの<client>.runtime.xml記述子を作成します。

クライアント・アプリケーションの実行

EARファイルからクライアント側のJARファイルを展開したら、weblogic.j2eeclient.Mainユーティリティを使用してクライアント側アプリケーションをブート・ストラップし、次のコマンドを使用してWebLogic Serverインスタンスを指すようにします。

java weblogic.j2eeclient.Main clientjar URL [application args]

例:

java weblogic.j2eeclient.Main myclient.jar t3://localhost:7001

weblogic.j2eeclient.Mainユーティリティによって、クライアント・コード内のjava:comp/envからアクセス可能なコンポーネント環境が作成されます。

application-client.xml記述子に記述されているリソースが以下のいずれかに該当する場合、あらかじめmyclient.runtime.xmlファイルに指定された情報に基づいて、weblogic.j2eeclient.MainクラスはサーバーのグローバルJNDIツリーからjava:comp/envへのバインドが試行されます。

- ejb-ref

- javax.jms.QueueConnectionFactory

- javax.jms.TopicConnectionFactory

- javax.mail.Session

- javax.sql.DataSource

ユーザー・トランザクションは、java:comp/UserTransactionにバインドされます。

application.xmlデプロイメント記述子の<res-auth>タグは、現時点では無視され、applicationと入力されます。現時点では、フォームベースの認証はサポートされていません。

残りのクライアント環境は、weblogic.ClientDeployerユーティリティによって作成されたweblogic-application-client.xmlファイルからバインドされます。

バインディングが見つからない場合や不完全な場合は、weblogic.j2eeclient.Mainクラスからエラー・メッセージが出力されます。

環境が初期化されると、weblogic.j2eeclient.MainユーティリティがMain-ClassエントリのJARクライアントのJARマニフェストを検索します。このクラスのmainメソッドを呼び出すと、クライアント・プログラムが起動します。URL引数の後ろでweblogic.j2eeclient.Mainユーティリティに渡したすべての引数は、クライアント・アプリケーションに渡されます。

アプリケーション用に作成したJavaクラス、およびそのアプリケーションが依存するすべてのJavaクラス(WebLogic Serverクラスを含む)は、クライアントJVMから使用できるようにしておく必要があります。クライアント・アプリケーションをステージするには、クライアントで必要とするすべてのファイルを特定のディレクトリにコピーし、そのディレクトリをJARファイルにバンドルします。クライアント・アプリケーション・ディレクトリの最上位には、アプリケーションを起動するためのバッチ・ファイルやスクリプトを格納できます。JavaクラスとJARファイルを保持するクラスまたはサブディレクトリを作成し、起動スクリプトのクライアントクラスパスに追加します。

Javaクライアント・アプリケーションにJRE (Java Runtime Environment)をパッケージ化することもできます。

注意:

クライアント・モジュールJARで使用するクラスパス・マニフェスト・エントリは移植できません。これは、Java EE標準で未対応であるためです。

14 セキュリティ対応クライアントの開発

この章では、JAAS (Java Authentication and Authorization Service)およびSecure Sockets Layer (SSL)を使用するWebLogicクライアントを開発する方法について説明します。

- JAASを使用するクライアントの開発

- JNDI認証を使用するクライアントの開発

- SSLを使用するクライアントの開発

- シン・クライアントでJAASおよびSSLを使用する際の制約

- セキュリティのサンプル・コード

JAASを使用するクライアントの開発

JAASでは、ユーザーIDに基づくアクセス制御機能が提供されます。ほとんどのWebLogic Serverクライアントの認証方法として推奨される手法です。一般には、ファイルの読取りや書込みの認証方法として使用します。JAAS認証を実装する方法の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaクライアントのJAAS認証の使用に関する項を参照してください。

注意:

WLS-IIOPクライアントはJAASをサポートしていません。「JNDI認証を使用するクライアントの開発」を参照してください。

JNDI認証を使用するクライアントの開発

クライアント証明書認証(双方向SSL認証ともいう)が必要なユーザーは、JNDI認証を使用してください(『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJNDI認証の使用に関する項を参照)。

SSLを使用するクライアントの開発

WebLogic Serverは、WebLogic Serverクライアントとサーバー、Javaクライアント、Webブラウザ、および他のサーバーの間で転送されるデータを暗号化するためにSecure Sockets Layer (SSL)をサポートしています。

すべてのSSLクライアントに、信頼を指定する必要があります。信頼とは、どの信頼性のある認証局がクライアントから信頼されるのかを指定するCA証明書の集合です。SSL接続を確立するためには、RMIクライアントでサーバーのデジタル証明書を発行した認証局を信頼する必要があります。サーバーの信頼性のあるCA証明書の場所は、RMIクライアントを起動する際に指定します。

デフォルトでは、JDK(...\jre\lib\security\cacerts)から利用できるすべての信頼性のある認証局がRMIクライアントから信頼されます。ただし、サーバーの信頼性のあるCA証明書が、次のいずれかの信頼キーストアに格納されている場合は、そのキーストアを使用するために特定のコマンド・ライン引数を指定する必要があります。

- デモ信頼 - デモ用信頼キーストア(DemoTrust.jks)の信頼性のあるCA証明書は、WL_HOME\server\libディレクトリに格納されます。JDK cacertsキーストアの信頼性のあるCAも信頼されます。デモ信頼を使用するには、次のコマンド・ライン引数を指定します。

-Dweblogic.security.TrustKeyStore=DemoTrust

必要に応じて、次のコマンド・ライン引数を使用するとJDK cacerts信頼キーストアのパスワードを指定できます。

-Dweblogic.security.JavaStandardTrustKeyStorePassPhrase=password

passwordは、Java標準信頼キーストアのパスワードです。このパスワードは、キーストアを作成するときに定義します。

- カスタム信頼 - 独自に作成した信頼キーストア。カスタム信頼を使用するには、次のコマンド・ライン引数を指定します。
信頼キーストアへの完全修飾パスを指定します。

-Dweblogic.security.CustomTrustKeyStoreFileName=filename

キーストアのタイプを指定します。

-Dweblogic.security.CustomTrustKeyStoreType=jks

必要に応じて、キーストアの作成時に定義されたパスワードを指定します。

-Dweblogic.security.CustomTrustKeyStorePassPhrase=password

- Oracleのkeytoolユーティリティ。このユーティリティを使用すると、秘密鍵、WebLogic Server用の自己署名デジタル証明書、およびCSR (証明書署名リクエスト)を取得できます。Oracleのkeytoolユーティリティの詳細は、http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.htmlのkeytool-Keyおよび証明書管理ツールに関する項を参照してください。オラクル社が提供するチュートリアル(http://docs.oracle.com/cd/E19226-01/820-7627/bnbxx/index.html)のSSLサポートのインストールと構成に関する項を参照してください。このチュートリアルは、「Creating a Client Certificate for Mutual Authentication」節が含まれています。

注意:

keytoolユーティリティを使用する場合、デフォルトのキー・ペア生成アルゴリズムはDSAです。WebLogic Serverでは、DSA (Digital Signature Algorithm)の使用はサポートされていません。WebLogic Serverを使用する場合には、別のキー・ペア生成および署名アルゴリズムを指定します。

SSLの実装方法の詳細は、Oracle WebLogic Serverセキュリティの管理のSSLの構成に関する項およびIDと信頼の構成に関する項を参照してください。

シン・クライアントでJAASおよびSSLを使用する際の制約

WebLogicシン・クライアント・アプリケーションでのJAAS認証は以下の方法でのみサポートされます。

- weblogic.security.auth.login.UsernamePasswordLoginModule.login

- weblogic.security.Security.runAs

WebLogicシン・クライアントでは、双方向SSLのみがサポートされます。双方向SSLには、SECURITY_CREDENTIALSプロパティに指定されているSSLContextが必要です。例として、次のクライアント・コードを参照してください。

例14-1 SSLContextを使用したクライアント・コード

.
.
.
System.out.println("Getting initial context");
Hashtable props = new Hashtable();
props.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
props.put(Context.PROVIDER_URL,"corbaloc:iiops:" + host + ":" + port +"/NameService");

props.put(Context.SECURITY_PRINCIPAL,"weblogic");
props.put(Context.SECURITY_CREDENTIALS, "password");

//Set the ssl properties through system property
//set the path to the keystore file (one key inside the store)
System.setProperty("javax.net.ssl.keyStore", YOUR-KEY_STORE_FILE_PATH);
//set the keystore pass phrase
System.setProperty("javax.net.ssl.keyStorePassword",YOUR_KEY_STORE_PASS_PHRASE);

//Set the trust store
//set the path to the trust store file
System.setProperty("javax.net.ssl.trustStore",YOUR-TRUST_STORE_FILE_PATH);
//set the trust store pass phrase
System.setProperty("javax.net.ssl.trustStorePassword",YOUR_TRUST_STORE_PASS_PHRASE);

Context ctx = new InitialContext(props);
.
.
.

セキュリティのサンプル・コード

WebLogic Server製品には、オプションで、セキュリティのサンプルが用意されています。これらのサンプルは、EXAMPLES_HOME\wl_server\examples\src\examples\securityディレクトリにあります。各サンプルの説明と、サンプルをビルド、構成、実行する方法については、package-summary.htmlファイルを参照してください。これらのサンプル・コードは、変更して再利用できます。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

15 RMI-IIOPクライアントでのEJBの使用

この章では、RMI-IIOPを使用するEnterprise JavaBeansを実装することで、異機種サーバー環境でEJBを相互運用する方法について説明します。

- JavaクライアントによるEJBへのアクセス

- CORBA/IDLクライアントによるEJBへのアクセス

JavaクライアントによるEJBへのアクセス

Java RMIクライアントから、ORBおよびIIOPを使用して、WebLogic Serverインスタンス上のエンタープライズBeanにアクセスできます。『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEnterprise JavaBeansの理解に関する項を参照してください。

CORBA/IDLクライアントによるEJBへのアクセス

Java以外のプラットフォームのCORBA/IDLクライアントから、WebLogic Server上のいかなるエンタープライズBeanオブジェクトにもアクセスできます。この場合、Javaソース・ファイルに定義されているEJBクラスがマッピング情報の源になります。WebLogic Serverには、必要なIDLファイルを生成するためのweblogic.appcユーティリティが用意されています。これらのファイルでは、CORBAビューをターゲットEJBの状態と動作で表します。weblogic.appcユーティリティの用途は以下のとおりです。

- EJBのクラス、インタフェース、およびデプロイメント記述子ファイルをJARファイルに格納します。

- EJB用のWebLogic Serverコンテナ・クラスを生成します。

- RMIコンパイラを使用して各EJBコンテナ・クラスを実行し、スタブとスケルトンを作成します。

- これらのクラスへのCORBAインタフェースを記述するCORBA IDLファイルのディレクトリ・ツリーを生成します。

weblogic.appcユーティリティでは、様々なコマンド修飾子がサポートされています。第10章「CORBA/IDLクライアントの開発」を参照してください。

結果として生成されたファイルはコンパイラで処理されます。コンパイラはその際に、idlSourcesディレクトリからソース・ファイルを読み込み、CORBA C++のスタブ・ファイルとスケルトン・ファイルを生成します。値タイプ以外のすべてのCORBAデータ型には、これらの生成されるファイルで十分です(詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』のWebLogic RMI-IIOPの制約に関する項を参照してください。)生成されたIDLファイルは、idlSourcesディレクトリに配置されます。なお、Java-to-IDLマッピング処理には、注意すべき点が多数あります。http://www.omg.org/technology/documents/formal/java_language_mapping_to_omg_idl.htmの「Java言語のOMG IDLへのマッピング仕様」を参照してください。

詳細は、Enterprise JavaBeansコンポーネントおよびCORBAクライアント: 開発者ガイド(http://docs.oracle.com/javase/7/docs/technotes/guides/rmi-iiop/interop.html)を参照してください。

IDL生成の例

以下の例では、作成済みのBeanからIDLを生成する方法を示します。

1. IDLファイルを生成します。

> java weblogic.appc -compiler javac -keepgenerated -idl -idlDirectory idlSources build\std_ejb_iiop.jar %APPLICATIONS%\ejb_iiop.jar

2. EJBインタフェースとクライアント・アプリケーションをコンパイルします(この例ではCLIENT_CLASSESおよびAPPLICATIONSターゲット変数を使用しています)。

> javac -d %CLIENT_CLASSES% Trader.java TraderHome.java TradeResult.java Client.java

3. ステップ1で生成したIDLファイルに対してIDLコンパイラを実行します。

>%IDL2CPP% idlSources\examples\rmi_iiop\ejb\Trader.idl
. . .

>%IDL2CPP% idlSources\javax\ejb\RemoveException.idl

4. C++クライアントをコンパイルします。

A クライアント・アプリケーションのデプロイメント記述子の要素

この章では、WebLogic ServerでサポートされるJava EEクライアント・アプリケーションのデプロイメント記述子について説明します。

- クライアント・アプリケーションのデプロイメント記述子の要素の概要

- application-client.xmlデプロイメント記述子の要素

- weblogic-appclient.xml記述子の要素

クライアント・アプリケーションのデプロイメント記述子の要素の概要

Java EEアプリケーションの場合、ユーザーの関心は通常、サーバー側モジュール(Webアプリケーション、EJBおよびコネクタ)にあります。サーバー側モジュールの構成には、application.xmlデプロイメント記述子を使用します(『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照)。

しかし、クライアント・モジュール(JARファイル)をEARファイルに含めることもできます。このJARファイルは、クライアント側でのみ使用するもので、このクライアント・モジュールの構成にはapplication-client.xmlデプロイメント記述子を使用します。この方法により、クライアント側とサーバー側、両方のモジュールのパッケージ化が可能になります。サーバーはサーバーが関係する部分(application.xmlファイルに基づく)だけを参照し、クライアントはクライアントが関係する部分(application-client.xmlファイルに基づく)だけを参照します。

クライアント側モジュールには、2つのデプロイメント記述子が必要です。1つはapplication-client.xmlというJava EEの標準デプロイメント記述子、もう1つはクライアント・アプリケーションのJARファイルから派生した名前を持つWebLogic固有の実行時デプロイメント記述子です。

application-client.xmlデプロイメント記述子の要素

application-client.xmlファイルは、Java EEクライアント・アプリケーションのデプロイメント記述子です。以下のDOCTYPE宣言を最初に指定する必要があります。

<!DOCTYPE application-client PUBLIC "-//Sun Microsystems,
Inc.//DTD Java EE Application Client 1.2//EN"
"http://java.sun.com/j2ee/dtds/application-client_1_2.dtd">

以降の節では、ファイル内に表示される各要素について説明します。

application-client

application-clientは、アプリケーション・クライアントのデプロイメント記述子のルート要素です。アプリケーション・クライアントのデプロイメント記述子は、クライアント・アプリケーションで使用するEJBモジュールおよびその他のリソースを記述します。

次の表では、application-client要素内で定義できる要素について説明します。

表A-1 application-client要素

要素

説明

<icon>

オプション。GUIツールでアプリケーションを表す小さい画像および大きい画像の場所。この要素は現在、WebLogic Serverでは使用されていません。

<display-name>

アプリケーションの表示名(GUIツールで表示することを想定した短い名前)。

<description>

オプション。クライアント・アプリケーションの説明。

<env-entry>

クライアント・アプリケーションの環境エントリの宣言が含まれます。

env-entry要素内で定義できる要素は、次のとおりです。

- description: オプション。特定の環境エントリの説明が格納されます。

- env-entry-name: クライアント・アプリケーションの環境エントリの名前が格納されます。

- env-entry-type: 環境エントリの完全修飾Javaタイプが格納されます。指定できる値は、java.lang.Boolean、java.lang.String、java.lang.Integer、java.lang.Double、java.lang.Byte、java.lang.Short、java.lang.Longおよびjava.lang.Floatです。

- env-entry-value: オプション。クライアント・アプリケーションの環境エントリの値が格納されます。値は、指定したenv-entry-typeのコンストラクタで有効な文字列とする必要があります。

<ejb-ref>

クライアント・アプリケーションで参照されるEJBへの参照の宣言に使用されます。

ejb-ref要素内で定義できる要素は、次のとおりです。

- description: オプション。参照されるEJBの説明を提供します。

- ejb-ref-name: 参照されるEJBの名前が格納されます。通常、名前には、ejb/Depositのようにejb/という接頭辞が付きます。

- ejb-ref-type: 参照されるEJBの予期されるタイプ(SessionまたはEntity)が格納されます。

- home - 参照されるEJBのホーム・インタフェースの完全修飾名が格納されます。

- remote - 参照されるEJBのリモート・インタフェースの完全修飾名が格納されます。

- ejb-link: EJB参照がJava EEアプリケーション・パッケージのEnterprise JavaBeansにリンクされるように指定します。ejb-link要素の値は、同じJava EEアプリケーションにおけるEJBのejb-nameの名前と同じであることが必要です。

<resource-ref>

クライアント・アプリケーションの、外部リソースへの参照の宣言が格納されます。

resource-ref要素内で定義できる要素は、次のとおりです。

- description: オプション。参照される外部リソースの説明が格納されます。

- res-ref-name - リソース・ファクトリ参照名を指定します。リソース・ファクトリ参照名は、値にデータ・ソースのJNDI名が含まれるクライアント・アプリケーションの環境エントリの名前。

- res-type - データ・ソースのタイプを指定します。このタイプは、データ・ソースによって実装されると予期されるJavaインタフェースまたはクラスによって指定されます。

- res-auth: EJBコードによってプログラムでリソース・マネージャに対するサインオンを行うか、EJBのかわりにコンテナによってリソース・マネージャに対するサインオンを行うかを指定します。後者の場合、コンテナは、デプロイヤから提供される情報を使用します。res-auth要素には、ApplicationとContainerのいずれかを指定できます。

weblogic-appclient.xml記述子の要素

このXML形式のデプロイメント記述子は、他のデプロイメント記述子とは異なり、クライアント・アプリケーションのJARファイル内には保存されませんが、クライアント・アプリケーションのJARファイルと同じディレクトリに保存する必要があります。

デプロイメント記述子のファイル名は、JARファイルの基本名に.runtime.xmlという拡張子を付けたものです。たとえば、クライアント・アプリケーションがc:\applications\ClientMain.jarというファイルにパッケージングされている場合、実行時デプロイメント記述子はc:\applications\ClientMain.runtime.xmlというファイルにあります。

application-client

application-client要素は、WebLogic固有のクライアント実行時デプロイメント記述子のルート要素です。次の表では、application-client要素内で定義できる要素について説明します。

表A-2 application-client要素

要素

説明

<env-entry>

デプロイメント記述子で宣言される環境エントリの値を指定します。

env-entry要素内で定義できる要素は、次のとおりです。

- env-entry-name: アプリケーション・クライアントの環境エントリの名前。たとえば、<env-entry-name>EmployeeAppDB</env-entry-name>となります。

- env-entry-value: アプリケーション・クライアントの環境エントリの値。値は、単独の文字列パラメータをとる、指定したタイプのコンストラクタで有効な文字列値とする必要があります。

<ejb-ref>

デプロイメント記述子内の宣言されたEJB参照のJNDI名を指定します。

ejb-ref要素内で定義できる要素は、次のとおりです。

- ejb-ref-name: EJB参照の名前。EJB参照は、アプリケーション・クライアントの環境のエントリです。名前の前にejb/を付けてください。たとえば、<ejb-ref-name>ejb/Payroll</ejb-ref-name>となります。

- jndi-name - EJBのJNDI名

<resource-ref>

アプリケーション・クライアントの外部リソースへの参照を宣言します。要素には、リソース・ファクトリの参照名が指定されます。この参照名は、アプリケーション・クライアントのコードで予期されているリソース・ファクトリのタイプ、および認証のタイプ(Beanかコンテナか)を示します。

次に例を示します。

<resource-ref>

<res-ref-name>EmployeeAppDB</res-ref-name>

<jndi-name>enterprise/databases/HR1984</jndi-name>

</resource-ref>

resource-ref要素内で定義できる要素は、次のとおりです。

- res-ref-name - リソース・ファクトリ参照名。リソース・ファクトリ参照名は、値にデータ・ソースのJNDI名が含まれるアプリケーション・クライアントの環境エントリの名前。

- jndi-name - リソースのJNDI名

<resource-description>

サーバー・リソースのJNDI名をWebLogic ServerにおけるEJBリソース参照にマップします。

resource-description要素内で定義できる要素は、次のとおりです。

- res-ref-name: リソース参照名を指定します。

- jndi-name: リソースのJNDI名を指定します。

<resource-env-description>

ejb-jar.xmlデプロイメント記述子で宣言されたresource-env-refを、それが表しているサーバー・リソースのJNDI名にマップします。

resource-env-description要素内で定義できる要素は、次のとおりです。

- res-env-ref-name: リソース環境参照名を指定します。

- jndi-name: リソース環境参照のJNDI名を指定します。

<ejb-reference-description>

ejb-reference-description要素内で定義できる要素は、次のとおりです。

- ejb-ref-name: Webアプリケーションで使用するEJB参照の名前を指定します。

- jndi-name: 参照のJNDI名を指定します。

<service-reference-description>

ejb-reference-description要素内で定義できる要素は、次のとおりです。

- service-ref-name

- wsdl-url

- call-property: call-property要素には次の下位要素があります。

- name

- value

- port-info: port-info要素には次の下位要素があります。

- port-name

- stub-property

- call-property

B WebLogic JarBuilderツールの使用

この章では、WebLogic JarBuilderツールを使用してwlfullclient.jarを作成する方法について説明します。

- JDK 1.7クライアント・アプリケーション用のwlfullclient.jarの作成

- JDK 1.6クライアント・アプリケーション用のwlfullclient.jarの作成

注意:

Antスクリプトで起動される<java>タスクからWebLogicフル・クライアントを実行する場合、wlfullclient.jarマニフェスト・クラスパスに含まれているRSA Crypto-Jライブラリに関する重要な情報は、「非フォーク対象VMでのWebLogicフル・クライアントの実行」を参照してください。

JDK 1.7クライアント・アプリケーション用のwlfullclient.jarの作成

JDK 1.7クライアント・アプリケーションのwlfullclient.jarファイルを作成するには、次の手順に従います。

1. ディレクトリをserver/libに変更します。

cd WL_HOME/server/lib

2. 次のコマンドを使用してserver/libディレクトリにwlfullclient.jarを作成します。

java -jar wljarbuilder.jar

3. wlfullclient.jarをコピーして、クライアント・アプリケーションにcryptoj.jarとともにバンドルできるようになりました。wlfullclient.jarおよびcryptoj.jarはマニフェスト・クラスパスのcryptoj.jarを参照するwlfullcient.jarと同じディレクトリに保持する必要があります。

4. wlfullclient.jarをクライアント・アプリケーションのクラスパスに追加します。

JDK 1.6クライアント・アプリケーション用のwlfullclient.jarの作成

JDK 1.6クライアント・アプリケーションのwlfullclient.jarファイルを作成するには、次の手順に従います。

1. ディレクトリをserver/libに変更します。

cd WL_HOME/server/lib

2. 次のコマンドを使用してserver/libディレクトリにwlfullclient.jarを作成します。

java -jar wljarbuilder.jar

3. wlfullclient.jarをコピーして、クライアント・アプリケーションにcryptoj.jarとともにバンドルできるようになりました。wlfullclient.jarおよびcryptoj.jarはマニフェスト・クラスパスのcryptoj.jarを参照するwlfullcient.jarと同じディレクトリに保持する必要があります。

4. wlfullclient.jarをクライアント・アプリケーションのクラスパスに追加します。

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

コピーライトについて

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

商標と登録商標について

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の登録商標です。

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

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

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

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

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

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

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