HTTP バインディングコンポーネントの使用

本書は Java Composite Application Platform Suite 6 (Java CAPS) に適用できます。

このガイドでは、HTTP バインディングコンポーネントの概要を説明し、JBI プロジェクトでバインディングコンポーネントを設定および配備するために必要な詳細について記述します。HTTP バインディングコンポーネントは、JBI 1.0 準拠の環境で SOAP over HTTP 接続を提供します。HTTP バインディングコンポーネントは、JBI 環境のサービスへの接続をサポートするプロバイダプロキシとしても、サービスを呼び出すコンシューマプロキシとしても使用されます。HTTP バインディングコンポーネントは、Java Business Integration コンポーネントインタフェースを実装する、JSR 208 準拠の JBI ランタイムコンポーネントです。

詳細は、Java CAPS の Web サイト http://goldstar.stc.com/support を参照してください。

必要な知識

HTTP バインディングコンポーネントを使用する前に必要な知識については、次のリンクを参照してください。

• 「HTTP バインディングコンポーネントについて」

• 「HTTP/SOAP バインディングのアーキテクチャー」

• 「HTTP バインディングコンポーネントの機能」

• 「HTTP バインディングコンポーネントのシナリオ例」

参照情報

HTTP バインディングコンポーネントの設定と使用に関する追加の参照情報については、次のリンクを参照してください。

• 「SOAP 処理」

• 「HTTP 処理」

• 「HTTP GET および POST 処理」

• 「HTTP バインディングコンポーネントの実行時プロパティー」

• 「サービス品質 (QOS) 機能」

• 「HTTP バインディングコンポーネントでの Tango Web サービス機能の使用」

• 「HTTP バインディングコンポーネントでの基本認証の使用」

• 「アプリケーション変数を使用した名前/値ペアの定義」

• 「アプリケーション設定を使用した接続パラメータの設定」

• 「アプリケーション設定を使用した接続パラメータの設定」

• 「統計情報の監視」

• 「HTTP バインディングコンポーネントのクラスタ化サポート」

• 「一般的なユーザーシナリオ」

HTTP バインディングコンポーネントについて

HTTP バインディングコンポーネントは、JBI 1.0 準拠の環境で SOAP over HTTP 接続を提供します。HTTP バインディングコンポーネントは、JBI 環境のサービスへの接続をサポートするプロバイダプロキシとしても、サービスを呼び出すコンシューマプロキシとしても使用されます。

JBI プラットフォームを使用すると、ソフトウェアベンダーは外部コンポーネントからさまざまなプロトコルを使用して呼び出すことのできるサービスを提供できます。このようなサービスは JBI サービスエンジンとして表現され、サービスのビジネスロジックを実装します。JBI バインディングコンポーネントは、JBI サービスエンジンで処理される抽象メッセージとプロトコルの具象メッセージの間のプロトコル変換を実装します。

HTTP バインディングコンポーネントを使用することにより、外部コンポーネントは HTTP/HTTPS プロトコルで SOAP メッセージを使用して、JBI プラットフォームでホストされているサービスを呼び出すことができます。また、JBI コンポーネントは、同じ SOAP over HTTP/HTTPS プロトコルを使用して外部 Web サービスを呼び出すことができます。

抽象メッセージから SOAP メッセージへの変換は、HTTP バインディングコンポーネント内で行われます。WSDL 1.1 仕様および SOAP 1.1 仕様で定義されている WSDL 拡張性要素は、この変換を正しく設定するために使用されます。これらの WSDL 拡張性要素は、WSDL ドキュメントの binding セクションおよび service セクションに含まれています。これらの WSDL ドキュメントは、バインディングコンポーネントに配備可能な JBI ユニットであるサービスユニットに含まれる主要アーティファクトです。メッセージの変換方法と送信先を決定するために、WSDL ドキュメントの binding セクションと service セクションの両方に正しく記入する必要があります。

HTTP/SOAP バインディングのアーキテクチャー

HTTP バインディングコンポーネントの SOAP バインディングを使用することにより、外部コンポーネントは HTTP プロトコルで SOAP メッセージを使用して、JBI プラットフォームでホストされている Web サービスを呼び出すことができます。また、これにより JBI エンジンはそのサービスを公開することができるようになります。Web サービスは、セキュリティー保護されていない場合と、HTTPS (HTTP over SSL) や TLS などの技術を使用してセキュリティー保護されている場合があります。

SOAP バインディングは JBI フレームワーク内にあります。Web コンテナによって提供されるサービスを利用して、着信する Web サービス要求を受信します。バインディングコンポーネントは、さまざまな J2EE ベースの JBI プラットフォームにわたる再利用性を高めるために標準規格に基づいており、独自仕様の API は使用していません。バインディングは、アウトバウンドの Web サービス要求には Web コンテナサービスを使用しません。

HTTP バインディングコンポーネントは B.P.1.0 に準拠しています。バインディングは、メッセージング (フォルトメッセージも含む SOAP メッセージの XML 表現、SOAP 処理モデル、および HTTP での SOAP の使用) およびトランスポートレベルのセキュリティーに関する、基本的なプロファイル要件を扱います。

次の図は、実行時環境内での HTTP バインディングコンポーネントとほかのコンポーネントの関係を示しています。

アプリケーションサーバーには、ESB/JBI コンテナのほかに、JAX-WS、JAX-RPC、JAXB、および WSIT (Tango ) が組み込まれた Metro コンテナと、非同期処理と NIO を追加する HTTP (Grizzly) コネクタがあります。ESB/JBI コンテナには、HTTP バインディングコンポーネント、BPEL サービスエンジン、Java EE サービスエンジン、およびほかの JBI コンポーネントが組み込まれています。HTTP/SOAP バインディングコンポーネントは、アプリケーションサーバー内の各種コンテナと JBI コンポーネントの間の対話を可能にします。

HTTP バインディングコンポーネントの機能

HTTP/SOAP バインディングコンポーネントの機能には、次のようなものがあります。

• WSDL 1.1 仕様と SOAP 1.1 仕様をサポートします。このバインディングコンポーネントとのメッセージ交換では、正規化メッセージ用の JBI WSDL 1.1 ラッパーが利用されます

• WSDL 1.1 仕様で定義されている HTTP および SOAP バインディングを実装します

• WS-I 1.0 の規約に従い、適合していないコンポーネントのサポートも追加します

• ドキュメント形式およびリモートプロシージャー呼び出し (RPC) 形式の Web サービスをサポートします

• リテラルとエンコードの使用をサポートします

• <service uri>?wsdl といった WSDL 取得の一般規約をサポートします

• OASIS 委員会仕様に従って XML カタログを使用します。これにより、コンポーネントはネットワークアクセスを利用せずにローカルでスキーマを解決できます

• JBI サービスユニットの配備をサポートして、提供または消費する Web サービスを定義します

• WSDL 拡張性 (標準の HTTP 拡張機能と SOAP 拡張機能)を利用して、提供または消費する Web サービスに関する外部通信の詳細を定義します

• BC-to-BC connection (バインディングコンポーネント対バインディングコンポーネント接続)をサポートします。これにより、複合アプリケーション内の HTTP バインディングコンポーネントと HTTP バインディングコンポーネントの直接接続が可能になります

• 拡張されたアプリケーション変数をサポートします

• HTTP 接続と HTTPS 接続をサポートします

• Metro (JAX-WS、Tango/WSIT) を統合して、着信および発信する要求に対する WS-* 機能 (WS-Security、WS-Addressing、WS-Reliable Messaging、WS-Transaction など) をサポートします

• 着信および発信する要求に対して JAX-WS を完全に統合します

• GlassFish V2 クラスタモードをサポートします

サービスプロバイダの機能

サービスプロバイダとして機能する HTTP バインディングコンポーネントは、HTTP メッセージまたは SOAP メッセージを外部 Web サービスに送信できます。

サービスプロバイダの機能には次のようなものがあります。

• Java API for XML Web Services (JAX-WS) を介して処理されるアウトバウンド要求

• プロキシおよびプロキシサーバー認証のサポート

サービスコンシューマの機能

サービスコンシューマとして機能する HTTP バインディングコンポーネントは、HTTP クライアントからの HTTP 要求または SOAP 要求を処理し、これらを変換 (正規化) してから正規化メッセージルーターに送信します。

サービスコンシューマの機能には次のようなものがあります。

• サーバーで非同期入出力 (NIO) を使用して、同時に着信する数千の要求を処理します

• 組み込みの HTTP サーバー (Grizzly) とともにパッケージ化されます

• クラスタ化をサポートします

セキュリティー機能

セキュリティー機能には、次のものを介したトランスポートレベルのセキュリティーのサポートが含まれます。

• 基本認証

• SSL のサポート

HTTP バインディングコンポーネントのシナリオ例

次の注文書の例は、複合アプリケーションで HTTP バインディングコンポーネントを使用する基本的なシナリオを示しています。このシナリオ例では、単一の HTTP バインディングコンポーネントがサービスプロバイダかつサービスコンシューマとして機能します。

注文書の例

医薬品会社が、事前承認済みの顧客だけに一連の製品を掲載した Web サイトを提供しています。このような顧客の 1 つである病院が Web サイトにログオンし、1000 枚の外科手術用マスクと 2000 組のゴム手袋を注文します。注文書は医薬品会社のサーバーによって受信されて保存され、注文が受信されたことを確認する応答が病院に返送されます。

図 1 サービスプロバイダかつサービスコンシューマとして機能する HTTP バインディングコンポーネント

このシナリオの注文書処理システムは、Sun Java Application Server と JBI フレームワークを使用して実装された Web サービスで表されます。

このシナリオの主体は次のとおりです。

• Web クライアント

  注文書を SOAP 要求としてパッケージ化し、サーバーに送信します。

• HTTP バインディングコンポーネント

  HTTP メッセージと SOAP メッセージを送受信します。

• BPEL サービスエンジン

  注文書に対応するためのコアビジネスロジックを実装します。

• 正規化メッセージルーター (NMR)

  JBI コンポーネント間で正規化メッセージをルーティングします。このシナリオでは、HTTP BC と BPEL SE の間で送受信される正規化メッセージをルーティングします。

シナリオでのメッセージフロー

注文書シナリオでのメッセージフローのステップは、図 1 の番号に従っています。

1. Web クライアントは、JavaScript などのクライアント側スクリプト言語を使用して、Web フォームに入力された注文書の情報を取得し、SOAP メッセージにパッケージ化します。SOAP メッセージの形式は WSDL を使用して定義されます。

2. SOAP メッセージは、HTTP バインディングコンポーネントによってホストされている Web サービスエンドポイントに送信されます。

3. HTTP バインディングコンポーネントは SOAP メッセージを正規化メッセージに変換します。正規化メッセージは正規化メッセージルーターに送信されます。

4. 正規化メッセージルーターは正規化メッセージを BPEL SE にルーティングします。

5. BPEL SE は注文書の情報を解釈し、要求に対応するためにほかの BPEL プロセスを適切に呼び出します。

6. BPEL SE は正規化メッセージの形式で応答メッセージを作成します。正規化メッセージは正規化メッセージルーターに送信されます。

7. HTTP BC は応答メッセージを受信し、SOAP メッセージに変換します。SOAP メッセージは、WSDL で定義されている適切な応答として Web クライアントに返送されます。

8. Web クライアントは応答を受け取り、人間が判読できる HTML ページを作成して、注文書が受け付けられたか拒否されたかをユーザーが理解できるようにします。

SOAP 処理

HTTP バインディングコンポーネントは、JBI 1.0 準拠の環境で SOAP over HTTP 外部接続を提供します。HTTP バインディングコンポーネントは SOAP 1.1 仕様をサポートし、WSDL 1.1 仕様の SOAP バインディングを実装します。

この節の内容は次のとおりです。

• 「SOAP WSDL 拡張性要素」

