概要

最近の企業間通信は、以前に比べて進化しており、規模も複雑さも増大した結果、企業のメッセージ・フローの管理とガバナンスが極めて重大かつ困難な問題を呈するようになっています。企業のメッセージ・フローは重要な収益の流れを表すことから、堅牢なツールを使って慎重に扱わなければなりません。しかしそのためには、企業にとって不可欠の資産の保護と標準的なビジネス手法の維持を実践するためのポリシーの導入が必要です。

多くの企業の間で、SOA 指向の通信システムを制御するビジネス指向のポリシーを確立、施行するためのスケーラブルな手段が求められています。これらのニーズに対処するために設計されているのが、Web Services Policy (WS-Policy) 標準とそのメカニズムです。

WebSphere が提供している 2 つの製品を連携させると、WS-Policy 標準に従ったビジネス・ポリシーの設定および施行が可能になります。それが、WebSphere Registry and Repository と WebSphere DataPower SOA アプライアンスです。

このチュートリアルでは、この 2 つの製品を連携させて使用することで、ビジネス・ポリシーを実装する具体的な方法を紹介します。例として実装するポリシーは、以下の 2 つです。

• 特定のエンタープライズ・アプリケーションに向けられたすべてのリクエストには署名が付けられていること
• そのエンタープライズ・アプリケーションから返されるすべてのレスポンスが暗号化されること

以下に、このチュートリアルで紹介するソリューションのアーキテクチャーを図解します。

ビジネス・マネージャーは、WebSphere Service Registry and Repository (レジストリー) 内にビジネス・ポリシーを設定することができます。DataPower アプライアンスは、レジストリーに設定されたポリシーを実際のメッセージ・フローに施行するために必要な構成情報を取得します。

レジストリーの構成

このチュートリアルでは、WSRR バージョン 7.5 リリースの機能を使用して、DataPower アプライアンスの構成を自動的に更新する例を紹介します。レジストリーの構成手順は、WSRR バージョン 6.2 以降で共通しています。

このポリシー施行アーキテクチャーを実装する最初のステップとして、まずはレジストリーを構成します。基本的な構成手順は以下のとおりです。

• 外部化するエンタープライズ・サービスが記述された WSDL をアップロードする
• 実装するポリシーが記述されたファイルをアップロードする
• レジストリー内に、WSDL を結果として返す保管済み検索を作成する

WSDL をアップロードする

バックエンドのエンタープライズ・サービスが記述された WSDL をアップロードするには、WSRR コンソールにログインして以下の手順を実行します。

1. 「Load Documents (文書のロード)」をクリックします。

2. ローカル・ファイルシステムから Echo.wsdl ファイルをロードします。

