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