ユーザーズ ガイド

     前  次    目次     
ここから内容

プロキシ サービスとビジネス サービスのコンフィグレーション

Oracle Service Bus のプロキシ サービスとビジネス サービスを使用すると、サービスの管理、メッセージの変換、およびエンタープライズ全体でのメッセージのルーティングを行うことができます。

プロキシ サービスとビジネス サービスは、実行時環境 (Oracle Service Bus Console) または開発環境 (Workshop for WebLogic 用の Oracle Service Bus プラグイン) を使用して作成およびコンフィグレーションできます。既存の 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 バインディングも含まれます (「WSDL を使用したサービスの定義」を参照)。

 

Oracle Service Bus ビジネス サービス

Oracle Service Bus ビジネス サービスは、Oracle Service Bus がクライアントとなるエンタープライズ Web サービスの定義です。これらの外部 Web サービスは、外部システムに実装され、外部システムによってホストされます。そのため、Oracle Service Bus は呼び出す対象、呼び出す方法、および呼び出しの結果として予想される内容を認識しておく必要があります。Oracle Service Bus が外部サービスを呼び出すことができるように、Oracle Service Bus ビジネス サービスではそのインタフェースをモデル化しています。

ビジネス サービスのコンフィグレーションには、インタフェース、転送設定、およびセキュリティ 設定が含まれます (メッセージ フロー定義は含まれません)。ビジネス サービスが WSDL に基づいている場合、コンフィグレーションには WSDL ポートまたは WSDL バインディングも含まれます (「WSDL を使用したサービスの定義」を参照)。

 

Oracle Service Bus で WSDL が使用されるしくみ

Oracle Service Bus では、WSDL (Web サービスを記述するための XML ベースの仕様) を使用して、複数のタイプのビジネス サービスとプロキシ サービスを定義します。WSDL ドキュメントには、サービス操作、入力/出力パラメータ、およびクライアントがサービスに接続する方法が記述されます。WSDL 1.1 仕様については、W3C Note の「W3C Web Services Description Language (WSDL) 1.1 (英文)」を参照してください。

有効な WSDL と生成された WSDL について

Oracle Service Bus では、「WSDL リソース」と呼ばれる既存の 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 ベースのサービスをサポートする転送 (HTTP、JMS、SB など) を使用して、これらのタイプのサービスの有効な WSDL を生成できます。

Oracle Service Bus では、次のタイプのプロキシ サービスおよびビジネス サービスの有効な WSDL を生成できません。

有効な WSDL は、プロキシ サービスとビジネス サービス、および WSDL ポートに基づくサービスと WSDL バインディングに基づくサービスのさまざまな特性を備えています。これらの特性については、このドキュメント全体を通じて説明しています。特に、「WSDL ポートと WSDL バインディングに基づくサービスの作成」を参照してください。

生成された WSDL

「生成された WSDL」とは、WSDL リソースから作成されてはいないが、WSDL を使用して記述できる転送型サービス用に Oracle Service Bus が生成する有効な WSDL です。たとえば、EJB ベースのサービスから生成された WSDL は「生成された WSDL」です。

有効な WSDL へのアクセス

有効な WSDL には、以下の 3 とおりの方法でアクセスできます。

WSDL の概要

WSDL ドキュメントでは、サービス、サービスの場所、サービス操作、およびクライアントがサービスと通信する方法を記述します。この節では、Oracle Service Bus の機能を説明する際のコンテキストを提供するために、WSDL の概要を簡単に説明します。

WSDL サービスの定義に使用する主な要素を表 2-1 に示します。

WSDL では、SOAP、HTTP、MIME、および Oracle Service Bus 固有のバインディング拡張が指定されます。これらのバインディング拡張では、WSDL バインディング メカニズムを拡張することで、プロトコル固有またはメッセージ フォーマット固有の機能をサポートします。

型

<types> 要素は、データ型定義のコンテナです。この要素では、XML スキーマ (XSD) などの型システムを使用して、このサービスで処理されるメッセージのボキャブラリを定義します。たとえば、株価を提供するサービスの場合、コード リスト 2-1 に示すように、TradePriceRequest および TradePrice という用語によって XML ボキャブラリを定義できます。

コード リスト 2-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 つまたは複数の部分を含めることができます。たとえば、コード リスト 2-2 の WSDL フラグメントでは、sellerInfoMessage、buyerInfoMessage、response、および negotiationMessage の 4 つのメッセージ タイプが定義されており、各メッセージ タイプには 1 つまたは複数の部分が含まれています。

コード リスト 2-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> 要素で定義されます。