• 「SOAP 接続要素」

• 「SOAP バインディング要素」

SOAP WSDL 拡張性要素

SOAP WSDL 要素を使用すると、HTTP バインディングコンポーネントの SOAP 接続および SOAP バインディングの情報を設定できます。

• 「SOAP 接続要素」には、次のような要素があります。

  • 「SOAP address 要素」

• 「SOAP バインディング要素」には、次のような要素があります。

  • 「SOAP binding 要素」

  • 「SOAP operation 要素」

  • 「SOAP body 要素」

  • 「SOAP fault 要素」

  • 「SOAP header および headerfault 要素」

SOAP 接続要素

SOAP 接続要素は address 要素で構成されます。

SOAP address 要素

SOAP address 拡張性要素を使用すると、SOAP サーバーへの接続の情報を指定できます。

次の例は、SOAP address 要素の使用法を示しています。

<port binding="y:binding" name="soapEndpoint">
   <soap:address location="http://myhost:7676/some/additional/context" />
</port>

SOAP バインディング要素

抽象 WSDL メッセージを SOAP メッセージにバインドするための SOAP 拡張性要素は、いくつかのセクションに分かれています。各セクションは、バインディングがどのように行われるべきかを表します。バインディングレベルでは、設定はポートタイプ全体に適用されます。オペレーションレベルでは、設定はそのオペレーションだけに適用されます。メッセージレベルでは、入力メッセージか出力メッセージかにかかわらず、設定はその特定のメッセージに適用されます。

SOAP binding 要素

SOAP binding 要素は、バインディングが SOAP プロトコルの形式 (Envelope、Header、および Body) にバインドされていることを示すために使用されます。この要素は、メッセージのエンコーディングや形式に関する要求 (SOAP 1.1 仕様のセクション 5 に必ず従うことなど) は行いません。

SOAP バインディングを使用するときは、SOAP binding 要素が存在する必要があります。次の例は、SOAP binding 要素の使用法を示しています。

<definitions .... >
    <binding .... >
        <soap:binding transport="uri"? style="rpc|document"?>
    </binding>
</definitions>

style 属性の値は、含まれている各オペレーションのデフォルトの style 属性です。style 属性が省略されている場合は、"document" と見なされます。

必須の transport 属性の値は、SOAP メッセージの配信に使用するトランスポートを示します。URI 値 http://schemas.xmlsoap.org/soap/http は、SOAP 仕様の HTTP バインディングに対応しています。ここにほかの URI を使用して、ほかのトランスポート (SMTP、FTP など) を指定することができます。

SOAP operation 要素

SOAP operation 要素は、抽象オペレーションから具象 SOAP オペレーションへのバインディング情報を提供するために使用されます。

次の例は、SOAP operation 要素の使用法を示しています。

<definitions .... >
    <binding .... >
        <operation .... >
           <soap:operation soapAction="uri"? style="rpc|document"?>?
        </operation>
    </binding>
</definitions>

style 属性 は、オペレーションが RPC 指向 (メッセージにパラメータと戻り値が含まれる) か、ドキュメント指向 (メッセージにドキュメントが含まれる) かを示します。この情報を使用して、適切なプログラミングモデルを選択することができます。この属性の値は、SOAP メッセージの本体の構築方法にも影響を与えます。この属性が指定されていない場合は、soap:binding 要素に指定されている値がそのデフォルト値になります。soap:binding 要素で style が指定されていない場合は、"document" と見なされます。

soapAction 属性は、このオペレーションの SOAPAction ヘッダーの値を指定します。この URI 値は SOAPAction ヘッダーの値として直接使用する必要があります。要求を行うときに、相対 URI 値を絶対値にしようとしないでください。SOAP の HTTP プロトコルバインディングの場合、この値は必須です (デフォルト値はない)。ほかの SOAP プロトコルバインディングの場合、これを指定してはならず、また soap:operation 要素は省略できます。

SOAP body 要素

SOAP body 要素は、抽象オペレーションから具象 SOAP オペレーションへのバインディング情報を提供するために使用されます。

次の例は、SOAP body 要素を示しています。

<definitions .... >
    <binding .... >
        <operation .... >
           <input>
               <soap:body parts="nmtokens"? use="literal|encoded"?
                          encodingStyle="uri-list"? namespace="uri"?>
           </input>
           <output>
               <soap:body parts="nmtokens"? use="literal|encoded"?
                          encodingStyle="uri-list"? namespace="uri"?>
           </output>
        </operation>
    </binding>
</definitions>

nmtokens タイプの省略可能属性 parts は、メッセージの SOAP Body 部分のどこかに出現するパートを示します (SOAP が multipart/related MIME バインディングと組み合わせて使用される場合など、メッセージのほかのパートがメッセージのほかの部分に出現する可能性がある)。parts 属性が省略されている場合は、メッセージで定義されているすべてのパートが SOAP Body 部分に含められると見なされます。

必須の use 属性は、メッセージパートがなんらかのエンコーディング規則を使用してエンコードされるか、あるいはメッセージパートがメッセージの具象スキーマを定義するかを示します。

use が encoded の場合、各メッセージパートは type 属性を使用して抽象タイプを参照します。これらの抽象タイプを使用して、encodingStyle 属性で指定されているエンコーディングを適用することにより、具象メッセージが生成されます。namespace 属性は、抽象タイプで明示的に定義されていない内容だけに適用されますが、namespace 属性のパート名、タイプ、および値はすべてエンコーディングに入力されます。参照先のエンコーディングスタイルでは、(SOAP エンコーディングの場合と同様に) 形式の変形を許可する場合、すべての変形がサポートされる (reader makes right) 必要があります。

use が literal の場合、各パートは element 属性か type 属性を使用して具象スキーマ定義を参照します。前者の場合、パートで参照される要素が Body 要素の下に直接出現するか (ドキュメント形式のバインディングの場合)、メッセージパートの名前で指定されるアクセサ要素の下に出現します (RPC 形式の場合)。後者の場合、パートで参照されるタイプが、包含する要素のスキーマタイプになります (ドキュメント形式の場合は Body、RPC 形式の場合はパートのアクセサ要素)。

タイプを使用して複合 Body の内容を定義する例については、節 2.3.1 を参照してください。use が literal の場合は、encodingStyle 属性の値を使用して、具象形式は特定のエンコーディング (SOAP エンコーディングなど) を使用して生成されたが、指定された変形だけがサポートされる (writer makes right) ことを示すことができます。

encodingStyle 属性の値は URI のリストです。各 URI は 1 つの空白で区切られています。これらの URI は、メッセージで使用されるエンコーディングを、制限の強いものから弱いものへ順に表します (SOAP 仕様で定義されている encodingStyle 属性とまったく同様)。

SOAP fault 要素

fault 要素は、SOAP Fault Details 要素の内容を指定します。そのパターンは body 要素と同様になります。

次の例は、SOAP fault 要素を示しています。

<definitions .... >
    <binding .... >
        <operation .... >
           <fault>*
               <soap:fault name="nmtoken" use="literal|encoded"
                                 encodingStyle="uri-list"? namespace="uri"?>
           </fault>
        </operation>
    </binding>
</definitions>

name 属性は、オペレーションに定義されている wsdl:fault に soap:fault を関連付けます。障害メッセージのパートは 1 つでなければなりません。

use、encodingStyle、および namespace 属性はどれも Body と同じ方法で使用されますが、障害にはパラメータが含まれないので style="document" と見なされる点だけが異なります。

SOAP header および headerfault 要素

header 要素と headerfault 要素を使用すると、SOAP Envelope の Header 要素内で送信されるヘッダーを定義できます。ヘッダーを使用する SOAP Envelope に出現するヘッダーをすべて列挙する必要があるわけではありません。たとえば、特定のヘッダーは実際のペイロードに追加されるように WSDL の拡張機能によって暗黙で指定されている場合があり、そのようなヘッダーはここに列挙する必要はありません。

次の例は、SOAP header および headerfault 要素を示しています。

<definitions .... >
    <binding .... >
        <operation .... >
           <input>
             <soap:header message="qname" part="nmtoken" use="literal|encoded"
                          encodingStyle="uri-list"? namespace="uri"?>*
               <soap:headerfault message="qname" part="nmtoken" use="literal|encoded"
                                 encodingStyle="uri-list"? namespace="uri"?/>*
             <soap:header>                                
           </input>
           <output>
               <soap:header message="qname" part="nmtoken" use="literal|encoded"
                            encodingStyle="uri-list"? namespace="uri"?>*
                 <soap:headerfault message="qname" part="nmtoken" use="literal|encoded"
                                   encodingStyle="uri-list"? namespace="uri"?/>*
               <soap:header>                                
           </output>
        </operation>
    </binding>
</definitions>

use、encodingStyle、および namespace 属性はどれも Body と同じ方法で使用されますが、ヘッダーにはパラメータが含まれないので style="document" と見なされる点だけが異なります。

QName タイプの message 属性と nmtoken タイプのpart 属性はともに、ヘッダータイプを定義するメッセージパートを参照します。

省略可能な headerfault 要素は、header 内に出現し、header と同じ構文を持ちます。この要素を使用すると、ヘッダーに関連しヘッダーで定義されているエラー情報を送信するための、ヘッダータイプを指定できます。SOAP 仕様では、ヘッダーに関連するエラーはヘッダー内で返す必要があると記述されています。この機構を使用すると、そのようなヘッダーの形式を指定できます。

HTTP 処理

HTTP 拡張性要素は、HTTP 1.1 の GET 動詞と POST 動詞による Web ブラウザと Web サイトの間の対話を記述します。これにより、Web ブラウザ以外のアプリケーションがサイトと対話できるようになります。

この節の内容は次のとおりです。

• 「HTTP WSDL 拡張性要素」

• 「HTTP 接続要素」

• 「HTTP バインディング要素」

HTTP WSDL 拡張性要素

HTTP WSDL 要素を使用すると、HTTP バインディングコンポーネントの HTTP 接続および HTTP バインディングの情報を設定できます。

HTTP WSDL 要素を使用すると、HTTP バインディングコンポーネントの HTTP 接続および HTTP バインディングの情報を設定できます。

• 「HTTP 接続要素」には、次のような要素があります。

  • 「HTTP address 要素」

• 「HTTP バインディング要素」には、次のような要素があります。

  • 「HTTP binding 要素」

  • 「HTTP operation 要素」

  • 「HTTP urlEncoded 要素」

  • 「HTTP urlReplacement 要素」

次に示すプロトコル固有の情報を指定することができます。

• バインディングで HTTP GET または POST を使用するかどうか

• ポートのアドレス

• 各オペレーションの相対アドレス (ポートで定義されている基底アドレスを基準とする)

ここの情報は 2 つの主要セクションに分割されます。1 つは、ユーザーが HTTP サービスのエンドポイントを設定する方法です。もう 1 つは、ユーザーが設定を指定して WSDL メッセージを HTTP メッセージにマップする方法です。

HTTP 接続要素

HTTP 接続要素は address 要素で構成されます。

HTTP address 要素

HTTP address 拡張性要素を使用すると、HTTP サーバーへの接続の情報を指定できます。

次の例は、サービスポートに定義される HTTP address 拡張性要素の使用法を示しています。

<port binding="y:binding" name="soapEndpoint">
   <http:address location="http://myhost:7676/some/additional/context" />
</port>

HTTP バインディング要素

抽象 WSDL メッセージを HTTP メッセージにバインドするための HTTP 拡張性要素は、いくつかのセクションに分かれています。各セクションは、バインディングがどのように行われるべきかを表します。バインディングレベルでは、設定はポートタイプ全体に適用されます。オペレーションレベルでは、設定はそのオペレーションだけに適用されます。メッセージレベルでは、入力メッセージか出力メッセージかにかかわらず、設定はその特定のメッセージに適用されます。

HTTP binding 要素

