Oracle® Fusion Middleware

Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング

11g リリース1 (10.3.6)

B61634-06(原本部品番号:E13735-07)

2015年4月

このドキュメントでは、ソフトウェア開発者を対象に、WebLogic JAX-RPC Webサービスの高度な機能をプログラミングする方法について説明します。

Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング, 11g リリース1 (10.3.6)

B61634-06

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

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

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

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

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

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

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

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

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

目次

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

はじめに

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

- 表記規則

1 概要

2 非同期リクエスト-レスポンスを使用したWebサービスの呼出し

- 非同期リクエスト-レスポンス機能の概要

- 非同期リクエスト-レスポンスの使用: 主な手順

- 非同期WebサービスのホストWebLogic Serverインスタンスの構成

- 非同期のJWSファイルの記述

- Webサービスの非同期な呼出しのコーディングに関するガイドライン

- 非同期の呼出し前および呼出し後におけるコンテキストの使用

- 同期呼出しのサンプル

- 非同期リクエスト-レスポンスを使用する場合のbuild.xmlファイルの更新

- 内部非同期サービスの無効化

- 非同期のリクエスト・レスポンスとプロキシ・サーバーの使用

3 Webサービスの信頼性のあるメッセージングの使用

- Webサービスの信頼性のあるメッセージングの概要

- WS-Policyを使用した信頼性のあるメッセージング・ポリシーのアサーションの指定

- 信頼性のあるメッセージ・シーケンスのライフサイクルの管理

- Webサービスの信頼性のあるメッセージングの使用: 主な手順

- 前提条件

- 宛先WebLogic Serverインスタンスの構成

- ソースWebLogic Serverインスタンスの構成

- Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成

- WS-ReliableMessagingポリシー・アサーション・バージョン1.1を使用したカスタムWS-Policyファイルの作成

- WS-ReliableMessagingポリシー・アサーション・バージョン1.0を使用したカスタムWS-Policyファイルの作成(非推奨)

- 複数のポリシー選択肢の使用

- 信頼性のあるJWSファイルに関するプログラミングのガイドライン

- @Policyアノテーションの使用

- @Onewayアノテーションの使用

- @BufferQueueアノテーションの使用

- @ReliabilityBufferアノテーションの使用

- 信頼性のあるWebサービスの信頼性のあるメッセージングの構成

- 管理コンソールを使用する

- WLSTの使用

- 信頼性のあるWebサービスを呼び出すJWSファイルに関するプログラミングのガイドライン

- 信頼性のあるWebサービスのクライアント用build.xmlファイルの更新

- 信頼性のあるメッセージングとMTOMの使用

- 信頼性のあるWebサービスを再デプロイする際にクライアント側で考慮すべき事項

- 信頼性のあるメッセージングとプロキシ・サーバーの使用

4 会話型Webサービスの作成

- 会話型Webサービスの概要

- 会話型Webサービスの作成: 主な手順

- 会話型JWSファイルに関するプログラミングのガイドライン

- 会話型Webサービスを呼び出すJWSファイルに関するプログラミングのガイドライン

- ConversationUtilsユーティリティ・クラス

- 会話型Webサービスのクライアント用build.xmlファイルの更新

- 会話型Webサービスを呼び出すためのスタンドアロンJavaクライアントの更新

- 会話型Webサービスの.NETクライアントの例

- ConversationService.javaファイル

- Service.csファイル

- build.xmlファイル

- 会話型Webサービスを再デプロイする際にクライアント側で考慮すべき事項

5 バッファ付きWebサービスの作成

- バッファ付きWebサービスの概要

- バッファ付きWebサービスの作成: 主な手順

- バッファ付きWebサービスのホストWebLogic Serverインスタンスの構成

- バッファ付きJWSファイルに関するプログラミングのガイドライン

- バッファ付きWebサービスを呼び出すJWSファイルのプログラミング

- バッファ付きWebサービスのクライアント用build.xmlファイルの更新

6 非同期機能の併用

- 非同期機能の併用

- 信頼性のある会話型Webサービスを実装するJWSファイルの例

- 信頼性のある会話型Webサービスを非同期で呼び出すクライアントWebサービスの例

7 コールバックによるクライアントへのイベントの通知

- コールバックの概要

- コールバックの実装の概要と用語

- コールバックのプログラミング: 主な手順

- ターゲットWebサービスのプログラミングのガイドライン

- コールバック・クライアントWebサービスのプログラミングのガイドライン

- コールバック・インタフェースのプログラミングのガイドライン

- クライアントWebサービスのbuild.xmlファイルの更新

8 接続プロトコルとしてのJMSトランスポートの使用

- JMSトランスポートの使用の概要

- Javaから開始するJMSトランスポートの使用: 主な手順

- WSDLから開始するJMSトランスポートの使用: 主な手順

- JMSトランスポートWebサービスのホストWebLogic Serverインスタンスの構成

- @WLJmsTransport JWSアノテーションの使用

- jwsc Antタスクの<WLJmsTransport>子要素の使用

- JMSトランスポートを使用するためのWSDLの更新

- JMSトランスポートを使用したWebLogic Webサービスの呼出し

- デフォルトのサービス・アドレスURLのオーバーライド

- デフォルトのTextMessageのかわりとしてのJMS BytesMessageの使用

- WSDLファイルへのHTTPアクセスの無効化

9 SOAPメッセージ・ハンドラの作成と使用

- SOAPメッセージ・ハンドラの概要

- SOAPメッセージ・ハンドラのWebサービスへの追加: 主な手順

- SOAPメッセージ・ハンドラおよびハンドラ・チェーンの設計

- GenericHandlerクラスの作成

- Handler.init()メソッドの実装

- Handler.destroy()メソッドの実装

- Handler.getHeaders()メソッドの実装

- Handler.handleRequest()メソッドの実装

- Handler.handleResponse()メソッドの実装

- Handler.handleFault()メソッドの実装

- SAAJを使用したSOAPリクエスト・メッセージおよびレスポンス・メッセージの直接操作

- SOAPPartオブジェクト

- AttachmentPartオブジェクト

- SOAPメッセージ・ハンドラで画像添付ファイルの操作

- JWSファイルでのハンドラの構成

- @javax.jws.HandlerChain

- @javax.jws.soap.SOAPMessageHandlers

- ハンドラ・チェーン構成ファイルの作成

- Webサービスのコンパイルと再ビルド

- クライアント側SOAPメッセージ・ハンドラの作成と使用

- クライアント側SOAPメッセージ・ハンドラの使用: 主な手順

- クライアント側ハンドラ・クラスの例

- クライアント側SOAPハンドラの構成ファイルの作成

- クライアント側ハンドラの構成ファイル用XMLスキーマ

- クライアント側SOAPハンドラの構成ファイルのclientgenへの指定

10 Database Webサービスの使用

- Database Webサービスの概要

- Databaseコールイン

- Databaseコールアウト

- SQLとXMLの間のタイプ・マッピング

- Webサービスのコールインに対するSQLからXMLタイプへのマッピング

- Webサービス・コールアウトに対するXMLからSQLタイプへのマッピング

- Oracle JDeveloperを使用したDatabase Webサービスの開発

11 UDDIを使用したWebサービスのパブリッシュと検索

- UDDIの概要

- UDDIとWebサービス

- UDDIとビジネス・レジストリ

- UDDIのデータ構造

- WebLogic ServerのUDDI機能

- UDDI 2.0サーバー

- UDDI 2.0サーバーの構成

- 外部LDAPサーバーの構成

- 51acumen.ldifファイルの目次

- uddi.propertiesファイルのプロパティの説明

- UDDIディレクトリ・エクスプローラ

- UDDIクライアントAPI

- プラガブルtModel

- XML要素と許容値

- プラガブルtModelのXMLスキーマ

- プラガブルtModelのサンプルXML

A 信頼性のあるメッセージング用にパッケージ化されているWS-Policyファイル

- DefaultReliability1.1.xml (WS-Policyファイル)

- Reliability1.1_SequenceTransportSecurity.xml (WS-Policyファイル)

- Reliability1.1_SequenceSTR.xml (WS-Policyファイル)

- Reliability1.0_1.1.xml (WS-Policy.xmlファイル)

- DefaultReliability.xml (WS-Policyファイル) [非推奨]

- LongRunningReliability.xml (WS-Policyファイル) [非推奨]

はじめに

ここでは、このガイド『Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』で使用されるドキュメント・アクセシビリティ機能および表記規則について説明します。

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

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 概要

この章では、このドキュメントに記載されているWebLogic Java API for XML-based RPC (JAX-RPC) の高度な機能をまとめています。このドキュメントは、JAX-RPCの高度な機能をプログラミングするソフトウェア開発者のための情報源です。

表1-1 JAX-RPCを使用した高度な機能のプログラミング

高度な機能

説明

第2章「非同期リクエスト-レスポンスを使用したWebサービスの呼出し」

Webサービスを非同期的に呼び出します。

第3章「Webサービスの信頼性のあるメッセージングの使用」

WS-ReliableMessaging仕様に準拠して信頼性のあるWebサービスを作成してから、そのWebサービスを呼び出すクライアントWebサービスを作成します。

第4章「会話型Webサービスの作成」

クライアントと通信する会話型Webサービスを作成します。

第6章「非同期機能の併用」

信頼性のあるメッセージング、非同期リクエスト-レスポンス、会話などの非同期機能を単一のWebサービスで一緒に使用します。

第7章「コールバックによるクライアントへのイベントの通知」

コールバックをプログラミングしてイベントの発生をWebサービスのクライアントに通知します。

第5章「バッファ付きWebサービスの作成」

WS-ReliableMessaging仕様に準拠した信頼性のあるWebサービスよりも単純なタイプのバッファ付きWebサービスを作成します。

第8章「接続プロトコルとしてのJMSトランスポートの使用」

Webサービスの呼出し時の接続プロトコルとして、デフォルトのHTTP/SではなくJMSを指定します。

第9章「SOAPメッセージ・ハンドラの作成と使用」

WebサービスのSOAPメッセージ・ハンドラを作成および構成します。

第10章「Database Webサービスの使用」

JDeveloperを使用してDatabase Webサービスを作成します。

第11章「UDDIを使用したWebサービスのパブリッシュと検索」

WebLogic WebサービスのUDDI機能を使用します。

WebLogic Webサービスの概要、規格、サンプル、および関連ドキュメントについては、『Oracle WebLogic Server WebLogic Webサービスの紹介』を参照してください。

WebLogic Webサービスのセキュリティについては、『Oracle WebLogic Server WebLogic Webサービスの保護』を参照してください。

2 非同期リクエスト-レスポンスを使用したWebサービスの呼出し

この章では、非同期リクエスト-レスポンスを使用してWebLogic Java API for XML-based RPC (JAX-RPC) Webサービスを呼び出す方法について説明します。

この章では、以下のトピックについて説明します。

- 非同期リクエスト-レスポンス機能の概要

- 非同期リクエスト-レスポンスの使用: 主な手順

- 非同期WebサービスのホストWebLogic Serverインスタンスの構成

- 非同期のJWSファイルの記述

- 非同期リクエスト-レスポンスを使用する場合のbuild.xmlファイルの更新

- 内部非同期サービスの無効化

- 非同期のリクエスト・レスポンスとプロキシ・サーバーの使用

非同期リクエスト-レスポンス機能の概要

Webサービスを同期的に呼び出す場合、呼出し側のクライアント・アプリケーションは、レスポンスが戻るまで待機してから、処理を続行します。レスポンスが即座に戻る場合であれば、このWebサービス呼出しの方法は適切であると考えられます。しかし、リクエストの処理が遅延する可能性があるため、クライアント・アプリケーションによる処理を続行しレスポンスへの対処は後で行うようにする、すなわち、WebLogic Webサービスにおける非同期リクエスト-レスポンス機能を使用すると便利なことがよくあります。

Webサービスの非同期的な呼出しは、WebLogic Webサービスで実行されているクライアントからのみ行います。スタンドアロンのクライアント・アプリケーションから行うことはありません。呼び出されたWebサービスは、まったく変更されません。したがって、Webサービスをホストするアプリケーション・サーバーがhttp://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/にあるWS-Addressing仕様をサポートしているかぎり、任意のデプロイ済Webサービス(WebLogicのものも、それ以外のものも)を非同期的に呼び出せます。

クライアントに非同期リクエスト-レスポンスを実装するには、操作を直接呼び出すのではなく、非同期な種類の同じ操作を呼び出します。(この非同期な種類の操作は、jwsc Antタスクによって自動生成されます。)たとえば、getQuoteという操作を直接呼び出すのではなく、getQuoteAsyncを呼び出します。非同期な種類の操作は、オリジナルの操作が値を戻す場合でも、常にvoidを戻します。そのため、クライアントには、非同期のレスポンスまたは障害が後で戻されたときにそれを処理するメソッドを組み込みます。これらのメソッド内には、Webサービス操作呼出しに対する戻り値、または潜在的な障害を処理するビジネス・ロジックを置きます。これらのメソッドをJWSコンパイラに対して指定するには、ネーミング・ルールとJWSアノテーションの双方を使用します。たとえば、非同期操作がgetQuoteAsyncである場合、これらのメソッドはonGetQuoteAsyncResponseおよびonGetQuoteAsyncFailureになります。

注意:
Webサービスの信頼性のあるメッセージングやバッファリングなどの他の非同期機能とともに非同期リクエスト-レスポンスを使用する場合については、第6章「非同期機能の併用」を参照してください。本項では、非同期リクエスト-レスポンス機能を単独で使用する方法について説明します。
非同期リクエスト-レスポンス機能は、HTTPでのみ動作します。HTTPSまたはJMSトランスポートでは使用できません。

非同期リクエスト-レスポンスの使用: 主な手順

次の手順では、他のWebサービス内に非同期的に操作を呼び出すクライアントWebサービスの作成方法を説明します。この手順では、クライアントWebサービスを実装するJWSファイルをゼロから作成する方法を示しています。既存のJWSファイルを更新する場合は、この手順をガイドとして利用してください。

わかりやすくするために、この手順では以下を想定しています。

- クライアントWebサービスの名前はStockQuoteClientServiceです。

- StockQuoteClientServiceサービスは、WSDLが次のURLにある、デプロイ済みのStockQuoteServiceサービスのgetQuote(String)操作を呼び出します。

http://localhost:7001/async/StockQuote?WSDL

さらに、Antベースの開発環境を設定済であり、かつjwsc Antタスクを実行して生成されたサービスをデプロイするためのターゲットを追加できる、作業用のbuild.xmlファイルがあることが前提となっています。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』の次の項を参照してください。

- 使用例とサンプル

- WebLogic Webサービスの開発

- JWSファイルのプログラミング

- Webサービスの呼出し

表2-1 非同期リクエスト-レスポンスを使用する手順

#

手順

説明

1

WebLogic Serverインスタンスを構成します。

「非同期WebサービスのホストWebLogic Serverインスタンスの構成」の説明に従って、非同期のレスポンス・サービスを構成します。

2

StockQuoteClientService Webサービスを実装する、新しいJWSファイルを作成するか、既存のJWSファイルを更新します。

使い慣れたIDEまたはテキスト・エディタを使用します。「非同期のJWSファイルの記述」を参照してください。

3

build.xmlファイルを更新して、StockQuoteClientServiceを実装するJWSファイルがコンパイルされるようにします。

jwsc Antタスクに<clientgen>子要素を追加することによって、呼び出している非同期な種類のWebサービス操作が自動的に生成されます。

「非同期リクエスト-レスポンスを使用する場合のbuild.xmlファイルの更新」を参照してください。

4

Antターゲットを実行して、StockQuoteClientServiceをビルドします。

例:

prompt> ant build-clientService

5

StockQuoteClientService Webサービスを通常どおりデプロイします。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

StockQuoteClientService Webサービスを呼び出すと、そのWebサービスがStockQuoteService Webサービスを呼び出します。この2回目の呼出しは、同期ではなく非同期のものになります。

非同期WebサービスのホストWebLogic Serverインスタンスの構成

非同期Webサービスのデプロイ先となるWebLogic Serverインスタンスを構成する際には、Webサービスのランタイムで内部的に使用される、JMSサーバーやモジュールなどのJMSリソースを構成します。

これらのリソースは手作業でも構成できますが、構成ウィザードで、Webサービス固有の拡張テンプレートを使用してWebLogic Serverドメインを拡張することもできます。構成ウィザードを使用すると、必要な構成手順を大幅に簡略化できます。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービス機能用のドメイン構成に関する項を参照してください。

注意:
または、WLSTを使用してリソースを構成することもできます。WLSTを使用してドメインを拡張する方法については、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。
Webサービス・リソースを含まないドメインは、Webサービスと関連のないシナリオや、非同期のリクエストおよびレスポンスを呼び出さないWebサービスのシナリオであれば、適切に起動して実行されます。ただし、サーバー・ログには、非同期リソースが構成されていないことと、Webサービス用の非同期レスポンス・サービスが完全にデプロイされていないことを示すINFOメッセージが表示されます。

リソースを手作業で構成する場合、以下の手順を実行します。

表2-2 非同期WebサービスのホストWebLogic Serverインスタンスを手作業で構成する手順

#

手順

説明

1

ホストWebLogic Serverインスタンスが格納されたドメインの管理コンソールを起動します。

ブラウザで管理コンソールを起動するには、次のURLを入力します。

http://host:port/console

ここで

- hostは、管理サーバーが動作しているコンピュータを指します。

- portは、管理サーバーが接続リクエストをリスニングしているポート番号を指します。管理サーバーのデフォルトのポート番号は7001です。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』の管理コンソールの起動に関する項を参照してください。

2

JMSサーバーを作成します。

JMSサーバーを作成します。JMSサーバーがすでに存在する場合は、新しいJMSサーバーを作成せずにそれを使用できます。

Oracle WebLogic Server管理コンソール・ヘルプのJMSサーバーの作成に関する項を参照してください。

3

JMSモジュールを作成し、キューを定義します。

JMSモジュールを作成し、その中にJMSキューを定義します。JMSモジュールがすでに存在する場合は、新しいJMSモジュールを作成せずにそれを使用することもできます。JMSキューを、1つ前の手順で作成したJMSサーバーにターゲット指定します。このJMSキューがローカルであることを必ず指定してください(通常は、ローカルJNDI名の設定により指定できます)。Oracle WebLogic Server管理コンソール・ヘルプのJMSシステム・モジュールの作成に関する項とシステム・モジュールのキューの作成に関する項を参照してください。

非同期WebサービスでデフォルトWebサービスのキューを使用する場合は、JMSキューのJNDI名をweblogic.wsee.DefaultQueueに設定します。

クラスタリングの考慮事項:

クラスタ内でWebサービスの非同期機能を使用する場合は、次の作業を行う必要があります。

- JMSキューの作成時に、分散キューではなくローカルJMSキューを作成します。

- このJMSキューをクラスタ内の各サーバーに明示的にターゲット指定します。

4

ワーク・マネージャを作成します。

weblogic.wsee.mdb.DispatchPolicyという名前でワーク・マネージャを定義します。これは、デフォルトで非同期リクエスト-レスポンス機能で使用されます。

Oracle WebLogic Server管理コンソール・ヘルプのグローバル・ワーク・マネージャの作成に関する項を参照してください。

5

必要に応じて、現在のドメイン環境をチューニングする(オプション)

『Oracle WebLogic Serverパフォーマンスおよびチューニング』の負荷が高いシステムのチューニングによるWebサービスのパフォーマンス向上に関する項を参照してください。

非同期のJWSファイルの記述

次の例では、StockQuoteClientというWebサービスを実装する簡単なJWSファイルを示します。このWebサービスには、asyncOperationという単一のメソッドがあり、これが非同期的に、StockQuoteサービスのgetQuoteメソッドを呼び出します。太字で示されたJavaコードについては、「Webサービスの非同期な呼出しのコーディングに関するガイドライン」で説明します。この非同期呼出しが、同じ操作の同期呼出しとどう違うのかについては、「同期呼出しのサンプル」を参照してください。

package examples.webservices.async_req_res;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.ServiceClient;
import weblogic.jws.AsyncResponse;
import weblogic.jws.AsyncFailure;

import weblogic.wsee.async.AsyncPreCallContext;
import weblogic.wsee.async.AsyncCallContextFactory;
import weblogic.wsee.async.AsyncPostCallContext;

import javax.jws.WebService;
import javax.jws.WebMethod;

import examples.webservices.async_req_res.StockQuotePortType;

import java.rmi.RemoteException;

@WebService(name="StockQuoteClientPortType",
serviceName="StockQuoteClientService",
targetNamespace="http://examples.org/")

@WLHttpTransport(contextPath="asyncClient",
serviceUri="StockQuoteClient",
portName="StockQuoteClientServicePort")

/**
*  Client Web Service that invokes the StockQuote Service asynchronously.
*/

public class StockQuoteClientImpl {

@ServiceClient(wsdlLocation="http://localhost:7001/async/StockQuote?WSDL",
serviceName="StockQuoteService", portName="StockQuote")

private StockQuotePortType port;

@WebMethod
public void asyncOperation (String symbol, String userName)
throws RemoteException {

AsyncPreCallContext apc = AsyncCallContextFactory.getAsyncPreCallContext();
apc.setProperty("userName", userName);

try {
port.getQuoteAsync(apc, symbol );
System.out.println("in getQuote method of StockQuoteClient WS");

} catch (RemoteException re) {

System.out.println("RemoteException thrown");
throw new RuntimeException(re);
}

}

@AsyncResponse(target="port", operation="getQuote")
public void onGetQuoteAsyncResponse(AsyncPostCallContext apc, int quote) {
// Get the userName property we set on AsyncPreCallContext
String userName = (String)apc.getProperty("userName");
System.out.println("-------------------");
System.out.println(username + " Got quote " + quote );
System.out.println("-------------------");
}

@AsyncFailure(target="port", operation="getQuote")
public void onGetQuoteAsyncFailure(AsyncPostCallContext apc, Throwable e) {
System.out.println("-------------------");
e.printStackTrace();
System.out.println("-------------------");
}

}

Webサービスの非同期な呼出しのコーディングに関するガイドライン

操作を非同期的に呼び出すための以下のガイドラインは、「非同期のJWSファイルの記述」に記載のサンプルにおいて太字で示したJavaコードに対応しています。これらのガイドラインは、JWSファイル作成のための標準的なガイドラインへの付け加えです。この非同期呼出しが、同じ操作の同期呼出しとどう違うのかについては、「同期呼出しのサンプル」を参照してください。

JWSファイルで操作の非同期呼出しを行う方法は次のとおりです。

- 非同期リクエスト-レスポンス機能に関連する、次のWebLogic固有のJWSアノテーションをインポートします。

import weblogic.jws.ServiceClient;
import weblogic.jws.AsyncResponse;
import weblogic.jws.AsyncFailure;

- 呼び出すWebサービスのポート・タイプのJAX-RPCスタブをインポートします。このスタブは、jwsc Antタスクによって後から作成されます。スタブ・パッケージは、jwscの子要素<clientgen>のpackageName属性によって指定され、スタブの名前は呼び出されたWebサービスのWSDLによって決まります。

import examples.webservices.async_req_res.StockQuotePortType;

- 非同期の呼出し前および呼出し後におけるコンテキストWebLogic APIをインポートします。

import weblogic.wsee.async.AsyncCallContextFactory;
import weblogic.wsee.async.AsyncPreCallContext;
import weblogic.wsee.async.AsyncPostCallContext;

非同期の呼出し前および呼出し後におけるコンテキストの詳細は、「非同期の呼出し前および呼出し後におけるコンテキストの使用」を参照してください。これらのAPIのさらなるリファレンス情報については、Oracle WebLogic Server APIリファレンスのweblogic.wsee.asyncに関する項を参照してください。

- JWSファイルの本文で、必要な@ServiceClient JWSアノテーションを使用して、非同期に呼び出すWebサービスのWSDL、名前およびポートを指定します。このアノテーションは、変数のフィールド・レベルで指定します。この変数のデータ型は、呼び出しているWebサービスのJAX-RPCポート・タイプとなります。

@ServiceClient(
wsdlLocation="http://localhost:7001/async/StockQuote?WSDL",
serviceName="StockQuoteService",
portName="StockQuote")

private StockQuotePortType port;

@ServiceClientアノテーションで変数(この場合はport)をアノテーション付きにする場合、Webサービス・ランタイムはその変数を自動的に初期化およびインスタンス化し、別のWebサービスの非同期呼出しに使用できるようにします。

- getQuote操作を非同期に呼び出すJWSファイルのメソッドで、コンテキスト・ファクトリを使用して、呼出し前の非同期コンテキストを取得します。

AsyncPreCallContext apc =
AsyncCallContextFactory.getAsyncPreCallContext();

非同期の呼出し前および呼出し後におけるコンテキストの詳細は、「非同期の呼出し前および呼出し後におけるコンテキストの使用」を参照してください。

- 呼出し前コンテキストのsetPropertyメソッドを使用して、ユーザー名を格納するプロパティを作成します。

apc.setProperty("userName", userName);

- @ServiceClientアノテーションを付けたスタブを使用して、操作(この場合はgetQuote)を呼び出します。ただし、直接呼び出すのではなく、その操作の名前の末尾にAsyncが追加された、非同期のものを呼び出します。非同期の種類の操作は、常にvoidを返します。非同期のコンテキストを最初のパラメータとして渡します。

port.getQuoteAsync(apc, symbol);

- 非同期に呼び出す各操作について、onOperationnameAsyncResponseというメソッドを作成します。Operationnameは操作名で、最初の1文字は常に大文字です。メソッドは、voidを返さなければならず、呼出し後の非同期コンテキストおよび呼び出している操作の戻り値という、2つのパラメータを備えていることが必要です。@AsyncResponse JWSアノテーションでメソッドをアノテーション付きにします。データ型がJAX-RPCスタブである変数を指定するにはtarget属性を使用し、非同期に呼び出している操作の名前を指定するにはoperation属性を使用します。メソッドの本文の中に、操作によって返された値を処理するビジネス・ロジックを入れます。呼出し後コンテキストのgetPropertyメソッドを使用して、非同期メソッドを呼び出す前に呼出し前コンテキストで設定したプロパティを取得します。

@AsyncResponse(target="port", operation="getQuote")
public void onGetQuoteAsyncResponse(AsyncPostCallContext apc,
int quote) {
// Get the userName property we set on AsyncPreCallContext
String userName = (String)apc.getProperty("userName");
System.out.println("-------------------");
System.out.println("Got quote " + quote );
System.out.println("-------------------");
}

非同期の呼出し前および呼出し後におけるコンテキストの詳細は、「非同期の呼出し前および呼出し後におけるコンテキストの使用」を参照してください。

- 非同期に呼び出す各操作について、onOperationnameAsyncFailureというメソッドを作成します。Operationnameは操作名で、最初の1文字は大文字です。メソッドはvoidを返さなければならず、呼出し後の非同期コンテキスト、および呼び出された操作がスローするすべての種類の例外を処理するすべての例外のスーパークラスであるThrowableオブジェクトという、2つのパラメータを備えていることが必要です。@AsyncFailure JWSアノテーションでメソッドをアノテーション付きにします。データ型がJAX-RPCスタブである変数を指定するにはtarget属性を使用し、非同期に呼び出している操作の名前を指定するにはoperation属性を使用します。メソッド内では、例外の性質を正確に判断し、適切なJavaコードを記述することができます。

@AsyncFailure(target="port", operation="getQuote")
public void onGetQuoteAsyncFailure(AsyncPostCallContext apc,
Throwable e) {
System.out.println("-------------------");
e.printStackTrace();
System.out.println("-------------------");
}

注意:
@AsyncResponseアノテーションおよび@AsyncFailureアノテーションの使用は、曖昧な点がすべて明瞭化されJWSファイルが明確かつ理解しやすいものになるため推奨されますが、必須ではありません。ただし、onXXXメソッドの1つで、同じ名前を持つ別々の2つのWebサービスから操作を呼び出している2つ(またはそれ以上)のスタブからの非同期レスポンスまたは障害を処理する場合は、これらのアノテーションの使用を明示的に避ける必要があります。onXXXメソッドの名前は必ず、前述の正しいネーミング・ルールに厳密に準拠するようにしてください。

非同期の呼出し前および呼出し後におけるコンテキストの使用

AsyncPreCallContextおよびAsyncPostCallContextの各APIは、様々な理由によりWebサービスでの使用が可能な非同期のコンテキストを記述します。例:

- 非同期レスポンスを処理するメソッドがそれぞれの非同期呼出しを見分けられるようコンテキストの前にプロパティを設定する

- 操作を呼び出しているユーザーの名前、パスワードなどのコンテキスト変数を取得および設定する

- メソッドを非同期的に呼び出したJAX-RPCスタブの名前を取得する、およびコンテキストのタイムアウト間隔を設定する

非同期の呼出し前および呼出し後におけるコンテキストを使用するには:

1. 非同期の呼出し前および呼出し後におけるコンテキストWebLogic APIをインポートします。

import weblogic.wsee.async.AsyncCallContextFactory;
import weblogic.wsee.async.AsyncPreCallContext;
import weblogic.wsee.async.AsyncPostCallContext;

2. 非同期操作を呼び出すJWSファイルのメソッドで、コンテキスト・ファクトリを使用して呼出し前の非同期コンテキストを取得します。例:

AsyncPreCallContext apc =
AsyncCallContextFactory.getAsyncPreCallContext();

3. 呼出し前コンテキストのメソッドを使用して、非同期メソッドが呼び出される前に非同期コンテキストに対して処理します。次の例は、呼出し前コンテキストのsetPropertyメソッドを使用して、ユーザー名を格納するプロパティを作成します。

apc.setProperty("userName", userName);

4. 呼出し後コンテキストのメソッドを使用して、非同期メソッドが呼び出された後で非同期コンテキストに対して処理します。次の例は、呼出し後コンテキストのgetPropertyメソッドを使用して、非同期メソッドを呼び出す前に呼出し前コンテキストで設定したプロパティを取得します。

String userName = (String)apc.getProperty("userName");

同期呼出しのサンプル

次のサンプルでは、StockQuote WebサービスのgetQuote操作を同期的に呼び出すJWSファイルを示します。このサンプルは、「非同期のJWSファイルの記述」に示した、対応する非同期呼出しとの比較目的でのみ示されています。

package examples.webservices.async_req_res;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.ServiceClient;

import javax.jws.WebService;
import javax.jws.WebMethod;

import java.rmi.RemoteException;

@WebService(name="SyncClientPortType",
serviceName="SyncClientService",
targetNamespace="http://examples.org/")

@WLHttpTransport(contextPath="syncClient",
serviceUri="SyncClient",
portName="SyncClientPort")

/**
*  Normal service-to-service client that invokes StockQuote service
*  synchronously.
*/

public class SyncClientImpl {

@ServiceClient(wsdlLocation="http://localhost:7001/async/StockQuote?WSDL",
serviceName="StockQuoteService", portName="StockQuote")
private StockQuotePortType port;

@WebMethod
public void nonAsyncOperation(String symbol) throws RemoteException {

int quote = port.getQuote(symbol);

System.out.println("-------------------");
System.out.println("Got quote " + quote );
System.out.println("-------------------");

}

}

非同期リクエスト-レスポンスを使用する場合のbuild.xmlファイルの更新

build.xmlファイルを更新して、Webサービス操作を非同期的に呼び出すJWSファイルを生成するには、次のようなtaskdefsおよびbuild-clientServiceターゲットを追加します。詳細は、サンプルの後の説明を参照してください。

<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />

<target name="build-clientService">

<jwsc
enableAsyncService="true"
srcdir="src"
destdir="${clientService-ear-dir}" >

<jws file="examples/webservices/async_req_res/StockQuoteClientImpl.java" >

<clientgen
wsdl="http://${wls.hostname}:${wls.port}/async/StockQuote?WSDL"
packageName="examples.webservices.async_req_res"/>

</jws>

</jwsc>

</target>

jwsc Antタスクの完全なクラス名を定義するには、taskdef Antタスクを使用します。

クライアントWebサービスをコンパイルするjwsc Antタスクを更新して、<jws>要素の<clientgen>子要素を含めます。これにより、デプロイされたStockQuote WebサービスのJAX-RPCスタブが生成およびコンパイルされるようになります。jwsc Antタスクでは、これらのスタブが生成されたWARファイルに自動的にパッケージ化されるため、即座にクライアントWebサービスからアクセスできるようになります。この場合のデフォルトでは、jwsc AntタスクはJAX-RPCスタブ内にWebサービス操作の同期した種類のものと非同期な種類のものを両方とも生成します。このようにするのは、生成されたクラスの1つをStockQuoteClientImpl JWSファイルでインポートして使用するためです。

内部非同期サービスの無効化

デフォルトでは、すべてのWebLogic Serverインスタンスに、非同期リクエスト-レスポンス機能を処理する内部非同期Webサービスがデプロイされます。この内部サービスがデプロイされないようにするには、-Dweblogic.wsee.skip.async.response=true Javaシステム・プロパティを使用してWebLogic Serverインスタンスを起動します。

非同期サービスを無効にするケースとしては、WebLogic ServerインスタンスをWebLogicクラスタへのWebプロキシとして使用する場合が考えられます。この場合、クラスタ宛に非同期メッセージが送信されても、プロキシ・サーバー上の非同期サービスによって消費されてしまうためクラスタには届きません。このような理由から、プロキシ・サーバー上の非同期サービスは、上記のシステム・プロパティを使用して無効にする必要があります。

Javaシステム・プロパティを指定してWebLogic Serverを構成する方法の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic ServerインスタンスのJavaオプションの指定に関する項を参照してください。

非同期のリクエスト・レスポンスとプロキシ・サーバーの使用

非同期のリクエスト・レスポンス機能を使用するクライアント・アプリケーションでは、操作を直接呼び出さず、プロキシ・サーバーを使用する場合があります。プロキシを使用する理由としては、ファイアウォールの存在や、呼び出されたWebサービスのクラスタへのデプロイメントなどがあります。

この場合、呼び出されたWebサービスをホストするWebLogic Serverインスタンスは、プロキシ・サーバーのアドレスとポートで構成する必要があります。Webサービスがクラスタにデプロイされている場合は、そのクラスタ内のすべてのサーバーを構成することが必要です。

この手順では、ネットワーク接続を管理するための構成可能なWebLogic Serverの主要リソースであるネットワーク・チャネルの作成方法について説明します。ネットワーク・チャネルにより、クラスタのフロントエンド・アドレスにアクセスするための一貫性のある方法を提供できます。ネットワーク・チャネルの詳細は、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・チャネルの理解に関する項を参照してください。

各サーバー・インスタンスについて、以下の手順を実行します。

1. Webサービスの呼出しに使用するプロトコル用のネットワーク・チャネルを作成します。ネットワーク・チャネルの名前は、weblogic-wsee-proxy-channel-XXXとする必要があります(XXXはプロトコルを表します)。たとえば、HTTPS用のネットワーク・チャネルを作成する場合、weblogic-wsee-proxy-channel-httpsという名前にします。
ネットワーク・チャネルの作成に関する一般情報は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください。

2. 「外部リスニング・アドレス」および「外部リスニング・ポート」フィールドを、それぞれプロキシ・サーバーのアドレスおよびポートで更新して、ネットワーク・チャネルを構成します。

3 Webサービスの信頼性のあるメッセージングの使用

この章では、WebLogic Java API for XML-based RPC (JAX-RPC) WebサービスにおけるWebサービスの信頼性のあるメッセージングについて説明します。

この章では、以下のトピックについて説明します。

- Webサービスの信頼性のあるメッセージングの概要

- Webサービスの信頼性のあるメッセージングの使用: 主な手順

- 宛先WebLogic Serverインスタンスの構成

- ソースWebLogic Serverインスタンスの構成

- Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成

- 信頼性のあるJWSファイルに関するプログラミングのガイドライン

- 信頼性のあるWebサービスの信頼性のあるメッセージングの構成

- 信頼性のあるWebサービスを呼び出すJWSファイルに関するプログラミングのガイドライン

- 信頼性のあるWebサービスのクライアント用build.xmlファイルの更新

- 信頼性のあるメッセージングとMTOMの使用

- 信頼性のあるWebサービスを再デプロイする際にクライアント側で考慮すべき事項

- 信頼性のあるメッセージングとプロキシ・サーバーの使用

注意:
Webサービスの信頼性のあるメッセージングでは、WebLogic Webサービスの非同期リクエスト-レスポンス機能を使用する必要があります。先に進む前に、第2章「非同期リクエスト-レスポンスを使用したWebサービスの呼出し」で説明する概念を理解してください。

Webサービスの信頼性のあるメッセージングの概要

Webサービスの信頼性のあるメッセージングとは、ある1つのアプリケーション・サーバーで実行中のアプリケーションが、別のアプリケーション・サーバーで実行中のWebサービスを確実に呼び出せるフレームワークです。ここでは、双方のサーバーでWS-ReliableMessaging仕様が実装されていることが前提となっています。「信頼性がある」とは、ソフトウェア・コンポーネント、システム、またはネットワークに障害があっても、2つのWebサービス間でメッセージ配信を保証できる状態として定義されます。

注意:
Webサービスの信頼性のあるメッセージングは、WS-ReliableMessaging仕様(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf)が実装された任意の2つのアプリケーション・サーバー間で機能します。ただし、このドキュメントでは、この2つのアプリケーション・サーバーがWebLogic Serverインスタンスであると想定しています。
Webサービスの信頼性のあるメッセージングは、JMSトランスポート機能ではサポートされません。

WebLogic Webサービスは、http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfにあるWS-ReliableMessaging仕様(2007年6月)に準拠しています。この仕様では、別々のアプリケーション・サーバーで実行されている2つのWebサービスが確実に通信できる方法について記述されています。具体的には、この仕様では送信元エンドポイント(つまりクライアントWebサービス)から宛先エンドポイント(つまり操作を確実に呼び出せるWebサービス)へ送信されるメッセージが、1つ以上の配信保証に基づいて確実に配信されるか、そうでなければ必ずエラーが発生する、相互運用性を備えたプロトコルについて説明されています。

信頼性のあるWebLogic Webサービスには、次の配信保証が備わっています。

表3-1 信頼性のあるメッセージングの配信保証

配信保証

説明

At Most Once

メッセージは最大で1回、重複なしに配信されます。メッセージによっては、一度も配信されない可能性もあります。

At Least Once

すべてのメッセージが、少なくとも1回配信されます。メッセージによっては、1回よりも多く配信される可能性があります。

Exactly Once

すべてのメッセージが、必ず1回重複なしに配信されます。

In Order

メッセージは、送信された順序で配信されます。この配信保証は、上記の3つの保証と組み合せることもできます。

注意:
Webサービスの信頼性のあるメッセージングでは、非同期メッセージを使用する必要があります。クライアントが信頼性のあるサービスを同期的に呼び出すことはできません。信頼性のあるスタブ・メソッドを呼び出す際には、xyz()ではなくxyzAsync()のような非同期署名を必ず使用してください。SOAPメッセージを直接作成するクライアントのために、非匿名のReplyToアドレスを使用してリクエスト・メッセージを作成します。
ReplyToを匿名URIに設定することはできません。JAX-RPCベースの信頼性のあるサービス操作を呼び出そうとすると(同期スタブ署名を呼び出すか、匿名のReplyToを使用してリクエストを送信することにより)、実行時例外がスローされます。

ここでは、信頼性のあるクライアントWebサービスを作成し、そのWebサービスがデプロイされる2つのWebLogic Serverインスタンスを構成する方法について説明します。Webサービスの信頼性のあるメッセージングのアーキテクチャの詳細は、WS-ReliableMessaging仕様を参照してください(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfを参照)。