たとえば、コード リスト 2-3 のフラグメントでは、入力メッセージ (GetLastTradePriceInput) と出力メッセージ (GetLastTradePriceOuput) を処理できる GetLastTradePrice という 1 つの操作でポート タイプが定義されています。コード リスト 2-4 の <soap:operation> 下位要素に示すように、これらのメッセージの具体的な記述は WSDL バインディングで定義されています。

コード リスト 2-3 WSDL のポート タイプと操作の例 
<portType name="StockQuotePortType">
    <operation name="GetLastTradePrice">
        <input message="tns:GetLastTradePriceInput"/>
        <output message="tns:GetLastTradePriceOutput"/>
    </operation>
</portType>

バインディング

<binding> 要素では、ポート タイプの具体的なデータ フォーマット仕様と具体的な転送プロトコルを指定します。

コード リスト 2-4 のフラグメントでは、type 属性の値として示された StockQuotePortType ポート タイプのバインディングを指定しています。<soap:binding> 下位要素は、このバインディングが SOAP プロトコル形式にバインドされることを示します。この下位要素では、style 属性でデータ フォーマットが SOAP ドキュメント スタイルであることを指定し、transport 属性で転送プロトコルが HTTP であることを指定しています。

コード リスト 2-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> 子要素で定義されます。ポートでは、ネットワーク アドレスに関連付けられたバインディングを定義します。たとえば、コード リスト 2-5 のフラグメントでは、StockQuotePort と StockQuotePortUK の 2 つのポートが定義されています。この 2 つのポートは、(<binding> で具体的に定義された) tns:StockQuoteSoapBinding という同じバインディングを使用していますが、ネットワーク アドレスは異なります (http://example.com/stockquote と http://example.uk/stockquote)。これらのポートは、このサービスで使用できる代替ポートです。

コード リスト 2-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 インタフェースが明確に定義されている場合、WSDL を使用してサービスを定義することをお勧めします。ただし、これは必須ではありません。

3 タイプの WSDL を定義できます。次の 3 タイプです。

SOAP ドキュメント ラップの Web サービス

ドキュメント ラップの Web サービスは、ドキュメント スタイルのサービスとして WSDL に記述されています。ただし、いくつかの追加規約に従います。標準のドキュメント指向の Web サービス操作では、1 つのパラメータまたはメッセージ部分だけを取得します (通常は、XML ドキュメントを取得します)。つまり、操作を実装するメソッドに含まれるパラメータも 1 つだけである必要があります。これに対して、ドキュメント ラップの Web サービス操作では、パラメータをいくつでも取得できます。パラメータ値は、SOAP メッセージ内の 1 つの複合データ型にラップされます。このラップされた複合データ型は、操作の 1 つのドキュメントとして WSDL に記述されます。

SOAP ドキュメント スタイルの Web サービス

プロキシ サービスを SOAP スタイルのプロキシ サービスとしてコンフィグレーションし、ビジネス サービスを SOAP スタイルのビジネス サービスとしてコンフィグレーションすることができます。

SOAP 1.1 を使用するドキュメント スタイルの Web サービスの WSDL の例をコード リスト 2-6 に示します。

コード リスト 2-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) の値をコード リスト 2-7 に示します。

注意 : わかりやすくするために、次のコード リストでは XML からネームスペース宣言を削除しています。
コード リスト 2-7 body 変数の値 
<soap-env:body>
  <req:purchaseorg>Oracle</req:purchaseorg>
</soap-env:body>

コード リスト 2-7 では、soap-env は定義済みの SOAP 1.1 ネームスペースであり、req は PurchaseOrg 要素のネームスペース (http://example.com/lookup/docs) です。

プロキシ サービスによるルーティング先となるビジネス サービスで上記の WSDL を使用した場合、上記の body 変数 ($body) の値はプロキシ サービスの body 変数 ($body) の値になります。

呼び出されたビジネス サービスからプロキシ サービスが受信する応答の body 変数 ($body) の値をコード リスト 2-8 に示します。

注意 : わかりやすくするために、次のコード リストでは XML からネームスペース宣言を削除しています。
コード リスト 2-8 body 変数の値 
<soap-env:body>
  <req:legacyboolean>true</req:legacyboolean>
</soap-env:body>

これは、この WSDL を使用するプロキシ サービスによって返される応答の body 変数 ($body) の値でもあります。

Oracle Workshop for WebLogic ツールをはじめとする多くのツールでは、プロキシ サービスの WSDL (ブラウザで、プロキシ サービスの URL に ?WSDL サフィックスを追加することによって取得) を受け取り、適切な要求パラメータと応答パラメータを持つ Java クラスを生成して、サービスの操作を呼び出します。この Java クラスを使用して、この WSDL を使用するプロキシ サービスを呼び出すことができます。

SOAP RPC の Web サービス

プロキシ サービスを RPC スタイルのプロキシ サービスとしてコンフィグレーションし、ビジネス サービスを RPC スタイルのビジネス サービスとしてコンフィグレーションすることができます。

SOAP 1.1 を使用する RPC スタイルの Web サービスの WSDL の例をコード リスト 2-9 に示します。

コード リスト 2-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

コード リスト 2-9 の WSDL を要求に使用したときに、SOAP RPC プロキシ サービスが取得する body 変数 ($body) の値をコード リスト 2-10 に示します。

注意 : わかりやすくするために、次のコード リストでは XML からネームスペース宣言を削除しています。
コード リスト 2-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) です。

