|
|
Oracle Service Bus Console は、『Oracle Service Bus Console の使い方』にあるように、Oracle Service Bus をコンフィグレーションするために使用します。WebLogic Portal を使用した WSRP 対応ポータルの作成の詳細については、『連合ポータル ガイド』を参照してください。
WSRP 対応 Oracle Service Bus のコンフィグレーションには、以下のタスクが含まれます。
通常、コンシューマは、プロデューサに直接アクセスして WSDL を取得します。しかし、Oracle Service Bus をプロキシ サービスとして使用している場合、プロデューサへのすべてのアクセスは Oracle Service Bus を介して行われます。このため、コンシューマ用のプロキシ サービスを実装します。このプロキシ サービスは、プロデューサの実際の URL を呼び出してプロデューサ WSDL を取得します。次のようにプロキシ サービスは結果を変換します。
開発者がプロデューサを作成するときに、プロデューサで SSL が必要 ("secure=true") かどうかを指定できます。また、Oracle Service Bus 管理者は、Oracle Service Bus コンフィグレーションを使用して、コンシューマに対するセキュリティ要件を変更できます。たとえば、プロデューサが SSL を要求しない場合は、Oracle Service Bus 管理者は、次のようにしてコンシューマに SSL の使用を要求することができます。
このようにコンフィグレーションすると、Oracle Service Bus は、コンシューマからの安全なメッセージとプロデューサが使用する安全でないメッセージを自動的に橋渡しします。
コンシューマは、WSDL のコピーを取得した後、WSDL の定義を使用してサービス要求を作成し、Oracle Service Bus を介してプロデューサに送信します。WSRP の要求/応答プロセスの手順は以下のとおりです。
WSRP Web サービスはポートレットをエクスポーズします。それらのポートレットは HTTP のクッキーとセッションに依存する場合があります。そのため、HTTP 転送ヘッダ (SOAPAction やクッキーなど) を伝播するには、WLSB をコンフィグレーションする必要があります。ただし、プロキシ サービスとビジネス サービスが同じ転送を使用するとは限らないため、デフォルトでは、Oracle Service Bus は、プロキシ サービスからビジネス サービスに転送ヘッダを渡しません。そのため、要求ヘッダを着信要求から発信要求にコピーするように、メッセージ フローをコンフィグレーションする必要があります。同様に、ビジネス サービスの応答ヘッダも、プロキシ サービスからコンシューマへの応答にコピーする必要があります。
すべての転送ヘッダをプロキシ サービスとビジネス サービスの間でコピーできますが、エラーを避けるために、コピーする転送ヘッダを選択してください。Set-Cookie ヘッダと Cookie ヘッダをコピーする必要があります。最終メッセージは、いくつかのヘッダ (Content-Length など) を保持する必要があります。これは、Oracle Service Bus は最終送信メッセージをアセンブルするエンティティであるためです。たとえば、メッセージ フローで Content-Length ヘッダをプロキシ サービスからビジネス サービスにコピーすると、処理中にメッセージの長さが変化したためにエラーになることがあります。そのため、Oracle Service Bus はヘッダを保持する必要があります。
WSRP アプリケーションをモニタすることによって、プロデューサの個々のサービスと処理の使用状況を追跡します。WSRP サービスのメッセージ フローのオーバーヘッドは非常に少なく、プロキシ サービスとプロデューサ間のマッピング、およびビジネス サービスとプロデューサ間のマッピングは容易にコンフィグレーションできます。そのため、SLA 要件を満たすには、プロキシ サービスをモニタするだけで十分です。
WSRP アプリケーションのモニタの詳細については、『オペレーション ガイド』の「実行時の Oracle Service Bus のモニタ」を参照してください。
Oracle Service Bus では、ビジネス サービスに、同じ Web サービスを提供する複数のエンドポイントを定義できます。複数のエンドポイントを定義すると、Oracle Service Bus では、エンドポイント間で要求のロードバランスを自動的に調整できます。また、1 つのエンドポイントがアクセスできなくなると、要求を自動的にフェイルオーバすることもできます。ただし、WSRP ではこれらの機能の使用が一部制限されます。
ポートレットは、アプリケーションにユーザ インタフェースを提供する手段です。そのため、通常、ポートレットには、セッション データが関連付けられています。セッション データを保持するために、ポートレットへの要求は、元の要求を処理したものと同じサーバ (またはクラスタ) に送信される必要があります。この要件により、Oracle Service Bus でのロード バランシングは適していません。ビジネス サービスの複数のエンドポイントは、通常、異なるサーバまたはクラスタを対象とします。別のクラスタ内に存在するサーバ間では通信は行われないため、セッションを保持する方法はありません。そのため、WSRP ビジネス サービスに複数のエンドポイントを定義している場合、ロード バランシングのアルゴリズムは "none" に設定する必要があります。
特定の環境では、複数のエンドポイントを使用して冗長性を確保し、エンドポイントの 1 つが使用できなくなった場合に備えることができます。2 つ目のエンドポイントで WSRP サービスを利用できます。ただし、最初のエンドポイントが使用できなくなった時点のセッション データは、他のエンドポイントでは使用できません。
このフェイルオーバ コンフィグレーションは、単純なプロデューサでのみ使用できるオプションです (「WSRP WSDL」を参照)。複雑なプロデューサでは使用できません。複雑なプロデューサでは、サービス要求を送信する前に、コンシューマでプロデューサに登録する必要があります。プロデューサは登録ハンドルを返します。コンシューマは、そのプロデューサへの各要求にこのハンドルを含める必要があります。ビジネス サービスに複数のエンドポイントが定義されている場合、各エンドポイントに個別の登録ハンドルが必要です。
ただし、Oracle Service Bus は、要求と要求の間はステートレスであるため、特定のエンドポイントに送信するための正しいハンドルのマッピングは保持されません。実際、登録要求は 1 つのエンドポイントに送信されるので、コンシューマは 1 つのプロデューサにのみ登録されます。このプロデューサを使用できない場合、Oracle Service Bus はサービス要求をそのビジネス サービスに定義されている別のエンドポイントへルーティングします。しかし、この新しいプロデューサにはコンシューマが登録されていないため、要求は "InvalidRegistration" エラーで失敗します。
登録ハンドルの管理では、この状態データを保持するために、Oracle Service Bus 以外のアプリケーションが必要になります。そのため、この登録要件により、複雑なプロデューサに複数のエンドポイントを定義できません。単純なプロデューサは、登録サービスをサポートしないため、ビジネス サービスに複数のエンドポイントを定義するフェイルオーバ コンフィグレーションが可能です。ただし、セッション データはフェイルオーバ時に失われます。
|