HTTP binding 要素は、バインディングが HTTP プロトコルにバインドされていることを示すために使用されます。

HTTP バインディングを使用するときは、HTTP binding 要素が存在する必要があります。次の例は、HTTP binding 要素を示しています。

<definitions .... >
    <binding .... >
        <http:binding verb="nmtoken" />
    </binding>
</definitions>

必須の verb 属性の値は、HTTP 動詞を示します。一般的な値は GET または POST ですが、ほかの値も使用できます。HTTP 動詞では大文字と小文字が区別されることに注意してください。

HTTP operation 要素

HTTP operation 要素は、抽象オペレーションから具象 HTTP オペレーションへのバインディング情報を提供するために使用されます。

次の例は、WSDL operation 要素を示しています。

<definitions .... >
    <binding .... >
        <operation .... >
           <soap:operation location="uri" />
        </operation>
    </binding>
</definitions>

location 属性は、オペレーションの相対 URI を指定します。この URI は、http:address 要素に指定されている URI と組み合わされて、HTTP 要求の完全な URI を形成します。URI の値は相対 URI でなければなりません。

HTTP urlEncoded 要素

urlEncoded 要素は、すべてのメッセージパートが標準の URI エンコーディング規則 (name1=value&name2=value...) を使用して HTTP 要求 URI 内にエンコードされることを示します。パラメータの名前はメッセージパートの名前に対応します。パートによって提供される各値は、名前=値のペアを使用してエンコードされます。これを GET とともに使用して URL エンコーディングを指定したり、POST とともに使用して FORM-POST を指定したりできます。GET の場合、「?」文字が必要に応じて自動的に追加されます。

例:

<definitions .... >
    <binding .... >
        <operation .... >
           <input .... >
               <http:urlEncoded/>
           </input>
           <output .... >
               <-- mime elements -->
           </output>
        </operation>
    </binding>
</definitions>

HTTP urlReplacement 要素

urlReplacement 要素は、すべてのメッセージパートが置換アルゴリズムを使用して HTTP 要求 URI 内にエンコードされることを示します。

• http:operation の相対 URI 値から一連の検索パターンが検索されます。

• この検索は、http:operation の値が http:address の location 属性の値と組み合わされる前に実行されます。

• 各メッセージパートに 1 つの検索パターンがあります。検索パターン文字列は、括弧「(」と「)」で囲まれたメッセージパートの名前です。

• 一致するごとに、対応するメッセージパートの値が一致した場所の一致内容に置換されます。

• 照合は値が置換される前に実行されます (置換された値によってさらに照合が行われることはない)。

メッセージパートには反復値が含まれていてはいけません。

HTTP urlReplacement 要素

例:

<definitions .... >
    <binding .... >
        <operation .... >
           <input .... >
               <http:urlReplacement/>
           </input>
           <output .... >
               <-- mime elements -->
           </output>
        </operation>
    </binding>
</definitions>

HTTP GET および POST 処理

HTTP バインディングコンポーネントは、WSDL 1.1 仕様で定義されている HTTP バインディングをサポートします。HTTP/SOAP バインディングに関する WSDL 1.1 仕様の詳細については、WSDL 1.1 仕様を参照してください。

バインディングコンポーネントは次のメッセージ処理をサポートします。

• 「XML/HTTP GET 処理」

• 「 HTTP POST メソッドでの HTTP バインディングコンポーネントの使用」

XML/HTTP GET 処理

HTTP バインディングコンポーネントは、JBI 環境のサービスへの接続を提供するプロバイダプロキシとして、あるいはサービスを呼び出すコンシューマプロキシとして使用されます。バインディングコンポーネントは、WSDL 1.1 仕様で定義されている HTTP 1.1 GET バインディングを実装します。これにより、アプリケーションは Web ブラウザに似た HTTP GET 対話を使用して、JBI 環境からサービスを消費または提供することができます。

HTTP バインディングコンポーネントを HTTP Get 対話用に設定する

HTTP バインディングコンポーネントを HTTP Get 対話で機能するように設定するには、バインディングコンポーネントがプロキシとして機能しているサービスの WSDL ファイルで、WSDL 1.1 仕様で定義されている次の HTTP バインディング言語要素を使用する必要があります。

• WSDL バインディングが HTTP GET を使用することを示す <http:binding> 要素。

• ポートのアドレスを表す <http:address> 要素。

• 各オペレーションの相対アドレスを表す <http:operation> 要素。ポートで定義されている <http:address> を基準とします。

• 要求のすべてのメッセージパートをどのようにエンコードして HTTP 要求 URI に含めるかを示す <http:urlEncoded> および <http:urlReplacement> 要素。

HTTP バインディングコンポーネントをプロバイダプロキシまたはコンシューマプロキシとして設定する方法の例は、Using the HTTP Binding Component with the HTTP GET method および Using the HTTP Binding Component with the HTTP POST Method で参照できます。

バインディングの詳細

以降の節では、HTTP バインディングコンポーネントが HTTP バインディング言語要素をどのようにサポートし、実装するかについて説明します。特に指示がないかぎり、ここで説明する WSDL 要素は名前空間 http://schemas.xmlsoap.org/wsdl/http/ で定義されています。

http:binding 要素

<http:binding> 要素:

• バインディングが HTTP プロトコルを使用することを示します。

• <wsdl:binding> の従属要素として指定する必要があります。

現在、HTTP バインディングコンポーネントでは GET と POST の値だけがサポートされています (HTTP メソッドでは大文字と小文字が区別されることに注意してください)。

例:

<http:binding verb="POST"/>

http:address 要素

<http:address> 要素:

• ポートのアドレスを表します。

• <wsdl:port> の従属要素として指定する必要があります。

• ポートの基底 URI を指定する location 属性が必要です。

例:

<http::address location="http://localhost/MyService/MyPort"/>

http:operation 要素

<http:operation> 要素:

• オペレーションのアドレスを表します。

• <wsdl:operation/> の従属要素として指定する必要があります。

• オペレーションの基底 URI を指定する location 属性が必要です。

• このポートおよびこの特定のオペレーションに対する要求の完全な URI。<http:address> 要素はポートのアドレスを指定し、ポートは複数のオペレーションを持つ可能性があるので、この要素は特定のオペレーションの相対アドレスを表します。この要素の location 属性の値は <http:address> の location 属性の値に付加されて、このポートおよびこの特定のオペレーションに対する要求の完全な URI を形成します。

HTTP バインディングコンポーネントでは、この要素の location 属性の値として空白がサポートされています。

例:

Given:
    <http:operation location="Submit">
    <http:address location="http://localhost/MyService/MyPort">

The full HTTP request URI is: 
http://localhost/MyService/MyPort/Submit

http:urlEncoded 要素

<http:urlEncoded> 要素:

• 入力メッセージを構成しているすべてのメッセージパートが、次のようにクエリー文字列エンコーディングを使用して、要求 URI 内にエンコードされることを示します。

  • 名前=値という形式で表された名前と値のペア

  • アンパサンドで区切られた名前と値のペア: name1=value1&name2=value2&...

  • メッセージパートの名前が各ペアの名前になり、メッセージパートの値が各ペアの値になります。

• <wsdl:input/> の従属要素として指定する必要があります。

• オペレーションの基底 URI を指定する location 属性が必要です。

• GET メソッドの HTTP バインディングコンポーネントでのみサポートされます。POST メソッドの場合、<http:urlEncoded> は無視されます。詳細については、POST URL Processing of the HTTP WSDL Binding Implementation を参照してください。

例:

Given this description:
<wsd:message name="MyMessage">
    <wsdl:part name="partA" type="xsd:string"/>
    <wsdl:part name="partB" type="xsd:string"/>
</wsdl:message>
...
<wsdl:portType name="MyPortType">
    <wsdl:operation name="MyOperation">
        <wsdl:input message="MyMessage"/>
    </wsdl:operation>
</wsdl:portType>
...
<wsdl:binding name="MyBinding" type="MyPortType">
    <http:binding verb="GET"/>
    <wsdl:operation name="MyOperation">
        <wsdl:input>
            <http:urlEncoded/>
        </wsdl:input>
    </wsdl:operation>
</wsdl:binding>
...
<wsdl:service name="MyService">
    <wsdl:port name="Port1" binding="MyBinding">
        <http:address location="http://localhost/MyService/MyPort"/>
    </wsdl:port>
</wsdl:service>

Given these values mapped to the input parts:
"valueY" -> "partA"
"valueZ" -> "partB"

The full HTTP request URI is:
http://localhost/MyService/MyPort/MyOperation/partA=valueY&partB=valueZ

http:urlReplacement

<http:urlReplacement/> 要素:

• 入力メッセージを構成しているすべてのメッセージパートが、WSDL 1.1 仕様で詳細に記述されている置換アルゴリズムを使用して、要求 URI 内にエンコードされることを示します。

• <wsdl:input/> の従属要素として指定する必要があります。

• オペレーションの基底 URI を指定する location 属性が必要です。

• GET メソッドの HTTP バインディングコンポーネントでのみサポートされます。POST メソッドの場合、<http:urlEncoded> は無視されます。詳細については、POST URL Processing of the HTTP WSDL Binding Implementation を参照してください。

例:

Given this description:
<wsd:message name="MyMessage">
    <wsdl:part name="partA" type="xsd:string"/>
    <wsdl:part name="partB" type="xsd:string"/>
</wsdl:message>
...
<wsdl:portType name="MyPortType">
    <wsdl:operation name="MyOperation">
        <wsdl:input message="MyMessage"/>
    </wsdl:operation>
</wsdl:portType>
...
<wsdl:binding name="MyBinding" type="MyPortType">
    <http:binding verb="GET"/>
    <wsdl:operation name="MyOperation/(partA)/subcategory/(partB)">
        <wsdl:input>
            <http:urlReplacement/>
        </wsdl:input>
    </wsdl:operation>
</wsdl:binding>
...
<wsdl:service name="MyService">
    <wsdl:port name="Port1" binding="MyBinding">
        <http:address location="http://localhost/MyService/MyPort"/>
    </wsdl:port>
</wsdl:service>

Given these values mapped to the input parts:
"valueY" -> "partA"
"valueZ" -> "partB"

The full HTTP request URI is:
http://localhost/MyService/MyPort/MyOperation/valueY/subcategory/valueZ

HTTP POST メソッドでの HTTP バインディングコンポーネントの使用

HTTP BC は、WSDL 1.1 仕様で定義されている HTTP 1.1 POST バインディングを実装します。これにより、アプリケーションは Web ブラウザに似た HTTP GET 対話を使用して、JBI 環境からサービスを消費または提供することができます。

HTTP バインディングコンポーネントを HTTP Get 対話用に設定する

HTTP バインディングコンポーネントを HTTP POST 対話で機能するように設定するには、バインディングコンポーネントがプロキシとして機能しているサービスの WSDL ファイルで、WSDL 1.1 仕様で定義されている次の HTTP バインディング言語要素を使用する必要があります。

• WSDL バインディングが HTTP POST を使用することを示す <http:binding> 要素。

• ポートのアドレスを表す <http:address> 要素。

• 各オペレーションの相対アドレスを表す <http:operation> 要素。ポートで定義されている <http:address> を基準とします。

• 要求のすべてのメッセージパートをどのようにエンコードして HTTP 要求 URI に含めるかを示す <http:urlEncoded> および <http:urlReplacement> 要素。

HTTP バインディングコンポーネントをプロバイダプロキシまたはコンシューマプロキシとして設定する方法の例は、Using the HTTP Binding Component with the HTTP GET method および Using the HTTP Binding Component with the HTTP POST Method で参照できます。

現在、HTTP バインディングコンポーネントでは、HTTP GET でのみ <http:urlReplacement> と <http:urlEncoded> の使用がサポートされています。

バインディングの詳細