プロキシ サービスによるメッセージのルーティング先となるビジネス サービスでコード リスト 2-10 の WSDL を使用した場合、コード リスト 2-11 に示す body 変数 ($body) の値は、プロキシ サービスの body 変数 ($body) の値になります。

この WSDL を要求に使用したときに、呼び出されたビジネス サービスからプロキシ サービスが受信する応答の body 変数 ($body) の値をコード リスト 2-10 に示します。

コード リスト 2-11 body 変数の値 
<soap-env:body>
  <ns:lookupResponse>
    <result>
      <req:legacyboolean>true</req:legacyboolean>
    </result>
  </ns:lookupResponse>
<soap-env:body>

これは、この WSDL を使用するプロキシ サービスによって返される応答の body 変数 ($body) の値でもあります。

Oracle Workshop for WebLogic ツールをはじめとする多くのツールでは、プロキシ サービスの WSDL (ブラウザで、プロキシの URL に ?WSDL サフィックスを追加することによって取得) を受け取り、適切な要求パラメータと応答パラメータを持つ Java クラスを生成して、サービスの操作を呼び出します。このような Java クラスを使用して、この WSDL を使用するプロキシ サービスを呼び出すことができます。

WSDL を使用する利点は次のとおりです。

 

WSDL ポートと WSDL バインディングに基づくサービスの作成

WSDL リソースに基づいてサービスを作成する場合、サービスは次のように WSDL ポートまたは WSDL バインディングに基づいている必要があります。

サービスを作成または変更するときに、転送方式は変更できますが、データ フォーマットをオーバーライドすることはできません。

元の WSDL リソースのポート定義とバインディング定義は、以下で説明するさまざまな要因に応じて有効な WSDL 内で変更されます。

プロキシ サービス用に生成される有効な WSDL の特性

プロキシ サービス用に生成される有効な WSDL には、以下の特性があります。

非転送型ビジネス サービス用に生成される有効な WSDL の特性

非転送型ビジネス サービス用に生成される有効な WSDL には、以下の特性があります。

転送型ビジネス サービス用に生成される有効な WSDL の特性

Oracle Service Bus は、転送型ビジネス サービス用に生成される有効な WSDL の wsdl:service セクションが 1 つだけであることを保証しません。WSDL は転送によって生成されるため、Oracle Service Bus が service セクションと port セクションを生成することはなく、クリーンアップも行いません。ただし、Oracle Service Bus は依存関係を評価し、エクスポート時に参照を設定します。

クラスタ化されたドメインでの有効な WSDL の生成

クラスタ化されたドメインで有効な WSDL を生成する場合、Oracle Service Bus はサーバまたはクラスタのコンフィグレーションに基づいてエンドポイント URL を書き換えます。フロントエンド HTTP ホスト/ポート (または HTTPS エンドポイントのフロントエンド HTTPS ホスト/ポート) が指定されている場合は、そのホストまたはポートが使用されます。それ以外の場合は、管理対象サーバのホストまたはポートが使用されます。クラスタ化されたドメインでは、フロントエンド HTTP または HTTPS ホスト/ポートを割り当てることを強くお勧めします。

ポートとバインディングに基づくプロキシ サービスの例

WSDL リソースのポート定義とバインディング定義のフラグメントをコード リスト 2-12 に示します。

コード リスト 2-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>
ポートに基づくサービスの作成

コード リスト 2-12 の StockQuotePort ポートに基づいてプロキシ サービスを作成すると、有効な WSDL はコード リスト 2-13 のフラグメントのようになります。

コード リスト 2-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>

上記の例について、以下の点に注意してください。

