| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.2.1) E69914-01 |
|
 前 |
 次 |
この章では、Oracle Service BusコンソールおよびJDeveloperを使用して、ビジネス・サービスを作成、構成および管理する方法について説明します。Service Busのビジネス・サービスとプロキシ・サービスを使用すると、エンタープライズ全体でのサービスの管理、メッセージの変換およびメッセージのルーティングを行うことができます。
ビジネス・サービスは、メッセージの交換先となるエンタープライズ・サービスのService Busでの定義です。これらは、Service BusがクライアントとなるエンタープライズWebサービスを定義します。これらの外部Webサービスは、外部システムに実装され、外部システムによってホストされるため、Service Busは呼び出す対象、呼び出す方法および呼出しの結果として予想される内容を認識しておく必要があります。Service Busが外部サービスを呼び出すことができるように、ビジネス・サービスではそのインタフェースをモデル化しています。
ビジネス・サービスは、プロキシ・サービスと同様に、WSDL (Web Services Definition Language)またはWADL (Web Application Definition Language)を使用して定義します。ビジネス・サービスの構成には、インタフェース、トランスポート設定、およびセキュリティ 設定が含まれますビジネス・サービスがWSDLドキュメントに基づいている場合、構成にはWSDLポートまたはWSDLバインドも含まれます。(「WSDLドキュメントの操作」を参照。)
UDDIレジストリ、SOA Oracle Metadata Services (MDS)レジストリ、アプリケーション・サーバー、またはファイル・システムからインポートしたドキュメントを含む、既存のWSDLおよびWADLドキュメントをビジネス・サービスの基盤にすることもできます。Service Busでは、RESTバインディングを使用するビジネス・サービスもサポートしています(「Oracle Service BusでのRESTサービスの作成」を参照)。これらのサービスは、WADLドキュメントに基づくものであり、JDeveloperのService Bus概要エディタでのみ作成できます。
各ビジネス・サービスは、WSDL WebサービスとService Busトランスポートのどちらを基準にするかで定義されます。WSDLベースのサービスは、WSDLドキュメントでインタフェースが記述されるSOAPビジネス・サービスまたはXMLビジネス・サービスです。トランスポート型のサービスは、JCAトランスポートなどのService Busトランスポートに基づくビジネス・サービスで、Oracle JCA準拠アダプタにビジネス・サービスを構成するためのサポートが提供されます。これにはHTTPトランスポートを使用するRESTビジネス・サービスも含まれます。各タイプのビジネス・サービスでは、その定義に固有のトランスポート・プロトコルがサポートされます。Service Busは、いくつかの標準トランスポート・プロトコルとカスタム・トランスポートをサポートします。
「ビジネス・サービスの作成」ウィザードまたはJDeveloperのService Bus概要エディタのいずれかを使用して、WSDLベースまたはトランスポート型のサービスでビジネス・サービスを作成できます。Service Bus概要エディタを使用すると、JCAアダプタからビジネス・サービスを直接生成して、そのアダプタ・タイプにすでに構成されているビジネス・サービスを作成できます。ウィザードとエディタのどちらでも、プロキシ・サービスからビジネス・サービスを生成できます。
Service Busは、従来のWebサービス(WSDLファイルでXMLまたはSOAPバインディングを使用)から非XMLサービス(汎用)サービスまで、多くのサービス・タイプに対応しています。トランスポート型のビジネス・サービスを作成する場合、サービス・タイプを指定して構成することで、サービスをさらに定義する必要もあります。選択できるサービス・タイプは、サービス・エンドポイントとの通信に使用するトランスポートに基づいて制限されます。各サービス・タイプでサポートされるトランスポートの詳細は、「トランスポート、アダプタおよびバインディング」を参照してください。
ビジネス・サービスのサービス・タイプは、次のいずれかになり、そのサービスが処理するメッセージのタイプで識別されます。
WSDLベース・サービス: このサービス・タイプは、既存のWSDLドキュメント、またはビジネス・サービスの作成と同時に作成したWSDLドキュメントから生成されます。WSDLベースのサービスを作成する際は、使用するポートまたはバインディングを指定する必要があります。
メッセージ・サービス: このサービス・タイプは、あるデータ型のメッセージを受信し、レスポンスとして別のデータ型のメッセージを返すことができます。サポートされるデータ型には、XML、Message Format Language (MFL)、テキスト、型なし、バイナリ、Java、インタフェースがWSDLで記述されていない添付などがあります
任意のSOAPサービス: このサービス・タイプは、SOAPメッセージを交換します。SOAPメッセージは、<soap:Envelope>要素内のheader変数およびbody変数のコンテンツをラップすることで作成されます。body変数に参照XMLが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに置き換えられません。attachments変数で添付が定義されている場合は、メイン・メッセージと添付データからMIMEパッケージが作成されます。各添付部分のコンテンツの処理方法は、メッセージング・サービスのコンテンツの処理方法に類似しています。
任意のXMLサービス(非SOAP): このサービス・タイプでは、XMLベースのサービスへのメッセージはXMLですが、ビジネス・サービスの構成で許可された任意の型を使用できます。添付を含むメッセージの場合、そのコンテンツは、プライマリXMLペイロードをその一部(通常は最初の部分、または最上位のContent-Typeヘッダーで指定される部分)として含むMIMEパッケージです。
RESTサービス: このサービス・タイプは、RESTバインディングに基づき、既存のWADLから生成するか、プロキシ・サービスの作成と同時に作成したWADLから作成するか(型付きREST)、またはWADLまたはスキーマなしで作成(型なしREST)できます。詳細は、「Oracle Service BusでのRESTサービスの作成」を参照してください。
各ビジネス・サービス・タイプは、サービスに対して構成する必要があるパターン同じパターンに従ってモデル化されます。これらのモデルは、プロキシ・サービスのモデルと同じです。詳細は、「プロキシ・サービス・タイプのバインディング定義とランタイム変数」を参照してください。
ビジネス・サービスの構成の大部分には、トランスポート・プロトコルが関与します。トランスポートは、外部システムとビジネス・サービスとの間の通信レイヤーです。ビジネス・サービスに使用できるトランスポート・プロトコルは、作成するサービス・タイプによって異なります。それぞれのトランスポート・プロトコルには独自の構成要件があります。トランスポート・プロトコルとその構成要件の詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照し、関連する特定のプロトコルのリンクをクリックしてください。
トランスポートおよびWSDLファイル、またはインタフェースに基づいて、トランスポート・モードが自動的に選択されますが、ルート・アクションまたはパブリッシュ・アクションのルーティング・オプション・アクションを使用して上書きできます。
各ビジネス・サービスの次のパラメータを構成できます。
形式<string URI, integer weight>による重み付けされたエンドポイントURIのリスト(例: <http://www.oracle.com, 100>)。ランダムな重みベースのリストには、少なくとも1つの要素が含まれます。
ロード・バランシング・アルゴリズム。ラウンド・ロビン、ランダム、ランダムな重みベースになります。ランダムな重みベースを選択すると、各URIに重みを適用できます。
再試行回数
再試行の反復間隔
アプリケーション・エラーの再試行
選択するトランスポート方式は、バインディング定義で必要とされるトランスポート・モード(リクエスト/レスポンス、一方向、または両方)をサポートできる必要があり、それに従って構成する必要があります。
両方のモード(リクエスト/レスポンスと一方向)でメッセージを交換するサービスでは、トランスポート・モードを適宜選択できるようにバインディング・レイヤーを構成する必要があります。サービスが具象型の場合、バインディング定義の記述に従って、この選択が自動的に行われます。サービスが具象型でない場合、バインディング・レイヤーを構成するには、パイプラインでルーティング・オプション・アクションを使用して、ルートまたはパブリッシュのモードを設定する必要があります。
Tuxedoトランスポートベースのサービスでは、サービス・タイプがXMLの場合、TuxedoクライアントのFLD_MBSTRINGフィールドを含むFML32バッファはXMLに変換されません。各種トランスポート・プロトコルに基づくビジネス・サービスの構成の詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。
ロード・バランシング・アルゴリズムは、エンドポイントURIが実行時に選択される順序を定義します。Service Busでは、次のアルゴリズムがサポートされます。
ラウンドロビン: ビジネス・サービスに定義するURIを動的に順序付けます。最初のものに失敗した場合は次が試行され、次のものに失敗した場合はその次というように、再試行回数に達するまで続きます。新しいメッセージごとに、URIの順序が新しく設定されます。
ランダム: ビジネス・サービスに定義するURIのリストをランダムに順序付けます。最初のものに失敗した場合は次が試行され、次のものに失敗した場合はその次というように、再試行回数に達するまで続きます。
ランダムな重みベース: ビジネス・サービスに定義するURIのリストをランダムに順序付けますが、「重み」フィールドに入力した値に基づいて、一部のURIが他のURIよりも頻繁に再試行されます。
なし: ビジネス・サービスに定義するURIのリストを上から下に順序付けます。
ビジネス・サービスの再試行オプションでは、ビジネス・サービスが最初の失敗後にエンドポイントURIへのアクセスを再試行できる最大回数を指定します。たとえば、エンドポイントURI eu1、eu2およびeu3を使用した場合のビジネス・サービスBの動作を考えてみます。再試行回数は、それぞれ1、2および4に設定しています。
再試行回数 = 1の場合: ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、エラーを返します。ビジネス・サービスは、3番目のエンドポイントURI eu3を試行しません。
再試行回数 = 2の場合: ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、eu3を使用してリクエストを処理しようとします(再試行2)。再試行が失敗した場合には、エラーを返します。
再試行回数 = 4の場合: ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、eu3を使用してリクエストを処理しようとします(再試行2)。次に、再試行の反復間隔に構成した間隔(秒)をおいて、eu1を試行します(再試行3)。これに失敗すると、eu2を再試行します(再試行4)。再試行が失敗した場合には、エラーを返します。
再試行回数を0に設定すると、ビジネス・サービスは、失敗後に再試行を実行しません。
注意:
ビジネス・サービスがエンドポイントを再試行する順序は、ロード・バランシング・アルゴリズムによって制御されます。
通信エラーやアプリケーション・エラーが発生すると、ビジネス・サービスはリクエストの処理に失敗します。通信エラーは、様々なネットワークの問題によって発生します。その場合、別のエンドポイントURIを使用してリクエストを再試行すると正常に処理できる可能性があります。アプリケーション・エラーは、リクエストの形式が正しくない場合やその他のエラーが原因で発生します。このエラーは、どのエンドポイントでも処理できません。使用したトランスポートに応じて、ビジネス・サービスの「トランスポート構成」ページにある「アプリケーション・エラーの再試行」オプションを選択解除することにより、アプリケーション・エラーの再試行動作を無効にできます。
ビジネス・サービスには、サービスによるメッセージ・コンテンツの処理(MTOM/XOPサポート、MIME添付ファイル、WS-I準拠のチェック、使用するXQueryバージョンなど)を定義するプロパティが含まれます。
XOP/MTOMサポートが有効なビジネス・サービスでは、アウトバウンド・メッセージをMTOM/XOP形式でエンコードできます。SOAP Message Transmission Optimization Mechanism (MTOM)は、バイナリ・データをWebサービスとの間で送受信する方法です。MTOMは、XML-binary Optimized Packaging (XOP)を使用してバイナリ・データを転送します。
Service Busでは、次のトランスポートを使用したXOP/MTOMがサポートされます。
HTTP/S
ローカル
SB
$headerおよび$bodyメッセージ・コンテンツ変数のバイナリ・データは、次の2つの方法のいずれかで処理できます。
参照によるバイナリ・データを含む: (デフォルト)アウトバウンド・レスポンス・メッセージでの$bodyメッセージ・コンテキスト変数の設定時に、xop:Include要素をctx:binary-content要素に置換します。
値によるバイナリ・データを含む: アウトバウンド・レスポンス・メッセージで、$bodyメッセージ・コンテキスト変数の設定時にxop:Include要素を対応するバイナリ・データのBase64エンコード・テキスト・バージョンで置換します。
「XOP/MTOMサポート」がビジネス・サービスに対して有効になっている場合は、すべてのアウトバウンド・メッセージがMTOM形式である必要はありません。かわりに、この設定はビジネス・サービスがMTOMペイロードを処理できることを指定します。Service BusではMTOMとSwAの組合せがサポートされないため、Service Busがアウトバウンド・リクエストをビジネス・サービスにディスパッチしようとした場合、およびビジネス・サービスでMTOMとXOPの両方が有効で、$attachmentsメッセージ・コンテキスト変数がnullでない場合は、システムによって実行時エラーが発行されます。
Service Busでは、HTTP/Sトランスポートを使用したMIME添付ファイルのストリーミングがサポートされます。この機能を使用すると、アウトバウンド・レスポンス・メッセージ内の添付ファイルをディスク・ファイルに格納し、添付ファイルのコンテンツをメモリーにバッファリングせずにストリーミング形式でデータを処理できます。これにより、ビジネス・サービスで、大きな添付ファイルを堅牢かつ効率的に処理できます。
XOP/MTOMサポートを有効にして「値によるバイナリ・データを含む」オプションを選択した場合、「添付ファイルのディスクへのページング」を選択しようとすると警告が表示されることに注意してください。この2つのオプションには互換性がありません。添付ファイルを含むペイロードはRFC 822に準拠している必要もあります。具体的には、インターネット・ヘッダーを含む行は、CRLF (復帰改行)で終了する必要があります。
メッセージをプロキシ・サーバー経由でルーティングするようにビジネス・サービスを構成するには、必要な資格証明とともに1つ以上のプロキシ・サーバーを指定するプロキシ・サーバー・リソースを作成します。その後、プロキシ・サーバー・リソースをビジネス・サービスに関連付けることができます。これにより、Service Busが、構成されたプロキシ・サーバーを使用してビジネス・サービスへの接続を行います。
複数のプロキシ・サーバーをリソースに追加すると、Service Busでロード・バランシングが実行され、構成されたプロキシ・サーバー間でフォルト・トレランスが可能になります。資格証明はプロキシ・サーバーに対する接続を開く場合に使用されます。特定のプロキシ・サーバーにアクセスできない場合、Service Busは構成に含まれる次のプロキシ・サーバーを使用しようとします。すべてのプロキシ・サーバーにアクセスできない場合、Service Busはバック・エンド・サービスへの直接接続を試みます。これにも失敗すると、フォルトが発生して呼出し元に返送されます。
プロキシ・サーバー・リソースの詳細は、「プロキシ・サーバー・リソースの操作」を参照してください。
サービス・レベル合意(SLA)のアラート・ルールでは、アラートの生成条件が定義されます。これらの条件は、通常、Service Busアプリケーションまたは特定のサービス・コンポーネントの全体的なヘルスのインジケータになります。ビジネス・サービスに対するSLAアラート・ルールの定義の詳細は、『Oracle Service Busの管理』のサービス・レベル合意のアラート・ルールの作成に関する項を参照してください。
ビジネス・サービスは、Oracle Web Services Manager (OWSM)ポリシーや、トランスポート・レベルのアクセス制御など、複数の方法で保護できます。アウトバウンド・トランスポート・レベルのセキュリティは、プロキシ・サービスとビジネス・サービスのと間の接続に適用されます。OWSMは参照によってバインドされ、有効なWSDLファイル内にインライン化されません。OWSMでビジネス・サービスを保護する場合、ポリシーのオーバーライドも指定できます。
トランスポート・レベルのセキュリティの詳細は、「トランスポート・レベルのセキュリティの構成」を参照してください。ビジネス・サービスの保護の詳細は、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。
この項では、Oracle JDeveloperまたはOracle Service Busコンソールを使用して、ビジネス・サービスを作成する方法について説明します。Service Busアプリケーションおよびプロジェクトの作成の詳細は、「JDeveloperでのService Busアプリケーションおよびプロジェクトの作成」または「リソースの新しいプロジェクトおよびフォルダの作成方法」を参照してください。JDeveloperでのプロジェクト、アプリケーションおよびその他コンポーネントの操作については、『Oracle JDeveloperによるアプリケーションの開発』を参照してください。
ビジネス・サービスは、既存のサービス、JCAリソースまたはWSDLドキュメントからの生成など、様々な方法で作成できます。ビジネス・サービスを作成する場合、「ビジネス・サービスの作成」ウィザードには、ビジネス・サービスの特定のプロパティを構成できる一連のページが表示されます。この項では、「ビジネス・サービスの作成」ウィザードを使用してビジネス・サービスを作成する方法について説明します。Service Bus概要エディタの使用については、「JDeveloperでのOracle Service Busアプリケーションの開発」を参照してください。
始める前に:
SMTPサーバー、MQ接続、UDDIサーバーなどのシステム・リソースを使用する場合、ビジネス・サービスの作成を開始する前に、必ずこれらのリソースを作成します。ビジネス・サービスを構成するには、これらのリソースを指定または選択する必要があり、必要なリソースがService Busにないかぎり、ビジネス・サービスの構成を完了できません。
JDeveloperで作業する場合は、ビジネス・サービスの追加先のアプリケーションおよびプロジェクトを作成するか開きます。Oracle Service Busコンソールで作業する場合は、アクティブ・セッションで作業していることと、ビジネス・サービスの追加先のプロジェクトが存在することを確認します。
ビジネス・サービス・タイプの詳細は、「ビジネス・サービスの定義」を参照してください。
WSDLファイルの詳細は、「WSDLドキュメントの操作」を参照してください。
使用できる様々なトランスポートの詳細は、「JCAアダプタ、トランスポートおよびバインドの操作」を参照してください。
ロード・バランシングの詳細は、「ロード・バランシング・アルゴリズムについて」を参照してください。
ビジネス・サービスを作成するには、サービスを作成するためにService BusコンソールまたはJDeveloperのいずれを使用するかに応じて、次のいずれかのタスクを実行します。
リソース・ギャラリからアクセスできるビジネス・サービスの作成ウィザードを使用して、Service Busコンソールでビジネス・サービスを作成します。
ビジネス・サービス定義エディタに、新しいビジネス・サービスの全般構成が表示されます。
ネイティブRESTビジネス・サービスの作成ウィザードを使用して、ネイティブの型付きRESTビジネス・サービスを作成できます。このウィザードで、サービスのリソースおよびメソッドを指定します。ウィザードにより、サービスおよび使用可能なリソースとメソッドの詳細を記述するWADLファイルが作成されます。
型付きRESTサービスの詳細は、「Service BusにおけるRESTの実装」を参照してください。
コンソールでネイティブの型付きRESTビジネス・サービスを作成するには、次のようにします。
注意:
各サービスにはリソースが1つ以上必要です。
ヒント:
すでに追加されているリソースにリソースを子として追加するには、次の図に示すように、「リソースの追加」ボタンのかわりに、リソースの隣にある「追加」アイコンをクリックします。
図add_child_resource.pngの説明
ビジネス・サービスを作成した後、「ビジネス・サービスの構成」の説明に従ってビジネス・サービスを構成します。
注意:
各サービスにはリソースが1つ以上必要です。
ヒント:
すでに追加されているリソースにリソースを子として追加するには、次の図に示すように、「リソースの追加」ボタンのかわりに、リソースの隣にある「追加」アイコンをクリックします。
図add_child_resource.pngの説明
サービスを作成した後、「ビジネス・サービスの構成」の説明に従ってサービスを構成します。
ビジネス・サービスの作成ウィザードを使用して、WSDLファイルに基づくビジネス・サービス、トランスポートに基づくビジネス・サービスおよびネイティブの型なしRESTサービスを作成します。
ネイティブの型付きRESTビジネス・サービスとWSDLファイルに基づくRESTビジネス・サービスの作成方法は、「JDeveloperを使用したService Bus用の入力済RESTサービスの作成方法」および「JDeveloperを使用したService Bus用のWSDLベースRESTサービスの作成方法」を参照してください。
Service Busでは、アウトバウンドJCAバインド・リソースからビジネス・サービスを生成できます。Service Bus JCAトランスポートを使用するJCAサービスは、JCAアダプタ・フレームワークおよびJCA準拠アダプタを介してEnterprise Information Systems (EIS)と通信します。JCAバインド・リソースの詳細は、「JCAトランスポートとJCAアダプタの使用」を参照してください。
始める前に:
JDeveloperで、JCAファイル、その関連抽象WSDLファイルおよび必要なその他のリソース(TopLinkマッピング・ファイルなど)を作成します。詳細は、「JCAトランスポートとJCAアダプタの使用」および「テクノロジ・アダプタの理解」を参照してください。
注意:
アウトバウンドJCAバインドではなくインバウンドJCAバインドを選択する場合、ビジネス・サービスを生成するオプションは利用できません。
JDeveloperでは、JCAアダプタをService Bus概要エディタから作成する場合、アダプタの作成時にビジネス・サービスも生成できます。詳細は、「ビジネス・サービスの作成方法」を参照してください。
始める前に、JCAリソース・ファイルをJDeveloperからコンソールにインポートし、依存関係へのすべての参照が維持されるようにします。詳細は、「JCAバインド・リソースの操作」および「リソースおよび構成のインポートとエクスポート」を参照してください。
コンソールでJCAバインドからビジネス・サービスを生成するには:
JDeveloperでは、作成するプロキシ・サービスからビジネス・サービスを生成できます。ビジネス・サービスの構成は、プロキシ・サービスの構成に基づきます。
JDeveloperでプロキシ・サービスからビジネス・サービスを生成するには:
ビジネス・サービスを作成すると、構成の編集、セキュリティ・ポリシーの追加、セキュリティ設定の変更およびSLAアラート・ルールの設定を行うことができます。変更できる情報は、最初にサービスを構成した方法によって異なります。ビジネス・サービスに構成可能なすべてのプロパティのリストについては、ビジネス・サービス定義エディタの各ページで利用可能なオンライン・ヘルプを参照してください。
Oracle Service Busコンソールで作業する場合は、この項のタスクを実行する前に、アクティブ・セッションにいることを確認してください。
ビジネス・サービス定義エディタの「全般」タブには、サービスに関する情報(サービスの説明、サービスで使用されるトランスポート、サービス・タイプ、WSDLのポートまたはバインディングなど)が表示されます。このページでは、説明のみを変更できます。次の図に、Oracle Service Busコンソールの「全般」タブを示します。
ビジネス・サービスの全般情報を構成するには:
「トランスポート」ページと「トランスポートの詳細」ページを使用して、ビジネス・サービスのトランスポートを構成します。使用可能なプロパティはトランスポートごとに異なります。次の図に、Oracle Service Busコンソールの「トランスポート」タブを示します。
ビジネス・サービスのトランスポートを構成するには:
「メッセージ処理」ページで、ビジネス・サービスによるメッセージ・コンテンツの処理方法(MTOM/XOPサポート、添付ファイル、WS-I準拠の確認、使用するXQueryバージョンなど)を構成できます。次の図に、Oracle Service Busコンソールの「メッセージ処理」タブを示します。
ビジネス・サービスのメッセージ処理を構成するには:
メッセージ処理プロパティの詳細は、「ビジネス・サービスのメッセージ処理」を参照してください。
「パフォーマンス」タブで、結果キャッシュを構成して、ビジネス・サービスのパフォーマンスを改善できます。詳細は、「ビジネス・サービスの結果のキャッシュによるパフォーマンスの改善」を参照してください。手順については、「結果キャッシュのビジネス・サービスの構成方法」を参照してください。
ビジネス・サービスは、Oracle Web Services Manager (WSM)ポリシーや、トランスポート・レベルのアクセス制御など、複数の方法で保護できます。ビジネス・サービスの保護の詳細は、「ビジネス・サービスのセキュリティおよびセキュリティ・ポリシー」と「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。
頻繁に変更されることのない結果を返すビジネス・サービスを使用する場合、それらのビジネス・サービスが結果をキャッシュするよう構成できます。結果のキャッシュを有効にすると、サービスは、外部サービスを呼び出すのではなく、キャッシュから結果を返します。これにより、外部サービスにアクセスするネットワーク・オーバーヘッドが減り、パフォーマンスが向上します。結果キャッシュによって、外部サービスをホストするバックエンド・サービスの負荷が削減され、スケーラビリティの向上にもつながります。
この項で、結果キャッシュとは、すべてのビジネス・サービスで共有し、各結果を格納するキャッシュ自体のことで、キャッシュされた結果とは、結果キャッシュ内の各結果のことです。結果キャッシュを使用するビジネス・サービスでは、キャッシュされた結果の存続時間を制御できます。キャッシュされた結果の有効期限に達すると、次のビジネス・サービス・コールによってバックエンド・サービスが呼び出され、結果が取得されます。この結果はキャッシュに格納され、以降のアクセス・リクエストに使用されます。
Service Busで使用される結果キャッシュのメカニズムは、WebLogic Serverに含まれているOracle Coherenceです。Service Busの結果キャッシュの実装には、グロバールな有効化/無効化、キャッシュ・メッセージ変数、各ビジネス・サービスの構成フィールド、およびサービス統計、デバッグ、アラート・ルールに関するキャッシュ・オプションが含まれます。
図9-4に、ビジネス・サービスを呼び出し、キャッシュされた結果を含むレスポンスを受け取るクライアントを示します。
注意:
結果キャッシュは、リクエスト/レスポンス操作についてのみ機能します。
キャッシュされた各結果は、ServiceRef (完全修飾されたサービスのパス名であるサービスの一意の識別子)、呼び出される操作およびキャッシュ・トークン文字列で構成されるキャッシュ・キーによって一意に識別されます。キャッシュ・トークンは、あるビジネス・サービスの1つのキャッシュ結果を他のキャッシュ結果から一意に識別する場合に役立ちます。キャッシュ・トークンの値は制御されます。キャッシュ・トークンを設定するには、ビジネス・サービスの結果キャッシュ構成でキャッシュ・トークン式を構成するか、パイプラインを使用する$transportMetaDataでcache-tokenメタデータ要素を使用します。
ビジネス・サービスで、キャッシュ・キーを使用してキャッシュされた結果が特定されると、外部サービスを直接呼び出すかわりにキャッシュされた結果がクライアントに返されます。
図9-4で、実線の矢印は、クライアントとキャッシュされた結果とのメッセージ・パスを表します。点線の矢印は、キャッシュされた結果がない場合のメッセージ・パスを表します。キャッシュされた結果がない場合、ビジネス・サービスは外部サービスを直接呼出し、結果をクライアントに返して、結果をキャッシュに格納します。初めての呼出しでキャッシュがまだない、キャッシュのエラー、キャッシュがフラッシュされたなどの様々な理由から、結果キャッシュが空の場合があります。
キャッシュされた結果には、キャッシュの有効期限として存続時間(TTL)属性があります。キャッシュの有効期限は、ビジネス・サービスの結果キャッシュ構成の「有効期限」プロパティまたはパイプラインを使用する$transportMetaDataでcache-ttl要素を使用して構成できます。CoherenceでTTLの期限が過ぎていることが検出されると、キャッシュがフラッシュされ、ビジネス・サービスによって外部サービスが呼び出されて結果が取得されます。結果はキャッシュに格納され(結果にエラーがない場合)、次のリクエストで返すことができるようになります。
Service BusをCoherenceとともに使用すると、キャッシュされた個々の結果、1つのビジネス・サービスについてキャッシュされたすべての結果または結果キャッシュ全体(すべてのビジネス・サービスについてキャッシュされたすべての結果)をフラッシュできます。次のイベントは、キャッシュがどのようにフラッシュされるかについて示しています。
キャッシュのTTLの期限は過ぎています。キャッシュされたそれぞれの結果には独自のTTLがあります。TTLに達すると、Coherenceによってキャッシュされた個々の結果がフラッシュされます。
1つのビジネス・サービスに関する結果キャッシュを無効にします。1つのビジネス・サービスに関する結果キャッシュを無効にすると、Service Busでは、そのビジネス・サービスについてキャッシュされたすべての結果がCoherenceでフラッシュされます。
ビジネス・サービスの更新、名前変更または削除を行います。これらのアクションによって、そのビジネス・サービスについてキャッシュされたすべての結果のCoherenceからのフラッシュがトリガーされます。
従属するリソースを更新します。WSDLドキュメントなど、従属するリソースを更新すると、そのビジネス・サービスについてキャッシュされたすべての結果のCoherenceからのフラッシュがトリガーされます。ただし、サービス・プロバイダ、UDDIレジストリ、アラート宛先といった従属リソースに対する変更ではキャッシュはフラッシュされません。
結果キャッシュをグローバルに無効化します。結果キャッシュをグローバルに無効にすると、結果キャッシュ全体(すべてのビジネス・サービスについてキャッシュされたすべての結果)のCoherenceからのフラッシュがトリガーされます。
キャッシュされた結果によって外部サービスは直接呼び出されなくなるため、静的でないサービス・アカウントまたはWS-Securityポリシーにセキュリティを提供するビジネスサービスには、結果キャッシュを使用しないでください。本番で結果キャッシュを使用するService Bus環境をデプロイする前に、『Oracle Coherenceでのアプリケーションの開発』の説明に従い、Coherenceの設定と構成の計画および実装を行って最適なパフォーマンスが得られるようにする必要があります。
結果キャッシュでは、キャッシュ・キーを使用して、キャッシュされた結果を識別し、有効期限を使用して、キャッシュされた結果をフラッシュするタイミングを判断します。
Service Busでは、キャッシュ・キーを使用して取得または移入するキャッシュ結果を識別し、キャッシュ・キーのキャッシュ・トークン部分は一意の識別子として使用されます。式(キャッシュ・トークン式)を使用して、ビジネス・サービスのキャッシュされた結果を一意に識別するキャッシュ・キーのキャッシュ・トークン部分を生成できます。リクエスト(ビジネス・サービスを起動するパイプラインまたは分割-結合内)の値からキャッシュ・トークンを生成する場合、パイプライン$body、$header、$operationまたは$transportMetaData ($outbound/ctx:transport/ctx:requestまたは$outbound/ctx:transport/ctx:response)から値を取得する式を使用します。たとえば、メッセージ$body内の顧客IDからcache-tokenに移入できます。
キャッシュ・トークン式は、文字列または、属性や子要素のない要素などの単純な内容に解決される必要があります。式がNULLに評価されるか、エラーが発生すると、結果はキャッシュされません。ビジネス・サービス構成でキャッシュ・トークン式を設定せずに、リクエストからキャッシュ・トークンを生成することもできます。これを行うには、パイプラインの$outbound/ctx:transport/ctx:request/ctx:cache-tokenに値を含めます。このcache-tokenの値は、ビジネス・サービス構成のキャッシュ・トークン式をオーバーライドします。
有効期限すなわち存続時間(TTL)は、ビジネス・サービスの結果キャッシュのエントリがいつフラッシュされるかを決定します。デフォルトの有効期限を使用して、結果キャッシュがフラッシュされるまでの期間を制限するか、リクエストまたはレスポンスの値から有効期限を生成する式を定義できます。デフォルトの有効期限は、resultcache.garのosb-coherence-cache-config.xmlファイルにあるexpiry-delayの値で定義されます。期間は、ビジネス・サービス構成で直接定義できます。
リクエストまたはレスポンス内の値から有効期限を生成するには、パイプラインまたは分割-結合$body、$header、$operationまたは$transportMetaData ($outbound/ctx:transport/ctx:requestまたは$outbound/ctx:transport/ctx:response)から値を取得する式を使用します。たとえば、Cache-Control HTTPヘッダーに設定した値を使用します。
有効期限は、整数(秒数を表す)、XQuery dayTimeDuration (XSDタイプ)または属性や子要素のない要素など、秒を表す単純な内容の整数値に解決される必要があります。式がNULLに評価されるか、エラーが発生すると、結果はキャッシュされません。
ビジネス・サービス構成で有効期限を設定しなくても、リクエストから有効期限を生成することもできます。これを行うには、パイプラインまたは分割-結合の$outbound/ctx:transport/ctx:request/ctx:cache-ttlに値を含めます。このcache-ttl要素の値が、ビジネス・サービス構成の有効期限をオーバーライドします。
結果キャッシュに使用されるリクエスト・メタデータには、cache-tokenおよびcache-ttl (両方とも文字列値)が含まれます。両方ともビジネス・サービス構成で構成できます。ビジネス・サービスでキャッシュ・トークンまたはTTLを未定義のままにすることも、リクエストでキャッシュ・トークンまたはTTLにこれらのメタデータを指定することもできます。リクエストでキャッシュ・トークンまたはTTLを設定すると、これらの値によって、ビジネス・サービス構成で定義されたキャッシュ・トークンまたはTTLがオーバーライドされます。
式(キャッシュ・トークン式またはTTL、あるいはその両方)を使用して結果キャッシュを構成する場合、式で使用するネームスペースと対応する接頭辞を入力できます。このフィールドでは、既存のネームスペースのリストを表示することもできます。
結果キャッシュは、結果キャッシュが構成されているビジネス・サービスが、パイプラインまたは分割-結合から(ルートまたはサービス・コールアウト・アクティビティなどを使用して)呼び出された場合のみ有効です。したがって、結果キャッシュをテストする場合、ビジネス・サービスをテスト・コンソールから直接起動しないでください。かわりに、テスト・コンソールを使用して、ビジネス・サービスを呼び出すパイプラインまたは分割-結合をテストします。
いくつかの変更が結果に含まれるビジネス・サービスを呼び出す場合は、結果キャッシュを使用すると、ビジネス・サービスのパフォーマンスが向上します。外部サービスを直接呼び出すかわりにキャッシュした結果をクライアントに返すためです。ビジネス・サービスの結果キャッシュは、Oracle Service Busコンソールでのみ構成できます。
キャッシュ・トークン式と有効期限式のどちらの場合も、式エディタを使用して式を定義します。式エディタの操作の詳細は、「XQueryでのデータの変換」を参照してください。次のイメージは、結果キャッシュを構成するOracle Service Busコンソールの「パフォーマンス」タブを示します。
結果キャッシュを構成するには:
各Service Busドメインで、ドメインがビジネス・サービスの結果キャッシュに対してCoherenceを使用する方法を変更できます。Service Busでは、MW_HOME/osb/lib/appsにある2つのファイル、resultcache.garとresultcache.earを指定することにより、ドメイン内のサーバーに対して、自身のデフォルトのCoherence構成を指定します。GARファイルは、結果キャッシュで使用するCoherenceキャッシュを定義します。結果キャッシュを設定するには、resultcache.garをWebLogic Serverにデプロイし、キャッシュが対象となるサーバーまたはクラスタを指定します。その後、コンソール(またはお好みでWLSTコマンド)を使用して、キャッシュを構成できます。
GARファイルにはデフォルトのキャッシュ構成が埋め込まれています。GARファイルからosb-coherence-cache-config.xmlを抽出し、必要に応じてプロパティを変更することにより、キャッシュの独自の構成を定義できます。デフォルトでは、結果キャッシュには、分散キャッシュ・スキームが使用されます。詳細は、『Oracle Coherenceでのアプリケーションの開発』のキャッシュ構成の要素に関する項を参照してください。
異なるキャッシュ構成を使用するには、WebLogic Server管理コンソールでCoherenceクラスタの新しいキャッシュ構成を作成する必要があります。キャッシュ構成の名前は/osb/service/ResultCache、JNDI名はservicebus/result-cacheとし、Service Busで使用されているものと同じCoherenceクラスタに配置する必要があります。ドメイン内の様々なサーバーで、1つの異なる構成を使用できます。
Coherenceのキャッシュ・アクセスをローカル・サーバーのみに限定するため、ユニキャスト設定を構成できます。この構成では、別のサーバーで起動されたノードは、同じCoherenceクラスタに参加してキャッシュされた情報を共有することはありません。かわりに、マルチキャスト値を構成して、同じテンプレートから作成された同じサブネット上の任意のWebLogic Serverノードによって共有されるCoherenceクラスタを作成できます。これらのプロパティは、WebLogic Server管理コンソールのCoherenceクラスタの「一般構成」タブで構成します。
Coherenceクラスタのノードの明示的なリストを持つユニキャスト・リスナーを使用するようにCoherenceクラスタを構成することをお薦めします。マルチキャストおよびユニキャストのプロパティについては、WebLogic Serverに付属のオンライン・ヘルプを参照してください。『Oracle Coherenceでのアプリケーションの開発』の既知のアドレスの使用に関する項も参照してください。
システム・プロパティを使用したオーバーライドを指定できます。複数のサーバーでCoherenceクラスタを正しく共有するようにCoherenceクラスタを構成する場合は、次のガイドラインに従ってください。
クラスタ内でマルチキャスト・リスナーからユニキャスト・リスナーに切り替える場合は、既知のアドレスを構成します。
同一サブネット内に複数のWebLogic Serverクラスタがある場合、Coherenceクラスタを正しく共有するように、関係のあるCoherenceアドレスとポートのプロパティを変更します。WebLogic Serverクラスタに使用されるのと同じアドレスとポートを使用しないでください。
同一サブネット内に管理対象サーバーを持つ複数の管理サーバーがある場合、Coherenceクラスタを正しく共有するように、関係のあるCoherenceアドレスとポートのプロパティを変更します。
同一サブネット内にWebLogic Serverクラスタと管理対象サーバーを持つ管理サーバーの組合せがある場合、Coherenceクラスタを正しく共有するように、関係のあるCoherenceアドレスとポートのプロパティを変更します。
同一サブネット内に複数のCoherenceクラスタが稼働している場合、マルチキャスト・アドレスとマルチキャスト・ポートを変更して、ノードが接続する必要のあるCoherenceクラスタを指定します。
Service Busで完全にCoherenceが使用されないようにするには、次の手順を実行します。
resultcache.ear)をアンデプロイします。次の図に、プロセス外Coherenceサーバーを示します。
この例には、2つのWebLogic Serverクラスタがあります。1番目のWebLogic Serverクラスタには、管理対象サーバー1および2が含まれ、次のようになっています。
Service Bus実行中
Service Bus結果キャッシュのエンタープライズ・アプリケーションがデプロイ済(resultcache.ear)
記憶域が無効
2番目のWebLogic Serverクラスタには、管理対象サーバー3および4が含まれ、次のようになっています。
Service Bus結果キャッシュのグリッド・アーカイブがデプロイ済(resultcache.gar)
記憶域が有効
キャッシュされたすべてのエントリは、管理対象サーバー3および4に保存されます。
Service Busで結果キャッシュを頻繁に使用し、結果キャッシュ用にヒープ領域を使用しすぎないようにする場合、Service BusのドメインJVMを共有するのではなく、独自のJVMを実行するようにCoherenceキャッシュ・サーバーを設定できます。Coherenceキャッシュ・サーバーをService Bus JVMの外部(プロセス外)で実行すると、Service Busでメッセージの処理に使用されるヒープ領域に影響なく、Coherenceキャッシュ・サーバーで独自のヒープ領域を使用できます。
注意:
Service Busとともに使用されるすべてのプロセス外Coherenceキャッシュ・サーバーでは、Service Busに含まれているバージョンと同バージョンのCoherenceを使用する必要があります。
プロセス外Coherenceキャッシュ・サーバーを作成するには:
MW_HOME/osb/lib/apps/resultcache.garファイルをデプロイします。 