これらの要素のバインディングの詳細については、「バインディングの詳細」を参照してください。

HTTP POST での http:urlEncoded および http:urlReplacement の取り扱い

GET 要求と POST 要求では要求の構造が異なるため、HTTP バインディングコンポーネントでの WSDL HTTP バインディングの使用法には GET および POST 形式の対話にわたる一貫性がありません。

相違点は次のとおりです。

• GET 要求は、URL (および HTTP ヘッダー) に含まれているデータのほかには追加のデータを含んでいません。

• POST 要求は、要求エンティティー本体で追加のデータを送信することができます。たとえば、Web ブラウザを使用して POST によってフォームを送信する (またはフォームを介してファイルをアップロードする) 場合、フォームデータまたはファイルの内容が要求の本体として送信されます。データは要求 URL の一部にはなりません。

これらの相違点のため、現在の HTTP バインディングコンポーネントの実装では、http:urlEncoded と http:urlReplacement は HTTP GET と組み合わせて使用される場合のみ意味を持つと見なされます。これらのバインディング要素は、GET 要求だけに適用される URL エンコーディングスタイルを示すからです。

HTTP POST の場合、現在の実装では http:urlEncoded バインディング要素と http:urlReplacement バインディング要素はどちらも無視されます。

HTTP バインディングコンポーネントの実行時プロパティー

HTTP バインディングコンポーネントの実行時プロパティーは、NetBeans IDE から、あるいはインストール中にコマンドプロンプト (コマンド行インタフェース) から設定できます。

HTTP バインディングコンポーネントのプロパティーは、すべてのプロバイダおよびコンシューマエンドポイントを含め、バインディングコンポーネント全体に適用されます。

NetBeans IDE でプロパティーを表示または編集するには、次の手順を実行します。

1. NetBeans IDE の「サービス」タブで、「サーバー」ノードを展開します。

2. GlassFish v2 など、使用しているアプリケーションサーバーを起動します。そのためには、アプリケーションサーバーを右クリックし、ショートカットメニューから「起動」を選択します。

3. アプリケーションサーバーの下で、「JBI」>「バインディングコンポーネント」ノードを展開し、「HTTP バインディングコンポーネント」(com.sun.httpsoapbc) を選択します。現在の HTTP バインディングコンポーネントのプロパティーが NetBeans IDE の右側に表示されます。HTTP バインディングコンポーネントをダブルクリックしてプロパティーウィンドウを開くこともできます。

4. 必要に応じてプロパティーを編集します。加えた変更を HTTP バインディングコンポーネントの実行時プロパティーに適用するには、HTTP バインディングコンポーネントを停止してから再起動します。

図 2 HTTP バインディングコンポーネントの実行時プロパティー

HTTP バインディングコンポーネントのプロパティーは、クラスタ化とプロキシの設定を指定し、バインディングコンポーネントの説明、名前、タイプ、および状態を参照します。

サービス品質 (QOS) 機能

サービス品質機能は CASA エディタから設定します。サービス品質機能には、再試行 (再配信) と制限の設定に使用されるプロパティーが含まれます。

この節の内容は次のとおりです。

• 「サービス品質プロパティーの設定」

• 「メッセージ制限: 設定と使用 」

• 「再配信: 設定と使用」

サービス品質プロパティーの設定

QOS 属性は QoS プロパティー設定エディタから設定します。このエディタには複合アプリケーションサービスアセンブリ (CASA) エディタからアクセスします。QoS プロパティー設定エディタへのアクセス方法の例については、「HTTP バインディングコンポーネントのエンドポイントの制限を設定する」を参照してください。

メッセージ制限: 設定と使用

制限を使用することにより、特定のエンドポイントで同時に処理されるメッセージの最大数を設定できます。メッセージ負荷やメッセージペイロードが増加すると、メモリー使用量の急増をまねき、パフォーマンスを低下させる可能性があります。制限によってリソースの消費が制限され、一貫したパフォーマンスが維持されます。

HTTP バインディングコンポーネントは、Grizzly HTTP Web サーバーで提供される機能を使用してメッセージのフローを管理します。つまり、エンドポイントを評価することにより、要求を中断すべき場合や通常どおり処理を再開すべき場合を判定します。

HTTP BC および制限の詳細については、HTTP BC Throttling を参照してください。

HTTP バインディングコンポーネントのエンドポイントの制限を設定する

HTTP バインディングコンポーネントの場合、制限は CASA エディタから設定される QOS 機能です。

HTTP/SOAP WSDL ポートの制限を設定する

1. NetBeans IDE の「プロジェクト」ウィンドウから、複合アプリケーションの下にある「サービスアセンブリ」ノードを右クリックし、ポップアップメニューから「編集」を選択します。

   CASA エディタが開き、ユーザーの複合アプリケーションが表示されます。

   

2. CASA エディタで、ユーザーの JBI モジュールと設定する WSDL ポートの間のリンク上にある QOS アイコンをクリックします。

   QoS プロパティーエディタが表示されます。

3. QoS プロパティーエディタで、ThrottlingExtension の下の maximumConcurrencyLimit のプロパティーフィールドをクリックし、このエンドポイントで同時に許可されるメッセージの最大数を表す整数を入力します。

   

4. 「閉じる」をクリックします。

   サービスアセンブリの構築時に、プロジェクトの jbi.xml ファイル内に接続の制限設定が適切に生成されます。

再配信: 設定と使用

再配信は、初回の配信が失敗した場合のメッセージ配信を処理するサービス品質機構です。再配信を使用することにより、システムでメッセージ配信を試行する回数、試行間隔、およびメッセージが配信不能な場合やエンドポイントが応答していない場合の最終結果を定義できます。

再配信は特定の接続に対して設定されます。設定するには、複合アプリケーションサービスアセンブリ (CASA) エディタからその接続の QoS アイコンをクリックします。これにより、その接続の「QoS プロパティー設定」が開きます。エディタの RedeliveryExtension セクションから、再配信のプロパティーを設定します。

再配信の設定パラメータは次のとおりです。

• maxAttempts: プロジェクトでメッセージの再配信を試行する回数を指定します。試行が失敗するたびに、JBI コンポーネントにエラー状態が返されます。

• waitTime: プロジェクトでメッセージの再配信を試行する間隔をミリ秒単位で指定します。

• on-failure: 再配信の試行が指定回数に達したときに実行するアクションおよびメッセージの送信先を指定します。このパラメータには、delete、redirect、suspend、および error の 4 つのオプションがあります。

  on-failure パラメータには、delete、redirect、suspend、および error の 4 つのオプションがあります。

  • delete: メッセージ再配信の最後の試行が失敗すると、QoS ユーティリティーはメッセージを削除し、JBI コンポーネントに Done 状態を返します。その時点で JBI コンポーネントは次のプロセスに進みます。delete オプションは In-Only メッセージ交換でのみサポートされます。

  • redirect: メッセージ再配信の最後の試行が失敗すると、QoS ユーティリティーは dead-message フォルダなどのユーザー定義のエンドポイントにメッセージをリダイレクトします。リダイレクトエンドポイントに正常に配信できた場合、QoS ユーティリティーは JBI コンポーネントに Done 状態を返します。その時点で JBI コンポーネントは次のプロセスに進みます。redirect オプションは In-Only メッセージ交換でのみサポートされます。

  • suspend: メッセージ再配信の最後の試行が失敗すると、JBI コンポーネントはプロセスインスタンスを中断します。このオプションは、JBI コンポーネントで監視が有効になっている場合のみサポートされます。これは、ユーザーが監視ツールを使用して中断されたインスタンスを再開する必要があるからです。このオプションは、In-Only と In-Out の両方のメッセージ交換でサポートされます。

  • error: メッセージ再配信の最後の試行が失敗すると、JBI コンポーネントは例外をスローします。このオプションは、JBI コンポーネントで監視が有効になっている場合のみサポートされます。これは、ユーザーが監視ツールを使用して中断されたインスタンスを再開する必要があるからです。このオプションは、In-Only と In-Out の両方のメッセージ交換でサポートされます。

注: on-failure の delete オプションと redirect オプションは、In-Out メッセージ交換には利用できません。In-Out メッセージ交換では、処理を進めるためにプロセスインスタンスから特定の応答が必要ですが、これらのオプションへの戻り値では十分ではないからです。

再配信の詳細については、Redelivery を参照してください。

HTTP バインディングコンポーネントでの基本認証の使用

基本認証を使用すると、トランザクションを行う場合にユーザー名とパスワードの形式で資格情報を要求することができます。資格情報はプレーンテキストで送信されます。プライバシを確保するために、ユーザー名とパスワードは送信前に Base 64 文字のシーケンスにエンコードされます。たとえば、ユーザー名「Fred」とパスワード「Dinosaur」は組み合わされて「Fred:Dinosaur」となり、Base 64 でエンコードされると「RnJlZDpEaW5vc2F1cg0K」になります。

プロバイダ Web サービスの場合は、クライアントからの要求メッセージの要求ヘッダーにユーザー名とパスワードのフィールドが含まれています。

コンシューマ Web サービスの場合は、基本認証を有効にして Web サービスを呼び出すと、認証の要求ヘッダーにユーザー名とパスワードが追加されます。

基本認証の詳細については、RFC 1945 (Hypertext Transfer Protocol HTTP/1.0)、RFC 2616 (Hypertext Transfer Protocol HTTP/1.1)、および RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication) を参照してください。

基本認証でサポートされる機能

基本認証をサポートするには、WSDL にポリシーを指定します。基本認証ポリシーを WSDL に追加するには、手作業で行うか、Tango (WSIT) を介して提供され CASA からアクセスできる「WS-Policy Attachment」ウィンドウを使用します。基本認証ポリシーは WSDL のルートレベルに指定されます。WSDL の「Port type」セクションにポリシーの参照が作成されて、ポリシーがエンドポイントにバインドされます。

基本認証をサポートするために、HTTP バインディングコンポーネントでは次の WSDL 要素が定義されます。

• MustSupportBasicAuthentication: この要素には on という属性があり、これを使用して認証をオンまたはオフに設定することができます。この属性に指定できる値は true または false です。エンドポイントで基本認証を有効にするには、ポリシー内に MustSupportBasicAuthentication 要素が必要です。

• UsernameToken: この要素は、次の目的に使用するユーザー名とパスワードのフィールドを指定します。

  • 要求を認証する (エンドポイントがプロバイダの場合)

  • 基本認証を有効にして Web サービスを呼び出す(設定されたエンドポイントがコンシューマの場合)

    ユーザー名とパスワードのフィールドは、WSDL にプレーンテキストで指定するか、WSDL にトークンとして指定して実行時に設定することができます。

コンシューマエンドポイントの認証機構

Web サービスコンシューマエンドポイントには、 3 種類の認証機構がサポートされています。

これらの機構の 1 つを使用するようにコンシューマエンドポイントを設定するには、エンドポイントの Policy の MustSupportBasicAuthentication 要素に子要素として追加します。

• WssTokenCompare: HTTP Authorization 要求ヘッダーから抽出されたユーザー名およびパスワードを、Policy の WssUsernameToken10 要素と WssPassword 要素に指定されているユーザー名およびパスワードと比較します。

• AccessManager: Sun Access Manager を使用して HTTP クライアントの資格情報を認証するようにコンシューマエンドポイントを設定します。

• Realm: Sun レルムセキュリティーを使用して HTTP クライアントの資格情報を認証するようにコンシューマエンドポイントを設定します。

以降の節では、これらの機構の詳細について説明します。

WssTokenCompare

WssTokenCompare 要素を使用するには、Policy 要素が存在し、認証に使用されるユーザー名とパスワードが指定されている必要があります。HTTP Authorization 要求ヘッダーから抽出されたユーザー名およびパスワードは、Policy の WssUsernameToken10 要素と WssPassword 要素に指定されているユーザー名およびパスワードと比較されます。