バインディングに基づくサービスの作成

コード リスト 2-12 の StockQuoteBinding バインディングに基づいてプロキシ サービスを作成すると、有効な WSDL はコード リスト 2-14 のフラグメントのようになります。

コード リスト 2-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>

上記の例について、以下の点に注意してください。

任意の SOAP サービス タイプまたは任意の XML サービス タイプの使用

1 つのポートだけをエクスポーズしてクライアントにさまざまなエンタープライズ アプリケーションを提供する場合は、[任意の SOAP サービス] または [任意の XML サービス] を使用します。任意の SOAP の場合、SOAP 1.1 と SOAP 1.2 のどちらであるかを指定する必要があります。

メッセージング サービス タイプの使用

要求メッセージまたは応答メッセージのいずれかが XML 以外である場合、メッセージング サービス タイプを使用する必要があります。

Oracle Service Bus では、「misunderstand」SOAP ヘッダのチェックは自動では行われません。ただし、XQuery 条件式と検証アクションを使用することで、この種のチェックを明示的に実行できます。検証アクションの詳細については、『Oracle Service Bus Console の使い方』の「検証アクションの追加」、または『Workshop for WebLogic 用 Oracle Service Bus プラグインの使用』の「検証アクションのプロパティ」を参照してください。XQuery 条件式の詳細については、『Oracle Service Bus Console の使い方』のプロキシ サービス : エディタ、または『Workshop for WebLogic 用 Oracle Service Bus プラグインの使用』の「条件エディタ」を参照してください。

Oracle Service Bus を使用して検証アクションをコンフィグレーションし、メッセージ フローで XQuery 条件式を使用して検証チェックを明示的に実行できます。

サービス タイプの詳細については、『Oracle Service Bus Console の使い方』の「プロキシサービスの作成とコンフィグレーション」にある「[全般的なコンフィグレーション] ページ」を参照してください。

 

プロキシ サービスのコンフィグレーション

以下の節では、プロキシ サービスのコンフィグレーションの概要を説明します。プロキシ サービスをコンフィグレーションする際の特定の手順については、以下を参照してください。

プロキシ サービスのタイプと転送方式

各プロキシ サービスは特定のタイプであり、それぞれのタイプに適した転送プロトコルで使用できます。Oracle Service Bus では、複数の標準転送とカスタム転送をサポートしています。サービス タイプと各タイプで使用できる標準転送を表 2-2 に示します。

表  2-2 Oracle Service Bus でサポートされるプロキシ サービスのタイプと転送方式
サービス タイプ
説明
このサービス タイプでサポートされる標準の転送プロトコル
WSDL Web サービス
WSDL ドキュメントでインタフェースが記述された SOAP プロキシ サービスまたは XML プロキシ サービス。
HTTP
JCA
JMS
ローカル
SB
WS
任意の SOAP サービス
(WSDL なし)
明示的に定義された具象インタフェースを持たない SOAP サービス。
HTTP
JMS
ローカル
SB
任意の XML サービス
(SOAP 以外、WSDL なし)
明示的に定義された具象インタフェースを持たない XML サービス。
電子メール
ファイル
FTP
HTTP
JMS
ローカル
MQ
SB
SFTP
Tuxedo
メッセージング サービス
(WSDL なし)
バイナリ、テキスト、MFL、XML などのさまざまなデータ型の要求メッセージと応答メッセージを使用できるメッセージング サービス。
電子メール
ファイル
FTP
HTTP
JMS
ローカル
MQ
SFTP
Tuxedo

注意 : すべてのサービス タイプで、MIME を使用して添付ファイルを送受信できます。

プロキシ サービスの転送とセキュリティのコンフィグレーション

Oracle Service Bus Console または Workshop for WebLogic 用 Oracle Service Bus プラグインで、プロキシ サービスのすべてのタイプの転送設定をコンフィグレーションする必要があります。コンフィグレーションの詳細は、転送の種類によって異なります。特定のコンフィグレーション設定については、以下を参照してください。

選択する転送は、バインディング定義で必要とされる転送モード (要求/応答、一方向、または両方) をサポートする必要があり、それに従ってコンフィグレーションする必要があります。

両方のモードでメッセージを交換するサービスの場合、(要求/応答を 2 つの非同期呼び出しとして実装する JMS などの転送で) 転送モードを適宜選択するようにバインディング レイヤをコンフィグレーションする必要があります。サービスが具象型の場合、バインディング定義の記述に従って、この選択が自動的に行われます。サービスが具象型でない場合、バインディング レイヤをコンフィグレーションするには、$outbound 変数でモードを設定する必要があります。