WS-Policyを使用した信頼性のあるメッセージング・ポリシーのアサーションの指定

WebLogic Webサービスでは、宛先エンドポイントがWebサービスの信頼性のあるメッセージングの機能と要件を記述および公開できるように、WS-Policyファイルを使用します。WS-Policyファイルは、サポートされているWS-ReliableMessaging仕様のバージョンやサービス品質の要件などが記述されたXMLファイルです。WS-Policy仕様(http://www.w3.org/TR/ws-policy/)では、Webサービスのポリシーを記述して通信するための、汎用的なモデルと構文が提供されています。

WebLogic Serverには、標準的な信頼性のあるメッセージング・アサーションを含むあらかじめパッケージ化されているWS-Policyファイルがあります(付録A「信頼性のあるメッセージング用にパッケージ化されているWS-Policyファイル」を参照)。あらかじめパッケージ化されているWS-Policyファイルがニーズに合わない場合は、独自のWS-Policyファイルを作成する必要があります。詳細は、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。信頼性のあるメッセージングのポリシー・アサーションに関するリファレンス情報は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

信頼性のあるメッセージ・シーケンスのライフサイクルの管理

次の図に、信頼性のあるメッセージの一方向の交換を示します。

図3-1 Webサービスの信頼性のあるメッセージの交換

信頼性のあるメッセージ・シーケンスは、RM送信元とRM宛先の間で確実に交換されるメッセージ・セットの進捗状況を追跡する際に使用されます。シーケンスは、0個以上のメッセージの送信に使用でき、文字列識別子で識別されます。この識別子は、信頼性のあるメッセージングを使用する際に、そのシーケンスを参照するために使用されます。

Webサービス・クライアント・アプリケーションは、RM送信元がRM宛先へ送信する信頼性のある配信のメッセージを送信します。RM宛先は、信頼性のあるメッセージを受信したことを確認応答し、そのメッセージをWebサービス・アプリケーションに配信します。RM送信元は、確認応答を受け取るまでメッセージを再送信できます。

Webサービス・クライアントは、JAX-RPCスタブに対するメソッドの呼出しを行い、ターゲットWebサービスへメッセージを送信します。スタブは、信頼性のあるWebサービスのポート・タイプに関連付けられており、そのWebサービスのプログラム的なインタフェースを表します。WebLogicでは、このスタブ内に、信頼性のあるメッセージ・シーケンスの識別子が格納されます。これによって、信頼性のあるメッセージ・シーケンスが単一のJAX-RPCスタブに接続されます。特定のスタブを使用して送信されるすべてのメッセージは、そのメッセージの数に関係なく、同じ信頼性のあるメッセージ・シーケンスを使用します。JAX-RPCスタブは、jwsc Antタスクの子要素<clientgenによって作成されます。

WebLogic Serverでは、リソースが信頼性のあるシーケンスに関連付けられた状態で維持されるため、これらのリソースを適時に解放する措置を講じることをお薦めします。WebLogic Serverには、Webサービスの信頼性のあるメッセージングで使用できるユーティリティ・クラスweblogic.wsee.reliability.WsrmUtilsがあります。このクラスを使用すると、構成オプションの設定、シーケンスIDの取得、信頼性のあるシーケンスの終了といった一般的なタスクを実行できます。

通常の環境下では、信頼性のあるシーケンスは、すべてのメッセージが送信され、RM宛先によって確認応答されるまで保持する必要があります。シーケンスを容易に適時終了するには、信頼性のあるメッセージ・シーケンスの最終メッセージを識別することが推奨されます。識別すると、RM宛先へのメッセージの送信が完了したこと、およびWebLogic Serverが信頼性のあるシーケンスを自動的に終了する前に最終確認応答の検出を開始できることを示します。最終メッセージは、weblogic.wsee.reliability.WsrmUtils.setFinalMessage()メソッドを使用し、メッセージの送信に使用されているJAX-RPCスタブをRM宛先に渡して示します。

最終メッセージを識別する場合、最終メッセージまでの最終メッセージを含むすべてのメッセージが確認応答され、信頼性のあるメッセージ・シーケンスが終了し、すべてのリソースが開放されます。そうでない場合、シーケンスは、構成したシーケンスの有効期限に達した後で自動的に終了します。

これは推奨されませんが、terminateSequence()メソッドを使用すると、すべてのメッセージが確認応答されているかどうかに関係なく、信頼性のあるメッセージ・シーケンスを終了できます。このメソッドを発行すると、このスタブ上で信頼性のあるメッセージをそれ以降送信することはできません。

注意:
JAX-RPCスタブは、最初のメソッドが信頼性のあるWebサービスに対して呼び出された直後まで完全に初期化されません。最初のメソッドが呼び出されると、RM送信元はCreateSequenceメッセージをRM宛先へ送信し、信頼性のあるシーケンスを作成および登録するようRM宛先にリクエストします。その後、RM送り先は新たに作成されたシーケンスについて、そのIDで応答します。RM送信元は、このレスポンスIDを受信するまでRM送り先と通信できず、RM送り先のターゲット・サービスを表すJAX-RPCスタブは使用できません。
信頼性のあるメッセージ・シーケンスに対しては、そのシーケンスが完全に初期化されるまで操作を行うことはできません。信頼性のあるメッセージ・シーケンスが初期化されているかどうかをモニターするには、weblogic.wsee.reliability.WsrmUtils.waitForSequenceInitialization()メソッドを使用します。このメソッドは、信頼性のあるシーケンスが初期化されると、そのシーケンスのIDを返します。

WsrmUtilsユーティリティ・クラスの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.wsee.reliability.WsrmUtilsに関する項を参照してください。

Webサービスの信頼性のあるメッセージングの使用: 主な手順

WebLogic Webサービスの信頼性のあるメッセージングを構成するには、JMSサーバーやストア・アンド・フォワード(SAF)・エージェントの作成など標準的なJMSタスクとともに、JWSファイルへのJWSアノテーションの追加などWebサービス固有のタスクを実行する必要があります。また、あらかじめパッケージ化されているファイルを使用しない場合は、必要に応じて、信頼性のあるWebサービスの信頼性のあるメッセージング機能を記述したWS-Policyファイルをユーザー側で作成します。

信頼性のあるWebサービスの呼出しにWebLogicクライアントAPIを使用している場合、クライアント・アプリケーションはWebLogic Server上で実行される必要があります。したがって構成タスクは、信頼性のあるWebサービスを確実に呼び出すクライアント・コードを含むWebサービスがデプロイされたソースWebLogic Serverインスタンスと、信頼性のあるWebサービスそのものがデプロイされた宛先WebLogic Serverインスタンスの双方で実行される必要があります。

次の表では、信頼性のあるWebサービスと、その操作を呼び出すクライアントWebサービスを作成する手順を説明しています。この手順では、2つのWebサービスを実装するJWSファイルをゼロから作成する方法を示しています。既存のJWSファイルを更新する場合は、この手順をガイドとして利用してください。またこの手順では、ソースWebLogic Serverインスタンスと宛先WebLogic Serverインスタンスの構成方法も示しています。

表3-2 信頼性のあるWebサービスの作成および呼出しの手順

#

手順

説明

1

宛先WebLogic ServerインスタンスとソースWebLogic Serverインスタンスを構成します。

信頼性のあるWebサービスを宛先WebLogic Serverインスタンスにデプロイします。宛先WebLogic Serverインスタンスの構成については、「宛先WebLogic Serverインスタンスの構成」を参照してください。

信頼性のあるWebサービスを呼び出すクライアントWebサービスを、ソースWebLogic Serverインスタンスにデプロイします。ソースWebLogic Serverインスタンスの構成については、「ソースWebLogic Serverインスタンスの構成」を参照してください。

2

WS-Policyファイルを作成する(オプション)

任意のXMLまたはプレーン・テキスト・エディタを使用し、必要に応じて宛先WebLogic Server上で実行されているWebサービスの信頼性のあるメッセージング機能が記述されたWS-Policyファイルを作成します。独自のWS-Policyファイルを作成する方法の詳細は、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。

WebLogic Serverに付属しているいずれかのWS-Policyファイルを使用する場合、この手順は不要です。詳細については、付録A「信頼性のあるメッセージングためのあらかじめパッケージ化されているWS-Policyファイル」を参照してください。

3

信頼性のあるWebサービスを実装するJWSファイルを作成および更新します。

このWebサービスは、宛先WebLogic Serverインスタンスにデプロイされます。「信頼性のあるJWSファイルに関するプログラミングのガイドライン」を参照してください。

4

信頼性のあるWebサービスのコンパイルに使用されるbuild.xmlファイルを更新します。

build.xmlファイルを更新して、信頼性のあるJWSファイルをWebサービスにコンパイルするjwsc Antタスクの呼出しを含めます。

jwscタスクの使用に関する一般情報は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のjwsc WebLogic WebサービスAntタスクの実行に関する項を参照してください。

5

信頼性のあるJWSファイルをコンパイルおよびデプロイします。

適切なターゲットを呼び出して信頼性のあるJWSファイルをコンパイルし、宛先WebLogic Serverにデプロイします。例:

prompt> ant build-mainService deploy-mainService

6

信頼性のあるWebサービスを構成します。

管理コンソールを使用して、信頼性のあるWebサービスの信頼性のあるメッセージング・オプションを構成します。「信頼性のあるWebサービスの信頼性のあるメッセージングの構成」を参照してください。

7

クライアントWebサービスを実装するJWSファイルを作成および更新します。

このサービスは、信頼性のあるWebサービスを呼び出し、ソースWebLogic Serverにデプロイされます。「信頼性のあるWebサービスを呼び出すJWSファイルに関するプログラミングのガイドライン」を参照してください。

8

クライアントWebサービスのコンパイルに使用されるbuild.xmlファイルを更新します。

「信頼性のあるWebサービスのクライアント用build.xmlファイルの更新」を参照してください。

9

クライアントJWSファイルをコンパイルおよびデプロイします。

適切なターゲットを呼び出してクライアントJWSファイルをコンパイルし、ソースWebLogic Serverにデプロイします。例:

prompt> ant build-clientService deploy-clientService

これらの各手順の詳細は、以降の節を参照してください。

また、以下の高度なトピックについて説明します。

- 信頼性のあるメッセージングとMTOMの使用 - MTOM/XOPを使用し、SOAPメッセージのxs:base64Binary型のXMLデータの送信を最適化する、信頼性のあるWebサービスを開発します

- 信頼性のあるWebサービスを再デプロイする際にクライアント側で考慮すべき事項 - 信頼性のある更新済WebLogic Webサービスの新しいバージョンを、同じWebサービスの古いバージョンと一緒にデプロイする際に、クライアント側で考慮すべき事項について説明します。

- 信頼性のあるメッセージングとプロキシ・サーバーの使用 - プロキシ・サーバーを使用して信頼性のあるWebサービス操作を呼び出す際の考慮事項について説明します。

前提条件

以下の作業を完了している必要があります。

- 宛先WebLogic ServerインスタンスとソースWebLogic Serverインスタンスを作成済である。

- 各環境でのAntベースの開発環境の設定

- 編集(jwsc Antタスクを実行して信頼性のある生成済Webサービスをデプロイするためのターゲットの追加など)が可能な作業用のbuild.xmlファイルの用意。

詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスの開発に関する項を参照してください。

宛先WebLogic Serverインスタンスの構成

信頼性のあるWebサービスがデプロイされるWebLogic Serverインスタンスを構成するには、JMSおよびストア・アンド・フォワード(SAF)・リソースを構成します。

これらのリソースは手作業でも構成できますが、構成ウィザードで、Webサービス固有の拡張テンプレートを使用してWebLogic Serverドメインを拡張することもできます。構成ウィザードを使用すると、必要な構成手順を大幅に簡略化できます。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービス機能用のドメイン構成に関する項を参照してください。

注意:
または、WLSTを使用してリソースを構成することもできます。WLSTを使用してドメインを拡張する方法については、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。
Webサービス・リソースを含まないドメインは、Webサービスと関連のないシナリオや、非同期のリクエストおよびレスポンスを呼び出さないWebサービスのシナリオであれば、適切に起動して実行されます。ただし、サーバー・ログには、非同期リソースが構成されていないことと、Webサービス用の非同期レスポンス・サービスが完全にデプロイされていないことを示すINFOメッセージが表示されます。

リソースを手作業で構成する場合、以下の手順を実行します。

表3-3 宛先WebLogic Serverインスタンスを手作業で構成する手順

#

手順

説明

1

宛先WebLogic Serverが格納されたドメインの管理コンソールを起動します。

ブラウザで管理コンソールを起動するには、次のURLを入力します。

http://host:port/console

ここで

- hostは、管理サーバーが動作しているコンピュータを指します。

- portは、管理サーバーが接続リクエストをリスニングしているポート番号を指します。管理サーバーのデフォルトのポート番号は7001です。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』の管理コンソールの起動に関する項を参照してください。

2

永続ファイル・ストアを作成する(オプション)

必要に応じて、宛先WebLogic ServerがWebサービスの信頼性のあるメッセージングの内部情報を格納するために使用する永続ストア(ファイルまたはJDBC)を作成します。新規作成しない場合は、既存のものを使用するか、常に存在するデフォルトのストアを使用できます。

Oracle WebLogic Server管理コンソール・ヘルプのファイル・ストアの作成に関する項を参照してください。

3

JMSサーバーを作成します。

JMSサーバーを作成します。JMSサーバーがすでに存在する場合は、新しいJMSサーバーを作成せずにそれを使用できます。

Oracle WebLogic Server管理コンソール・ヘルプのJMSサーバーの作成に関する項を参照してください。

4

JMSモジュールを作成し、キューを定義します。

JMSモジュールを作成し、その中にJMSキューを定義します。JMSモジュールがすでに存在する場合は、新しいJMSモジュールを作成せずにそれを使用することもできます。JMSキューを、1つ前の手順で作成したJMSサーバーにターゲット指定します。このJMSキューがローカルであることを必ず指定してください(通常は、ローカルJNDI名の設定により指定できます)。

後で信頼性のあるWebサービスを実装するJWSファイルをプログラムする際に使用するため、JMSキュー用に定義したJNDI名は覚えておく必要があります。

Oracle WebLogic Server管理コンソール・ヘルプのJMSシステム・モジュールの作成に関する項とシステム・モジュールのキューの作成に関する項を参照してください。

クラスタリングの考慮事項:

クラスタ内でWebサービスの信頼性のあるメッセージング機能を使用する場合は、次の作業を行う必要があります。

- JMSキューの作成時に、分散キューではなくローカルJMSキューを作成します。

- このJMSキューをクラスタ内の各サーバーに明示的にターゲット指定します。

5

ストア・アンド・フォワード(SAF)エージェントを作成します。

新規作成しない場合は、既存のものを使用できます。

SAFエージェントを作成する場合は、次の作業を行います。

- 「エージェントの種類」フィールドを「両方」に設定して、送信エージェントと受信エージェントの双方を有効化します。

- 最初のアシスタント・ページで、「終了」ではなく「次へ」をクリックして「ターゲットの選択」ページを表示し、必ずSAFエージェントをターゲット指定します。

クラスタリングの考慮事項:

- クラスタ内で信頼性のあるメッセージングを使用している場合、SAFエージェントをそのクラスタにターゲット指定する必要があります。

Oracle WebLogic Server管理コンソール・ヘルプのストア・アンド・フォワード・エージェントの作成に関する項を参照してください。

6

必要に応じて、現在のドメイン環境をチューニングする(オプション)

『Oracle WebLogic Serverパフォーマンスおよびチューニング』の負荷が高いシステムのチューニングによるWebサービスのパフォーマンス向上に関する項を参照してください。

7

サーバーを再起動します。

構成の変更を有効にするには、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項の説明に従って、サーバーを再起動する必要があります。

ソースWebLogic Serverインスタンスの構成

クライアントWebサービスがデプロイされるWebLogic Serverインスタンスを構成する際には、JMSおよびストア・アンド・フォワード(SAF)・リソースを構成します。

これらのリソースは手作業でも構成できますが、構成ウィザードで、Webサービス固有の拡張テンプレートを使用してWebLogic Serverドメインを拡張することもできます。構成ウィザードを使用すると、必要な構成手順を大幅に簡略化できます。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービス機能用のドメイン構成に関する項を参照してください。

注意:
または、WLSTを使用してリソースを構成することもできます。WLSTを使用してドメインを拡張する方法については、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。
Webサービス・リソースを含まないドメインは、Webサービスと関連のないシナリオや、非同期のリクエストおよびレスポンスを呼び出さないWebサービスのシナリオであれば、適切に起動して実行されます。ただし、サーバー・ログには、非同期リソースが構成されていないことと、Webサービス用の非同期レスポンス・サービスが完全にデプロイされていないことを示すINFOメッセージが表示されます。

リソースを手作業で構成する場合、以下の手順を実行します。

表3-4 ソースWebLogic Serverインスタンスの構成手順

#

手順

説明

1

ソースWebLogic Serverが格納されたドメインの管理コンソールを起動します。

ブラウザで管理コンソールを起動するには、次のURLを入力します。

http://host:port/console

ここで

- hostは、管理サーバーが動作しているコンピュータを指します。

- portは、管理サーバーが接続リクエストをリスニングしているポート番号を指します。管理サーバーのデフォルトのポート番号は7001です。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』の管理コンソールの起動に関する項を参照してください。

2

永続ファイル・ストアを作成する(オプション)

必要に応じて、ソースWebLogic ServerがWebサービスの信頼性のあるメッセージングの内部情報を格納するために使用する永続ストア(ファイルまたはJDBC)を作成します。新規作成しない場合は、既存のものを使用するか、常に存在するデフォルトのストアを使用できます。

Oracle WebLogic Server管理コンソール・ヘルプのファイル・ストアの作成に関する項を参照してください。

3

ストア・アンド・フォワード(SAF)エージェントを作成します。

新規作成しない場合は、既存のものを使用できます。

SAFエージェントを作成する場合は、「エージェントの種類」フィールドを「両方」に設定して、送信エージェントと受信エージェントの双方を有効化します。

Oracle WebLogic Server管理コンソール・ヘルプのストア・アンド・フォワード・エージェントの作成に関する項を参照してください。

6

必要に応じて、現在のドメイン環境をチューニングする(オプション)

『Oracle WebLogic Serverパフォーマンスおよびチューニング』の負荷が高いシステムのチューニングによるWebサービスのパフォーマンス向上に関する項を参照してください。

7

サーバーを再起動します。

構成の変更を有効にするには、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項の説明に従って、サーバーを再起動する必要があります。

Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成

WS-Policyファイルは、WS-Policy仕様に準拠するポリシー・アサーションを含むXMLファイルです。この場合、WS-PolicyファイルにはWebサービスの信頼性のあるメッセージングのポリシー・アサーションが含まれています。

WebLogic Serverには、標準的な信頼性のあるメッセージング・アサーションを含むWS-Policyファイルがあらかじめパッケージ化されています。独自のWS-Policyファイルを作成しない場合は、これらのファイルを使用できます。次の表に、あらかじめパッケージ化されているWS-Policyファイルを示します。

注意:
このリリースでは、DefaultReliability.xmlファイルとLongRunningReliability.xmlファイルは非推奨となっています。DefaultReliability1.1.xml、Reliability1.1_SequenceTransportSecurity、またはReliability1.0_1.1.xmlファイルを使用することをお薦めし、http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfであるWS-ReliableMessaging仕様の1.1バージョンに準拠する必要があります。

表3-5 あらかじめパッケージ化されているWS-Policyファイル

あらかじめパッケージ化されているWS-Policyファイル

説明

DefaultReliability1.1.xml

サービス品質に関連するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいています。DefaultReliability1.1.xml (WS-Policyファイル)に関する項を参照してください。

Reliability1.1_SequenceTransportSecurity

トランスポート・レベルのセキュリティとサービス品質に関連するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいています。Reliability1.1_SequenceTransportSecurity.xml (WS-Policyファイル)に関する項を参照してください。

Reliability1.0_1.1.xml

1.1と1.0のWS Reliable Messagingポリシー・アサーションを結合します。このサンプルは、適切なポリシーの選択に基づいて実行時に適用されるポリシー・アサーションを決定します。「Reliability1.0_1.1.xml (WS-Policy.xmlファイル)」を参照してください

DefaultRelibility.xml

非推奨。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion Version 1.0(http://schemas.xmlsoap.org/ws/2005/02/rm/WS-RMPolicy.pdf)に基づいています。このリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

信頼性のあるメッセージングのポリシーのアサーションに一般的な値(非アクティブ・タイムアウト10分、確認応答の間隔200ミリ秒、基本的な再送信間隔3秒など)を指定します。「DefaultReliability.xml (WS-Policyファイル) [非推奨]」を参照してください。

LongRunningReliability.xml

非推奨。長期実行プロセスに関して、Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion Version 1.0に基づいています。このリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

1つ前に示した、信頼性のあるメッセージングのデフォルトWS-Policyファイルとほぼ同じですが、アクティビティのタイムアウト間隔に、より大きな値(24時間)を指定する点が異なります。「LongRunningReliability.xml (WS-Policyファイル) [非推奨]」を参照してください。

WebLogic Serverに含まれる、あらかじめパッケージ化されている信頼性のあるメッセージングWS-Policyファイルの1つを使用できます。これらのファイルは、ほとんどの場合に適合しています。あらかじめパッケージ化されているファイルは変更できません。値がニーズを満たさない場合は、カスタムのWS-Policyファイルを作成する必要があります。以下の節で、カスタムWS-Policyファイルの作成方法を説明します。

- WS-ReliableMessagingポリシー・アサーション・バージョン1.1を使用したカスタムWS-Policyファイルの作成

- WS-ReliableMessagingポリシー・アサーション・バージョン1.0を使用したカスタムWS-Policyファイルの作成(非推奨)

- 複数のポリシー選択肢の使用

WS-ReliableMessagingポリシー・アサーション・バージョン1.1を使用したカスタムWS-Policyファイルの作成

この項では、WS Reliable Messaging Policy Assertion Version 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいたWebサービスの信頼性のあるメッセージングのアサーションを含むカスタムWS-Policyファイルを作成する方法について説明します。現在のリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

WS-Policyファイルのルート要素は<Policy>であり、次のネームスペース宣言が含まれている必要があります。

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

Webサービスの信頼性のあるメッセージングのポリシー・アサーションはすべて、<wsrmp:RMAssertion>要素の内部でラップします。この要素には、Webサービスの信頼性のあるメッセージングのポリシー・アサーションを使用するため、次のネームスペース宣言が含まれている必要があります。

<wsrmp:RMAssertion
xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">

次の表に、WS-Policyファイルで指定可能なWebサービスの信頼性のあるメッセージングのアサーションを示します。アサーションの指定順序は重要です。次のアサーションを指定できますが、WS-Policyファイルでは次の一覧の順序どおりに指定する必要があります。

表3-6 Webサービスの信頼性のあるメッセージング・アサーション(バージョン1.1)

アサーション

説明

<wsrmp:SequenceSTR>

信頼性のあるシーケンスでメッセージを保護するため、ランタイムはCreateSequenceメッセージで参照されるwsse:SecurityTokenReferenceを使用します。指定できるセキュリティ・アサーションは1つのみとなります。つまり、wsrmp:SequenceSTRまたはwsrmp:SequenceTransportSecurityのいずれか1つは指定できますが、両方は指定できません。

<wsrmp:SequenceTransportSecurity>

信頼性のあるシーケンスでメッセージを保護するため、ランタイムはCreateSequenceメッセージの送信に使用されるSSLトランスポート・セッションを使用します。このアサーションは、特定のトランスポート・レベル・セキュリティ・メカニズム(sp:HttpsTokenなど)の使用を要求するsp:TransportBindingアサーションとともに使用する必要があります。指定できるセキュリティ・アサーションは1つのみとなります。つまり、wsrmp:SequenceSTRまたはwsrmp:SequenceTransportSecurityのいずれか1つは指定できますが、両方は指定できません。

<wsrm:DeliveryAssurance>

Webサービスの配信保証レベル(配信品質)。有効な値は、AtMostOnce、AtLeastOnce、ExactlyOnceおよびInOrderです。次の表に定義されている配信保証レベルのいずれか1つを設定できます。設定しない場合、配信保証レベルはデフォルトのExactlyOnceが使用されます。

次の例では、簡単なWebサービスの信頼性のあるメッセージングのWS-Policyファイルを示します。

<?xml version="1.0"?>

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsrmp:RMAssertion
xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
<wsrmp:SequenceTransportSecurity/>
<wsrmp:DeliveryAssurance>
<wsp:Policy>
<wsrmp:ExactlyOnce/>
</wsp:Policy>
</wsrmp:DeliveryAssurance>
</wsrmp:RMAssertion>
</wsp:Policy>

WS-Policyファイルにおける信頼性のあるメッセージングのポリシー・アサーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

WS-ReliableMessagingポリシー・アサーション・バージョン1.0を使用したカスタムWS-Policyファイルの作成(非推奨)

この項では、WS Reliable Messaging Policy Assertion Version 1.0(http://schemas.xmlsoap.org/ws/2005/02/rm/WS-RMPolicy.pdf)に基づいたWebサービスの信頼性のあるメッセージングのアサーションを含むカスタムWS-Policyファイルを作成する方法について説明します。

注意:
現在のリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

WS-Policyファイルのルート要素は<Policy>です。Webサービスの信頼性のあるメッセージングのポリシー・アサーションを使用するには、これに次のネームスペース宣言が含まれていることが必要です。

<wsp:Policy
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:beapolicy="http://www.bea.com/wsrm/policy">

Webサービスの信頼性のあるメッセージングのポリシー・アサーションはすべて、<wsrm:RMAssertion要素の内部でラップします。wsrm:ネームスペースを使用するアサーションは、WS-ReliableMessaging仕様(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf)で定義される標準的なアサーションです。beapolicy:ネームスペースを使用するアサーションは、WebLogic固有のものです。詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

次の表に、WS-Policyファイルで指定可能なWebサービスの信頼性のあるメッセージングのアサーションを示します。Webサービスの信頼性のあるメッセージングのアサーションは、すべてオプションなので、デフォルト値が不適切なものだけを設定します。アサーションの指定順序は重要です。次のアサーションを指定できますが、WS-Policyファイルでは次のリストの順序どおりに指定する必要があります。

表3-7 Webサービスの信頼性のあるメッセージング・アサーション(バージョン1.0)

アサーション

説明

<wsrm:InactivityTimeout>

非アクティブ間隔を定義する、Milliseconds属性で指定されるミリ秒数。この時間が経過した時点で、宛先エンドポイントがソース・エンドポイントからのメッセージを受け取っていなければ、宛先エンドポイントは、処理が行われずシーケンスは終了したものと見なす場合があります。これは、ソース・エンドポイントについても同様のことが言えます。デフォルトでは、シーケンスがタイムアウトすることはありません。

<wsrm:BaseRetransmissionInterval>

ソース・エンドポイントがメッセージを送信してから、そのメッセージの確認応答を受け取っていない場合に再送信を行うまでの間隔(ミリ秒単位)。デフォルト値は、ソース・エンドポイントのWebLogic Serverインスタンス上のSAFエージェントによって設定されます。

<wsrm:ExponentialBackoff>

再送信の間隔が、指数関数的なバックオフ・アルゴリズムを使用して調整されることを指定します。この要素に属性はありません。

<wsrm:AcknowledgmentInterval>

宛先エンドポイントがスタンドアロンの確認応答を送信しなければならない最大間隔(ミリ秒単位)。デフォルト値は、宛先エンドポイントのWebLogic Serverインスタンス上のSAFエージェントによって設定されます。

<beapolicy:Expires>

信頼性のあるWebサービスの有効期限が切れ、これ以上の新しいシーケンス・メッセージを受け付けなくなるまでの時間の長さ。デフォルト値では、有効期限が切れることはありません。この要素には、Expiresという1つの属性があります。この属性のデータ型はXMLスキーマ期間型です。(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#durationを参照。)たとえば、有効期限までを1日と設定する場合は、<beapolicy:Expires Expires="P1D" />とします。

<beapolicy:QOS>

表3-9で説明されている、配信保証レベル。この要素にはQOSという1つの属性があり、この属性はAtMostOnce、AtLeastOnce、ExactlyOnceの各値のうちの1つに設定します。また、メッセージを順序通りにすることを指定するためにInOrder文字列を含めることもできます。デフォルト値はExactlyOnce InOrderです。この要素は通常、設定されません。

次の例では、簡単なWebサービスの信頼性のあるメッセージングのWS-Policyファイルを示します。

<?xml version="1.0"?>

<wsp:Policy
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:beapolicy="http://www.bea.com/wsrm/policy"
>

<wsrm:RMAssertion>

<wsrm:InactivityTimeout
Milliseconds="600000" />
<wsrm:BaseRetransmissionInterval
Milliseconds="500" />
<wsrm:ExponentialBackoff />
<wsrm:AcknowledgementInterval
Milliseconds="2000" />

</wsrm:RMAssertion>

</wsp:Policy>

WS-Policyファイルにおける信頼性のあるメッセージングのポリシー・アサーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

複数のポリシー選択肢の使用

カスタム・ポリシー・ファイルを作成することによって、単一のWebサービスに対して複数のポリシー選択肢(適切なポリシー選択肢)を構成できます。実行時には、適用されるポリシーがそれらの中から自動的に選択されます。その際は、サポートされていないポリシーやアサーションが競合しているポリシーが除外され、構成されているプリファレンスに基づいて、受信メッセージの検証とレスポンス・メッセージの構築に適したポリシーが選択されます。

次の例では、1.1と1.0 WSの信頼性のあるメッセージングの両方をサポートするセキュリティ・ポリシーの例を示します。各ポリシー選択肢は、<wsp:All>要素で囲まれています。

注意:
1.0のWebサービスの信頼性のあるメッセージング・アサーションには、接頭辞としてwsrmp10が付加されます。

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<wsrmp10:RMAssertion
xmlns:wsrmp10="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
<wsrmp10:InactivityTimeout Milliseconds="1200000"/>
<wsrmp10:BaseRetransmissionInterval Milliseconds="60000"/>
<wsrmp10:ExponentialBackoff/>
<wsrmp10:AcknowledgementInterval Milliseconds="800"/>
</wsrmp10:RMAssertion>
</wsp:All>
<wsp:All>
<wsrmp:RMAssertion
xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
<wsrmp:SequenceSTR/>
<wsrmp:DeliveryAssurance>
<wsp:Policy>
<wsrmp:AtMostOnce/>
</wsp:Policy>
</wsrmp:DeliveryAssurance>
</wsrmp:RMAssertion>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

複数のポリシー選択肢の詳細は、『Oracle WebLogic Server WebLogic Webサービスの保護』の「メッセージ・レベルのセキュリティの構成」、適切なポリシーの選択に関する項を参照してください。

信頼性のあるJWSファイルに関するプログラミングのガイドライン

この項では、信頼性のあるWebサービスを実装するJWSファイルの作成方法を説明します。

信頼性のあるWebサービスを実装するJWSファイルでは、次のJWSアノテーションが使用されます。

表3-8 信頼性のあるメッセージングのJWSアノテーション

アノテーション

説明

@weblogic.jws.Policy

必須。信頼性のあるメッセージングのアサーションが含まれるWS-PolicyファイルをWebサービスに追加するよう指定します。「@Policyアノテーションの使用」を参照してください。

@javax.jws.Oneway

信頼性のあるWebサービス操作を同期的に呼び出す(つまり、非同期リクエスト-レスポンスの機能は使用しない)場合にのみ必須です。「@Onewayアノテーションの使用」を参照してください。

@weblogic.jws.BufferQueue

オプション。WebLogic Serverが信頼性のあるメッセージを内部的に格納するために使用するJMSキューのJNDI名を指定します。「@BufferQueueアノテーションの使用」を参照してください。

@weblogic.jws.ReliabilityBuffer

オプション。WebLogic ServerによるJMSキューからWebサービス実装へのメッセージ配信試行回数、およびサーバーが待機すべき再試行間隔を指定します。「@ReliabilityBufferアノテーションの使用」を参照してください。

次のサンプルでは、信頼性のあるWebサービスを実装する簡単なJWSファイルを示します。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.reliable;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.Oneway;

import weblogic.jws.WLHttpTransport;

import weblogic.jws.ReliabilityBuffer;
import weblogic.jws.BufferQueue;
import weblogic.jws.Policy;

/**
* Simple reliable Web Service.
*/

@WebService(name="ReliableHelloWorldPortType",
serviceName="ReliableHelloWorldService")

@WLHttpTransport(contextPath="ReliableHelloWorld",
serviceUri="ReliableHelloWorld",
portName="ReliableHelloWorldServicePort")

@Policy(uri="ReliableHelloWorldPolicy.xml",
direction=Policy.Direction.both,
attachToWsdl=true)
@BufferQueue(name="webservices.reliable.queue")

public class ReliableHelloWorldImpl {

private static String onewaySavedInput = null;

/**
* A one-way helloWorld method that saves the given string for later
* concatenation to the end of the message passed into helloWorldReturn.
*/
@WebMethod()
@Oneway()
@ReliabilityBuffer(retryCount=10, retryDelay="10 seconds")

public void helloWorld(String input) {
System.out.println(" Hello World " + input);
onewaySavedInput = input;
}

/**
* This echo method concatenates the saved message from helloWorld
* onto the end of the provided message, and returns it.
*/
@WebMethod()
@ReliabilityBuffer(retryCount=10, retryDelay="10 seconds")

public String echo(String input2) {
System.out.println(" Hello World " + input2 + onewaySavedInput);
return input + onewaySavedInput;
}
}

この例では、カスタムReliableHelloWorldPolicy.xmlポリシー・ファイルがクラス・レベルでWebサービスに追加されています。つまり、ポリシー・ファイルはWebサービスのすべてのパブリック操作に適用されます。ポリシー・ファイルは、リクエストWebサービス・メッセージ(信頼性のあるメッセージング機能によって要求される)のみに適用され、WSDLファイルに追加されます。あらかじめパッケージ化されている利用可能なポリシーおよびカスタム・ポリシーの作成の詳細につぃては、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。

WebLogic Serverが、Webサービスの信頼性のあるメッセージングを有効化するために内部で使用するJMSキューのJNDI名は、@BufferQueueアノテーションで指定されているように、webservices.reliable.queueです。

helloWorld()メソッドは、@WebMethodと@Oneway、どちらのJWSアノテーションでもマークされています。これは、このメソッドがhelloWorldというパブリック操作であるということです。@Policyアノテーションがあるために、操作を確実に呼び出すことができます。@ReliabilityBufferアノテーションに記述されているとおり、Webサービスのランタイムでは、最大で10回、10秒間隔で、信頼性のあるメッセージをサービスに配信しようとします。たとえば、トランザクションがロールバックされる場合や、コミットしない場合などには、メッセージの再配信が必要となることがあります。

echo()メソッドは、@WebMethodとJWSアノテーションでもマークされています。これは、このメソッドがechoというパブリック操作であるということです。@Policyアノテーションがあるために、操作を確実に呼び出すことができます。helloWorld()メソッドと同じような信頼性バッファ構成を使用します。

@Policyアノテーションの使用

信頼性のあるメッセージングのアサーションが含まれるWS-PolicyファイルをWebサービスに追加するよう指定するには、JWSファイルで@Policyアノテーションを使用します。WebLogic Serverでは、あらかじめパッケージ化されているWS-Policyファイルのセットが提供されます。付録A「信頼性のあるメッセージング用にパッケージ化されているWS-Policyファイル」を参照してください。

Webサービスの信頼性のあるメッセージングで@Policyアノテーションを使用する場合は、次のガイドラインに従います。

- uri属性を使用して、ポリシー・ファイルのビルド時の場所を以下のように指定します。

- 独自のWS-Policyファイルを作成した場合は、JWSファイルを基準として相対的に場所を指定します。例:

@Policy(uri="ReliableHelloWorldPolicy.xml",
direction=Policy.Direction.both,
attachToWsdl=true)

この例では、ReliableHelloWorldPolicy.xmlファイルがJWSファイルと同じディレクトリに置かれています。

- あらかじめパッケージ化されているWS-Policyファイルの1つか、共有Java EEライブラリにパッケージ化されているWS-Policyファイルを指定するには、そのポリシー・ファイルの名前とパスとともにpolicy:接頭辞を使用します。この構文ではビルド時のjwsc Antタスクに、ファイル・システムの実際のファイルを探させず、Webサービスが、サービスのデプロイ時にWebLogic ServerからWS-Policyファイルを取得することを通知しています。

注意:
共有Java EEライブラリは、様々なエンタープライズ・アプリケーション内にパッケージ化されている複数のWebサービスとWS-Policyファイルを共有する場合に有用です。WS-Policyファイルが共有Java EEライブラリのMETA-INF/policiesまたはWEB-INF/policiesディレクトリに置かれているかぎり、ポリシー・ファイルはWebサービスの同じアーカイブにパッケージ化されている場合と同様に指定できます。ライブラリの作成、およびWebサービスがポリシー・ファイルを見つけることができるようにするための環境設定については、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

- ポリシー・ファイルをWeb上で公開するよう指定するには、次の例に示すとおり、URLと共にhttp:接頭辞を使用します。

@Policy(uri="http://someSite.com/policies/mypolicy.xml"
direction=Policy.Direction.both,
attachToWsdl=true)

- デフォルトでは、WS-Policyファイルはリクエスト(着信)とレスポンス(発信)の両方のSOAPメッセージに適用されます。このデフォルトの動作は、direction属性をPolicy.Direction.inboundまたはPolicy.Direction.outboundに設定すると変更できます。

- uriで指定されるポリシー・ファイル内でwsp:optional属性を使用し、Webサービスで操作が確実に呼び出され、そのレスポンスが確実に配信されるよう要求するかどうかを指定できます。
任意の操作での発信に対してoptional属性をfalseに設定する場合:

- クライアントは、信頼性のあるレスポンスを送信する時使用できるようにofferシーケンスを提供する必要があります。(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfにあるWS-ReliableMessaging仕様で説明されている<wsrm: Offer...>)

- レスポンスが必要なすべての操作に対してレスポンスが確実に送信されます。

すべての操作での発信に対してoptional属性をtrueに設定する場合:

- クライアントはofferシーケンスを提供する必要がありません。

- クライアントがofferシーケンスを提供する場合、レスポンスは確実に送信され、提供しない場合、レスポンスの送信には信頼性がありません。

- @PolicyアノテーションのattachToWsdl属性を設定して、ポリシー・ファイルをWebサービスのパブリック規約が記述されたWSDLファイルに付加するかどうかを指定できます。通常は、クライアント・アプリケーションでWebサービスの信頼性のあるメッセージング機能が認識されるよう、パブリックなものとしてポリシーを公開します。そのため、この属性のデフォルト値はtrueです。

@Policyアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.Policyに関する項を参照してください。

@Onewayアノテーションの使用

信頼性のあるWebサービス操作を同期的に呼び出す(すなわち、非同期リクエスト-レスポンス機能を使用しない)場合は、実装メソッドに@Onewayアノテーションを付けて、そのメソッドが一方向のものであることを指定する必要があります。つまり、メソッドは値を戻すことができず、明示的にvoidを戻すことになります。

反対に、メソッドに@Onewayアノテーションが付いていなければ、非同期リクエスト-レスポンス機能を使用して呼び出す必要があります。操作の呼出し方法がわからない場合は、同期と非同期の2種類の操作を作成することを検討してください。

第2章「非同期リクエスト-レスポンスを使用したWebサービスの呼出し」と第6章「非同期機能の併用」を参照してください。

@BufferQueueアノテーションの使用

信頼性のあるメッセージを内部に格納するためにWebLogic Serverが使用するJMSキューのJNDI名を指定するには、@BufferQueueアノテーションを使用します。JNDI名は、「宛先WebLogic Serverインスタンスの構成」のステップ4でのJMSキューの作成時に構成したものです。

@BufferQueueアノテーションは、省略可能です。これをJWSファイルで指定しなければ、WebLogic Serverはweblogic.wsee.DefaultQueueのJNDI名を持つキューを使用します。ただし、それでもこのJNDI名を持つJMSキューを管理コンソールで明示的に作成する必要はあります。

@BufferQueueアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.BufferQueueに関する項を参照してください。

@ReliabilityBufferアノテーションの使用

@ReliabilityBufferアノテーションは、WebLogic ServerによるJMSキューからWebサービス実装へのメッセージ配信試行回数、およびサーバーが待機すべき再試行間隔の指定に使用します。

再試行回数の指定にはretryCount属性を、待機時間の指定にはretryDelay属性を使用します。retryDelay属性の形式としては、数字の後に以下の文字列のうち1つを続けます。

- seconds

- minutes

- hours

- days

- years

たとえば、再試行回数を20、再試行の遅延を2日と指定するには、次の構文を使用します。

@ReliabilityBuffer(retryCount=20, retryDelay="2 days")

再試行の回数と遅延のデフォルト値はそれぞれ、3と5です。

@ReliabilityBufferアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.ReliabilityBufferに関する項を参照してください。

信頼性のあるWebサービスの信頼性のあるメッセージングの構成

必要に応じて、アプリケーションのデプロイメント・プランを更新し、weblogic-webservices.xml記述子に格納される、信頼性のあるWebサービスの信頼性のあるメッセージ構成オプションを編集することができます。新しい値は、デプロイメント・プランにより、現在のアプリケーションの記述子における特定の場所に関連付けられます。デプロイメント時に、デプロイメント・プランは変数割当ての値を、その変数のリンク先アプリケーション記述子内の場所に適用することによって、そのアプリケーション内の記述子に結合されます。

次の表では、信頼性のあるWebサービス用に構成できる信頼性のあるメッセージングのオプションを説明しています。

表3-9 信頼性のあるメッセージングの構成オプション

構成オプション

説明

信頼性のあるメッセージ構成のカスタマイズ

Webサービス・エンドポイント・レベルにおけるWebサービス記述子またはデプロイメント・プランで定義された信頼性のあるメッセージ構成をカスタマイズするかどうかを指定するフラグ。このフラグは、Webサービス・エンドポイント・レベルで信頼性のあるメッセージングを構成する場合にのみ使用できます。チェックされない場合、WebLogic Serverに指定された信頼性のあるメッセージ構成が使用されます。

注意:このフラグは、直接WSDLに指定されるWS-RMポリシーなどの他の形式では、信頼性のあるメッセージングの構成を反映しません。

基本の再送信間隔

RM宛先にメッセージの再送信を行うまでの時間間隔。

ソース・エンドポイントは指定時間内にメッセージの確認応答を受け取らなかった場合、そのメッセージを再送信します。ソース・エンドポイントは、メッセージのシーケンスの存続期間内の任意の時点で、この再送信間隔を変更することがあります。

この要素を「再送信間隔の指数関数的バックオフ」要素と組み合せて使用すると、再送信間隔を調整するアルゴリズムを指定できます。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT3S (3秒)。

再送信間隔の指数関数的バックオフの有効化

メッセージの再送信の間隔を、指数関数的なバックオフ・アルゴリズムを使用して調整するかどうかを示すフラグ。

この要素は「基本の再送信間隔」要素と組み合せて使用します。宛先エンドポイントが、「基本の再送信間隔」で指定した時間内でメッセージのシーケンスを確認応答しなかった場合、メッセージが引続き確認されなければ、連続再送信のタイミングに対して、ソース・エンドポイントは指数関数的なバックオフ・アルゴリズムを使用します。

指数関数的なバックオフ・アルゴリズムは、連続再送信の間隔が、基本の再送信間隔を基に指数的に増えるように指定します。たとえば、基本の再送信間隔が2秒で、指数関数的なバックオフ要素が設定されている場合、連続再送信の間隔は、メッセージが確認されなければ、2、4、8、16、32秒というように増えていきます。

デフォルト値はfalseであり、連続再送信の間隔は指数的に増えず、同じ値が維持されます。

確認応答の間隔

宛先エンドポイントがスタンドアロンの確認応答を送信しなければならない最大間隔。

宛先エンドポイントは、ソース・エンドポイントからメッセージを受信した直後に、返されたメッセージに対する確認応答を送信できます。また、スタンドアロンの確認応答として個別に確認応答を送信することもできます。返されたメッセージに対して確認応答を送信できない場合、宛先エンドポイントは、スタンドアロンの確認応答を送信するまで、確認応答の間隔に設定した時間範囲内で待機することがあります。未確認のメッセージがない場合、宛先エンドポイントは確認応答を送信しない場合があります。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT0.2S (200ミリ秒)。

非アクティブ・タイムアウト

非アクティブの間隔。非アクティブ・タイムアウト間隔で、エンドポイント(RM送信元とRM宛先)がアプリケーションのメッセージまたは制御メッセージを受け取らなければ、エンドポイントはRMシーケンスが非アクティブなため終了したものと見なす場合があります。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT600S (600秒)。

順序の有効期限

アクティビティにかかわらず、シーケンスが期限切れになるまでの時間。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP1D (1日)。

バッファの再試行回数

信頼性のあるリクエストを再試行する回数。この値のデフォルトは3。

バッファの再試行遅延

信頼性のあるリクエストを再試行するまでの待機時間。

再試行はJMSキュー上のクライアントのリクエスト・メッセージとWebサービス実装へのメッセージ配信の間で行われます。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT5S (5秒)。

信頼性のあるメッセージング構成オプションは、管理コンソールやWLSTを使用して設定できます。以降の節を参照してください。

- 管理コンソールを使用する

- WLSTの使用

管理コンソールを使用する

管理コンソールを使用してWebサービス・エンドポイント用の信頼性のあるメッセージングを構成するには:

1. 『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』の管理コンソールの起動に関する項の説明に従って、管理コンソールを起動します。

2. 左側のナビゲーション・ペインで、「デプロイメント」を選択します。

3. 「デプロイメント」表でWebサービスの名前をクリックします。

4. 「構成」タブ、「ポート」タブの順に選択します。

5. 「ポート」表でWebサービスのエンドポイントの名前をクリックします。

6. 「信頼できるメッセージ」タブを選択します。

7. 「信頼性のあるメッセージ構成のカスタマイズ」をクリックし、必要に応じて、デプロイメント・プランを保存する手順を実行します。

8. 必要に応じて、信頼性のあるメッセージングのプロパティを設定します。

9. 「保存」をクリックします。

WLSTの使用

アプリケーションのデプロイメント・プランを更新して信頼性のあるメッセージングを構成する方法の詳細と例は、『Oracle WebLogic Scripting Tool』のデプロイメント・プランの更新に関する項を参照してください。

以下の表に、WS-RM構成オプションのXPath値を参考としてまとめます。

表3-10 WS_RM構成変数名とXPath値

構成オプション

変数名の例

XPath値

非アクティブ・タイムアウト

ReliabilityConfig_
InactivityTimeout

/weblogic-webservices/webservice-description/
[webservice-description-name="
service_name"]/port-component/
[port-component-name="port_name"]
/reliability-config/inactivity-timeout

基本の再送信間隔

ReliabilityConfig_
BaseRetransmission
Interval

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/base-retransmission-interval

再送信間隔の指数関数的バックオフ

ReliabilityConfig_
Retransmission
ExponentialBackoff

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]/reliability-
config/retransmission-exponential-backoff

確認応答の間隔

ReliabilityConfig_
AcknowledgementInterval

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/acknowledgement-interval

シーケンスの有効期限

ReliabilityConfig_
SequenceExpiration

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/sequence-expiration

バッファの再試行回数

ReliabilityConfig_
BufferRetryCount

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/buffer-retry-count

バッファの再試行遅延

ReliabilityConfig_
BufferRetryDelay

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/buffer-retry-delay

信頼性のあるWebサービスを呼び出すJWSファイルに関するプログラミングのガイドライン

WebLogicクライアントAPIを使用している場合は、信頼性のあるWebサービスをWebサービス内から呼び出す必要があります。スタンドアロンのクライアント・アプリケーションからは呼び出せません。

次の例では、「信頼性のあるJWSファイルに関するプログラミングのガイドライン」で説明した、サービスから信頼性のある操作を呼び出すWebサービス用の簡単なJWSファイルを示します。

package examples.webservices.reliable;

import java.rmi.RemoteException;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.xml.rpc.Stub;
import weblogic.jws.WLHttpTransport;
import weblogic.jws.ServiceClient;
import weblogic.jws.ReliabilityErrorHandler;

import weblogic.jws.AsyncFailure;
import weblogic.jws.AsyncResponse;

import examples.webservices.reliable.ReliableHelloWorldPortType;

import weblogic.wsee.reliability.ReliabilityErrorContext;
import weblogic.wsee.reliability.ReliableDeliveryException;
import weblogic.wsee.reliability.WsrmUtils;

@WebService(name="ReliableClientPortType",
serviceName="ReliableClientService")

@WLHttpTransport(contextPath="ReliableClient",
serviceUri="ReliableClient",
portName="ReliableClientServicePort")

public class ReliableClientImpl
{
private static String responseMessage = null;

@ServiceClient(
serviceName="ReliableHelloWorldService",
portName="ReliableHelloWorldServicePort")

private ReliableHelloWorldPortType port;

@WebMethod
public void callHelloWorld(String input, String input2, String serviceUrl)
throws RemoteException {

((Stub)port)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, serviceUrl);

port.helloWorld(input);

System.out.println(" Invoked the ReliableHelloWorld.helloWorld operation reliably." );
WsrmUtils.setFinalMessage((Stub)port);
port.echo(input2);
System.out.println(" Invoked the ReliableHelloWorld.echo operation reliably." );
}

@AsyncResponse(target = "port", operation = "echo")
public void onEchoAsyncResponse(String msg) {

System.out.println("ClientService: Got async response for request : " + msg);
responseMessage = msg;
}

@AsyncFailure(target = "port", operation = "echo")
public void onEchoAsyncFailure(Throwable t) {
System.out.println("ClientService: Got async FAILURE for request : " + t);
t.printStackTrace();
}

@ReliabilityErrorHandler(target="port")
public void onReliableMessageDeliveryError(ReliabilityErrorContext ctx) {

ReliableDeliveryException fault = ctx.getFault();
String message = null;
if (fault != null) {
message = ctx.getFault().getMessage();
}
String operation = ctx.getOperationName();
System.out.println("Reliable operation " + operation + " may have not invoked. The error message is " + message);
}

}

信頼性のあるWebサービスを呼び出すJWSファイルをプログラミングする際は、次のガイドラインに従います。ガイドラインのサンプル・コードは、前述のサンプル内では太字で示されています。

- @ServiceClientおよび@ReliabilityErrorHandler JWSアノテーションをインポートします。

import weblogic.jws.ServiceClient;
import weblogic.jws.ReliabilityErrorHandler;

- エラー(信頼性のあるWebサービスから受信したメッセージの確認応答をクライアントWebサービスで受信していない場合に発生するエラー)を処理するメソッド内で使用するWebLogic APIをインポートします。

import weblogic.wsee.reliability.ReliabilityErrorContext;
import weblogic.wsee.reliability.ReliableDeliveryException;

- 非同期のレスポンスおよび障害のために使用するAPIをインポートします。

import weblogic.jws.AsyncFailure;
import weblogic.jws.AsyncResponse;

- 呼び出す信頼性のあるWebサービスのポート・タイプのJAX-RPCスタブをインポートします。このスタブは、jwsc Antタスクの<clientgen>子要素によって後から作成されます。スタブ・パッケージは、<clientgen>のpackageName属性によって指定され、スタブの名前は呼び出されたWebサービスのWSDLによって決まります。

import examples.webservices.reliable.ReliableHelloWorldPortType;

- ライフサイクル管理に使用されるAPIをインポートします(あとでプロパティを設定し、最終メッセージを指定するため)。

import javax.xml.rpc.Stub;
import weblogic.wsee.reliability.WsrmUtils;

- JWSファイルの本文で、@ServiceClient JWSアノテーションを使用して、呼び出す信頼性のあるWebサービスの名前とポートを指定します。このアノテーションは、プライベート変数のフィールド・レベルで指定します。この変数のデータ型は、呼び出しているWebサービスのJAX-RPCポート・タイプとなります。

@ServiceClient(
serviceName="ReliableHelloWorldService",
portName="ReliableHelloWorldServicePort")

private ReliableHelloWorldPortType port;

- port._setPropertyメソッドを使用して、ターゲットとなるサービス・エンドポイント・アドレスをWebサービス・クライアント内で動的に指定します。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービスの実行時情報へのアクセスに関する項を参照してください。

((Stub)port)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, serviceUrl);

- @ServiceClientアノテーションを付けたスタブを使用して、信頼性のある操作helloWorldを呼び出します。

port.helloWorld(input);

操作は一方向のものとしてマークされているので、値は返しません。

- エラー(信頼性のあるWebサービスが受信したメッセージの確認応答をクライアントWebサービスで受信していない場合に発生するエラー)を処理するメソッドを作成し、@weblogic.jws.ReliabilityErrorHandlerアノテーションを付けます。

@ReliabilityErrorHandler(target="port")
public void onReliableMessageDeliveryError(ReliabilityErrorContext ctx) {
ReliableDeliveryException fault = ctx.getFault();
String message = null;
if (fault != null) {
message = ctx.getFault().getMessage();
}
String operation = ctx.getOperationName();
System.out.println("Reliable operation " + operation + " may have not invoked. The error message is " + message);
}

このメソッドは、唯一のパラメータとしてReliabilityErrorContextを取り、voidを返します。

このエラー処理メソッドのプログラミングの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.ReliabilityErrorHandlerに関する項を参照してください。

- サービスは会話型ではないため、ポート・フィールドに保持されている状態は、このメソッドが戻されると失われます。信頼性のあるメッセージングの場合、この状態には、メッセージの送信に使用されている信頼性のあるシーケンスのIDが含まれます。setFinalMessageメソッドは、このメッセージがこのシーケンスで送信される最終メッセージであることを指定します。これにより、信頼性のあるメッセージング・サブシステムは、信頼性のあるシーケンスをタイムアウトさせる前にクリーンアップすることができます。

WsrmUtils.setFinalMessage((Stub)port);

- @ServiceClientアノテーションを付けたスタブを使用して、信頼性のある操作echoを呼び出します。

port.echo(input2);

- 非同期レスポンスまたは障害を処理するメソッドを作成します。@weblogic.jws.AsyncResponseと@weblogic.jws.AsyncFailureアノテーションを使用します。

@AsyncResponse(target = "port", operation = "echo")
public void onEchoAsyncResponse(String msg) {
System.out.println("ClientService: Got async response for request : " + msg);
responseMessage = msg;
}

@AsyncFailure(target = "port", operation = "echo")
public void onEchoAsyncFailure(Throwable t) {
System.out.println("ClientService: Got async FAILURE for request : " + t);
t.printStackTrace();
}

非同期のレスポンスおよび障害のメソッドの生成方法については、「非同期のJWSファイルの記述」を参照してください。

クライアントWebサービスをプログラミングする際、次のガイドラインに従います。

- 関連付けられたWS-Policyファイル内で、信頼性のあるメッセージング・アノテーション(ただし@ReliabilityErrorHandlerを除く)を指定したり、信頼性のあるメッセージング・アサーションを使用しません。

- @ServiceClientアノテーションのwsdlLocation属性を指定しません。これは、指定したWSDLの実行時の取得に失敗する可能性があり、ローカルのWSDLファイルが使用されるようにしておいたほうがよいためです。

信頼性のあるWebサービスのクライアント用build.xmlファイルの更新

build.xmlファイルを更新し、信頼性のあるWebサービス操作を呼び出すJWSファイルを生成するには、次のようなtaskdefおよびbuild-reliable-clientターゲットを追加します。

<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />

<target name="build-reliable-client">

<jwsc
enableAsyncService="true"
srcdir="src"
destdir="${client-ear-dir}" >

<jws file="examples/webservices/reliable/ReliableClientImpl.java">

<clientgen
wsdl="http://${wls.destination.host}:${wls.destination.port}/ReliableHelloWorld/ReliableHelloWorld?WSDL"
packageName="examples.webservices.reliable"/>

</jws>

</jwsc>

</target>

jwsc Antタスクの完全なクラス名を定義するには、taskdef Antタスクを使用します。

クライアントWebサービスをコンパイルするjwsc Antタスクを更新して、<jws>要素の<clientgen>子要素を含めます。これにより、デプロイされたReliableHelloWorld WebサービスのJAX-RPCスタブが生成およびコンパイルされるようになります。jwsc Antタスクでは、これらのスタブが生成されたWARファイルに自動的にパッケージ化されるため、即座にクライアントWebサービスからアクセスできるようになります。このようにするのは、生成されたクラスの1つをReliableClientImpl JWSファイルでインポートして使用するためです。

信頼性のあるメッセージングとMTOMの使用

次に、信頼性のあるWebサービスを実装し、MTOM/XOPを使用してSOAPメッセージ内のxs:base64Binary型のXMLデータの転送を最適化する簡単なJWSファイルの例を示します。コーディング・ガイドラインとして、サンプル・コードの後の説明を参照してください。このガイドラインはJavaコード内の太字部分に対応しています。このサンプルは、「信頼性のあるWebサービスを呼び出すJWSファイルに関するプログラミングのガイドライン」のサンプルを元に作成しています。

package examples.webservices.reliable;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.Oneway;
import weblogic.jws.WLHttpTransport;

import weblogic.jws.ReliabilityBuffer;
import weblogic.jws.BufferQueue;
import weblogic.jws.Policy;
import weblogic.jws.Policies;

/**
* Simple reliable Web Service.
*/

@WebService(name="ReliableHelloWorldPortType",
serviceName="ReliableHelloWorldService")

@WLHttpTransport(contextPath="ReliableHelloWorld",
serviceUri="ReliableHelloWorld",
portName="ReliableHelloWorldServicePort")

@Policies({@Policy(uri="ReliableHelloWorldPolicy.xml",
direction=Policy.Direction.both,
attachToWsdl=true),
@Policy(uri = "policy:Mtom.xml")})

@BufferQueue(name="webservices.reliable.queue")

public class ReliableHelloWorldImpl {

@WebMethod()
@Oneway()
@ReliabilityBuffer(retryCount=10, retryDelay="10 seconds")

public void helloWorld(String input) {
System.out.println(" Hello World " + input);

}

@WebMethod

public byte[] echoBinary(byte[] bytes) {
return bytes;
}
}

MTOMを使用して信頼性のあるWebサービスを呼び出すJWSファイルをプログラミングする際は、次のガイドラインに従います。ガイドラインのサンプル・コードは、前述のサンプル内では太字で示されています。

- あらかじめパッケージ化されているMtom.xmlファイルを現在のWebサービスに適用するには、@weblogic.jws.Policyアノテーションを使用します。複数のWS-Policyファイル(信頼性のあるメッセージング・ポリシー・ファイルやMTOMポリシー・ファイルを含む)をグループ化するには、@weblogic.jws.Policiesアノテーションを使用します。

@Policies({@Policy(uri="ReliableHelloWorldPolicy.xml",
direction=Policy.Direction.both,
attachToWsdl=true),
@Policy(uri = "policy:Mtom.xml")})

- 結果として得られるSOAPメッセージでMTOM/XOPを使用してバイナリ・データの送受信を行う場合は必ず、Webサービス操作でJava byte[]データ型を戻り値または入力パラメータとして使用します。

public byte[] echoBinary(byte[] bytes) {
return bytes;
}

注意:
このリリースのWebLogic Serverでは、MTOM/XOP使用時にサポートされるJavaデータ型はbyte[]のみです。その他のバイナリ・データ型(imageなど)はサポートされていません。

信頼性のあるWebサービスを再デプロイする際にクライアント側で考慮すべき事項

WebLogic Serverでは、本番再デプロイメントがサポートされています。つまり、信頼性のあるWebLogic Webサービスの更新後の新しいバージョンを、同じWebサービスの古いバージョンと並行してデプロイできます。

WebLogic Serverでは、新しいクライアントのリクエストのみが新しいバージョンに転送されるように、クライアント接続が自動的に管理されます。再デプロイメント時にすでにWebサービスに接続していたクライアントは、作業が完了するまで古いバージョンのサービスを使用し続け、それらの作業が完了した時点で、WebLogic Serverが古いWebサービスを自動的にリタイアします。クライアントが信頼性のあるWebサービスに接続されている場合は、既存の信頼性のあるメッセージ・シーケンスがクライアントによって明示的に終了されるか、またはタイムアウトになったときに、そのクライアントの作業が完了したと見なされます。

本番再デプロイメントとWebサービス・クライアントの詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービスを再デプロイする際にクライアントで考慮すべき事項に関する項を参照してください。

信頼性のあるメッセージングとプロキシ・サーバーの使用

信頼性のあるWebサービスを呼び出すクライアント・アプリケーションでは、直接操作を呼び出すのではなく、プロキシ・サーバーを使用することがあります。プロキシを使用する理由としては、ファイアウォールの存在や、呼び出されたWebサービスのクラスタへのデプロイメントなどがあります。

この場合、呼び出されたWebサービスをホストするWebLogic Serverインスタンスは、プロキシ・サーバーのアドレスとポートで構成する必要があります。Webサービスがクラスタにデプロイされている場合は、そのクラスタ内のすべてのサーバーを構成することが必要です。

この手順では、ネットワーク接続を管理するための構成可能なWebLogic Serverの主要リソースであるネットワーク・チャネルの作成方法について説明します。ネットワーク・チャネルにより、クラスタのフロントエンド・アドレスにアクセスするための一貫性のある方法を提供できます。ネットワーク・チャネルの詳細は、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・チャネルの理解に関する項を参照してください。

各サーバー・インスタンスについて、以下の手順を実行します。

1. Webサービスの呼出しに使用するプロトコル用のネットワーク・チャネルを作成します。ネットワーク・チャネルの名前は、weblogic-wsee-proxy-channel-XXXとする必要があります(XXXはプロトコルを表します)。たとえば、HTTPS用のネットワーク・チャネルを作成する場合、weblogic-wsee-proxy-channel-httpsという名前にします。
ネットワーク・チャネルの作成に関する一般情報は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください。

2. 「外部リスニング・アドレス」および「外部リスニング・ポート」フィールドを、それぞれプロキシ・サーバーのアドレスおよびポートで更新して、ネットワーク・チャネルを構成します。

3. -Dweblogic.wsee.skip.async.response=true Javaシステム・プロパティを使用してWebLogic Serverインスタンスを起動することによって、WebLogic Serverプロキシ・サーバー上の非同期レスポンス・サービスを無効にします。
デフォルトでは、すべてのWebLogic Serverインスタンスに、非同期リクエスト-レスポンス機能を処理する内部非同期Webサービスがデプロイされます。このシステム・プロパティを指定しない場合、プロキシ・サーバー上の非同期サービスが非同期メッセージを消費するため、非同期メッセージは要求したとおりにクラスタに到着しません。

4 会話型Webサービスの作成

この章では、会話型のWebLogic Java API for XML-based RPC (JAX-RPC) Webサービスの作成方法について説明します。

この章では、以下のトピックについて説明します。

- 会話型Webサービスの概要

- 会話型Webサービスの作成: 主な手順

- 会話型JWSファイルに関するプログラミングのガイドライン

- 会話型Webサービスを呼び出すJWSファイルに関するプログラミングのガイドライン

- ConversationUtilsユーティリティ・クラス

- 会話型Webサービスのクライアント用build.xmlファイルの更新

- 会話型Webサービスを呼び出すためのスタンドアロンJavaクライアントの更新

- 会話型Webサービスの.NETクライアントの例

- 会話型Webサービスを再デプロイする際にクライアント側で考慮すべき事項

会話型Webサービスの概要

Webサービスと、そのWebサービスを呼び出すクライアント・アプリケーションは、1つのタスクを完了するために複数回通信する場合があります。また、複数のクライアント・アプリケーションが同時に同じWebサービスと通信する場合もあります。会話を使用すると、直接的な方法で、呼出し間のデータを追跡して、Webサービスが常に正しいクライアントに応答するようにできます。

会話を使用すると、複数の通信にわたってデータを維持することに伴う以下の2つの問題が解決されます。

- 会話では、1つのクライアント・アプリケーションと1つのWebサービスの間の双方向通信が一意に識別されるので、メッセージが常に正しいクライアントに戻されます。たとえば、ショッピング・カート・アプリケーションでは、どのショッピング・カートがどの顧客に属するかを会話型Webサービスが追跡します。会話型Webサービスでは、クライアント・アプリケーションとの間で新しい会話が始まるたびに、一意の会話IDを作成することによって、これを実現しています。

- 会話によってWebサービスへの呼出し間の状態を保持します。つまり、サービスに対する呼出し間の特定のクライアント・アプリケーションに関連付けられているデータを追跡します。会話を使用すると、特定のクライアントに関連付けられているデータは、必要がなくなるまで、または処理が完了するまで、確実に保存されます。たとえば、ショッピング・カート・アプリケーションでは、顧客がショッピングを続けている間、ショッピング・カートに入っている品物を会話型Webサービスが記憶します。状態の保持はまた、会話中にWebサービスをホストするコンピュータで発生した障害に対処するためにも必要です。すべての状態関連データがディスクに永続化されるので、コンピュータが再起動すれば、クライアント・アプリケーションとの会話を続行できます。

WebLogic Serverはこの一意のIDと状態を、クライアント・アプリケーションが新しく会話を開始するたびに会話コンテキストを作成することによって管理します。Webサービスがその後、このコンテキストを使用して、サービスとの間の呼出しを相関させ、状態関連データを永続化します。

クライアント・アプリケーションとWebサービスの間の会話には、3つの異なるフェーズがあります。

- 開始: クライアント・アプリケーションが、会話型Webサービスの開始操作を呼び出すことによって、会話を開始します。次にそのWebサービスが、新しい会話コンテキストおよびそれに伴う一意のIDを作成し、アイドル時間と会話の存続期間を計測する内部タイマーを起動します。

- 続行: クライアント・アプリケーションは会話を開始した後、1つ以上の続行操作を呼び出して会話を続行します。会話型Webサービスでは、呼出しに関連付けられたIDを使用して、会話しているクライアント・アプリケーション、永続化する状態、およびリセットするアイドル・タイマーを判断します。通常の続行操作は、クライアント・アプリケーションからさらに情報をリクエストするものや、ステータスをリクエストするものなどです。

- 終了: クライアント・アプリケーションは、会話が終了すると明示的に終了操作を呼び出します。Webサービスがその後、その会話と関連付けられたすべてのデータまたはリソースを、削除済としてマークします。

会話は通常、2つのWebLogic Webサービス間で発生します。そのうち1つは会話型としてマークされ、開始、続行、および終了の操作を定義し、もう1つのWebサービスは@ServiceClientアノテーションを使用して、それが会話型Webサービスのクライアントであることを指定します。また、制限事項はありますが、会話型WebサービスはスタンドアロンJavaクライアントからも呼び出せます。

他のWebLogic Webサービスの機能と同様に、Webサービスを会話型のものとして指定するには、JWSアノテーションを使用します。

注意:
会話型Webサービスを呼び出すクライアントWebサービスは、必ずしも会話型にする必要はありません。ただし、クライアントが会話型でない場合は、このクライアントの複数のインスタンスが同じ会話型Webサービス・スタブにアクセスする危険性があり、保存されている会話状態が破損するおそれがあります。この危険性があると判断した場合は、クライアントWebサービスも会話型になるように指定してください。その場合は、スタンドアロンのJavaクライアントは使用できません。これは、WebLogic APIを使用して会話型であることを指定する方法がないためです。
会話型Webサービス自体は、必ず1回、メッセージの配信が行われることや、メッセージが順序どおりに配信されることを保証するものではありません。そのようなメッセージ配信保証が必要であれば、Webサービスに信頼性があることも指定する必要があります。「Webサービスの信頼性のあるメッセージングの使用: 主な手順」および「非同期機能の併用」を参照してください。

会話型Webサービスの作成: 主な手順

次の手順では、会話型Webサービス、ならびにクライアントWebサービスおよびスタンドアロンJavaクライアント・アプリケーション(いずれも会話を開始および実施するもの)を作成する方法について説明します。この手順では、2つのWebサービスを実装するJWSファイルをゼロから作成する方法を示しています。既存のJWSファイルを更新する場合は、この手順をガイドとして利用することもできます。

Antベースの開発環境を設定済であり、かつjwsc Antタスクを実行して生成された会話型Webサービスをデプロイするためのターゲットを追加できる、作業用のbuild.xmlファイルがあることが前提となっています。さらに、会話を開始するクライアントWebサービスをホストする、WebLogic Serverインスタンスを同様に設定してあることも前提となっています。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』の次の項を参照してください。

- 使用例とサンプル

- WebLogic Webサービスの開発

- JWSファイルのプログラミング

- Webサービスの呼出し

表4-1 会話型Webサービスの作成手順

#

手順

説明

1

会話型Webサービスを実装する、新しいJWSファイルを作成するか、既存のJWSファイルを更新します。

使い慣れたIDEまたはテキスト・エディタを使用します。「会話型JWSファイルに関するプログラミングのガイドライン」を参照してください。

2

build.xmlファイルを更新して、会話型JWSファイルをWebサービスにコンパイルするjwsc Antタスクの呼出しを含めます。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のjwsc WebLogic WebサービスAntタスクの実行に関する項を参照してください。

3

Antターゲットを実行して、会話型Webサービスをビルドします。

例:

prompt> ant build-mainService

4

ターゲットWebサービスを通常どおりデプロイします。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

5

クライアントWebサービスを実装する、新しいJWSファイルを作成するか、既存のJWSファイルを更新します。

クライアント・アプリケーションがスタンドアロンJavaクライアントである場合は、「会話型Webサービスを呼び出すためのスタンドアロンJavaクライアントの更新」を参照してください。ステップ6 - 9をスキップします。

クライアント・アプリケーション自体がWebサービスである場合は、ステップ6 - 9に従います。

6

会話型Webサービスで会話を開始および実施する新しいJWSファイルを作成するか、既存のJWSファイルを更新します。

使い慣れたIDEまたはテキスト・エディタを使用します。クライアントWebサービスが、会話型Webサービスをホストするものとは別のWebLogic Serverインスタンスにデプロイされていることが前提となります。「会話型Webサービスを呼び出すJWSファイルに関するプログラミングのガイドライン」を参照してください。

7

クライアントWebサービスをビルドするbuild.xmlファイルを更新します。

「会話型Webサービスのクライアント用build.xmlファイルの更新」を参照してください。

8

Antターゲットを実行して、クライアントWebサービスをビルドします。

例:

prompt> ant build-clientService

9

クライアントWebサービスを通常どおりデプロイします。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

会話型JWSファイルに関するプログラミングのガイドライン

次のサンプルでは、会話型Webサービスを実装する簡単なJWSファイルを示します。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.conversation;

import java.io.Serializable;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.Conversation;
import weblogic.jws.Conversational;
import weblogic.jws.Context;
import weblogic.wsee.jws.JwsContext;
import weblogic.wsee.jws.ServiceHandle;

import javax.jws.WebService;
import javax.jws.WebMethod;
@Conversational(maxIdleTime="10 minutes",
maxAge="1 day",
runAsStartUser=false,
singlePrincipal=false )
@WebService(name="ConversationalPortType",
serviceName="ConversationalService",
targetNamespace="http://examples.org/")

@WLHttpTransport(contextPath="conv",
serviceUri="ConversationalService",
portName="ConversationalServicePort")

/**
* Conversational Web service.
*/

public class ConversationalServiceImpl implements Serializable {

@Context
private JwsContext ctx;
public String status = "undefined";

@WebMethod
@Conversation (Conversation.Phase.START)
public String start() {

ServiceHandle handle = ctx.getService();
String convID = handle.getConversationID();

status = "start";
return "Starting conversation, with ID " + convID + " and status equal to " + status;

}

@WebMethod
@Conversation (Conversation.Phase.CONTINUE)
public String middle(String message) {

status = "middle";
return "Middle of conversation; the message is: " + message + " and status is " + status;

}

@WebMethod
@Conversation (Conversation.Phase.FINISH)
public String finish(String message ) {

status = "finish";
return "End of conversation; the message is: " + message + " and status is " + status;

}

}

会話型Webサービスを実装するJWSファイルをプログラミングする際には、次のガイドラインに従います。ガイドラインのコード・スニペットは、前述のサンプルでは太字で示されています。

- 会話型Webサービスは、java.io.Serializableを実装している必要があるので、まずJWSファイルにクラスをインポートします。

import java.io.Serializable;

- 会話型JWSアノテーションをインポートします。

import weblogic.jws.Conversation;
import weblogic.jws.Conversational;

- 会話型Webサービスの実行時情報にアクセスする場合は、@ContextアノテーションおよびコンテキストAPIをインポートします。

import weblogic.jws.Context;

import weblogic.wsee.jws.JwsContext;
import weblogic.wsee.jws.ServiceHandle;

Webサービスの実行時コンテキストの詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービスの実行時情報へのアクセスに関する項を参照してください。

- クラス・レベルの@Conversationalアノテーションを使用して、Webサービスが会話型であると指定します。このアノテーションはオプションですが(メソッド・レベルの@Conversationアノテーションを指定していると仮定した場合)、常にこれをJWSファイル内で使用して、Webサービスが会話型であると明確に指定することをお薦めします。
指定するオプション属性は、WebLogic Serverが会話を終了するまでの、Webサービスがアイドル状態でいられる最大時間maxIdleTime、会話の最大存続期間maxAge、既存の会話の続行フェーズと終了フェーズを、会話を開始したユーザーとして実行するかどうかを示すrunAsStartUser、会話を開始したユーザー以外のユーザーが、会話の続行フェーズと終了フェーズの実行を許可されるかどうかを示すsinglePrincipalのうちのいずれかです。

@Conversational(maxIdleTime="10 minutes",
maxAge="1 day",
runAsStartUser=false,
singlePrincipal=false )

JWSファイルに@Conversationalアノテーションが含まれている場合、Webサービスのすべての操作が会話型です。操作のデフォルトのフェーズは、明示的に@Conversationアノテーションが指定されていなければ、続行フェーズです。ただし、会話型Webサービスには、1つ以上の開始操作と、1つの終了操作が含まれていることが必要なので、メソッド・レベルの@Conversationアノテーションを使用して、これらの操作をどのメソッドで実装するかを指定する必要があります。

属性のデフォルト値の詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.Conversationalに関する項を参照してください。

- JWSファイルには、java.io.Serializableが実装されている必要があります。

public class ConversationalServiceImpl implements Serializable {

- Webサービスの実行時情報にアクセスするには、データ型weblogic.wsee.jws.JwsContextのプライベート・クラス変数に、フィールド・レベルの@Context JWSアノテーションを付けます。

@Context
private JwsContext ctx;

- @Conversationアノテーションを使用して、会話の開始、続行、および終了フェーズを実装するメソッドを指定します。会話には、1つ以上の開始操作と、1つの終了操作が必要です。続行操作は任意指定です。フェーズを指定するアノテーションには、Conversation.Phase.START、Conversation.Phase.CONTINUE、またはConversation.Phase.FINISHの各パラメータを使用します。次の例では、開始操作を指定しています。

@WebMethod
@Conversation (Conversation.Phase.START)
public String start() {...

@ConversationアノテーションでマークするJWSファイルのメソッドが1つのみの場合、Webサービス全体が会話型となり、各操作は、会話の一部と見なされます。これは、JWSファイルで任意指定のクラス・レベル@Conversationalアノテーションを使用していなかった場合でも当てはまります。@Conversationで明示的にアノテーション付きにされていないメソッドはすべて、デフォルトで続行操作となります。つまり、たとえばクライアント・アプリケーションが、それ以前に開始操作を呼び出していない状態でこれらの続行メソッドの1つを呼び出すと、Webサービスが実行時エラーを返すということです。

なお、スタンドアロンJavaクライアントから会話型Webサービスを呼び出す場合、開始操作はリクエスト-レスポンスであることが必要です。つまり、この操作に、@Oneway JWSアノテーションを付けることはできません。操作は、voidを返すことがあります。Webサービスを、WebLogic Serverで実行されているクライアント・アプリケーションからのみ呼び出す場合、この要件は適用されません。

詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.Conversationに関する項を参照してください。

- Webサービスの実行時情報を取得するには、JwsContextインスタンスを使用します。
たとえば、開始操作の次のコードでは、WebLogic Serverが新しい会話に割り当てるIDを取得します。

ServiceHandle handle = ctx.getService();
String convID = handle.getConversationID();

コンテキスト関連APIの使用の詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービスの実行時情報へのアクセスに関する項を参照してください。

会話型Webサービスを呼び出すJWSファイルに関するプログラミングのガイドライン

次の例では、「会話型JWSファイルに関するプログラミングのガイドライン」で説明した会話型Webサービスを呼び出すWebサービス用の簡単なJWSファイルを示します。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.conversation;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.ServiceClient;

import weblogic.wsee.conversation.ConversationUtils;

import javax.jws.WebService;
import javax.jws.WebMethod;

import javax.xml.rpc.Stub;

import examples.webservices.conversation.ConversationalPortType;

import java.rmi.RemoteException;

@WebService(name="ConversationalClientPortType",
serviceName="ConversationalClientService",
targetNamespace="http://examples.org/")

@WLHttpTransport(contextPath="convClient",
serviceUri="ConversationalClient",
portName="ConversationalClientPort")

/**
*  client that has a conversation with the ConversationalService.
*/

public class ConversationalClientImpl {

@ServiceClient(
wsdlLocation="http://localhost:7001/conv/ConversationalService?WSDL",
serviceName="ConversationalService",
portName="ConversationalServicePort")

private ConversationalPortType port;

@WebMethod
public void runConversation(String message) {

try {

// Invoke start operation
String result = port.start();
System.out.println("start method executed.");
System.out.println("The message is: " + result);

// Invoke continue operation
result = port.middle(message );
System.out.println("middle method executed.");
System.out.println("The message is: " + result);

// Invoke finish operation
result = port.finish(message );
System.out.println("finish method executed.");
System.out.println("The message is: " + result);
ConversationUtils.renewStub((Stub)port);

}
catch (RemoteException e) {
e.printStackTrace();
}

}

}

会話型Webサービスを呼び出すJWSファイルをプログラミングする際には、次のガイドラインに従います。ガイドラインのコード・スニペットは、前述のサンプルでは太字で示されています。

- @ServiceClient JWSアノテーションをインポートします。

import weblogic.jws.ServiceClient;

- 必要に応じて、会話をさらに構成するためのWebLogicユーティリティ・クラスをインポートします。

import weblogic.wsee.conversation.ConversationUtils;

- 呼び出す会話型Webサービスのポート・タイプのJAX-RPCスタブをインポートします。実際のスタブそのものは、後でjwsc Antタスクによって作成されます。スタブ・パッケージは、<jws>の子要素<clientgen>のpackageName属性によって指定され、スタブの名前は呼び出されたWebサービスのWSDLによって決まります。

import examples.webservices.conversation.ConversationalPortType;

- JWSファイルの本文で、@ServiceClient JWSアノテーションを使用して、呼び出す会話型WebサービスのWSDL、名前、およびポートを指定します。このアノテーションは、プライベート変数のフィールド・レベルで指定します。この変数のデータ型は、呼び出しているWebサービスのJAX-RPCポート・タイプとなります。

@ServiceClient(
wsdlLocation="http://localhost:7001/conv/ConversationalService?WSDL",
serviceName="ConversationalService",
portName="ConversationalServicePort")

private ConversationalPortType port;

- @ServiceClientアノテーションを付けたスタブを使用して、会話型Webサービスの開始操作を呼び出し、会話を開始します。開始メソッドは、JWSファイルの任意の場所(コンストラクタ、メソッドなど)から呼び出せます。

String result = port.start();

- 必要に応じて続行メソッドを呼び出し、会話を続行します。開始したものと同じ会話が続行されるよう、必ず同じスタブ・インスタンスを使用します。

result = port.middle(message );

- 会話が完了したら、会話型Webサービスが現在の会話に使用していたリソースを解放できるよう、終了操作を呼び出します。

result = port.finish(message );

- Webサービスの会話スタブを再利用して新しい会話を開始するには、weblogic.wsee.conversation.ConversationUtilsユーティリティ・クラスのrenewStub()メソッドを使用して、そのスタブを明示的に更新する必要があります。

ConversationUtils.renewStub((Stub)port);

注意:
会話型Webサービスを呼び出すクライアントWebサービスは、必ずしも会話型にする必要はありません。ただし、クライアントが会話型でない場合は、このクライアントの複数のインスタンスが同じ会話型Webサービス・スタブにアクセスする危険性があり、保存されている会話状態が破損するおそれがあります。この危険性があると判断した場合は、クライアントWebサービスも会話型になるように指定してください。

ConversationUtilsユーティリティ・クラス

WebLogic Serverには、会話機能で使用するユーティリティ・クラスが用意されています。このクラスを使用すると、会話IDの取得や設定、構成オプションの設定といった一般的なタスクを実行できます。これらのタスクには、会話型Webサービス内で実行するものと、会話型Webサービスを呼び出すクライアント内で実行するものがあります。このクラスの使用例については、「会話型Webサービスを呼び出すJWSファイルに関するプログラミングのガイドライン」を参照してください。

詳細は、Oracle WebLogic Server APIリファレンスのweblogic.wsee.conversation.ConversationUtilsに関する項を参照してください。

会話型Webサービスのクライアント用build.xmlファイルの更新

build.xmlファイルを更新して、会話型Webサービスを呼び出すJWSファイルを生成するには、次のサンプルのようなtaskdefsおよびbuild-clientServiceターゲットを追加します。詳細は、サンプルの後の説明を参照してください。

<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />

<target name="build-clientService">

<jwsc
enableAsyncService="true"
srcdir="src"
destdir="${clientService-ear-dir}" >

<jws file="examples/webservices/conversation/ConversationalClientImpl.java" >
<clientgen
wsdl="http://${wls.hostname}:${wls.port}/conv/ConversationalService?WSDL"
packageName="examples.webservices.conversation"/>

</jws>

</jwsc>

</target>

jwsc Antタスクの完全なクラス名を定義するには、taskdef Antタスクを使用します。

クライアントWebサービスをコンパイルするjwsc Antタスクを更新して、<jws>要素の<clientgen>子要素を含めます。これにより、デプロイされたConversationalService WebサービスのJAX-RPCスタブが生成およびコンパイルされるようになります。jwsc Antタスクでは、これらのスタブが生成されたWARファイルに自動的にパッケージ化されるため、即座にクライアントWebサービスからアクセスできるようになります。このようにするのは、生成されたクラスの1つをConversationalClientImpl JWSファイルでインポートして使用するためです。

会話型Webサービスを呼び出すためのスタンドアロンJavaクライアントの更新

次の例では、「会話型JWSファイルに関するプログラミングのガイドライン」で説明した会話型Webサービスを呼び出す、簡単なスタンドアロンのJavaクライアントを示します。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.conv_standalone.client;

import java.rmi.RemoteException;

import javax.xml.rpc.ServiceException;
import javax.xml.rpc.Stub;
import weblogic.wsee.jaxrpc.WLStub;

/**
* stand-alone client that invokes and converses with ConversationlService.
*/

public class Main {

public static void main(String[] args)
throws ServiceException, RemoteException{

ConversationalService service = new ConversationalService_Impl(args[0] + "?WSDL");
ConversationalPortType port = service.getConversationalServicePort();

// Set property on stub to specify that client is invoking a Web service
// that uses advanced features; this property is automatically set if
// the client runs in a WebLogic Server instance.

Stub stub = (Stub)port;
stub._setProperty(WLStub.COMPLEX,  "true");

// Invoke start operation to begin the conversation
String result = port.start();
System.out.println("start method executed.");
System.out.println("The message is: " + result);

// Invoke continue operation
result = port.middle("middle" );
System.out.println("middle method executed.");
System.out.println("The message is: " + result);

// Invoke finish operation
result = port.finish("finish" );
System.out.println("finish method executed.");
System.out.println("The message is: " + result);

}

}

会話型Webサービスを呼び出すスタンドアロンJavaクライアントをプログラミングする際には、次のガイドラインに従います。ガイドラインのコード・スニペットは、前述のサンプルでは太字で示されています。

- weblogic.wsee.jaxrpc.WLStubクラスをインポートします。

import weblogic.wsee.jaxrpc.WLStub;

- _setPropertyメソッドを使用して、WLStub.ComplexプロパティをConversationalServiceのJAX-RPCスタブに対して設定します。

Stub stub = (Stub)port;
stub._setProperty(WLStub.COMPLEX,  "true");

このプロパティは、クライアントが高度なWebサービス(この場合は会話型Webサービス)を呼び出すことをWebサービスのランタイムに対して指定します。このプロパティは、別のWebLogic Webサービスから会話型Webサービスを呼び出している場合には、自動的に設定されます。

- 会話型Webサービスの開始操作を呼び出して、会話を開始します。

String result = port.start();

- 必要に応じて続行メソッドを呼び出し、会話を続行します。

result = port.middle(message );

- 会話が完了したら、会話型Webサービスが現在の会話に使用していたリソースを解放できるよう、終了操作を呼び出します。

result = port.finish(message );

会話型Webサービスの.NETクライアントの例

この項では、会話型WebLogic Webサービスの.NET WSE3.0クライアントを作成する方法について説明します。この例には次のファイルが含まれています。

- ConversationService.java -- @Conversationおよび@Callbackアノテーションを使用して会話型Webサービスを実装するJWSファイル。ConversationService.javaは、コールバックを介してクライアントに結果を通知することもできます(オプション)。

- Service.cs -- ConversationService Webサービスのクライアントとして機能するConversationClient .NET WebサービスのC#ソース・ファイル。
このサンプル.NETクライアントは、ConversationServiceとの会話に参加できます。また、コールバックを介して結果を受け取ることも可能です。

- build.xml -- 会話型Webサービスをビルドおよびデプロイするためのターゲットを含むAntビルド・ファイル。

これらのファイルについては、以降の項で詳しく説明します。

ConversationService.javaファイル

サンプルのConversationService.javaファイルを例4-1に示します。このサンプルには、機能を説明するコメントが大量に含まれています。

例4-1 ConversationService.javaファイル

package conv;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.Oneway;

import weblogic.jws.Conversation;
import weblogic.jws.Callback;
import weblogic.jws.CallbackService;

import java.io.Serializable;

/**
* Demonstrates use of the @Conversation annotation to manage the lifetime of the service
* and provide data persistence and message correlation.
*
* Remember that multiple clients might invoke a web service simultaneously.  When the
* web service stores data relevant to the client or calls additional services
* in order to process a client's request, the service must be able to process returned
* data from the external services in the context of the specific client it relates
* to.  This is all automatic when conversations are used.
*
* Remember that not all clients are capable of accepting callbacks.  Specifically,
* clients operating from behind firewalls may not be able to receive asynchronous
* callbacks.  You may wish to provide a synchronous interface, like this one,
* for such clients.  If a client can accept callbacks, it must send a callback endpoint refrence
* as part of any "start conversation" method invocation.
*
* To see the behavior in the Test View, invoke startRequest and then getRequestStatus
* several times quickly.
*/
@WebService(serviceName = "ConversationService", portName = "conversation", targetNamespace = "http://www.openuri.org/")
public class ConversationService implements Serializable {

@Callback
public CallbackInterface callback;
private boolean useCallbacks;
private int num;

/**
* Starts the conversation
*/
@Conversation(Conversation.Phase.START)
@WebMethod
public void startRequest(boolean useCallbacks) {
this.useCallbacks = useCallbacks;
}

@WebMethod
@Conversation(Conversation.Phase.CONTINUE)
public String getRequestStatus() {

num++;
if (num == 1)
return "This is the first time you call getRequestStatus method.";
if (num == 2 && useCallbacks) {
callback.onResultReady("finished");
return "This is the second time you call  getRequestStatus method, the conversation has been terminated automtically when the onResultReady callback method is invoked.";
} else
return "You have called getRequestStatus method " + num + " times";

}

/**
* Used to tell Conversation.jws that the current conversation is
* no longer needed.
*/
@WebMethod
@Conversation(Conversation.Phase.FINISH)
public void terminateRequest() {

}

@CallbackService(serviceName = "ConversationCallbackService")
public interface CallbackInterface {

/**
* Callback to invoke on the client when the external service
* returns its result. Will only be called it the client can
* accept callbacks and told us where to send them.
* <p/>
* If this callback is used, it implicitly terminates the
* conversation with no action required on the part of the
* client.
*/
@WebMethod
@Oneway
@Conversation(Conversation.Phase.FINISH)
public void onResultReady(String result);
}

}

Service.csファイル

サンプルのService.csファイルを例4-2に示します。

この会話プロキシ・ファイルは、Microsoft WSDL to Proxy ClassツールWseWsdl3.exe(http://msdn.microsoft.com/en-us/library/aa529578.aspxを参照)とConversationService WebサービスのWSDLファイルを使用して作成したものです。

このサンプルには、機能を説明するコメントが大量に含まれています。

例4-2 Service.csファイル

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Diagnostics;
using System.IO;
using System.Xml;
using Microsoft.Web.Services3.Addressing;
using Microsoft.Web.Services3;
using System.Collections.Generic;
using Microsoft.Web.Services3.Design;

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Service : System.Web.Services.WebService
{

public Service () {

//Uncomment the following line if using designed components
//InitializeComponent();
}

/*
* start invokes the Conversation web service's startRequest
* operation.
*
* Since the Conversation web service is conversational,
* we must also persist the ReplyTo endpoint reference SOAP header
* for subsequent calls.
*
* Since the Conversation web service can optionally communicate
* the result of it's work via a callback, we must prepare a
* second SOAP header CallbackTo SOAP header, which is the endpoint reference
* of the recipient to which callbacks should be sent.
*/
[WebMethod(EnableSession = true)]
public void start(Boolean useCallbacks, Boolean useIPAddress)
{
/*
* The Conversation proxy was created using .NET WSE3.0's WseWsdl3.exe
* application and the Conversation.jws's WSDL file.  The WSDL
* file for any WLS web service may be obtained
* by hitting the web service's URL with "?WSDL" appended to
* the end.  For example:
*
* http://somehost:7001/samples/async/Conversation.jws?WSDL
*
* WseWsdl3.exe produces a C# proxy class.  Place the resulting
* ConversationService.cs file in your .NET project, then use Visual
* Studio's Project->Add Existing Item menu action to "import"
* the class into the project.
*/
ConversationServiceSoapBinding conv;
String callbackLocation;
int asmxIndex;

/*
* Construct the callback URL from various pieces of
* server and HttpRequest info.
*/
Uri requestUrl = Context.Request.Url;

if (useIPAddress)
{
/*
* if useIPAddress is true, construct the callback address
* with the IP address of this host.
*/
callbackLocation = requestUrl.Scheme + "://" + System.Net.Dns.GetHostByName(requestUrl.Host).AddressList[0] +
":" + requestUrl.Port + requestUrl.AbsolutePath;
}
else
{
/*
* if useIPAddress is false, construct the callback address
* with the hostname of this host.
*/
callbackLocation = requestUrl.Scheme + "://" + requestUrl.Host +
":" + requestUrl.Port + requestUrl.AbsolutePath;
}

// Remove everything after ".asmx"
asmxIndex = callbackLocation.IndexOf(".asmx") + 5;
callbackLocation = callbackLocation.Remove(asmxIndex,
callbackLocation.Length - asmxIndex);

/*
* Create an instance of the proxy for the Conversation
* web service.
*
*/
conv = new ConversationServiceSoapBinding();

/*
* When callback is enabled, a custom callback header should be added into
* the outbound soap message.
*
*/
if (useCallbacks)
enableSoapFilterToAddCallbackHeader(conv, callbackLocation);

/*
* Invoke the startRequest method of the web service. The
* single boolean parameter determines whether the Conversation
* web service will use callbacks to communicate the result
* back to this client.
*
* If the argument is true, an onResultReady callback will
* be sent when the result is ready.  This client must implement
* a method with that name that expects the message shape defined
* by the target web service (returns void and accepts a single
* string argument).  See the onResultReady method below.
*
* If the argument to startRequest is false, callbacks will not
* be used and this client must use the getRequestStatus method
* to poll the Conversation web service for the result.
*/
conv.startRequest(useCallbacks);
/*
* Persist the ReplyTo header  in session state so that it can
* be used in other methods that take part in the conversation.
*
* This is not safe since one session could start multiple
* conversations, but there is no other apparent way to persist
* this information.  Member variables of WebService classes
* are not persisted across method invocations.
*/
Session["ConversationReplyTo"] = conv.ResponseSoapContext.Addressing.ReplyTo;

}

/* the CallbackTo header defintion isn't exposed by WLS9x/WLS10x callback service.
* So we need to use SOAPFilter to add the CallbackTo header.
*
*/
private static void enableSoapFilterToAddCallbackHeader(ConversationServiceSoapBinding conv, String callbackLocation)
{
//Create a custom policy.
Policy myPolicy = new Policy();
// Create a new policy assertion
MyPolicyAssertion myAssertion = new MyPolicyAssertion(callbackLocation);
// Add the assertion to the policy
myPolicy.Assertions.Add(myAssertion);
//Set the custom policy you have created on the client proxy
conv.SetPolicy(myPolicy);
}

/*
* getStatus invokes Conversation's getRequestStatus method.
* getRequestStatus is a polling method that is an alternative
* for web services that cannot recieve callbacks.
*
* Note that a conversation must be started with startRequest before
* this method may be invoked.  If not, or if this method is invoked
* outside of a conversation for any reason, it will get back a SOAP
* fault indicating that the conversation does not exist.
*/
[WebMethod(EnableSession = true)]
public String getStatus()
{
String result;

/*
* Create an instance of the proxy for the Conversation
* web service.  We could probably persist the proxy instance
* in session state, but chose not to.
*/
ConversationServiceSoapBinding conv = new ConversationServiceSoapBinding();

/*
* change the destination to the ReplyTo endpoint reference we cached on session state in
* the start method.
*/
conv.RequestSoapContext.Addressing.Destination = (EndpointReference)Session["ConversationReplyTo"];
/*
* Invoke the getRequestStatus method of the web service.
*/
result = conv.getRequestStatus();
return result;
}

/*
* finish invokes Conversation's terminateRequest method, which
* terminates the current conversation.
*
* Note that a conversation must be started with startRequest before
* this method may be invoked.  If not, or if this method is invoked
* outside of a conversation for any reason, it will get back a SOAP
* fault indicating that the conversation does not exist.
*/
[WebMethod(EnableSession = true)]
public void finish()
{
/*
* Create an instance of the proxy for the Conversation
* web service.  We could probably persist the proxy instance
* in session state, but chose not to.
*/
ConversationServiceSoapBinding conv = new ConversationServiceSoapBinding();

/*
* change the destination to the ReplyTo endpoint reference we cached on session state in
* the start method. Both "continue" and "finish" methods use the same destination.
*/
conv.RequestSoapContext.Addressing.Destination = (EndpointReference)Session["ConversationReplyTo"];
/*
* Invoke the terminateRequest method of the web service.
*/
conv.terminateRequest();
}

/*
* onResultReady is a callback handler for the onResultReady
* callback that Conversation.jws can optionally use to return
* its results.
*
* .NET WSE3.0 does not support callbacks directly, but a callback is just
* a method invocation message.  So if you construct a WebMethod with
* the same signature as the callback and set the XML namespace
* properly, it serves as a callback handler.
*
*/
[WebMethod]
[SoapDocumentMethod(OneWay = true,
Action = "http://www.openuri.org/ConversationService_CallbackInterface/onResultReady",
RequestElementName = "http://www.openuri.org/",
ResponseNamespace = "http://www.openuri.org/"
)]
public void onResultReady(String result)
{
/*
* When the callback is invoked, log a message to the
* hardcoded file c:\temp\ConversationClient.log.
*
* Note: if c:\temp does not exist on this server, an
* Exception will be raised.  Since it is not handled here,
* it will be returned as a SOAP fault to the Conversation
* web service.
*/
TextWriter output;
output = File.AppendText("c:\\temp\\ConversationClient.log");
String msg = "[" + DateTime.Now.ToString() + "] callback received";
output.WriteLine(msg);
output.Flush();
output.Close();
}

}

public class MyFilter : Microsoft.Web.Services3.SoapFilter
{
private String callbackLocation;

public MyFilter(String callbackLocation)
{
this.callbackLocation = callbackLocation;
}

public override SoapFilterResult ProcessMessage(SoapEnvelope envelope)
{

//create the CallbackTo soap element.
XmlDocument xmldoc = new XmlDocument();
XmlElement xmlEle = xmldoc.CreateElement("callback", "CallbackTo", "http://www.openuri.org/2006/03/callback");

//create the CallbackTo endpoint reference.
Address callbacto = new Address(new Uri(callbackLocation));
XmlElement xmlEle2 =new EndpointReference(callbacto).GetXml(xmldoc);
//add the CallbackTo endpoint reference into CallbackTo SOAP element.
xmlEle.AppendChild(xmlEle2.FirstChild);
//add the whole CallbackTo SOAP element into SOAP header.
XmlNode callbackheader = envelope.ImportNode(xmlEle, true);
envelope.DocumentElement.FirstChild.AppendChild(callbackheader);
return SoapFilterResult.Continue;

}
}

public class MyPolicyAssertion : Microsoft.Web.Services3.Design.PolicyAssertion
{
private String callbackLocation;

public MyPolicyAssertion(String callbackLocation)
{
this.callbackLocation = callbackLocation;
}

public override  SoapFilter CreateClientInputFilter(FilterCreationContext context)
{
return null;
}

public override  SoapFilter CreateClientOutputFilter(FilterCreationContext context)
{
//use MyFilter to add the CallbackTo header in the outbound soap message.
return new MyFilter(callbackLocation);
}

public override  SoapFilter CreateServiceInputFilter(FilterCreationContext context)
{
return null;
}

public override  SoapFilter CreateServiceOutputFilter(FilterCreationContext context)
{
return null;
}

}

build.xmlファイル

サンプルのbuild.xmlファイルを例4-3に示します。

build.xmlは、サンプル・ソース・ファイルを新しいWL_HOME\samples\server\examples\src\examples\webservices\convディレクトリにコピーすることを前提としています。WL_HOMEは、WebLogic Serverがインストールされているディレクトリです。

build.xmlを使用するには、まずWL_HOME\samples\domains\wl_server>setExamplesEnv.cmd(shを実行してサンプルの環境を正しく設定し、サンプルのサーバーを開始しておくことも必要です。

このサンプルには、ビルド・ファイルの機能を説明するコメントとターゲットが含まれています。

例4-3 build.xml File

<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="webservices.conversation" default="all" basedir=".">

<!-- set global properties for this build -->
<property file="../../../examples.properties"/>

<property name="client.dir" value="${client.classes.dir}/webservices_conversation" />
<property name="package.dir" value="examples/webservices/conv"/>
<property name="package" value="examples.webservices.conv"/>
<property name="ear.dir" value="${examples.build.dir}/webservicesConversationEar" />

<path id="client.class.path">
<pathelement path="${java.class.path}"/>
</path>

<!-- Web service WLS Ant task definitions -->
<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />
<taskdef name="clientgen"
classname="weblogic.wsee.tools.anttasks.ClientGenTask" />

<target name="all" depends="build, deploy"/>

<target name="clean">
<delete dir="${ear.dir}"/>
</target>

<!-- Target that builds the conversational  Web service -->
<target name="build" description="Target that builds the MTOM Web service">
<jwsc
srcdir="${examples.src.dir}/${package.dir}"
sourcepath="${examples.src.dir}"
destdir="${ear.dir}"
classpath="${java.class.path}"
keepGenerated="true"
deprecation="${deprecation}"
debug="${debug}">
<jws file="ConversationService.java">
<WLHttpTransport contextPath="/samples/async" serviceURI="conversation.jws"/>
</jws>
</jwsc>
</target>

<!-- Target that deploys the conversational Web service -->
<target name="deploy" description="Target that deploys the conversational Web service">
<wldeploy
action="deploy"
source="${ear.dir}"
user="${wls.username}"
password="${wls.password}"
verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}"
failonerror="${failondeploy}"/>
</target>

<!-- Target that undeploys the conversational Web service -->
<target name="undeploy" description="Target that deploys the conversational Web service">
<wldeploy
action="undeploy"
name="webservicesConversationEar"
user="${wls.username}"
password="${wls.password}"
verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}"
failonerror="${failondeploy}"/>
</target>

</project>

会話型Webサービスを再デプロイする際にクライアント側で考慮すべき事項

WebLogic Serverでは、本番再デプロイメントがサポートされています。つまり、会話型WebLogic Webサービスの更新後の新しいバージョンを、同じWebサービスの古いバージョンと並行してデプロイできます。

WebLogic Serverでは、新しいクライアントのリクエストのみが新しいバージョンに転送されるように、クライアント接続が自動的に管理されます。再デプロイメント時にすでにWebサービスに接続していたクライアントは、作業が完了するまで古いバージョンのサービスを使用し続け、それらの作業が完了した時点で、WebLogic Serverが古いWebサービスを自動的にリタイアします。クライアントが会話型Webサービスに接続されている場合は、既存の会話がクライアントによって明示的に終了されるか、またはタイムアウトになったときに、そのクライアントの作業が完了したと見なされます。

本番再デプロイメントとWebサービス・クライアントの詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービスを再デプロイする際にクライアントで考慮すべき事項に関する項を参照してください。

5 バッファ付きWebサービスの作成

この章では、バッファ付きのWebLogic Java API for XML-based RPC (JAX-RPC) Webサービスの作成方法について説明します。

この章では、以下のトピックについて説明します。

- バッファ付きWebサービスの概要

- バッファ付きWebサービスの作成: 主な手順

- バッファ付きWebサービスのホストWebLogic Serverインスタンスの構成

- バッファ付きJWSファイルに関するプログラミングのガイドライン

- バッファ付きWebサービスを呼び出すJWSファイルのプログラミング

- バッファ付きWebサービスのクライアント用build.xmlファイルの更新

バッファ付きWebサービスの概要

バッファ付き操作がクライアントによって呼び出されると、メソッド操作はJMSキューに渡され、WebLogic Serverは非同期にそれを処理します。Webサービスの信頼性のあるメッセージングの場合と同様に、メソッド呼出しがまだキューに入っているときにWebLogic Serverが停止しても、再起動すればすぐに処理が行われます。バッファ付きWebサービスを呼び出す際に、クライアントが呼出しからのレスポンスを待機しないので、クライアントの実行は続行可能です。

バッファ付きWebサービスの作成: 主な手順

次の手順では、バッファ付きWebサービスと、そのバッファ付きWebサービス操作を呼び出すクライアントWebサービスを作成する方法を説明しています。この手順では、2つのWebサービスを実装するJWSファイルをゼロから作成する方法を示しています。既存のJWSファイルを更新する場合は、この手順をガイドとして利用してください。この手順ではまた、バッファ付きWebサービスをホストするWebLogic Serverインスタンスを構成する方法も示しています。

注意:
非同期リクエスト-レスポンス機能を一緒に使用しているのでなければ、別のWebサービスからバッファ付きWebサービスを呼び出す必要はありません。これは、スタンドアロンJavaアプリケーションからも呼び出すことができます。

Antベースの開発環境を設定済であり、かつjwsc Antタスクを実行して生成されたバッファ付きWebサービスをデプロイするためのターゲットを追加できる、作業用のbuild.xmlファイルがあることが前提となっています。さらに、バッファ付きWebサービスを呼び出すクライアントWebサービスをホストする、WebLogic Serverインスタンスを同様に設定してあることも前提となっています。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』を参照してください。

- 使用例とサンプル

- WebLogic Webサービスの開発

- JWSファイルのプログラミング

- Webサービスの呼出し

表5-1 バッファ付きWebサービスの作成手順

#

手順

説明

1

バッファ付きWebサービスをホストするWebLogic Serverインスタンスを構成します。

「バッファ付きWebサービスのホストWebLogic Serverインスタンスの構成」を参照してください。

2

バッファ付きWebサービスを実装する、新しいJWSファイルを作成するか、既存のJWSファイルを更新します。

使い慣れたIDEまたはテキスト・エディタを使用します。「バッファ付きJWSファイルに関するプログラミングのガイドライン」を参照してください。

3

build.xmlファイルを更新して、JWSファイルをバッファ付きWebサービスにコンパイルするjwsc Antタスクの呼出しを含めます。

例:

<jwsc
srcdir="src"
destdir="${service-ear-dir}" >
<jws
file="examples/webservices/async_buffered/AsyncBufferedImpl.java"
/>
</jwsc>

jwsc Antタスクの使用に関する一般情報は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のjwsc WebLogic WebサービスAntタスクの実行に関する項を参照してください。

4

適切なターゲットを呼び出してJWSファイルを再コンパイルしてから、WebLogic ServerにWebサービスを再デプロイします。

例:

prompt> ant build-clientService deploy-clientService

デプロイメントの詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

5

バッファ付きWebサービスを呼び出すクライアントWebサービスを実装する、新しいJWSファイルを作成するか、既存のJWSファイルを更新します。

「バッファ付きWebサービスを呼び出すJWSファイルのプログラミング」を参照してください。

6

クライアントWebサービスをビルドするbuild.xmlファイルを更新します。

「バッファ付きWebサービスのクライアント用build.xmlファイルの更新」を参照してください。

7

適切なターゲットを呼び出してクライアントJWSファイルを再コンパイルしてから、クライアントWebLogic ServerにWebサービスを再デプロイします。

例:

prompt> ant build-clientService deploy-clientService

デプロイメントの詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

バッファ付きWebサービスのホストWebLogic Serverインスタンスの構成

バッファ付きWebサービスのデプロイ先となるWebLogic Serverインスタンスを構成する際には、Webサービスのランタイムで内部的に使用される、JMSサーバーやモジュールなどのJMSリソースを構成します。

これらのリソースは手作業でも構成できますが、構成ウィザードで、Webサービス固有の拡張テンプレートを使用してWebLogic Serverドメインを拡張することもできます。構成ウィザードを使用すると、必要な構成手順を大幅に簡略化できます。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービス機能用のドメイン構成に関する項を参照してください。

注意:
または、WLSTを使用してリソースを構成することもできます。WLSTを使用してドメインを拡張する方法については、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。
Webサービス・リソースを含まないドメインは、Webサービスと関連のないシナリオや、非同期のリクエストおよびレスポンスを呼び出さないWebサービスのシナリオであれば、適切に起動して実行されます。ただし、サーバー・ログには、非同期リソースが構成されていないことと、Webサービス用の非同期レスポンス・サービスが完全にデプロイされていないことを示すINFOメッセージが表示されます。

リソースを手作業で構成する場合、以下の手順を実行します。

表5-2 バッファ付きWebサービスのホストWebLogic Serverインスタンスを手作業で構成する手順

#

手順

説明

1

ホストWebLogic Serverインスタンスが格納されたドメインの管理コンソールを起動します。

ブラウザで管理コンソールを起動するには、次のURLを入力します。

http://host:port/console

ここで

- hostは、管理サーバーが動作しているコンピュータを指します。

- portは、管理サーバーが接続リクエストをリスニングしているポート番号を指します。管理サーバーのデフォルトのポート番号は7001です。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』の管理コンソールの起動に関する項を参照してください。

3

JMSサーバーを作成します。

JMSサーバーを作成します。JMSサーバーがすでに存在する場合は、新しいJMSサーバーを作成せずにそれを使用できます。

Oracle WebLogic Server管理コンソール・ヘルプのJMSサーバーの作成に関する項を参照してください。

4

JMSモジュールを作成し、キューを定義します。

JMSモジュールを作成し、その中にJMSキューを定義します。JMSモジュールがすでに存在する場合は、新しいJMSモジュールを作成せずにそれを使用することもできます。JMSキューを、1つ前の手順で作成したJMSサーバーにターゲット指定します。このJMSキューがローカルであることを必ず指定してください(通常は、ローカルJNDI名の設定により指定できます)。Oracle WebLogic Server管理コンソール・ヘルプのJMSシステム・モジュールの作成に関する項とシステム・モジュールのキューの作成に関する項を参照してください。

バッファ付きWebサービスで、デフォルトWebサービスのキューを使用する場合は、JMSキューのJNDI名をweblogic.wsee.DefaultCallbackQueueに設定します。そうせずに、別のJNDI名を使用する場合は、JWSファイル内で@BufferQueueアノテーションを使用して、このJNDI名を信頼性のあるWebサービスに対して指定する必要があります。「バッファ付きJWSファイルに関するプログラミングのガイドライン」を参照してください。

クラスタリングの考慮事項:

クラスタ内でWebサービスのバッファ機能を使用する場合は、次の作業を行う必要があります。

- JMSキューの作成時に、分散キューではなくローカルJMSキューを作成します。

- このJMSキューをクラスタ内の各サーバーに明示的にターゲット指定します。

4

必要に応じて、現在のドメイン環境をチューニングする(オプション)

『WebLogic Serverパフォーマンスおよびチューニング』の「Webサービスのパフォーマンスを向上させるために負荷が高いシステムのチューニング」を参照してください。

バッファ付きJWSファイルに関するプログラミングのガイドライン

次のサンプルでは、バッファ付きWebサービスを実装する簡単なJWSファイルを示します。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.buffered;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.Oneway;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.MessageBuffer;
import weblogic.jws.BufferQueue;

@WebService(name="BufferedPortType",
serviceName="BufferedService",
targetNamespace="http://example.org")

@WLHttpTransport(contextPath="buffered",
serviceUri="BufferedService",
portName="BufferedPort")

// Annotation to specify a specific JMS queue rather than the default
@BufferQueue(name="my.jms.queue")

/**
* Simple buffered Web Service.
*/

public class BufferedImpl {

@WebMethod()
@MessageBuffer(retryCount=10, retryDelay="10 seconds")
@Oneway()
public void sayHelloNoReturn(String message) {
System.out.println("sayHelloNoReturn: " + message);

}
}

バッファ付きWebサービスを実装するJWSファイルをプログラミングする際には、次のガイドラインに従います。ガイドラインのコード・スニペットは、前述のサンプルでは太字で示されています。

- バッファ付きWebサービスに使用されるJWSアノテーションをインポートします。

import javax.jws.Oneway;
import weblogic.jws.MessageBuffer;
import weblogic.jws.BufferQueue;

どのJWSアノテーションが必要かについては、以下の箇条書きを参照してください。

- 必要に応じて、クラス・レベルの@BufferQueue JWSアノテーションを使用し、バッファ付きの呼出しを処理する際にWebLogic Serverによって内部使用されるJMSキューのJNDI名を指定します。例:

@BufferQueue(name="my.jms.queue")

このJWSアノテーションを指定しなかった場合、WebLogic Serverは、デフォルトWebサービスJMSキュー(weblogic.wsee.DefaultQueue)を使用します。

デフォルトのJMSキューと、このアノテーションで指定されたキューの双方を作成してからでなければ、バッファ付きの操作を正常に呼び出すことはできません。詳細については、「バッファ付きWebサービスのホストWebLogic Serverインスタンスの構成」を参照してください。

- @MessageBuffer JWSアノテーションを使用し、バッファ付きWebサービス操作を指定します。アノテーションには、次の2つのオプション属性があります。

- retryCount: WebLogic ServerによるJMSキューからWebサービス実装へのメッセージ配信試行回数(デフォルトでは3)。

- retryDelay: サーバーが待機すべき再試行間隔(デフォルトでは5分)。

例:

@MessageBuffer(retryCount=10, retryDelay="10 seconds")

このアノテーションをクラス・レベルで使用すると、すべての操作をバッファ付きにすることを指定でき、メソッド・レベルで指定すると、どの操作をバッファ付きにするかを選択できます。

- バッファ付きWebサービス操作を同期的に呼び出す(すなわち、非同期リクエスト-レスポンス機能を使用しない)場合は、実装メソッドに@Onewayアノテーションを付けて、そのメソッドが一方向のものであることを指定する必要があります。つまり、メソッドは値を戻すことができず、明示的にvoidを戻すことになります。例:

@Oneway()
public void sayHelloNoReturn(String message) {

反対に、メソッドに@Onewayアノテーションが付いていなければ、非同期リクエスト-レスポンス機能を使用して呼び出す必要があります。操作の呼出し方法がわからない場合は、同期と非同期の2種類の操作を作成することを検討してください。

第2章「非同期リクエスト-レスポンスを使用したWebサービスの呼出し」と第6章「非同期機能の併用」を参照してください。

バッファ付きWebサービスを呼び出すJWSファイルのプログラミング

バッファ付きWebサービスは、スタンドアロンJavaアプリケーション(非同期リクエスト-レスポンスを使用していない場合)と別のWebサービスの双方から呼び出せます。ただし、他のWebLogic Webサービスの非同期機能とは異なり、クライアントWebサービスにおいて@ServiceClient JWSアノテーションは使用せず、その他のサービスと同じように呼び出します。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』の別のWebサービスからのWebサービスの呼出しに関する項を参照してください。

次のサンプルJWSファイルでは、BufferedService WebサービスのsayHelloNoReturn操作を呼び出す方法を示します。

package examples.webservices.buffered;

import java.rmi.RemoteException;
import javax.xml.rpc.ServiceException;

import javax.jws.WebService;
import javax.jws.WebMethod;

import weblogic.jws.WLHttpTransport;

import examples.webservices.buffered.BufferedPortType;
import examples.webservices.buffered.BufferedService_Impl;
import examples.webservices.buffered.BufferedService;

@WebService(name="BufferedClientPortType",
serviceName="BufferedClientService",
targetNamespace="http://examples.org")

@WLHttpTransport(contextPath="bufferedClient",
serviceUri="BufferedClientService",
portName="BufferedClientPort")

public class BufferedClientImpl {

@WebMethod()
public String callBufferedService(String input, String serviceUrl)
throws RemoteException {

try {

BufferedService service = new BufferedService_Impl(serviceUrl + "?WSDL");
BufferedPortType port = service.getBufferedPort();

// Invoke the sayHelloNoReturn() operation of BufferedService

port.sayHelloNoReturn(input);

return "Invoke went okay!";

} catch (ServiceException se) {

System.out.println("ServiceExcpetion thrown");
throw new RuntimeException(se);

}
}
}

バッファ付きWebサービスのクライアント用build.xmlファイルの更新

build.xmlファイルを更新して、バッファ付きWebサービス操作を呼び出すJWSファイルを生成するには、次のサンプルのようなtaskdefsおよびbuild-clientServiceターゲットを追加します。詳細は、サンプルの後の説明を参照してください。

<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />

<target name="build-clientService">

<jwsc
enableAsyncService="true"
srcdir="src"
destdir="${clientService-ear-dir}" >

<jws file="examples/webservices/buffered/BufferedClientImpl.java">
<clientgen
wsdl="http://${wls.hostname}:${wls.port}/buffered/BufferedService?WSDL"
packageName="examples.webservices.buffered"/>

</jws>

</jwsc>

</target>

jwsc Antタスクの完全なクラス名を定義するには、taskdef Antタスクを使用します。

クライアントWebサービスをコンパイルするjwsc Antタスクを更新して、<jws>要素の<clientgen>子要素を含めます。これにより、デプロイされたBufferedService WebサービスのJAX-RPCスタブが生成およびコンパイルされるようになります。jwsc Antタスクでは、これらのスタブが生成されたWARファイルに自動的にパッケージ化されるため、即座にクライアントWebサービスからアクセスできるようになります。このようにするのは、生成されたクラスの1つをBufferedClientImpl JWSファイルでインポートして使用するためです。

6 非同期機能の併用

この章では、WebLogic Java API for XML-based RPC (JAX-RPC) Webサービスと非同期機能を併用する方法について説明します。

この章では、以下のトピックについて説明します。

- 非同期機能の併用

- 信頼性のある会話型Webサービスを実装するJWSファイルの例

- 信頼性のある会話型Webサービスを非同期で呼び出すクライアントWebサービスの例

非同期機能の併用

ここまでの各項では、WebLogic Webサービスの非同期機能(Webサービスの信頼性のあるメッセージング、会話、非同期リクエスト-レスポンス、およびバッファリング)を単独で使用する方法を説明します。ただし、通常、Webサービスではこれらの機能を併用しています。例については、「信頼性のある会話型Webサービスを実装するJWSファイルの例」および「信頼性のある会話型Webサービスを非同期で呼び出すクライアントWebサービスの例」を参照してください。

併用すると、個々の機能についての節で説明した制限事項の一部が適用されなくなったり、場合によっては追加の制限事項が適用されたりします。次の表に、様々な機能を組み合せる場合の考慮事項をまとめます。

表6-1 非同期機能を一緒に使用する場合の考慮事項

機能の組合せ

考慮事項

非同期リクエスト-レスポンス機能とWebサービスの信頼性のあるメッセージング/バッファ機能

- 信頼性のあるWebサービスからの非同期レスポンスも信頼性があります。つまり、レスポンスを処理するためには、宛先WebLogic Serverインスタンスを構成するのと同じように、ソースWebLogic Serverインスタンス上でもJMSサーバー、モジュールおよびキューを構成する必要があります。
ソースWebLogic Serverインスタンス上でJMSキューを作成する際には、weblogic.wsee.DefaultQueueのJNDI名を指定することが要求されます。キューの名前は任意に付けることができます。また、このJMSキューがローカルであることも(通常は、ローカルJNDI名の設定により)指定する必要があります。

- 信頼性のある操作またはバッファ付きの操作を一方向にすることはできません。つまり、実装メソッドに@Onewayアノテーションを付加することはできません。

非同期リクエスト-レスポンス機能とWebサービスの信頼性のあるメッセージング機能

非同期コンテキストのいずれか1つ(AsyncPreCallContextまたはAsyncPostCallContext)でプロパティを設定する場合、そのプロパティはjava.io.Serializableを実装する必要があります。

非同期リクエスト-レスポンス機能とバッファ機能

バッファ付きWebサービス操作を呼び出すクライアントWebサービスで@ServiceClient JWSアノテーションを使用する必要があります。

会話機能とWebサービスの信頼性のあるメッセージング機能

- JWSの会話は、信頼性のあるシーケンスとは異なり、いかなる方法によってもリンクされません。信頼性のあるシーケンスの管理は、会話のライフサイクルとは別に検討する必要があります。たとえば、信頼性のあるメッセージングを使用して、クライアント・サービスと信頼性のある会話型サービスとの間でメッセージを送信する場合、会話を終了しても信頼性のあるシーケンスは終了されません。信頼性のあるシーケンスは(WsrmUtils.setFinalMessage()などの許容可能なメソッドを使用して)明示的に終了させる必要があります。または、シーケンスの存続期間が経過して期限切れになるまでアクティブにしておくことができます。信頼性のあるメッセージ・シーケンスのライフサイクルの詳細については、「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」を参照。

- プロパティWLStub.CONVERSATIONAL_METHOD_BLOCK_TIMEOUTは、クライアントWebサービスのスタブに対して設定された場合、クライアントがブロックしないため無視されます。

- 信頼性のある会話型Webサービスの少なくとも1つのメソッドは、@Onewayアノテーションでマークしないでください。

会話機能と非同期リクエスト-レスポンス機能

クライアントの会話型Webサービスとその他のWebサービスとの間における非同期のレスポンスもまた、会話に参加します。たとえば、WebServiceAが会話型で、非同期リクエスト-レスポンスを使用してWebServiceBを呼び出すとします。WebServiceAは会話型であるため、WebServiceBからの非同期レスポンスも同じ会話に参加します。

信頼性のある会話型Webサービスを実装するJWSファイルの例

次のサンプルのJWSファイルでは、信頼性があり、かつ会話型でもあるWebサービスを実装しています。

package examples.webservices.async_mega;

import java.io.Serializable;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.Conversation;
import weblogic.jws.Policy;

import javax.jws.WebService;
import javax.jws.WebMethod;

@WebService(name="AsyncMegaPortType",
serviceName="AsyncMegaService",
targetNamespace="http://examples.org/")

@Policy(uri="AsyncReliableConversationPolicy.xml",
attachToWsdl=true)

@WLHttpTransport(contextPath="asyncMega",
serviceUri="AsyncMegaService",
portName="AsyncMegaServicePort")

/**
* Web Service that is both reliable and conversational.
*/

public class AsyncMegaServiceImpl implements Serializable {

@WebMethod
@Conversation (Conversation.Phase.START)
public String start() {
return "Starting conversation";
}

@WebMethod
@Conversation (Conversation.Phase.CONTINUE)
public String middle(String message) {
return "Middle of conversation; the message is: " + message;
}

@WebMethod
@Conversation (Conversation.Phase.FINISH)
public String finish(String message ) {
return "End of conversation; the message is: " + message;
}

}

信頼性のある会話型Webサービスを非同期で呼び出すクライアントWebサービスの例

次のJWSファイルでは、「信頼性のある会話型Webサービスを実装するJWSファイルの例」に記載のWebサービスにおける様々な会話型のメソッドを確実に呼び出すクライアントWebサービスの実装方法を示します。クライアントJWSファイルでは、非同期リクエスト-レスポンス機能も使用しています。

package examples.webservices.async_mega;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.ServiceClient;
import weblogic.jws.AsyncResponse;
import weblogic.jws.AsyncFailure;

import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.xml.rpc.Stub;

import weblogic.wsee.async.AsyncPreCallContext;
import weblogic.wsee.async.AsyncCallContextFactory;
import weblogic.wsee.async.AsyncPostCallContext;
import weblogic.wsee.reliability.WsrmUtils;

import examples.webservices.async_mega.AsyncMegaPortType;
import examples.webservices.async_mega.AsyncMegaService;
import examples.webservices.async_mega.AsyncMegaService_Impl;

import java.rmi.RemoteException;

@WebService(name="AsyncMegaClientPortType",
serviceName="AsyncMegaClientService",
targetNamespace="http://examples.org/")

@WLHttpTransport(contextPath="asyncMegaClient",
serviceUri="AsyncMegaClient",
portName="AsyncMegaClientServicePort")

/**
* Client Web Service that has a conversation with the AsyncMegaService
* reliably and asynchronously.
*/

public class AsyncMegaClientImpl {

@ServiceClient(
wsdlLocation="http://localhost:7001/asyncMega/AsyncMegaService?WSDL",
serviceName="AsyncMegaService",
portName="AsyncMegaServicePort")

private AsyncMegaPortType port;

@WebMethod
public void runAsyncReliableConversation(String message) {

AsyncPreCallContext apc = AsyncCallContextFactory.getAsyncPreCallContext();
apc.setProperty("message", message);

try {
port.startAsync(apc);
System.out.println("start method executed.");

port.middleAsync(apc, message );
System.out.println("middle method executed.");

// Since this service is not conversational, any state kept in the port
// field will be lost when this method returns. In the case of reliable
// messaging, this state includes the ID of the reliable sequence being
// used to send messages. The setFinalMessage method specifies
// that this is the final message to be sent on this sequence. This
// will allow the reliable messaging subsystem to proactively clean up
// the reliable sequence instead of timing out.
WsrmUtils.setFinalMessage((Stub)port);
port.finishAsync(apc, message );
System.out.println("finish method executed.");

}
catch (RemoteException e) {
e.printStackTrace();
}

}

@AsyncResponse(target="port", operation="start")
public void onStartAsyncResponse(AsyncPostCallContext apc, String message) {
System.out.println("-------------------");
System.out.println("Got message " + message );
System.out.println("-------------------");
}

@AsyncResponse(target="port", operation="middle")
public void onMiddleAsyncResponse(AsyncPostCallContext apc, String message) {
System.out.println("-------------------");
System.out.println("Got message " + message );
System.out.println("-------------------");
}

@AsyncResponse(target="port", operation="finish")
public void onFinishAsyncResponse(AsyncPostCallContext apc, String message) {
System.out.println("-------------------");
System.out.println("Got message " + message );
System.out.println("-------------------");
}

@AsyncFailure(target="port", operation="start")
public void onStartAsyncFailure(AsyncPostCallContext apc, Throwable e) {
System.out.println("-------------------");
e.printStackTrace();
System.out.println("-------------------");
}

@AsyncFailure(target="port", operation="middle")
public void onMiddleAsyncFailure(AsyncPostCallContext apc, Throwable e) {
System.out.println("-------------------");
e.printStackTrace();
System.out.println("-------------------");
}

@AsyncFailure(target="port", operation="finish")
public void onFinishAsyncFailure(AsyncPostCallContext apc, Throwable e) {
System.out.println("-------------------");
e.printStackTrace();
System.out.println("-------------------");
}
}

7 コールバックによるクライアントへのイベントの通知

この章では、WebLogic Java API for XML-based RPC (JAX-RPC) Webサービスでコールバックを使用してクライアントにイベントを通知する方法について説明します。

この章では、以下のトピックについて説明します。

- コールバックの概要

- コールバックの実装の概要と用語

- コールバックのプログラミング: 主な手順

- ターゲットWebサービスのプログラミングのガイドライン

- コールバック・クライアントWebサービスのプログラミングのガイドライン

- コールバック・インタフェースのプログラミングのガイドライン

- クライアントWebサービスのbuild.xmlファイルの更新

コールバックの概要

コールバックは、なんらかのイベントが発生したことをWebサービスのクライアントに通知するものです。たとえば、クライアントのリクエストの結果が用意されたとき、または、クライアントのリクエストが実行できない場合に、クライアントに通知できます。

メソッドをJWSファイル内で(@WebMethodアノテーションを使用して)標準のパブリック操作として公開した場合は、クライアントがWebサービスにSOAPメッセージを送信して操作を呼び出します。一方、Webサービスにコールバックを追加する場合は、WebサービスからクライアントWebサービスに返送するメッセージを定義して、イベントが発生したことをそのメッセージでクライアントに通知します。つまり、メソッドをパブリック操作として公開することとコールバックを定義することは、送受信の方向が逆になった対照的なプロセスです。

WebLogic Serverでは、呼出し側のクライアントからのSOAPメッセージは、ターゲットWebサービスに自動的にルーティングされます。一方、クライアントがコールバックを受信するためには、クライアントが同じサービスを提供する環境で動作している必要があります。これは一般的に、クライアントがWebサーバー上で動作するWebサービスであることを意味します。クライアントがこれらの要件を満たしていない場合、通常はWebサービスからのコールバックを受信できません。

コールバックに使用されるプロトコルおよびメッセージ形式は、現在の会話を開始したメソッドで使用されているプロトコルおよびメッセージ形式と必ず同じになります。コールバックのプロトコルやメッセージ形式をオーバーライドしようとするとエラーがスローされます。

コールバックの実装の概要と用語

コールバックを実装するには、以下の3つのJavaファイルを作成または更新する必要があります。

- コールバック・インタフェース: コールバック・メソッドを定義するJavaインタフェース・ファイル。このファイルは明示的に実装するのではなく、jwsc Antタスクによってこのインタフェースの実装が自動的に生成されます。この実装によって、ターゲットWebサービスからクライアントWebサービスにメッセージが返送されます。生成されたWebサービスは、クライアントWebサービスをホストする同じWebLogic Serverにデプロイされます。
この節で示す例では、コールバック・インタフェースの名前をCallbackInterfaceとしています。このインタフェースには、単一のコールバック・メソッド、callbackOperation()が定義されています。

- ターゲットWebサービスを実装するJWSファイル: ターゲットWebサービスには、コールバック・インタフェースで定義されたメソッドを呼び出す1つ以上の標準操作が含まれます。このメソッドによって、ターゲットWebサービス操作の呼出し元のクライアントWebサービスにメッセージが返送されます。
例では、このWebサービスの名前がTargetServiceになっており、単一の標準メソッドtargetOperation()が定義されています。

- クライアントWebサービスを実装するJWSファイル: クライアントWebサービスは、ターゲットWebサービス操作を呼び出します。このWebサービスには、コールバック・メソッドを介してターゲットWebサービスからコールバック・メッセージを受け取ったときに、クライアントが実行すべき動作を指定する1つ以上のメソッドが含まれます。
例では、このWebサービスの名前がCallbackClientになっています。このWebサービスは、コールバックを受信すると、callbackHandler()というメソッドを自動的に呼び出します。clientOperation()は、TargetServiceを標準の方法で呼び出すメソッドです。

次の図に、メッセージの流れを示します。

1. あるWebLogic Serverインスタンスで動作するCallbackClient WebサービスのclientOperation()メソッドが、TargetServiceのtargetOperation()操作を明示的に呼び出します。TargetServiceサービスは、別のWebLogic Serverインスタンスで動作していてもかまいません。

2. TargetService.targetOperation()メソッドの実装が、コールバック・サービスを実装するCallbackInterfaceのcallbackOperation()操作を明示的に呼び出します。コールバック・サービスは、クライアントWebサービスをホストするWebLogic Serverにデプロイされています。

3. jwscによって生成されたCallbackInterface.callbackOperation()メソッドの実装は、単純にメッセージをCallbackClient Webサービスに返送します。クライアントWebサービスには、このメッセージを処理するcallbackHandler()メソッドが含まれています。

コールバックのプログラミング: 主な手順

この項の手順では、コールバックを実装するために必要な3つのJWSファイル(ターゲットWebサービス、クライアントWebサービス、コールバック・インタフェース)をプログラミングおよびコンパイルする方法について説明します。この手順では、これらのJWSファイルをゼロから作成する方法を示しています。既存のJWSファイルを更新する場合は、この手順をガイドとして利用してください。

Antベースの開発環境を設定済であり、かつjwsc Antタスクを実行してWebサービスをデプロイするためのターゲットを追加できる、作業用のbuild.xmlファイルがあることが前提となっています。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』を参照してください。

表7-1 コールバックのプログラミング手順

#

手順

説明

1

ターゲットWebサービスを実装する、新しいJWSファイルを作成するか、既存のJWSファイルを更新します。

使い慣れたIDEまたはテキスト・エディタを使用します。「ターゲットWebサービスのプログラミングのガイドライン」を参照してください。

注意: ターゲットWebサービスを実装するJWSファイルは、コールバック・インタフェースの1つ以上のコールバック・メソッドを呼び出します。(コールバック・インタフェースのプログラミング手順については後述の説明を参照してください。)したがって、この手順に従って順番にプログラミングするのではなく、3つのJWSファイルを同時にプログラミングすることをお薦めします。ここでは、各手順を理解しやすくするため、この順番で説明しています。

2

build.xmlファイルを更新して、ターゲットJWSファイルをWebサービスにコンパイルするjwsc Antタスクの呼出しを含めます。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のjwsc WebLogic WebサービスAntタスクの実行に関する項を参照してください。

3

Antターゲットを実行して、ターゲットWebサービスをビルドします。

例:

prompt> ant build-mainService

4

ターゲットWebサービスを通常どおりデプロイします。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

5

クライアントWebサービスを実装する、新しいJWSファイルを作成するか、既存のJWSファイルを更新します。

クライアントWebサービスは、ターゲットWebサービスをホストするものとは別のWebLogic Serverインスタンスにデプロイされていることが前提となっています。「コールバック・クライアントWebサービスのプログラミングのガイドライン」を参照してください。

6

コールバックWebサービスを実装するコールバックJWSインタフェースを作成します。

「コールバック・インタフェースのプログラミングのガイドライン」を参照してください。

7

クライアントWebサービスをビルドするbuild.xmlファイルを更新します。

クライアントWebサービスをビルドするjwsc Antタスクでは、コールバックWebサービスもコールバック・インタフェース・ファイルから暗黙的に生成されます。「クライアントWebサービスのbuild.xmlファイルの更新」を参照してください。

8

Antターゲットを実行して、クライアントおよびコールバックWebサービスをビルドします。

例:

prompt> ant build-clientService

9

クライアントWebサービスを通常どおりデプロイします。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

ターゲットWebサービスのプログラミングのガイドライン

次のサンプルでは、ターゲットWebサービスを実装する簡単なJWSファイルを示します。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.callback;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.Callback;

import javax.jws.WebService;
import javax.jws.WebMethod;

@WebService(name="CallbackPortType",
serviceName="TargetService",
targetNamespace="http://examples.org/")

@WLHttpTransport(contextPath="callback",
serviceUri="TargetService",
portName="TargetServicePort")

/**
* callback service
*/

public class TargetServiceImpl {

@Callback
CallbackInterface callback;

@WebMethod
public void targetOperation (String message) {

callback.callbackOperation (message);
}

}

ターゲットWebサービスを実装するJWSファイルをプログラミングする際には、次のガイドラインに従います。ガイドラインのコード・スニペットは、前述のサンプルでは太字で示されています。

- 必要なJWSアノテーションをインポートします。

import weblogic.jws.Callback;

- @weblogic.jws.Callback JWSアノテーションを使用して、変数がコールバックであることを指定します。つまり、アノテーション付き変数を使用して、TargetService Webサービス操作を呼び出したクライアントWebサービスにコールバック・イベントを返送できます。この変数のデータ型はコールバック・インタフェース(この場合はCallbackInterface)です。

@Callback
CallbackInterface callback;

- TargetService操作を実装するメソッドでは、アノテーション付き変数を使用してコールバック・インタフェースのコールバック・メソッドの1つ(この場合はcallbackOperation())を呼び出します。

callback.callbackOperation (message);

この項で説明したWebLogic固有のJWSアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のJWSアノテーション・リファレンスの項を参照してください。

コールバック・クライアントWebサービスのプログラミングのガイドライン

次のサンプルでは、「ターゲットWebサービスのプログラミングのガイドライン」で説明したターゲットWebサービスを呼び出すクライアントWebサービス用の簡単なJWSファイルを示します。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.callback;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.ServiceClient;
import weblogic.jws.CallbackMethod;
import weblogic.jws.security.CallbackRolesAllowed;
import weblogic.jws.security.SecurityRole;

import javax.jws.WebService;
import javax.jws.WebMethod;

import examples.webservices.callback.CallbackPortType;

import java.rmi.RemoteException;

@WebService(name="CallbackClientPortType",
serviceName="CallbackClientService",
targetNamespace="http://examples.org/")

@WLHttpTransport(contextPath="callbackClient",
serviceUri="CallbackClient",
portName="CallbackClientPort")

public class CallbackClientImpl {

@ServiceClient(
wsdlLocation="http://localhost:7001/callback/TargetService?WSDL",
serviceName="TargetService",
portName="TargetServicePort")
@CallbackRolesAllowed(@SecurityRole(role="mgr", mapToPrincipals="joe"))
private CallbackPortType port;

@WebMethod
public void clientOperation (String message) {

try {

port.targetOperation(message);
}
catch (RemoteException e) {
e.printStackTrace();
}

}
@CallbackMethod(target="port", operation="callbackOperation")
@CallbackRolesAllowed(@SecurityRole(role="engineer",  mapToPrincipals="shackell"))
public void callbackHandler(String msg) {

System.out.println (msg);
}

}

ターゲットWebサービスを呼び出すJWSファイルをプログラミングする際には、次のガイドラインに従います。ガイドラインのコード・スニペットは、前述のサンプルでは太字で示されています。

- 必要なJWSアノテーションをインポートします。

import weblogic.jws.ServiceClient;
import weblogic.jws.CallbackMethod;

- コールバック・メソッドの呼出しを許可するロールを指定したい場合は、必要に応じてセキュリティ関連のアノテーションをインポートします。

import weblogic.jws.security.CallbackRolesAllowed;
import weblogic.jws.security.SecurityRole;

- 呼び出すターゲットWebサービスのポート・タイプのJAX-RPCスタブをインポートします。実際のスタブそのものは、後でjwsc Antタスクによって作成されます。スタブ・パッケージは、<jws>の子要素<clientgen>のpackageName属性によって指定され、スタブの名前は呼び出されたWebサービスのWSDLによって決まります。

import examples.webservices.callback.CallbackPortType;

- JWSファイルの本文で、@ServiceClient JWSアノテーションを使用して、呼び出すターゲットWebサービスのWSDL、名前、およびポートを指定します。このアノテーションは、プライベート変数のフィールド・レベルで指定します。この変数のデータ型は、呼び出しているWebサービスのJAX-RPCポート・タイプとなります。

@ServiceClient(
wsdlLocation="http://localhost:7001/callback/TargetService?WSDL",
serviceName="TargetService",
portName="TargetServicePort")
@CallbackRolesAllowed(@SecurityRole(role="mgr", mapToPrincipals="joe"))
private CallbackPortType port;

このコードでは、省略可能な@CallbackRolesAllowedアノテーションを使用して、コールバック・メソッドの呼出しを許可する@SecurityRolesのリストを指定する方法も示されています。

- @ServiceClientアノテーションを付けた変数を使用して、ターゲットWebサービス操作を呼び出します。この操作によって、コールバック・インタフェースのコールバック・メソッドが呼び出されます。

port.targetOperation(message);

- コールバック・サービスから受信したコールバック・メッセージを処理するメソッドを作成します。このメソッドには自由に名前を付けることができます。ただし、そのシグネチャは、コールバック・インタフェース内の対応するメソッドのシグネチャと完全に一致させる必要があります。
メソッドに@CallbackMethodアノテーションを付けて、このメソッドでコールバック・メッセージを処理することを指定します。target属性を使用すると、コールバックを受信するJAX-RPCポートの名前(つまり、前の手順で@ServiceClientアノテーションを付けた変数)を指定できます。operation属性を使用すると、このメソッドで処理するコールバック・メッセージを送信するコールバック・インタフェース内のコールバック・メソッドの名前を指定できます。

@CallbackMethod(target="port", operation="callbackOperation")
@CallbackRolesAllowed(@SecurityRole(role="engineer",  mapToPrincipals="shackell"))
public void callbackHandler(String msg) {
System.out.println (msg);
}

このコードでは、省略可能な@CallbackRolesAllowedアノテーションを使用して、この特定のコールバック・メソッドの呼出しを許可するセキュリティ・ロールをさらに制限する方法も示されています。

この項で説明したWebLogic固有のJWSアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のJWSアノテーション・リファレンスの項を参照してください。

コールバック・インタフェースのプログラミングのガイドライン

コールバック・インタフェースも、Webサービスを実装したJWSファイルです。ただし、大きな違いが1つあります。コールバック・インタフェースでは、標準の@javax.jws.WebServiceアノテーションを使用して標準のWebサービスであることを指定するかわりに、WebLogic固有の@weblogic.jws.CallbackServiceを使用してコールバック・サービスであることを指定します。@CallbackServiceの属性は、@WebServiceの属性の限定的なサブセットです。

コールバック・サービスを実装するJWSファイルをプログラミングする場合は、使用できるデータ型およびJWSアノテーションについて以下の制約があります。

- @weblogic.jws.CallbackService以外のWebLogic固有のJWSアノテーションを使用することはできません。

- 以下を除くすべての標準JWSアノテーションを使用できます。

- javax.jws.HandlerChain

- javax.jws.soap.SOAPMessageHandler

- javax.jws.soap.SOAPMessageHandlers

- Holderクラス(javax.xml.rpc.holders.Holderインタフェースを実装するユーザー定義のデータ型)を除き、サポートされているすべてのデータ型をパラメータまたは戻り値として使用できます。

次の例では、コールバックWebサービスを実装する簡単なコールバック・インタフェース・ファイルを示します。まず、「ターゲットWebサービスのプログラミングのガイドライン」で説明したターゲットWebサービスが、このインタフェースのメソッドを明示的に呼び出します。次に、jwscによって生成されたコールバック・インタフェースの実装が、ターゲットWebサービスの呼出し元のクライアントWebサービスにメッセージを自動的に返送します。クライアントWebサービスについては「コールバック・クライアントWebサービスのプログラミングのガイドライン」を参照してください。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.callback;

import weblogic.jws.CallbackService;

import javax.jws.Oneway;
import javax.jws.WebMethod;

@CallbackService
public interface CallbackInterface {

@WebMethod
@Oneway
public void callbackOperation (String msg);

}

コールバックWebサービスを実装するJWSファイルをプログラミングする際には、次のガイドラインに従います。ガイドラインのコード・スニペットは、前述のサンプルでは太字で示されています。

- 必要なJWSアノテーションをインポートします。

import weblogic.jws.CallbackService;

- インタフェース宣言に@CallbackServiceアノテーションを付けて、JWSファイルがコールバック・サービスを実装することを指定します。

@CallbackService
public interface CallbackInterface {

- ターゲットWebサービスが明示的に呼び出すメソッドを作成します。このメソッドは、ターゲットWebサービスの呼出し元のクライアント・サービスにメッセージを自動的に返信するメソッドです。このメソッドの実装は、Javaインタフェース・ファイルであるこのファイルでは提供しません。どちらかというと、WebLogic Webサービス・ランタイムは、jwsc Antタスクでメソッドの実装を生成します。

public void callbackOperation (String msg);

注意:
このサンプルのコールバック・メソッドは、voidを返し、@Onewayアノテーションが付けられていますが、必ずしもこのように設定する必要はありません。

この項で説明したWebLogic固有のJWSアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のJWSアノテーション・リファレンスの項を参照してください。

クライアントWebサービスのbuild.xmlファイルの更新

クライアントWebサービスを実装するJWSファイルに対してjwsc Antタスクを実行すると、この項で説明するように、コールバックWebサービスも暗黙的に生成されます。

build.xmlファイルを更新して、ターゲットWebサービスを呼び出すクライアントWebサービスを生成するには、次のサンプルのようなtaskdefsおよびbuild-clientServiceターゲットを追加します。詳細は、サンプルの後の説明を参照してください。

<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />

<target name="build-clientService">

<jwsc
srcdir="src"
destdir="${clientService-ear-dir}" >

<jws file="examples/webservices/callback/CallbackClientImpl.java" >

<clientgen
wsdl="http://${wls.hostname}:${wls.port}/callback/TargetService?WSDL"
packageName="examples.webservices.callback"
serviceName="TargetService" />

</jws>

</jwsc>

</target>

jwsc Antタスクの完全なクラス名を定義するには、taskdef Antタスクを使用します。

クライアントWebサービスをコンパイルするjwsc Antタスクを更新して、<jws>要素の<clientgen>子要素を含めます。これにより、デプロイされたTargetService WebサービスのJAX-RPCスタブが生成およびコンパイルされるようになります。jwsc Antタスクでは、これらのスタブが生成されたWARファイルに自動的にパッケージ化されるため、即座にクライアントWebサービスからアクセスできるようになります。このようにするのは、生成されたクラスの1つをCallbackClientImpl JWSファイルでインポートして使用するためです。

ターゲットWebサービスのWSDLには、ターゲットWebサービスから呼び出されるコールバックWebサービスを表す追加の<service>要素が含まれています。このため、jwsc Antタスクの<clientgen>子要素によってコールバックWebサービスも生成およびコンパイルされ、クライアントWebサービスと同じEARファイルにパッケージ化されます。

8 接続プロトコルとしてのJMSトランスポートの使用

この章では、非同期リクエスト-レスポンスを使用するWebLogic Java API for XML-based RPC (JAX-RPC) Webサービスで、JMSトランスポートを接続プロトコルとして使用する方法について説明します。

この章では、以下のトピックについて説明します。

- JMSトランスポートの使用の概要

- Javaから開始するJMSトランスポートの使用: 主な手順

- WSDLから開始するJMSトランスポートの使用: 主な手順

- JMSトランスポートWebサービスのホストWebLogic Serverインスタンスの構成

- @WLJmsTransport JWSアノテーションの使用

- jwsc Antタスクの<WLJmsTransport>子要素の使用

- JMSトランスポートを使用したWebLogic Webサービスの呼出し

JMSトランスポートの使用の概要

通常、クライアント・アプリケーションからWebLogic Webサービスを呼び出すときは、接続プロトコルとしてHTTP/Sが使用されます。しかし、クライアント・アプリケーションがトランスポートとしてJMSを使用するようにWebLogic Webサービスを構成することもできます。

JMSトランスポートを使用すると、信頼性、スケーラビリティ、サービス品質が向上します。Webサービスの信頼性のあるメッセージングの場合と同様に、メソッド呼出しがまだキューに入っているときにWebLogic Serverが停止しても、再起動すればすぐに処理が行われます。クライアントは、Webサービスを呼び出す際に呼出しからのレスポンスを待機しないため、クライアントの実行は続行可能です。ただし、JMSトランスポートを使用する場合は、HTTP/Sより若干オーバーヘッドが大きくなり、プログラムが複雑になります。

トランスポートを構成するには、後の項で説明するように、JWSアノテーションとjwsc Antタスクの子要素のどちらかを使用します。接続トランスポートとしてJMSを使用するようにWebLogic Webサービスを構成した場合、Webサービスの生成済WSDLで対応するポートに対して指定されたエンドポイント・アドレスのURLでは、http://ではなくjms://が使用されます。JMSエンドポイントのアドレスの例を次に示します。

jms://myHost:7001/transports/JMSTransport?URI=JMSTransportQueue

URLのURI=JMSTransportQueueセクションでは、JMSトランスポート機能用に構成されたJMSキューを指定しています。HTTPを使用してWebサービスを呼び出すことはできませんが、HTTPを使用してそのWebサービスのWSDLを参照できます。これにより、clientgenはやはりWebサービスのJAX-RPCスタブを生成できます。

指定する各トランスポートに対し、WebLogic ServerはWSDL内に追加のポートを生成します。このため、Webサービス呼出し時に使用できるトランスポート(JMS、HTTP、またはHTTPS)をクライアント・アプリケーションで選択できるようにするには、適切なJWSアノテーションまたはjwscの子要素を使用して、明示的にトランスポートを追加する必要があります。

注意:
JMSトランスポートの使用は、WebLogicの付加価値機能です。.NETクライアントなど、WebLogic以外のクライアント・アプリケーションでは、JMSポートを使用してWebサービスを呼び出すことができない場合があります。

Javaから開始するJMSトランスポートの使用: 主な手順

Javaから開始する際にJMSトランスポートを使用するには、以下の少なくとも1つのタスクを実行する必要があります。

- JWSファイルに@WLJmsTransportアノテーションを追加します。

- jwsc Antタスクに<WLJmsTransport>子要素を追加します。この設定は、JWSファイルで定義されたトランスポートをオーバーライドします。

注意:
JWSファイルのコーディング時にはニーズに最適なトランスポートがわからない場合があるため、トランスポートは、<WLJmsTransport>子要素を使用してビルド時に指定することをお薦めします。

次の手順では、Javaから開始する際に、JMSトランスポートを使用して現在のWebサービスを呼び出すために必要なすべての手順について説明します。

注意:
Webサービスを実装する基本的なJWSファイルが作成されており、JMSを使用して呼び出すWebサービスを構成することが前提となっています。また、Antベースの開発環境を設定済であり、かつjwsc Antタスクを実行してサービスをデプロイするためのターゲットを含む、作業用のbuild.xmlファイルがあることも前提となっています。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』を参照してください。

表8-1 Javaから開始するJMSトランスポートの使用手順

#

手順

説明

1

必要なJMSコンポーネント用にWebLogic Serverドメインを構成します。

「JMSトランスポートWebサービスのホストWebLogic Serverインスタンスの構成」を参照してください。

2

JWSファイルに@WLJmsTransportアノテーションを追加します。(オプション)

この手順は省略可能です。現在のJWSに@WLJmsTransportアノテーションを追加しない場合、<WLJmsTransport>子要素をjwsc Antタスクに追加する必要があります(ステップ3を参照)。

「@WLJmsTransport JWSアノテーションの使用」を参照してください。

3

jwsc Antタスクに<WLJmsTransport>子要素を追加します。(オプション)

<WLJmsTransport>子要素を使用して、JWSファイルで定義されているトランスポートをオーバーライドします。この手順は、ステップ2で@WLJmsTransportアノテーションをJWSファイルに追加しなかった場合に必須です。それ以外の場合、この手順は省略可能です。

詳細については、「jwsc Antタスクの<WLJmsTransport>子要素の使用」を参照してください。

4

jwscタスクを呼び出すbuild.xml Antファイル内のターゲットを実行することにより、Webサービスをビルドします。

たとえば、jwsc Antタスクを呼び出すターゲットがbuild-serviceというものであれば、以下を実行します。

prompt> ant build-service

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のjwsc WebLogic WebサービスAntタスクの実行に関する項を参照してください。

5

WebサービスをWebLogic Serverにデプロイします。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

JMSトランスポートを使用してWebサービスを呼び出すようにクライアント・アプリケーションを更新する方法については、「JMSトランスポートを使用したWebLogic Webサービスの呼出し」を参照してください。

WSDLから開始するJMSトランスポートの使用: 主な手順

WSDLから開始する際にJMSトランスポートを使用するには、以下の少なくとも1つのタスクを実行する必要があります。

- wsdlc Antタスクを実行する前に、JMSトランスポートを使用するようにWSDLを更新します。

- @WLJmsTransportアノテーションを追加するように、wsdlc Antタスクによって生成される途中まで作成済みのJWS実装ファイルを更新します。

- JWS実装ファイルの作成に使用されるjwsc Antタスクに<WLJmsTransport>子要素を追加します。この設定は、JWSファイルで定義されたトランスポートをオーバーライドします。

注意:
JWSファイルのコーディング時にはニーズに最適なトランスポートがわからない場合があるため、トランスポートは、<WLJmsTransport>子要素を使用してビルド時に指定することをお薦めします。

次の手順では、WSDLから開始する際に、JMSトランスポートを使用して現在のWebサービスを呼び出すために必要なすべての手順について説明します。

注意:
この手順では既存のWSDLファイルがあることを前提としています。

表8-2 WSDLから開始するJMSトランスポートの使用手順

#

手順

説明

1

必要なJMSコンポーネント用にWebLogic Serverドメインを構成します。

「JMSトランスポートWebサービスのホストWebLogic Serverインスタンスの構成」を参照してください。

2

JMSトランスポートを使用するようWSDLを更新する(オプション)

この手順は省略可能です。JMSトランスポートを使用するようWSDLを更新しなかった場合、以下の少なくとも1つの作業を行う必要があります。

- 途中まで作成済みのJWSファイルを編集して@WLJmsTransportアノテーションをJWSファイルに追加します(ステップ4を参照)。

- <WLJmsTransport>子要素をjwsc Antタスクに追加します(ステップ5を参照)。

「JMSトランスポートを使用するためのWSDLの更新」を参照してください。

3

WSDLファイルに対してwsdlc Antタスクを実行します。

たとえば、wsdlc Antタスクを呼び出すターゲットがgenerate-from-wsdlというものであれば、以下を実行します。

prompt> ant generate-from-wsdl

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のwsdlc WebLogic WebサービスAntタスクの実行に関する項を参照してください。

4

途中まで作成済みのJWSファイルを更新します。

wsdlc Antタスクにより途中まで作成済のJWSファイルが生成されます。必要な動作をWebサービスに実装するには、独自のビジネス・コードをWebサービスに追加する必要があります。『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のwsdlcで生成される途中まで作成済のJWS実装クラス・ファイルの更新に関する項を参照してください。

ステップ2で、JMSトランスポートを使用するようにWSDLを更新した場合、JWSファイルには、JMSトランスポートを定義する@WLJmsTransportアノテーションが含まれます。@WLJmsTransportアノテーションがJWSファイルに含まれない場合、以下の少なくとも1つの作業を行う必要があります。

- JWSファイルを編集して、@WLJmsTransportアノテーションをJWSファイルに追加します(「@WLJmsTransport JWSアノテーションの使用」を参照)。

- <WLJmsTransport>子要素をjwsc Antタスクに追加します(ステップ5を参照)。

5

jwsc Antタスクに<WLJmsTransport>子要素を追加します。(オプション)

<WLJmsTransport>子要素を使用して、JWSファイルで定義されているトランスポートをオーバーライドします。JWSファイルに@WLJmsTransportアノテーションが含まれない場合、この手順は必須です(ステップ4を参照)。それ以外の場合、この手順は省略可能です。

詳細については、「jwsc Antタスクの<WLJmsTransport>子要素の使用」を参照してください。

6

JWSファイルに対してjwsc Antタスクを実行し、Webサービスをビルドします。

wsdlc Antタスクによって生成されたアーティファクトと更新したJWS実装ファイルを指定して、Webサービスを実装するエンタープライズ・アプリケーションを生成します。『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のjwsc WebLogic WebサービスAntタスクの実行に関する項を参照してください。

7

WebサービスをWebLogic Serverにデプロイします。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項を参照してください。

JMSトランスポートを使用してWebサービスを呼び出すようにクライアント・アプリケーションを更新する方法については、「JMSトランスポートを使用したWebLogic Webサービスの呼出し」を参照してください。

JMSトランスポートWebサービスのホストWebLogic Serverインスタンスの構成

JMSトランスポートWebサービスのデプロイ先となるWebLogic Serverインスタンスを構成する際には、Webサービスのランタイムで内部的に使用される、JMSサーバーやモジュールなどのJMSリソースを構成します。

これらのリソースは手作業でも構成できますが、構成ウィザードで、Webサービス固有の拡張テンプレートを使用してWebLogic Serverドメインを拡張することもできます。構成ウィザードを使用すると、必要な構成手順を大幅に簡略化できます。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービス機能用のドメイン構成に関する項を参照してください。

注意:
または、WLSTを使用してリソースを構成することもできます。WLSTを使用してドメインを拡張する方法については、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。
Webサービス・リソースを含まないドメインは、Webサービスと関連のないシナリオや、非同期のリクエストおよびレスポンスを呼び出さないWebサービスのシナリオであれば、適切に起動して実行されます。ただし、サーバー・ログには、非同期リソースが構成されていないことと、Webサービス用の非同期レスポンス・サービスが完全にデプロイされていないことを示すINFOメッセージが表示されます。

リソースを手作業で構成する場合、以下の手順を実行します。

表8-3 JMSトランスポートWebサービスのホストWebLogic Serverインスタンスを手作業で構成する手順

#

手順

説明

1

ホストWebLogic Serverインスタンスが格納されたドメインの管理コンソールを起動します。

ブラウザで管理コンソールを起動するには、次のURLを入力します。

http://host:port/console

ここで

- hostは、管理サーバーが動作しているコンピュータを指します。

- portは、管理サーバーが接続リクエストをリスニングしているポート番号を指します。管理サーバーのデフォルトのポート番号は7001です。

『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』の管理コンソールの起動に関する項を参照してください。

3

JMSサーバーを作成します。

JMSサーバーを作成します。JMSサーバーがすでに存在する場合は、新しいJMSサーバーを作成せずにそれを使用できます。

Oracle WebLogic Server管理コンソール・ヘルプのJMSサーバーの作成に関する項を参照してください。

4

JMSモジュールを作成し、キューを定義します。

JMSモジュールを作成し、その中にJMSキューを定義します。JMSモジュールがすでに存在する場合は、新しいJMSモジュールを作成せずにそれを使用することもできます。JMSキューを、1つ前の手順で作成したJMSサーバーにターゲット指定します。このJMSキューがローカルであることを必ず指定してください(通常は、ローカルJNDI名の設定により指定できます)。Oracle WebLogic Server管理コンソール・ヘルプのJMSシステム・モジュールの作成に関する項とシステム・モジュールのキューの作成に関する項を参照してください。

JMSトランスポートWebサービスで、デフォルトWebサービスのキューを使用する場合は、JMSキューのJNDI名をweblogic.wsee.DefaultQueueに設定します。そうではなく、別のJNDI名を使用する場合は、@WLJmsTransportアノテーションまたはjwsc Antタスクの子要素<WLJmsTransport>を指定する際にキュー名を指定する必要があります。

クラスタリングの考慮事項:

クラスタ内でWebサービスのJMSトランスポート機能を使用する場合は、次の作業を行う必要があります。

- JMSキューの作成時に、分散キューではなくローカルJMSキューを作成します。

- このJMSキューをクラスタ内の各サーバーに明示的にターゲット指定します。

@WLJmsTransport JWSアノテーションの使用

JWSファイルをプログラムした時点で、Webサービスの呼出しにクライアント・アプリケーションで(HTTP/Sではなく) JMSトランスポートを使用することが決まっている場合は、@WLJmsTransportを使用してその呼出しの詳細を指定できます。後のビルド時に、「jwsc Antタスクの<WLJmsTransport>子要素の使用」に従い、jwsc Antタスクの<WLJmsTransport>子要素を指定して、JWSファイルで定義されている呼出しをオーバーライドし、さらにJMSトランスポート指定を追加できます。

@WLJmsTransportアノテーションを使用する際は、これらのガイドラインに従ってください:

- JWSファイルに含めることができる@WLJmsTransportアノテーションは1つのみです。

- これより前の部分で構成したJMSキューのJNDI名の指定にはqueue属性を使用します。デフォルトのWebサービス・キュー(weblogic.wsee.DefaultQueue)を使用する場合は、queue属性を指定する必要はありません。

- 接続ファクトリのJNDI名の指定にはconnectionFactory属性を使用します。この属性のデフォルト値は、WebLogic ServerインスタンスのデフォルトのJMS接続ファクトリです。

次の例では、@WLJmsTransportアノテーションを使用する簡単なJWSファイルを示します。関連するコードは太字で示しています。

package examples.webservices.jmstransport;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;

import weblogic.jws.WLJmsTransport;

@WebService(name="JMSTransportPortType",
serviceName="JMSTransportService",
targetNamespace="http://example.org")

@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)

// WebLogic-specific JWS annotation that specifies the context path and
// service URI used to build the URI of the Web Service is
// "transports/JMSTransport"

@WLJmsTransport(contextPath="transports", serviceUri="JMSTransport",
queue="JMSTransportQueue", portName="JMSTransportServicePort",
connectionFactory="JMSTransportConnectionFactory")

/**
* This JWS file forms the basis of simple Java-class implemented WebLogic
* Web Service with a single operation: sayHello
*/

public class JMSTransportImpl {

@WebMethod()
public String sayHello(String message) {
System.out.println("sayHello:" + message);
return "Here is the message: '" + message + "'";
}
}

jwsc Antタスクの<WLJmsTransport>子要素の使用

JMSトランスポートはjwsc Antタスクの<jws>要素の<WLJmsTransport>子要素を使用して、ビルド時にも指定できます。ビルド時にトランスポートを指定する理由としては、次のようなものが挙げられます。

- JWSファイルで指定した属性値をオーバーライドする必要があります。

- JWSファイルでは別のトランスポートが指定されており、ビルド時に、JMSをトランスポートとして使用すると決定しました。

- JWSファイルに@WLXXXTransportアノテーションが含まれていないため、デフォルトではHTTPトランスポートが使用されていますが、ビルド時にJMSトランスポートを使用してWebサービスを呼び出すと決定しました。

jwsc Antタスクに対してトランスポートを指定すると、それがJWSファイル内のすべてのトランスポート・アノテーションに優先されます。

次の例では、jwsc Antタスクに対してトランスポートを指定する方法を示します。

<target name="build-service">

<jwsc
srcdir="src"
destdir="${ear-dir}">
<jws file="examples/webservices/jmstransport/JMSTransportImpl.java">

<WLJmsTransport
contextPath="transports"
serviceUri="JMSTransport"
portName="JMSTransportServicePort"
queue="JMSTransportQueue"
connectionFactory="JMSTransportConnectionFactory"/>

</jws>

</jwsc>

</target>

上述の例では、「@WLJmsTransport JWSアノテーションの使用」に示したJWSファイルで指定されたものと同じ値をURLおよびJMSキューに対して指定する方法を示しています。

jwsc Antタスクの使用方法の詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のjwscに関する項を参照してください。

JMSトランスポートを使用するためのWSDLの更新

JMSトランスポートを使用するようにWSDLを更新するには、JMSトランスポート情報を定義する<wsdl:binding>定義と<wsdl:service>定義を追加する必要があります。これらの定義は、以下のいずれかの方法で追加できます。

- 既存のHTTPの<wsdl:binding>および<wsdl:service>定義を編集します。

- WSDLで複数のトランスポート・オプションを指定するには、既存のHTTPの<wsdl:binding>および<wsdl:service>定義をコピーし、JMSトランスポートを使用するように編集します。

どちらの場合でも、JMSトランスポートを使用するように<wsdl:binding>および<wsdl:service>定義を以下のように変更する必要があります。

- <wsdl:binding>要素の子要素<soapwsdl:binding>のtransport属性をhttp://www.openuri.org/2002/04/soap/jmsに設定します。例:

<binding name="JmsTransportServiceSoapBindingjms" type="tns:JmsTransportPortType">
<soap:binding style="document" transport="http://www.openuri.org/2002/04/soap/jms/"/>

- <wsdl:service>の子要素<soapwsdl:address>のlocation属性に、JMS形式のエンドポイントURLを指定します。例:

<s0:service name="JmsTransportService">
<s0:port binding="s1:JmsTransportServiceSoapBindingjms" name="JmsTransportServicePort">
<s2:address location="jms://localhost:7001/transports/JmsTransport?URI=JMSTransportQueue"/>
</s0:port>
</s0:service>

JMSトランスポートを使用したWebLogic Webサービスの呼出し

JMSトランスポートを使用してWebサービスを呼び出すクライアント・アプリケーションの記述は、HTTPトランスポートを使用する場合の記述と同様に行います。ただ1つ異なるのは、必ず、JMSキュー(@WLJmsTransportアノテーションまたはjwsc Antタスクの<WLJmsTransport>子要素で指定)とその他のJMSオブジェクトが作成済でなければならないという点です。詳細については、「Javaから開始するJMSトランスポートの使用: 主な手順」または「WSDLから開始するJMSトランスポートの使用: 主な手順」を参照してください。

HTTPを使用してJMSトランスポートで構成されたWebサービスを呼び出すことはできませんが、HTTPを使用してそのWebサービスのWSDLを参照することはできます。これにより、clientgen AntタスクはWebサービスのJAX-RPCスタブを作成することができます。たとえば、この項で示すWebサービスのWSDLのためのURLは、次のようになります。

http://host:port/transports/JMSTransport?WSDL

ただし、デプロイされたWebサービスのWSDLにおけるエンドポイント・アドレスでは、http://ではなくjms://が使用され、このアドレスには修飾子?URI=JMS_QUEUEが含まれるため、clientgen AntタスクはWebサービス呼出し時にJMSトランスポートを使用するために必要なスタブを自動作成し、クライアント・アプリケーション側で通常と違う処理を行う必要はありません。JMSエンドポイントのアドレスの例を次に示します。

jms://host:port/transports/JMSTransport?URI=JMSTransportQueue

注意:
JMSトランスポートを使用して呼び出すWebサービスをトランザクションのコンテキスト内でも実行することを指定した(つまり、JWSファイルに@weblogic.jws.Transactionalアノテーションが含まれている)場合は、そのサービスを呼び出す際に非同期リクエスト-レスポンスを使用する必要があります。そうしないと、デッドロックが発生して呼出しが失敗します。

Webサービス呼出しに関する一般情報は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービスの呼出しに関する項を参照してください。

デフォルトのサービス・アドレスURLのオーバーライド

clientgenで生成されたJAX-RPCスタブを使用してWebサービスを呼び出すクライアント・アプリケーションを作成する場合、Webサービスのデフォルトのサービス・アドレスURLは、ServiceコンストラクタのWSDLファイル引数の<address>要素で指定したものとなります。

ただし、場合によっては、特にクラスタにデプロイされているWebLogic Webサービスを呼び出す際に、クラスタのアドレスまたはクラスタ内の管理対象サーバーのアドレスのリストを指定する場合には、このアドレスをオーバーライドする必要があることがあります。また、t3プロトコルを使用してWebサービスを呼び出すことが必要な場合もあります。JMSトランスポートの使用時にこのサービス・エンドポイントURLをオーバーライドするには、次の例で示すように、weblogic.wsee.jaxrpc.WLStub.JMS_TRANSPORT_JNDI_URLスタブ・プロパティを使用します。

package examples.webservices.jmstransport.client;

import weblogic.wsee.jaxrpc.WLStub;

import java.rmi.RemoteException;

import javax.xml.rpc.ServiceException;
import javax.xml.rpc.Stub;

/**
* This is a simple standalone client application that invokes the
* the <code>sayHello</code> operation of the JMSTransport Web service.
*/

public class Main {

public static void main(String[] args)
throws ServiceException, RemoteException{

JMSTransportService service = new JMSTransportService_Impl(args[0] + "?WSDL" );
JMSTransportPortType port = service.getJMSTransportServicePort();

Stub stub = (Stub) port;

stub._setProperty(WLStub.JMS_TRANSPORT_JNDI_URL,
"t3://shackell01.amer.com:7001");
try {
String result = null;

result = port.sayHello("Hi there! ");

System.out.println( "Got JMS result: " + result );

} catch (RemoteException e) {
throw e;
}
}
}

その他のスタブ・プロパティについては、Oracle WebLogic Server APIリファレンスのWLStubに関する項を参照してください。

デフォルトのTextMessageのかわりとしてのJMS BytesMessageの使用

JMSトランスポートを使用する場合、Webサービス・ランタイムは、デフォルトではjavax.jms.TextMessageオブジェクトを使用してメッセージを送信します。ほとんどのクライアント・アプリケーションはこのデフォルトのままで十分ですが、状況によっては普通のテキストではなくバイナリ・データを送信する必要がある場合もあります。その場合は、Webサービス・ランタイムでjavax.jms.BytesMessageを使用することをリクエストする必要があります。そのためには、クライアント・アプリケーションでWLStub.JMS_TRANSPORT_MESSAGE_TYPEスタブ・プロパティを使用し、値としてWLStub.JMS_BYTESMESSAGEを設定します。次に例を示します。

stub._setProperty(WLStub.JMS_TRANSPORT_MESSAGE_TYPE,
WLStub.JMS_BYTESMESSAGE);

Webサービス・ランタイムは、リクエストと同じメッセージ・データ型を使用してレスポンスを戻します。

このプロパティを設定できるクライアント・アプリケーションの例については、「デフォルトのサービス・アドレスURLのオーバーライド」を参照してください。その他のスタブ・プロパティについては、Oracle WebLogic Server APIリファレンスのWLStubに関する項を参照してください。

WSDLファイルへのHTTPアクセスの無効化

「JMSトランスポートを使用したWebLogic Webサービスの呼出し」で説明したように、デプロイされているWebサービスのWSDLには、デフォルトでHTTPでアクセスできるようになっています。WSDLファイルへのアクセスを無効にする場合(特に、ファイアウォールの外でWebサービスにアクセスできる場合)は、次のいずれかを実行します。

- JWSファイルで、weblogic.jws.WSDLアノテーションを使用してプログラム的にアクセスを無効にします。詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.WSDLに関する項を参照してください。

- Webサービスをデプロイした後に、管理コンソールを使用してWSDLへのアクセスを無効にします。この場合、構成情報は、アノテーションではなくデプロイメント・プラン内に格納されます。
このタスクを管理コンソールを使用して実行する場合は、デプロイしたWebサービスの「構成」→「全般」ページに移動し、「動的WSDLの表示を有効化」チェック・ボックスの選択を解除します。この変更を有効にするには、構成をデプロイメント・プランに保存した後に、Webサービス(またはそのエンタープライズ・アプリケーション)を再デプロイ(更新)する必要があります。

9 SOAPメッセージ・ハンドラの作成と使用

この章では、WebLogic Java API for XML-based RPC (JAX-RPC) Webサービスで、SOAPメッセージ・ハンドラを作成および使用する方法について説明します。

この章では、以下のトピックについて説明します。

- SOAPメッセージ・ハンドラの概要

- SOAPメッセージ・ハンドラのWebサービスへの追加: 主な手順

- SOAPメッセージ・ハンドラおよびハンドラ・チェーンの設計

- GenericHandlerクラスの作成

- JWSファイルでのハンドラの構成

- ハンドラ・チェーン構成ファイルの作成

- Webサービスのコンパイルと再ビルド

- クライアント側SOAPメッセージ・ハンドラの作成と使用

SOAPメッセージ・ハンドラの概要

Webサービスの中には、SOAPメッセージへのアクセスを必要とするものがあります。このSOAPメッセージに対してSOAPメッセージ・ハンドラを作成できます。

SOAPメッセージ・ハンドラは、Webサービスのリクエストとレスポンスの両方でSOAPメッセージをインターセプトするメカニズムです。ハンドラは、WebサービスそのものとWebサービスを呼び出すクライアント・アプリケーションの両方で作成することができます。

ハンドラ使用の簡単な例としては、SOAPメッセージのヘッダー部分の情報へのアクセスがあります。SOAPのヘッダーを使用してWebサービス固有の情報を格納しておき、ハンドラを使用してその情報を操作することができます。

SOAPメッセージ・ハンドラは、Webサービスのパフォーマンスを向上させるために使用することもできます。Webサービスがデプロイされてしばらくすると、同じパラメータを使用してWebサービスを呼び出すコンシューマが多いことに気付く場合があります。よく使用されるWebサービス呼出しの結果をキャッシュしておき(結果が静的であることが前提となります)、適宜、キャッシュしておいた結果をただちに戻すことによって、Webサービスを実装したバックエンド・コンポーネントを呼び出す必要がなくなり、Webサービスのパフォーマンスが向上します。このパフォーマンスの向上は、ハンドラを使用して、SOAPリクエスト・メッセージに頻繁に使用されるパラメータが含まれていないかチェックすることで実現できます。

次の表では、Webサービスでハンドラ・チェーンが構成されていることを指定するためにJWSファイル内で使用できる標準的なJWSアノテーションを示しています。その後の項で、これらのアノテーションの使い方について、より詳細に説明します。詳細は、http://www.jcp.org/en/jsr/detail?id=181にある「Web Services MetaData for the Java Platform (JSR-181)仕様」を参照してください。

表9-1 SOAPメッセージ・ハンドラ・チェーンの構成に使用されるJWSアノテーション

JWSアノテーション

説明

javax.jws.HandlerChain

Webサービスを外部で定義されるハンドラ・チェーンと関連付けます。複数のWebサービスで同じハンドラ構成を共有する必要がある場合、またはハンドラ・チェーンが複数のトランスポートのハンドラで構成されている場合は、このアノテーションを使用します。

javax.jws.soap.SOAPMessageHandlers

各Webサービス操作の呼出し前と呼出し後に実行されるSOAPハンドラのリストを指定します。外部構成ファイルを使用するよりも、JWSファイルそのものにハンドラ構成情報を埋め込む方が望ましい場合は、(@HandlerChainではなく)このアノテーションを使用します。

@SOAPMessageHandlerアノテーションは、@SOAPMessageHandlersの配列です。ハンドラは、この配列内にリストされている順番で実行されます。

注意: このアノテーションは、JAX-RPC Webサービスでのみ機能します。

javax.jws.soap.SOAPMessageHandler

単一のSOAPメッセージ・ハンドラを@SOAPMessageHandlers配列で指定します。

次の表では、javax.xml.rpc.handler APIのメイン・クラスおよびインタフェースについて説明します。これらの一部は、ハンドラそのものの作成時に使用します。これらのAPIについては、後の節でより詳細に説明します。これらのAPIの詳細は、http://java.net/projects/jax-rpc/にある「JAX-RPC 1.1仕様」を参照してください。

表9-2 JAX-RPCハンドラのインタフェースとクラス

javax.xml.rpc.handlerのインタフェースとクラス

説明

Handler

ハンドラ作成時に実装される主なインタフェース。SOAPのリクエスト、レスポンス、およびフォルトを処理するメソッドが格納されています。

GenericHandler

Handlerインタフェースを実装する抽象クラス。ハンドラ作成時には、Handlerを直接実装するのではなく、このクラスを拡張します。

GenericHandlerクラスは、ハンドラの記述を容易にする便利な抽象クラスです。このクラスは、ライフサイクル・メソッドinitおよびdestroy、ならびに様々な処理メソッドのデフォルト実装を提供します。ハンドラの開発者は、派生したハンドラ実装クラスの一部として特化する必要があるメソッドのみをオーバーライドします。

HandlerChain

ハンドラのリストを表すインタフェース。HandlerChainインタフェースの実装クラスは、登録されているハンドラの呼出しに関するポリシーとメカニズムを抽象化します。

HandlerRegistry

HandlerRegistry内のハンドラのプログラムによる構成に対するサポートを提供するインタフェース。

HandlerInfo

ハンドラ・チェーン内のハンドラの情報が格納されているクラス。HandlerInfoインスタンスがHandler.initメソッドに渡されて、Handlerインスタンスが初期化されます。

MessageContext

ハンドラによって処理されたメッセージのコンテキストを抽出します。MessageContextプロパティにより、ハンドラ・チェーン内のハンドラは処理ステートを共有できます。

soap.SOAPMessageContext

SOAPメッセージの取得または更新に使用されるMessageContextインタフェースのサブインタフェース。

javax.xml.soap.SOAPMessage

実際のSOAPのリクエスト・メッセージまたはレスポンス・メッセージが入ったオブジェクト。ヘッダー、本文、添付ファイルが含まれます。

SOAPメッセージ・ハンドラのWebサービスへの追加: 主な手順

次の手順では、WebサービスにSOAPメッセージ・ハンドラを追加する手順を大まかに説明します。

Webサービスを実装する基本的なJWSファイルを作成済であり、SOAPメッセージ・ハンドラおよびハンドラ・チェーンを追加してWebサービスを更新することが前提となっています。また、Antベースの開発環境を設定済であり、かつjwsc Antタスクを実行するためのターゲットを含む、作業用のbuild.xmlファイルがあることも前提となっています。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』を参照してください。

- 使用例とサンプル

- WebLogic Webサービスの開発

- JWSファイルのプログラミング

- Webサービスの呼出し

表9-3 WebサービスへのSOAPメッセージ・ハンドラの追加手順

#

手順

説明

1

ハンドラとハンドラ・チェーンを設計します。

「SOAPメッセージ・ハンドラおよびハンドラ・チェーンの設計」を参照してください。

2

ハンドラ・チェーン内の各ハンドラについて、javax.xml.rpc.handler.GenericHandler抽象クラスを拡張するJavaクラスを作成します。

「GenericHandlerクラスの作成」を参照してください。

3

SOAPメッセージ・ハンドラを構成するためのアノテーションを追加して、JWSファイルを更新します。

「JWSファイルでのハンドラの構成」を参照してください。

4

JWSファイル内で@HandlerChain標準アノテーションを使用している場合は、ハンドラ・チェーンの構成ファイルを作成します。

「ハンドラ・チェーン構成ファイルの作成」を参照してください。

5

ハンドラ・チェーン内のすべてのハンドラ・クラスをコンパイルし、Webサービスを再ビルドします。

「Webサービスのコンパイルと再ビルド」を参照してください。

クライアント側のSOAPメッセージ・ハンドラおよびハンドラ・チェーンの作成については、「クライアント側SOAPメッセージ・ハンドラの作成と使用」を参照してください。

SOAPメッセージ・ハンドラおよびハンドラ・チェーンの設計

SOAPメッセージ・ハンドラおよびハンドラ・チェーンを設計するときには、以下の事項を決定する必要があります。

- すべての作業を実行するために必要なハンドラの数

- 実行の順序

ハンドラ・チェーン内の各ハンドラには、SOAPのリクエスト・メッセージを処理するメソッドとSOAPのレスポンス・メッセージを処理するメソッドが1つずつあります。順序付けされたハンドラのグループが、ハンドラ・チェーンです。Webサービスに、@HandlerChainと@SOAPMessageHandlerという2つのJWSアノテーションのうち1つを備えるハンドラ・チェーンが付加されていることを指定します。どちらをいつ使用するかは、後の項で説明します。

Webサービスを呼び出すときに、WebLogic Serverは次のようにハンドラを実行します。

1. ハンドラ・チェーン内のハンドラのhandleRequest()メソッドはすべて、JWSアノテーションで指定されている順序で実行されます。これらのhandleRequest()メソッドのいずれもが、SOAPのリクエスト・メッセージを変更できます。

2. ハンドラ・チェーン内の最後のハンドラのhandleRequest()メソッドが実行されると、WebLogic Serverは、Webサービスを実装するバックエンド・コンポーネントを呼び出し、最終的なSOAPのリクエスト・メッセージを渡します。

3. バックエンド・コンポーネントの実行が終了したら、ハンドラ・チェーン内のハンドラのhandleResponse()メソッドが、JWSアノテーションで指定されているのとは逆の順序で実行されます。これらのhandleResponse()メソッドのいずれもが、SOAPのレスポンス・メッセージを変更できます。

4. ハンドラ・チェーン内の最初のハンドラのhandleResponse()メソッドが実行されると、WebLogic Serverは、Webサービスを呼び出したクライアント・アプリケーションに最終的なSOAPレスポンス・メッセージを戻します。

たとえば、JWSファイルで@HandlerChain JWSアノテーションを使用して外部構成ファイルを指定することになっており、その構成ファイルでは、次の例に示す3つのハンドラが格納されたSimpleChainというハンドラ・チェーンを定義していると仮定します。

<jwshc:handler-config xmlns:jwshc="http://www.bea.com/xml/ns/jws"
xmlns:soap1="http://HandlerInfo.org/Server1"
xmlns:soap2="http://HandlerInfo.org/Server2"
xmlns="http://java.sun.com/xml/ns/j2ee" >

<jwshc:handler-chain>

<jwshc:handler-chain-name>SimpleChain</jwshc:handler-chain-name>

<jwshc:handler>
<handler-name>handlerOne</handler-name>
<handler-class>examples.webservices.soap_handlers.global_handler.ServerHandler1</handler-class>
</jwshc:handler>

<jwshc:handler>
<handler-name>handlerTwo</handler-name>
<handler-class>examples.webservices.soap_handlers.global_handler.ServerHandler2</handler-class>
</jwshc:handler>

<jwshc:handler>
<handler-name>handlerThree</handler-name>
<handler-class>examples.webservices.soap_handlers.global_handler.ServerHandler3</handler-class>
</jwshc:handler>

</jwshc:handler-chain>

</jwshc:handler-config>

次の図は、WebLogic Serverで各ハンドラのhandleRequest()メソッドとhandleResponse()メソッドが実行される順序を示しています。

図9-1 ハンドラ・メソッドの実行順序

通常、着信メッセージと発信メッセージで同じタイプの処理が必要となるので、各SOAPメッセージ・ハンドラには、リクエストSOAPメッセージとレスポンスSOAPメッセージを処理する別個のメソッドがあります。たとえば、SOAPリクエストにあるセキュア・データを復号化するhandleRequest()メソッドと、SOAPレスポンスを暗号化するhandleResponse()メソッドを持つ暗号化ハンドラを設計する場合があります。

一方、SOAPリクエストのみを処理し、それと同等のレスポンス処理は行わないハンドラを設計することもできます。

また、ハンドラ・チェーン内の次のハンドラを呼び出さず、そのまま、任意の時点でクライアント・アプリケーションにレスポンスを送信することも可能です。

GenericHandlerクラスの作成

SOAPメッセージ・ハンドラ・クラスでは、javax.rpc.xml.handler.GenericHandler抽象クラスを拡張する必要があります。この抽象クラス自体が、javax.rpc.xml.handler.Handlerインタフェースを実装します。

GenericHandlerクラスは、ハンドラの記述を容易にする便利な抽象クラスです。このクラスは、ライフサイクル・メソッドinit()およびdestroy()ならびにHandlerインタフェースの様々なhandleXXX()メソッドのデフォルト実装を提供します。ハンドラ・クラスを記述する際には、Handler実装クラスの一部としてカスタマイズが必要なメソッドのみをオーバーライドします。

特に、Handlerインタフェースには、GenericHandlerを拡張するハンドラ・クラス内で実装できる、次のメソッドが格納されています。

- init()
「Handler.init()メソッドの実装」を参照してください。

- destroy()
「Handler.destroy()メソッドの実装」を参照してください。

- getHeaders()
「Handler.getHeaders()メソッドの実装」を参照してください。

- handleRequest()
「Handler.handleRequest()メソッドの実装」を参照してください。

- handleResponse()
「Handler.handleResponse()メソッドの実装」を参照してください。

- handleFault()
「Handler.handleFault()メソッドの実装」を参照してください。

特に画像などの添付ファイルを処理する場合などには、ハンドラ内から直接SOAPメッセージを表示または更新しなければならない場合もあります。その場合には、javax.xml.soap.SOAPMessage抽象クラスを使用します。このクラスは、SOAP With Attachments API for Java 1.1 (SAAJ)仕様(http://java.net/projects/saaj/)に含まれています。詳細については、「SAAJを使用したSOAPリクエスト・メッセージおよびレスポンス・メッセージの直接操作」を参照してください。

次の例は、SOAPのリクエストおよびレスポンス・メッセージをWebLogic Serverのログ・ファイルに出力する簡単なSOAPメッセージ・ハンドラを示しています。

package examples.webservices.soap_handlers.global_handler;

import javax.xml.namespace.QName;
import javax.xml.rpc.handler.HandlerInfo;
import javax.xml.rpc.handler.GenericHandler;
import javax.xml.rpc.handler.MessageContext;
import javax.xml.rpc.handler.soap.SOAPMessageContext;
import javax.xml.rpc.JAXRPCException;

import weblogic.logging.NonCatalogLogger;

/**
* This class implements a handler in the handler chain, used to access the SOAP
* request and response message.
* <p>
* This class extends the <code>javax.xml.rpc.handler.GenericHandler</code>
* abstract classs and simply prints the SOAP request and response messages to
* the server log file before the messages are processed by the backend
* Java class that implements the Web Service itself.
*/

public class ServerHandler1 extends GenericHandler {

private NonCatalogLogger log;

private HandlerInfo handlerInfo;

/**
*  Initializes the instance of the handler.  Creates a nonCatalogLogger to
*  log messages to.
*/

public void init(HandlerInfo hi) {

log = new NonCatalogLogger("WebService-LogHandler");
handlerInfo = hi;
}

/**
* Specifies that the SOAP request message be logged to a log file before the
* message is sent to the Java class that implements the Web Service.
*/

public boolean handleRequest(MessageContext context) {

SOAPMessageContext messageContext = (SOAPMessageContext) context;

System.out.println("** Request: "+messageContext.getMessage().toString());
log.info(messageContext.getMessage().toString());
return true;

}

/**
* Specifies that the SOAP response message be logged to a log file before the
* message is sent back to the client application that invoked the Web
* service.
*/

public boolean handleResponse(MessageContext context) {

SOAPMessageContext messageContext = (SOAPMessageContext) context;

System.out.println("** Response: "+messageContext.getMessage().toString());
log.info(messageContext.getMessage().toString());
return true;

}

/**
* Specifies that a message be logged to the log file if a SOAP fault is
* thrown by the Handler instance.
*/

public boolean handleFault(MessageContext context) {

SOAPMessageContext messageContext = (SOAPMessageContext) context;

System.out.println("** Fault: "+messageContext.getMessage().toString());
log.info(messageContext.getMessage().toString());
return true;

}

public QName[] getHeaders() {

return handlerInfo.getHeaders();

}

}

Handler.init()メソッドの実装

Handler.init()メソッドは、Handlerオブジェクトのインスタンスを作成し、そのインスタンスが自動的に初期化されるようにするために呼び出されます。そのシグネチャは次のとおりです。

public void init(HandlerInfo config) throws JAXRPCException {}

HandlerInfoオブジェクトには、SOAPメッセージ・ハンドラ情報、特に初期化パラメータが格納されています。HandlerInfo.getHandlerConfig()メソッドを使用してパラメータを取得すると、このメソッドは、名前と値のペアの入ったjava.util.Mapオブジェクトを返します。

初期化パラメータを処理する必要がある場合、または、他の初期化タスクを実行する必要がある場合は、init()メソッドを実装します。

初期化パラメータの使用例としては、デバッグのオン、オフ、メッセージやエラーを書き込むためのログ・ファイルの名前の指定などがあります。

Handler.destroy()メソッドの実装

Handler.destroy()メソッドは、Handlerオブジェクトのインスタンスを破棄するために呼び出されます。そのシグネチャは次のとおりです。

public void destroy() throws JAXRPCException {}

destroy()メソッドを実装すると、ハンドラのライフサイクルを通じて取得されたあらゆるリソースを解放できます。

Handler.getHeaders()メソッドの実装

Handler.getHeaders()メソッドは、このHandlerインスタンスで処理できるヘッダー・ブロックを取得します。そのシグネチャは次のとおりです。

public QName[] getHeaders() {}

Handler.handleRequest()メソッドの実装

Handler.handleRequest()メソッドは、バックエンド・コンポーネントによって処理される前にSOAPのリクエスト・メッセージをインターセプトするために呼び出されます。そのシグネチャは次のとおりです。

public boolean handleRequest(MessageContext mc)
throws JAXRPCException,SOAPFaultException  {}

このメソッドを実装すると、バックエンド・コンポーネントによって処理される前のSOAPメッセージ内のデータの復号化などのタスクが実行できます。

MessageContextオブジェクトは、SOAPメッセージ・ハンドラによって処理されたメッセージのコンテキストを抽出します。MessageContextプロパティにより、ハンドラ・チェーン内のハンドラは処理ステートを共有できます。

MessageContextのSOAPMessageContextサブインタフェースを使用すると、SOAPのリクエスト・メッセージの内容を取得または更新することができます。SOAPのリクエスト・メッセージそのものは、javax.xml.soap.SOAPMessageオブジェクトに格納されます。このオブジェクトの詳細は、「SAAJを使用してSOAPリクエスト・メッセージおよびレスポンス・メッセージの直接操作」を参照してください。

SOAPMessageContextクラスは、SOAPリクエストを処理する次の2つのメソッドを定義します。

- SOAPMessageContext.getMessage(): SOAPのリクエスト・メッセージの入ったjavax.xml.soap.SOAPMessageオブジェクトを返します。

- SOAPMessageContext.setMessage(javax.xml.soap.SOAPMessage): SOAPのリクエスト・メッセージを変更後、それを更新します。

SOAPリクエストのすべての処理をコーディングしたら、次のシナリオのいずれかをコーディングします。

- trueを返すことにより、ハンドラ・リクエスト・チェーン内の次のハンドラを呼び出します。
リクエスト・チェーンの次のハンドラは、@HandlerChainアノテーションによって指定された構成ファイル内の<handler-chain>要素の次の<handler>サブ要素と、@SOAPMessageHandlersアノテーションによって指定された配列内の次の@SOAPMessageHandlerのいずれかとして指定されます。チェーン内のすべてのハンドラが実行されたら、メソッドはWebサービスの構成に応じて、バックエンド・コンポーネントの呼出し、最終的なSOAPのリクエスト・メッセージの送信、または最後のハンドラのhandleResponse()メソッドの呼出しを行います。

- falseを返すことにより、ハンドラ・リクエスト・チェーンの処理をブロックします。
ハンドラ・リクエスト・チェーンの処理をブロックすると、Webサービスのこの呼出しについては、バックエンド・コンポーネントは実行されなくなります。Webサービスの一部の呼出しの結果をキャッシュしてあり、そのリストに現在の呼出しも含まれている場合は、この操作が便利な場合があります。

ハンドラ・リクエスト・チェーンの処理は中断されますが、WebLogic Serverが、現在のハンドラから順に、レスポンス・チェーンを呼び出します。たとえば、ハンドラ・チェーンに、handlerAとhandlerBという2つのハンドラがあると想定します。ここで、handlerAのhandleRequest()メソッドは、handlerBの対応するメソッドの前に呼び出されるものとします。handlerAで処理がブロックされると(したがってhandlerBのhandleRequest()メソッドは呼び出されません)、ハンドラ・レスポンス・チェーンはhandlerAで開始され、handlerBのhandleRequest()メソッドも呼び出されません。

- javax.xml.rpc.soap.SOAPFaultExceptionをスローして、SOAPフォルトを示します。
handleRequest()メソッドがSOAPFaultExceptionをスローすると、WebLogic Serverは、この例外を取得して、ハンドラ・リクエスト・チェーンの後続の処理を終了し、このハンドラのhandleFault()メソッドを呼び出します。

- あらゆるハンドラ固有の実行時エラーに対してJAXRPCExceptionをスローします。
handleRequest()メソッドがJAXRPCExceptionをスローすると、WebLogic Serverは、この例外を取得して、ハンドラ・リクエスト・チェーンの後続の処理を終了し、この例外をWebLogic Serverのログ・ファイルに記録し、このハンドラのhandleFault()メソッドを呼び出します。

Handler.handleResponse()メソッドの実装

Handler.handleResponse()メソッドは、SOAPのレスポンス・メッセージがバックエンド・コンポーネントによって処理された後、Webサービスを呼び出したクライアント・アプリケーションに戻される前に、そのメッセージをインターセプトするために呼び出されます。そのシグネチャは次のとおりです。

public boolean handleResponse(MessageContext mc) throws JAXRPCException {}

このメソッドを実装すると、クライアント・アプリケーションに返される前にSOAPメッセージに含まれているデータを暗号化したり、戻り値に処理を加えたりといったタスクを実行できます。

MessageContextオブジェクトは、SOAPメッセージ・ハンドラによって処理されたメッセージのコンテキストを抽出します。MessageContextプロパティにより、ハンドラ・チェーン内のハンドラは処理ステートを共有できます。

MessageContextのSOAPMessageContextサブインタフェースを使用すると、SOAPのレスポンス・メッセージの内容を取得または更新することができます。SOAPのレスポンス・メッセージそのものは、javax.xml.soap.SOAPMessageオブジェクトに格納されます。「SAAJを使用したSOAPリクエスト・メッセージおよびレスポンス・メッセージの直接操作」を参照してください。

SOAPMessageContextクラスは、SOAPレスポンスを処理する次の2つのメソッドを定義します。

- SOAPMessageContext.getMessage(): SOAPのレスポンス・メッセージの入ったjavax.xml.soap.SOAPMessageオブジェクトを返します。

- SOAPMessageContext.setMessage(javax.xml.soap.SOAPMessage): SOAPのレスポンス・メッセージを変更後、それを更新します。

SOAPレスポンスのすべての処理をコーディングしたら、次のシナリオのいずれかをコーディングします。

- trueを返すことにより、ハンドラ・レスポンス・チェーン内の次のハンドラを呼び出します。
ハンドラ・チェーンの次のレスポンスは、@HandlerChainアノテーションによって指定された構成ファイル内の<handler-chain>要素の前の<handler>サブ要素か、@SOAPMessageHandlersアノテーションによって指定された配列内の前の@SOAPMessageHandlerのいずれかとして指定されます(ハンドラ・チェーン上のレスポンスは、JWSファイルで指定されたのと逆の順序で実行されることに留意してください。詳細については、「SOAPメッセージ・ハンドラおよびハンドラ・チェーンの設計」を参照してください)。

ハンドラ・チェーン内のすべてのハンドラが実行されたら、メソッドは、Webサービスを呼び出したクライアント・アプリケーションに最終的なSOAPのレスポンス・メッセージを戻します。

- falseを返すことにより、ハンドラ・レスポンス・チェーンの処理をブロックします。
ハンドラ・レスポンス・チェーンの処理をブロックすると、レスポンス・チェーンにある残りのハンドラが、Webサービスのこの呼出しについては実行されなくなり、現在のSOAPメッセージがクライアント・アプリケーションに戻されます。

- あらゆるハンドラ固有の実行時エラーに対してJAXRPCExceptionをスローします。
handleRequest()メソッドがJAXRPCExceptionをスローすると、WebLogic Serverは、この例外を取得して、ハンドラ・リクエスト・チェーンの後続の処理を終了し、この例外をWebLogic Serverのログ・ファイルに記録し、このハンドラのhandleFault()メソッドを呼び出します。

Handler.handleFault()メソッドの実装

Handler.handleFault()メソッドは、SOAPメッセージ処理モデルに基づいてSOAPフォルトを処理します。そのシグネチャは次のとおりです。

public boolean handleFault(MessageContext mc) throws JAXRPCException  {}

このメソッドを実装すると、バックエンド・コンポーネントによって生成されたフォルトのほか、handleResponse()メソッドおよびhandleRequest()メソッドによって生成されたあらゆるSOAPフォルトの処理も扱うことができます。

MessageContextオブジェクトは、SOAPメッセージ・ハンドラによって処理されたメッセージのコンテキストを抽出します。MessageContextプロパティにより、ハンドラ・チェーン内のハンドラは処理ステートを共有できます。

MessageContextのSOAPMessageContextサブインタフェースを使用すると、SOAPメッセージの内容を取得または更新することができます。SOAPメッセージそのものは、javax.xml.soap.SOAPMessageオブジェクトに格納されます。「SAAJを使用したSOAPリクエスト・メッセージおよびレスポンス・メッセージの直接操作」を参照してください。

SOAPMessageContextクラスは、SOAPメッセージを処理する次の2つのメソッドを定義します。

- SOAPMessageContext.getMessage(): SOAPメッセージの入ったjavax.xml.soap.SOAPMessageオブジェクトを返します。

- SOAPMessageContext.setMessage(javax.xml.soap.SOAPMessage): SOAPのメッセージを変更後、それを更新します。

SOAPフォルトのすべての処理をコーディングしたら、次のいずれかを実行します。

- trueを返すことにより、ハンドラ・チェーン内の次のハンドラのhandleFault()メソッドを呼び出します。

- falseを返すことにより、ハンドラ・フォルト・チェーンの処理をブロックします。

SAAJを使用したSOAPリクエスト・メッセージおよびレスポンス・メッセージの直接操作

javax.xml.soap.SOAPMessage抽象クラスは、SOAP With Attachments API for Java 1.1 (SAAJ)仕様に含まれています。(http://java.net/projects/saaj/を参照。)このクラスは、SOAPメッセージ・ハンドラ作成時にSOAPのリクエスト・メッセージおよびレスポンス・メッセージを操作するのに使用します。この節では、SOAPMessageオブジェクトの基本構造とSOAPメッセージの表示および更新に役立つメソッドのいくつかについて説明します。

SOAPMessageオブジェクトは、SOAPPartオブジェクト(SOAP XMLドキュメントそのものが入っている)、または同オブジェクトと添付ファイルで構成されています。

SOAPMessageクラスの詳細な説明については、SAAJに関するJavadocを参照してください。

SOAPPartオブジェクト

SOAPPartオブジェクトには、SOAPEnvelopeオブジェクトに格納されたXML SOAPドキュメントが入っています。このオブジェクトは、実際のSOAPのヘッダーと本文を取得するのに使用します。

次のJavaコードのサンプルは、Handlerクラスによって提供されたMessageContextオブジェクトからSOAPメッセージを取り出して、その各部を参照する方法を示しています。

SOAPMessage soapMessage =  messageContext.getMessage();
SOAPPart soapPart = soapMessage.getSOAPPart();
SOAPEnvelope soapEnvelope = soapPart.getEnvelope();
SOAPBody soapBody = soapEnvelope.getBody();
SOAPHeader soapHeader = soapEnvelope.getHeader();

AttachmentPartオブジェクト

javax.xml.soap.AttachmentPartオブジェクトには、SOAPメッセージに対するオプションの添付ファイルが入っています。添付ファイルは、SOAPメッセージの残りの部分とは異なり、XMLフォーマットの必須部分ではないので、その形式は、単純なテキストからイメージ・ファイルまで、さまざまです。

注意:
SOAPメッセージ・ハンドラから直接に添付ファイルjava.awt.Imageにアクセスする場合は、「SOAPメッセージ・ハンドラで画像添付ファイルの操作」で重要情報を参照してください。

添付ファイルを操作するには、SOAPMessageクラスの以下のメソッドを使用します。

- countAttachments(): このSOAPメッセージに含まれている添付ファイルの数を返します。

- getAttachments(): すべての添付ファイルを取り出し、(AttachmentPartオブジェクトとして) Iteratorオブジェクトに格納します。

- createAttachmentPart(): 他のタイプのObjectからAttachmentPartオブジェクトを作成します。

- addAttachmentPart(): 作成されたAttachmentPartオブジェクトをSOAPMessageに追加します。

SOAPメッセージ・ハンドラで画像添付ファイルの操作

この節では、添付ファイルjava.awt.ImageにアクセスするSOAPメッセージ・ハンドラを作成すること、およびclientgen Antタスクによって生成されたクライアントJAX-RPCスタブを使用するクライアント・アプリケーションからImageが送信されていることを前提としています。

clientgen Antタスクによって生成されたクライアント・コードでは、添付ファイルjava.awt.Imageはimage/gifではなくtext/xmlのMIMEタイプで、呼び出されるWebLogic Webサービスに送信され、画像は画像を表す整数のストリームにシリアライズされます。特に、このクライアント・コードは次の形式で画像をシリアライズします。

- int width

- int height

- int[] pixels

つまり、受信したImage添付ファイルを操作するSOAPメッセージ・ハンドラでは、このデータ・ストリームをデシリアライズして元の画像を作成し直す必要があるということです。

JWSファイルでのハンドラの構成

Webサービスのハンドラ・チェーンを構成するためにJWSファイルで使用できる標準的なアノテーションは、@javax.jws.HandlerChainおよび@javax.jws.soap.SOAPMessageHandlersの2つです。

@javax.jws.HandlerChain

@javax.jws.HandlerChainアノテーション(この章では簡単にするため@HandlerChainとも呼びます)を使用する場合は、file属性を使用して、Webサービスと関連付けるハンドラ・チェーンの構成が含まれた外部ファイルを指定します。構成には、チェーン内のハンドラのリスト、ハンドラが実行される順序、初期化パラメータなどが含まれます。

以下の条件の1つ以上が適用される場合は、@SOAPMessageHandlersアノテーションではなく@HandlerChainアノテーションをJWSファイルで使用します:

- 複数のWebサービスで同じ構成を共有したい。

- ハンドラ・チェーンに、複数のトランスポートのハンドラが含まれている。

- Webサービスを実装するJWSファイルを再コンパイルしないで、そのWebサービスのハンドラ・チェーン構成を変更できるようにしたい。

次のJWSファイルでは、@HandlerChainアノテーションの使用例を示します。関連のJavaコードは太字で示しています。

package examples.webservices.soap_handlers.global_handler;

import java.io.Serializable;

import javax.jws.HandlerChain;
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.soap.SOAPBinding;

import weblogic.jws.WLHttpTransport;

@WebService(serviceName="HandlerChainService",
name="HandlerChainPortType")

// Standard JWS annotation that specifies that the handler chain called
// "SimpleChain", configured in the HandlerConfig.xml file, should fire
// each time an operation of the Web Service is invoked.

@HandlerChain(file="HandlerConfig.xml", name="SimpleChain")

@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)

@WLHttpTransport(contextPath="HandlerChain", serviceUri="HandlerChain",
portName="HandlerChainServicePort")

/**
* This JWS file forms the basis of simple Java-class implemented WebLogic
* Web Service with a single operation: sayHello.  The Web Service also
* has a handler chain associated with it, as specified by the
* @HandlerChain annotation.
*/

public class HandlerChainImpl  {

public String sayHello(String input) {
weblogic.utils.Debug.say( "in backend component. input:" +input );
return "'" + input + "' to you too!";
}
}

@HandlerChainアノテーションを使用する前に、前述の例に示すように、それをJWSファイルにインポートする必要があります。

@HandlerChainアノテーションのfile属性を使用し、ハンドラ・チェーンの構成情報を含む外部ファイルの名前を指定します。この属性の値はURLです。これは相対でも絶対でもかまいません。相対URLは、ファイルをコンパイルするためにjwsc Antタスクを実行した時点でのJWSファイルの場所を基準とします。

Webサービスと関連付ける構成ファイル内のハンドラ・チェーンの名前を指定するには、name属性を使用します。この属性の値は、構成ファイル内の<handler-chain>要素のname属性に対応します。

注意:
1つのJWSファイル内に複数の@HandlerChainアノテーションを指定すると、エラーになります。また、@HandlerChainアノテーションを@SOAPMessageHandlersアノテーションと一緒に使用しても、エラーになります。

外部構成ファイル作成の詳細は、「ハンドラ・チェーン構成ファイルの作成」を参照してください。

この項で説明した標準的なJWSアノテーションの詳細は、Web Services Metadata for the Java Platform仕様(http://www.jcp.org/en/jsr/detail?id=181)を参照してください。

@javax.jws.soap.SOAPMessageHandlers

注意:
このアノテーションは、Web Services Metadata for the Java Platform仕様(JSR-181)(http://www.jcp.org/en/jsr/detail?id=181)では非推奨となっています。

@javax.jws.soap.SOAPMessageHandlers(この項では簡単にするため@SOAPMessageHandlersとも呼びます)アノテーションを使用する場合、JWSファイル自体の中で、Webサービス操作の前と後に実行するSOAPメッセージ・ハンドラの配列を指定します(@SOAPMessageHandlerアノテーションで指定)。@SOAPMessageHandlerアノテーションには、ハンドラのクラス名、初期化パラメータ、ハンドラで処理されるSOAPヘッダーのリストなどを指定する属性が含まれます。JWSファイル自体の内部でハンドラのリストを指定するので、ハンドラ・チェーンの構成はWebサービス内に埋め込まれます。

以下の条件の1つ以上が適用される場合は、@SOAPMessageHandlersアノテーションを使用します:

- 外部のファイルで構成を指定するのではなく、Webサービス自体の内部にハンドラ・チェーンの構成を埋め込みたい。

- ハンドラ・チェーンにSOAPハンドラのみが含まれており、それ以外のトランスポート用のハンドラは含まれていない。

- ハンドラ・チェーンの構成を変更するたびにJWSファイルを再コンパイルしたい。

次のJWSファイルでは、@SOAPMessageHandlersアノテーションの簡単な使用例を示します。関連のJavaコードは太字で示しています。

package examples.webservices.soap_handlers.simple;

import java.io.Serializable;

import javax.jws.soap.SOAPMessageHandlers;
import javax.jws.soap.SOAPMessageHandler;
import javax.jws.soap.SOAPBinding;
import javax.jws.WebService;
import javax.jws.WebMethod;

import weblogic.jws.WLHttpTransport;

@WebService(name="SimpleChainPortType",
serviceName="SimpleChainService")

// Standard JWS annotation that specifies a list of SOAP message handlers
// that exeucte before and after an invocation of all operations in the
// Web Serice.

@SOAPMessageHandlers ( {
@SOAPMessageHandler (
className="examples.webservices.soap_handlers.simple.ServerHandler1"),
@SOAPMessageHandler (
className="examples.webservices.soap_handlers.simple.ServerHandler2")
} )

@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)

@WLHttpTransport(contextPath="SimpleChain", serviceUri="SimpleChain",
portName="SimpleChainServicePort")

/**
* This JWS file forms the basis of simple Java-class implemented WebLogic
* Web Service with a single operation: sayHello.  The Web Service also
* has a handler chain associated with it, as specified by the
* @SOAPMessageHandler/s annotations.
*/

public class SimpleChainImpl  {

// by default all public methods are exposed as operations

public String sayHello(String input)  {
weblogic.utils.Debug.say( "in backend component. input:" +input );
return "'" + input + "' to you too!";
}
}

@SOAPMessageHandlersアノテーションおよび@SOAPMessageHandlerアノテーションを使用する前に、前述の例に示すように、それらをJWSファイルにインポートする必要があります。これらのアノテーションは、javax.jws.soapパッケージに入っています。

@SOAPMessageHandlers配列で(@SOAPMessageHandlerアノテーションを使用して)ハンドラをリストした順序により、ハンドラの実行の順序(操作前なら順序どおりに、操作後なら逆順で)が指定されます。前述のサンプルでは、ハンドラ・チェーンにおいて2つのハンドラを構成しています。これらのハンドラのクラス名は、examples.webservices.soap_handlers.simple.ServerHandler1とexamples.webservices.soap_handlers.simple.ServerHandler2です。

@SOAPMessageHandlerのinitParams属性を使用すると、特定のハンドラにおいて予期されている初期化パラメータの配列を指定できます。@InitParam標準JWSアノテーションを使用し、次の例のように、名前と値のペアを指定します。

@SOAPMessageHandler(
className = "examples.webservices.soap_handlers.simple.ServerHandler1",
initParams = { @InitParam(name="logCategory", value="MyService")}
)

また、@SOAPMessageHandlerアノテーションには、ハンドラによって実装されるSOAPロールをリストするためのroles属性、およびハンドラによって処理されるSOAPヘッダーをリストするためのheaders属性も含まれています。

注意:
@SOAPMessageHandlersアノテーションを@HandlerChainアノテーションと一緒に使用すると、エラーになります。

この項で説明した標準的なJWSアノテーションの詳細は、Web Services Metadata for the Java Platform仕様(http://www.jcp.org/en/jsr/detail?id=181)を参照してください。

ハンドラ・チェーン構成ファイルの作成

JWSファイルで@HandlerChainアノテーションを使用して、ハンドラ・チェーンをWebサービスと関連付けることにした場合は、ハンドラ・チェーン内のハンドラのリスト、それらの実行順、初期化パラメータなどを指定する外部構成ファイルを作成する必要があります。

このファイルはJWSファイルの外部にあるため、この単一の構成ファイルを複数のWebサービスで使用するように構成し、エンタープライズ内のすべてのWebサービスに関してハンドラ構成ファイルを標準化することができます。加えて、すべてのWebサービスを再コンパイルすることなく、ハンドラ・チェーンの構成を変更できます。なお、非SOAPのトランスポートを使用するハンドラ・チェーンにハンドラを入れた場合、@SOAPMessageHandlerアノテーションではなく@HandlerChainアノテーションを使用することが必要となります。

構成ファイルは、次の簡単なサンプルに示すように、XMLを使用して1つまたは複数のハンドラ・チェーンをリストします。

<jwshc:handler-config xmlns:jwshc="http://www.bea.com/xml/ns/jws"
xmlns:soap1="http://HandlerInfo.org/Server1"
xmlns:soap2="http://HandlerInfo.org/Server2"
xmlns="http://java.sun.com/xml/ns/j2ee" >
<jwshc:handler-chain>
<jwshc:handler-chain-name>SimpleChain</jwshc:handler-chain-name>
<jwshc:handler>
<handler-name>handler1</handler-name>
<handler-class>examples.webservices.soap_handlers.global_handler.ServerHandler1</handler-class>
</jwshc:handler>
<jwshc:handler>
<handler-name>handler2</handler-name>
<handler-class>examples.webservices.soap_handlers.global_handler.ServerHandler2</handler-class>
</jwshc:handler>
</jwshc:handler-chain>
</jwshc:handler-config>

この例では、SimpleChainというハンドラ・チェーンに、handler1およびhandler2という2つのハンドラが入っています。これらは<handler-class>要素で指定されるクラス名で実装されます。2つのハンドラは、関連のWebサービス操作の前には昇順で実行され、操作実行後には逆順で実行されます。

ハンドラ初期化パラメータ、ハンドラによって実装されるSOAPロール、およびハンドラによって処理されるSOAPヘッダーを指定するには、それぞれ<handler>要素の<init-param>、<soap-role>、および<soap-header>子要素を使用します。

外部構成ファイルを定義するXMLスキーマ、その作成の詳細、および他のサンプルについては、Web Services Metadata for the Java Platform仕様(http://www.jcp.org/en/jsr/detail?id=181)を参照してください。

Webサービスのコンパイルと再ビルド

この項では、Webサービスをコンパイルおよびビルドする作業用のbuild.xml Antファイルがあり、そのビルド・ファイルを更新してハンドラ・チェーンを含めることを想定しています。このbuild.xmlファイルの作成については、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスの開発に関する項を参照してください。

メッセージ・ハンドラのコンパイルとビルドが含まれるように開発環境を更新するには、以下のガイドラインに従います。

- @HandlerChainまたは@SOAPMessageHandlersアノテーションでJWSファイルを更新後、jwsc Antタスクを再実行して、JWSファイルを再コンパイルし、新しいWebサービスを生成する必要があります。これは、JWSファイル内のアノテーションに変更を加えた場合は常に当てはまります。
JWSファイルで@HandlerChainアノテーションを使用し、jwsc Antタスクを再実行してWebサービスを再生成し、その後、外部構成ファイルのみを変更した場合は、2度目の変更を有効にするためにjwscを再実行する必要はありません。

- 以下の条件がすべて満たされていれば、jwsc AntタスクはSOAPメッセージ・ハンドラJavaファイルをハンドラ・クラスにコンパイル(およびその後それらを生成されたアプリケーションにパッケージ化)します。

- ハンドラ・クラスはJWSファイルの@HandlerChainまたは@SOAPMessageHandler(s)アノテーションにおいて参照されます。

- Javaファイルはsourcepath属性で指定されたディレクトリ内に置かれます。

- クラスは現在CLASSPATH内に存在しません。

ハンドラ・クラスをjwscで自動的にコンパイルするのではなく、ユーザー側でコンパイルする場合は、jwsc Antタスクを実行する前に、コンパイルされたクラスがCLASSPATH内にあることを確認してください。

- ハンドラ・チェーンが関連付けられているWebサービスのデプロイおよび呼出しは、ハンドラ・チェーンのないWebサービスのデプロイおよび呼出しと同様に行います。唯一の相違点は、Webサービスのどの操作を呼び出す場合でも、WebLogic Webサービス・ランタイムは、操作呼出しの前と後の両方で、ハンドラ・チェーン内のハンドラを実行するということです。

クライアント側SOAPメッセージ・ハンドラの作成と使用

ここまでの各項では、WebLogic Serverで動作するWebサービスの一環として実行される、サーバー側SOAPメッセージ・ハンドラを作成する方法について説明してきました。この他に、Webサービス操作を呼び出すクライアント・アプリケーションの一環として実行される、クライアント側ハンドラを作成することもできます。クライアント側ハンドラの場合は、次のタイミングで二度実行されます。

- クライアント・アプリケーションがWebサービスにSOAPリクエストを送信する直前

- クライアント・アプリケーションがWebサービスからSOAPレスポンスを受信した直後

クライアント側SOAPメッセージ・ハンドラは、スタンドアロン・クライアントと、WebLogic Server内部で実行されるクライアントの、双方のために構成できます。

実際のJavaクライアント側ハンドラは、サーバー側ハンドラと同じ方法、つまりjavax.xml.rpc.handler.GenericHandler抽象クラスを拡張するJavaクラスを記述する方法で作成できます。多くの場合、WebLogic Serverで実行されるWebサービスとそのWebサービスを呼び出すクライアント・アプリケーションで、同じハンドラ・クラスを使用できます。たとえば、サーバーおよびクライアント用として、送信および受信したすべてのSOAPメッセージをログに記録する汎用ロギング・ハンドラ・クラスを記述できます。

サーバー側SOAPハンドラのプログラミングと同様に、クライアント側SOAPメッセージ・ハンドラを呼び出すclientgen AntタスクもXMLファイルを使用して指定します。ただし、次の手順で説明するように、このXMLファイルのXMLスキーマは少し異なります。

クライアント側SOAPメッセージ・ハンドラの使用: 主な手順

次の手順では、Webサービス操作を呼び出すクライアント・アプリケーションにクライアント側SOAPメッセージ・ハンドラを追加する手順を大まかに説明します。

デプロイされたWebサービスを呼び出すクライアント・アプリケーションを作成済であり、クライアント側SOAPメッセージ・ハンドラおよびハンドラ・チェーンを追加してクライアント・アプリケーションを更新することを想定しています。また、Antベースの開発環境を設定済であり、かつclientgen Antタスクを実行するためのターゲットを含む、作業用のbuild.xmlファイルがあることが前提となっています。詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のスタンドアロン・クライアントからのWebサービスの呼出し: 主な手順に関する項を参照してください。

1. クライアント側SOAPハンドラと、それらのハンドラの実行順序を指定するハンドラ・チェーンを設計します。この手順は、視点がWebサービスからではなくクライアント・アプリケーションからとなる点を除けば、サーバー側SOAPメッセージ・ハンドラを設計するのとほぼ同じです。
「SOAPメッセージ・ハンドラおよびハンドラ・チェーンの設計」を参照してください。

2. ハンドラ・チェーン内の各ハンドラについて、javax.xml.rpc.handler.GenericHandler抽象クラスを拡張するJavaクラスを作成します。この手順は、チェーン内のハンドラをサーバーではなくクライアントで実行する点を除けば、サーバー側ハンドラの場合の手順と非常に似ています。
ハンドラ・クラスのプログラミングの詳細は、「GenericHandlerクラスの作成」を参照してください。サンプルについては、「クライアント側ハンドラ・クラスの例」を参照してください。

3. クライアント側SOAPハンドラの構成ファイルを作成します。このXMLファイルでは、ハンドラ・チェーン内のハンドラ、ハンドラが実行される順序、送信すべき初期化パラメータなどを記述します。
「クライアント側SOAPハンドラの構成ファイルの作成」を参照してください。

4. クライアント・アプリケーションのビルドに使用するbuild.xmlファイルを更新して、clientgen AntタスクにSOAPハンドラの構成ファイルの名前を指定します。また、build.xmlファイルによってハンドラ・ファイルがJavaクラスにコンパイルされ、クライアント・アプリケーションで使用できる状態になることも確認します。
「クライアント側SOAPハンドラの構成ファイルのclientgenへの指定」を参照してください。

5. 適切なタスクを実行して、クライアント・アプリケーションを再ビルドします。

prompt> ant build-client

次回クライアント・アプリケーションを実行したときには、SOAPリクエスト・メッセージの送信前とレスポンスの受信後に、構成ファイルに記述したSOAPメッセージ・ハンドラが自動的に実行されます。

注意:
clientgen Antタスクにハンドラの構成ファイルが指定されているかぎり、クライアント側SOAPメッセージ・ハンドラを呼び出すために実際のクライアント・アプリケーションを更新する必要はありません。ハンドラは、生成されたJAX-RPCスタブによって自動的に正しい順序で実行されます。

クライアント側ハンドラ・クラスの例

次の例では、Webサービスを呼び出すクライアント・アプリケーション用に構成できる単純なSOAPメッセージ・ハンドラ・クラスを示します。

package examples.webservices.client_handler.client;

import javax.xml.namespace.QName;
import javax.xml.rpc.handler.HandlerInfo;
import javax.xml.rpc.handler.GenericHandler;
import javax.xml.rpc.handler.MessageContext;

public class ClientHandler1 extends GenericHandler {

private QName[] headers;

public void init(HandlerInfo hi) {
System.out.println("in " + this.getClass() + " init()");
}

public boolean handleRequest(MessageContext context) {
System.out.println("in " + this.getClass() + " handleRequest()");
return true;
}

public boolean handleResponse(MessageContext context) {
System.out.println("in " + this.getClass() + " handleResponse()");
return true;
}

public boolean handleFault(MessageContext context) {
System.out.println("in " + this.getClass() + " handleFault()");
return true;
}

public QName[] getHeaders() {
return headers;
}
}

クライアント側SOAPハンドラの構成ファイルの作成

クライアント側SOAPハンドラの構成ファイルでは、ハンドラ・チェーン内のハンドラのリスト、ハンドラが実行される順序、初期化パラメータなどを指定します。このファイルの詳細は、「クライアント側ハンドラの構成ファイル用XMLスキーマ」を参照してください。

この構成ファイルでは、1つまたは複数のハンドラを含む1つのハンドラ・チェーンをXMLで記述します。次に単純な例を示します。

<weblogic-wsee-clientHandlerChain
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">

<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>examples.webservices.client_handler.client.ClientHandler1</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>

<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>examples.webservices.client_handler.client.ClientHandler2</j2ee:handler-class>
</handler>

</weblogic-wsee-clientHandlerChain>

この例では、ハンドラ・チェーンに2つのハンドラ(clienthandler1およびclienthandler2)が含まれており、<j2ee:handler-class>要素に指定されたクラス名で実装されています。これら2つのハンドラは、クライアント・アプリケーションがSOAPリクエストをWebサービスに送信する直前に指定の順序で実行され、クライアント・アプリケーションがWebサービスからのSOAPレスポンスを受信した直後に逆の順序で実行されます。

この例では、<j2ee:init-param>要素を使用して1つまたは複数の初期化パラメータをハンドラに指定する方法も示しています。

ハンドラによって実装されるSOAPロール、ハンドラによって処理されるSOAPヘッダー、およびハンドラが関連付けられているWSDLのポート名要素を指定するには、それぞれ、<handler>要素の子要素である<soap-role>、<soap-header>、および<port-name>を使用します。

クライアント側ハンドラの構成ファイル用XMLスキーマ

次のXMLスキーマ・ファイルでは、クライアント側SOAPハンドラの構成ファイルの構造を定義しています。

<?xml version="1.0" encoding="UTF-8"?>

<schema
targetNamespace="http://www.bea.com/ns/weblogic/90"
xmlns:wls="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
>
<include schemaLocation="weblogic-j2ee.xsd"/>

<element name="weblogic-wsee-clientHandlerChain"
type="wls:weblogic-wsee-clientHandlerChainType">
<xsd:key name="wsee-clienthandler-name-key">
<xsd:annotation>
<xsd:documentation>

Defines the name of the handler. The name must be unique within the
chain.

</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="j2ee:handler"/>
<xsd:field xpath="j2ee:handler-name"/>
</xsd:key>
</element>

<complexType name="weblogic-wsee-clientHandlerChainType">
<sequence>
<xsd:element name="handler"
type="j2ee:service-ref_handlerType"
minOccurs="0" maxOccurs="unbounded">
</xsd:element>
</sequence>
</complexType>
</schema>

1つの構成ファイルで、1つのクライアント側ハンドラ・チェーンを指定します。構成ファイルのルートは<weblogic-wsee-clientHandlerChain>で、ファイルにはゼロ個以上の<handler>子要素(それぞれがチェーン内の各ハンドラを記述しています)が含まれます。

<handler>要素の構造は、Java EE 1.4 Web service client XML Schema(http://java.sun.com/xml/ns/j2ee/j2ee_web_services_client_1_1.xsd)で指定されているJava EEのservice-ref_handlerType複合型で記述します。

クライアント側SOAPハンドラの構成ファイルのclientgenへの指定

クライアント側SOAPハンドラの構成ファイルを指定するには、clientgen AntタスクのhandlerChainFile属性を使用します。次に、build.xmlファイルからの抜粋を示します。

<clientgen
wsdl="http://ariel:7001/handlers/ClientHandlerService?WSDL"
destDir="${clientclass-dir}"
handlerChainFile="ClientHandlerChain.xml"
packageName="examples.webservices.client_handler.client"/>

clientgenによって自動的に生成されたJAX-RPCスタブを使用すると、クライアント・アプリケーションがWebサービス操作を呼び出す前と後に、構成ファイルで記述されたハンドラが必ず正しい順序で実行されます。

10 Database Webサービスの使用

この章では、Database Webサービスの使用方法について説明します。

この章では、以下のトピックについて説明します。

- Database Webサービスの概要

- SQLとXMLの間のタイプ・マッピング

- Oracle JDeveloperを使用したDatabase Webサービスの開発

Database Webサービスの概要

異機種環境と接続されていない環境で、Webサービスのインタフェースを介してストアド・プロシージャ、データおよびメタデータにアクセスするニーズが増加しています。Database Webサービスの技術は、データベースに対しするWebサービスを有効にします。以下の2つの方向に機能します。

- Databaseコールイン — Webサービスとしてのデータベース・リソースへのアクセス

- Databaseコールアウト —データベースからの外部Webサービスの消費

Databaseコールイン

OracleデータベースがWebサービス・プロバイダに取り込まれると、Javaストアド・プロシージャ、PL/SQLパッケージ、詳細キュー、定義済みのSQL問合せおよびDMLなどの機能を利用できます。

注意:
このリリースでは、問合せ、Java、DMLおよび詳細キュー以外のWebサービスの作成はサポートされません。

クライアント・アプリケーションは、問合せを実行し、Oracleデータベースからデータを取得して、標準のWebサービス・プロトコルを使用することによってストアド・プロシージャを呼び出します。Oracle固有のデータベースの接続プロトコルへの依存はありません。アプリケーションは、キャッシュされたWebLogic Serverへのすべての接続において適用できます。このアプローチは、異種の環境、分散型環境および接続されていない環境でとても役立ちます。

Database WebサービスはWebLogic Webサービスの一部であるため、一貫性のある統一された開発およびデプロイメント環境での利用が可能です。Webサービスの公開されたデータベースとWebサービス・クライアントの間で交換されるメッセージは、WebLogic Webサービスによって提供されている管理機能(セキュリティ、信頼性、監査およびロギング)のすべてを活用できます。

次の図は、Webサービスのコールインを示しています。

図10-1 データベースへのWebサービスの呼出し

次の手順では、前の図に示した処理を説明しています。

1. データベース・サービスのタイプに対するリクエストはアプリケーション・サーバーに受信します。サービス・エンドポイントは、暗黙にリクエストされたサービスのタイプを指定します。

2. JAX-RPC処理サーブレットは、リクエストをデコードするためにSOAPライブラリとXMLパーサーを参照します。

3. サーブレットは、公開されたデータベース操作に対応するクラスにリクエストを渡します。生成されたクラスは、データベースのPL/SQLパッケージ、問合せ、DML、AQストリーム、またはJavaクラスを表すことができます。

4. データベースは、レスポンスをJAX-RPC処理サーブレットに渡し、それをエンコードするためにJAX-RPC処理サーブレットはSOAPライブラリとXMLパーサーを参照します。

5. WSDLに基づいてフォーマットされたSOAPレスポンスがクライアントに返されます。

Databaseコールアウト

Webサービスを含むように、リレーショナル・データベース・ストレージ、索引、および検索機能を拡張できます。Webサービスを呼び出すことによって、データベースは、生成されたオンデマンドの動的データ(株価、為替レート、または気象情報など)の記録、集約、リフレッシュおよび問合せができます。サービスのコンシューマとしてのデータベース使用例として、複数のサプライヤからのインベントリ情報を取得してローカル・インベントリ情報を更新するために事前定義済みのデータベース・ジョブから外部Webサービスを呼び出します。もう1つの例は、Web Crawlerの例です。データベース・ジョブはいくつかのソースから製品情報と価格情報を照合できるようスケジュールします。

以下の図に、データベース・コールアウトを示します。

図10-2 データベース内からのWebサービスの呼出し

次の手順では、前の図に示した処理を説明しています。

- SQL呼出しおよびPL/SQL呼出しの仕様 - ユーザー定義関数の呼出し(SQL文内で直接呼び出すか、ビューで呼び出す)または変数 を介してWebサービスを呼び出します。

- UTL_DBWS PL/SQLパッケージを使用した動的Webサービスの呼出し。CallオブジェクトはWSDLに基づいて動的に作成され、その後、Webサービス操作を呼び出すことができます。
Oracle Database PL/SQLパッケージおよびタイプ・リファレンスは、UTL_DBWS PL/SQLパッケージ使用の詳細について説明します。

- Pure Java静的プロキシ・クラス - JAX-RPCを使用しているクライアント・プロキシ・クラスを生成します。サービスの場所が既知のため、UDDIレジストリ内のサービスをルックアップせずに、このメソッドはWebサービスを簡単に呼び出します。クライアント・プロキシ・クラスは、パラメータのマーシャリングとアンマーシャリングが含まれるSOAPリクエストを構成するすべての作業を実行します。

- JAX-RPC上のDII (Dynamic Invocation Interface)を使用したPure Java - 動的呼出しはSOAPリクエストを構成して、クライアント・プロキシを使用せずにサービスにアクセスする機能を提供します。

メソッドの使用は、SQLやPL/SQLから実行するか、Javaクラスから実行するか、またはサービスがあらかじめ知られているか(静的呼出し)、実行時にのみ知られているか(DII)、によって異なります。

SQLとXMLの間のタイプ・マッピング

次の節では、Webサービスがあらかじめ知られている(静的呼出し)場合、コールインおよびコールアウトに対するSQLとXMLの間のタイプ・マッピングについて説明します。

Webサービスが実行時に既知の場合、Dynamic Invocation Interface (DII)またはUTL_DBWS PL/SQLパッケージのみが使用されます。

Webサービスのコールインに対するSQLからXMLタイプへのマッピング

Database Webサービスのコールインでは、PL/SQLストアド・プロシージャまたはSQL文などのSQL操作が1つまたは複数のWebサービス操作にマップされます。SQL操作のパラメータは、SQLタイプからXMLタイプにマップされます。

注意:
複数の操作があるのは、OracleAS WebサービスがSQL値をXMLで表すためのデータ表現方法を複数提供しているためです。たとえば、SQL結果セットを様々な方法で表現できます。

次の表では、Webサービス・コールインのSQLからXMLへのマッピングについて説明します。最初の列では、SQLタイプをリストします。XMLタイプ(リテラル)、表の2番目の列は、use属性のデフォルトのリテラル値に対するSQLからXMLタイプへのマッピングを示します。XMLタイプ(エンコード)、3番目の列は、use属性のエンコード値に対するマッピングを示します。リテラル値とエンコード値は、SOAPメッセージの本文をエンコーディングするためのルールを示します。

表10-1 Webサービス・コールインに対するSQLからXMLタイプへのマッピング

SQLタイプ

XMLタイプ(リテラル)

XMLタイプ(エンコード)

INT

int

int

INTEGER

int

int

FLOAT

double

double

NUMBER

decimal

decimal

VARCHAR2

string

string

DATE

dateTime

dateTime

TIMESTAMP

dateTime

dateTime

BLOB

byte[]

byte[]

CLOB

String

String

LONG

String

String

RAW

byte[]

byte[]

Primitive PL/SQL indexby table

Array

Array

PL/SQL Boolean

boolean

boolean

PL/SQL indexby table

complexType

complexType

PL/SQL record

complexType

complexType

REF CURSOR (nameBeans)

Array

Array

REF CURSOR

nameXML)

any

test_xml

REF CURSOR

nameMLRowSet

swaRef

test_xml

SQL object

complexType

complexType

SQL table

complexType

complexType

SYS.XMLTYPE

any

test_xml

注意:
国別言語サポート(「NLS」または「グローバライゼーション・サポート」とも呼ばれます)の文字をSQL SYS.XMLTYPE値に使用している場合、正しく処理されません。

REF CURSORを返す問合せやPL/SQL関数は、下記にリストされている3つのメソッドによってマップされます。ここでの、nameは問合せかPL/SQL関数の名前です。

- nameBeans - このメソッドは配列を返します。配列の各要素はカーソルの1つの行を表すXSD複合型のインスタンスです。複合型のサブ要素はその行の列に対応します。

- nameXMLRowSet - このメソッドは、XML形式のOracleWebRowSetを含むswaRefまたはtext_xmlレスポンスを返します。

- nameXML - このメソッドは、Oracle XDBの行セットを含む任意のXMLまたはtext_xmlレスポンスを返します。

OUTとIN OUT PL/SQLの両方のパラメータは、WSDLファイルのIN OUTパラメータにマップされます。

表10-1では、2つの異なるマッピング・タイプを提供します。1つはリテラルと別のはエンコードのために使用できます。デフォルトのマッピングはリテラルです。Database Webサービスに関しては、エンコードを使用する特別な理由はありません。エンコード使用の設定を呼び出すシナリオを使用する場合のために、エンコードに対するマッピングが提供されています。この章で説明されているすべてのトピックは、特に指定しない限りリテラル使用の設定を使用することを前提としています。

Webサービス・コールアウトに対するXMLからSQLタイプへのマッピング

Database Webサービスのコールアウトでは、XMLタイプがSQLタイプにマップされています。以下の表では、コールアウトに使用するXMLからSQLタイプへのマッピングについて説明します。

表10-2 Webサービス・コールアウトに対するXMLからSQLタイプへのマッピング

XMLタイプ

SQLタイプ

int

NUMBER

float

NUMBER

double

NUMBER

decimal

NUMBER

dateTime

DATE

String

VARCHAR2

byte[]

RAW

complexType

SQL OBJECT

Array

SQL TABLE

test_xml

XML Type

Oracle JDeveloperを使用したDatabase Webサービスの開発

Oracle JDeveloper 11gを使用することで、PL/SQL Webサービスを生成およびデプロイできます。JDeveloperのPL/SQL Webサービス・ウィザードの作成は、PL/SQLパッケージまたはオブジェクト・タイプを使用するJavaストアド・プロシージャからWebサービスを簡単に生成できます。Javaストアド・プロシージャは、それを呼び出すSQL仕様により定義され、PL/SQL Webサービス・ウィザードにより、パッケージと同じように扱われます。Webサービスをボトムアップ形式で作成できます。つまり、WSDLからDatabase Webサービスは作成できません。

詳細については、Oracle JDeveloperオンライン・ヘルプの「Webサービスの開発」節の「PL/SQL Webサービスの作成」を参照してください。

注意:
このリリースでは、問合せ、Java、DMLおよび詳細キュー以外のWebサービスの作成はサポートされません。

11 UDDIを使用したWebサービスのパブリッシュと検索

この章では、UDDI (Universal Description, Discovery, and Integration)を使用したWebサービスのパブリッシュと検索方法について説明します。

この章では、以下のトピックについて説明します。

- UDDIの概要

- WebLogic ServerのUDDI機能

- UDDI 2.0サーバー

- UDDIディレクトリ・エクスプローラ

- UDDIクライアントAPI

- プラガブルtModel

注意:
このリリースでは、UDDI v2.0レジストリとUDDIExplorerアプリケーションは非推奨となっています。お客さまには、SOAの可視性と管理を提供するOracleエンタープライズ・リポジトリまたはOracleサービス・レジストリへのアップグレードについて考慮することをお薦めします。詳細は、http://www.oracle.com/us/products/middleware/soa/enterprise-repository/overview/index.htmlを参照してください。

UDDIの概要

UDDIプロジェクトは、企業が互いに迅速、簡潔、動的にトランザクションを検索および実行できるようにするための業界イニシアティブです。

UDDIレジストリには、ビジネス、ビジネスが提供するサービス、およびビジネスがトランザクションを実行するために使用する通信規格とインタフェースに関する情報がカタログ化されて格納されます。

UDDIはSOAP (Simple Object Access Protocol)データ通信規格に基づいて構築されており、グローバルでプラットフォームに依存しないオープンなアーキテクチャを実現して企業にメリットをもたらします。

UDDIレジストリは、次の2つのカテゴリに大別できます。

- UDDIとWebサービス

- UDDIとビジネス・レジストリ

UDDIのデータ構造の詳細は、「UDDIのデータ構造」を参照してください。

UDDIとWebサービス

Webサービスの所有者は、WebサービスをUDDIレジストリにパブリッシュします。パブリッシュ後、UDDIレジストリにはWebサービスの説明とWebサービスのポインタが保持されます。

UDDIを使用すると、クライアントはこのレジストリを検索し、目的のサービスを見つけてその詳細を取得できます。これらの詳細には、サービスの呼出しポイントのほかに、サービスとその機能を識別するための情報が含まれます。

Webサービス機能は、プログラミング・インタフェースを介して公開され、一般にWeb Services Description Language (WSDL)で記述されます。一般的なパブリッシュ/照会のシナリオでは、プロバイダがそのビジネスをパブリッシュし、その下にサービスを登録し、バインディング・テンプレートにそのWebサービスの技術情報を定義します。バインディング・テンプレートには、1つ以上のtModel(Webサービスによって実装される抽象的なインタフェースを表す)への参照も保存されます。tModelは、インタフェースとWSDLドキュメントのURL参照に関する情報とともに、プロバイダによって独自にパブリッシュされている場合があります。

一般的なクライアントの照会の目的は、次の2つのうちのいずれかです。

- 既知のインタフェースの実装を検索します。この場合、クライアントはtModel IDを持っており、そのModelを参照するバインディング・テンプレートを検索します。

- 既知のバインディング・テンプレートIDの呼出しポイント(アクセス・ポイント)の更新値を検索します。

UDDIとビジネス・レジストリ

ビジネス・レジストリ・ソリューションとしてのUDDIを使用すると、企業は自社のビジネス製品およびサービス、さらにWebでのビジネス・トランザクションの実行方法を公開できます。このようにUDDIを使用することにより、企業間(B2B)電子商取引が補完されます。

ビジネスをパブリッシュするために必要な情報は、1つのビジネス名だけです。パブリッシュされたビジネス・エンティティの詳細な記述には、さまざまな情報が含まれます。こうした情報はすべて、ビジネス・エンティティとその製品およびサービスを、正確に、そしてアクセス可能な形式で公開するのに役立ちます。

ビジネス・レジストリには、次の要素が含まれます。

- ビジネスID - ビジネスの複数の名前と説明、連絡先、および標準のID (納税者番号など)です。

- カテゴリ - 標準のカテゴリ情報(D-U-N-Sビジネス・カテゴリ番号など)です。

- サービスの記述 - サービスの複数の名前と説明です。サービス情報のコンテナとして、企業は様々なサービスを公開しつつ、サービスの所有権を明確に表示できます。bindingTemplate情報は、サービスへのアクセス方法を説明するものです。

- 規格への準拠 - 場合によっては、各種規格への準拠を指定することが重要となります。これらの規格には、サービスの使い方に関する詳細な技術要件が示されます。

- カスタム・カテゴリ - ビジネスまたはサービスを識別または分類する独自仕様(tModels)をパブリッシュできます。

UDDIのデータ構造

UDDIのデータ構造は、businessEntity、businessService、bindingTemplate、tModelという4つの構造で構成されています。

次の表に、Webサービス・アプリケーションまたはビジネス・レジストリ・アプリケーションで使用する場合のこれらの構造の相違点を示します。

表11-1 UDDIのデータ構造

データ構造

Webサービス

ビジネス・レジストリ

businessEntity

Webサービス・プロバイダを表します。

- 企業名

- 連絡先

- その他のビジネス情報

企業、またはその事業部または部門を表します。

- 企業名(複数可)

- 連絡先

- 識別情報およびカテゴリ

businessService

1つ以上のWebサービスの論理グループ。

単一名のAPI。子要素として格納され、上記の名前のビジネス・エンティティによって保持されます。

単一のbusinessEntityに複数のサービスのグループを含めることができます。

- 複数の名前と説明

- カテゴリ

- 規格への準拠の指定

bindingTemplate

単一のWebサービス。

ターゲットWebサービスにバインドして対話するためにクライアント・アプリケーションが必要とする技術情報。

アクセス・ポイント(Webサービスを呼び出すURI)を含んでいます。

追加の規格準拠インスタンス。

URL形式のサービス・アクセス・ポイント、電話番号、電子メール・アドレス、ファックス番号など。

tModel

技術仕様(通常は仕様のポインタ)、または仕様ドキュメントに関するメタデータ(実際の仕様を指す名前およびURLなど)を表します。Webサービスのコンテキストでは、実際の仕様ドキュメントはWSDLファイルで表されます。

標準または技術仕様(定着しているか、またはユーザーが特定用途のために登録したもの)を表します。

WebLogic ServerのUDDI機能

WebLogic Serverは、以下のUDDI機能を提供します。

- UDDI 2.0サーバー

- UDDIディレクトリ・エクスプローラ

- UDDIクライアントAPI

- プラガブルtModel

UDDI 2.0サーバー

UDDI 2.0サーバーはWebLogic Serverの一部であり、WebLogic Serverの起動時に自動的に起動されます。UDDIサーバーは、UDDI 2.0サーバー仕様を実装しています。詳細は、http://uddi.orgを参照してください。

UDDI 2.0サーバーの構成

UDDI 2.0サーバーを構成するには:

1. WebLogic Serverを停止します。

2. WL_HOME/server/libディレクトリのuddi.propertiesファイルを更新します。WL_HOMEは、WebLogic Serverのメイン・インストール・ディレクトリです。

注意:
WebLogic Serverドメインを作成したユーザーがWebLogic Serverをインストールしたユーザーと異なる場合は、WebLogic Server管理者はuddi.propertiesファイルの権限を変更してすべてのユーザーがアクセスできるようにする必要があります。

3. Weblogic Serverを再起動します。

WebLogic Serverの実行中はuddi.propertiesファイルを編集しないでください。このファイルを修正したことでUDDIサーバーが正常に起動しなくなった場合は、WL_HOME/server/lib/uddi.properties.bootedファイルの前回の正常な構成を参照してください。

構成をデフォルトに回復するには、uddi.propertiesファイルをWL_HOME/server/libディレクトリから削除します。このファイルは、バックアップ用のディレクトリに移動することをお薦めします。新しいuddi.propertiesファイルが作成され、正常に起動されたときにuddi.properties.bootedファイルが上書きされるためです。プロパティ・ファイルを削除したら、サーバーを再起動します。最低限のデフォルト・プロパティがロードされ、新しいuddi.propertiesファイルに書き込まれます。

以下の節では、uddi.properitesファイルに追加できるUDDIサーバー・プロパティについて説明します。プロパティのリストは、コンポーネント、用途、および機能に従って分類されています。常にすべてのプロパティが必要というわけではありません。

外部LDAPサーバーの構成

UDDI 2.0サーバーは、組込みLDAPサーバーで自動的に構成されます。しかし、この節の以下の手順によって、外部LDAPサーバーを構成することもできます。

注意:
現時点では、WebLogic ServerはUDDI 2.0サーバーで使用するものとして、SunOne Directory Serverのみをサポートしています。

UDDIで使用するSunOne Directory Serverを構成するには、次の手順に従います:

1. LDAP_DIR/Sun/MPS/slapd-LDAP_INSTANCE_NAME/config/schemaディレクトリ内に51acumen.ldifというファイルを作成します。LDAP_DIRは、SunOne Directory Serverのインストール先のルート・ディレクトリ、LDAP_INSTANCE_NAMEはインスタンス名を表します。

2. 「51acumen.ldifファイルのコンテンツ」で説明するコンテンツを使って、51acumen.ldifファイルを更新します。

3. SunOne Directory Serverを再起動します。

4. WebLogic UDDI 2.0サーバーのuddi.propertiesファイルに以下のプロパティを追加して、更新します。

datasource.ldap.manager.password
datasource.ldap.manager.uid
datasource.ldap.server.root
datasource.ldap.server.url

プロパティの値は、SunOne Directory Serverの構成に応じて異なります。次の例では、デフォルト値を使用する構成として考えられるものを示します。

datasource.ldap.manager.password=password
datasource.ldap.manager.uid=cn=Directory Manager
datasource.ldap.server.root=dc=beasys,dc=com
datasource.ldap.server.url=ldap://host:port

これらのプロパティについては、表11-1を参照してください。

5. Weblogic Serverを再起動します。

51acumen.ldifファイルのコンテンツ

以下のコンテンツを使用して、51acumen.ldifファイルを作成します。

dn: cn=schema
#
# attribute types:
#
attributeTypes: ( 11827.0001.1.0 NAME 'uddi-Business-Key'                DESC 'Business Key' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{41} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.1 NAME 'uddi-Authorized-Name'             DESC 'Authorized Name for publisher of
data' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.2 NAME 'uddi-Operator'                    DESC 'Name of UDDI Registry Operator'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.3 NAME 'uddi-Name'                        DESC 'Business Entity Name' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{258} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.4 NAME 'uddi-Description'                 DESC 'Description of Business Entity'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.7 NAME 'uddi-Use-Type'                    DESC 'Name of convention that the
referenced document follows' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.8 NAME 'uddi-URL'                         DESC 'URL' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.9 NAME 'uddi-Person-Name'                 DESC 'Name of Contact Person' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.10 NAME 'uddi-Phone'                      DESC 'Telephone Number' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{50} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.11 NAME 'uddi-Email'                      DESC 'Email address' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.12 NAME 'uddi-Sort-Code'                  DESC 'Code to sort addresses' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{10} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.13 NAME 'uddi-tModel-Key'                 DESC 'Key to reference a tModel entry'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.14 NAME 'uddi-Address-Line'               DESC 'Actual address lines in free
form text' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{80} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.15 NAME 'uddi-Service-Key'                DESC 'Service Key' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{41} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.16 NAME 'uddi-Service-Name'               DESC 'Service Name' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.17 NAME 'uddi-Binding-Key'                DESC 'Binding Key' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{41} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.18 NAME 'uddi-Access-Point'               DESC 'A text field to convey the entry
point address for calling a web service' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.19 NAME 'uddi-Hosting-Redirector'         DESC 'Provides a Binding Key attribute
to redirect reference to a different binding template' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{41} SINGLE-VALUE
X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.20 NAME 'uddi-Instance-Parms'             DESC 'Parameters to use a specific
facet of a bindingTemplate description' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.21 NAME 'uddi-Overview-URL'               DESC 'URL reference to a long form of
an overview document' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.22 NAME 'uddi-From-Key'                   DESC 'Unique key reference to first
businessEntity assertion is made for' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{41} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.23 NAME 'uddi-To-Key'                     DESC 'Unique key reference to second
businessEntity assertion is made for' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{41} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.24 NAME 'uddi-Key-Name'                   DESC 'An attribute of the
KeyedReference structure' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.25 NAME 'uddi-Key-Value'                  DESC 'An attribute of the
KeyedReference structure' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.26 NAME 'uddi-Auth-Info'                  DESC 'Authorization information'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{4096} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.27 NAME 'uddi-Key-Type'                   DESC 'The key for all UDDI entries'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.28 NAME 'uddi-Upload-Register'            DESC 'The upload register' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.29 NAME 'uddi-URL-Type'                   DESC 'The type for the URL' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{16} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.30 NAME 'uddi-Ref-Keyed-Reference'        DESC 'reference to a keyedReference
entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12{255}  X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.31 NAME 'uddi-Ref-Category-Bag'           DESC 'reference to a categoryBag
entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12{255}  X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.32 NAME 'uddi-Ref-Identifier-Bag'         DESC 'reference to a identifierBag
entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12{255}  X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.33 NAME 'uddi-Ref-TModel'                 DESC 'reference to a TModel entry'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12{255} SINGLE-VALUE X-ORIGIN 'acumen defined' )
# id names for each entry
attributeTypes: ( 11827.0001.1.34 NAME 'uddi-Contact-ID'                 DESC 'Unique ID which will serve as
the Distinguished Name of each entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.35 NAME 'uddi-Discovery-URL-ID'           DESC 'Unique ID which will serve as
the Distinguished Name of each entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.36 NAME 'uddi-Address-ID'                 DESC 'Unique ID which will serve as
the Distinguished Name of each entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.37 NAME 'uddi-Overview-Doc-ID'            DESC 'Unique ID which will serve as
the Distinguished Name of each entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.38 NAME 'uddi-Instance-Details-ID'        DESC 'Unique ID which will serve as
the Distinguished Name of each entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.39 NAME 'uddi-tModel-Instance-Info-ID'    DESC 'Unique ID which will serve as
the Distinguished Name of each entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.40 NAME 'uddi-Publisher-Assertions-ID'    DESC 'Unique ID which will serve as
the Distinguished Name of each entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.41 NAME 'uddi-Keyed-Reference-ID'         DESC 'Unique ID which will serve as
the Distinguished Name of each entry' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} SINGLE-VALUE X-ORIGIN 'acumen
defined' )
attributeTypes: ( 11827.0001.1.42 NAME 'uddi-Ref-Attribute'              DESC 'a reference to another entry'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.43 NAME 'uddi-Entity-Name'                DESC 'Business entity Name' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{258} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.44 NAME 'uddi-tModel-Name'                DESC 'tModel Name' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{255} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.45 NAME 'uddi-tMII-TModel-Key'            DESC 'tModel key referneced in
tModelInstanceInfo' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.46 NAME 'uddi-Keyed-Reference-TModel-Key' DESC 'tModel key referneced in
KeyedReference' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.47 NAME 'uddi-Address-tModel-Key'         DESC 'tModel key referneced in
Address' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.48 NAME 'uddi-isHidden'                   DESC 'a flag to indicate whether an
entry is hidden' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.49 NAME 'uddi-Time-Stamp'                 DESC 'modification time satmp' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.50 NAME 'uddi-next-id'                    DESC 'generic counter' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.51 NAME 'uddi-tModel-origin'              DESC 'tModel origin' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.52 NAME 'uddi-tModel-type'                DESC 'tModel type' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.53 NAME 'uddi-tModel-checked'             DESC 'tModel field to check or not'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.54 NAME 'uddi-user-quota-entity'          DESC 'quota for business entity'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.55 NAME 'uddi-user-quota-service'         DESC 'quota for business services per
entity' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.56 NAME 'uddi-user-quota-binding'         DESC 'quota for binding templates per
service' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.57 NAME 'uddi-user-quota-tmodel'          DESC 'quota for tmodels' SYNTAX
1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.58 NAME 'uddi-user-quota-assertion'       DESC 'quota for publisher assertions'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.59 NAME 'uddi-user-quota-messagesize'     DESC 'quota for maximum message size'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.60 NAME 'uddi-user-language'              DESC 'user language' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.61 NAME 'uddi-Name-Soundex'               DESC 'name in soundex format' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{258} X-ORIGIN 'acumen defined' )
attributeTypes: ( 11827.0001.1.62 NAME 'uddi-var'                        DESC 'generic variable' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'acumen defined' )
#
# objectclasses:
#
objectClasses: ( 11827.0001.2.0 NAME 'uddi-Business-Entity'              DESC 'Business Entity object' SUP top
STRUCTURAL MUST (uddi-Business-Key $ uddi-Entity-Name $ uddi-isHidden $ uddi-Authorized-Name ) MAY (
uddi-Name-Soundex $ uddi-Operator $ uddi-Description $ uddi-Ref-Identifier-Bag $ uddi-Ref-Category-Bag )
X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.1 NAME 'uddi-Business-Service'             DESC 'Business Service object' SUP top
STRUCTURAL MUST ( uddi-Service-Key $ uddi-Service-Name $ uddi-isHidden ) MAY ( uddi-Name-Soundex $
uddi-Description $ uddi-Ref-Category-Bag ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.2 NAME 'uddi-Binding-Template'             DESC 'Binding Template object' SUP TOP
STRUCTURAL   MUST ( uddi-Binding-Key $ uddi-isHidden ) MAY ( uddi-Description $ uddi-Access-Point $
uddi-Hosting-Redirector ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.3 NAME 'uddi-tModel'                       DESC 'tModel object' SUP top
STRUCTURAL   MUST (uddi-tModel-Key $ uddi-tModel-Name $ uddi-isHidden $ uddi-Authorized-Name ) MAY (
uddi-Name-Soundex $ uddi-Operator $ uddi-Description $ uddi-Ref-Identifier-Bag $ uddi-Ref-Category-Bag $
uddi-tModel-origin $ uddi-tModel-checked $ uddi-tModel-type ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.4 NAME 'uddi-Publisher-Assertion'          DESC 'Publisher Assertion object' SUP
TOP STRUCTURAL   MUST ( uddi-Publisher-Assertions-ID $ uddi-From-Key $ uddi-To-Key $ uddi-Ref-Keyed-Reference )
X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.5 NAME 'uddi-Discovery-URL'                DESC 'Discovery URL' SUP TOP
STRUCTURAL   MUST ( uddi-Discovery-URL-ID $ uddi-Use-Type $ uddi-URL ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.6 NAME 'uddi-Contact'                      DESC 'Contact Information' SUP TOP
STRUCTURAL   MUST ( uddi-Contact-ID $ uddi-Person-Name ) MAY ( uddi-Use-Type $ uddi-Description $ uddi-Phone $
uddi-Email $ uddi-tModel-Key ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.7 NAME 'uddi-Address'                      DESC 'Address information for a
contact entry' SUP TOP STRUCTURAL   MUST ( uddi-Address-ID ) MAY ( uddi-Use-Type $ uddi-Sort-Code $
uddi-Address-tModel-Key $ uddi-Address-Line ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.8 NAME 'uddi-Keyed-Reference'              DESC 'KeyedReference' SUP TOP
STRUCTURAL   MUST ( uddi-Keyed-Reference-ID $ uddi-Key-Value ) MAY ( uddi-Key-Name $
uddi-Keyed-Reference-TModel-Key ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.9 NAME 'uddi-tModel-Instance-Info'         DESC 'tModelInstanceInfo' SUP TOP
STRUCTURAL   MUST ( uddi-tModel-Instance-Info-ID $ uddi-tMII-TModel-Key ) MAY ( uddi-Description ) X-ORIGIN
'acumen defined' )
objectClasses: ( 11827.0001.2.10 NAME 'uddi-Instance-Details'            DESC 'instanceDetails' SUP TOP
STRUCTURAL   MUST ( uddi-Instance-Details-ID ) MAY ( uddi-Description $ uddi-Instance-Parms ) X-ORIGIN 'acumen
defined' )
objectClasses: ( 11827.0001.2.11 NAME 'uddi-Overview-Doc'                DESC 'overviewDoc' SUP TOP STRUCTURAL
MUST ( uddi-Overview-Doc-ID ) MAY ( uddi-Description $ uddi-Overview-URL ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.12 NAME 'uddi-Ref-Object'                  DESC 'an object class conatins a
reference to another entry' SUP TOP STRUCTURAL MUST ( uddi-Ref-Attribute ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.13 NAME 'uddi-Ref-Auxiliary-Object'        DESC 'an auxiliary type object used in
another structural class to hold a reference to a third entry' SUP TOP AUXILIARY MUST ( uddi-Ref-Attribute )
X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.14 NAME 'uddi-ou-container'                DESC 'an organizational unit with uddi
attributes' SUP organizationalunit STRUCTURAL MAY ( uddi-next-id $ uddi-var ) X-ORIGIN 'acumen defined' )
objectClasses: ( 11827.0001.2.15 NAME 'uddi-User'                        DESC 'a User with uddi attributes' SUP
inetOrgPerson STRUCTURAL MUST ( uid $ uddi-user-language $ uddi-user-quota-entity $ uddi-user-quota-service $
uddi-user-quota-tmodel $ uddi-user-quota-binding $ uddi-user-quota-assertion $ uddi-user-quota-messagesize )
X-ORIGIN 'acumen defined' )

uddi.propertiesファイルのプロパティ

次の表に、uddi.propertiesファイルのプロパティを、説明されるUDDIのタイプ別に示します。

- 表11-2 基本的なUDDI構成

- 表11-3 UDDIのユーザー・デフォルト

- 表11-4 一般的なサーバーの構成

- 表11-5 ロガーの構成

- 表11-6 接続プール

- 表11-7 LDAPデータストアの構成

- 表11-8 複製LDAPデータストアの構成

- 表11-9 ファイル・データストアの構成

- 表11-10 一般的なセキュリティの構成

- 表11-11 LDAPセキュリティの構成

- 表11-12 ファイル・セキュリティの構成

表11-2 基本的なUDDI構成

UDDIプロパティ・キー

説明

auddi.discoveryurl

保存されたビジネス・エンティティごとに設定されるDiscoveryURL接頭辞。通常、これはuddilistenerサーブレットの完全なURLとなるため、完全なDiscoveryURLを指定すると、格納されたBusinessEntityデータが表示されます。

auddi.inquiry.secure

許容値は、trueおよびfalseです。trueに設定すると、UDDIサーバーの照会呼出しはセキュアなhttps接続だけに制限されます。通常のhttp URLを介したUDDI照会呼出しは拒否されます。

auddi.publish.secure

許容値は、trueおよびfalseです。trueに設定すると、UDDIサーバーのパブリッシュ呼出しはセキュアなhttps接続だけに制限されます。通常のhttp URLを介したUDDIパブリッシュ呼出しは拒否されます。

auddi.search.maxrows

検索操作で返される行の最大数。検索の結果がこの最大行数を超えると、結果が切り詰められます。

auddi.search.timeout

検索操作のタイムアウト値。この値は、ミリ秒単位で指定します。

auddi.siteoperator

UDDIレジストリのサイト・オペレータの名前。指定した値はオペレータ属性として使用され、以後のすべてのBusinessEntity登録に保存されます。この属性はレスポンスで返され、どのUDDIレジストリがレスポンスを生成したかを示します。

security.cred.life

認証の資格証明の存続期間(秒単位で指定)。ユーザーの認証時に、このプロパティで指定した有効期限を持つAuthTokenが割り当てられます。

pluggableTModel.file.list

UDDIサーバーには、標準のTModelがあらかじめ組み込まれています。独自の分類法を使用して、TModel形式でUDDIサーバーをさらにカスタマイズできます。分類法は、XMLスキーマに従ってXMLファイルに定義する必要があります。このプロパティの値は、URI (XMLファイルなど)のカンマ区切りリストです。これらのTModelを表す値は、指定した分類法に照らし合わされてチェックおよび検証されます。

表11-3 UDDIのユーザー・デフォルト

UDDIプロパティ・キー

説明

auddi.default.lang

ユーザーの初期言語。デフォルトでは作成時にユーザー・プロファイルに割り当てられます。ユーザー・プロファイルの設定は、サインアップ時またはそれ以降に変更できます。

auddi.default.quota.assertion

ユーザーの初期アサーション割当て。デフォルトでは作成時にユーザー・プロファイルに割り当てられます。アサーション割当ては、ユーザーがパブリッシュできるパブリッシャ・アサーションの最大数。制限を設定しない場合は、値を -1に設定します。ユーザーのプロファイル設定は、サインアップ時またはそれ以降に変更できます。

auddi.default.quota.binding

ユーザーの初期バインディング割当て。デフォルトでは作成時にユーザー・プロファイルに割り当てられます。バインディング割当ては、ビジネス・サービスごとにユーザーがパブリッシュできるバインディング・テンプレートの最大数。制限を設定しない場合は、値を -1に設定します。ユーザーのプロファイル設定は、サインアップ時またはそれ以降に変更できます。

auddi.default.quota.entity

ユーザーの初期ビジネス・エンティティ割当て。デフォルトでは作成時にユーザー・プロファイルに割り当てられます。エンティティ割当ては、ユーザーがパブリッシュできるビジネス・エンティティの最大数。制限を設定しない場合は、値を -1に設定します。ユーザーのプロファイル設定は、サインアップ時またはそれ以降に変更できます。

auddi.default.quota.messageSize

ユーザーの初期メッセージ・サイズ制限。デフォルトでは作成時にユーザー・プロファイルに割り当てられます。メッセージ・サイズ制限は、ユーザーがUDDIサーバーに送信できるSOAP呼出しの最大サイズ。制限を設定しない場合は、値を -1に設定します。ユーザーのプロファイル設定は、サインアップ時またはそれ以降に変更できます。

auddi.default.quota.service

ユーザーの初期サービス割当て。デフォルトでは作成時にユーザー・プロファイルに割り当てられます。サービス割当ては、ビジネス・エンティティごとにユーザーがパブリッシュできるビジネス・サービスの最大数。制限を設定しない場合は、値を -1に設定します。ユーザーのプロファイル設定は、サインアップ時またはそれ以降に変更できます。

auddi.default.quota.tmodel

ユーザーの初期TModel割当て。デフォルトでは作成時にユーザー・プロファイルに割り当てられます。TModel割当ては、ユーザーがパブリッシュできるTModelの最大数。制限を設定しない場合は、値を -1に設定します。ユーザーのプロファイル設定は、サインアップ時またはそれ以降に変更できます。

表11-4 一般的なサーバーの構成

UDDIプロパティ・キー

説明

auddi.datasource.type

UDDIデータの物理ストレージの場所。この値はデフォルトではWLSとなります。これは、WebLogic Serverの内部LDAPディレクトリがデータ・ストレージ用に使用されることを示します。その他の許容値は、LDAP、ReplicaLDAP、およびFile。

auddi.security.type

UDDIサーバーのセキュリティ・モジュール(認証)。この値はデフォルトではWLSとなります。これは、WebLogic Serverのデフォルト・セキュリティ・レルムがUDDI認証用に使用されることを示します。このため、WebLogic ServerユーザーはUDDIサーバー・ユーザーとなります。また、どのWebLogic Server管理者もUDDIサーバー管理者となり、UDDIサーバー設定で定義されているUDDIサーバーの管理者グループのメンバーに加えられます。その他の許容値は、LDAPおよびFile。

auddi.license.dir

UDDIサーバーのライセンス・ファイルの場所。このプロパティを指定しない場合、WL_HOME/server/libディレクトリがデフォルトのライセンス・ディレクトリと見なされます。WL_HOMEは、WebLogic Serverのメイン・インストール・ディレクトリ。一部のWebLogicユーザーは、基本UDDIサーバー・コンポーネントのUDDIサーバー・ライセンスの取得を免除されていますが、追加コンポーネント(UDDIサーバー・ブラウザなど)についてはライセンスが必要になる場合があります。

auddi.license.file

ライセンス・ファイルの名前。このプロパティを指定しない場合、uddilicense.xmlがデフォルトのライセンス・ファイル名と見なされます。一部のWebLogicユーザーは、基本UDDIサーバー・コンポーネントのUDDIサーバー・ライセンスの取得を免除されていますが、追加コンポーネント(UDDIサーバー・ブラウザなど)についてはライセンスが必要になる場合があります。

表11-5 ロガーの構成

UDDIプロパティ・キー

説明

logger.file.maxsize

ロガー出力ファイルの最大サイズ(出力がファイルに送信される場合)。単位はKB。出力ファイルが最大サイズに達すると、そのファイルは閉じられ、新しいログ・ファイルが作成されます。

logger.indent.enabled

許容値は、trueおよびfalseです。trueに設定すると、「+」および「-」で始まるログ・メッセージ(通常TRACEレベルのログ)によって出力のインデントが増減されます。

logger.indent.size

各インデントのサイズ(スペースの数)。整数として指定します。

logger.log.dir

ログ・ファイルが格納されるディレクトリの絶対パスまたは相対パス。

logger.log.file.stem

すべてのログ・ファイル名の先頭に付加される文字列。

logger.log.type

ログ・メッセージの出力先を画面にするか、ファイルにするか、またはその両方にするかを決定します。許容値は、それぞれLOG_TYPE_SCREEN、LOG_TYPE_FILE、LOG_TYPE_SCREEN_FILEです。

logger.output.style

ログ出力にメッセージだけを含めるか、またはスレッドおよびタイムスタンプ情報を含めるかを決定します。許容値は、OUTPUT_LONGとOUTPUT_SHORTです。

logger.quiet

ロガー自体に情報メッセージを表示するかどうかを決定します。許容値は、trueおよびfalseです。

logger.verbosity

ロガーの冗長レベル。許容値(大文字と小文字は区別される)は、TRACE、DEBUG、INFO、WARNING、ERROR。各重大度には、下位の重大度も含まれます。

表11-6 接続プール

UDDIプロパティ・キー

説明

datasource.ldap.pool.increment

プール内のすべての接続がビジーの場合に、作成してプールに追加する新しい接続の数

datasource.ldap.pool.initialsize

プールの作成および初期化時に格納される接続数。

datasource.ldap.pool.maxsize

プールが保持できる接続の最大数。

datasource.ldap.pool.systemmaxsize

プールがその最大容量に達した後に作成される接続の最大数。プールが最大サイズに達し、すべての接続がビジーの場合、新しい接続が一時的に作成されてクライアントに返されます。この接続はプールには格納されません。しかし、システムの最大サイズに達すると、ビジー接続が使用可能になるまで新しい接続リクエストはすべてブロックされます。

表11-7 LDAPデータストアの構成

UDDIプロパティ・キー

説明

datasource.ldap.manager.uid

LDAPにデータを保存できるバックエンドLDAPサーバー管理者または権限があるユーザーのID (cn=Directory Managerなど)。

datasource.ldap.manager.password

datasource.ldap.manager.uidのパスワード。データ・ストレージ用のLDAPディレクトリとの接続を確立します。

datasource.ldap.server.url

データ・ストレージ用のLDAPディレクトリの「ldap://」URL。

datasource.ldap.server.root

データ・ストレージ用のLDAPディレクトリのルート・エントリ(dc=acumenat、dc=comなど)。

注意:
複製LDAP環境には、「m」LDAPマスタと「n」LDAPレプリカがあります。これらの番号は、それぞれ0から(m-1)および0から(n-1)です。次のプロパティ・キーの5番目の部分の「i」はこの番号を表しており、定義されているLDAPサーバー・インスタンスによって異なります。

表11-8 複製LDAPデータストアの構成

UDDIプロパティ・キー

説明

datasource.ldap.server.master.i.manager.uid

LDAPにデータを保存できる、このマスタLDAPサーバー・ノードの管理者または権限があるユーザーID (cn=Directory Managerなど)。

datasource.ldap.server.master.i.manager.password

datasource.ldap.server.master.i.manager.uidのパスワード。データを書き込むための関連するマスタLDAPディレクトリとの接続を確立します。

datasource.ldap.server.master.i.url

対応するLDAPディレクトリ・ノードの「ldap://」URL。

datasource.ldap.server.master.i.root

対応するLDAPディレクトリ・ノードのルート・エントリ(dc=acumenat、dc=comなど)。

datasource.ldap.server.replica.i.manager.uid

このレプリカLDAPサーバー・ノードのユーザーID (cn=Directory Managerなど)。このユーザーはLDAPからUDDIデータを読み出すことができます。

datasource.ldap.server.replica.i.manager.password

datasource.ldap.server.replica.i.manager.uidのパスワード。データを読み出すための関連するレプリカLDAPディレクトリとの接続を確立します。

datasource.ldap.server.replica.i.url

対応するLDAPディレクトリ・ノードの「ldap://」URL。

datasource.ldap.server.replica.i.root

対応するLDAPディレクトリ・ノードのルート・エントリ(dc=acumenat、dc=comなど)。

表11-9 ファイル・データストアの構成

UDDIプロパティ・キー

説明

datasource.file.directory

UDDIデータを格納するファイル・システムのディレクトリ。

表11-10 一般的なセキュリティの構成

UDDIプロパティ・キー

説明

security.custom.group.operators

セキュリティ・グループ名。このグループのメンバーはUDDI管理者として扱われます。

表11-11 LDAPセキュリティの構成

UDDIプロパティ・キー

説明

security.custom.ldap.manager.uid

セキュリティLDAPサーバー管理者または権限があるユーザーID (cn=Directory Managerなど)。このユーザーは、LDAPにデータを保存することができます。

security.custom.ldap.manager.password

このプロパティの値は、上記のユーザーIDのパスワードであり、セキュリティ用のLDAPディレクトリに接続するために使用します。

security.custom.ldap.url

このプロパティの値は、セキュリティ用のLDAPディレクトリの「ldap://」URL。

security.custom.ldap.root

セキュリティ用のLDAPディレクトリのルート・エントリ(dc=acumenat、dc=comなど)。

security.custom.ldap.userroot

セキュリティLDAPサーバーのユーザー・ルート・エントリ。ou=Peopleなど。

security.custom.ldap.group.root

セキュリティLDAPサーバーのオペレータ・エントリ。たとえば、「cn=UDDI Administrators, ou=Groups」のように指定します。このエントリにはすべてのUDDI管理者のIDが含まれます。

表11-12 ファイル・セキュリティの構成

UDDIプロパティ・キー

説明

security.custom.file.userdir

UDDIセキュリティ情報(ユーザーとグループ)の格納先となるファイル・システムのディレクトリ。

UDDIディレクトリ・エクスプローラ

UDDIディレクトリ・エクスプローラを使用すると、認可されたユーザーは、WebLogic ServerのプライベートなUDDIレジストリにWebサービスをパブリッシュしたり、すでにパブリッシュされているWebサービスの情報を変更することができます。また、Webサービスおよび関連付けられたWSDLファイル(利用可能な場合)に関する詳細情報にアクセスできます。

また、UDDIディレクトリ・エクスプローラを使用して、パブリックとプライベート両方のUDDIレジストリにあるWebサービス、およびこれらのWebサービスを提供している企業や部門に関する情報を検索できます。

ブラウザでUDDIディレクトリ・エクスプローラを起動するには、次を入力します:

http://host:port/uddiexplorer

ここで

- hostは、WebLogic Serverが動作しているコンピュータ。

- portは、WebLogic Serverが接続リクエストをリスニングするポート番号。デフォルトのポート番号は7001です。

注意:
Oracle WebLogic Serverユーザー名およびパスワードを使用して、「UDDIディレクトリ・エクスプローラ」ページにアクセスします。

UDDIディレクトリ・エクスプローラを使用して、以下のタスクを実行できます。

- パブリック・レジストリの検索

- プライベート・レジストリの検索

- プライベート・レジストリへのパブリッシュ

- プライベート・レジストリの詳細の変更

- UDDIディレクトリ・エクスプローラのセット・アップ

UDDIディレクトリ・エクスプローラの使い方の詳細は、メイン・ページの「Explorer Help」リンクをクリックしてください。

UDDIクライアントAPI

WebLogic Serverには、Javaクライアント・アプリケーションでWebサービスをプログラムから検索およびパブリッシュするために使用できるクライアント側UDDI APIが組み込まれています。

UDDIクライアントAPIには、InquiryとPublishという、2つの主なクラスがあります。Inquiryクラスは、既知のUDDIレジストリにあるWebサービスの検索に使用し、Publishクラスは、開発したWebサービスを既知のレジストリに追加するために使用します。

WebLogic Serverでは、以下のクライアントUDDI APIパッケージを実装しています。

- 「weblogic.uddi.client.service」

- 「weblogic.uddi.client.structures.datatypes」

- 「weblogic.uddi.client.structures.exception」

- 「weblogic.uddi.client.structures.request」

- 「weblogic.uddi.client.structures.response」

これらのパッケージの使用方法の詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

プラガブルtModel

分類法は、基本的にcategoryBagまたはidentifierBagによって参照として使用されるtModelです。主な相違点は、単純なtModelに対して、分類法の参照は一般にチェックおよび検証されることです。WebLogic ServerのUDDIサーバーはこのコンセプトを活用し、プラガブルtModelという独自の分類法を採用することでこの機能を拡張します。プラガブルtModelを使用すると、ユーザー(UDDI管理者)は独自のチェック済み分類法をUDDIレジストリに追加し、標準の分類法を上書きできます。

プラガブルtModelを追加するには:

1. 「プラガブルtModelのXMLスキーマ」で説明する形式に従って、tModelKey/categorizationごとにXMLファイルを作成します。

2. UDDIサーバーを構成するために使用するuddi.propertiesファイルのpluggableTModel.file.listプロパティに、ファイルのカンマ区切りの完全修飾名を追加します。例:

pluggableTModel.file.list=c:/temp/cat1.xml,c:/temp/cat2.xml

uddi.propertiesファイルの詳細は、「UDDI 2.0サーバーの構成」を参照してください。

3. Weblogic Serverを再起動します。

以下の節では、XML要素とその許容値の表、プラガブルtModelの検証に使用するXMLスキーマ、およびサンプルXMLを示します。

XML要素と許容値

次の表に、プラガブルtModelを記述するXMLファイルの要素について説明します。

表11-13 プラガブルtModelを構成するためのXML要素の説明

要素/属性

必須

ロール

値

コメント

Taxonomy

必須

ルート要素

-

なし

checked

必須

この分類がチェックされるかどうか。

trueまたはfalse

falseを指定すると、keyValueは検証されません。

type

必須

tModelのタイプ。

categorization、identifier、uddi-org-typesで定義した有効値

有効値についてはuddi-org-types tModelを参照してください。

applicability

オプション

tModelの使用に関する制約。

-

この要素を指定しない場合、制約があるとは見なされません

scope

applicability要素が含まれている場合は必須

tModelの使用に関する制約。

businessEntity、businessService、bindingTemplate、tModel

「bindingTemplate」を指定した場合、tModelはtModelInstanceInfoで使用できます。

tModel

必須

UDDIデータ構造に従った実際のtModel。

有効なtModelKey

なし

categories

checkedがtrueの場合は必須

-

-

なし

category

categories要素が含まれている場合は必須

実際のkeyNameとkeyValueを保持します。

keyNameとkeyValueのペア

categoryは、グループ化またはツリー構造用にネストできます。

keyName

必須

-

-

なし

keyValue

必須

-

-

なし

プラガブルtModelのXMLスキーマ

プラガブルtModelのXMLスキーマは次のように検証されます。

<simpleType name="type">
<restriction base="string"/>
</simpleType>

<simpleType name="checked">
<restriction base="NMTOKEN">
<enumeration value="true"/>
<enumeration value="false"/>
</restriction>
</simpleType>

<element name="scope" type="string"/>

<element name = "applicability" type = "uddi:applicability"/>

<complexType name = "applicability">
<sequence>
<element ref = "uddi:scope" minOccurs = "1" maxOccurs = "4"/>
</sequence>
</complexType>

<element name="category" type="uddi:category"/>

<complexType name = "category">
<sequence>
<element ref = "uddi:category" minOccurs = "0" maxOccurs = "unbounded"/>

</sequence>
<attribute name = "keyName" use = "required" type="string"/>
<attribute name = "keyValue" use = "required" type="string"/>
</complexType>
<element name="categories" type="uddi:categories"/>

<complexType name = "categories">
<sequence>
<element ref = "uddi:category" minOccurs = "1" maxOccurs = "unbounded"/>
</sequence>
</complexType>

<element name="Taxonomy" type="uddi:Taxonomy"/>

<complexType name="Taxonomy">
<sequence>
<element ref = "uddi:applicability" minOccurs = "0" maxOccurs = "1"/>
<element ref = "uddi:tModel" minOccurs = "1" maxOccurs = "1"/>
<element ref = "uddi:categories" minOccurs = "0" maxOccurs = "1"/>
</sequence>
<attribute name = "type" use = "required" type="uddi:type"/>
<attribute name = "checked" use = "required" type="uddi:checked"/>
</complexType>

プラガブルtModelのサンプルXML

次に、プラガブルtModelのサンプルXMLを示します。

<?xml version="1.0" encoding="UTF-8" ?>

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Body>

<Taxonomy checked="true" type="categorization" xmlns="urn:uddi-org:api_v2" >
<applicability>
<scope>businessEntity</scope>
<scope>businessService</scope>
<scope>bindingTemplate</scope>
</applicability>
<tModel  tModelKey="uuid:C0B9FE13-179F-41DF-8A5B-5004DB444tt2" >
<name> sample pluggable tModel </name>
<description>used for test purpose only </description>
<overviewDoc>
<overviewURL>http://www.abc.com </overviewURL>
</overviewDoc>
</tModel>
<categories>
<category keyName="name1 " keyValue="1">
<category keyName="name11" keyValue="12">
<category keyName="name111" keyValue="111">
<category keyName="name1111" keyValue="1111"/>
<category keyName="name1112" keyValue="1112"/>
</category>
<category keyName="name112" keyValue="112">
<category keyName="name1121" keyValue="1121"/>
<category keyName="name1122" keyValue="1122"/>
</category>
</category>
</category>
<category keyName="name2 " keyValue="2">
<category keyName="name21" keyValue="22">
<category keyName="name211" keyValue="211">
<category keyName="name2111" keyValue="2111"/>
<category keyName="name2112" keyValue="2112"/>
</category>
<category keyName="name212" keyValue="212">
<category keyName="name2121" keyValue="2121"/>
<category keyName="name2122" keyValue="2122"/>
</category>
</category>
</category>
</categories>
</Taxonomy>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

A 信頼性のあるメッセージング用にパッケージ化されているWS-Policyファイル

この付録では、あらかじめパッケージ化されているWS-Policyファイルについて説明します。このファイルには、WebLogic Java API for XML-based RPC (JAX-RPC) Webサービスで信頼性のあるメッセージングをサポートするために使用できる標準的な信頼性のあるメッセージング・アサーションが含まれています。

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

- DefaultReliability1.1.xml (WS-Policyファイル)

- Reliability1.1_SequenceTransportSecurity.xml (WS-Policyファイル)

- Reliability1.1_SequenceSTR.xml (WS-Policyファイル)

- Reliability1.0_1.1.xml (WS-Policy.xmlファイル)

- DefaultReliability.xml (WS-Policyファイル) [非推奨]

- LongRunningReliability.xml (WS-Policyファイル) [非推奨]

あらかじめパッケージ化されているファイルは変更できません。値がニーズに合わない場合は、独自のWS-Policyファイルを作成する必要があります。詳細は、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。信頼性のあるメッセージングのポリシー・アサーションに関するリファレンス情報は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

DefaultReliability1.1.xml (WS-Policyファイル)

DefaultRealiability1.1.xml WS-Policyファイルは、サービス品質に関連するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいています。

<?xml version="1.0"?>

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
>
<wsrmp:RMAssertion
xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702"
>
<wsrmp:DeliveryAssurance>
<wsp:Policy>
<wsrmp:ExactlyOnce />
</wsp:Policy>
</wsrmp:DeliveryAssurance>
</wsrmp:RMAssertion>
</wsp:Policy>

Reliability1.1_SequenceTransportSecurity.xml (WS-Policyファイル)

Reliability1.1_SequenceTransportSecurity.xmlファイルは、トランスポート・レベルのセキュリティおよびサービス品質に関連するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいています。

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsrmp:RMAssertion
xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
<wsrmp:SequenceTransportSecurity/>
<wsrmp:DeliveryAssurance>
<wsp:Policy>
<wsrmp:ExactlyOnce/>
</wsp:Policy>
</wsrmp:DeliveryAssurance>
</wsrmp:RMAssertion>
</wsp:Policy>

Reliability1.1_SequenceSTR.xml (WS-Policyファイル)

Reliability1.1_SequenceSTR.xmlファイルは、信頼性のあるシーケンスでメッセージを保護するために、CreateSequenceで参照されるwsse:SecurityTokenReferenceをランタイムが使用するよう指定します。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいています。

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsrmp:RMAssertion
xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
<wsrmp:SequenceSTR/>
<wsrmp:DeliveryAssurance>
<wsp:Policy>
<wsrmp:ExactlyOnce/>
</wsp:Policy>
</wsrmp:DeliveryAssurance>
</wsrmp:RMAssertion>
</wsp:Policy>

Reliability1.0_1.1.xml (WS-Policy.xmlファイル)

Reliability1.0_1.1.xml WS-Policy.xmlファイルは、Webサービスの信頼性のあるメッセージング・ポリシーのアサーションのバージョン1.1と1.0を結合します。このサンプルは、適切なポリシーの選択に基づいて実行時に適用されるポリシー・アサーションを決定します。適切なポリシー選択の詳細は、「複数のポリシー選択肢の使用」を参照してください。

注意:
1.0のWebサービスの信頼性のあるメッセージング・アサーションには、接頭辞としてwsrmp10が付加されます。

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<wsrmp10:RMAssertion
xmlns:wsrmp10="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
<wsrmp10:InactivityTimeout Milliseconds="600000"/>
<wsrmp10:BaseRetransmissionInterval Milliseconds="3000"/>
<wsrmp10:ExponentialBackoff/>
<wsrmp10:AcknowledgementInterval Milliseconds="200"/>
</wsrmp10:RMAssertion>
</wsp:All>
<wsp:All>
<wsrmp:RMAssertion
xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
<wsrmp:SequenceSTR/>
<wsrmp:DeliveryAssurance>
<wsp:Policy>
<wsrmp:ExactlyOnce/>
</wsp:Policy>
</wsrmp:DeliveryAssurance>
</wsrmp:RMAssertion>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

DefaultReliability.xml (WS-Policyファイル) [非推奨]

このWS-Policyファイルは非推奨となっています。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion Version 1.0(http://schemas.xmlsoap.org/ws/2005/02/rm/policy/)に基づいています。現在のリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

DefaultReliability.xml WS-Policyファイルは、信頼性のあるメッセージングのポリシーのアサーションに一般的な値(非アクティブ・タイムアウト10分、確認応答の間隔200ミリ秒、基本的な再送信間隔3秒など)を指定します。

<?xml version="1.0"?>

<wsp:Policy
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:beapolicy="http://www.bea.com/wsrm/policy"
>

<wsrm:RMAssertion >

<wsrm:InactivityTimeout
Milliseconds="600000" />
<wsrm:BaseRetransmissionInterval
Milliseconds="3000" />
<wsrm:ExponentialBackoff />
<wsrm:AcknowledgementInterval
Milliseconds="200" />
<beapolicy:Expires Expires="P1D" optional="true"/>
</wsrm:RMAssertion>

</wsp:Policy>

LongRunningReliability.xml (WS-Policyファイル) [非推奨]

このWS-Policyファイルは非推奨となっています。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion Version 1.0(http://schemas.xmlsoap.org/ws/2005/02/rm/policy/)に基づいています。現在のリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

LongRunningRelibility.xml WS-PolicyファイルはDefaultReliability.xml WS-Policyファイルと同様の値を指定しますが、より長いアクティビティのタイムアウト間隔(24時間)を指定する点が異なります。「LongRunningReliability.xml (WS-Policyファイル) [非推奨]」を参照してください。

<?xml version="1.0"?>

<wsp:Policy
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:beapolicy="http://www.bea.com/wsrm/policy"
>

<wsrm:RMAssertion >

<wsrm:InactivityTimeout
Milliseconds="86400000" />
<wsrm:BaseRetransmissionInterval
Milliseconds="3000" />
<wsrm:ExponentialBackoff />
<wsrm:AcknowledgementInterval
Milliseconds="200" />
<beapolicy:Expires Expires="P1M" optional="true"/>
</wsrm:RMAssertion>

</wsp:Policy>

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

コピーライトについて

Copyright © 1994-2015, 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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

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

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

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

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

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