| Oracle® Fusion Middleware Oracle Service Bus開発者ガイド 11gリリース1 (11.1.1.6.2) B61435-05 |
|
 前 |
 次 |
この章では、Oracle Service Bus (OSB)で使用するカスタム・トランスポート・プロバイダを開発する際の概念、機能および設計上の考慮事項について説明します。
開発作業を綿密に計画すると、カスタム・トランスポート・プロバイダの開発に要する時間と労力を大幅に削減できます。
この章の内容は以下のとおりです。
トランスポート・プロバイダは、トランスポートSDKのインタフェースを実装し、Oracle Service Busとメッセージを送受信するメカニズムとの橋渡しをします。このようなメカニズムには、HTTPなどの特定の転送プロトコルだけでなく、ファイルや電子メール・メッセージなど、他のエンティティが含まれる場合もあります。トランスポート・プロバイダは、トランスポート・エンドポイントのライフ・サイクルおよび実行時の動作を管理します。エンドポイントは、メッセージの送信元または送信先となるリソースです。
図38-1は、Oracle Service Busを介した基本的なメッセージの流れを示したものです。クライアントは、特定の転送プロトコルを使用してOracle Service Busにメッセージを送信します。トランスポート・プロバイダは、インバウンド・メッセージを処理します。サービス・クライアント・エンドポイントとの通信を処理し、Oracle Service Busへのメッセージのエントリ・ポイントとして機能します。
図38-1にはバインディング・レイヤーも示されています。これは、メッセージのパックおよびアンパック、メッセージのセキュリティ処理を行い、Oracle Service Busパイプラインにメッセージを渡します。
|
ヒント: Oracle Service Busのメッセージ・ブローカリングおよびトランスポート・レイヤーの役割の詳細は、『Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ』を参照してください。Oracle Service Busを介したメッセージ・フローについてのより詳細なシーケンス・ダイアグラムは、付録A「トランスポートSDKのUMLシーケンス・ダイアグラム」を参照してください。 |
デフォルトでは、Oracle Service Busには、HTTP、JMS、ファイル、FTPなど、一般的に使用されている複数の転送プロトコルをサポートするトランスポート・プロバイダが用意されています。これらのネイティブなプロバイダを使用して、前述の一般的な転送プロトコルを必要とするプロキシ・サービスおよびビジネス・サービスを構成できます。
この項では、トランスポートSDKの用途および機能について簡単に説明します。この項には次のトピックが含まれます:
Oracle Service Busのメッセージ処理は、メッセージの送受信方法とは関係なく行われます。トランスポートSDKは、Oracle Service Busと、Oracle Service Busで送受信されるデータ・フローを扱うコンポーネントの間に抽象化レイヤーを提供します。この抽象化レイヤーがあることで、一意の転送プロトコルを扱うための新しいトランスポート・プロバイダを開発できます。
SDKは、Oracle Service Busの他の部分から以下を抽象化します。
特定のトランスポート・バインディングの処理
サービス・エンドポイントのトランスポート・バインディングへのデプロイ。エンドポイントではメッセージの送信も受信も行うことができます。
モニター情報の収集
エンドポイントの管理(中断または再開操作の実行、および接続プロパティの設定など)
サービス・レベル・アグリーメント(SLA)動作の適用(接続のタイムアウトなど)
この項では、トランスポートSDKの主要な機能について説明します。
トランスポートSDKを使用して開発されたトランスポート・プロバイダは、以下のようにインバウンド・メッセージおよびアウトバウンド・メッセージを処理します。
通常、インバウンド・メッセージは、HTTPクライアントなどの外部ソースからOracle Service Busに送信されます。ペイロードおよびトランスポート・レベル・ヘッダーがある場合、トランスポートSDKは、それらを汎用的なデータ構造にパッケージ化します。その後、トランスポートSDKは、汎用フォーマットでOracle Service Busパイプラインにメッセージを渡します。
アウトバウンド・メッセージは、Oracle Service Busのビジネス・サービスから発信され、WebサービスまたはJMSキューなどの外部で管理されているエンドポイントに送信されます。トランスポートSDKは、Oracle Service Busパイプラインから汎用的なデータ構造を受け取り、対応するトランスポート固有のヘッダーおよびペイロードに変換し、外部システムに送信します。
トランスポートSDKは、アウトバウンド・メッセージおよびインバウンド・メッセージを個別に処理します。インバウンド・メッセージを1つの転送プロトコルにバインドし、アウトバウンド・エンドポイントで異なる転送プロトコルにバインドすることもできます。
一部のトランスポートでは、アーティファクトをOracle WebLogic Serverにデプロイする必要があります。たとえば、JMSプロキシは、メッセージドリブンBeanとして実装されます。このアーティファクト、EARファイルは、新しいJMSプロキシを登録する際にデプロイする必要があります。同様に、EJBトランスポート・プロバイダではEARファイルを使用しますが、これは新しいEJBビジネス・サービスを登録する際にデプロイする必要があります。サービス登録の一環としてキューおよびトピックを作成することがあるJMSトランスポートなどのように、その他のタイプのアーティファクトのデプロイが必要になる場合があります。SDKにより、これらのアーティファクトをサポートし、WLSのデプロイメント・サイクルに参加できます。これらのアーティファクト・ファイルのいずれかのデプロイメントが失敗した場合、Oracle Service Busのセッションに通知され、デプロイメントはキャンセルされます。SDKのこの機能により、サービスを最小単位で作成できます。失敗が発生した場合、セッションは以前の状態に戻ります。
|
注意: WLSのデプロイメント・サイクルに参加するには、トランスポート・プロバイダがTransportWLSArtifactDeployerインタフェースを実装している必要があります。この方法の第一の利点は、最小単位でOracle WebLogic Serverをデプロイできる点であり、必要に応じてロールバックすることもできます。このインタフェースの詳細は、41.3.2項「汎用インタフェースの概要」および39.11項「TransportWLSArtifactDeployerの実装が適している場合」を参照してください。 |
メッセージを処理する際、サーバーで動作するスレッド数には限りがあるため、非同期的に行うことが重要です。この機能により、多数のメッセージを処理できるようにOracle Service Busを拡張できます。リクエストが処理されると、スレッドは解放されます。ビジネス・サービスがレスポンスを受信すると(または、一方向の場合はリクエストを処理し終えると)、コールバックによってOracle Service Busに非同期的に通知します。
38.5.2項「同期トランザクションのサポート」および38.7項「スレッディング・モデル」も参照してください。
トランスポートSDKを使用して、インバウンド・プロパティのモードおよびアウトバウンド・プロパティのモードを実装できます。これらの接続モードおよびエンドポイント・モードは、トランスポート・プロバイダのXMLスキーマ定義ファイルで指定します。このファイルの詳細は、39.3.3項「3.トランスポート固有のアーティファクトのXMLスキーマ・ファイルの作成」を参照してください。このスキーマは、Oracle Service Busパイプラインでフィルタ処理およびルーティングを行う際に使用できます。
この項では、トランスポート・マネージャによって提供される関連機能について示します。トランスポート・マネージャは、様々なトランスポート・プロバイダの管理、エンドポイントの登録、制御、インバウンド・メッセージとアウトバウンド・メッセージの処理、およびその他の機能を一元化するための主要ポイントとなります。これらの機能は、トランスポート・プロバイダによる特定のサポートを必要としません。
トランスポートSDKは、アウトバウンド・メッセージのロード・バランシングおよびフェイルオーバーをサポートします。サポートされているロード・バランシングのオプションは以下のとおりです。
なし - アウトバウンド・リクエストごとに、トランスポート・プロバイダが、URIが記載されているリストを巡回し、送信が成功するまで、各URIにメッセージの送信を試みます。
ラウンド・ロビン - 「なし」と似ていますが、トランスポート・プロバイダは最後に試行されたURIを追跡します。メッセージが送信されるたびに、プロバイダはリストの最後の位置から開始します。
ランダム - トランスポート・プロバイダは、URIが記載されているリストからランダムに試行します。
ランダムな重みベース - 各URIは、任意の重みに関連付けられます。アルゴリズムを使用して、この重みに基づいてURIを選択します。
この項では、カスタム・トランスポート・プロバイダの記述が必要となる基本的な使用例について説明します。別の方法を選択した方が適切な場合もあります。この項には次のトピックが含まれます:
トランスポートSDKの主要な使用例の1つは、既に内部アプリケーション間の通信に使用している特別なトランスポートをサポートすることです。このようなトランスポートでは、セット・アップされたハンドシェイク、ヘッダー・フィールド、メタデータ、またはトランスポート・レベルのセキュリティに独自の概念が用いられている場合があります。トランスポートSDKを使用して、個々のエンドポイントや、インバウンドおよびアウトバウンドのいずれか、または両方の構成を可能にする、Oracle Service Busのトランスポートの実装を作成できます。カスタム・トランスポートを実装することで、特別なトランスポートのメタデータおよびヘッダー・フィールドをプロキシ・サービス・パイプラインで使用できるコンテキスト変数にマッピングできます。
信頼性、セキュリティ、パフォーマンス、管理、ユーザー・インタフェースおよびUDDIレジストリの使用のために、トランスポート・プロバイダをOracle Service Busのあらゆる側面にシームレスに統合する必要がある場合は、トランスポートSDKを使用してください。
トランスポートSDKを使用してカスタム・トランスポートを開発した方が良い場合の例を以下に示します。
カスタム・インタフェースを必要とし、組織の既存のアプリケーションをサポートする、独自開発のトランスポートを使用している場合。
CORBAアプリケーションとの通信にCORBAまたはIIOPプロトコルを使用している場合。
IMSおよびMainframeなど、その他のレガシー・システムを使用している場合。
SFTP (Secure FTP)やIBMのネイティブWebSphere MQ API (WebSphere MQ JMSのかわりとして)などの、既存のトランスポートのバリエーションを使用している場合。
LLP、AS3、およびACCORDなどの業界固有のトランスポートを使用している場合。
TEXTメッセージまたはXMLメッセージで生ソケットを使用している可能性がある場合。このタイプのトランスポートの実装のサンプルについては、第42章「サンプル・ソケット・トランスポート・プロバイダ」を参照してください。
また、トランスポートSDKを使用して、Oracle Service Busで提供される既存のトランスポートの1つで特別なプロトコルをサポートできます。この例には、以下のサポートが含まれます。
HTTPを介した、解析済またはバイナリのXMLで構成されたメッセージ。
HTTPを介したWS-RMまたは新しいWebサービス標準。
JMSを介したリクエスト/レスポンス・メッセージ。ただし、Oracle Service BusのJMSトランスポートでサポートされている2つのパターンのいずれとも異なるレスポンス・パターンを持つもの(たとえば、メッセージ・コンテキストで定義されているレスポンス・キューなど)。
トランスポートSDKを使用して新しいOracle Service Busトランスポート・プロバイダを作成する場合、多大な労力が必要となることがあります。トランスポートSDKは、カスタム・トランスポートが、Oracle Service Busにネイティブに付属するトランスポートの利便性と機能をすべて活用できるようにするために、多彩な機能をすべて備えた環境を提供します。ただし、このような多彩な機能を持ったカスタム・トランスポートは複雑になります。場合によっては、より簡単な別の方法を検討することをお薦めします。
既存のプロトコルを介して送受信される、異なるフォーマットのメッセージをサポートするためだけに拡張機能が必要な場合は、既存のトランスポートおよびJavaコールアウトを使用してメッセージを変換できる場合があります。たとえば、標準のJMSプロトコルを介して送信される(ASN.1またはシリアライズされたJavaオブジェクトなどの)特別なバイナリ・フォーマットを使用しているとします。この場合、サービスのタイプがバイナリの入出力メッセージを使用するメッセージング・サービスである、標準のJMSトランスポートを使用したサービスを定義することも検討できます。次に、パイプラインでメッセージ・コンテンツが必要な場合は、Javaコールアウト・アクションを使用してメッセージをXMLに変換したりXMLから変換したりできます。Javaコールアウトの使用の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJavaコールアウトおよびPOJOを使用するExtensibilityに関する項を参照してください。
トランスポートSDKを使用してカスタム・トランスポートを開発することが最適とは言えないその他の例を以下に示します。
既存のOracleソリューション(Oracle WebLogic Server、Oracle WebLogic Integration、Oracle Data Service Integrator、Oracle Business Process Management、Oracle Tuxedo、Oracle WebLogic Portalなど)をOracle Service Busと組み合せることにより、トランスポートの要件を満たします。
Eclipseなどのサービス有効化ツールを使用することによって、SOA方式を実装するためのより簡略な標準ベースのメカニズムが提供される場合。
(Oracle Service Busで動作確認されている)別の接続ソリューションでも要件に対応できる場合。例: iWayアダプタおよびCycloneのB2B。
ある種の簡単なJava機能を抽象化する手段として、EJBを代用できる場合。
この項では、トランスポート・プロバイダの実行時および設計時のコンポーネントについて説明したUMLダイアグラムを示します。この項には次のトピックが含まれます:
通常、カスタム・トランスポート・プロバイダは設計時部分と実行時部分から構成されています。設計時部分では、トランスポート・プロバイダへのエンドポイントの登録を行います。この構成動作は、UIインタフェースの実装によって実行されます。実行時部分では、メッセージの送受信のメカニズムを実装します。
新しいカスタム・トランスポート・プロバイダを開発する場合は、SDKによって提供される多数のインタフェースを実装する必要があります。この項では、SDKの設計時部分および実行時部分の構成をモデル化したUMLダイアグラムを示します。
|
ヒント: Oracle Service Busでは、TransportProviderインタフェースの実装は、転送プロトコル固有の構成プロパティおよび実行時プロパティの集中的な管理ポイントとなります。サポートされているプロトコルごとに、TransportProviderオブジェクトの単一のインスタンスが存在します。たとえば、HTTPトランスポート・プロバイダ、JMSトランスポート・プロバイダ、およびその他のトランスポート・プロバイダに、それぞれ単一のインスタンスが存在します。 |
詳細は、第39章「トランスポート・プロバイダの開発」で、必要なインタフェースのリストを参照してください。トランスポートSDKによって提供されるインタフェースおよびクラスの概要は、第41章「トランスポートSDKのインタフェースおよびクラス」を参照してください。詳細な説明は、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスにあります。
カスタム・トランスポート・プロバイダの設計時部分はユーザー・インタフェースの構成で成り立っています。この構成は、新しいビジネス・サービスまたはプロキシ・サービスが登録される際に、Oracle Service Bus管理コンソールまたはIDEによって呼び出されます。図38-2に、トランスポート・プロバイダの設計時部分の構造を説明したUMLダイアグラムを示します。ダイアグラムでは次のインタフェースについて説明しています。
TransportManager - トランスポート・プロバイダはこのインタフェースを介してトランスポート・マネージャと通信します。実装は公開されていません。
TransportProvider - サード・パーティはこのインタフェースを実装する必要があります。TransportProviderは、TransportEndpointオブジェクトを追跡します。TransportProviderは、エンドポイントのライフ・サイクルも管理します。たとえば、トランスポート・エンドポイントは中断できますが、これはTransportProviderインタフェースを介して管理されます。
TransportUIBinding - Oracle Service Bus管理コンソールが、トランスポート固有のページを表示できるようにします。
|
注意: 各トランスポート・エンドポイントの構成は、任意のトランスポート・プロバイダのすべてのエンドポイントに対して汎用なプロパティ(URIなど)と、そのプロバイダのエンドポイントだけに固有のプロパティとで構成されます。図38-3は、共有のエンドポイント構成プロパティとトランスポート・プロバイダ固有の構成プロパティの関係を示しています。詳細は38.5.1項「トランスポート・エンドポイントのプロパティの概要」を参照してください。 |
カスタム・トランスポート・プロバイダの実行時部分では、以下を行います。
メッセージを受信し、それらをOracle Service Busランタイムに配信します。
Oracle Service Busランタイムから外部サービスにアウトバウンド・メッセージを配信します。
実行時フレームワークでは、トランスポート・プロバイダは、トランスポート・マネージャを呼び出してインバウンド・メッセージを受信したことを認識します。トランスポート・メッセージ・コンテキストにはインバウンド・メッセージのヘッダーおよび本文が含まれています。アウトバウンド・メッセージの場合、TransportSendListenerおよびTransportSenderがあります。トランスポート・プロバイダは、メッセージからヘッダーおよび本文を取得します。
図38-2に、トランスポート・プロバイダの実行時部分の構造を説明したUMLダイアグラムを示します。
トランスポートSDKを使用して新しいトランスポート・プロバイダを開発する前に、メッセージ・エンドポイントのトランザクション・モデルを検討することが重要です。この項では、Oracle Service Busで使用されるトランザクション・モデル、およびそのモデルがトランスポートSDKにどのように関係するかを説明します。
この項には次のトピックが含まれます:
トランスポート・エンドポイントは、JMSプロキシ・サービスなどのOracle Service Busリソースであり、メッセージの送信元または送信先となります。Oracle Service Busでは、トランスポート・エンドポイントはプロトコル固有のトランスポート・プロバイダによって管理されます。トランスポート・プロバイダは、トランスポート・エンドポイントのライフ・サイクルおよび実行時動作を管理するプラグイン・オブジェクトです。
Oracle Service Busのトランザクション・モデルを理解するには、サービス・トランスポート・エンドポイントのプロパティを確認しておくと役に立ちます。
エンドポイントはトランザクション対応の場合と非対応の場合があります。トランザクション対応のエンドポイントは、メッセージを処理する際に、グローバル・トランザクションのコンテキスト内で開始または追加できます。以下の例では、トランザクションのプロパティがエンドポイントによってどのように異なるかを示します。
XA接続ファクトリを使用するJMSプロキシ・サービスはトランザクション対応のエンドポイントです。メッセージを受信すると、コンテナは、トランザクションのコンテキスト内でメッセージが処理されるように、トランザクションが開始されたことを確認します。
Tuxedoプロキシ・サービスは、トランザクション対応でない場合があります。Tuxedoプロキシ・サービスは、メッセージを受信する前にTuxedoクライアント・アプリケーションによってトランザクションが開始された場合にのみトランザクション対応になります。
HTTPクライアントによって呼び出されるHTTPプロキシ・サービスには通常はトランザクションが関連付けられませんが、トランザクションを開始して、そのトランザクションのコンテキストでメッセージ・フローを実行するというオプションをHTTPプロキシ構成で設定できます。
任意のエンドポイントで、以下のメッセージ・パターンのいずれかを使用できます。
一方向 - レスポンスを受け取りません。一方向のエンドポイントの例としては、レスポンスを受け取らないJMSプロキシ・サービスがあります。
同期 - リクエストまたはレスポンスを意味します。この場合、レスポンス・メッセージとリクエスト・メッセージは暗黙的にペアになります。これは、リクエストが出された時点からレスポンスを受け取るまでの間にトランスポート・チャネルで他のトラフィックが発生し得ないためです。ほとんどの場合、同期メッセージは、アウトバウンド・リクエストの呼出しのブロックを意味します。EJBエンドポイントは同期です。HTTPエンドポイントも同期です(レスポンスを受信するまで新しいリクエストは送信できません)。
非同期 - リクエストおよびレスポンスを意味します。レスポンスは、JMSトランスポートおよびJMSCorrelationIDメッセージ・プロパティによる相関関係などの、トランスポート固有のメカニズムによってリクエストと関連付けられます。たとえば、リクエストおよびレスポンスを持つJMSビジネス・サービス・エンドポイントは非同期です。
すべてのOracle Service Busプロキシ・サービスはトランザクション伝播をサポートします。すなわち、トランザクションが存在していない場合に開始することができます。また、アウトバウンド・ビジネス・サービスが非同期の場合でも、オプションとして、レスポンスがそのトランザクションのコンテキストで発生するように保証できます。つまり、非同期パターンを実質的に同期パターンに変換します。アウトバウンド・ビジネス・サービスでは、既存トランザクションの中断など、その他のトランザクション・サポートも提供されます。
同期トランザクション対応トランスポートでは、次の例がサポートされます。
レスポンス・パイプラインの処理が受信トランザクションに含まれるのは、インバウンド・トランスポートが同期トランザクションをサポートする場合、またはトランザクションをレスポンスに伝播するようにプロキシ・サービスを構成する場合です。この例は、インバウンド・トランスポートが他のアウトバウンド・トランスポートとペアである場合にサポートされますが、次の「注意」に示すように例外があります。
|
注意: インバウンド・トランスポートが同期トランザクションでアウトバウンド・トランスポートが非同期トランザクションの場合、デッドロック状況が発生します。デッドロックが発生する原因は、トランザクションがコミットされるまではアウトバウンド・リクエストがビジネス・サービスで受信できないにもかかわらず、トランザクションが外部で開始され、Oracle Service Busがレスポンスを受け取って制御が戻るまでコミットされないためです。トランスポート・マネージャはこの状況を認識し、実行時エラーをスローしてデッドロックを回避します。 たとえば、Tuxedoプロキシ・サービスなどの同期トランザクションのインバウンド・エンドポイントを使用していて、JMSビジネス・サービスなどのようにアウトバウンド・エンドポイントが非同期トランザクションである場合、レスポンスを受信するまでアウトバウンド・リクエストはトランザクションをコミットしません。外部エンティティがリクエストを受け取り、処理するまでは、レスポンスを受信できません。 |
また、この場合、レスポンス・パイプラインで実行されるOracle Service Busパブリッシュ・アクションは、トランザクションの一部として行われます。これはリクエスト・パイプラインで実行されるパブリッシュ・アクションがトランザクションの一部として行われるのと同様です。
|
注意: 複数のアクションが(リクエスト・パイプラインまたはレスポンス・パイプラインの)トランザクションに参加できます。これには、パブリッシュ・アクション、サービス・コールアウト・アクション、およびレポート・アクションが含まれます。 |
たとえば、インバウンドTuxedoトランスポートが同期トランザクションの場合、リクエスト・パイプラインおよびレスポンス・パイプラインが完了した場合のみコミットできます。この場合、トランスポート・マネージャは、トランザクション・コンテキストをインバウンド・スレッドからアウトバウンド・スレッドに転送します。レスポンス・スレッドが終了すると、トランザクション・コントロールおよび結果が呼出しクライアントに返されます。
Oracle Service Busサービス・コールアウトを使用すると、あるプロキシ・サービスから別のサービスへのコールアウトを行うことができます。同期トランザクション対応のトランスポートに対しサービス・コールアウト・アクションが実行された場合、「ベスト・エフォート」のサービス品質に加えて、「必ず1回」のサービス品質がサポートされます。「必ず1回」では、アウトバウンド・メッセージの送信が開始されるまでは終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに1回だけ配信されます「ベスト・エフォート」では、それぞれの送信で独自のトランザクション・コンテキストが定義されます(トランザクション対応のトランスポート方式の場合)。「ベスト・エフォート」が指定されている場合、メッセージングの機能に信頼性はなく、重複するメッセージは除去されませんが、パフォーマンスが最適化されます。39.7項「TransportOptionsの操作」も参照してください。
同期トランザクション対応のトランスポートへのコールアウトは必要に応じて既存のトランザクションの一部になります。たとえば、グローバル・トランザクション中にリクエスト・パイプラインを実行しいても、サービス・コールアウトはトランザクションへの参加を許可されます。たとえば、EJBサービスへのコールアウトがある場合、必要に応じてサービス品質の値を「必ず1回」に設定することで、サービスがそのトランザクションに参加できます。
サービス・コールアウトの詳細は、2.4.29項「メッセージ・フローへのサービス・コールアウト・アクションの追加と構成」を参照してください。
以下の条件に当てはまる場合、トランスポート・プロバイダを呼び出してアウトバウンド・リクエストを送信する前に、トランスポート・フレームワークがトランザクションを中断します。
アウトバウンド・サービス・エンドポイントがトランザクション対応です。
進行中のグローバルXAトランザクションがあります。
サービス品質が「ベスト・エフォート」に設定されている場合。
送信操作が完了すると、中断されていたトランザクションが再開されます。
トランスポートSDKにより、ユーザーおよびサード・パーティは、Oracle Service Busに新しいトランスポートをプラグインできます。Oracle Service Busのセキュリティ・モデル内では、トランスポート・プロバイダは信頼性のあるコードと見なされます。セキュリティ・ホールによる潜在的なセキュリティ上の脅威を避けるため、トランスポート・プロバイダの実装は慎重に設計することが重要です。このドキュメントには、安全なトランスポート・プロバイダを開発する方法についての具体的なガイドラインは含まれていませんが、この項では、以下のトランスポートSDKのセキュリティ目標について説明します。
トランスポート・プロバイダは、インバウンド認証のメカニズムがそのトランスポートに適しているものはすべて自由に実装できます。例:HTTPトランスポートは以下の認証方式をサポートします。
HTTP BASIC
HTTPヘッダーで送信されるカスタム認証トークン
HTTPSトランスポート・プロバイダは、上記の認証方法の他に、SSLクライアント認証をサポートします。HTTPトランスポート・プロバイダおよびHTTPSトランスポート・プロバイダのどちらも、匿名のクライアント・リクエストをサポートします。
トランスポート・プロバイダは、適用可能な任意のトランスポート・レベル認証スキームを実装します(存在する場合)。トランスポート・プロバイダがクライアントを認証する場合、weblogic.security.Security.runAs(subject)のスコープ内でTransportManager.receiveMessage()を呼び出し、Oracle Service BusがクライアントのSubjectオブジェクトを使用できるようにする必要があります。このメソッドの詳細は、Oracle Fusion MiddlewareのOracle Service Bus Java APIリファレンスを参照してください。
|
ヒント: JavaのSubjectクラスの詳細は、 |
プロキシは、以下のように、このSubjectを使用します。
プロキシ・サービスへのアクセス制御中
メッセージ・コンテキスト変数$inbound/ctx:security/ctx:transportClient/*へのデータの入力
IDの伝播および資格証明マッピングの入力として(メッセージ・レベルのクライアント認証もある場合を除く)
トランスポート・プロバイダが認証をサポートしない、または匿名のリクエストをサポートする場合、リクエストをディスパッチする前に匿名サブジェクトがスレッド上にあることを確認する必要があります。通常、トランスポート・プロバイダは、匿名としてすでに実行しています。そうでない場合、プロバイダは以下を呼び出す必要があります。
Subject anonymous = SubjectUtils.getAnonymousUser() Security.runAs(anonymous, action)
トランスポート・プロバイダは、インバウンド・クライアント認証の構成に必要な、任意のOracle Service Bus管理コンソール構成ページの提供も行います。
トランスポート・プロバイダは、インバウンド認証モデルを明確に記録しておく必要があります。
トランスポート・プロバイダは、アウトバウンド認証スキームがそのトランスポートに適しているものはすべて自由に実装できます。トランスポートSDKには、ユーザー名およびパスワードによるアウトバウンド認証、(双方向) SSLクライアント認証、およびJAAS Subject認証を容易に実現するためのAPIが含まれています。
Oracle Service Busのサービス・アカウントを使用して、ユーザー名およびパスワードによるアウトバウンド認証を実装できます。サービス・アカウントは、最上位のOracle Service Busリソースです。サービス・アカウントは、Oracle Service Bus管理コンソールで作成および管理されます。トランスポート・プロバイダでは、それぞれのトランスポート固有の構成を自由に設計し、サービス・アカウントへの参照を含めることができます。このようにして、トランスポート・プロバイダは、Oracle Service Busのサービス・アカウントによって提供される資格証明管理メカニズムを利用することができます。
トランスポート・プロバイダでは、サービス・アカウントの構成の詳細について懸念する必要はありません。サービス・アカウントのタイプは、以下の3つです。
静的 - 静的なサービス・アカウントは、固定されたユーザー名およびパスワードで構成されます。
マップされている - マップされたサービス・アカウントには、リモート・ユーザーおよびリモート・パスワードのリストとローカル・ユーザーからリモート・ユーザーへのマップが含まれます。マップされたサービス・アカウントでは、必要に応じて、任意のリモート・ユーザーに匿名サブジェクトをマップできます。
パススルー - パススルー・サービス・アカウントは、Oracle Service Busクライアントのユーザー名およびパスワードがバックエンドに送信される必要があることを示しています。
アウトバウンド・エンドポイントは、サービス・アカウントへの参照を持つことができます。サービス・アカウントへの参照は、トランスポート固有のエンドポイントの構成に格納する必要があります。プロキシ・サービスが、メッセージをこのアウトバウンド・エンドポイントにルーティングする場合、トランスポート・プロバイダは、サービス・アカウントへの参照をCredentialCallback.getUsernamePasswordCredential(ref)に渡します。Oracle Service Busは、サービス・アカウントの構成に応じて、ユーザー名およびパスワードを返します。この方法には、IDの伝播と資格証明マッピングの構成をトランスポート固有の詳細な作業から分離することで、トランスポートSDKを簡素化できるという利点があります。また、この構成の共有も可能になります。複数のエンドポイントが同じサービス・アカウントを参照できます。
|
注意: CredentialCallbackオブジェクトは、 |
CredentialCallback.getUsernamePasswordCredential()は、weblogic.security.UsernameAndPasswordインスタンスを返します。これは、ユーザー名およびパスワードを取得するためのメソッドを持つ簡単なクラスです。返されるユーザー名およびパスワードは、サービス・アカウントのタイプによって異なります。サービス・アカウントのタイプが静的である場合、固定されたユーザー名およびパスワードが返されます。サービス・アカウントのタイプがマップされている場合、クライアント・サブジェクトを使用してリモートのユーザー名およびパスワードがルックアップされます。サービス・アカウントがパススルーである場合、クライアントのユーザー名およびパスワードが返されます。
|
注意: 以下の場合、マップされたサービス・アカウントは、CredentialNotFoundExceptionをスローします。
|
Oracle Service Busは、アウトバウンドSSLクライアント認証もサポートします。この場合、アウトバウンドSSLリクエストを出すプロキシを、SSL用のPKIキー・ペアを使用して構成する必要があります。これには、プロキシ・サービス・プロバイダへの参照が含まれますが、このドキュメントでは、詳細については取り上げていません。SSLクライアント認証用のキー・ペアを取得するには、トランスポート・プロバイダがCredentialCallback.getKeyPair()を呼び出す必要があります。この例として、HTTPSトランスポート・プロバイダがあります。
一部のトランスポート・プロバイダは、認証トークンとして、シリアライズされたJAAS Subjectを回線で送信します。インバウンド・サブジェクトを取得するには、トランスポート・プロバイダがCredentialCallback.getSubject()を呼び出す必要があります。
|
注意: 戻り値は、匿名サブジェクトである場合があります。 |
一部のトランスポートでは、サービスに接続するために資格証明が必要になります。たとえば、FTPサーバーへの認証には、FTPエンドポイントが必要になる場合があります。トランスポート・プロバイダは、静的なサービス・アカウントを利用して、接続を確立するためのユーザー名およびパスワードを取得できます。これらの接続は、特定のクライアント・リクエストのかわりとしての確立されるものではないため、この場合、マップされたサービス・アカウントまたはパススルー・サービス・アカウントは使用できません。トランスポート・プロバイダでこのアプローチを採用する場合は、サービス・アカウントへの参照を使用してエンドポイントを構成する必要があります。実行時に、トランスポート・プロバイダは、TransportManagerHelper.getUsernamePassword()を呼び出して、静的なサービス・アカウントへの参照を渡す必要があります。
Oracle Service Busは、すべてのインバウンド・リクエストについてプロキシ・サービスへのアクセス制御を実施します。トランスポート・プロバイダでは、アクセス制御を実施するための、またはアクセス制御ポリシーを管理するためのインタフェースを提供する必要はありません。
|
注意: アクセス制御ポリシーはほとんどの使用例を対象としていますが、トランスポート・プロバイダに固有の理由で、(Oracle Service Busによって行われるアクセス制御チェックの他に)独自のアクセス制御メカニズムが必要な場合は、それらを実装できます。この場合は、Oracle販売代理店にお問い合わせください。通常は、トランスポート・プロバイダで、Oracle Service Busを使用してアクセス制御を処理する方法をお薦めします。 |
アクセスが拒否されると、TransportManager.receiveMessage()は、TransportException内にラップされているAccessNotAllowedExceptionをスローします。トランスポート・プロバイダは、TransportExceptionの根本原因を確認します。根本原因がAccessNotAllowedExceptionである場合、トランスポート・プロバイダは、特別なエラー処理を行う場合があります。たとえば、この場合、HTTP/Sトランスポート・プロバイダはHTTP 403(forbidden)エラー・コードを返します。
|
注意: Oracle Service Busは、アクセス制御の判断を行うために、認可プロバイダがリクエスト・ヘッダーを使用できるようにします。 |
38.6.2項「アウトバウンド・リクエストの認証」で説明したように、Oracle Service Busには、3つのタイプのサービス・アカウントが用意されています。トランスポート・プロバイダは、サービス・アカウントを利用して、アウトバウンド認証のためのユーザー名およびパスワードにアクセスできます。サービス・アカウントは、Oracle Service Busのトランスポート・プロバイダに対し、すべてのIDの伝播および資格証明マッピングの詳細を非表示にしています。
この項では、Oracle Service Busで使用されるスレッディング・モデル、およびそのモデルがトランスポートSDKにどのように関係するかを説明します。この項には次のトピックが含まれます:
図38-5に、1つのインバウンド・メッセージを処理する仮想のトランスポート・エンドポイントを表す、Oracle Service Busのスレッディング・モデルを示します。
Servletなどのフロント・エンド・アーティファクトが、インバウンド・メッセージを取得します。リクエストを、アウトバウンド・エンドポイントにルーティングし、非同期的に送信できます。この時点で、スレッドは解放されます。その後しばらくして、コールバックを使用して、レスポンスがOracle Service Busに送り返されます。レスポンスが受信され、パッケージ化されて、Oracle Service Busパイプラインに渡されます。その後、パイプラインが、レスポンスをクライアントに送信する準備ができていることをインバウンド・エンドポイントに通知します。スレッドが使用できないのは必要な間のみであるため、この処理はスケーラブルです。
同じスレッドで以下のアクションが実行されます。
トランスポート・エンドポイントのフロント・エンド・アーティファクトがインバウンド・メッセージを受信します。このフロント・エンド・アーティファクトは、HTTPサーブレットやJMSメッセージドリブンBeanのインスタンスなどです。
トランスポート・エンドポイントの実装により、メッセージはTransportMessageContextオブジェクトにパッケージ化され、Oracle Service Busランタイムに渡されます。TransportMessageContextインタフェースの詳細は、41.5項「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」を参照してください。
パイプラインは、プロキシに構成されているリクエスト・パイプライン・アクションを実行します。
Oracle Service Busパイプラインでインバウンド・メッセージを処理すると同時に、同じ(リクエスト)スレッドで、Oracle Service Busランタイムは、アウトバウンド・メッセージを外部サービスに配信するよう、登録されているアウトバウンド・トランスポート・エンドポイント(このエンドポイントは、同じプロバイダで管理されていない場合もある)に要求します。
その後しばらくして、外部サービスは、レスポンス・メッセージを配信するよう、アウトバウンド・エンドポイントに非同期的に要求します。アウトバウンド・エンドポイントは、トランスポート固有のコールバック・オブジェクトを使用して、事前に登録されている必要があります。
|
注意: この時点で、最初のリクエスト・スレッドは解放され、別のリクエストが使用できるようにOracle WebLogic Serverのスレッド・プールに戻されます。 |
同じスレッドで以下のアクションが実行されます。
レスポンス・メッセージは、TransportMessageContextオブジェクトにパッケージ化され、レスポンス処理のためにOracle Service Busランタイムに戻されます。この処理は、リクエスト・スレッドとは別のスレッドで実行されます。新しいスレッドは、レスポンス・スレッドと呼ばれます。
レスポンス・メッセージが処理された後、Oracle Service Busランタイムは、レスポンスを呼出し元に送り返すタイミングであることを通知するよう、InboundTransportMessageContextオブジェクトに要求します。InboundTransportMessageContextインタフェースの詳細は、41.5項「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」を参照してください。
トランスポート・プロバイダが、非同期の(非ブロッキング)アウトバウンド呼出しをネイティブに実装していない場合は、インバウンド・リクエスト・メッセージを受信したスレッドとは別のスレッドで、Oracle Service Busランタイムにレスポンスを返す必要があります。これを行うためにトランスポート・プロバイダは、リクエスト・スレッドでブロッキング呼出しを実行し、トランスポートSDKのヘルパー・メソッドを使用して、Oracle Service Busランタイムにレスポンスを返します。
たとえば、EJBトランスポート・プロバイダは、非同期(非ブロッキング)のアウトバウンド呼出しを実装していません。基底のAPIはブロッキングAPIです。これに対処するには、プロバイダがブロッキング呼出しを行い、その後で、TransportManagerHelper.schedule()を使用して処理に対するレスポンスをスケジュールします。EJBトランスポート・プロバイダの詳細は、第28章「EJBトランスポート・」を参照してください。
トランスポート・サブシステムは、意図的に、Oracle Service Busと非同期的に対話するようになっています。これは、非同期での動作が、同期での動作よりもスケーラブルであるため望ましいからです。非同期の対話用に1つ、および同期の対話用に1つと、2つの別々のAPIを作成するのではなく、Oracle Service Busランタイムでは非同期の対話が必要です。この処理は、ブロッキング呼出しやコールバックでのレスポンスをポストするなどの方法により、トランスポート開発者が行う必要があります。いずれにせよ、レスポンスは、リクエストとは別のスレッドで実行する必要があります。
図38-5に示すスレッド・ダイアグラムは、ルーティングに焦点を当てたものです。トランスポート・サブシステムは、リクエストまたはレスポンス・パイプラインの処理中に実行されるOracle Service Busのパブリッシュ・アクションとサービス・コールアウト・アクションに対して同じように動作します。これらのアクションは、トランスポート・サブシステムの範囲外およびOracle Service Busパイプラインの範囲内で実行されます。そのため、パブリッシュおよびサービス・コールアウトのスレッディング動作とトランスポート・プロバイダのスレッディング動作には違いがいくつかあります。
ただし、以下の場合に注意してください。
サービス・コールアウト - 非同期的にレスポンスを受信するまで、パイプライン・プロセッサがスレッドをブロックします。その後、ブロックされたスレッドはパイプラインの実行を再開します。この目的は、後でパイプライン・アクションで使用できる変数をバインドし、ビジネス・ロジックを実行することです。そのため、レスポンスが返される前にビジネス・ロジックが実行されるように、これらのアクションがブロックする必要があります。
パブリッシュ - 非同期的にレスポンスを受信するまで、パイプライン・プロセッサがスレッドをブロックしない場合もあります。その後、このスレッドは、残りのリクエストまたはレスポンス・パイプラインの処理の実行を続行します。
|
ヒント: サービス・コールアウト・アクションにより、ユーザーは、Oracle Service Busにすでに登録されているプロキシまたはビジネス・サービスに対し、同期(ブロッキング)呼出しを構成することができます。メッセージのターゲット・サービスを特定し、そのサービスへメッセージをパッケージ化し、送信する方法を構成するには、パブリッシュ・アクションを使用してください。サービス・コールアウト・アクションおよびパブリッシュ・アクションの詳細は、2.4.29項「メッセージ・フローへのサービス・コールアウト・アクションの追加と構成」および2.4.17項「メッセージ・フローへのパブリッシュ・アクションの追加と構成」を参照してください。 |
この項には次のトピックが含まれます:
トランスポート・プロバイダには、メッセージ・コンテンツの独自のネイティブ表現があります。たとえば、HTTPトランスポートはjava.io.InputStreamを使用し、JMSは、様々なタイプのMessageオブジェクトがあります。また、Tuxedoにはバッファがあり、WLS WebサービスのスタックはSAAJを使用します。ただし、プロキシ・サービスの実行時は、コンテンツのネイティブ表現は、メッセージ・コンテキストです。Oracle Service Busは、InputStreamからメッセージ・コンテキストへの、またはその逆などの一部の一般的な変換シナリオをサポートしますが、トランスポートでの表現とメッセージ・コンテキストの間の変換は、最終的にはトランスポート・プロバイダが行います。
通常、トランスポートSDKが、トランスポートの2つの異なるコンテンツ表現を直接変換することはありません。ただし、2つのトランスポートが互換性のある表現を使用していて、コンテンツを再エンコードする必要がない場合は、SDKによって、(たとえば、インバウンド・ファイル・トランスポートからアウトバウンドHTTPトランスポートにFileInputStreamを渡すことにより)ソース・コンテンツを直接パススルーできます。ただし、ソース・コンテンツで何らかの処理が必要な場合は、最初にソース・コンテンツをメッセージ・コンテキストに復号化し、その後で標準のメカニズムを使用して送信トランスポート用のコンテンツを生成した方が適切です。
コンテンツは、Sourceインタフェースのインスタンスとして表されます。TransportSenderやTransportMessageContextなどのメッセージ・コンテンツを処理するトランスポートSDKインタフェースは、すべてメッセージ・ペイロードを渡す際に、Sourceインタフェースを使用します。Sourceにおける要件はごくわずかです。Sourceは、基本となるSourceインタフェースで定義されている2つのメソッドを使用した、バイト単位のストリームへのプルベースおよびプッシュ・ベースの変換をサポートする必要があります。Sourceは、シリアライゼーション中に、TransformOptionsパラメータで指定されている、文字セット・エンコーディングなどの様々なトランスフォーメーションのオプションを考慮しない場合があります。
すべてのSourceオブジェクトは基底のシリアライゼーション・インタフェースを実装する必要がありますが、Sourceオブジェクトの基礎となる表現は実装固有のものです。そのため、InputStream、JMS Messageオブジェクト、String、または特定のトランスポートに最も適している表現に基づいたSourceオブジェクトを使用できます。通常、Sourceを実装することで、基本的なシリアライゼーション・メソッドだけでなく、基底のコンテンツに直接アクセスできるようになります。たとえば、内部でStringオブジェクトを使用してそのコンテンツを格納するStringSourceは、内部データにアクセスするためのgetString()メソッドを提供します。その後、Sourceの最終的なコンシューマは、これらのソース固有のAPIを呼び出して、基底のコンテンツを抽出し、シリアライゼーションのオーバーヘッドを回避することができます。
また、Transformerオブジェクトを使用して、Sourceを他のタイプのSourceに変換することもできます。トランスポート・プロバイダなどのSourceコンシューマが、認識できないSourceインスタンスを受け取った場合は、多くの場合、認識できるSourceインスタンスに変換できます。その後、ソース固有のAPIを使用して、認識できるSourceから基底のコンテンツを抽出できます。ただし、トランスポート・プロバイダは多くの場合、単に基本的なシリアライゼーション・メソッドを使用してコンテンツをシリアライズし送信します。41.4項「SourceおよびTransformerクラスとインタフェース」も参照してください。
Sourceは、トランスポート・レイヤーとバインディング・レイヤーの間の一般的なコンテンツ表現です。バインディング・レイヤーは、トランスポート・レイヤーで使用されるSource表現と実行時にパイプラインで使用されるメッセージ・コンテキストとの間でコンテンツを変換するエンティティです。変換がどのように行われるかは、サービスのタイプ(そのバインディングのタイプ)と添付の有無によって異なります。厳密にはトランスポートSDKの役割ではありませんが、独自のSourceオブジェクトを定義しているすべてのトランスポート・プロバイダは、この変換プロセスを認識している必要があります。
添付が存在しない場合、受信したSourceは単にコアとなるメッセージ・コンテンツを示します。受信したSourceを特定のタイプのSourceに変換し、その後で基底のコンテンツを抽出することでMessageContextが初期化されます。たとえば、XMLベースのサービスの場合、受信したSourceはXmlObjectSourceに変換されます。その後、XmlObjectSourceからXmlObjectが抽出され、$bodyコンテキスト変数内でペイロードとして使用されます。同様に、SOAPサービスはXmlObjectSourceに変換されます。ただし、<SOAP:Header>および<SOAP:Body>要素を抽出して$headerおよび$bodyコンテキスト変数を初期化できるようにするために、抽出されたXmlObjectがSOAP Envelopeである必要がある点が異なります。
定義された一連のサービス・タイプで使用される標準的なSourceのタイプを以下に示します。
SOAP - XmlObjectSource
XML - XmlObjectSource
TEXT - StringSource
MFL - MFLSource
バイナリ・サービスの場合、Sourceの変換は行われません。かわりに、Sourceは、SourceRepositoryに登録され、結果の<binary-content/> XMLは、$body内でペイロードとして使用されます。
添付が存在する場合、Sourceは最初にMessageContextSourceに変換されます。MessageContextSourceから、2つのタイプのSourceオブジェクトが取得されます。1つが添付で、もう1つがコア・メッセージです。コア・メッセージのSourceは、前述のとおり処理されます。添付を表すSourceは、AttachmentsSourceに変換されます。AttachmentsSourceから、XMLが取得され、$attachmentsコンテキスト変数、および任意のバイナリの添付コンテンツを表す登録済のSourceを含むSourceRepositoryの初期化に使用されます。図38-6に、このプロセス全体を示します。
トランスポート・レイヤーに渡すためにMessageContext内のデータからSourceを作成する場合にも、同様の変換が実行されます。コア・メッセージは、サービスのタイプの標準的なSourceに変換できるSourceインスタンスで表現されています。ほとんどの場合、Sourceは、すでに標準的なSourceのインスタンスになっていますが、必ずしもそうであるとは限りません。添付が存在する場合、トランスポート・レイヤーに渡されるSourceは、MessageContextSourceインスタンスに変換できるSourceになります。トランスポート・プロバイダが、事前定義されたトランスポート・ヘッダーとしてContent-Typeをサポートする場合、一般的に、配信されたSourceはMessageContextSourceのインスタンスになります。それ以外の場合、配信されたSourceはMimeSourceのインスタンスであることが多いですが、これもMessageContextSourceに変換できます。
この違いの理由は、トランスポート・ヘッダーとしてContent-Typeをネイティブにサポートするトランスポートでは、ペイロードではなく、トランスポート・ヘッダーにトップ・レベルのMIMEヘッダーが含まれている必要があるためです。この例としては、HTTPおよび電子メールがあります。Content-Typeをネイティブにサポートしないトランスポートでは、これらのトップ・レベルのMIMEヘッダーがペイロードに含まれている必要があります。Content-Typeヘッダーは、複数のMIMEパッケージのデコードに不可欠であるためです。
表38-1はソースと、そのソースを組込みのトランスフォーメーションによって変換できるソース・タイプの一覧を示しています。たとえば、StringSourceからXmlObjectSourceへの変換を処理する組込みのトランスフォーメーションはありますが、StringSourceをXmlObjectSourceに変換できるトランスフォーメーションはありません。通常、次に示すトランスフォーメーションは、両方のソース・タイプで使用される内部データ表示の情報を利用します。
表38-1 組込みのトランスフォーメーション
| パブリック・ソース | 変換後のソース・タイプ |
|---|---|
|
Source |
|
|
StreamSource |
StreamSource |
|
ByteArraySource |
ByteArraySource |
|
StringSource |
|
|
XmlObjectSource |
|
|
DOMSource |
|
|
MFLSource |
|
|
MimeSource |
|
|
SAAJSource |
|
|
MessageContextSource |
|
これらの一般的なトランスフォーメーションは元のソース・タイプの情報を使用せずに行われますが、かわりに、すべてのSourceが実装している基本的なシリアライゼーション・メソッドのgetInputStream()およびwriteTo()を利用します。したがって、XmlObjectSourceからByteArraySourceへの変換は最終的には可能ですが、XmlObjectSourceの内部情報を使用して行われることはありません。
|
注意: トランスポートで実装されているカスタムSourceの多くは、(基底のデータが構造化されていないバイトの収集である場合は特に)これらの一般的なトランスフォーメーションで処理できます。たとえば、ファイル・トランスポートは、ディスク上のファイルから直接コンテンツを取り出すカスタムSourceを使用します。ただし、データは構造のない単なるバイトのセットであるため、XmlObjectSourceなどへのカスタム・トランスフォーメーションを実行する必要はありません。SourceからXmlObjectSourceへの一般的なトランスフォーメーションで、すべてのSourceが実装している基本的なシリアライゼーション・メソッドのみを使用して、このカスタムFileSourceを処理することができます。 |
詳細は、41.4項「SourceおよびTransformerクラスとインタフェース」を参照してください。