3. 「Service Documents (サービス文書)」領域で「WSDL Documents (WSDL 文書)」をクリックして、新しくロードした WSDL ファイルが使用可能になっていることを確認します。レジストリーでは、ファイル名 (Echo.wsdl) とネーム･スペース (http://ibm.com/was/wssample/sei/echo/) の両方を使用してファイルを識別することに注意してください。

ポリシー・ファイルをアップロードする

基本の WSDL が配置され、任意の DataPower アプライアンスからアクセスできるようになりました。次は、施行するビジネス・ポリシーが記述されたポリシー・ファイルをアップロードします。以下に、wsp-sp-1-1-sign-parts.xml ポリシー・ファイルの内容を記載します。

<?xml version='1.0' encoding='UTF-8'?>


<wsp:Policy 
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"
   xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
        oasis-200401-wss-wssecurity-utility-1.0.xsd"
   wsu:Id="wsp-sp-1-1-sign-parts">

  <dpe:summary xmlns="" xmlns:dpe="http://www.datapower.com/extensions">
    <dppolicy:domain xmlns:dppolicy="http://www.datapower.com/policy">
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
    </dppolicy:domain>
    <description>
      Implements WS Security Policy 1.1 - support SignedParts
    </description>
  </dpe:summary>

  <wsp:ExactlyOne>
    <wsp:All>
      <sp:SignedParts>
        <sp:Body/>
      </sp:SignedParts>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

この例でポリシー・ファイルが表現しているのは、すべての SOAP メッセージの本体には署名が付けられていなければならないというポリシーです。ただし、リクエスト・メッセージとレスポンス・メッセージとの区別はありません。このファイルは、DataPower アプライアンスの store:/// ディレクトリーから取得することができます。このディレクトリー内にあるファイルを必要に応じて local:/// ディレクトリーにコピーして、変更してください。

ポリシー・ファイルをレジストリーにアップロードする手順は以下のとおりです。

1. ページの最上部にある「Load Documents (文書のロード)」をクリックします。
2. ローカル・ファイルシステム上のポリシー・ファイルの場所を指定します。
3. 「Document Type (文書タイプ)」ドロップダウン・リストから「Policy (ポリシー)」を選択します。
4. 「OK」をクリックします。これにより、以下に示すパネルが表示されます。

5. 「Finish (終了)」をクリックします。すると、正常にアップロードされたことを伝える確認メッセージが表示されるはずです。

次に、暗号化に関するポリシーを表現するファイルをレジストリーにアップロードします。そのための手順も、上記のアップロード手順と変わりません。

6. ページの最上部にある「Load Documents (文書のロード)」をクリックします。
7. ローカル・ファイルシステム上のポリシー・ファイルの場所を指定します。
8. 「Document Type (文書タイプ)」ドロップダウン・リストから「Policy (ポリシー)」を選択します。
9. 「OK」をクリックします。これにより、以下に示すパネルが表示されます。

10. 「Finish (終了)」をクリックします。

これで基本となるポリシー表現が配置されたので、このポリシーと WSDL をどのように関連付けるかを記述するファイルを DataPower アプライアンスにアップロードする必要があります。

WSDL ファイルは、ファイル名 (Echo.wsdl) ではなく、ネーム･スペース (http://ibm.com/was/wssample/sei/echo/) で識別されることに注意してください。レジストリーにアップロードされているファイルのなかに、このネーム･スペースを持つファイルが他にもある場合、使用する予定の WSDL ファイルとは異なるファイルにポリシーが関連付けられる可能性があります。

ポリシー参照では、ファイルでポリシーに割り当てられた wsu:Id (「wsp-sp-1-1-encrypted-parts-body」) を参照しますが、その ID が含まれるファイルを参照するのではないことに注意してください。

以下の図に、ポリシー接続ファイルが WSDL と基本ポリシー表現をどのように接続するかを示します。

他のポリシー・ファイルをアップロードしたときと同じ方法で、ポリシー接続ファイルをアップロードします。

11. ページの最上部にある「Load Documents (文書のロード)」をクリックします。
12. ローカル・ファイルシステム上のポリシー・ファイルの場所を指定します。
13. 「Document Type (文書タイプ)」ドロップダウン・リストから「Policy (ポリシー)」を選択します。
14. 「OK」をクリックします。これにより、以下に示すパネルが表示されます。

15. 「Finish (終了)」をクリックします。すると、正常にアップロードされたことを伝える確認メッセージが表示されるはずです。

エンタープライズ・ビジネス・ポリシーでは、すべてのリクエストに署名が付けられること、そしてすべてのレスポンスが暗号化されることを規定しています。この 2 つの条件のうち、このポリシー接続ファイルが表現しているのは 1 つだけです。上記の手順でアップロードしたポリシー接続ファイルは、署名付きリクエストしか扱っていません。そこで、レスポンスの暗号化に対処するための、もう 1 つのポリシー接続ファイルが必要です。

前と同じアップロード手順に従ってください。

16. ページの最上部にある「Load Documents (文書のロード)」をクリックします。
17. ローカル・ファイルシステム上のポリシー・ファイルの場所を指定します。
18. 「Document Type (文書タイプ)」ドロップダウン・リストから「Policy (ポリシー)」を選択します。
19. 「OK」をクリックします。これにより、以下に示すパネルが表示されます。

20. 「Finish (終了)」をクリックします。すると、正常にアップロードされたことを伝える確認メッセージが表示されるはずです。

これで、必要なポリシー・ファイルはすべてアップロードされました。使用可能なポリシー文書のリストを表示すると、ポリシー接続ファイルがレジストリーで使用できるようになっていることを確認することができます。

WSRR がポリシーを正しく構文解析して、WSDL ファイルに適用したことを確認するには、レジストリー内で WSDL ファイルを開きます。それには、ホーム画面に戻り、WSDL 文書を表示します。すると、以下の画面が表示されます。

「Policy (ポリシー)」タブをクリックすると、以下の画面が表示されます。

echoOperationRequest および echoOperationResponse メッセージの下に記載されているポリシー表現に注目してください。この内容から、レジストリーがポリシー・ステートメントを正しく構文解析して WSDL に適用したことがわかります。DataPower アプライアンスがレジストリーから WSDL を取得するときには、この WSDL を受け取ります。

保管済み検索を作成する

レジストリーに保管済み検索を作成するには、まず始めに、レジストリー内に照会 (検索) を作成する必要があります。

以下に、保管済み検索の作成手順を説明します。

1. ホーム画面に戻り、左側のメニューで「Queries (照会)」項目の隣にある矢印をクリックします。

2. 照会ウィザードを起動するリンクをクリックします。
3. ドロップダウン・リストから「WSDL Documents (WSDL 文書)」を選択します。すると、以下のような画面が表示されます。

4. 「Next (次へ)」をクリックします。
5. 「Enter details (詳細の入力)」ページの「Name (名前)」フィールドに WSDL の名前を指定します (以下の図を参照)。

6. 「Next (次へ)」をクリックします。
7. すると、「Summary (要約)」ページに、照会の詳細が表示されます (以下の図を参照)。

8. 「Finish (終了)」をクリックします。これで、照会が実行されて結果が返されます。この照会は、指定された WSDL だけを結果として返します。

9. 「Save this Search (この検索を保存)」の下に、この検索の名前を入力します (例えば、「GetEchoWSDL」)。DataPower サブスクリプション・オブジェクトを構成するには、この名前を使用することになります。
10. 「保存 (Save)」をクリックします。

レジストリーの構成は、これで完了です。

WebSphere DataPower アプライアンスの構成

DataPower アプライアンスの Web サービス・プロキシー・サービスでは、上記の手順で構成したような WSRR の保管済み検索から、Web サービス・プロキシーの構成情報を取得することができます。現行の DataPower ファームウェアのバージョン 4.0.1.0 および WSRR バージョン 7.5 では、レジストリーに保存された WSDL が更新されると DataPower アプライアンスの構成情報も自動的に更新されるように設定することができます。この機能を使用すれば、ポーリング間隔 (数日に及ぶ場合もあります) が経過するのを待たずに、アプライアンスを即時に更新することができます。このセクションでは、保管済み検索サブスクリプションと併せて、この自動更新機能を使用するように Web サービス・プロキシーを構成する手順を詳しく説明します。

自動更新機能を有効にするには、まずアプライアンスの「XML Management Interface (XML 管理インターフェース)」の構成を調整する必要があります。それには、アプライアンスのデフォルト・デーモンに切り替えてから、以下の手順を実行します。

1. ナビゲーション・メニューから「Network (ネットワーク)」 > 「Management (管理)」 > 「XML Management Interface (XML 管理インターフェース)」の順に選択します。
2. 「WSRR Subscription (WSRR サブスクリプション)」ボックスにチェック・マークを付けます (以下の図を参照)。このボックスは、ファームウェア 4.0.1.0 を使用していない場合には表示されません。

3. 「Apply (適用)」をクリックします。

次に、サービスを作成するために使用するアプリケーション・ドメインに戻ります (通常は、デフォルト・ドメインではありません)。

「Control Panel (コントロール・パネル)」の「Web Service Proxy (Web サービス・プロキシー)」アイコンをクリックして、サービスの構成を開始します。

1. 既存の Web サービス・プロキシー・オブジェクトのリストの下にある「Add (追加)」ボタンをクリックします。すると、Web サービス・プロキシー構成プロセスの最初のページが表示されます。
2. 表示されたフィールドに、新しいプロキシーの名前を入力します。
3. 「Create Web Service Proxy (Web サービス・プロキシーの作成)」をクリックします。すると、Web サービス・プロキシーの WSDL 構成ページが表示されます。

4. 「WSRR Saved Search Subscription (WSRR 保管済み検索サブスクリプション)」をクリックします。

以下の図に示す一連のブランク・フィールドが表示されます。

5. 「New (新規)」フィールドに「Echo」と入力します。これが、サブスクリプション・オブジェクトの名前です。
6. 「WSRR Server (WSRR サーバー)」の下にある「+」ボタンをクリックします。これにより新しいウィンドウが開き、新規 WSRR サーバー・オブジェクトを作成するためのフォームが表示されます。
7. 以下の図に示すように WSRR サーバー・オブジェクトを構成します。

「SOAP URL」、「Username (ユーザー名)」、「Password (パスワード)」の各フィールドに入力する値は、それぞれの環境によって異なることに注意してください。また、(ポーリングではなく) 自動更新をサポートするには、「WSRR Server Version (WSRR サーバー・バージョン)」を「7.5 or later (7.5 以降)」にしなければなりません。保管済み検索サブスクリプションは、バージョン 6.2 以降でサポートされます。

8. 「Find a Saved Search (保管済み検索の検出)」をクリックします。これによって、アプライアンスがレジストリーにアクセスして、使用可能なすべての保管済み検索のリストを取得します。

9. リストから「GetEchoWSDL」を選択して、「Apply (適用)」をクリックします。
10. 「Synchronization Method (同期方式)」ドロップダウン・リストから、「Automatic (WSRR 7.5 or later) (自動 (WSRR 7.5 以降))」を選択します。WSRR サーバーに保管されている WSDL が変更されると、レジストリーが自動的に、新しいバージョンが使用可能になったことを DataPower アプライアンスに通知します。すると、DataPower アプライアンスはその新規バージョンをレジストリーから取得し、Web サービス・プロキシーが提供するサービスを必要に応じて変更します。注意する点として、このオプションを使用するには、前に説明したようにアプライアンスの XML 管理インターフェース構成を変更することが必要です。
11. 「WS-Policy Parameter Set (WS-Policy パラメーター･セット)」の下の「+」ボタンをクリックします。この Web サービス・プロキシーは、WSDL に記述されたポリシーを施行するように設定されています (「WS-Policy Enforcement Mode (WS-Policy 強制モード)」)。そのため、Web サービス・プロキシーには、リクエストに含まれる署名を検証するため、さらには暗号化されていないレスポンス・メッセージを暗号化するために使用するさまざまな鍵と資格情報のセットが必要です。
12. 「Parameter Set (パラメーター・セット)」を以下のように構成します。

「Parameter Name (パラメーター名)」および「Parameter Value (パラメーター値)」は、3 つすべてのエントリーで共通していることに注意してください。エントリーごとに異なるのは、「Policy Domain (ポリシー・ドメイン)」のみです。「Policy Domain (ポリシー・ドメイン)」の 1 つのエントリーのみを使用してポリシー施行の目標を達成することも可能ですが、3 つのドメインをすべて含めれば、パラメーター・セットと WSDL との間でネーム･スペースの問題が発生しません。ポリシー・ドメインを 1 つのみ使用する場合には、そのポリシー・ドメインがポリシー・ファイルで使用するネーム･スペースと一致していなければなりません。

この構成を完了するには、鍵のセット (公開証明書とそれに対応する公開鍵) を作成する必要があります。これらのオブジェクトを作成するには、「Parameter Name (パラメーター名)」ドロップダウン・リストから「Encryption Certificate (暗号化証明書)」を選択した後、「Parameter Value (パラメーター値)」の下にある「+」ボタンをクリックします。

Web サービス・プロキシーがポリシーを施行するために必要なすべての情報は、これらの「Encryption Certificate (暗号化証明書)」エントリーだけが含まれるパラメーター・セットによって提供されます。

オプションで、リクエストに含まれる署名のタイム・スタンプを Web サービス・プロキシーが無視するように設定するパラメーターを追加することもできます。タイム・スタンプが無視されない場合、署名の有効期限は 5 分で切れます。以下の図には、署名のタイム・スタンプを無視するためのパラメーターが追加されています。

12. パラメーター・セットが完成したら、「Submit (送信)」をクリックします。

Web サービス・プロキシー・サービスの構成ページは、以下の図のようになっているはずです。

13. 「Next (次へ)」をクリックします。すると Web サービス・プロキシーが WSRR サーバーにアクセスして、保管済み検索サブスクリプションによって返される WSDL を受け取ります。これにより、「Front Side Handler (フロント・サイド・ハンドラー)」の設定、および宛先 URL の調整を行うために必要な入力が表示されます。
14. 使用可能なハンドラーのリストから既存の「Front Side Handler (フロント・サイド・ハンドラー)」を選択するか、「+」ボタンをクリックして新規ハンドラーを作成します。新規ハンドラーは HTTP プロトコルを使用するので、すでに有効になっているデフォルトの他に、HTTP GET リクエストを使用可能にする必要があります。

15. 「Apply (適用)」をクリックしてフロント・サイド・ハンドラーを作成あるいは変更します。
16. URI の下にあるフィールドに「/echo」と入力します。
17. 「Edit/Remove (編集/削除)」の下にある「Add (追加)」をクリックします。
18. 「Remote (リモート)」プロパティーを調整して、宛先サーバーに接続するようにします。宛先サーバーの場所は、環境によって異なります。正しいレスポンスを提供する XML ファイアウォール・サービスの完全な構成は、ダウンロード・ファイルに含まれています。

19. 「Next (次へ)」をクリックすると、Web サービス・プロキシー・サービスはポリシー・パラメーター・セットを使用したサービスの構成を完了します。これで、Web サービス・プロキシーがリクエストを受け付ける準備は整いました。

20. Web サービス・プロキシーが Web サービス・プロキシー・サービスから WSDL を取得してポリシー・ステートメントを組み込むことを確認します。それには、ブラウザーで URL (以下はその一例です) にアクセスします。
    
    http://DP_addr:3110/echo?wsdl

これによって、WSDL が取得されます。以下に、この WSDL の最後の部分を記載します。ここに示されているように、ポリシー接続は正しくリクエスト・メッセージとレスポンス・メッセージに適用されています。

         
<wsdl:binding name="EchoSOAP" type="ns0:EchoServicePortType">
   <soap11:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
      <wsdl:operation name="echoOperation">
	<soap11:operation soapAction="echoOperation" style="document"/>

                 <wsdl:input name="echoOperationRequest">
		<wsp:PolicyReference URI="#policy1"/>
		     <soap11:body use="literal"/>
	      </wsdl:input>
	      
	      <wsdl:output name="echoOperationResponse">
		<wsp:PolicyReference URI="#policy0" />
		      <soap11:body use="literal"/>
	       </wsdl:output>

        </wsdl:operation>
</wsdl:binding>          

21. Web サービス・プロキシーの WSDL ページで、「WSDL Status (WSDL 状況)」として示されている「Okay」をクリックして、保管済み検索サブスクリプションの状況を確認します。

22. 署名付きリクエスト・ファイルをサービスに送信します。以下は、そのための curl コマンドの一例です。
    
    curl –data-binary @echo-signed
    http://DP_addr:3110/echo

以下に示すように、レスポンスは暗号化されるはずです。

このトランザクションのデバッグ･ログを調べると、Web サービス・プロキシーがリクエストに含まれる署名を見つけて検証を行っているポイントがわかります。署名が見つからなかった場合には、Web サービス・プロキシーはそのリクエストを拒否し、「Rejected by Policy (ポリシーによって拒否されました)」というエラー・メッセージを返します。

         
11:02:06	multistep	info	487360	request	9.32.115.47	
0x80c00002	wsgw (RegistryPolicy): rule (message-input_127_5-req): 
#2 filter: 'INPUT store:///verify.xsl' completed OK.

11:02:06	multistep	debug	487360	request	9.32.115.47	
0x80c0004e	wsgw (RegistryPolicy): Stylesheet URL to compile is 
'store:///verify.xsl'

以下のエントリーを見ると、暗号化されていないレスポンス・メッセージに Web サービス・プロキシーが暗号化を適用していることがわかります。

              
11:02:06	multistep	info	487360	response	
9.32.115.47	0x80c00002	wsgw (RegistryPolicy): rule 
(message-output_127_6-process-resp): 
#4 filter: 'enc-output store:///required-elements-filter.xsl' completed OK.

11:02:06	multistep	debug	487360	response	
9.32.115.47	0x80c0004e	wsgw (RegistryPolicy): Stylesheet URL 
to compile is 'store:///required-elements-filter.xsl'

11:02:06	multistep	info	487360	response	
9.32.115.47	0x80c00002	wsgw (RegistryPolicy): rule 
(message-output_127_6-process-resp): 
#3 Conditional on INPUT completed OK.

11:02:06	multistep	info	487360	response	
9.32.115.47	0x80c00002	wsgw (RegistryPolicy): rule 
(message-output_127_6-process-resp): 
#2 xform: 'Transforming INPUT with
http://127.0.0.1:63502/DocumentCryptoMap.xml?objDomain=Ryan&
objName=message-output_127_6-1-conditional-content-encrypt-2-enc-enc-cryptomap 
results stored in enc-output' completed OK.

11:02:06	multistep	debug	487360	response	
9.32.115.47	0x80c0004e	wsgw (RegistryPolicy): Stylesheet URL to compile is
'http://127.0.0.1:63502/DocumentCryptoMap.xml?objDomain=Ryan&
objName=message-output_127_6-1-conditional-content-encrypt-2-enc-enc-cryptomap'

診断

Web サービス・プロキシーは、サブスクリプションのさまざまな操作に関する通知メッセージを生成します。以下に、サブスクリプションおよび自動通知について Web サービス・プロキシーが生成したログ・エントリーの一部を抜粋します。

以下に記載するのは、WSRR サーバーとの初期登録時のメッセージ交換です。

      
09:51:16	wsrr	notice	69503	 	  	
0x810000c8	wsrr-saved-search-subscription (Echoer): 
WSRR subscriber registered using ws-proxy RegistryPolicy

09:51:16	wsrr	notice	69503	 	  	
0x810000c9	wsrr-saved-search-subscription (Echoer): 
WSRR subscriber unregistered using ws-proxy RegistryPolicy

以下に記載するのは、WSRR サーバーで作成されたサブスクリプションです (デフォルト・ドメインのログ)。

 
10:46:56	wsrr	info	101668	 	  	
0x81000451	Resolving 
'wsrr://WSRR25/376a0c37-eafa-4ac1.bef4.660fd266f4cc/#wsp-sp-1-1-encrypted-parts-body'.

10:46:56	wsrr	info	101668	 	  	
0x81000451	Resolving 
'wsrr://WSRR25/081ecd08-4c2b-4b32.9183.2b884d2b837c/#wsp-sp-1-1-sign-parts'.

10:46:56	wsrr	info	101668	 	  	
0x81000451	Resolving 'wsrr://WSRR25/8e42008e-125c-4cc4.bb24.147558142425/'.

10:46:56	wsrr	info	66257	 	  	
0x810004d0	wsrr-saved-search-subscription (Echoer): 
The subscription 'Echoer' contains '1' WSDL files.

10:46:56	wsrr	debug	66257	 	  	
0x810004ef	wsrr-saved-search-subscription (Echoer): 
Setting WSRR Event Notification bsrURI '0c12ef0c-baca-4aaf.aa37.a4581ca4373a'.

10:46:56	wsrr	debug	69663	 	  	
0x810004ce	The subscription 'Echoer' is creating the PolicyReference 
'wsrr://WSRR25/376a0c37-eafa-4ac1.bef4.660fd266f4cc/#wsp-sp-1-1-encrypted-parts-body' 
for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004cd	The subscription 'Echoer' is creating the AppliesTo 
URI 'http://ibm.com/was/wssample/sei/echo/#wsdl11.message(echoOperationResponse)' 
for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004cc	The subscription 'Echoer' is creating a 
PolicyAttachment for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004ce	The subscription 'Echoer' is creating the 
PolicyReference 
'wsrr://WSRR25/081ecd08-4c2b-4b32.9183.2b884d2b837c/#wsp-sp-1-1-sign-parts' 
for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004cd	The subscription 'Echoer' is creating the AppliesTo URI 
'http://ibm.com/was/wssample/sei/echo/#wsdl11.message(echoOperationRequest)' 
for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004cc	The subscription 'Echoer' is creating a 
PolicyAttachment for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	info	69663	 	  	
0x810004cb	The subscription 'Echoer' has a 
WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425' 
and '2' policy attachments.

10:46:56	wsrr	info	69663	 	  	
0x8100044d	The subscription 'Echoer' of type Saved-Search contains 
the WSDL 'Echo.wsdl' with bsrURI '8e42008e-125c-4cc4.bb24.147558142425' 
and location 'Echo.wsdl'.

10:46:55	wsrr	debug	69663	 	  	
0x810004e6	The subscription 'Echoer' creating a WSRR Notification 
Event for 'GetEchoWSDL' with bsrURI '7ee5467e-0bb0-40ef.9b3d.567bf4563d6c', 
Fetch Policy 'true', Notify IP '9.70.154.57', Notify Port '5550', and 
renewal interval '1'.

10:46:55	wsrr	info	69663	 	  	
0x810004e2	The subscription 'Echoer' is creating 
a WSRR Notification Event for 'GetEchoWSDL' of type 
'saved-search' with bsrURI '7ee5467e-0bb0-40ef.9b3d.567bf4563d6c'.

10:46:55	wsrr	notice	69503	 	  	
0x810000c8	wsrr-saved-search-subscription (Echoer): 
WSRR subscriber registered using ws-proxy RegistryPolicy

以下に記載するのは、Web サービス・プロキシー構成に組み込まれた新しい WSDL です。

   
11:37:54	ws-proxy	info	91567	 	  	
0x81000081	wsgw (RegistryPolicy): 
Adding new wsdl '8e42008e-125c-4cc4.bb24.147558142425'.

以下に記載するのは、アプリケーション・ドメインのログに含まれる更新通知に関するエントリーです。

         
11:37:54	ws-proxy	info	91567	 	  	
0x8100007c	wsgw (RegistryPolicy): Process update from subscription 
Echo for wsdl wsrr://WSRR25/8e42008e-125c-4cc4.bb24.147558142425/, 
service key 8e42008e-125c-4cc4.bb24.147558142425.

以下に記載するのは、更新通知に関するデフォルト・ドメインのログ・エントリーです。

以下に記載するのは、WSRR の変更 (保管済み検索が削除されるなど)、あるいは DataPower アプライアンスの変更によってサブスクリプションが無効になった場合の、アプリケーション・ドメインにおけるログ・エントリーです。

 
10:41:23	wsrr	warn	65121	 	  	
0x810000fc	wsrr-saved-search-subscription (Echoer): 
WSRR subscription Echoer fail to retrieve files from server

10:41:23	wsrr	error	65121	 	  	
0x810004f2	wsrr-saved-search-subscription (Echoer): 
Encountered an error while creating Automatic Subscription.

10:41:23	wsrr	debug	65121	 	  	
0x810004f6	wsrr-saved-search-subscription (Echoer): 
WSRR Event Notification bsrURI cleared.

10:41:23	wsrr	error	69663	 	  	
0x8100044f	Failed to fetch WSDL, Concept, or Saved 
Search 'GetEchoWSDL0' from 
http://9.70.155.25:9080/WSRR/6.2/Metadata/XML/Query/GetEchoWSDL0.

10:41:23	network	error	69663	 	  	
0x80e00040	url-open: Remote error on url 
'http://9.70.155.25:9080/WSRR/6.2/Metadata/XML/Query/GetEchoWSDL0'

エラーが修正されると、前に示したサブスクリプション初期化シーケンスが再び開始されます。

バージョン管理

多くの場合、エンドポイント・サービスはクライアントが使用しているうちに進化していきます。それは、顧客のニーズを満たすための変更、新しい機能を提供するための変更、あるいは標準との互換性を維持するための変更が加えられていくためです。通常、このような変更には、サービスを記述する WSDL ファイルを変更することが必要になってきます。サブスクリプションの自動更新を使用することの主な利点は、エンドポイント・サービスを記述する WSDL が変更されると、サブスクリプションに関連付けられた DataPower サービスも自動的に更新されることです。また、サービスの機能が変更されると WSDL が変更されて、WSDL の新しいバージョンが WSRR サービスにロードされます。

標準的な慣例として、WSRR サービスは既存のファイルを上書きしません。したがって、既存の WSDL の新しいバージョンが WSRR にロードされると、同じ名前とネーム･スペースを持つ 2 つのバージョンの WSDL がレジストリーに存在することになります。以下は、その一例です。

保管済み検索による照会は WSDL 文書の名前に依存するため、ロードされた両方のバージョンの WSDL を返します。DataPower アプライアンスは、バージョンの新旧に関わらず、最初に受け取ったほうの WSDL を使用します。

WSRR を使用してバージョン管理を行うには、いくつかの方法があります。

1. 新規 WSDL バージョンを追加して、古いバージョンを削除する。WSRR がこの変更を検出して DataPower アプライアンスに通知を送信すると、DataPower アプライアンスが新しいバージョンの WSDL を取得します。
2. 分類を使用する。レジストリー内の成果物のそれぞれを分類して、検索を分類の値に応じて行うことができます。以下の図に、WSDL に割り当てられた分類を示します。

右下隅に表示されている「Classifications (分類)」プロパティーを見てください。WSRR には、アセットのライフサイクルを管理するために設計された標準ガバナンス・モデルが組み込まれています。この図の上には、「Governance (ガバナンス)」タブが示されています。検索を、ここに示されたカスタム分類ではなく、標準ライサイクルの分類のいずれかに関連付けることもできます。

以下に示す照会ウィザードのパネルで、検索基準として使用する分類を選択することができます。

3. WSDL 文書の他のプロパティーを使用してバージョンを区別する。使用できるプロパティーには、カスタム・プロパティーも含まれます。カスタム・プロパティーも、分類を使用する方法と同じように使用することができます。以下は、その一例です。

「SearchKey」プロパティーが、WSDL レコードに追加されたカスタム・プロパティーです。

まとめ

DataPower アプライアンス上で動作する Web サービス・プロキシーは、企業が設定し、レジストリーの構成によって表現されたビジネス・ポリシーを有効に施行します。保管済み検索サブスクリプションを使用するように Web サービス・プロキシー・サービスを構成すると、これらの Web サービス・プロキシー・サービスのすべてが自動的に同じ構成を受信するようになります。

WebSphere Service Registry and Repository と WebSphere DataPower を組み合わせることにより、企業は一箇所でビジネス・ポリシーを確立し、そのポリシーを多数の場所に自動的に実装して施行することができます。DataPower アプライアンスはサブスクリプションによって自動的に自らを最新の状態に更新するため、ビジネスは容易にポリシーを変更して、その変更を自動的に DataPower のポリシー施行ポイントに伝播させることができます。

上に戻る

ダウンロード

ダウンロード形式について

参考文献

• Twitter で developerWorks をフォローしてください。
  
  
• ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。
  
  
• developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 概要
• レジストリーの構成
• WebSphere DataPower アプライアンスの構成
• 診断
• バージョン管理
• まとめ
• ダウンロード
• 参考文献
• 著者について
• コメント