| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.1.3) E53004-06 |
|
 前 |
 次 |
この章では、ローカル・トランスポートの概要と、プロキシ・サービスでの使用および構成方法について説明します。
この章の内容は次のとおりです。
Service Busプロジェクトでは、プロキシ・サービス・ロジックはクライアントに公開されますが、ロジックの公開を望まない場合があります。この場合、ローカル・トランスポート・プロキシ・サービスの後方にロジックを設計して、他のService Busプロジェクトからそのプロキシ・サービスを呼び出すことができます。たとえば、バックエンド・サービスを呼び出すサービスがいくつかある場合、ローカル・プロキシ・サービスを含む個別のプロジェクトを作成して、すべてのバックエンド(未公開)・ロジックを定義できます。特定の処理ロジックをすべてのクライアントに対して非公開にしながら、他のService Busプロジェクトからそのローカル・プロキシ・サービスを呼び出すことができます。
ローカル・プロキシ・サービスは、他のプロジェクトに含まれるパイプラインをコールする唯一の方法でもあります。すべてのパイプラインが同じService Busプロジェクトに含まれている場合、1つのパイプラインから別のパイプラインを直接コールできます。ただし、1つのパイプラインから異なるプロジェクト内のパイプラインを直接コールすることはできません。これを行うには、パイプライン間でローカル・プロキシ・サービスを使用する必要があります。ローカル・トランスポートには次の機能があります。
効率的でセキュアな通信。
トランザクションとトランザクション動作の伝播。
IDをエンド・ツー・エンドで伝播できるようなセキュリティ・コンテキストの伝播。また、セキュリティ・コンテキストの伝播により、サービスのチェーンに含まれる最初のプロキシ・サービスのクライアントを、チェーン内で以降に呼び出されるプロキシ・サービスが認可できるようになり、詳細なアクセス制御がサポートされます。
ローカル・トランスポート・ベースのプロキシ・サービスは、その他のプロキシ・サービスまたはパイプラインからのみ呼び出すことができ、その他のクライアントからは呼び出せません。呼出しはService Busによって最適化されます。ローカル・プロキシ・サービスにURIはありませんが、ローカル・トランスポート・プロキシ・サービスによってサポートされるサービスとインタフェースのタイプには制約はありません。1つの例外は、SAMLがパス・スルー・シナリオでのみサポートされることです。
呼出しを行うサービスのサービス品質(QoS)がExactly Onceに定義されている場合、そのサービスのトランザクションは、ローカル・トランスポート・プロキシ・サービスに伝播されます。つまり、呼び出されたローカル・トランスポート・プロキシ・サービスは呼出しを行ったサービスのトランザクション動作を継承します。
プロキシ・サービスはトランスポート・レベルまたはメッセージ・レベルで認証を行うことができます。メッセージ・レベルが有効な場合は、メッセージ・レベルで認証されたクライアントが有効になります。メッセージ・レベルで認証されたクライアントが有効でない場合は、トランスポート・レベルで認証されたクライアントが有効になります(トランスポート・レベルが有効な場合)。メッセージ・レベルおよびトランスポート・レベルで認証されたクライアントのいずれも有効になっていない場合、匿名のクライアントが有効なクライアントになります。
プロキシ・サービスがローカル・トランスポート・プロキシ・サービスを呼び出す場合、呼出しを行うサービスの有効なクライアントが、呼び出されるローカル・プロキシ・サービスのトランスポート・レベルのクライアントになります。ローカル・トランスポート・プロキシ・サービスでは、アクセス制御ポリシーを使用して、このクライアントにアクセスを認可できます。この方法により、エンド・ツー・エンドのメッセージ・フロー全体で、最初のサービスのクライアントを、後続のすべてのプロキシ・サービスに伝播できます。
ローカル・トランスポート・プロキシ・サービスは、ユーザー定義のトランスポート・ヘッダーをサポートします。プロキシ・サービスでHTTPトランスポートを使用するシナリオを想定してください。パイプラインを介してローカル・プロキシ・サービスへのルーティングが実行され、そのパイプラインはトランスポート・ヘッダー・アクションを使用して、ヘッダーをローカル・プロキシ・サービスに渡します。このシナリオでは、HTTPプロキシ・サービスがContent-Typeヘッダーを受け取った場合、このヘッダーをユーザー・ヘッダーとしてローカル・トランスポートで使用できるため、型付きのトランスポート・ヘッダーとしてではなく、標準のユーザー・ヘッダーを使用してアクセスできます。
ローカル・トランスポート・プロキシ・サービスは、メッセージ・フローの一部を非公開のままにし、その他の部分を公開する場合に役立ちます。たとえば、バックエンド処理を定義するプロジェクトがあり、それらのプロジェクトを、アラートやフォルト処理などのフロントエンド・ロジックを定義するプロジェクトからコールする場合があります。バックエンド・プロジェクトのローカル・プロキシ・サービスを使用すると、これらは非公開のままになります。
フロントエンド・プロジェクト内のパイプラインは、メッセージをローカル・トランスポート・プロキシ・サービスにルーティングします。複数のパイプラインや複数のプロジェクトから、同じローカル・プロキシ・サービスをコールできます。次の図に、HTTPプロキシ・サービスを含むプロジェクトと、JMSプロジェクト・サービスを含むプロジェクトによって呼び出されるローカル・プロキシ・サービスを示します。
Service Busの以前のバージョンでは、タイプが任意のSOAPまたは任意のXMLであるプロキシ・サービスが、異なるエンタープライズ・システムに対するフロントエンドとして機能する場合に、ローカル・トランスポートを使用できました。このフロントエンド・プロキシ・サービスは、適切なローカル・トランスポートへの汎用ルーターです。Service Busの現在のバージョンでは、プロキシ・サービスとは別にパイプラインを作成できるため、このようなローカル・トランスポートの使用方法は廃止されました。図32-2および図32-3に示すように、ローカル・プロキシ・サービスをパイプラインに置き換えることができます。
以前のバージョンと同様、動的ルーティングを使用して実行時にルーティング・ルールを抽象化し、メッセージをローカル・トランスポート・プロキシ・サービスにルーティングできます。動的ルーティングの使用例については、「動的ルーティングの使用」を参照してください。
次の図は、リリース11gのこのシナリオで、ローカル・トランスポートがどのように使用されるかを示しています。
現在のリリースでは、前述の11gのシナリオが更新され、次に示すように、パイプラインがローカル・プロキシ・サービスのかわりに使用されます。
ローカル・プロキシ・サービスをチェーンすると、$fault変数のSOAPフォルトは、あるプロキシ・サービスからパイプラインを経由して別のプロキシ・サービスに自動的に伝播されません。次に例を示します。
Client > Proxy1 > Pipeline > Proxy2 > Business Service > Back-end Service
バックエンド・サービスでSOAPフォルトが発生すると、そのフォルトはProxy2の$fault変数に伝播されます。ただし、Proxy2のSOAPフォルトの値は、Proxy1の$fault変数に自動的に伝播されないため、クライアントに戻されません。
SOAPフォルトをあるプロキシから別のプロキシに伝播するには:
$body変数にフォルト情報を格納したSOAPメッセージが戻されます。詳細は、「コンソールでの返信アクションの追加」を参照してください。$body変数を変換します。Service BusによるSOAPフォルトの処理方法の詳細は、「エラー・メッセージの生成、レポート、および返信」を参照してください。
Oracle Web Services Manager (OWSM)のサービス・ポリシーをWSDLサービス・タイプのローカル・プロキシ・サービスにアタッチして、各ローカル・プロキシに着信するメッセージに特定のセキュリティ制御を適用できます。この項では、プロキシ・サービスがセキュリティ・ヘッダーを含むメッセージをローカル・プロキシ・サービスにパイプライン経由で転送する場合に、Service Busが実行時にポリシーを処理する方法について説明します。メッセージ転送は、ルーティング、サービス・コールアウト、パブリッシュなどのアクションを通じて発生します。
プロキシ・サービスは、メッセージを他のプロキシ・サービスに転送する場合に、アウトバウンドWS-Security処理を実行しません。この項の図は、この動作を説明しており、プロキシ間接続の異なるシナリオにおけるWS-Security構成を示しています。他のプロキシ・サービスからメッセージを受信するローカル・プロキシ・サービスで適切にOWSMサービス・ポリシーを使用できるように、これらのシナリオを使用してその動作を理解してください。
図32-4は、次のいずれかの特徴を持つフロントエンド・プロキシにメッセージを送信するクライアント・ポリシーが適用されたクライアントを示しています。
フロント・エンド・プロキシが、アクティブであり、リクエストのすべてのWS-Securityヘッダーまたはそれらのヘッダーのサブセットのみに対してインバウンド処理を実行するOWSMポリシーを含む場合。たとえば、リクエストに認証ヘッダーとメッセージ保護ヘッダーの両方が含まれる場合、認証ポリシーは処理されますが、メッセージ保護ポリシーは処理されません。プロキシには、OWSMログ・ポリシーなどのセキュリティ以外のポリシーも含まれることがあります。
フロント・エンド・ポリシーが、パッシブであり、OWSMポリシーを含む場合。
フロント・エンド・プロキシがOWSMポリシーを含まない場合。
どの場合でも、フロントエンド・プロキシ・サービスは、メッセージ内に少なくとも1つのセキュリティ・ヘッダーを検出します。プロキシ・サービスは、アウトバウンドWS-Security処理を実行せずにこのメッセージをパイプラインに渡し、パイプラインは、メッセージをローカル・プロキシ・サービスに渡します。ローカル・プロキシ・サービスは、OWSMポリシーを含む場合と含まない場合があります。
図32-4では、予期されるセキュリティ・ヘッダーがメッセージに含まれるため、ローカル・プロキシ・サービス2は例外をスローせずにメッセージを受信します。セキュリティ処理を部分的に実行するポリシーをフロントエンド・プロキシ・サービスが含む場合でも(認証処理は行うがメッセージ保護処理は行わないなど)、転送されたメッセージには引き続きセキュリティ・ヘッダーが含まれます。
図32-5は、フロントエンド・プロキシ・サービスにメッセージを送信するクライアント・ポリシーが適用されたクライアントを示しています。フロントエンド・プロキシ・サービスは、アクティブであり、メッセージのすべてのWS-Securityヘッダーを処理するOWSMサービス・ポリシーを含みます。インバウンド・サービス・ポリシーが処理され、そのセキュリティ・ヘッダーのメッセージが削除されます。フロントエンド・プロキシ・サービスは、他のプロキシにメッセージを転送するため、アウトバウンドWS-Security処理は実行されず、セキュリティ・ヘッダーのないメッセージがローカル・プロキシ・サービスに転送されます。一方のローカル・プロキシ・サービスには、セキュリティ・ヘッダーを予期しているOWSMサービス・ポリシーが含まれており、セキュリティ・ヘッダーのないメッセージが到着すると例外がスローされます。他方のローカル・プロキシには、セキュリティ・ポリシーではなく施行の発生しないOWSMポリシーが含まれているため、セキュリティ・ヘッダーのないメッセージは正常にパススルーされます。
図32-5 ローカル・プロキシへの転送前にすべてのセキュリティ・ヘッダーを処理するフロント・エンド・プロキシ