次のサンプル WSDL には、WssTokenCompare を使用するためのポリシーとその参照が含まれています。パスワードが WSDL に公開されないように、パスワードにはアプリケーション変数トークンが使用されていることに注意してください。パスワードの値は、NetBeans を使用してコンポーネントのプロパティーで指定できます。「アプリケーション変数を使用した名前/値ペアの定義」を参照してください。

<wsdl:service name="echoService">
    <wsdl:port name="echoPort" binding="tns:echoBinding">
        <soap:address location="http://pponnala-tecra-xp.stc.com:18181/
         echoService/echoPort"/>
        <wsp:PolicyReference URI="#HttpBasicAuthBindingBindingPolicy"/>
    </wsdl:port>
</wsdl:service>

<wsp:Policy wsu:Id="HttpBasicAuthBindingBindingPolicy">
    <mysp:MustSupportBasicAuthentication on="true">
        <mysp:BasicAuthenticationDetail>
           <mysp:WssTokenCompare/>
        </mysp:BasicAuthenticationDetail>
    </mysp:MustSupportBasicAuthentication>
    <mysp:UsernameToken mysp:IncludeToken="http://schemas.xmlsoap.org/ws/
     2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
       <wsp:Policy>
            <sp:WssUsernameToken10>wilma</sp:WssUsernameToken10>
            <sp:WssPassword>${pass_token}</sp:WssPassword>
       </wsp:Policy>
  </mysp:UsernameToken>
</wsp:Policy>

上記のコードは読みやすいように折り返されています。

AccessManager

AccessManager を使用するには、Sun Access Manager を使用して HTTP クライアントの資格情報を認証するようにコンシューマエンドポイントを設定します。HTTP バインディングコンポーネントの SOAP バインディングは Sun Access Manager とシームレスに統合され、HTTP クライアントの資格情報 (HTTP Authorization ヘッダーから抽出されたユーザー名およびパスワード) を、Sun Access Manager のデータベースにあるユーザーの資格情報と照合して認証します。

Sun Access Manager による認証を使用する前に、バインディングコンポーネントの追加設定を行なって、HTTP SOAP BC で Access Manager を使用するように設定する必要があります。この設定の名前は「Sun Access Manager 設定ディレクトリ」で、値は Sun Access Manager の AMConfig.properties ファイルが置かれているディレクトリです。

「Sun Access Manager 設定ディレクトリ」を設定するには、次の手順を実行します。

1. NetBeans の「サービス」ウィンドウから「HTTP バインディングコンポーネントのプロパティー」にアクセスします。「サーバー」>「GlassFish·V2」>「JBI」>「バインディングコンポーネント」の下の sun-http-binding を右クリックし、ポップアップメニューから「プロパティー」を選択します。

2. 「Sun Access Manager 設定ディレクトリ」プロパティーを設定して、Sun Access Manager の AMConfig.properties ファイルの場所を指定します。

次のサンプル WSDL には、AccessManager を使用するためのポリシーとその参照が含まれています。

<wsdl:service name="echoService">
    <wsdl:port name="echoPort" binding="tns:echoBinding">
        <soap:address location="http://pponnala-tecra-xp.stc.com:18181/
         echoService/echoPort"/>
        <wsp:PolicyReference URI="#HttpBasicAuthBindingBindingPolicy"/>
    </wsdl:port>
</wsdl:service>

<wsp:Policy wsu:Id="HttpBasicAuthBindingBindingPolicy">
    <mysp:MustSupportBasicAuthentication on="true">
        <mysp:BasicAuthenticationDetail>
           <mysp:AccessManager/>
        </mysp:BasicAuthenticationDetail>
    </mysp:MustSupportBasicAuthentication>
</wsp:Policy>

上記のコードは読みやすいように折り返されています。

Sun Java System Access Manager を使用してサービスのクライアントとサーバー間の通信をセキュリティーで保護する方法を示すチュートリアルは、Securing Communications in OpenESB with Sun Access Manager で参照できます。

Realm

Realm 要素を使用するには、Sun レルムセキュリティーを使用して HTTP クライアントの資格情報を認証するようにコンシューマエンドポイントを設定します。Realm 要素を使用する場合は、Sun レルムセキュリティーを使用して HTTP クライアントの資格情報を認証するようにコンシューマエンドポイントを設定します。HTTP SOAP バインディングコンポーネントは Sun レルムセキュリティーと統合され、HTTP クライアントの資格情報 (HTTP Authorization ヘッダーから抽出されたユーザー名およびパスワード) を、指定された Realm 内のユーザーの資格情報と照合して認証します。

レルムの名前は、Realm 要素の realmName という属性で指定されます。たとえば、GlassFish のインストールには事前設定済みの file レルムが含まれています。これは基本的に、ファイルベースのユーザーデータベースです。ユーザーを作成してレルムに追加する方法については、 GlassFish documentation on Realm security を参照してください。file レルムを例にとって、Realm を使用するためのポリシーとその参照を含んだサンプル WSDL を次に示します。

次のサンプル WSDL には、Realm を使用するためのポリシーとその参照が含まれています。

<wsdl:service name="echoService">
   <wsdl:port name="echoPort" binding="tns:echoBinding">
        <soap:address location="http://pponnala-tecra-xp.stc.com:18181/
         echoService/echoPort"/>
        <wsp:PolicyReference URI="#HttpBasicAuthBindingBindingPolicy"/>
    </wsdl:port>
</wsdl:service>

<wsp:Policy wsu:Id="HttpBasicAuthBindingBindingPolicy">
    <mysp:MustSupportBasicAuthentication on="true">
        <mysp:BasicAuthenticationDetail>
           <mysp:Realm realmName="file"/>
        </mysp:BasicAuthenticationDetail>
    </mysp:MustSupportBasicAuthenti</wsp:Policy>

アプリケーション変数を使用した名前/値ペアの定義

バインディングコンポーネントの「アプリケーション変数」プロパティーを使用すると、指定されたタイプの名前:値ペアのリストを定義できます。アプリケーション変数名は、対応するバインディングの WSDL 拡張性要素属性のトークンとして使用できます。たとえば、ホスト名を表すアプリケーション変数を FOO と定義する場合、WSDL 属性は ${FOO} となります。「アプリケーション変数」プロパティーで、名前として文字列値 FOO を入力し、必要な属性を値として入力します。アプリケーション変数を使用するアプリケーションを配備するとき、アプリケーションの WSDL で参照されているすべての変数が自動的にロードされます。

「アプリケーション変数」設定プロパティーでは、次の 4 つのタイプが提供されています。

• String: パスやディレクトリなどの文字列値を指定します。

• Number: 数値を指定します。

• Boolean: ブール値を指定します。「値」フィールドにチェックボックスが表示されます (チェックマーク付き = true)。

• Password: パスワード値を指定します。パスワードはマスクされ、アスタリスクだけが表示されます。

変数を使用することで、WSDL ファイルの柔軟性を高めることができます。たとえば、アプリケーション変数を使用してシステム固有の情報を指定することにより、同じ WSDL を異なる実行時環境に使用できます。その後、必要に応じてバインディングコンポーネントの実行時プロパティーから、任意の環境に対してこれらの値を変更することができます。

アプリケーション変数を使用するアプリケーションを配備するとき、アプリケーションの WSDL ファイルで参照されているすべてのアプリケーション変数が自動的にロードされます。アプリケーションを起動しようとしたときにアプリケーション変数の値が定義されていない (そのアプリケーション変数に値が指定されていない) 場合は、例外がスローされます。

アプリケーションの実行中にプロパティーを変更するには、「アプリケーション変数」プロパティーの値を変更してから、「サーバー」>「GlassFish」>「JBI」>「サービスアセンブリ」の下の「サービス」ウィンドウでアプリケーションを右クリックし、ポップアップメニューで「停止」をクリックします。プロジェクトを再起動すると、新しい設定が有効になります。

パスワード保護のためにアプリケーション変数を使用する

保護されていないパスワードは WSDL ファイルに平文で表示されますが、Password アプリケーション変数をトークンとして挿入することにより、パスワードを保護できます。次の例では、名前 SECRET とパスワード PROTECT を使用するパスワードアプリケーション変数を作成します。

パスワードアプリケーション変数を作成する

1. 「サーバー」ウィンドウの「サーバー」>「GlassFish·V2」>「JBI」の下の「バインディングコンポーネント」ディレクトリから sun-http-binding を選択します。

   sun-http-binding のプロパティーがプロパティーウィンドウに表示されます。

2. 「アプリケーション変数」プロパティーの省略符号ボタン (...) をクリックします。

   アプリケーション変数エディタが表示されます。

3. 「追加」をクリックし、変数のタイプとして Password を選択し、「了解」をクリックします。

   アプリケーション変数エディタに新しい行が追加されます。

4. 名前として SECRET、値として PROTECT を入力します。

   これはパスワードタイプなので、パスワードの文字はアスタリスクで表示されます。

5. ドル記号と中括弧を使用して、アプリケーション変数名 ${SECRET} を WSDL パスワード属性として使用します。

アプリケーション設定を使用した接続パラメータの設定

「アプリケーション設定」プロパティーを使用すると、作成したアプリケーション (サービスアセンブリなど) の外部接続パラメータを設定できます。また、アプリケーションの変更や再構築を行うことなく、同じアプリケーションを別のシステムに配備できます。たとえば、テスト環境で実行中のアプリケーションを、アプリケーションの再構築を行うことなく本稼働環境に配備できます。

「アプリケーション設定」プロパティーから、複合アプリケーションの外部接続パラメータの値を指定できます。これらのパラメータは通常、WSDL サービス拡張性要素で定義されます。ユーザーによって名前の付けられたエンドポイントの ConfigExtension プロパティーにこれらの値を適用することができます。アプリケーション設定プロパティーエディタには、そのコンポーネントのバインディングプロトコルに適用されるすべての接続パラメータのフィールドがあります。アプリケーション設定エディタで、保存された ConfigExtension の名前を入力し、接続パラメータを定義すると、プロジェクトの配備時に WSDL で定義されている接続属性よりもこれらの値が優先されます。これらの接続パラメータを再度変更するには、アプリケーション設定エディタで値を変更したあと、新しい値を適用するためにサービスアセンブリを停止してから起動します。

アプリケーション設定プロパティーエディタを使用すると、ユーザーが定義した独自の名前で参照できるさまざまなアプリケーション設定を作成できます。バインディングコンポーネントプロトコルが異なると、そその属性も異なります。HTTP バインディングの属性は JMS バインディングの属性とは異なるため、これらのバインディングコンポーネントのそれぞれで、アプリケーション設定プロパティーエディタに表示される属性は異なります。

アプリケーションの実行中にプロパティーを変更するには、「アプリケーション設定」プロパティーの値を変更してから、「サーバー」>「GlassFish」>「JBI」>「サービスアセンブリ」の下の「サービス」ウィンドウでアプリケーションを右クリックし、ポップアップメニューで「停止」をクリックします。プロジェクトを再起動すると、新しい設定が有効になります。

HTTP バインディングコンポーネントの「アプリケーション設定」プロパティーに含まれるパラメータは、「HTTP URL 位置」の 1 つだけです。

名前付き ConfigExtension をアプリケーション設定に適用する

1. CASA エディタで、エンドポイントの「設定拡張」プロパティーから、エンドポイントの設定拡張の名前を指定します。

2. 「サービス」ウィンドウで、JBI ノードの下の「バインディングコンポーネント」ディレクトリに移動し、アプリケーションで使用するバインディングコンポーネントを右クリックし、「プロパティー」を選択します。

   プロパティーウィンドウが表示されます。

3. バインディングコンポーネントのプロパティーの中で、「アプリケーション設定」プロパティーの省略符号ボタン (...) をクリックします。

   アプリケーション設定プロパティーエディタが表示されます。