転送方式と WSDL に基づいて、転送モードが自動的に選択されますが、$inbound または $outbound で上書きできます。

サービス プロバイダを使用して、プロキシ サービスのセキュリティを指定できます。サービス プロバイダが必要となるのは、プロキシ サービスがクライアント証明書認証を必要とする HTTPS サービスにメッセージをルーティングする場合です。また、一部のメッセージ レベルのセキュリティ シナリオで必要となる場合もあります。

サービス アカウントを作成して、ビジネス サービスへの接続時に認証を行うことができます。サービス アカウントは、必要なユーザ名とパスワードの組み合わせのエリアス リソースとして機能します。

WebLogic Server を使用して、資格レベルの検証を必要とするビジネス サービスのセキュリティ資格を直接管理することができます。

詳細については、『Oracle Service Bus Console の使い方』の「サービス キー プロバイダ」を参照してください。また、「プロキシ サービスのセキュリティ関連の検証」も参照してください。

プロキシ サービスの各タイプのコンフィグレーション設定

プロキシ サービスの各タイプは、同じパターンに従ってモデル化されています。各サービス タイプでは、以下のコンフィグレーションを定義する必要があります。

プロキシ サービスの各タイプに固有のコンフィグレーションのプロパティを表 2-3 に示します。

表 2-3 プロキシ サービスのさまざまなタイプのコンフィグレーションのプロパティ
プロキシ サービスのタイプ
コンフィグレーションのプロパティ
WSDL Web サービス
バインディング定義 : 「WSDL を使用したサービスの定義」を参照してください。
実行時変数 :
任意の SOAP サービス
バインディング定義 : このサービス タイプで定義する情報は、WSDL バインディング定義に関係なく、サービスで SOAP メッセージを受信または送信するということだけです。したがって、このタイプのバインディング コンフィグレーションは空になります。
また、バインディング コンフィグレーションが存在しないため、このタイプとメッセージのコンテンツ タイプの組み合わせから、メッセージに添付ファイルがあるかどうかを十分判別できます。
定義上、「任意の」サービス (SOAP または XML) には WSDL 定義はありません。これらのサービスの WSDL ドキュメントを生成または表示することはできません。
実行時変数 :
$body 変数と $header 変数に、受信 SOAP メッセージの <soap:Body> と <soap:Header> がそれぞれ保持されます (SOAP 1.1 プロキシの場合、$body と $header では SOAP 1.1 ネームスペース本体とネームスペースを使用し、SOAP 1.2 プロキシでは SOAP 1.2 ネームスペース本体とネームスペースを使用します)。
SOAP メッセージに添付ファイルがある場合は、$attachments 変数に格納されます。
ポート タイプを定義しないため、$operation 変数はこのサービス タイプには適用されません。
メッセージ コンテキスト変数の詳細については、「メッセージ関連の変数」 および「送信するメッセージの作成」を参照してください。
任意の XML サービス
バインディング定義 : このサービス タイプで定義する情報は、WSDL バインディング定義に関係なく、サービスで XML メッセージを受信または送信するということだけです。したがって、このタイプのバインディング コンフィグレーションは空になります。
また、バインディング コンフィグレーションが存在しないため、このタイプとメッセージのコンテンツ タイプの組み合わせから、メッセージに添付ファイルがあるかどうかを十分判別できます。
定義上、「任意の」サービス (SOAP または XML) には WSDL 定義はありません。これらのサービスの WSDL ドキュメントを要求することはできません。
実行時変数 :
$body 変数には、<soap:Body> 要素内にラップされた受信 XML メッセージが保持されます (SOAP 1.1 プロキシの場合、$body と $header では SOAP 1.1 ネームスペース本体とネームスペースを使用し、SOAP 1.2 プロキシでは SOAP 1.2 ネームスペース本体とネームスペースを使用します)。
メッセージに添付ファイルがある場合は、$attachments 変数に格納されます。
$header 変数はこのサービス タイプには適用されず、デフォルト値に設定されます。
ポート タイプを定義しないため、$operation 変数はこのサービス タイプには適用されません。
メッセージ コンテキスト変数の詳細については、「メッセージ関連の変数」 および「送信するメッセージの作成」を参照してください。
メッセージング サービス
バインディング定義 : メッセージング サービスのバインディング定義は、交換されるメッセージのコンテンツ タイプのコンフィグレーションで構成されます。応答のコンテンツ タイプは、要求のコンテンツ タイプと同じである必要はありません。そのため、応答は個別にコンフィグレーションされます (たとえば、サービスで MFL メッセージを受け入れ、XML の受信確認を返すことができます)。また、応答のコンテンツ タイプを [なし] に設定することもできます。
定義上、メッセージング ベースのサービスには WSDL 定義はありません。これらのサービスの WSDL ドキュメントを要求することはできません。
要求 (および応答) のコンテンツ タイプは、次の 4 つの中から選択できます。
  • バイナリ
  • テキスト
  • XML
  • MFL
