| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.1.3) E53004-06 |
|
 前 |
 次 |
この章では、WSトランスポートの概要と、サービスでの使用および構成方法について説明します。WSトランスポートでは、Webサービス信頼できるメッセージング(Web Services Reliable Messaging: WSRM)をService Busで使用できます。
この章の内容は次のとおりです。
WSトランスポートは、SOAP 1.1およびSOAP 1.2に基づくWebサービスの信頼性のあるメッセージング(WSRM)ポリシーを持ったWSDLドキュメントから派生したサービスに関するインバウンド・リクエストとアウトバウンド・リクエストの両方を実装しています。ただし、WSRMポリシーはWSDLファイルの一部である場合と、サービスにアタッチされる場合とがあります。さらに、セキュリティ・ポリシーもWSDLファイルで宣言される場合と、WSDLベースのサービスに関連付けられる場合があります。Service BusでWSDLベースのサービスにWSRMポリシーを構成する場合は、サービスにWSトランスポートを選択する必要があります。Service Busでは、サービスの構成が保存されるときにWSRMポリシーがチェックされて、WSRMポリシーがサービスに関連付けられたWSDLファイルで宣言されていない場合、検証エラーが送出されます。
Webサービスの信頼性のあるメッセージングは、WS信頼できるメッセージングまたは単にWSRMとも呼ばれます。この仕様では、ソフトウェアやシステム、ネットワークに障害が発生した場合でも、分散アプリケーション間で信頼性のあるメッセージ配信を可能にするプロトコルについて記述されています。WS-ReliableMessagingは、IBM、Oracle、Microsoft、およびTIBCO Systemsによって共同開発された仕様です。この仕様は、OASISによって開発された競合関係にある仕様のWS-Reliability (WSR)とは異なります。
Service Busは、2005年2月に提出された仕様をサポートしています。この仕様の詳細は、「Web Services Reliable Messagingプロトコル(WS-ReliableMessaging)」(http://schemas.xmlsoap.org/ws/2005/02/rm/)を参照してください。
WSトランスポートの主要な機能を次に示します。
一方向およびリクエスト/レスポンスのメッセージ・パターン。詳細は、「メッセージング・パターン」を参照してください。
WSトランスポートと他のトランスポート(JMS、SB、およびTuxedoトランスポート)間でXAトランザクションをサポートする「必ず1回(Exactly Once)」送信。
基本認証を使用するHTTPS、およびクライアント証明書認証(双方向SSL)を使用するがクライアント認証を使用しないHTTPS。詳細は、「サービスの認証と認可」を参照してください。
リソースのインポート中のWSRMセキュリティ構成の保持。詳細は、「リソースのインポートとエクスポート」を参照してください。
WSプロキシ・サービスに対するトランスポート・レベル・アクセス制御ポリシーの割当て。このポリシーを割り当てることができるのは管理者に限られます。詳細は、「トランスポート・レベルのアクセス・ポリシーの構成方法」を参照してください。
2004年8月に提出されたWS-Addressingの仕様。詳細は、「Web Services Addressing (WS-Addressing)」(http://www.w3.org/Submission/ws-addressing/)を参照してください。
WS-I基本プロファイルへの準拠。詳細は、「Webサービスの相互運用性」を参照してください。
Service BusのWSプロキシに対するサービスの品質(QoS)は、常に「必ず1回」に設定されます。詳細は、「サービスの品質」を参照してください。
QoSは<beapolicy:QOS>要素を使用して、RMポリシー・ファイルで設定できます。この要素にはQOSという属性が1つあり、次の値のいずれかを使用します。
AtMostOnce
AtLeastOnce
ExactlyOnce
InOrder
注意:
WSトランスポートのQoSは、Service BusのQoSとは異なります。
プロキシ・サービスまたはビジネス・サービスのWSRMポリシーに関連付けられるのは、SOAP 1.1およびSOAP 1.2に基づくWSDLファイルに限られます。詳細は、「WSトランスポートを使用するプロキシ・サービスの構成」および「WSトランスポートを使用するビジネス・サービスの構成」を参照してください。
WSRMでは、一方向とリクエスト/レスポンスの両方のメッセージング・パターンがサポートされます。WSトランスポートでは、信頼性のあるレスポンスはサポートされていません。リクエストには常に信頼性がありますが、レスポンスには信頼性がありません。
ビジネス・サービスの場合、外部Webサービスへのリクエストの送信は非同期で行われます。呼出しの成功は、メッセージがRMレイヤーに無事に到達し、確実に配信されることを示します。しかし、呼出しに成功しても、メッセージがエンドポイントに送信され、Webサービスの呼出しに成功するという意味ではありません。
リクエスト/レスポンス・メッセージング・パターンの場合、リクエストに対するレスポンスを外部Webサービスから受信します。この場合、リクエストとレスポンスのパスには2つの異なるトランザクションがあり、2つの異なるスレッドで実行されます。レスポンス・パイプラインは、一方向メッセージングのメッセージ・パターンで均等に実行されます。一方向のパターンの場合、レスポンス・パイプラインの呼出しは、メッセージが確実にターゲットの宛先に到達し、Webサービスの呼出しが完了したことを意味します。
WSトランスポートを使用するプロキシ・サービスまたはビジネス・サービスは、RMアサーションを使用するWS-Policyを持つ必要があります。このことは逆に、WSトランスポート以外のトランスポートを使用するサービスではRMアサーションを使用するWS-Policyを持てないことを示しています。WSトランスポートでは、RMアサーションを使用するWS-PolicyとWSSP v1.2トランスポート・レベル・セキュリティ・アサーションがサポートされます。
ただし、WSSP v1.2メッセージ・レベル・セキュリティ・アサーションと9.X Oracle独自のセキュリティ・アサーションはサポートされません。RMアサーションは、操作レベルや操作のリクエスト/レスポンス・レベルではなく、サービス・レベルでのみバインドされる必要があります。
注意:
WS-Policyで使用するRMアサーションは1つに限られます。
WS-Policyは、次の2つの方法のどちらかを使用して構成できます。
WS-Policyの構成をサービスに関連付けられたWSDLファイルの一部として指定します。WSDLファイルで指定されるポリシーは、WSDLファイルに含まれているか、あるいはWSDLファイルで参照されています。
サービスを構成するときにWS-Policyをサービスに割り当てます。
注意:
サービスにセキュリティ・ポリシーを関連付けるには、この2つの方法のどちらか1つのみを使用できます。Service Busサービスでポリシーを直接構成すると、WSDLファイルで定義されたポリシーは無視されます。
WSトランスポートでは、基礎となるインフラストラクチャ(WLS JAX-RPCスタック)で完全に具体化されたペイロードを使用しているため、サイズの大きいメッセージのストリーミングのサポートがありません。ただし、プロキシ・サービスでサイズの大きいメッセージの処理を構成した場合は、WSトランスポートによってService Busのストリーミングの最適化が使用されて、メッセージはJavaオブジェクトに完全に具体化されます。サイズの大きいメッセージの処理でコンテンツをストリーミングする場合は、プロキシ・サービスの構成中に、メモリーまたはディスクにコンテンツのバッファリングを行うようにします。詳細は、「bodyコンテンツのストリーミング」を参照してください。
WSトランスポートでは、WS-I基本プロファイルによってWebサービスの相互運用性をサポートします。現在、Service Busプロキシ・サービスはWS-I基本プロファイルの制限に従っていません。しかし、このトランスポートを使用するように構成されたすべてのサービスは、WS-I基本プロファイルの仕様に厳密に従っています。WSプロキシ・サービスにはサービスの構成にWS-I準拠のチェックがなく、常にWS-I基本プロファイルに従います。WS-I基本プロファイルはSOAP 1.1にのみ適用されるため、このことはSOAP1.1 WSDLバインディングに対して有効です。
この項では、WSプロキシ・サービスとビジネス・サービスが認証および認可される方法について説明します。
WSプロキシ・サービスでは基本認証とクライアント証明書(双方向SSL)認証の両方をサポートします。WS-Policyで基本認証が指定された場合は、WSプロキシ・サービスに対するすべてのHTTPリクエストには、RMプロトコル・メッセージも含めて、有効なユーザー名とパスワードが含まれている必要があります。
プロキシ・サービス認証のサポートは次のように行われます。
プロキシ・サービスが参照するサービス・キー・プロバイダに割り当てられたSSL鍵ペアを使用したクライアント証明書のアウトバウンド認証。
WSプロキシ・サービス(基本認証を使用する)による他の任意のアウトバウンド・トランスポート、またはアウトバウンドWSSユーザー名トークンに対するユーザー名/パスワードのIDの伝播。
WSプロキシ・サービス(基本認証または双方向SSL認証)と他の任意のトランスポートとの間の資格証明のマッピング。
WSプロキシ・サービスからRMクライアントへのHTTPまたはHTTPSによる非同期レスポンスの送信。プロキシ・サービスとビジネス・サービスで使用されるデフォルトのプロトコルはHTTPです。
WSプロキシ・サービスから、RMクライアントによって指定されるAcksToまたはReplyToエンドポイント参照に接続するRMクライアントへの非同期レスポンス。RMクライアントはHTTP URLまたはHTTPS URLのどちらかを使用できます。RMクライアントがHTTPSを使用する場合、RMクライアントはSSLハンドシェイク中にクライアント証明書をリクエストできます。WSトランスポートでは、リクエスト時にサービス・キー・プロバイダのSSLのキー・ペアを使用します。
管理者は、トランスポート・レベルのアクセス制御ポリシーをWSプロキシ・サービスに割り当てることができます。他のすべてのトランスポートと同様に、このポリシーは、インバウンド・トランスポート・プロバイダがリクエスト・メッセージをService Busバインディング・レイヤーに渡した後、リクエスト・パイプラインを呼び出す前に実施されます。詳細は、「トランスポート・レベルのアクセス・ポリシーの構成方法」を参照してください。
WSビジネス・サービスでは基本認証とクライアント証明書認証をサポートします。アウトバウンド基本認証は、サービス・アカウントによってサポートされます。ユーザー名およびパスワードのIDの伝播と資格証明のマッピングがサービス・アカウントによって提供されます。ただし、静的アカウントも認証に使用されることがあります。サービス・アカウントは、静的、パススルーまたはマップになります。パススルー認証では、クライアント・リクエストからバックエンドRMサービスへユーザー名およびパスワードを渡すことが可能です。マップされたサービス・アカウントでは資格証明のマッピングが可能です。静的サービス・アカウントは、固定した資格証明が必要な場合に使用されます。
WSビジネス・サービスでは、SSLクライアント証明書認証(双方向SSL)もサポートされています。アウトバウンドの双方向SSLで使用されるキー・ペア(秘密鍵と証明書)は、WSビジネス・サービスではなく、プロキシ・サービスによって参照されるサービス・キー・プロバイダで構成されます。
1つのメッセージをWSビジネス・サービスにルーティングすると、Service Busサーバーとバックエンド・サービスからの複数のHTTP/Sリクエストが対象となることがあります。このようなメッセージはすべて、WSビジネス・サービスで構成される認証方法の影響を受けます。つまり、サービスが基本認証用に構成されている場合は、Service Busから送信されるすべてのメッセージに、ユーザー名およびパスワードが格納されたHTTP認可ヘッダーが含まれており、メッセージがクライアント証明書認証用に構成されている場合は、Service Busで鍵ペアを使用してすべてのメッセージの認証を行います。
WSトランスポートは、分散ネットワークにおいて信頼性のあるメッセージ配信を行います。WSRM機能は、SOAP 1.1およびSOAP 1.2に基づくWSRMポリシーを持ったWSDLファイルでのみトランスポートとして使用できます。サービスがRMポリシーを持つSOAP 1.1または1.2 WSDLファイルに関連付けられていること、あるいはRMポリシーがサービスにアタッチされていることを確認してください。WS-PolicyはWSDLファイルで構成するか、またはサービスに割り当てることができます。詳細は、「WSポリシーの構成」を参照してください。
WSトランスポートを使用するようにプロキシ・サービスおよびビジネス・サービスの構成を始める前に、必要なWSDLファイルが、使用するService Busドメインで利用可能であることを確認します。詳細は、「Oracle Service BusコンソールへのWSDLドキュメントのインポート」、「WSトランスポートを使用するプロキシ・サービスの構成」および「WSトランスポートを使用するビジネス・サービスの構成」を参照してください。
サービスにエラー・キューを構成して、Service Busがエラーになったメッセージをこのキューに配信するようにすることもできます。これは分散キューにできます。このキューは自動的には作成されないので、サービスの構成を始める前に作成しておく必要があります。詳細は、「エラー・キューの構成」を参照してください。
Oracle Service BusコンソールでWSRMポリシーを持つWSDLファイルに基づいてサービスを作成するためには、WSDLファイルをインポートするかまたはエディタでWSDLリソースおよびファイルの内容を作成する必要があります。詳細は、「Oracle Service BusコンソールでのWSDLドキュメントの操作」および「リソースおよび構成のインポートとエクスポート」を参照してください。
WSトランスポートは、WSRMポリシーを持つSOAP WSDLファイルでのみ使用できます。WS-PolicyをWSDLファイルで構成するか、JDeveloperあるいはOracle Service BusコンソールでWS-Policyをサービスに割り当てることができます。詳細は、「WSトランスポートのWS-Policy」を参照してください。
RMポリシー・アサーションがサービスに関連付けられたWSDLファイルで指定されていない場合、セッションをアクティブ化すると検証メッセージが表示されます。この競合を解決するには、WSDLファイルを更新するかまたはサービスにポリシーを付加する必要があります。詳細は、「サービスへのWSポリシーの付加」および「WS-PolicyによるOracle Service Busプロキシ・サービスとビジネス・サービスの保護」を参照してください。
JDeveloperまたはOracle Service Busコンソールのいずれかのサービス定義エディタで、プロキシ・サービスまたはビジネス・サービスにポリシーをアタッチできます。サービスにWS-Policyをアタッチすると、そのサービスに関連付けられたWSDLファイルで定義されるすべてのポリシーは無視されます。ポリシーの付加の詳細は、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。
デフォルトでは、配信されなかったメッセージは指定された回数の再試行を行った後、破棄されます。これらのメッセージを保存するために、ビジネス・サービスのエラー・キューを構成できます。Service Busは、パイプラインで失敗したメッセージをこれらのキューに配信します。エラーにはJMSキューを構成する必要があります。Oracleでは、エラー・キューをリモート・キューではなく、ローカルで構成することをお薦めします。
ビジネス・サービスでは、レスポンスのタイムアウトが発生すると、レスポンス・パイプラインがエラーで呼び出されます。シーケンスの有効期限に達すると、メッセージはビジネス・サービス用に構成されたエラー・キューに置かれ、レスポンス・パイプラインがエラーで呼び出されます。ただし、レスポンスのタイムアウトがすでに発生していた場合は、メッセージはエラー・キューに置かれますが、レスポンス・パイプラインは呼び出されません。
注意:
一方向サービスおよびリクエスト/レスポンス・サービスではどちらも、エラーになったメッセージをエラー・キューに入れる処理は「そうするように最善を尽くす」に過ぎません。
HTTPプロキシ・サーバーが構成されている場合、WSビジネス・サービスはHTTPプロキシ・サーバーを使用してアウトバウンド・メッセージを送信します。クライアント・アプリケーションでHTTPプロキシ・サーバーの詳細を指定する方法の詳細は、Oracle WebLogic Server JAX-RPC Webサービスの開発の「Webサービスの呼出し」にあるWebサービス呼出し時のプロキシ・サーバーの使用に関する項を参照してください。
アプリケーション・エラーを処理するようにWSトランスポートベースのビジネス・サービスを構成できます。これには、アプリケーション・エラーの発生時にビジネス・サービスのエンドポイントURIを再試行するかどうかを指定します。アプリケーション・エラーは、WSベースのビジネス・サービスでSOAPフォルトがレスポンスとして受信され、BEA-380001またはOSB-380001エラー・コードが生成されると発生します。
ビジネス・サービスに対する要求で応答またはシーケンスのタイム・アウトが発生した場合、Service Busサーバーは、ロード・バランシング・アルゴリズムに基づいてその次のURIにメッセージの送信を試行します。この動作は「アプリケーション・エラーの再試行」オプションに依存しません。
Service Busドメインにリソースが存在する場合、「セキュリティおよびポリシーの構成を保持」オプションを選択することで、リソースをService Busにインポートするときにセキュリティおよびポリシーの構成の詳細を保持できます。このオプションを選択すると、リソース内でセキュリティとポリシーについての構成が更新されている場合であっても、インポート時に既存のリソースの値が保持されます。
リソースのインポートの詳細は、「リソースおよび構成のインポートとエクスポート」を参照してください。
プロキシ・サービスがUDDIレジストリにパブリッシュされると、サービスはWSDLファイルを使用するWSビジネス・サービスに変換されます。認証の構成がある場合は、これもUDDIにエクスポートされます。
WSRMポリシーを使用するWSDLベースのビジネス・サービスがUDDIレジストリからService Busにインポートされる場合は、サービスは自動的にWSトランスポートを使用するように構成されたWSビジネス・サービスとしてインポートされます。詳細は、「WSトランスポートのWS-Policy」を参照してください。
詳細は、「UDDIレジストリの操作」を参照してください。
ここでは、WSトランスポートのエンドポイントURLの形式と構成オプションを説明します。
WSトランスポートを使用するプロキシ・サービスのエンドポイント構成は、HTTPプロキシ・サービスの構成と同様です。次の形式でURIを指定し、HTTPトランスポートまたはWSトランスポートのどちらかを使用するプロキシ・サービスに対して、コンテキスト・パスが一意であることを確認します。
/contextPath
WSトランスポートを使用するビジネス・サービスのエンドポイント構成は、HTTPの構成と同様です。次の形式のいずれかでURIを指定します。
http://host:port number/name https://host:port number/name
WSトランスポートを使用するビジネス・サービスは、RMアサーションを持つWS-Policyと関連付けられている必要があります。詳細は、「WSトランスポートのWS-Policy」を参照してください。ビジネス・サービスは、外部の信頼性のあるWebサービスを呼び出すクライアントとして動作します。ビジネス・サービスによってサービスにリクエストが送信され、Service Busによってデプロイされたアプリケーションでレスポンスを受信します。これによりレスポンス・パスが呼び出されます。
次の表に、WSベースのビジネス・サービスを構成するために使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。
表38-1 ビジネス・サービスのWSトランスポート・プロパティ
| プロパティ | 説明 |
|---|---|
レスポンス・タイムアウト |
タイム・アウトまで応答を待つ時間(秒)を入力します。このフィールドを指定しない場合、レスポンスのタイムアウトは発生しません。ビジネス・サービスは、RMポリシーで構成されたシーケンス・タイムアウトの期間待機します。リクエストの送信後、定義された間隔以内にレスポンスが返されない場合、サービスがタイムアウトしたというエラーでレスポンス・パイプラインが呼び出されます。 値ゼロ( |
サービス・アカウント |
このサービスにHTTP基本認証ポリシーがある場合に使用する資格証明を定義するサービス・アカウントを指定します。 詳細は、「サービス・アカウントの操作」を参照してください。 注意: これは基本認証を必要とするWS-PolicyがWSビジネス・サービスにある場合にのみ適用されます。 |
エラー・メッセージをキューに入れる |
このチェック・ボックスを選択して、構成されたエラー・キューにエラー・メッセージを送信することを指定します。 |
エラー・キューURI |
エラー・メッセージを格納するJMSキューのURIを次の形式で入力します。 jms://host:port/connFactoryJndiName/queueJndiName このオプションは、「エラー・メッセージをキューに入れる」チェック・ボックスが選択されている場合のみ有効です。 注意: WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。 |
JMSエラー・キューのサービス・アカウント |
JNDI参照およびエラー・キューへのエラー・メッセージ送信用に使用する資格証明を定義するサービス・アカウントを指定します。このオプションは、「エラー・メッセージをキューに入れる」チェック・ボックスが選択されている場合のみ有効です。 詳細は、Oracle Service Busによるサービスの開発のサービス・アカウントの操作方法に関する項を参照してください。 |
エラー・キューにSSLを使用 |
エラー・キューへの接続にSSLを使用する場合に選択します。 このオプションは、「エラー・メッセージをキューに入れる」チェック・ボックスが選択されている場合のみ有効です。 |
Send Error Message as Binary |
このオプションを選択して、エラー・メッセージを |
WSトランスポートを使用してビジネス・サービスを構成する方法の詳細は、Service Busのオンライン・ヘルプを参照してください。
WSトランスポートを使用するプロキシ・サービスは、RMアサーションを持つWS-Policyと関連付けられている必要があります。詳細は、「WSトランスポートのWS-Policy」を参照してください。
プロキシ・サービスでは、クライアントからリクエストを受信し、WSRMに関連する処理を行った後で、これをパイプラインに渡します。プロキシ・サービスでは、レスポンス・パイプラインからレスポンスを受信した後、これをクライアントに送信することもできます。WSトランスポートを使用するプロキシ・サービスは他の任意のプロキシ・サービスから呼び出すことが可能で、外部クライアントから呼び出されたときと同じ動作を行います。HTTPプロキシ・サーバーが構成されている場合、WSプロキシ・サービスはHTTPプロキシ・サーバーを使用して非同期メッセージを送信します。
SOAP 1.2バインディングのWSDLに基づくプロキシ・サービスではSOAP 1.2メッセージのみをサポートしており、SOAP 1.1メッセージによるバージョンの不一致エラーが発生すると、エラーがスローされます。同様に、SOAP 1.1バインディングのWSDLに基づくプロキシ・サービスではSOAP 1.1メッセージのみをサポートしており、SOAP 1.2メッセージによるバージョンの不一致エラーが発生すると、エラーがスローされます。
次の表に、WSベースのプロキシ・サービスを構成するために使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。
表38-2 プロキシ・サービスのWSトランスポート・プロパティ
| プロパティ | 説明 |
|---|---|
ディスパッチ・ポリシー |
このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。 ワーク・マネージャの詳細は、次の説明を参照してください。
|
再試行回数 |
WSRMレイヤーがService Busメッセージ・フローへのメッセージ配信を試行する回数を指定します。デフォルトは3です。 プロキシのリクエスト・フローで未処理の例外が発生した場合、着信WSトランスポート・メッセージはこの値で指定される回数までメッセージ・フローに再配信されます。これはWSトランスポート・メッセージを確実に処理するために重要です。 注意: メッセージの配信が失敗すると、現在のトランザクションはロール・バックされますが、メッセージはキューから削除されません。サーバーはメッセージの配信に成功するまで、または再試行回数の制限に到達するまでメッセージの送信を試行します。再試行回数の制限に到達すると、メッセージはキューから削除されるか、またはエラー・キューに移されます。エラー・キューは分散キューにすることができ、Oracle WebLogic Server管理コンソールで作成することができます。詳細は、「エラー・キューの構成」を参照してください。 |
再試行の遅延 |
サーバーがメッセージ配信を再試行する前に待機する時間(秒)を指定します。デフォルトは5秒です。 |
WSトランスポートを使用してプロキシ・サービスを構成する方法の詳細は、Service Busのオンライン・ヘルプを参照してください。
