この章では、Oracle Service Busのローカル・トランスポートについて説明します。内容は以下のとおりです。
通常、サービス・バス・アーキテクチャには、複雑なメッセージ・フローが含まれています。そのメッセージ・フローでは、メッセージは、より大きな複数のプロキシ・サービス・フローにまとめられる複数のプロキシ・サービスにルーティングされています。これらの複数のプロキシ・サービスのシナリオにおける個々のプロキシ・サービスは、フローの次のプロキシ・サービスにルーティング、パブリッシュ、またはコールアウトされます。
複数のプロキシ・サービスを設計する理由は、エンド・ツー・エンドのメッセージ・フローの様々なコンポーネントのモジュール性と区分化をサポートするためです。
複数のプロキシ・サービス・フローにおける個々のプロキシ・サービスには以下が必要です。
効率的で安全に通信します。
トランザクションとトランザクション動作の伝播を許可します。
IDがエンド・ツー・エンドで伝播されるように、セキュリティ・コンテキストが伝播されることを許可します。また、セキュリティ・コンテキストの伝播により、複数サービス・フロー内の最初のプロキシ・サービスのクライアントを、フロー内で以降に呼び出されるプロキシ・サービスが認可できるようになります。このため、ローカル・トランスポートでの詳細なアクセス制御汎用ヘッダーがサポートされます。
プロキシ・サービスでローカル・トランスポートを使用することで、これらの機能のサポートが保証されます。
ローカル・トランスポート・ベースのプロキシ・サービスは、その他のプロキシ・サービスからのみ呼び出すことができ、その他のクライアントからは呼び出せません。呼出しはOracle Service Busによって最適化されます。ローカル・プロキシ・サービスはURIを持ちません。ただし、ローカル・トランスポート・プロキシ・サービスによってサポートされるサービスとインタフェースのタイプには制約はありません。1つの例外は、SAMLがパス・スルー・シナリオでのみサポートされることです。
呼出しを行うプロキシ・サービスのサービス品質(QoS)がExactly Onceに定義されている場合、そのサービスのトランザクションは、ローカル・トランスポート・プロキシ・サービスに伝播されます。
つまり、呼び出されたローカル・トランスポート・プロキシ・サービスは呼出しを行ったプロキシ・サービスのトランザクション動作を継承します。プロキシ・サービスはトランスポート・レベルまたはメッセージ・レベルで認証を行うことができます。メッセージ・レベルが有効な場合は、メッセージ・レベルで認証されたクライアントが有効になります。メッセージ・レベルで認証されたクライアントが有効でない場合は、トランスポート・レベルで認証されたクライアントが有効になります(トランスポート・レベルが有効な場合)。メッセージ・レベルおよびトランスポート・レベルで認証されたクライアントのいずれも有効になっていない場合、匿名のクライアントが有効なクライアントになります。
プロキシ・サービスがローカル・トランスポート・プロキシ・サービスを呼び出す場合、呼出しを行うプロキシ・サービスの有効なクライアントが、呼び出されるローカル・プロキシ・サービスのトランスポート・レベルのクライアントになります。ローカル・トランスポート・プロキシ・サービスでは、アクセス制御ポリシーを使用して、このクライアントにアクセスを認可できます。この方法により、エンド・ツー・エンドのメッセージ・フロー全体で、最初のプロキシ・サービスのクライアントを、後続のすべてのプロキシ・サービスに伝播できます。
ローカル・トランスポート・プロキシ・サービスは、ユーザー定義のトランスポート・ヘッダーをサポートします。プロキシ・サービスでHTTPトランスポートを使用するシナリオを想定してください。HTTPトランスポートにより、ローカル・プロキシ・サービスにルーティングし、HTTPプロキシ・サービスはトランスポート・ヘッダー・アクションを使用して、ヘッダーをローカル・プロキシ・サービスに渡します。このシナリオでは、HTTPプロキシ・サービスがContent-Typeヘッダーを受け取った場合、このヘッダーをユーザー・ヘッダーとしてローカル・トランスポートで使用できるため、型付きのトランスポート・ヘッダーとしてではなく、標準のユーザー・ヘッダーを使用してアクセスできます。
Oracle Service Busのテスト・ブラウザからローカル・トランスポート・プロキシ・サービスを呼び出すことができます。その他のすべてのサービスと同様に、ローカル・トランスポート・プロキシ・サービス用にメトリックが収集されます。
ローカル・トランスポート・プロキシ・サービスのメッセージ処理のオプションを指定できます。
具体的には、該当する場合に、ローカル・トランスポート・プロキシ・サービスがMTOM/XOP形式でインバウンド・メッセージをデコードおよび解析し、MTOM/XOP形式を使用してレスポンスを送信できます。SOAP Message Transmission Optimization Mechanism (MTOM)は、バイナリ・データをWebサービスとの間で送受信する方法です。MTOMでは、XML-binary Optimized Packaging (XOP)を使用してバイナリ・データを転送します。
同様に、ローカル・トランスポート・プロキシ・サービスがHTTPトランスポート・プロキシ・サービスを通じてチェーンされている場合、ローカル・トランスポート・プロキシ・サービスは添付ファイルをディスクにページし、(添付ファイルのコンテンツをメモリーにバッファリングせずに)ストリーミング形式で処理するかどうかの設定を継承します。
つまり、もし外部のHTTPトランスポート・プロキシ・サービスが添付ファイルをディスクにページするように構成されている場合、チェーンされたローカル・トランスポート・プロキシ・サービスもこの形式で添付ファイルを処理します。これにより、プロキシ・サービスで、大きな添付ファイルを堅牢かつ効率的に処理できます。
プロキシ・サービスのメッセージ処理の構成の詳細は、4.3.4項「プロキシ・サービスの「メッセージ処理構成」ページ」を参照してください。
ローカル・トランスポート・プロキシ・サービスを使用してサポートされる一般的なシナリオは、プロキシ・サービスを異なるトランスポートを使用して呼び出す必要があるシナリオです。これは、メッセージ・フローのパスで、フロント・エンド・プロキシ・サービス(トランスポートごとに1つのサービス)のセットをローカル・トランスポート・プロキシ・サービスの前に置くことによって実現されます。
これらのフロント・エンド・プロキシ・サービスは、メッセージをローカル・トランスポート・プロキシ・サービスにルーティングするだけです。次の図は、このシナリオについて説明しています。
もう1つの一般的なシナリオは、プロキシ・サービスのタイプが任意のSOAPまたは任意のXMLである場合に、プロキシ・サービスが、異なるエンタープライズ・システムに対するフロント・エンドとして機能するシナリオです。このフロント・エンド・プロキシ・サービスでは、様々なフォーマットでメッセージを受信し、受信したすべてのメッセージに共通の方法(WS-Addressing SOAPヘッダーなど)を使用して、メッセージを適切なローカル・トランスポート・プロキシ・サービスにルーティングできます。
このシナリオでは、フロント・エンド・プロキシ・サービスは、エンタープライズ・システムまたはメッセージ・フォーマットとセマンティクスの情報をほとんど持たない汎用ルーターとして機能します。設計時にルーティング・ルールの情報をさらに抽象化するために、フロント・エンド・プロキシ・サービスは、動的なルーティングを使用してメッセージをローカル・トランスポート・プロキシ・サービスにルーティングできます。動的なルーティングがプロキシ・サービスでどのように使用されるかを示す例は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の動的ルーティングの使用に関する項を参照してください。
フロント・エンド・サービスからメッセージをルーティングされた各ローカル・トランスポート・プロキシ・サービスは、今度は、特定のビジネス・サービスのフロント・エンド・プロキシ・サービスとして機能します。ローカル・トランスポート・プロキシ・サービスは、ルーティングするビジネス・サービスで必要なメッセージ・フォーマットを認識しています。
このシナリオでは、これらのローカル・トランスポート・プロキシ・サービスは、機能上のプロキシ・サービスとして動作します。機能上のプロキシ・サービスの役割は、特定のビジネス・サービスの呼出しにアクセス制御を適用したり、対象ビジネス・サービスを適切に呼び出すために必要なメッセージのトランスフォーメーションを実行したりすることです。次の図は、このシナリオについて説明しています。
ローカル・トランスポートの制限は以下のとおりです。
ローカル・トランスポートを使用してプロキシ・サービスを呼び出せるのは、別のプロキシ・サービスからのみです。
ローカル・トランスポートを使用するプロキシ・サービスはUDDIにはパブリッシュできません。
ローカル・トランスポート・プロキシ・サービスは、インバウンドWS-Security SAMLトークンを処理できません。