4. ConfigExtension のユーザー定義の名前を入力し、接続パラメータの値を定義します。

5. 「アプリケーション設定」の値の定義が完了したら、アプリケーションを配備します。

拡張されたログ

HTTP バインディングコンポーネントの実行時ロガープロパティーには、ユーザー指定のレベルで監視および記録できる 30 種類以上のコンポーネントアクティビティーがあります。HTTP バインディングコンポーネントのプロパティーエディタから、これらの各アクティビティーに対して個別にログレベルを設定できます。

各ロガーは、次のレベルのいずれかで情報を記録するように設定できます。

• FINEST: メッセージは非常に詳細なトレース情報を提供します

• FINER: メッセージはより詳細なトレース情報を提供します

• FINE: メッセージは基本的なトレース情報を提供します

• CONFIG: 静的な設定メッセージを提供します

• INFO: 通知メッセージを提供します

• WARNING: メッセージは警告を示します

• SEVERE: メッセージは重大なエラーを示します

• OFF: ログメッセージなし

例外メッセージは一意の識別子で始まります。HTTP バインディングコンポーネントの例外メッセージは HTTPBC で始まります。例: HTTPBC-E00101.Start_failed=HTTPBC-E00101: \\{0\\} の起動に失敗しました。\\{1\\}

統計情報の監視

HTTP バインディングコンポーネントは、交換、エラー、要求、応答など、19 種類のコンポーネントアクティビティーに関する統計情報を記録して管理します。これらの統計情報は、エンドポイントのライフサイクル中に記録され、HTTP バインディングコンポーネントのプロパティーエディタからアクセスされます。たとえば、送信要求が完了した回数の統計情報は、アプリケーションの HTTP バインディングコンポーネントのプロパティーで、「統計情報」>「送信した要求」の現在の値として表示されます。

HTTP バインディングコンポーネントでの Tango Web サービス機能の使用

Tango は Metro プロジェクトの主要なコンポーネントです。Tango (WSIT とも呼ばれる) は、一般的に WS-サービスと呼ばれる WS-Security、WS-Reliable Messaging、WS-Transactions などの主要なエンタープライズ Web サービスを実装したものです。Tango は既存の JAX-WS および EJB プログラミングモデルを利用し、ユーザーが追加の設定ファイルをアプリケーションにバンドルすることでアプリケーションエンドポイントのセキュリティー、信頼性、およびトランザクション機能を定義できるようにします。

HTTP バインディングコンポーネントは、複合アプリケーションプロジェクトに適用できるいくつかの Tango 機能を公開します。

• メッセージの最適化: 処理と帯域幅の効率が最適になるように Web サービスメッセージを変更します。クライアントエンドポイントで 1 KB より大きい Web ドキュメントが処理される場合には、メッセージの最適化をお勧めします。

  MTOM (メッセージ送信の最適化機構) は、インターネット経由で効率よく送信されるように Web サービスメッセージを最適化します。つまり、処理時間を向上させ、必要な帯域幅を最小限に抑えるように、XML コードをエンコーディングします。

• WS-Addressing: 要求と応答の再ルーティングを可能にします。WS-Addressing は、正規化された Web サービスアドレスをサポートして、HTTP 以外の複数のトランスポートを使用できるようにします。

• 高信頼性メッセージング: アプリケーションメッセージが Web サービスエンドポイントに 1 回だけ、および場合によっては正しい順序で、配信されることを保証します。

  • WS Reliable Messaging: 2 つのパーティー間でメッセージの識別、追跡、および管理を信頼性の高い方法で行うための標準規格を定義し、メッセージが失われた場合や誤った順序で受信された場合に発生する障害から確実に復旧できるようにします。詳細については、「高信頼性メッセージ配信の設定」を参照してください。

  • WS Atomic Transactions: 2 フェーズのコミットプロトコルをサポートして、トランザクション内で呼び出されたオペレーションがすべて成功するか、そうでない場合はすべてロールバックされることを保証します。

• セキュリティー: 既存のトランスポートレベルセキュリティーと並行して機能し、相互運用可能なメッセージコンテンツの完全性と機密性を提供します。

  • WS Security: メッセージコンテンツの完全性と機密性を実装するためにセキュリティー保護された Web サービスを構築する場合に使用する SOAP 拡張機能の標準セットを定義します。各種のセキュリティートークン形式、信頼ドメイン、署名形式、および暗号化技術をサポートします。

  • WS Secure Conversation: コンシューマとプロバイダが複数メッセージ交換のための共有セキュリティーコンテキストを確立できるようにします。Secure Conversation 認証の仕様は、一連のメッセージを認証するための標準化された方法を定義して、Web サービスセキュリティーの短所に対処しています。WS Security Conversation モデルでは、セキュリティーコンテキストは、Web Services Trust のバインディングを使用して取得される新しい Web サービスセキュリティートークンタイプとして定義されます。

  • WS Trust: セキュリティートークンを発行、更新、および検証するためのメソッドを提供する、Web Services Security の拡張機能を定義します。信頼関係の管理をサポートします。

高信頼性メッセージ配信の設定

次の例は、プロジェクトの高信頼性メッセージ配信を設定する方法を示しています。NetBeans に含まれている「同期 BPEL プロセス」サンプルを使用しています。

「同期 BPEL プロセス」サンプルをインストールする

1. NetBeans IDE で、「プロジェクト」タブを選択して「プロジェクト」ウィンドウを開きます。

2. 「ファイル」メニューから「新規プロジェクト」を選択します。

   「新規プロジェクト」ダイアログボックスが表示されます。

3. 「新規プロジェクト」ダイアログボックスの「カテゴリ」リストで、「サンプル」>「SOA」>「同期 BPEL プロセス」を選択し、「次へ」をクリックします。

4. デフォルトのプロジェクト名と場所をそのまま使用し、「完了」をクリックします。

   「プロジェクト」ウィンドウに新規プロジェクトが表示されます。

プロジェクトの Web サービスを CASA エディタから設定する

1. NetBeans IDE で、「プロジェクト」ウィンドウの SynchronousSampleApplication ノードを展開します。「サービスアセンブリ」を右クリックし、「編集」を選択します。

   NetBeans IDE 内に CASA エディタが開き、同期サンプルアプリケーションのデザインビューが表示されます。CASA エディタは .casa ファイルの作成と編集を行います。このファイルには、複合アプリケーションの設定情報が含まれています。このサンプルには、CASA エディタによって SynchronousSampleApplication.casa ファイルが作成されています。

2. CASA エディタで、「プロジェクトの構築」アイコンをクリックして複合アプリケーションを構築します。

   構築が正常に完了すると、デザインビューに WSDL ポートエンドポイント、JBI モジュール、およびこのエンドポイントと JBI モジュールの間の接続が表示されます。

3. 「SOAP バインディング」を右クリックし、ポップアップメニューから「編集する WSDL ポートを複製...」を選択します。

   「複合アプリケーションに WSDL ポートを複製」ダイアログが表示されます。「了解」をクリックして続行します。「SOAP バインディング」アイコンに、プロパティーエディタと「サーバー/クライアント設定」にアクセスするためのアイコンが表示されます。

4. 「SOAP バインディング」上の「サーバー/クライアント設定」アイコンをクリックし、「サーバー設定」を選択します。

   SOAP バインディングポートの「WS-Policy Attachment」ダイアログボックスが表示されます。

HTTP バインディングコンポーネントで公開される Tango Web サービス属性の設定

複合アプリケーションの場合、Web サービス属性は、指定されたエンドポイントに関連付けられた WS Policy Attachment エディタを使用して、WSDL ポートに対して設定されます。WSDL ポートの WS Policy Attachment エディタには、CASA エディタからアクセスします。

この節の内容は次のとおりです。

• 「Tango (WSIT) Web サービス属性の設定にアクセスする」

• 「サーバー設定 — Web サービス属性」

• 「セキュリティー機構を設定する」

• 「高信頼性メッセージ配信の設定」

Tango (WSIT) Web サービス属性の設定にアクセスする

Web サービス属性は、指定されたエンドポイントに関連付けられた WS Policy Attachment エディタを使用して、各 WSDL ポートに対して設定されます。WS Policy Attachments エディタには CASA エディタからアクセスします。そのためには、WSDL ポートを右クリックし、「Web サービス属性の編集」—>「サーバー設定」または「クライアント設定」を選択します。

以降の説明では、複合アプリケーションがすでに作成されていると想定しています。このオプションは、CASA で WSDL ポートが複製または作成されたあとで使用可能になります。

特定のエンドポイントの WS-Policy Attachment エディタにアクセスする

1. NetBeans IDE の「プロジェクト」ウィンドウで、複合アプリケーションを展開します。「サービスアセンブリ」ノードを右クリックし、ポップアップメニューから「編集」を選択します。

   複合アプリケーションサービスアセンブリ (CASA) エディタが開き、複合アプリケーションが表示されます。

2. CASA エディタで、「プロジェクトの構築」アイコンをクリックして複合アプリケーションを構築します。

   構築が正常に完了すると、デザインビューに WSDL ポートエンドポイント、JBI モジュール、およびこれらの間の接続が表示されます。

3. WSDL ポートを作成または複製していない場合、そのポートを設定するための WS Policy Attachment は使用できません。ポートを複製するには、WSDL ポートを右クリックし、ポップアップメニューから「編集する WSDL ポートを複製」を選択します。

   

   ポートが複製されたあと、「ポートのプロパティー」アイコンと「Web サービス属性」アイコンがポートに追加されます。

4. ポートの「Web サービス属性」アイコン (ポート下部のアイコン) をクリックし、「サーバー設定」または「クライアント設定」を選択して、該当する WS Policy Attachment 設定エディタを開きます。

サーバー設定 — Web サービス属性

HTTP バインディングコンポーネントで公開されるサーバー設定 Web サービス属性は、WS Policy Attachment 設定エディタから設定されます。

サーバー設定 Web サービス属性には次のようなものがあります。

セキュリティー機構を設定する

この節では、Tango を介して使用できる次のセキュリティー機構と、各選択項目のサーバー設定オプションについて説明します。これらのセキュリティー機構の詳細については、Security Mechanisms を参照してください。

使用できるセキュリティー機構は次のとおりです。

• 「対称キーによるユーザー名認証 」

• 「相互証明書セキュリティー」

• 「トランスポートセキュリティー (SSL)」

• 「SSL を使用したメッセージ認証」

• 「SSL を使用した SAML 承認」

• 「承認証明書」

• 「SAML Sender-Vouches と証明書」

• 「SAML Holder-of-Key」

• 「STS 発行トークン」

• 「STS 発行トークンとサービス証明書」

• 表 21

対称キーによるユーザー名認証

対称キーによるユーザー名認証機構では、アプリケーションの完全性と機密性が保護されます。対称キー暗号化方式は、メッセージの署名と暗号化の両方に使用される単一の共有秘密鍵を基にしています。通常は、公開キー暗号化方式より高速です。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

• デフォルトユーザー: デフォルトのユーザー名とパスワードか UsernameCallbackHandler を設定します。あるいは、これらのオプションを空白にしておいて実行時にユーザーを指定します。

• GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

相互証明書セキュリティー

相互証明書セキュリティー機構では、認証とメッセージ保護によるセキュリティーを使用して、完全性と機密性が保護されます。この機構では、アプリケーションのクライアント側とサーバー側の両方に、キーストアおよびトラストストアのファイルが必要です。

相互証明書セキュリティーの WS Security を設定する例については、Using the WSIT Mutual Certificates Security Mechanism with the HTTP BC を参照してください。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア (別名なし): トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

トランスポートセキュリティー (SSL)

トランスポートセキュリティー機構では、メッセージ移送時の認証と機密性のために SSL が使用されます。トランスポートレイヤーのセキュリティーは、Secure Sockets Layer (SSL) でセキュリティー保護された HTTP トランスポート (HTTPS) を基にしています。このポイントツーポイントのセキュリティー機構は、認証、メッセージの完全性、および機密性のために使用できます。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

• GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

• GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

SSL を使用したメッセージ認証

SSL を使用したメッセージ認証機構は、暗号化によってセキュリティー保護された識別情報または認証トークンをメッセージに添付し、機密性保護のために SSL を使用します。認証は、ユーザー名サポートトークンまたは X.509 サポートトークンによって指定されます。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

• GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

SSL を使用した SAML 承認

SSL を使用した SAML 承認機構は、承認トークンをメッセージに添付します。機密性保護のために SSL が使用されます。この機構では、エンドユーザーに関する承認情報が SAML トークンで伝送されます。トークンの送信側は、実際に SAML トークンで資格情報を保証しています。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア (別名なし): クライアントの証明書および信頼できるルートが格納されているトラストストアの別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

• SAML コールバックハンドラ: SAML コールバックハンドラを指定します。デフォルトの SAML コールバックハンドラはないので、SAML コールバックハンドラを使用するにはそれを作成する必要があります。

• SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

承認証明書

承認証明書機構は、完全性と機密性のために対象キーを使用するセキュリティー保護されたメッセージを使用します。また、クライアント承認証明書を使用して、メッセージ署名に関連付けられたトークンで申請する内容を補強します。クライアントはサービスの証明書を認識し、要求は特殊な識別情報によって承認されている必要があります。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

SAML Sender-Vouches と証明書

この機構は、相互証明書を使用してメッセージの完全性と機密性を提供し、Sender-Vouches SAML トークンを使用して承認を提供します。Sender-Vouches 方式では、SOAP メッセージとその SOAP メッセージに追加される SAML 表明の間の対応が確立されます。(SAML 表明内の) SAML 主体ステートメントの主体と SOAP メッセージコンテンツの間の対応を確立するのに使用される確認証拠は、証明エンティティーによって提供されます。

メッセージペイロードには署名と暗号化を行う必要があります。要求者は、要求者が代行している実体の資格情報 (SAML 表明内にある) を保証します。イニシエータトークンは X.509 トークンであり、署名に使用されます。受信者トークンも X.509 トークンであり、暗号化に使用されます。サーバーの場合はこれが逆になり、受信者トークンは署名トークン、イニシエータトークンは暗号化トークンです。SAML トークンが承認に使用されます。

SAML Sender-Vouches と証明書を使用して WS Security を設定する例については、Using the SAML Sender Vouches with Certificates Security Mechanism with the HTTP BC を参照してください。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア (別名なし): クライアントの証明書および信頼できるルートが格納されているトラストストアの別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

• SAML コールバックハンドラ: SAML コールバックハンドラを指定します。デフォルトの SAML コールバックハンドラはないので、SAML コールバックハンドラを使用するにはそれを作成する必要があります。

SAML Holder-of-Key

この機構は、クライアントの公開キーおよび承認情報を伝送する (信頼できる機関から発行された) 署名付き SAML 表明を含んだメッセージの完全性と機密性を、相互証明書を使用して保護します。Holder-of-Key (HOK) 方式では、SOAP メッセージとその SOAP メッセージに追加される SAML 表明の間の対応が確立されます。詳細については、http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf で「SAML Token Profile」ドキュメントを参照してください。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア (別名なし): クライアントの証明書および信頼できるルートが格納されているトラストストアの別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

• SAML コールバックハンドラ: SAML コールバックハンドラを指定します。デフォルトの SAML コールバックハンドラはないので、SAML コールバックハンドラを使用するにはそれを作成する必要があります。

STS 発行トークン

信頼できるセキュアトークンサービス (STS) によって発行されたトークンを使用してメッセージの完全性と機密性を保護します。

この機構を Web サービスに使用するには、使用するセキュリティー機構でこのオプションを選択します。サービスから参照できるセキュリティートークンサービスが必要です。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。クライアントのトラストストアに STS の証明書が格納されている必要があります。更新済みの GlassFish 証明書を使用していれば、この証明書の別名は wssip です。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

• STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。

STS 発行トークンとサービス証明書

「STS 発行トークン」に似ていますが、クライアントは指定の STS によって発行された SAML トークンを使用して認証するようにサービスから要求されます。また、サービス証明書を使用して機密性保護が実現される点も異なります。サービス証明書は、サービスを認証するため、およびメッセージ保護を提供するためにクライアントで使用されます。GlassFish の場合は、デフォルトの証明書 s1as が付属しています。

この機構を Web サービスに使用するには、使用するセキュリティー機構でこのオプションを選択します。サービスから参照できるセキュリティートークンサービスが必要です。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。クライアントのトラストストアに STS の証明書が格納されている必要があります。更新済みの GlassFish 証明書を使用していれば、この証明書の別名は wssip です。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

• STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。

STS 発行承認トークン

「STS 発行トークン」に似ていますが、クライアントは指定の STS によって発行された SAML トークンを使用して認証されます。承認トークンがメッセージ署名への署名に使用されます。

メッセージの完全性と機密性は、サービス用の暗号化された短期キーを使用して保護されます。短期キーでは、キーハンドルが破棄されたときに交換キーの値を暗号化サービスプロバイダ (CSP) から削除するアルゴリズムが使用されます。サービスでは、指定の STS によって発行された SAML トークンでメッセージが承認されていることが要求されます。

この機構の場合、サービスでは、セキュリティー保護された通信が信頼できる STS によって承認されていることが要求されます。サービスは、クライアントを直接信頼するのではなく、指定の STS によって発行されたトークンを信頼します。つまり、STS はクライアントを安全に認証するための 2 番目のサービスの役割を果たします。

この機構を Web サービスに使用するには、使用するセキュリティー機構でこのオプションを選択します。サービスから参照できるセキュリティートークンサービスが必要です。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。クライアントのトラストストアに STS の証明書が格納されている必要があります。更新済みの GlassFish 証明書を使用していれば、この証明書の別名は wssip です。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

• キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

• キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

• トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

• STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。

クライアント設定 — Web サービス属性

WS Policy Attachment エディタに公開されるクライアント設定 Web サービス属性は、プロジェクトおよびサーバー設定によって決まります。

HTTP バインディングコンポーネントで公開される属性について、次の表で説明します。

WS-Transaction の使用

HTTP バインディングコンポーネントは、Tango (WSIT) を介して使用できる WS-Atomic Transaction の実装である、WS-Transaction と統合されています。WS-AtomicTransaction 仕様は、2 フェーズのコミットプロトコルを定義して、トランザクションがすべて完了するか、そうでない場合はすべてロールバックされることを保証します。これは「オールオアナッシング」とも呼ばれます。トランザクションが成功したかどうかに応じて、登録されているトランザクション参加者はコミットまたは中止を決定します。両方の参加者に最終結果が通知されます。

SoapWSATCompositeApp サンプル複合アプリケーション

HTTP バインディングコンポーネントおよび BPEL サービスエンジンでの WS-Transaction の使用方法を示すサンプル複合アプリケーションについては、HTTP BC AtomicTransactions を参照してください。

サンプルでは、次の内容が示されています。

• 既存の Java Transaction API (JTA) を使用してトランザクションを開始および完了する。

• トランザクション Web サービスオペレーションの呼び出しフローの、クライアントから Web サービスへのトランザクションコンテキスト。

• Web サービスクライアントから HTTP/SOAP バインディングコンポーネントへの、トランザクションコンテキストのインポート。

• HTTP/SOAP バインディングコンポーネントから BPEL サービスエンジンへの、および、BPEL サービスエンジンから HTTP/SOAP バインディングコンポーネントへの、トランザクションの伝達。

• HTTP/SOAP バインディングコンポーネントから Web サービスへの、トランザクションコンテキストフローの再開。

• クライアントによって作成されたトランザクションで更新される持続リソースは、単一の原子トランザクションとしてすべてコミットされるかロールバックされます。

• クライアント側のコードが JTA トランザクションをコミットまたは中止したあと、クライアントはトランザクション Web サービスに対して確認メソッドを呼び出すことによって、トランザクション内のすべてのオペレーションが成功または失敗したことを確認します。

HTTP バインディングコンポーネントのクラスタ化サポート

クラスタは、0 個以上のサーバーインスタンスを含んでいる論理エンティティーです。簡単に言えば、クラスタはアプリケーションサーバーインスタンスの集まりであり、クラスタ化されたアプリケーションインスタンス全体に作業負荷を分散してパフォーマンスを最適化できます。このようなサーバーインスタンスは、同じアプリケーション、リソース、および設定情報を共有します。クラスタ化されたサーバーインスタンスは、1 つのクラスタだけに属し、すべてをその親クラスタから継承します。クラスタ内のインスタンスは、任意の数のコンピュータに分散している可能性があります。

Sun Java System Application Server では、単一のホストまたは複数のホストにインストールされた同種の (同じ JBI コンポーネント、アプリケーション、および設定情報を持つ) アプリケーションサーバーインスタンスをクラスタ化できます。各アプリケーションサーバーインスタンスで実行されるアプリケーションは独立していますが、Web ブラウザベースの (DAS) クライアントまたはコマンド行クライアントを介した管理インフラストラクチャーによって管理することもできます。

HTTP ロードバランサ

HTTP ロードバランサは、HTTP 要求および HTTPS 要求を受け入れ、それらをクラスタ内のアプリケーションサーバーインスタンスに分散する、Web サーバープラグインです。これにより、HTTP バインディングコンポーネントを水平に拡大縮小して、Sun Java System Application Server クラスタ内の複数のインスタンスで実行することができます。

クラスタ化には、次のような多数の利点があります。

• 複数の物理的マシンに作業負荷を分散することにより、全体的なシステムスループットが増加します

• 各サーバーのハードウェア容量が異なる場合は、より強力なホストに優先的に作業負荷を分散することができます

• ある特定のアプリケーションサーバーインスタンスが過負荷または使用不可の状態になった場合、もっとも負荷の少ないアプリケーションサーバーインスタンスに要求を再ルーティングできます

• クラスタ化はクライアントには意識されません。クライアントに関するかぎり、HTTP 要求はすべて、ロードバランサが設定されている Web サーバーインスタンスに送信されます

HTTP ロードバランサには次の機能があります。

• スティッキーラウンドロビン負荷分散アルゴリズム

• 複数クラスタのサポート

• 設定可能な健全性フェイルオーバー機能 (30 ミリ秒未満)

• ロードバランサに動的に加えられた変更の確認と再読み込み

• 静止化のサポート - Web サービスのローリングアップグレードを可能にします

• べき等 URL に対する失敗した要求の自動再試行

• 設定可能なエラーページ

HTTP バインディングコンポーネントをクラスタ化用に設定する

HTTP バインディングコンポーネントをクラスタ化用に設定する処理の大部分は、Sun Java System Application Server (GlassFish) によって行われます。HTTP バインディングコンポーネントは、アプリケーションサーバーにインストール済みのコンポーネントです。デフォルトの HTTP および HTTPS ポート番号は、バインディングコンポーネントがサーバーインスタンスにインストールされたときに計算され、事前に割り当てられています。HTTP バインディングコンポーネントによって提供される Web サービスは、「http://<hostname>:<port>/<context>」という構造の一意の URL 識別子で識別されます。

クラスタ内の各コンポーネントインスタンスはリソースに対して排他的アクセスを持つ必要があるため、各コンポーネントインスタンスに一意のポート番号が割り当てられます。コンポーネントが各インスタンスに配備されるときに、WSDL アーティファクトで定義済みのトークン名を使用して、実際のポート値が解決されます。

定義済み HTTP ポートトークン

定義済みトークンの名前は次のとおりです。

• HTTP ポートの場合は ${HttpDefaultPort}

• HTTPS ポートの場合は ${HttpsDefaultPort}