実行時変数 :
このサービス タイプはメッセージ ベースです。Web サービスには、複数の「操作」という概念はありません。したがって、$operation 変数は空のままになります。
$body 変数には、<soap:Body> 要素内にラップされた受信メッセージが保持されます (SOAP 1.1 プロキシの場合、$body ではSOAP 1.1 ネームスペース本体を使用し、SOAP 1.2 プロキシでは、SOAP 1.2 ネームスペース本体を使用します)。
$header 変数はこのサービス タイプには適用されず、デフォルト値に設定されます。
メッセージに添付ファイルがある場合は、$attachments 変数に格納されます。
メッセージ コンテキスト変数の詳細については、「メッセージ関連の変数」 および「送信するメッセージの作成」を参照してください。

メッセージ フローのコンフィグレーション

プロキシ サービスのメッセージ フロー定義では、プロキシ サービスを介したメッセージ フローでメッセージを処理する方法を決定するロジックを定義します。メッセージ フロー定義では、必要に応じてメッセージを変換し、メッセージ データをビジネス サービス (発信メッセージの場合) または送信元のクライアント (着信メッセージの場合) に必要なフォーマットにマップします。次に、メッセージは適切な場所にルーティングされます。メッセージ フローのコンフィグレーションについては、「Oracle Service Bus でのメッセージ フローの作成」を参照してください。

プロキシ サービスのセキュリティ関連の検証

アクティブなプロキシ サービスへの変更が含まれるセッションをアクティブ化する場合、Oracle Service Bus は変更を検証して、プロキシ サービスの静的なエンドポイントに必要なすべての資格が作成されているかどうかを確認します。たとえば、Web サービスを静的なエンドポイントとして使用するようにプロキシ サービスをコンフィグレーションしており、その Web サービスがデジタル署名を必要とする場合、Oracle Service Bus はプロキシ サービスにサービス キー プロバイダが関連付けられているかどうか、また、サービス キー プロバイダにデジタル署名として使用できるキーペア バインディングが含まれているかどうかを検証します。

セッションにサービス キー プロバイダのキーペア バインディングへの変更が含まれている場合は、そのサービス キー プロバイダを使用するすべてのプロキシ サービスに対して変更が検証されます。たとえば、暗号化用のキーペアを削除すると、暗号化が必要なエンドポイントを含むプロキシ サービス プロバイダを参照しているプロキシ サービスに対して、検証エラーが報告されます。

以下の条件により、セキュリティ関連の検証が実行されるタイミングと、検証中に行われるアクションが決定されます。

 

ビジネス サービスのコンフィグレーション

以下の節では、ビジネス サービスのコンフィグレーションの概要を説明します。ビジネス サービスをコンフィグレーションする際の特定の手順については、以下を参照してください。

ビジネス サービスのタイプと転送方式

各ビジネス サービスは特定のタイプであり、それぞれのタイプに適した転送プロトコルで使用できます。Oracle Service Bus では、複数の標準転送とカスタム転送をサポートしています。サービス タイプと各タイプで使用できる標準転送を表 2-4 に示します。

表 2-4 Oracle Service Bus でサポートされるビジネス サービスのタイプと転送方式
サービス タイプ
説明
転送プロトコル
WSDL Web サービス
WSDL ドキュメントでインタフェースが記述された SOAP ビジネス サービスまたは XML ビジネス サービス。
DSP
HTTP
JMS
JPD
ローカル1
SB
WS
任意の SOAP サービス
(WSDL なし)
明示的に定義された具象インタフェースを持たない SOAP サービス。
DSP
HTTP
JMS
JPD
ローカル
SB
任意の XML サービス
(WSDL なし)
明示的に定義された具象インタフェースを持たない XML サービス。
WSDL を使用しない XML でサポートされているのは HTTP GET だけです。
DSP
電子メール
ファイル
FTP
HTTP GET
JMS
JPD
ローカル
MQ
SB
SFTP
Tuxedo2
転送型付きのサービス
(WSDL なし)
EJB 転送を使用するサービス。
EJB
フロー
メッセージング タイプのサービス
(WSDL なし)
バイナリ、テキスト、MFL、XML などのさまざまなデータ型の要求メッセージと応答メッセージを使用できるメッセージング サービス。
電子メール
ファイル
FTP
HTTP GET
JMS
ローカル
MQ
SFTP
Tuxedo

