この章では、WSDLの構造と使用、サービスのタイプとトランスポート、Oracle Coherenceを使用したビジネス・サービス結果キャッシュを含むOracle Service Busのビジネス・サービスとプロキシ・サービスの構成の側面を説明します。
Oracle Service Busのプロキシ・サービスとビジネス・サービスを使用すると、サービスの管理、メッセージの変換、およびエンタープライズ全体でのメッセージのルーティングを行うことができます。
プロキシ・サービスとビジネス・サービスは、実行時環境(Oracle Service Bus管理コンソール)または開発環境(Oracle Service Busプラグインを使用するEclipse)を使用して作成および構成できます。既存のWeb Services Description Language(WSDL)リソース(Oracle Service RegistryなどのUDDIレジストリからインポートされたリソースなど)に基づいてプロキシ・サービスまたはビジネス・サービスを作成した後に、Oracle Service Bus管理コンソールまたはプラグインでさらに構成することができます。
この章の内容は次のとおりです。
Oracle Service Busプロキシ・サービスとは、Oracle Service Busがローカルに実装しホストする仲介Webサービスの定義です。Oracle Service Busでは、プロキシ・サービスを使用してビジネス・サービス(エンタープライズWebサービスやデータベースなど)とサービス・クライアント(プレゼンテーション・アプリケーションやその他のビジネス・サービスなど)との間でメッセージをルーティングします。
プロキシ・サービスの構成には、インタフェース、トランスポート設定、セキュリティ設定、およびメッセージ・フロー定義が含まれます。メッセージ・フロー定義では、プロキシ・サービスを介したメッセージ・フローでメッセージを処理する方法を決定するロジックを定義します。プロキシ・サービスがWSDLドキュメントに基づいている場合、構成にはWSDLポートまたはWSDLバインディングも含まれます(36.4項「WSDLを使用したサービスの定義」を参照)。
Oracle Service Busビジネス・サービスは、Oracle Service BusがクライアントとなるエンタープライズWebサービスの定義です。これらの外部Webサービスは、外部システムに実装され、外部システムによってホストされます。そのため、Oracle Service Busは呼び出す対象、呼び出す方法、および呼出しの結果として予想される内容を認識しておく必要があります。Oracle Service Busが外部サービスを呼び出すことができるように、Oracle Service Busビジネス・サービスではそのインタフェースをモデル化しています。
ビジネス・サービスの構成には、インタフェース、トランスポート設定、およびセキュリティ 設定が含まれます(メッセージ・フロー定義は含まれません)。ビジネス・サービスがWSDLに基づいている場合、構成にはWSDLポートまたはWSDLバインディングも含まれます(36.4項「WSDLを使用したサービスの定義」を参照)。
Oracle Service Busでは、WSDL (Webサービスを記述するためのXMLベースの仕様)を使用して、複数のタイプのビジネス・サービスとプロキシ・サービスを定義します。WSDLドキュメントには、サービス操作、入力/出力パラメータ、およびクライアントがサービスに接続する方法が記述されます。WSDL 1.1仕様については、W3C Noteの『W3C Web Services Description Language (WSDL) 1.1』(http://www.w3.org/TR/wsdl
)を参照してください。
Oracle Service Busでは、「WSDLリソース」と呼ばれる既存のWSDLに基づいて新しいプロキシ・サービスまたは新しいビジネス・サービスを作成し、構成プロパティをオーバーライドしたり追加したりできます。また、既存のWSDLに基づいていない新しいサービスを作成または構成することもできます。
WSDLベースのサービスの場合、Oracle Service Busは実際の.wsdlファイルのかわりに有効なWSDLを使用します。有効なWSDLとは、Oracle Service Busで構成されたサービスのWSDLプロパティです。
ソースWSDLは有効なWSDLのテンプレートとして機能します。WSDLに基づいてサービスを作成すると、Oracle Service Busは元のWSDLの設定、ユーザーが設定したトランスポート構成の設定、およびユーザーが元のWSDLで追加または変更したその他の構成設定を組み合せて、有効なWSDLを生成します。新しい構成で使用しない元のWSDLの設定は、有効なWSDLから除外されます。
Oracle Service Busでは、次のタイプのプロキシ・サービスおよびビジネス・サービスの有効なWSDLを生成できます。
WSDLから作成されたSOAPサービス
WSDLから作成されたXMLサービス
WSDLベースのサービスをサポートするトランスポート(HTTP、JMS、SBなど)を使用して、これらのタイプのサービスの有効なWSDLを生成できます。
Oracle Service Busでは、次のタイプのプロキシ・サービスおよびビジネス・サービスの有効なWSDLを生成できません。
任意のSOAP
任意のXML
メッセージング・タイプのサービス
有効なWSDLは、プロキシ・サービスとビジネス・サービス、およびWSDLポートに基づくサービスとWSDLバインディングに基づくサービスの様々な特性を備えています。これらの特性については、このドキュメント全体を通じて説明しています。特に、36.5項「WSDLポートとWSDLバインディングに基づくサービスの作成」を参照してください。
生成されたWSDLとは、WSDLリソースから作成されてはいないが、WSDLを使用して記述できるトランスポート型サービス用にOracle Service Busが生成する有効なWSDLです。たとえば、EJBベースのサービスから生成されたWSDLは「生成されたWSDL」です。
有効なWSDLには、次の3とおりの方法でアクセスできます。
Webブラウザで、HTTPベースのプロキシ・サービスのURLの末尾に?WSDL
を付加して入力します。
この方法は、Oracle Service Busが有効なWSDLを生成できるHTTPトランスポート・ベースのサービスでのみ使用できます。
Webブラウザで、固定されたHTTP URLを入力します。例:
http://host:port/sbresource?PROXY/project_path/proxy_service_name
または
http://host:port/sbresource?BIZ/project_path/business_service_name
この方法は、Oracle Service Busが有効なWSDLを生成できるサービスすべてに使用できます。
管理コンソールまたはプラグインからWSDLをエクスポートします。次を参照してください。
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の有効なWSDLの生成に関する項を参照してください。
WSDLをエクスポートすると、有効なWSDLおよび関連付けられた依存関係(スキーマやWS-Policyなど)を含む.zipファイルが生成されます。Oracle Service Busはこの依存関係を評価し、WSDLのimport
要素のlocation
属性に適切な場所が追加されます。
WS-Policyのimport
要素はありません。WS-Policyでは、ポリシー参照が保持され、エクスポート時にポリシー・リソースが含まれます。
生成されたWSDLをエクスポートすることはできません。
URLを使用したOracle Service Busリソースへのアクセスの詳細は、4.30項「Webブラウザでのリソースの表示」を参照してください。
WSDLドキュメントでは、サービス、サービスの場所、サービス操作、およびクライアントがサービスと通信する方法を記述します。この項では、Oracle Service Busの機能を説明する際のコンテキストを提供するために、WSDLの概要を簡単に説明します。
表36-1に、WSDLサービスの定義に使用する主な要素を示します。
表36-1 上位のWSDL要素
要素 | 説明 |
---|---|
<types> |
メッセージ・コンテンツの型定義。 |
<message> |
やり取りされるデータの抽象的な定義。メッセージはパートで構成され、パートはメッセージの理論上抽象的な内容を表します。 |
<portType> |
サービスでサポートされる操作の抽象的な集合。 |
<operation> |
サービスでサポートされるアクションの抽象的な説明。 |
<binding> |
ポート・タイプの具体的なプロトコルとデータ形式の指定。 |
<port> |
ネットワーク・アドレスとバインディングで構成される単一のエンドポイント。 |
<service> |
関連するポートまたはエンドポイントの集合。 |
WSDLでは、SOAP、HTTP、MIME、およびOracle Service Bus固有のバインディング拡張が指定されます。これらのバインディング拡張では、WSDLバインディング・メカニズムを拡張することで、プロトコル固有またはメッセージ・フォーマット固有の機能をサポートします。
<types>
要素は、データ型定義のコンテナです。この要素では、XMLスキーマ(XSD)などの型システムを使用して、このサービスで処理されるメッセージのボキャブラリを定義します。たとえば、株価を提供するサービスの場合、例36-1に示すように、TradePriceRequest
およびTradePrice
という用語によってXMLボキャブラリを定義できます。
例36-1 WSDLの型の例
<types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types>
<message>
要素は、通信されるデータの抽象的な型付き定義です。メッセージはパートで構成され、各パートは、メッセージの1つの論理抽象単位を表します。WSDLでは、1つ以上のメッセージを定義でき、各メッセージには1つ以上のパートを含めることができます。たとえば、例36-2のWSDLフラグメントでは、sellerInfoMessage
、buyerInfoMessage
、response
およびnegotiationMessage
の4つのメッセージ・タイプが定義されており、各メッセージ・タイプには1つ以上のパートが含まれています。
例36-2 WSDLメッセージの例
<message name="sellerInfoMessage"> <part name="inventoryItem" type="xsd:string"/> <part name="askingPrice" type="xsd:integer"/> </message> <message name="buyerInfoMessage"> <part name="item" type="xsd:string"/> <part name="offer" type="xsd:integer"/> </message> <message name="response"> <part name="result" type="xsd:string"/> </message> <message name="negotiationMessage"> <part name="item" type="xsd:string"/> <part name="price" type="xsd:integer"/> <part name="outcome" type="xsd:string"/> </message>
<portType>
要素では、(<port>
要素で定義された)1つ以上のエンドポイントがサポートする一連の操作を定義します。ポート・タイプは、サービスが提供する操作のパブリック・インタフェースを提供します。各操作は、サービスがサポートするアクションの抽象的な記述である<operation>
要素で定義されます。
たとえば、例36-3のフラグメントでは、入力メッセージ(GetLastTradePriceInput
)と出力メッセージ(GetLastTradePriceOuput
)を処理できるGetLastTradePrice
という1つの操作でポート・タイプが定義されています。例36-4の<soap:operation>
下位要素に示すように、これらのメッセージの具体的な記述はWSDLバインディングで定義されています。
<binding>
要素では、ポート・タイプの具体的なデータ・フォーマット仕様と具体的な転送プロトコルを指定します。
例36-4のフラグメントでは、type
属性の値として示されたStockQuotePortType
ポート・タイプのバインディングを指定しています。<soap:binding>
下位要素は、このバインディングがSOAPプロトコル形式にバインドされることを示します。この下位要素では、style
属性でデータ・フォーマットがSOAPドキュメント・スタイルであることを指定し、transport
属性で転送プロトコルがHTTPであることを指定しています。
例36-4 WSDLのバインディングの例
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice"> <soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>
<service>
要素では、関連するエンドポイントの集合を定義します。各エンドポイントは、<port>
子要素で定義されます。ポートでは、ネットワーク・アドレスに関連付けられたバインディングを定義します。たとえば、例36-5のフラグメントでは、StockQuotePort
とStockQuotePortUK
の2つのポートが定義されています。この2つのポートは、(<binding>
で具体的に定義された)tns:StockQuoteSoapBinding
という同じバインディングを使用していますが、ネットワーク・アドレスは異なります(http://example.com/stockquote
とhttp://example.uk/stockquote
)。これらのポートは、このサービスで使用できる代替ポートです。
例36-5 WSDLのサービスとポートの例
<service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding"> <soap:address location="http://example.com:9999/stockquote"/> </port> <port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding"> <soap:address location="http://example.uk:9999/stockquote"/> </port> </service>
サービスでWSDLインタフェースが明確に定義されている場合、WSDLを使用してサービスを定義することをお薦めします。ただし、これは必須ではありません。
3タイプのWSDLを定義できます。次のとおりです。
ドキュメント・ラップのWebサービスは、ドキュメント・スタイルのサービスとしてWSDLに記述されています。ただし、いくつかの追加規約に従います。標準のドキュメント指向のWebサービス操作では、1つのパラメータまたはメッセージ部分だけを取得します(通常は、XMLドキュメントを取得します)。つまり、操作を実装するメソッドに含まれるパラメータも1つだけである必要があります。これに対して、ドキュメント・ラップのWebサービス操作では、パラメータをいくつでも取得できます。パラメータ値は、SOAPメッセージ内の1つの複合データ型にラップされます。このラップされた複合データ型は、操作の1つのドキュメントとしてWSDLに記述されます。
プロキシ・サービスをSOAPスタイルのプロキシ・サービスとして構成し、ビジネス・サービスをSOAPスタイルのビジネス・サービスとして構成することができます。
例36-6に、SOAP 1.1を使用するドキュメント・スタイルのWebサービスのWSDLの例を示します。
例36-6 ドキュメント・スタイルのサンプルWebサービスのWSDL
<definitions name="Lookup" targetNamespace="http://example.com/lookup/service/defs" xmlns:tns="http://example.com/lookup/service/defs" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:docs="http://example.com/lookup/docs" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <xs:schema targetNamespace="http://example.com/lookup/docs" elementFormDefault="qualified"> <xs:element name="PurchaseOrg" type="xs:string"/> <xs:element name="LegacyBoolean" type="xs:boolean"/> </xs:schema> </types> <message name="lookupReq"> <part name="request" element="docs:purchaseorg"/> </message> <message name="lookupResp"> <part name="result" element="docs:legacyboolean"/> </message> <portType name="LookupPortType"> <operation name="lookup"> <input message="tns:lookupReq"/> <output message="tns:lookupResp"/> </operation> </portType> <binding name="LookupBinding" type="tns:lookupPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="lookup"> <soap:operation/> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> </definitions>
このサービスには、lookup
という操作(Javaクラスのメソッドに相当)が含まれています。バインディングは、これがSOAP 1.1ドキュメント・スタイルWebサービスであることを示しています。
前述のWSDLをリクエストに使用したときに、ドキュメント・スタイルのプロキシ・サービスが取得するbody変数($body
)の値を例36-7に示します。
注意: わかりやすくするために、次のコード・リストではXMLからネームスペース宣言を削除しています。 |
例36-7 body変数の値
<soap-env:body> <req:purchaseorg>Oracle</req:purchaseorg> </soap-env:body>
例36-7では、soap-env
は定義済のSOAP 1.1ネームスペースで、req
はPurchaseOrg
要素のネームスペース(http://example.com/lookup/docs
)です。
プロキシ・サービスによるルーティング先となるビジネス・サービスで前述のWSDLを使用した場合、前述のbody変数($body
)の値はプロキシ・サービスのbody変数($body
)の値になります。
呼び出されたビジネス・サービスからプロキシ・サービスが受信するレスポンスのbody変数($body
)の値を例36-8に示します。
注意: わかりやすくするために、次のコード・リストではXMLからネームスペース宣言を削除しています。 |
例36-8 body変数の値
<soap-env:body> <req:legacyboolean>true</req:legacyboolean> </soap-env:body>
これは、このWSDLを使用するプロキシ・サービスによって返されるレスポンスのbody変数($body
)の値でもあります。
Oracle Service Busプラグインを使用するEclipseをはじめとする多くのツールでは、プロキシ・サービスのWSDL(ブラウザで、プロキシ・サービスのURLに?WSDL
接尾辞を追加することによって取得)を受け取り、適切なリクエスト・パラメータとレスポンス・パラメータを持つJavaクラスを生成して、サービスの操作を呼び出します。このJavaクラスを使用して、このWSDLを使用するプロキシ・サービスを呼び出すことができます。
プロキシ・サービスをRPCスタイルのプロキシ・サービスとして構成し、ビジネス・サービスをRPCスタイルのビジネス・サービスとして構成することができます。
例36-9に、SOAP 1.1を使用するRPCスタイルのWebサービスのWSDLの例を示します。
例36-9 RPCスタイルのサンプルWebサービスのWSDL
<definitions name="Lookup" targetNamespace="http://example.com/lookup/service/defs" xmlns:tns="http://example.com/lookup/service/defs" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:docs="http://example.com/lookup/docs" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <xs:schema targetNamespace="http://example.com/lookup/docs" elementFormDefault="qualified"> <xs:complexType name="RequestDoc"> <xs:sequence> <xs:element name="PurchaseOrg" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:complexType name="ResponseDoc"> <xs:sequence> <xs:element name="LegacyBoolean" type="xs:boolean"/> </xs:sequence> </xs:complexType> </xs:schema> </types> <message name="lookupReq"> <part name="request" type="docs: RequestDoc"/> </message> <message name="lookupResp"> <part name="result" type="docs: ResponseDoc"/> </message> <portType name="LookupPortType"> <operation name="lookup"> <input message="tns:lookupReq"/> <output message="tns:lookupResp"/> </operation> </portType> <binding name="LookupBinding" type="tns:lookupPortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="lookup"> <soap:operation/> <input> <soap:body use="literal" namespace="http://example.com/lookup/service"/> </input> <output> <soap:body use="literal" namespace="http://example.com/lookup/service"/> </output> </operation> </binding> </definitions>
前述のサービスには、lookup
という操作(Javaクラスのメソッドに相当)が含まれています。バインディングは、これがSOAP RPC Webサービスであることを示しています。つまり、このWebサービスの操作では、一連のリクエスト・パラメータを受け取り、一連のレスポンス・パラメータを返します。lookup
操作には、request
というパラメータとresult
という戻りパラメータがあります。バインディングにおける操作のネームスペースは次のとおりです。
http://example.com/lookup/service/defs
例36-9のWSDLをリクエストに使用したときに、SOAP RPCプロキシ・サービスが取得するbody変数($body
)の値を例36-10に示します。
注意: わかりやすくするために、次のコード・リストではXMLからネームスペース宣言を削除しています。 |
例36-10 body変数の値
<soap-env:body> <ns:lookup> <request> <req:purchaseorg>Oracle</req:purchaseorg> </request> </ns:lookup> <soap-env:body>
ここで、soap-env
は定義済のSOAP 1.1ネームスペース、ns
は操作のネームスペース(<http://example.com/lookup/service>
)、req
はPurchaseOrg
要素のネームスペース(http://example.com/lookup/docs
)です。
プロキシ・サービスによるメッセージのルーティング先となるビジネス・サービスで例36-10のWSDLを使用した場合、例36-11に示すbody変数($body
)の値は、プロキシ・サービスのbody変数($body
)の値になります。
このWSDLがリクエストに使用された場合に呼び出されたビジネス・サービスからプロキシ・サービスが受信するレスポンスのbody変数($body
)の値を例36-10に示します。
例36-11 body変数の値
<soap-env:body> <ns:lookupResponse> <result> <req:legacyboolean>true</req:legacyboolean> </result> </ns:lookupResponse> <soap-env:body>
これは、このWSDLを使用するプロキシ・サービスによって返されるレスポンスのbody変数($body
)の値でもあります。
Oracle Service Busプラグインを使用するEclipseをはじめとする多くのツールでは、プロキシ・サービスのWSDL(ブラウザで、プロキシのURLに?WSDL
接尾辞を追加することによって取得)を受け取り、適切なリクエスト・パラメータとレスポンス・パラメータを持つJavaクラスを生成して、そのサービスの操作を呼び出します。このようなJavaクラスを使用して、このWSDLを使用するプロキシ・サービスを呼び出すことができます。
WSDLを使用する利点は次のとおりです。
システムでWSDLの各操作のメトリックを提供できます。
パイプラインで操作ブランチが可能になります。詳細は、37.2項「メッセージ・フローの分岐」を参照してください。
SOAP 1.1サービスの場合、プロキシ・サービスが呼び出すサービスにSOAPAction
ヘッダーが自動的に作成されます。SOAP 1.2サービスの場合、プロキシ・サービスが呼び出すサービスにContent-Type
ヘッダーのaction
パラメータが自動的に作成されます。
WS-Securityを使用するサービスにはWSDLが必要です。WS-PolicyはWSDLに添付されます。
システムが<url>?WSDL
構文をサポートしているため、HTTPプロキシ・サービスのWSDLを動的に取得できます。この機能は、Oracle Service Busプラグインを使用するEclipseをはじめとする多くのSOAPクライアント生成ツールで役立ちます。詳細は、4.30項「Webブラウザでのリソースの表示」を参照してください。
XQueryエディタ、XPathエディタ、および条件ビルダーでは、プロキシ・サービスのWSDLのリクエスト・メッセージにbodyコンテンツ変数($body
)がデフォルトでマップされるため、$body
の操作が容易になります。第39章「メッセージ・コンテキスト」を参照してください。
特定のアクションにおける$body
の実行時のコンテンツが、エディタに表示されるデフォルト・マッピングと異なる場合があります。これは、Oracle Service Busが型付きの変数を宣言して使用するプログラミング言語ではないためです。変数は型なしであり、値が割り当てられると実行時に動的に作成されます。また、変数の型は、メッセージ・フローの任意の位置でコンテンツに基づく型になります。XQuery式およびXPath式を容易に作成できるように、設計時エディタでは、指定した変数を型にマップすることによって、その変数の型をマップできます。XQueryエディタおよびXPathエディタを使用して式を作成する方法については、37.11項「変数の構造での作業」を参照してください。
WSDLリソースに基づいてサービスを作成する場合、サービスは次のようにWSDLポートまたはWSDLバインディングに基づいている必要があります。
WSDLリソースのバインディングに基づいて新しいサービスを作成する場合は、WSDLリソースで選択した<binding>
要素で定義されているプロトコルとデータ・フォーマットを選択します。
WSDLリソースのポートに基づいて新しいサービスを作成する場合は、<port>
要素で定義されているバインディングとネットワーク・アドレスを選択します。
サービスを作成または変更するときに、トランスポート方式は変更できますが、データ・フォーマットをオーバーライドすることはできません。
元のWSDLリソースのポート定義とバインディング定義は、次に説明する様々な要因に応じて有効なWSDL内で変更されます。
プロキシ・サービス用に生成される有効なWSDLには、次の特性があります。
有効なWSDLに含まれるwsdl:service
セクションは1つのみです。
wsdl:service
セクションに含まれるwsdl:port
セクションは1つのみです。
SOAPサービスの場合、既存の<wsdl:service>
定義が削除され、<wsdl:port>
が1つ含まれた新しいサービス定義が作成されます。
サポートされているすべてのトランスポートのSOAPバインディングでは、wsdl:binding
セクションに標準のWSDL SOAPバインディング要素と、トランスポートを識別する一意のトランスポートURIが含まれます。
XML over HTTPバインディングでは、wsdl:binding
セクションでWSDL 1.1仕様で指定された標準のバインディング要素が使用されます。
サポートされている他のすべてのトランスポートのXMLバインディングでは、wsdl:binding
セクションでOracle (Oracle Service Bus)独自のWSDL XMLバインディング要素が使用されます。
サービスがバインディングに基づいている場合
WSDLリソースのバインディングYからサービスが生成されると、有効なWSDLで新しいサービスとポート(<bindingname>QSService
と<bindingname>QSPort
)が定義されます。WSDLリソースで定義されているポートは、有効なWSDLには含まれません。
そのバインディングに関連付けられたWSDLに複数のポートが含まれている場合があります。ポートごとに異なるURLを使用できます。そのため、有効なWSDLではこのバインディングが使用されますが、バインディングに対応するサービスの構成から代用ポートが生成されます。他のポートはすべて削除されます。
サービスがポートに基づいている場合
WSDLリソースのポートXからサービスが生成されると、有効なWSDLでもポートXが定義されます。WSDLリソースで定義されているその他のポートは含まれません。また、WSDLポートに基づいてプロキシ・サービスを作成した場合、有効なWSDLではそのポート名が使用されます。バインディングはポートから決定され、ポート・タイプはバインディングから決定されます。
有効なWSDLには、WSDLリソースで定義されているポートに関連付けられたすべてのWS-Policyが保持されます。
WSDLリソースのポート定義で指定されているトランスポート・アドレスは、有効なWSDLでプロキシ・サービスのアドレスとしては使用されません。
HTTPサービスでは、管理コンソールまたはプラグインでトランスポートを構成するときに、トランスポート・アドレスを指定する必要があります。このアドレスが有効なWSDLのポート定義で使用されます。
Oracle Service Busは常にプロキシ・サービスをホストするため、プロキシ・サービスのトランスポート・アドレスとして指定したURLは、常にOracle Service Busドメイン内のパスからの相対位置になります。
SOAPプロトコル・ベースのWSDLサービスの場合、SOAPバインディングのトランスポートURIはトランスポートの実装によって異なります。標準のトランスポート(HTTPやJMSなど)の場合、この値はSOAP仕様または汎用的に受け入れられる別の値に従います。SOAPで標準の値が定義されていないトランスポートの場合、Oracle Service Busは末尾にトランスポートIDを付加した定義済のネームスペース(http://www.oracle.com/transport/2007/05/
)で構成される値を設定します。
有効なWSDLに含まれるサービス要素は1つです。また、ポート・アドレスには、バインディングで選択されているトランスポートで構文とセマンティクスが定義されたURLが含まれます。
非トランスポート型ビジネス・サービス用に生成される有効なWSDLには、次の特性があります。
有効なWSDLに含まれるwsdl:service
セクションは1つのみです。
wsdl:service section
には、複数のwsdl:port
セクションが含まれる場合があります。通常、これが該当するのは、ロード・バランシングを使用しており、サポートされるロード・バランシング・アルゴリズムのいずれかを使用することによって使用できる複数のエンド・ポイント・アドレスが存在する場合です。
サポートされているすべてのトランスポートのSOAPバインディングでは、wsdl:binding
セクションに標準のWSDL SOAPバインディング要素と、トランスポートを識別する一意のトランスポートURIが含まれます。
サポートされているすべてのトランスポートのXMLバインディングでは、wsdl:binding
セクションにOracleのWSDL XMLバインディング要素が含まれます。
トランスポート・アドレスとして指定されたURLは、リモート・サービスがホストされるリモートの場所を示します。
サービスがポートに基づいている場合
有効なWSDLでは、新しいサービスの基になっているテンプレートのポートと同じ名前を使用してポートが定義されます。ビジネス・サービスの複数のエンドポイント・アドレスが構成されている場合、そのサービスから生成される有効なWSDLですべてのエンドポイントのポートが定義されます。これらのポートには、<portname_in_template>_1, <portname_in_template>_2
(以降も同様)という名前が付けられます。
新しいサービスのバインディングはポートから決定され、ポート・タイプはバインディングから決定されます。
トランスポート・アドレスのURLは、リモート・サービスがホストされるリモートの場所を示します。
サービスがバインディングに基づいている場合
有効なWSDLでは、WSDLリソースのポートに基づいて新しいサービスとポートが定義されます。WSDLリソースで定義されているポートは、有効なWSDLには含まれません。
WSDLリソースのバインディングが複数のポートに関連付けられている場合があります。ポートごとに異なるURLを使用でき、それぞれ異なるWS-Policyを添付できます。そのため、生成されるWSDLではこのバインディングが使用されますが、バインディング用にWS-Policyが添付されていない代用ポートが生成されます。
XMLベースのWSDLサービスでは、サービスでHTTPトランスポートを使用している場合にのみ、標準のHTTPバインディングが使用されます。XMLベースのWSDLから作成される他のすべてのサービスでは、有効なWSDLでOracleバインディングが使用されます。
Oracle Service Busは、トランスポート型ビジネス・サービス用に生成される有効なWSDLのwsdl:service
セクションが1つのみであることを保証しません。WSDLはトランスポートによって生成されるため、Oracle Service Busがserviceセクションとportセクションを生成することはなく、クリーンアップも行いません。ただし、Oracle Service Busは依存関係を評価し、エクスポート時に参照を設定します。
クラスタリングされたドメインで有効なWSDLを生成する場合、Oracle Service Busはサーバーまたはクラスタの構成に基づいてエンドポイントURLを書き換えます。フロント・エンドHTTPホスト/ポート(またはHTTPSエンドポイントのフロント・エンドHTTPSホスト/ポート)が指定されている場合は、そのホストまたはポートが使用されます。それ以外の場合は、管理対象サーバーのホストまたはポートが使用されます。クラスタリングされたドメインでは、フロント・エンドHTTPまたはHTTPSホスト/ポートを割り当てることを強くお薦めします。
例36-12に、WSDLリソースのポート定義とバインディング定義のフラグメントを示します。
例36-12 WSDLリソース
<portType name="StockQuotePortType"> ... </portType> <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> ... </binding> <service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding"> <soap:address location="http://example.com:9999/stockquote"/> </port> <port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding"> <soap:address location="http://example.uk:9999/stockquote"/> </port> </service>
例36-12のStockQuotePort
ポートに基づいてプロキシ・サービスを作成すると、有効なWSDLは例36-13のフラグメントのようになります。
例36-13 ポートに基づいたプロキシ・サービスの有効なWSDL
<binding name="StockQuoteSoapBinding" type="ns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> ... </binding> <service name="StockQuoteService"> <port name="StockQuotePort" binding="ns:StockQuoteSoapBinding"> <soap:address location="http://host:port/project/proxyname"/> </port> </service>
この例について、次の点に注意してください。
テンプレートと有効なWSDLのサービス名(StockQuoteService
)は同じです。
テンプレートと有効なWSDLのバインディングは同じです。この例のバインディングでは、サービスがSOAPドキュメント・スタイルのメッセージにHTTP転送プロトコルを使用することを指定しています。(この例では示されていませんが、テンプレートと有効なWSDLで同じバインディング操作も指定しています)。
WSDLリソースで定義されている2つ目のポートStockQuotePortUK
は、有効なWSDLでは定義されていません。
WSDLリソースのポートで定義されているトランスポート・アドレス(URI)http://example.com:9999/stockquote
は、有効なWSDLのポートで生成されたアドレスhttp://host:port/project_path/proxy_service_nameとは異なります。有効なWSDLでは、Oracle Service Bus管理コンソールまたはOracle Service Busプラグインを使用するEclipseでのトランスポート構成に指定したアドレスが使用されます。
例36-12のStockQuoteBinding
バインディングに基づいてプロキシ・サービスを作成すると、有効なWSDLは例36-14のフラグメントのようになります。
例36-14 バインディングに基づいたプロキシ・サービスの有効なWSDL
<binding name="StockQuoteSoapBinding" type="ns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> ... </binding> <wsdl:service name="StockQuoteSoapBindingQSService" <wsdl:port name="StockQuoteSoapBindingQSPort" binding="ns:StockQuoteSoapBinding"> <soap:address location="http:/host:port/project/proxyname"/> </wsdl:port> </wsdl:service>
この例について、次の点に注意してください。
WSDLリソースのサービスとポートは、有効なWSDLで生成されたサービスとポートとは異なります。
WSDLリソースと有効なWSDLのサービス名は異なります。テンプレートではStockQuoteService
、有効なWSDLではStockQuoteSoapBindingQSService
です。
WSDLリソースと有効なWSDLのバインディングは同じです。この例のバインディングでは、サービスがSOAPドキュメント・スタイルのメッセージにHTTP転送プロトコルを使用することを指定しています。
この例では示されていませんが、テンプレートと有効なWSDLのバインディングでは、同じバインディング操作を指定しています。
WSDLリソースのポートで定義されているトランスポート・アドレス(URI)http://example.com:9999/stockquote
は、有効なWSDLのポートで生成されたアドレスhttp://
host:port/project
/stockquote
とは異なります。
1つのポートのみを公開してクライアントに様々なエンタープライズ・アプリケーションを提供するには、任意のSOAPまたは任意のXMLサービス・タイプを使用します。任意のSOAPの場合、SOAP 1.1とSOAP 1.2のどちらであるかを指定する必要があります。
リクエスト・メッセージまたはレスポンス・メッセージのいずれかがXML以外である場合、メッセージング・サービス・タイプを使用する必要があります。
Oracle Service Busでは、誤りのあるSOAPヘッダーのチェックは自動では行われません。ただし、XQuery条件式と検証アクションを使用することで、この種のチェックを明示的に実行できます。検証アクションの詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の検証アクションの追加に関する項または検証アクションのプロパティに関する項を参照してください。XQuery条件式の詳細については『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の第23章「プロキシ・サービス: XQueryエディタとXPathエディタ」または条件エディタに関する説明を参照してください。
Oracle Service Busを使用して検証アクションを構成し、メッセージ・フローでXQuery条件式を使用して検証チェックを明示的に実行できます。
サービス・タイプの詳細は、20.1項「プロキシ・サービスの作成と構成」の「「全般的な構成」ページ」を参照してください。
次の項では、プロキシ・サービスの構成の概要を説明します。プロキシ・サービスを構成する際の特定の手順については、次を参照してください。
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のプロキシ・サービスの操作に関する項
各プロキシ・サービスは特定のタイプであり、それぞれのタイプに適した転送プロトコルで使用できます。Oracle Service Busでは、複数の標準トランスポートとカスタム・トランスポートをサポートしています。サービス・タイプと各タイプで使用できる標準トランスポートを表36-2に示します。
表36-2 Oracle Service Busでサポートされるプロキシ・サービスのタイプとトランスポート
サービス・タイプ | 説明 | このサービス・タイプでサポートされる標準の転送プロトコル |
---|---|---|
WSDL Webサービス |
WSDLドキュメントでインタフェースが記述されたSOAPプロキシ・サービスまたはXMLプロキシ・サービス。 |
HTTP JCA JMS ローカル SB WS |
トランスポート型付きのサービス (WSDLなし) |
JEJBトランスポートを使用するサービス。 |
JEJB |
メッセージング・サービス (WSDLなし) |
バイナリ、テキスト、MFL、XMLなどの様々なデータ型のリクエスト・メッセージとレスポンス・メッセージを使用できるメッセージング・サービス。 |
電子メール ファイル FTP HTTP JMS ローカル MQ SFTP TUXEDO |
任意のSOAPサービス (WSDLなし) |
明示的に定義された具象インタフェースを持たないSOAPサービス。 |
HTTP JMS ローカル SB |
任意のXMLサービス (非SOAP、WSDLなし) |
明示的に定義された具象インタフェースを持たないXMLサービス。 |
電子メール ファイル FTP HTTP JMS ローカル MQ SB SFTP TUXEDO |
注意: すべてのサービス・タイプで、MIMEを使用して添付ファイルを送受信できます。 |
Oracle Service Bus管理コンソールまたはOracle Service Busプラグインを使用するEclipseでのすべてのプロキシ・サービス・タイプに対して、トランスポート設定を構成する必要があります。構成の詳細は、トランスポートの種類によって異なります。特定の構成設定については、20.2.3項「「トランスポート構成」ページ」および20.2.4項「プロトコル固有のトランスポート構成ページ」を参照してください。
選択するトランスポートは、バインディング定義で必要とされるトランスポート・モード(リクエスト/レスポンス、一方向、または両方)をサポートする必要があり、それに従って構成する必要があります。
両方のモードでメッセージを交換するサービスの場合、(リクエスト/レスポンスを2つの非同期呼出しとして実装するJMSなどのトランスポートで)トランスポート・モードを適宜選択するようにバインディング・レイヤーを構成する必要があります。サービスが具象型の場合、バインディング定義の記述に従って、この選択が自動的に行われます。サービスが具象型でない場合、バインディング・レイヤーを構成するには、$outbound変数でモードを設定する必要があります。
トランスポートとWSDLに基づいて、トランスポート・モードが自動的に選択されますが、$inbound
または$outbound
で上書きできます。
サービス・プロバイダを使用して、プロキシ・サービスのセキュリティを指定できます。サービス・プロバイダが必要となるのは、プロキシ・サービスがクライアント証明書認証を必要とするHTTPSサービスにメッセージをルーティングする場合です。また、一部のメッセージ・レベルのセキュリティ・シナリオで必要となる場合もあります。
サービス・アカウントを作成して、ビジネス・サービスへの接続時に認証を行うことができます。サービス・アカウントは、必要なユーザー名とパスワードの組合せのエイリアス・リソースとして機能します。
Oracle WebLogic Serverを使用して、資格証明レベルの検証を必要とするビジネス・サービスのセキュリティ資格証明を直接管理することができます。
詳細は、第18章「サービス・キー・プロバイダ」を参照してください。また、36.6.5項「プロキシ・サービスのセキュリティ関連の検証」も参照してください。
プロキシ・サービスの各タイプは、同じパターンに従ってモデル化されています。各サービス・タイプでは、次の構成を定義する必要があります。
バインディング定義
ランタイム構成
ランタイム変数($operation
、$body
、$header
、$attachments
)
プロキシ・サービスの各タイプに固有の構成のプロパティを表36-3に示します。
表36-3プロキシ・サービスのさまざまなタイプの構成のプロパティ
プロキシ・サービスのタイプ | 構成プロパティ |
---|---|
WSDL Webサービス |
バインディング定義: 36.4項「WSDLを使用したサービスの定義」を参照してください。 ランタイム変数:
|
トランスポート・タイプ |
トランスポート型付きのサービスは、空のバインディング定義を持ちます。WSDLは指定されません。 トランスポート型付きのサービスは、Oracle Service Busを介したEJBによる呼出しを可能にするインバウンド・トランスポートです。これは、サービス・インタフェースを記述するWSDLを生成する自己記述型のトランスポートです。JEJBトランスポートは、トランザクションとセキュリティ・コンテキストの伝播を特徴とします。 |
メッセージング・サービス |
バインディング定義: メッセージング・サービスのバインディング定義は、交換されるメッセージのコンテンツ・タイプの構成で構成されます。レスポンスのコンテンツ・タイプは、リクエストのコンテンツ・タイプと同じである必要はありません。そのため、レスポンスは個別に構成されます(たとえば、サービスでMFLメッセージを受け入れ、XMLの受信確認を返すことができます)。また、レスポンスのコンテンツ・タイプを「なし」に設定することもできます。 定義上、メッセージング・ベースのサービスにはWSDL定義はありません。これらのサービスのWSDLドキュメントをリクエストすることはできません。 リクエストおよびレスポンスから選択するコンテンツ・タイプは、次のとおりです。
注意: サービスからの成功または失敗のメッセージをコール元のクライアントに伝搬するために、パイプラインで返信アクションを使用している場合は、「なし」以外のオプションを選択します。「なし」オプションによって、返信がブロックされます。 ランタイム変数: このサービス・タイプはメッセージ・ベースです。Webサービスには、複数の「操作」という概念はありません。したがって、
メッセージに添付ファイルがある場合は、 メッセージ・コンテキスト変数の詳細は、39.3項「メッセージ関連の変数」および39.9項「ディスパッチするメッセージの作成」を参照してください。 |
任意のSOAPサービス |
バインディング定義: このサービス・タイプで定義する情報は、WSDLバインディング定義に関係なく、サービスでSOAPメッセージを受信または送信するということのみです。したがって、このタイプのバインディング構成は空になります。 また、バインディング構成が存在しないため、このタイプとメッセージのコンテンツ・タイプの組合せから、メッセージに添付ファイルがあるかどうかを十分判別できます。 定義上、「任意の」サービス(SOAPまたはXML)にはWSDL定義はありません。これらのサービスのWSDLドキュメントを生成または表示することはできません。 ランタイム変数:
SOAPメッセージに添付ファイルがある場合は、 ポート・タイプを定義しないため、 メッセージ・コンテキスト変数の詳細は、39.3項「メッセージ関連の変数」および39.9項「ディスパッチするメッセージの作成」を参照してください。 |
任意のXMLサービス |
バインディング定義: このサービス・タイプで定義する情報は、WSDLバインディング定義に関係なく、サービスでXMLメッセージを受信または送信するということのみです。したがって、このタイプのバインディング構成は空になります。 また、バインディング構成が存在しないため、このタイプとメッセージのコンテンツ・タイプの組合せから、メッセージに添付ファイルがあるかどうかを十分判別できます。 定義上、「任意の」サービス(SOAPまたはXML)にはWSDL定義はありません。これらのサービスのWSDLドキュメントをリクエストすることはできません。 ランタイム変数:
メッセージに添付ファイルがある場合は、
ポート・タイプを定義しないため、 メッセージ・コンテキスト変数の詳細は、39.3項「メッセージ関連の変数」および39.9項「ディスパッチするメッセージの作成」を参照してください。 |
プロキシ・サービスのメッセージ・フロー定義では、プロキシ・サービスを介したメッセージ・フローでメッセージを処理する方法を決定するロジックを定義します。メッセージ・フロー定義では、必要に応じてメッセージを変換し、メッセージ・データをビジネス・サービス(アウトバウンド・メッセージの場合)または送信元のクライアント(インバウンド・メッセージの場合)に必要なフォーマットにマップします。次に、メッセージは適切な場所にルーティングされます。メッセージ・フローの構成については、第37章「Oracle Service Busでのメッセージ・フローの作成」を参照してください。
アクティブなプロキシ・サービスへの変更が含まれるセッションをアクティブ化する場合、Oracle Service Busは変更を検証して、プロキシ・サービスの静的なエンドポイントに必要なすべての資格証明が作成されているかどうかを確認します。たとえば、Webサービスを静的なエンドポイントとして使用するようにプロキシ・サービスを構成しており、そのWebサービスがデジタル署名を必要とする場合、Oracle Service Busはプロキシ・サービスにサービス・キー・プロバイダが関連付けられているかどうか、また、サービス・キー・プロバイダにデジタル署名として使用できるキー・ペア・バインディングが含まれているかどうかを検証します。
セッションにサービス・キー・プロバイダのキー・ペア・バインディングへの変更が含まれている場合は、そのサービス・キー・プロバイダを使用するすべてのプロキシ・サービスに対して変更が検証されます。たとえば、暗号化用のキー・ペアを削除すると、暗号化が必要なエンドポイントを含むプロキシ・サービス・プロバイダを参照しているプロキシ・サービスに対して、検証エラーが報告されます。
次の条件により、セキュリティ関連の検証が実行されるタイミングと、検証中に行われるアクションが決定されます。
プロキシ・サービスが静的なルートと処理を指定している場合は、静的なルートおよび処理に必要な資格証明が決定されます。必要な資格証明がプロキシ・サービスに含まれていない場合は、その資格証明が追加されるまで、セッションはコミットされません。
プロキシ・サービスが静的なルートを指定しており、処理がインバウンド・リクエストからパススルーされる場合は、静的なルートおよび各ルートの処理に必要な資格証明が決定されます。必要な資格がプロキシ・サービスに含まれていない場合は、検証の警告が表示されますが、セッションをコミットすることはできます。
プロキシ・サービスが動的なルートと処理を指定する場合は、セキュリティ要件を検証できないため、ランタイム・エラーが発生するおそれがあります。動的ルーティングについては、37.8項「動的ルーティングの使用」を参照してください。
次の項で、ビジネス・サービス構成の概要について説明します。
この項の内容は次のとおりです。
ビジネス・サービスの構成の特定の手順については、次を参照してください。
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のビジネス・サービスの操作に関する項
各ビジネス・サービスは特定のタイプであり、それぞれのタイプに適した転送プロトコルで使用できます。Oracle Service Busでは、複数の標準トランスポートとカスタム・トランスポートをサポートしています。サービス・タイプと各タイプで使用できる標準トランスポートを表36-4に示します。
表36-4 Oracle Service Busでサポートされるビジネス・サービスのタイプとトランスポート
サービス・タイプ | 説明 | 転送プロトコル |
---|---|---|
WSDL Webサービス |
WSDLドキュメントでインタフェースが記述されたSOAPビジネス・サービスまたはXMLビジネス・サービス。 |
BPEL-10g DSP HTTP JCA JMS ローカル脚注 1 SB SOA-DIRECT WS |
トランスポート型付きのサービス (WSDLなし) |
EJB、JEJBまたはフロー(分割-結合)トランスポートを使用するサービス。 |
EJB フロー JEJB |
メッセージング・タイプのサービス (WSDLなし) |
バイナリ、テキスト、MFL、XMLなどの様々なデータ型のリクエスト・メッセージとレスポンス・メッセージを使用できるメッセージング・サービス。 |
電子メール ファイル FTP HTTP JMS ローカル MQ SFTP TUXEDO |
任意のSOAPサービス (WSDLなし) |
明示的に定義された具象インタフェースを持たないSOAPサービス。 |
DSP HTTP JMS ローカル SB |
任意のXMLサービス (WSDLなし) |
明示的に定義された具象インタフェースを持たないXMLサービス。 |
DSP 電子メール ファイル FTP HTTP JMS ローカル MQ SB SFTP TUXEDO脚注 2 |
脚注 1 2つのプロキシ・サービス間の通信には、ローカル・トランスポートを使用することをお薦めします。ローカル・トランスポートの詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のローカル・トランスポートに関する項を参照してください。
脚注 2 Tuxedoトランスポートベースのサービスでは、サービス・タイプがXMLの場合、TuxedoクライアントのFLD_MBSTRINGフィールドを含むFML32バッファはXMLに変換されません。
様々な転送プロトコルに基づいたプロキシ・サービスおよびビジネス・サービスの構成の詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のトランスポートに関する項を参照してください。
ビジネス・サービスの各タイプは、同じパターンに従ってモデル化されています。各サービス・タイプでは、次の構成を定義する必要があります。
バインディング定義
ランタイム構成
ランタイム変数($operation
、$body
、$header
、$attachments
)
表36-5に示すビジネス・サービスの構成のプロパティは、すべてのサービス・タイプに共通するものです。各サービス・タイプに固有のプロパティについては、36.7.3項「ビジネス・サービスの各タイプの構成設定」を参照してください。
表36-5 ビジネス・サービスの共通する構成のプロパティ
プロパティ | 説明 |
---|---|
リソース定義 |
リソース定義は、次のもので構成されます。
|
トランスポート構成 |
各ビジネス・サービスの次のパラメータを構成できます。
選択するトランスポート方式は、バインディング定義で必要とされるトランスポート・モード(リクエスト/レスポンス、一方向、または両方)をサポートできる必要があり、それに従って構成する必要があります。 両方のモード(リクエスト/レスポンスと一方向)でメッセージを交換するサービスでは、トランスポート・モードを適宜選択できるようにバインディング・レイヤーを構成する必要があります。サービスが具象型の場合、バインディング定義の記述に従って、この選択が自動的に行われます。サービスが具象型でない場合、バインディング・レイヤーを構成するには、メッセージ・フローでルーティング・オプション・アクションを使用して、ルートまたはパブリッシュのモードを設定する必要があります。 トランスポート方式とWSDLまたはインタフェースに基づいて、トランスポート・モードが自動的に選択されますが、ルート・アクションまたはパブリッシュ・アクションのルーティング・オプション・アクションを使用して上書きできます。 |
結果キャッシュ |
すべてのビジネス・サービスで、ビジネス・サービスの呼出しの結果をキャッシュするかどうかおよびキャッシュ方法を決定できます。サービス構成の「メッセージ処理」セクションにあるこの機能によって、結果があまり変わらないサービスのパフォーマンスを改善できます。結果キャッシュを有効にすると、サービスの結果は、外部サービスを呼び出して結果を取得するのではなく、キャッシュから返されます。 詳細は、36.7.5項「ビジネス・サービスの結果のキャッシュによるパフォーマンスの改善」を参照してください。 |
ビジネス・サービスの各タイプに固有の構成のプロパティを表36-6に示します。
表36-6 ビジネス・サービスの様々なタイプの構成のプロパティ
プロパティ | 説明 |
---|---|
WSDL Webサービス |
36.4項「WSDLを使用したサービスの定義」を参照してください。 |
任意のSOAPサービス |
バインディング定義: このサービス・タイプで定義する情報は、WSDLバインディング定義に関係なく、サービスでSOAPメッセージを受信または送信するということのみです。したがって、このタイプのバインディング構成は空になります。 また、バインディング構成が存在しないため、このタイプとメッセージのコンテンツ・タイプの組合せから、メッセージに添付ファイルがあるかどうかを十分判別できます。 定義上、任意のサービス(SOAPまたはXML)にはWSDL定義はありません。 ランタイム変数:
SOAPメッセージに添付ファイルがある場合は、 メッセージ・コンテキスト変数の詳細は、39.3項「メッセージ関連の変数」を参照してください。 |
トランスポート・タイプ |
トランスポート型付きのサービスには空のバインディング定義があります。WSDLは指定されません。かわりに、トランスポートによってサービスのWSDLが自動的に定義されます。このWSDLを含むzipは、Oracle Service Bus管理コンソールまたはEclipse用のOracle Service Busプラグインからエクスポートできます。このWSDLでは、ポートは定義されません。 EJB/JEJBトランスポート型付きサービスは、Oracle Service BusからEJBにアクセスするためのアウトバウンド・トランスポートです。これは、サービス・インタフェースを記述するWSDLを生成する自己記述型のトランスポートです。EJBとJEJBトランスポート機能には、トランザクションとセキュリティ・コンテキストの伝播が含まれます。 EJBまたはJEJBトランスポートを使用して構築されたビジネス・サービスは、パブリッシュ、サービス・コールアウトおよびサービス呼出しに使用できます。 |
任意のXMLサービス |
バインディング定義: このサービス・タイプで定義する情報は、WSDLバインディング定義に関係なく、サービスでXMLメッセージを受信または送信するということのみです。したがって、このタイプのバインディング構成は空になります。 また、バインディング構成が存在しないため、このタイプとメッセージのコンテンツ・タイプの組合せから、メッセージに添付ファイルがあるかどうかを十分判別できます。 定義上、任意のサービス(SOAPまたはXML)にはWSDL定義はありません。 ランタイム変数:
メッセージに添付ファイルがある場合は、
メッセージ・コンテキスト変数の詳細は、39.3項「メッセージ関連の変数」を参照してください。 |
メッセージング・サービス |
バインディング定義: メッセージング・サービスのバインディング定義は、交換されるメッセージのコンテンツ・タイプの構成で構成されます。レスポンスのコンテンツ・タイプは、リクエストのコンテンツ・タイプと同じである必要はありません。そのため、レスポンスは個別に構成されます(たとえば、サービスでMFLメッセージを受信し、XMLの受信確認を返すことも可能です)。 定義上、メッセージング・ベースのサービスにはWSDL定義はありません。これらのサービスのWSDLドキュメントをリクエストすることはできません。 リクエストおよびレスポンスには、次のコンテンツ・タイプを使用できます。
ランタイム変数: このサービス・タイプはメッセージ・ベースです。
メッセージに添付ファイルがある場合は、 メッセージ・コンテキスト変数の詳細は、39.3項「メッセージ関連の変数」を参照してください。 |
ビジネス・サービスでWebサービス・セキュリティが必要な場合は、ビジネス・サービスの作成時に、指定するWSDLに必要なWS-Policyがアタッチされていることを確認してください。さらに、ビジネス・サービスのWS-Policyにより暗号化が必要な場合は、ビジネス・サービスのパブリック証明書がWSDLに埋め込まれていることを確認してください。ビジネス・サービスがOracle WebLogic Server 9.0以降のWebサービスである場合は、http://<host>:<port>/<service url>?WSDL
というURLを使用してWSDLを取得できます。必要に応じて、パブリック証明書が自動的に埋め込まれます。詳細は、4.30項「Webブラウザでのリソースの表示」を参照してください。
プロキシ・サーバーを介してメッセージをルーティングするように、ビジネス・サービスを構成できます。これを行うには、必要な資格証明と共に1つまたは複数のプロキシ・サーバーを指定するプロキシ・サーバー・リソースを作成します。その後、プロキシ・サーバー・リソースをビジネス・サービスに関連付けることができます。これにより、Oracle Service Busが、構成されたプロキシ・サーバーを使用してビジネス・サービスへの接続を行います。
複数のプロキシ・サーバーをリソースに追加することにより、Oracle Service Busでロード・バランシングを実行し、構成されたプロキシ・サーバー間でフォルト・トレランスを可能にします。資格証明はプロキシ・サーバーに対する接続を開く場合に使用されます。特定のプロキシ・サーバーにアクセスできない場合、Oracle Service Busは構成に含まれる次のプロキシ・サーバーを使用しようとします。すべてのプロキシ・サーバーにアクセスできない場合、Oracle Service Busはバック・エンド・サービスへの直接接続を試みます。これにも失敗すると、フォルトが発生して呼出し元に返送されます。
プロキシ・サーバーを構成する際、ホスト名またはIPアドレスに加えて、サーバーのクリア・テキストまたはSSLポート番号を指定できます。プロキシ・サーバー・リソース構成で指定されたポートは、バック・エンド・サービスのポートではなく、Webプロキシ・サーバーの実際の物理的なポートに対応するものです。ただし、ビジネス・サービスでのエンド・ポイント構成はバック・エンド・サービスの実際のエンド・ポイントに対応します。これはHTTP CONNECTコマンドを使用したSSL/TLSトンネリングの場合にも当てはまります。
注意: Webプロキシ・サーバーには、クリア・テキスト・ソケットを使用したHTTP CONNECTとSSLソケットを使用したHTTP CONNECTの両方をサポートするサーバーもあれば、クリア・テキスト・ソケットを使用したHTTP CONNECTのみをサポートするサーバーもあります。たとえば、 Oracle iPlanet Web Proxy Server 4.0は、クリア・テキスト・ソケットを使用したHTTP CONNECTおよびSSLソケットを使用したHTTP CONNECTをサポートしますが、プロキシ・サーバー・モードでのApache Web Server 2.2は、クリア・テキスト・ソケットを使用したHTTP CONNECTのみをサポートします。
通常は、SSL/TLSトンネリングをサポートする場合、物理的なプロキシ・サーバーにサーバーまたは認証局(CA)の証明書をインストールする必要はありません。かわりに、Webプロキシ・サーバーは安全なソケットを開くために、呼出し元(この場合、Oracle Service Bus)から受信した証明書を使用します。同様に、ビジネス・アプリケーションをホストするサーバーがクライアントの証明書を必要とする場合は、プロキシ・サービスをホストするサーバー(Oracle Service Bus)の証明書が認証に使用されます。
頻繁に変更されることのない比較的静的な結果を返すビジネス・サービスを使用する場合、それらのビジネス・サービスが結果をキャッシュするよう構成できます。結果のキャッシュを有効にすると、サービスは、外部サービスを呼び出すのではなく、キャッシュから結果を返します。これにより、外部サービスにアクセスするネットワーク・オーバーヘッドが減り、パフォーマンスが向上します。結果キャッシュによって、外部サービスをホストするバックエンド・サービスの負荷が削減され、スケーラビリティの向上にもつながります。
この項では、結果キャッシュとは、すべてのビジネス・サービスで共有し、各結果を格納するキャッシュ自体のことで、キャッシュされた結果とは結果キャッシュ内の各結果のことです。
結果キャッシュを使用するビジネス・サービスでは、キャッシュされた結果の存続時間を制御できます。キャッシュされた結果の有効期限に達すると、次のビジネス・サービス・コールによってバックエンド・サービスが呼び出され、結果が取得されます。この結果はキャッシュに格納され、以降のアクセス・リクエストに使用されます。
Oracle Service Busで使用される結果キャッシュのメカニズムは、Oracle WebLogic Serverに含まれているOracle Coherence (Enterprise Edition)です。そのプロセッサでOracle WebLogic Serverのライセンスが有効であれば、Coherenceはそのコンピュータで使用できます。
Oracle Service Busの結果キャッシュの実装には、グロバールな有効化/無効化、キャッシュ・メッセージ変数、各ビジネス・サービスの構成フィールドおよびサービス統計、デバッグ、アラート・ルールとスマート検索に関するキャッシュ・オプションが含まれます。
この項では、Oracle Service Busの結果キャッシュの実装について説明します。
図36-1に、ビジネス・サービスを呼び出し、キャッシュされた結果を含むレスポンスを受け取るクライアントを示します。
注意: 結果キャッシュは、リクエスト/レスポンス操作についてのみ機能します。 |
キャッシュされた各結果は、ServiceRef(完全修飾されたサービスのパス名であるサービスの一意の識別子)、呼び出される操作およびキャッシュ・トークン文字列で構成されるキャッシュ・キーによって一意に識別されます。キャッシュ・トークンは、あるビジネス・サービスの1つのキャッシュ結果を他のキャッシュ結果から一意に識別する場合に役立ちます。キャッシュ・トークンの値は制御されます。キャッシュ・トークンは、ビジネス・サービスの結果キャッシュ構成でキャッシュ・トークン式を構成することで、またはプロキシ・サービス・メッセージ・フローを使用する$transportMetaDataのcache-tokenメタデータ要素を使用することで設定できます。
ビジネス・サービスで、キャッシュ・キーを使用してキャッシュされた結果が特定されると、外部サービスを直接呼び出すかわりにキャッシュされた結果がクライアントに返されます。
図36-1で、実線の矢印は、クライアントとキャッシュされた結果とのメッセージ・パスを表します。点線の矢印は、キャッシュされた結果がない場合のメッセージ・パスを表します。キャッシュされた結果がない場合、ビジネス・サービスは外部サービスを直接呼出し、結果をクライアントに返して、結果をキャッシュに格納します。初めての呼出しでキャッシュがまだない、キャッシュのエラー、キャッシュがフラッシュされたなどの様々な理由から、結果のキャッシュが空の場合があります。
キャッシュされた結果には、キャッシュの有効期限として存続時間(TTL)属性があります。キャッシュの有効期限は、ビジネス・サービスの「結果キャッシュ」構成の「有効期限」プロパティまたはプロキシ・サービス・メッセージ・フローを使用する$transportMetaDataのcache-ttl要素を使用して構成できます。Oracle CoherenceでTTLの期限が過ぎていることが検出されると、キャッシュがフラッシュされ、ビジネス・サービスによって外部サービスが呼び出されて結果が取得されます。結果はキャッシュに格納され(結果にエラーがない場合)、次のリクエストで返すことができるようになります。
Oracle Service Bus/Coherenceでキャッシュされた個々の結果、あるビジネス・サービスについてキャッシュされているすべての結果または結果キャッシュ全体(すべてのOracle Service Busビジネス・サービスについてキャッシュされたすべての結果)をフラッシュできます。次のイベントは、Oracle Service Bus/Coherenceでキャッシュがどのようにフラッシュされるかについて示しています。
キャッシュTTLの期限切れ - キャッシュされた各結果にはそれぞれTTLがあります。TTLに達すると、Oracle Coherenceによってキャッシュされた個々の結果がフラッシュされます。
1つのビジネス・サービスの結果キャッシュの無効化 - あるビジネス・サービスの結果キャッシュを無効にすると、Oracle Service Busによって、そのビジネス・サービスについてキャッシュされたすべての結果がOracle Coherenceでフラッシュされます。
ビジネス・サービスの更新、名前変更または削除 - あるビジネス・サービスを更新、名前変更または削除すると、Oracle Service Busによって、そのビジネス・サービスについてキャッシュされたすべての結果がOracle Coherenceからフラッシュされます。
従属リソースの更新 - WSDLなどの従属リソースを更新すると、Oracle Service Busによって、そのビジネス・サービスについてキャッシュされたすべての結果がOracle Coherenceからフラッシュされます。ただし、サービス・プロバイダ、UDDIレジストリ、アラート宛先といった従属リソースに対する変更ではキャッシュはフラッシュされません。
結果キャッシュのグローバルな無効化 - 結果キャッシュをグローバルに無効にすると、Oracle Service Busによって、結果キャッシュ全体(すべてのビジネス・サービスについてキャッシュされたすべての結果)がOracle Coherenceからフラッシュされます。
結果キャッシュの操作および構成の詳細は、次を参照してください。
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のビジネス・サービスの「メッセージ処理構成」ページに関する項
この項では、結果キャッシュの使用のベスト・プラクティスについて説明します。
キャッシュされた結果によって外部サービスは直接呼び出されなくなるため、静的でないサービス・アカウントまたはWS-Securityポリシーにセキュリティを提供するビジネスサービスには、結果キャッシュを使用しないでください。
本番環境では結果キャッシュを使用する場合、Oracle Service Bus環境をデプロイする前に、http://download.oracle.com/docs/cd/E15357_01/coh.360/e15723/deploy_checklist.htm#CHDJEJEI
にあるOracle Coherence開発者ガイドの本番環境のチェックリストに関する説明に従って、Coherenceの設定と構成の計画および実装を行って最適なパフォーマンスが得られるようにする必要があります。
結果キャッシュに使用されるメタデータは、次のとおりです。
結果キャッシュに使用されるリクエスト・メタデータは、cache-tokenおよびcache-ttl(両方とも文字列値)です。両方ともビジネス・サービス構成で構成できます。ビジネス・サービスでキャッシュ・トークンまたはTTLを未定義のままにすることも、リクエストでキャッシュ・トークンまたはTTLにこれらのメタデータを指定することもできます。リクエストでキャッシュ・トークンまたはTTLを設定すると、これらの値によって、ビジネス・サービス構成で定義されたキャッシュ・トークンまたはTTLがオーバーライドされます。
ビジネス・サービス構成の詳細は、19.2.23項「「メッセージ処理構成」ページ」を参照してください。
結果キャッシュは、結果キャッシュが構成されているビジネス・サービスが、プロキシ・サービスから(ルーティングまたはサービス・コールアウトなどを使用して)呼び出された場合のみ有効です。したがって、結果キャッシュをテストする場合、ビジネス・サービスをテスト・コンソールから直接起動しないでください。かわりに、テスト・コンソールを使用して、ビジネス・サービスを呼び出すプロキシ・サービスをテストします。
ただし、分割-結合ビジネス・サービスを直接呼び出して、結果キャッシュをテストできます。
各Oracle Service Busドメインで、ドメインでのOracle Coherenceのビジネス・サービス結果キャッシュに対する使用方法を変更できます。この項では、デフォルトの設定とこれを変更する必要がある場合について説明します。
Oracle Service Busの結果キャッシュのキャッシュ・スキームは、DOMAIN_HOME/config/osb/coherence/osb-coherence-cache-config.xmlを変更することでチューニングできます。デフォルトでは、Oracle Service Busの結果キャッシュには、分散キャッシュ・スキームが使用されます。詳細は、Oracle Coherence開発者ガイドのキャッシュ構成要素に関する説明(http://download.oracle.com/docs/cd/E15357_01/coh.360/e15723/appendix_cacheconfig.htm
)を参照してください。
Oracle Service Busで、Oracle Coherenceの独自のデフォルト構成がドメイン内のサーバーに提供されます。構成ファイルはDOMAIN_HOME/config/osb/coherence/osb-coherence-override.xmlで、Oracle Coherenceキャッシュへのサーバー・アクセスを制御する様々なプロパティが含まれます。
この項では、Oracle Service Busの単一サーバー・ドメインおよび複数サーバー・ドメインに対するOracle Coherenceのデフォルト構成設定と、デフォルト設定を変更する必要があるシナリオについて説明します。
表36-7では、開発者用Oracle Service Busテンプレートを使用して作成した単一サーバー・ドメインのosb-coherence-override.xmlでのシステム・プロパティのデフォルト値を示します。これらのユニキャストの設定によって、Oracle Coherenceのキャッシュ・アクセスがローカル・サーバーに限定されます。この構成では、別のサーバーで起動されたノードは、同じOracle Coherenceクラスタに参加してキャッシュされた情報を共有することはありません。
システム・プロパティは、osb-coherence-override.xml(サーバーの再起動が必要)で指定するか、またはサーバー起動時にシステム・プロパティを指定することで変更できます。
表36-7「開発者用Oracle Service Bus」ドメイン・トポロジ設定に対するosb-coherence-override.xmlのデフォルト値
サーバーの詳細 | ファイル内での要素/プロパティ名 | システム・プロパティ | デフォルト値 |
---|---|---|---|
ユニキャスト・アドレス |
<address> |
OSB.coherence.localhost |
127.0.0.1 |
ユニキャスト・ポート |
<port> |
OSB.coherence.localport |
7890 |
既知のアドレス |
<address> |
OSB.coherence.wka |
127.0.0.1 |
既知のポート |
<port> |
OSB.coherence.wka.port |
7890 |
ネットワーク存続時間(TTL) |
<time-to-live> |
OSB.coherence.ttl |
0 この設定の詳細は、 |
表36-8に、Oracle Service Busテンプレートで作成された複数サーバー・ドメインに対するosb-coherence-override.xmlでのシステム・プロパティのデフォルト値を示します。マルチキャストのデフォルト値で、同じテンプレートから作成された同一のサブネット上のOracle WebLogic Serverノードで共有されるOracle Coherenceクラスタが作成されます。
システム・プロパティは、osb-coherence-override.xml(サーバーの再起動が必要)で指定するか、またはサーバー起動時にシステム・プロパティを指定することで変更できます。
表36-8 「Oracle Service Bus」ドメイン・トポロジに対するosb-coherence-override.xmlのデフォルト設定
サーバーの詳細 | ファイル内での要素/プロパティ名 | システム・プロパティ | デフォルト値 |
---|---|---|---|
ユニキャスト・アドレス |
<address> |
OSB.coherence.localhost |
127.0.0.1 |
ユニキャスト・ポート |
<port> |
OSB.coherence.localport |
7890 |
既知のユニキャスト・アドレス・プレースホルダー |
<address> |
OSB.coherence.wkaN |
このファイルは、必要に応じて構成して使用できる既知の9つのアドレス(アドレス値なし)用のプレースホルダーを提供します。 |
既知のユニキャスト・アドレス・ポート・プレースホルダー |
<port> |
OSB.coherence.wkaN.port |
このファイルは、必要に応じて構成して使用できる既知の9つのアドレス・ポート(アドレス値なし)用のプレースホルダーを提供します。 |
マルチキャスト・リスナー・アドレス |
<address> |
OSB.coherence.clusteraddress |
228.8.8.8 |
マルチキャスト・リスナー・ポート |
<port> |
OSB.coherence.clusterport |
9888 |
マルチキャスト・アドレスとマルチキャスト・ポートのプロパティによって、Oracle Coherenceクラスタのメンバー・ノードの特定方法が決まります。この組合せは、同じサブネット内で稼働するOracle Coherenceクラスタごとに一意である必要があります。
注意: デフォルトでは、Oracle Service Busテンプレートには、マルチキャスト・リスナーを使用するように構成されていますが、ベスト・プラクティスは、Oracle Coherenceのノードが明示的にリストされたユニキャスト・リスナーを使用するようOracle Coherenceクラスタを構成することです。 ユニキャストに切り替えるには、マルチキャスト値を削除して、ユニキャスト・リスナーの既知のアドレスを入力します。例: <well-known-addresses> <socket-address id="1"> <address system-property="OSB.coherence.wka1">127.0.0.1</address> <port system-property="OSB.coherence.wka1.port">7890</port> </socket-address> ... 詳細は、 『Oracle Fusion Middleware高可用性ガイド』のOracle Service Busの結果キャッシュに対するOracle Coherenceの構成に関する説明に従って、システム・プロパティを使用したオーバーライドを指定できます。 |
次の構成では、複数のサーバーでOracle Coherenceクラスタを希望通りに共有するために、osb-coherence-override.xmlの手動での変更(または前述の注意の説明に従ったシステム・プロパティのオーバーライドの指定)が必要です。
クラスタ内の既知のアドレスを使用してマルチキャスト・リスナーからユニキャスト・リスナーに切り替える場合、前述の注意のとおりにします。
同一サブネット内に複数のOracle WebLogic Serverクラスタがある場合、Oracle Coherenceクラスタを希望どおりに共有するには、関係のあるOracle Coherenceアドレスとポートのプロパティを変更します。Oracle WebLogic Serverクラスタに使用されるのと同じアドレスとポートを使用しないでください。
同一サブネット内に管理対象サーバーを持つ複数の管理サーバーがある場合、Oracle Coherenceクラスタを希望どおりに共有するには、関係のあるOracle Coherenceアドレスとポートのプロパティを変更します。
同一サブネット内にOracle WebLogic Serverクラスタと管理対象サーバーを持つ管理サーバーの組合せがある場合、Oracle Coherenceクラスタを希望どおりに共有するには、関係のあるOracle Coherenceアドレスとポートのプロパティを変更します。
同一サブネット内に複数のOracle Coherenceクラスタが稼働している場合、マルチキャスト・アドレスとマルチキャスト・ポートを変更して、ノードが接続する必要のあるOracle Coherenceクラスタを指定します。
Oracle Service Busで結果キャッシュを頻繁に使用し、結果キャッシュ用にヒープ領域を使用しすぎないようにする場合、Oracle Service BusのドメインJVMを共有するのではなく、独自のJVMを実行するようにCoherenceキャッシュ・サーバーを設定できます。Coherenceキャッシュ・サーバーをOracle Service Bus JVMの外部(プロセス外)で実行すると、Oracle Service Busでメッセージの処理に使用されるヒープ領域に影響なく、Coherenceキャッシュ・サーバーで独自のヒープ領域を使用できます。
Oracle Service Busでは、OSB_ORACLE_HOME/lib/osb-coherence-client.jarというJARファイルを使用したプロセス外Coherenceキャッシュのサポートが提供されます。
次の手順は、プロセス外Coherenceキャッシュ・サーバーの使用方法を説明しています。
注意: Oracle Service Busとともに使用されるすべてのプロセス外Coherenceキャッシュ・サーバーでは、Oracle Service Busに含まれているバージョンと同バージョンのCoherenceを使用する必要があります。 |
プロセス外Coherenceキャッシュ・サーバーをサポートするようにOracle Service Busドメインを構成します。
Oracle Service Busノードの起動に次の引数を追加して各Oracle Service Busノードのローカル・キャッシュを無効にします。
-Dtangosol.coherence.distributed.localstorage=false
次の引数を使用してCoherenceクラスタの名前を設定します。
-DOSB.coherence.cluster=cluster_name
プロセス外キャッシュ・サーバーの起動を構成します。
osb-coherence-client.jarがCoherenceキャッシュ・サーバーのクラスパス上に存在していることを確認します。例:
-classpath coherence.jar:OSB_ORACLE_HOME/lib/osb-coherence-client.jar
注意: この例のパスは、Oracle Service Busインストールのデフォルトの場所のosb-coherence-client.jarを示しています。Oracle Service Busがインストールされていないプロセス外Coherenceキャッシュ・サーバーで、このファイルをOracle Service BusドメインからCoherenceキャッシュ・ドメインにコピーして、すべてのCoherenceノードの起動引数で参照します。 |
Coherenceキャッシュ・サーバーの起動に次の引数を追加して、osb-coherence-override.xmlを使用します。
-Dtangosol.coherence.override=DOMAIN_HOME/config/osb/coherence/osb-coherence-override.xml
この手順によって、Oracle Service BusのCoherenceノードとプロセス外Coherenceキャッシュ・サーバーの両方で同じネットワーク構成が確実に使用されるようになります。このファイルの詳細は、36.7.5.5.2項「ユニキャストおよびマルチキャストの操作」を参照してください。
注意: この例のパスは、Oracle Service Busインストールのデフォルトの場所のosb-coherence-override.xmlファイルを示しています。Oracle Service Busがインストールされていないプロセス外Coherenceキャッシュ・サーバーで、このファイルをOracle Service BusドメインからCoherenceキャッシュ・ドメインにコピーして、すべてのCoherenceノードの起動引数で参照します。 |
Coherenceキャッシュ・サーバーの起動に次の引数を追加して、osb-coherence-cache-config.xmlを使用します。
-Dtangosol.coherence.cacheconfig=DOMAIN_HOME/config/osb/coherence/osb-coherence-cache-config.xml
前述の注意を参照してください。
Coherenceキャッシュ・サーバーの起動に次の引数を追加してホストとポートを設定します。
-DOSB.coherence.localhost=
HOSTNAME
および-DOSB.coherence.localport=
PORT
(host:portはクラスタ内で一意)
クラスタ・メンバーシップにユニキャスト・リスナーを使用(推奨)し、表36-8に示されているように既知のリスナーをosb-coherence-override.xmlファイルに含めない場合は、次の引数を使用してCoherenceキャッシュ・サーバーに必要な数の既知のアドレスを追加します。
-DOSB.coherence.wka[1-9]
および-DOSB.coherence.wka[1-9].port
Oracle Service BusでのOracle Coherenceへのユニキャストの使用の詳細は、『Oracle Fusion Middleware高可用性ガイド』のOracle Service Busの結果キャッシュに対するOracle Coherenceの構成に関する説明を参照してください。
次の起動引数を使用して、Coherenceクラスタの名前がOracle Service Busサーバーとプロセス外Coherenceキャッシュ・サーバーで同じになるようにします。
-Dtangosol.coherence.cluster=OSB-cluster
Oracle Service Busクラスタは常に「OSB-cluster」という名前で呼び出されます。
サーバーの起動
この手順の最初で説明したとおり、Oracle Service Busサーバーでローカル・キャッシュを無効にする必要があるプロセス外Coherenceキャッシュ・サーバーを使用する場合は、必ずOracle Service Busサーバーを起動する前にプロセス外Coherenceキャッシュ・サーバーを起動してください。
Coherenceキャッシュ・サーバーを起動する1つの方法として、必要な引数を指定してJavaコマンドを使用する方法があります。次の起動コマンドの例では、ホスト、ポートおよび既知のアドレス(ユニキャスト・リスナー)の適切な構成がosb-coherence-override.xmlに含まれていることを想定しています。
java -classpath coherence.jar:C:/oracle/Oracle_OSB1/lib/osb-coherence-client.jar -Dtangosol.coherence.override=C:/oracle/user_projects/domains/osb_domain/config/osb/coherence/osb-coherence-override.xml -Dtangosol.coherence.cacheconfig=C:/oracle/user_projects/domains/osb_domain/config/osb/coherence/osb-coherence-cacheconfig.xml -Dtangosol.coherence.cluster=OSB-cluster com.tangosol.net.DefaultCacheServer
Coherenceキャッシュ・サーバーの起動の詳細は、http://download.oracle.com/docs/cd/E15357_01/index.htm
にあるOracle Coherenceのドキュメントを参照してください。
Oracle Coherence構成フレームワークを使用すると、様々なキャッシュ構成を、アプリケーションを変更することなく、柔軟に行うことができます。たとえば、属性を使用してキャッシュのタイプや動作を変更したり、キャッシュに問い合せたりできます。詳細は、次を参照してください。
『Oracle Fusion Middleware高可用性ガイド』のOracle Service Busの結果キャッシュに対するOracle Coherenceの構成に関する説明
http://download.oracle.com/docs/cd/E15357_01/index.htm
にあるOracle Coherenceのドキュメント
Oracle Service Busでは、URLを介してOracle Service Busに登録されたリソースを表示するために使用されるリソース・サーブレットが提供されます。詳細は、4.30項「Webブラウザでのリソースの表示」を参照してください。