これらのトークンは、アプリケーションクライアントが HTTP 要求をデフォルトポートに送信できるように、エンドポイント URL (soap:address) で実際のポート番号の代わりに使用されます。その後、アプリケーションの配備時に、トークンの値は設定されているデフォルト値に基づいて HTTP バインディングコンポーネントによって解決されます。

HTTP バインディングコンポーネントを再インストールした場合、各コンポーネントインスタンスのデフォルトポートを適切に設定する必要があります。

${HttpDefaultPort} トークンについて

ここでは、${HttpDefaultPort} トークンの概略と、アプリケーションの配備時にこれがどのように解決されるかについて説明します。

GlassFish Web サービスは常に指定の HTTP ポート (設定済みのデフォルトは 8080) に配備されますが、それと同様に HTTP バインディングコンポーネントにも、Web サービスが配備されるデフォルトの HTTP ポートがあります。HTTP バインディングコンポーネントは GlassFish にインストール済みのコンポーネントとして付属しているため、デフォルトの HTTP ポートが常に割り当てられています。デフォルトポートは、GlassFish のインストール時に JBI ランタイムモジュールで設定されます。その際、GlassFish ドメイン内の各 HTTP バインディングコンポーネントインスタンスに、使用可能なポートが割り当てられます。

最初、このデフォルトポート設定と ${HttpDefaultPort} トークンは、クラスタ化をサポートするために WSDL URL に置かれ、同じマシンで複数の HTTP BC インスタンスを実行できるようになっていました。そのため、各インスタンスに割り当てられたポートの実際のポート値は、衝突が発生しないように、アプリケーションの配備時にポートトークンを使用して解決されます。

それ以降、ポートの使用法が発展して、HTTP バインディングコンポーネント (JBI の Web サービスコンテナ) は GlassFish Web サービスコンテナと同様の動作をするようになりました。アプリケーションがバインディングコンポーネントに「到着」すると、バインディングコンポーネントはそのデフォルトの HTTP ポート設定を検索し、URL 内のトークンを実際のポート番号で置き換えます。デフォルトのポート番号が設定されていない場合は、「初期化失敗」例外がスローされます。

一般的なユーザーシナリオ

次に示す一般的なユーザーシナリオは、特定のビジネス目標を達成するためにコンポーネントが外部のシステムとどのように対話するかを示しています。最初の 5 つのシナリオは design-time オペレーションに適用され、残りのシナリオは runtime オペレーションに適用されます。

1. 「HTTP 拡張性要素を WSDL エディタから検証する」

2. 「WSDL ドキュメントに SOAP テンプレートを追加する」

3. 「WSDL ドキュメントに HTTP テンプレートを追加する」

4. 「HTTP 基本認証を使用してオペレーションを呼び出す Web サービスクライアント」

5. 「HTTP 基本認証で保護されたオペレーションを実装する Web サービス」

6. 「SSL 認証を使用してオペレーションを呼び出す Web サービスクライアント」

7. 「SSL 認証で保護されたオペレーションを実装する Web サービス」

HTTP 拡張性要素を WSDL エディタから検証する

この例では、HTTP 拡張性要素の検証を WSDL エディタから実行します。この例では、HTTP 拡張性要素を含んだ既存の WSDL ドキュメントで作業していると想定しています。

結果

エディタの下部に「WSDL 検証」ウィンドウが表示されます。通常フローの場合、エラーは見つからなかったというメッセージが表示されます。例外フローの場合、現在のエラーをすべて表示するダイアログが表示されます。

メインシナリオ

このシナリオは、通常フローと例外フローのどちらについても同じです。

1. WSDL をダブルクリックして WSDL エディタを開きます。

2. WSDL エディタのツールバーの「XML の検証」ボタンをクリックします。NetBeans IDE の下部に「出力」区画が表示されます。

3. プロジェクトエクスプローラで WSDL ファイルを右クリックし、ポップアップメニューから「XML の検証」を選択します。検証結果が「出力」区画に表示されます。

WSDL ドキュメントに SOAP テンプレートを追加する

この例では、新規 WSDL ドキュメントウィザードを使用して SOAP 拡張性要素を生成します。

結果

生成された WSDL には、バインディングレベル、バインディングオペレーションレベル、バインディングオペレーション入力レベル、およびポートレベルに SOAP 拡張性要素が含まれています。バインディングレベルのサブタイプは、新規 WSDL ドキュメントウィザードの手順 4 で選択したバインディングサブタイプに設定されます。

メインシナリオ

1. プロジェクトエクスプローラでプロジェクトを右クリックし、ポップアップメニューから「新規」>「WSDL ドキュメント」を選択することにより、新しい WSDL ドキュメントを作成します。新規 WSDL ドキュメントウィザードが表示されます。

2. ウィザードの手順 1 から 3 に従って、新しい WSDL ドキュメントを生成します。

3. ウィザードの手順 4 では、バインディングタイプとして「SOAP」を選択します。使用可能なバインディングサブタイプのオプションが「バインディングサブタイプ」フィールドに表示されます。

   適切なオプションを選択します。

   • RPC リテラル

   • ドキュメントリテラル

   • RPC エンコード

4. 「完了」をクリックして WSDL ドキュメントを生成します。

WSDL ドキュメントに HTTP テンプレートを追加する

この例では、新規 WSDL ドキュメントウィザードを使用して HTTP 拡張性要素を生成します。

結果

生成された WSDL には、バインディングレベル、バインディングオペレーションレベル、バインディングオペレーション入力レベル、およびポートレベルに HTTP 拡張性要素が含まれています。バインディングレベルのサブタイプは、新規 WSDL ドキュメントウィザードの手順 4 で選択したバインディングサブタイプに設定されます。

メインシナリオ

1. プロジェクトエクスプローラでプロジェクトを右クリックし、ポップアップメニューから「新規」>「WSDL ドキュメント」を選択することにより、新しい WSDL ドキュメントを作成します。新規 WSDL ドキュメントウィザードが表示されます。

2. ウィザードの手順 1 から 3 に従って、新しい WSDL ドキュメントを生成します。

3. ウィザードの手順 4 では、バインディングタイプとして「HTTP」を選択します。使用可能なバインディングサブタイプのオプションが「バインディングサブタイプ」フィールドに表示されます。

   適切なオプションを選択します。

   • Post オペレーション UrlEncoded

   • Post オペレーション UrlReplacement

   • Get オペレーション UrlEncoded

   • Get オペレーション UrlReplacement

4. 「完了」をクリックして WSDL ドキュメントを生成します。

HTTP 基本認証を使用してオペレーションを呼び出す Web サービスクライアント

この例では、クライアントが HTTP 基本認証を必要とするサービスを呼び出します。この例では、HTTP 基本認証を処理するように設定されている WSDL を含んだ配備済みの BPEL プロジェクトを実行していると想定しています。この BPEL プロジェクトは、HTTP 基本認証を使用して保護されたサービスを呼び出します。

結果

このサービスは、セキュリティー資格を確認したあと、想定されている HTTP 経由の SOAP メッセージを処理します。

メインシナリオ

1. Web サービスクライアントが、BPEL プロセスによって実装されている In-Only 抽象オペレーションを呼び出します。抽象オペレーションには具象 HTTP SOAP バインディングが存在するので、クライアントは SOAP over HTTP プロトコルを使用してオペレーションを適切に呼び出す必要があります。

2. クライアントとして機能している BPEL プロセスは、抽象オペレーションのメッセージを受け取り、別の In-Only 抽象オペレーションを呼び出します。このオペレーションには、HTTP 基本認証を必要とする具象 HTTP SOAP バインディングが存在します。

3. バインディングコンポーネントは正規化メッセージを受け取って SOAP メッセージに変換します。

4. バインディングコンポーネントは、該当するユーザー名とパスワードを Access Manager または WSDL から取得します。

5. バインディングコンポーネントは、メッセージおよび適切なセキュリティー資格をサービスに転送します。

HTTP 基本認証で保護されたオペレーションを実装する Web サービス

この例では、HTTP 基本認証で保護された BPEL プロジェクトを JBI で作成します。この例では、HTTP 基本認証を必要とするサービスを実装している BPEL プロセスを含んだ配備済みの BPEL プロジェクトを実行していると想定しています。

結果

JBI プロセスは、セキュリティー資格を確認したあと、想定されている HTTP 経由の SOAP メッセージを受け取ります。

メインシナリオ

1. BPEL サービスエンジンは、実装しているオペレーションに基本認証を必要とします。

2. HTTP バインディングコンポーネントは HTTP メッセージを受け取り、HTTP 基本認証のセキュリティー情報を解析します。

3. バインディングコンポーネントは、Access Manager または WSDL にあるユーザー名とパスワードの既知のデータベースを使用して、セキュリティー情報を確認します。

4. バインディングコンポーネントは正規化メッセージを作成し、正規化メッセージルーターに送信します。

5. BPEL サービスエンジンに属する BPEL プロセスが、抽象メッセージを処理し、Done または ERROR のどちらかの状態メッセージを返します。

SSL 認証を使用してオペレーションを呼び出す Web サービスクライアント

この例では、クライアントが SSL 認証を必要とするサービスを呼び出します。この例では、SSL 認証用に設定されている WSDL を含んだ配備済みの BPEL プロジェクトを実行していると想定しています。この BPEL プロジェクトは、SSL 認証によって保護されたサービスを呼び出します。

結果

サービスは、セキュリティー資格を確認したあと、想定されている HTTP 経由の SOAP メッセージを受け取ります。

メインシナリオ

1. BPEL プロセスは、サービスの実装に対してクライアントとして機能します。抽象オペレーションには具象 HTTP SOAP バインディングが存在するので、クライアントは SOAP over HTTP プロトコルを使用してオペレーションを適切に呼び出す必要があります。

2. HTTP バインディングコンポーネントは SOAP メッセージを受け取り、正規化メッセージに変換してから、正規化メッセージルーターおよび待ち受けている BPEL プロセスに転送します。

3. クライアントとして機能している BPEL プロセスは、抽象オペレーションのメッセージを受け取り、別の In-Only 抽象オペレーションを呼び出します。このオペレーションには、SSL 認証を必要とする具象 HTTP SOAP バインディングが存在します。

4. クライアント BPEL プロセスが抽象オペレーションを呼び出すと、正規化メッセージが生成され、正規化メッセージルーターに送信されます。

5. バインディングコンポーネントは正規化メッセージを受け取って SOAP メッセージに変換します。

6. バインディングコンポーネントは、サービスプロバイダとの間にセキュリティー保護された通信を確立し、要求を転送します。

SSL 認証で保護されたオペレーションを実装する Web サービス

この例では、サーバーが SSL 認証を必要とするサービスを実装します。この例では、SSL 認証を必要とするサービスを実装している BPEL プロセスを含んだ BPEL プロジェクト配備済みであると想定しています。

結果

サービスは、セキュリティー資格を確認したあと、想定されている HTTP 経由の SOAP メッセージを受け取ります。

メインシナリオ

1. Web サービスクライアントが、BPEL プロセスによって実装されている In-Only 抽象オペレーションを呼び出します。このオペレーションには具象 HTTP SOAP バインディングが存在するので、クライアントは HTTP プロトコルを使用してオペレーションを適切に呼び出す必要があります。

2. バインディングコンポーネントは SSL ハンドシェークを開始し、クライアントとのセキュリティー保護された通信を確立します。

3. バインディングコンポーネントは HTTP メッセージを受け取り、SSL 認証のセキュリティー情報を解析します。

4. バインディングコンポーネントは、既知の SSL 証明書を使用してセキュリティー情報を確認します。

5. バインディングコンポーネントは正規化メッセージを作成し、正規化メッセージルーターに送信します。

6. BPEL プロセスが抽象メッセージを処理し、Done または ERROR のどちらかの状態メッセージを返します。