12 つのプロキシ サービス間の通信には、ローカル転送を使用することをお勧めします。ローカル転送の詳細については、『ローカル転送ユーザーズ ガイド』を参照してください。

2Tuxedo 転送ベースのサービスでは、サービス タイプが XML の場合、Tuxedo クライアントの FLD_MBSTRING フィールドを含む FML32 バッファは XML に変換されません。

2さまざまな転送プロトコルに基づいてプロキシ サービスとビジネスサービスをコンフィグレーションする方法については、「Oracle Service Bus の転送」ページを参照してください。

ビジネス サービスのすべてのタイプのコンフィグレーション設定

ビジネス サービスの各タイプは、同じパターンに従ってモデル化されています。各サービス タイプでは、以下のコンフィグレーションを定義する必要があります。

表 2-5 に示すビジネス サービスのコンフィグレーションのプロパティは、すべてのサービス タイプに共通するものです。各サービス タイプに固有のプロパティについては、「ビジネス サービスの各タイプのコンフィグレーション設定」を参照してください。

表 2-5 ビジネス サービスの共通するコンフィグレーションのプロパティ
プロパティ
説明
リソース定義
リソース定義は、以下で構成されます。
  • サービス名 (プロジェクト名、パス名、およびローカル名)
  • サービスの説明 (省略可能)
  • サービス タイプ
転送コンフィグレーション
各ビジネス サービスの以下のパラメータをコンフィグレーションできます。
  • <string URI, integer weight> のペア (<http://www.oracle.com, 100> など) のリスト。ランダムな重みベースのリストには、少なくとも 1 つの要素が含まれます。
  • ロード バランシング アルゴリズム - 列挙値 (ラウンドロビン、ランダム、ランダムな重みベースのいずれか)。ランダムな重みベースを選択すると、各 URI に重みを適用できます。
  • 再試行回数
  • 再試行の反復間隔
  • アプリケーション エラーの再試行
選択する転送方式は、バインディング定義で必要とされる転送モード (要求/応答、一方向、または両方) をサポートできる必要があり、それに従ってコンフィグレーションする必要があります。
両方のモード (要求/応答と一方向) でメッセージを交換するサービスでは、転送モードを適宜選択できるようにバインディング レイヤをコンフィグレーションする必要があります。サービスが具象型の場合、バインディング定義の記述に従って、この選択が自動的に行われます。サービスが具象型でない場合、バインディング レイヤをコンフィグレーションするには、メッセージ フローでルーティング オプション アクションを使用して、ルートまたはパブリッシュのモードを設定する必要があります。
転送方式と WSDL またはインタフェースに基づいて、転送モードが自動的に選択されますが、ルート アクションまたはパブリッシュ アクションのルーティング オプション アクションを使用して上書きできます。

ビジネス サービスの各タイプのコンフィグレーション設定

ビジネス サービスの各タイプに固有のコンフィグレーションのプロパティを表 2-6 に示します。

表 2-6 ビジネス サービスのさまざまなタイプのコンフィグレーションのプロパティ
プロパティ
説明
WSDL Web サービス
「WSDL を使用したサービスの定義」を参照してください。
任意の SOAP サービス
バインディング定義 : このサービス タイプで定義する情報は、WSDL バインディング定義に関係なく、サービスで SOAP メッセージを受信または送信するということだけです。したがって、このタイプのバインディング コンフィグレーションは空になります。
また、バインディング コンフィグレーションが存在しないため、このタイプとメッセージのコンテンツ タイプの組み合わせから、メッセージに添付ファイルがあるかどうかを十分判別できます。
定義上、任意のサービス (SOAP または XML) には WSDL 定義はありません。
実行時変数 :
$body 変数と $header 変数に、ビジネス サービスにルーティングまたはパブリッシュされる SOAP メッセージの <soap:Body> と <soap:Header> がそれぞれ保持されます (SOAP 1.1 プロキシの場合、$body と $header では SOAP 1.1 ネームスペース本体とネームスペースを使用し、SOAP 1.2 プロキシでは SOAP 1.2 ネームスペース本体とネームスペースを使用します)。
SOAP メッセージに添付ファイルがある場合は、$attachments 変数に格納されます。
メッセージ コンテキスト変数の詳細については、「メッセージ関連の変数」を参照してください。
転送型付き
転送型付きのサービスには空のバインディング定義があり、EJB ビジネス サービスにのみ適用されます。WSDL は指定されません。代わりに、転送によってサービスの WSDL が自動的に定義されます。この WSDL を含む zip は、Oracle Service Bus Console または Workshop for WebLogic 用 Oracle Service Bus プラグインからエクスポートできます。この WSDL では、ポートは定義されません。
EJB 転送型付きサービスは、Oracle Service Bus から EJB にアクセスするための発信転送です。これは、サービス インタフェースを記述する WSDL を生成する自己記述型の転送です。EJB 転送は、トランザクションとセキュリティ コンテキストの伝播を特徴とします。
EJB 転送を使用して構築されたビジネス サービスは、パブリッシュ、サービス コールアウト、およびサービス呼び出しに使用できます。
任意の XML サービス
バインディング定義 : このサービス タイプで定義する情報は、WSDL バインディング定義に関係なく、サービスで XML メッセージを受信または送信するということだけです。したがって、このタイプのバインディング コンフィグレーションは空になります。
また、バインディング コンフィグレーションが存在しないため、このタイプとメッセージのコンテンツ タイプの組み合わせから、メッセージに添付ファイルがあるかどうかを十分判別できます。
定義上、任意のサービス (SOAP または XML) には WSDL 定義はありません。
実行時変数 :
$body 変数には、<soap:Body> 要素内にラップされた受信 XML メッセージが保持されます (SOAP 1.1 プロキシの場合、$body では SOAP 1.1 ネームスペース本体を使用し、SOAP 1.2 プロキシでは SOAP 1.2 ネームスペース本体を使用します)。
メッセージに添付ファイルがある場合は、$attachments 変数に格納されます。
$header 変数はこのサービス タイプには適用されず、デフォルト値に設定されます。
メッセージ コンテキスト変数の詳細については、「メッセージ関連の変数」を参照してください。
メッセージング サービス
バインディング定義 : メッセージング サービスのバインディング定義は、交換されるメッセージのコンテンツ タイプのコンフィグレーションで構成されます。応答のコンテンツ タイプは、要求のコンテンツ タイプと同じである必要はありません。そのため、応答は個別にコンフィグレーションされます (たとえば、サービスで MFL メッセージを受け入れ、XML の受信確認を返すことができます)。
定義上、メッセージング ベースのサービスには WSDL 定義はありません。これらのサービスの WSDL ドキュメントを要求することはできません。
要求 (および応答) には、以下のコンテンツ タイプを使用できます。
  • バイナリ
  • テキスト
  • XML
  • MFL
  • なし
実行時変数 :
このサービス タイプはメッセージ ベースです。
$body 変数には、<soap:Body> 要素内にラップされた受信メッセージが保持されます (SOAP 1.1 プロキシの場合、$body では SOAP 1.1 ネームスペース本体を使用し、SOAP 1.2 プロキシでは SOAP 1.2 ネームスペース本体を使用します)。
$header 変数はこのサービス タイプには適用されず、デフォルト値に設定されます。
メッセージに添付ファイルがある場合は、$attachments 変数に格納されます。
メッセージ コンテキスト変数の詳細については、「メッセージ関連の変数」を参照してください。

ビジネス サービスで Web サービス セキュリティが必要な場合は、ビジネス サービスの作成時に、指定する WSDL に必要な WS-Policy がアタッチされていることを確認してください。さらに、ビジネス サービスの WS-Policy により暗号化が必要な場合は、ビジネス サービスのパブリック証明書が WSDL に埋め込まれていることを確認してください。ビジネス サービスが WebLogic Server 9.0 以降の Web サービスである場合は、http://<host>:<port>/<service url>?WSDL という URL を使用して WSD を取得できます。必要に応じて、パブリック証明書が自動的に埋め込まれます。

プロキシ サーバの使用

プロキシ サーバを介してメッセージをルーティングするように、ビジネス サービスをコンフィグレーションできます。これを行うには、必要な資格と共に 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 のみをサポートするサーバもあります。たとえば、Sun 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 Service Bus に登録されたリソースをエクスポーズする際に使用するリソース サーブレットが用意されています。Oracle Service Bus に登録されているリソースは次のとおりです。

リソースをエクスポーズする際に使用する URL の形式も示します。

以下の URL 形式を使用して、リソースの詳細をエクスポーズできます。

注意 : Oracle Service Bus でリソースのエクスポーズに使用する URL は、特殊文字をエスケープするために UTF-8 でコード化する必要があります。

  ページの先頭       前  次