4. WebOTX UDDI Registryの運用

本章では、WebOTX UDDI Registryの運用についての説明を行います。


4.1. 概要

ここではWebOTX UDDI Registryの運用に関する概要について説明します。

WebOTX UDDI Registryを用いて、UDDIレジストリを構築した場合、 運用作業として以下の作業を行う必要があります。


4.2. Webシステムの運用

WebOTX UDDI Registry は、Webサービスの機能を持ったWebアプリケーションです。 WebコンテナはWebOTX Web Editionと同じものを使用しています。 デフォルトインストールではWebサーバもWebOTXバンドルのApache Web Serverを使います。

インストール完了時点でアプリケーションの配備は完了した状態になっているので、 バージョンアップなどWebOTX UDDI Registry自身の置換が必要なければアプリケーションの配備・配備解除は不要です。

WebOTX UDDI Registryとして必要となるWebシステムの運用は、 通常、サービスの開始・終了・稼動状況の監視だけになります。 これらを含め必要となる運用操作は利用するWebサーバや、 WebOTXのWebコンテナのマニュアルを参照して行ってください。

WebOTX UDDI Registryのシステム構成図
WebOTX UDDI Registryのシステム構成図

UDDI Version 3.0仕様では、HTTPSプロトコルの使用が推奨されています。 WebOTXで、HTTPSによる接続を使用するためには、SSL機能をオンにして起動する必要があります。 SSL機能を利用するWebサーバの設定は、 4. HTTPサーバに関する設定を参照してください。


4.3. データベースの運用

WebOTX UDDI Registry は、 JDBCアクセス可能なSQLデータベースを用いて格納情報を管理しているため、 信頼性の高いデータの管理ができます。 SQLデータベースとしては、 商用のOracleに加えてフリーソフトウエアのPostgreSQLもサポートしており、 安価なUDDIレジストリの構築も可能です。 データベースを運用することになりますので、 データベースソフトウェアごとに必要となる運用(データ保全のためのセーブ・リストア、データベースサーバの起動・停止など)を各製品の説明書を参照して行ってください。


4.4. ユーザの管理

WebOTX UDDI Registryを用いて、 UDDIレジストリを構築した場合、 運用作業として「発行APIを使用可能なユーザの管理」を行う必要があります。 これらの作業は、 管理コンソールを用いて、 Webブラウザから行うことができます。 詳細は、「5.2.3. ユーザ管理」を参照してください。

登録されたサービス提供者である各ユーザは、 UDDI発行APIを通して各自が提供したい情報を、 UDDIレジストリに登録・変更・削除ができます。 また、管理コンソールやデータ・マネージャからも登録・変更・削除することができます。


4.5. レプリケーション

レプリケーションは、 分散した複数のノードからなるUDDIレジストリの間でデータの同期をとる機能です。 レプリケーションにより、 各ノード間でUDDIの保持するデータを同一にすることができます。 本節では、レプリケーションの設定方法について述べます。

レプリケーションは、 「レプリケーション設定ファイル」によりその動作を制御します。 (「4.5.1. レプリケーションの設定」参照。) 「レプリケーション設定ファイル」は、 レプリケーションを行う際のトポロジ(ノードの接続形態)などを記述した レプリケーションの動作を制御する設定ファイルです。

このファイルをレジストリ内部の全てのノードに配置することで、 各ノードが協調してレプリケーション動作を行います。


4.5.1. レプリケーションの設定

レプリケーションの設定作業の手順は大まかに以下のようになります。

  1. レプリケーション構成ノードの決定
    まず、レプリケーションに参加するノードを決定します。 各ノードにWebOTX UDDI Registryをインストールしてください。 また、そのノードを接続する形態(トポロジ)も決定します。
  2. レプリケーション設定ファイルの記述
    レプリケーション設定ファイルを記述します。 レプリケーション設定ファイルの記述方法については、 「4.5.2. レプリケーション設定ファイル」を参照してください。
  3. レプリケーション設定ファイルの配布
    記述したレプリケーション設定ファイルを各ノードに配布します。
  4. レプリケーション設定ファイルの配置とレプリケーションの再起動

    配布した各ノードでノードが動作している場合には一度停止します。 Webコンテナそのものを停止しても良いですし、 レプリケーション機能だけ停止(5.2.5. レプリケーション管理参照)してもかまいません。

    次に配布されたレプリケーション設定ファイルを各ノードの所定の位置に配置します。 この位置はserver.propertiesファイルのreplicationConfigurationプロパティ (「3.3.1. server.properties」参照)で指定されたファイルです。 もしこのプロパティが設定されていない場合には、このプロパティを設定してください。

    最後に、レプリケーションを再開します。 Webコンテナそのものを停止した場合はWebコンテナを再起動します。 レプリケーション機能だけ停止した場合には、 レプリケーション機能を起動(「5.2.5. レプリケーション管理」参照)してください。


4.5.2. レプリケーション設定ファイル

本節では、 前節で説明したレプリケーションの制御を行う「レプリケーション設定ファイル」の書き方について説明します。 WebOTX UDDI RegistryではこのXMLファイルを記述することでレプリケーション動作の制御を行います。

以降では、「レプリケーション設定ファイル」の例を用いて説明します。 実際に、レプリケーション設定ファイルを記述する場合にはこのファイルをテンプレートとして変更して使用すると良いでしょう。

以下に、レプリケーション設定ファイル内の要素を順に説明していきます。主要な要素を次に示します。

<serialNumber>は必須の要素で、replicationConfigurationファイルの変更回数を記述します。

例えば、"8"というような自然数をシリアル番号として記述します。

現在のバージョンのWebOTX UDDI Registryではこの要素の値は参照しません。 管理者がレプリケーション設定ファイルの管理のためにバージョン番号を振るなど、 適宜ご使用ください。 



    3     <!-- serialNumber 要素はreplicationConfigurationファイルの変更回数を記述するための必須要素です。 -->
    4     <serialNumber>8</serialNumber>

<timeOfConfigurationUpdate>は必須の要素で、 replicationConfigurationファイルの最新の変更日時を記述します。

例えば、"200203041859Z"というような日時を記述します。

現在のバージョンのWebOTX UDDI Registryではこの要素の値は参照しません。 管理者がレプリケーション設定ファイルの管理のために最終更新日付を記述するなど、 適当な日時を記述してください。 



    5     <!-- timeOfConfigurationUpdate 要素は最新の変更日時を記述するための必須要素です。 -->
    6     <timeOfConfigurationUpdate>200203041859Z</timeOfConfigurationUpdate>

<registryContact>は必須の要素で、replicationConfigurationファイルの管理者への連絡先を記述します。

連絡先の記述にはbusinessEntityのcontact要素の構造を利用します(そのため名前空間は"urn:uddi-org:api_v3"です)。

現在のバージョンのWebOTX UDDI Registryではこの要素の値は参照しません。 レプリケーション設定ファイルを記述した管理者が自己の連絡先の情報を記述するのにご使用ください。 



    7     <!-- registryContact 要素はreplicationConfigurationの管理者への連絡先を記述するための必須要素です。 -->
    8     <registryContact>
    9           <contact xmlns="urn:uddi-org:api_v3">
   10             <description>Registry Administrative Contact</description>
   11             <personName>Taro Nichiden</personName>
   12             <phone useType="Voice">123-456-7890</phone>
   13             <email useType="e-mail">NECtaro@jp.nec.com</email>
   14           </contact>
   15     </registryContact>

<operator>はオプションの要素で、0個以上記述することができます。

この要素には、レプリケーションに参加するUDDIレジストリ内のノードを全て列挙します。



   16     <!-- operator 要素はレプリケーションに関わるUDDIレジストリを列挙するためのオプション要素です。 -->
   17     <operator>

<operator>要素の中には、<operatorNodeID>要素を記述します(必須)。

この要素にはUDDIレジストリのノードIDを記述します。 自ノードのノードIDの値は、 server.propertiesファイルのnodeIDプロパティ(「3.3.1. server.properties」参照)で決定されます。



   18           <!-- operatorNodeID 要素はUDDIレジストリのIDを記述するための必須要素です。 -->
   19           <operatorNodeID>uddi:uddi1.jp.nec.com</operatorNodeID>

<operator>要素の中には、<operatorStatus>要素を記述します(必須)。

この要素はUDDIレジストリの登録状態("new"/"normal"/"resigned")を示します。 新規に追加された直後には"new"という値を、 通常の状態では"normal"という値を、 削除された状態では"resigned"という値を、 それぞれ指定します。

現在のバージョンのWebOTX UDDI Registryではこの要素の値で"new"/"normal"を区別しません。 ノードを追加する場合には"normal"として値を指定してください。 また、ノードを削除する場合には"resigned"として値を指定してください。 



   20           <!-- operatorStatus 要素は必須要素です。 -->
   21           <operatorStatus>normal</operatorStatus>

<operator>要素の中には、<contact>要素を1個以上記述します(必須)。

この要素はbusinessEntityのcontact要素と同様に連絡先を記述します。

現在のバージョンのWebOTX UDDI Registryではこの要素の値は参照しません。 他のノードの管理者の連絡先の情報を記述するのにご使用ください。 



   22           <!-- contact 要素はUDDIレジストリ管理者への連絡先を記述するための必須要素です。  -->
   23           <contact useType="Operator Contact" xmlns="urn:uddi-org:api_v3">
   24             <description>UDDI Node 1 operator</description>
   25             <personName>Taro Nichiden</personName>
   26             <phone useType="Voice"></phone>
   27             <email useType="e-mail">NECtaro@jp.nec.com</email>
   28           </contact>

<operator>要素の中には、<soapReplicationURL>要素を記述します(必須)。

この要素にはレプリケーション時に接続する接続先を記述します。



   31           <!-- soapReplicationURL 要素はレプリケーション時の接続先を記述するための必須要素です。 -->
   32           <soapReplicationURL>http://uddi1.jp.nec.com/uddi/services/replication</soapReplicationURL>

<communicationGraph>はオプションの要素で、 レプリケーションの経路を指定します。



   58     <!-- communicationGraph 要素はレプリケーションの経路を指定するためのオプション要素です。 -->
   59     <communicationGraph>

<communicationGraph>要素の中には、<node>要素を1個以上記述します(必須)。

この要素にはレプリケーション経路内のUDDIレジストリのIDを記述します。

ここには先の<operator>要素で宣言した<operatorNodeID>要素の値を指定します。



   60           <!-- node 要素はレプリケーション経路内のUDDIレジストリのIDを記述するための必須要素です。 -->
   61           <node>uddi:uddi1.jp.nec.com</node>
   62           <node>uddi:uddi2.jp.nec.com</node>
   63           <node>uddi:uddi3.jp.nec.com</node>

<communicationGraph>要素の中には、<controlledMessage>要素を1個以上記述します(必須)。

この要素ではレプリケーション時にedge要素で指定されるノード間で送受信されるメッセージAPIを指定します。

例えば、"get_changeRecords"/"notify_changeRecordsAvailable"というようなレプリケーションAPI名を記述します。



   64           <!-- controlledMessage 要素はレプリケーション時にedge要素で指定されるノード間で送受信されるメッセージAPIを指定します。 -->
   65           <controlledMessage>get_changeRecords</controlledMessage>
   66           <controlledMessage>notify_changeRecordsAvailable</controlledMessage>

<communicationGraph>要素の中には、<edge>要素を0個以上記述することができます。

この要素ではレプリケーションにおけるUDDIレジストリのノード間の接続関係を記述します。 



   68           <edge>
   69             <!-- message 要素はUDDIレジストリのノード間で利用するAPIを指定するための必須要素です。 -->
	        ...

<edge>要素の中には、<message>要素を1個以上記述します(必須)。

この要素ではUDDIレジストリのノード間で利用されるAPIを指定します。

ここには、"get_changeRecords"/"notify_changeRecordsAvailable"というようなAPI名を記述します。 以下で説明するmessageSender要素/messageReceiver要素で指定されたノード間では、 message要素で指定されたメッセージだけが送信可能です。 2つのノード間で、 get_changeRecordsのnotify_changeRecordsAvailableの両方を送受信したい場合は、 それぞれのmessage要素を指定した2つのedge要素を指定する必要があります。 



   69             <!-- message 要素はUDDIレジストリのノード間で利用するAPIを指定するための必須要素です。 -->
   70             <message>get_changeRecords</message>

<edge>要素の中には、<messageSender>要素を記述します(必須)。

この要素ではメッセージ送信側のUDDIレジストリのIDを指定します。

例えば、"uddi:uddi1.jp.nec.comというようなIDを記述します。



   71             <!-- messageSender 要素はメッセージ送信側のUDDIレジストリのノードIDを指定するための必須要素です。 -->
   72             <messageSender>uddi:uddi1.jp.nec.com</messageSender>

<edge>要素の中には、<messageReceiver>要素を記述します(必須)。

この要素ではメッセージ受信側のUDDIレジストリのIDを指定します。

例えば、"uddi:uddi2.jp.nec.com"というようなIDを記述します。



   73             <!-- messageReceiver 要素はメッセージ受信側のUDDIレジストリのノードIDを指定するための必須要素です。 -->
   74             <messageReceiver>uddi:uddi2.jp.nec.com</messageReceiver>

<maximumTimeToSyncRegistry>はオプションの要素で、 あるノードにおける変更が全てのノードに伝わるのに期待される時間を一時間単位で表します。

現在のバージョンのWebOTX UDDI Registryではこの要素の値は参照しませんので、敢えて指定する必要はありません。 



  103     <!-- maximumTimeToSyncRegistry 要素は、あるノードにおける変更が全てのノードに伝わるのに期待される時間を表すオプション要素です。 -->
  104     <maximumTimeToSyncRegistry>12</maximumTimeToSyncRegistry>

<maximumTimeToGetChanges>は必須の要素で、 更新データの受け取りに要する待ち時間の上限を1時間単位で記述します。 この要素はget_changeRecordsレプリケーションAPIを呼び出す最長時間間隔となります。

現在のバージョンのWebOTX UDDI Registryではこの要素の値は参照しません。 WebOTX UDDI Registryは、(notify_changeRecordsAvailableレプリケーションAPIにより変更の通知がない場合には) 一時間に一回get_changeRecordsレプリケーションAPIを呼び出します。 



  105     <!-- maximumTimeToGetChanges 要素は、更新データの受け取りに要する時間の上限を記述する必須要素です。 -->
  106     <maximumTimeToGetChanges>12</maximumTimeToGetChanges>

4.5.3. レプリケーション設定ファイルの実例

本節では、 前節で見た「レプリケーション設定ファイル」の例を実例として どのようなレプリケーションの構成が行われているかを説明します。

「レプリケーション設定ファイル」の例では、以下の三つのノードが存在します。 



   61           <node>uddi:uddi1.jp.nec.com</node>
   62           <node>uddi:uddi2.jp.nec.com</node>
   63           <node>uddi:uddi3.jp.nec.com</node>

これらをそれぞれ以下のようにノード1、ノード2、ノード3と呼びます。

  • ノード1: ノードIDはuddi:uddi1.jp.nec.com
  • ノード2: ノードIDはuddi:uddi2.jp.nec.com
  • ノード3: ノードIDはuddi:uddi3.jp.nec.com

    • これらのノードは以下の記述で、get_changeRecordsレプリケーションAPIを、 ノード1→ノード2→ノード3(→ノード1)の向きに発行することを表します。 

    

   68           <edge>
   69             <!-- message 要素はUDDIレジストリのノード間で利用するAPIを指定するための必須要素です。 -->
   70             <message>get_changeRecords</message>
   71             <!-- messageSender 要素はメッセージ送信側のUDDIレジストリのノードIDを指定するための必須要素です。 -->
   72             <messageSender>uddi:uddi1.jp.nec.com</messageSender>
   73             <!-- messageReceiver 要素はメッセージ受信側のUDDIレジストリのノードIDを指定するための必須要素です。 -->
   74             <messageReceiver>uddi:uddi2.jp.nec.com</messageReceiver>
   75           </edge>
   76           <edge>
   77             <message>get_changeRecords</message>
   78             <messageSender>uddi:uddi2.jp.nec.com</messageSender>
   79             <messageReceiver>uddi:uddi3.jp.nec.com</messageReceiver>
   80           </edge>
   81           <edge>
   82             <message>get_changeRecords</message>
   83             <messageSender>uddi:uddi3.jp.nec.com</messageSender>
   84             <messageReceiver>uddi:uddi1.jp.nec.com</messageReceiver>
   85           </edge>

    または以下の記述で、notify_changeRecordsAvailableレプリケーションAPIを、 ノード1→ノード3→ノード2(→ノード1)の向きに発行することを表します。 

    

   87           <edge>
   88             <message>notify_changeRecordsAvailable</message>
   89             <messageSender>uddi:uddi1.jp.nec.com</messageSender>
   90             <messageReceiver>uddi:uddi3.jp.nec.com</messageReceiver>
   91           </edge>
   92           <edge>
   93             <message>notify_changeRecordsAvailable</message>
   94             <messageSender>uddi:uddi3.jp.nec.com</messageSender>
   95             <messageReceiver>uddi:uddi2.jp.nec.com</messageReceiver>
   96           </edge>
   97           <edge>
   98             <message>notify_changeRecordsAvailable</message>
   99             <messageSender>uddi:uddi2.jp.nec.com</messageSender>
  100             <messageReceiver>uddi:uddi1.jp.nec.com</messageReceiver>
  101           </edge>

    notify_changeRecordsAvailableレプリケーションAPIはノードの情報に変更が生じたときにそれを通知するAPIです。 また、get_changeRecordsレプリケーションAPIは、実際に更新情報の取得を行うAPIで、 その返値として更新情報が返されます。 notify_changeRecordsAvailableレプリケーションAPIの呼び出し方向を青色、 get_changeRecordsレプリケーションAPIの呼び出し方向を赤色、 実際の変更情報の流れの方向を黄色で表すと、 このレプリケーション構成は以下の図で表せます。 ( notify_changeRecordsAvailableレプリケーションAPIは新しい変更情報を通知するものなので、 更新情報の向きと同方向になります。 逆に、 get_changeRecordsレプリケーションAPIの返値として更新情報が変えされるので、 get_changeRecordsレプリケーションの向きと更新情報の向きが逆になります。 )

    レプリケーションの構成

    get_changeRecordsレプリケーションAPIを指定したedge要素を用いてトポロジを構成すると、 更新情報を伝えることができます。

    さらに、 notify_changeRecordsAvailableレプリケーションAPIを指定したedge要素を、 get_changeRecordsレプリケーションAPIを指定したedge要素に対して逆向きに付加することで、 変更のあったノードがその更新情報を送信するノードに対しての通知を notify_changeRecordsAvailableレプリケーションAPIで行うことができるため、 変更の伝搬がスムーズに行われます。 そのため、 通常は notify_changeRecordsAvailableレプリケーションAPIと get_changeRecordsレプリケーションAPIを指定したedge要素を逆向きにした組にしてノード間に設定するのが良いでしょう。

    なお、WebOTX UDDI Registryでは、 get_changeRecordsレプリケーションAPIを指定したedge要素が、 全てのノードを環状につないでいる必要があります。


    4.6. サブスクリプションにおける更新情報通知処理

    4.6.1. 概要

    サブスクリプションは、UDDIレジストリに登録されているデータに対する変更の通知を行うための機能です。 サブスクリプション機能を使用することで、更新された情報のみを取得することができます。

    サブスクリプションは、事前に登録されたユーザが、 通知して欲しい更新情報に関する各種の条件を記載したサブスクリプション情報を、 UDDIレジストリに登録することで、 UDDIレジストリからクライアント側に電子メール/SOAPにより更新情報の通知が行われます。 また、クライアント側がUDDIのAPIを使用して、 レジストリ側に対して更新情報の取得を依頼することもできます。

    サブスクリプション機能を実現するためのレジストリ側の処理には、 大きく以下の二つの側面があります。

    1. サブスクリプションAPIの処理
    2. 更新情報の通知処理

    WebOTX UDDI Registryでは、 前者(サブスクリプションAPIの処理)をWebOTX UDDI Registry本体が、 後者(更新情報の通知処理)をWebOTX UDDI Registry本体とは独立したサブスクリプション通知サーバが行います。


    4.6.1.1. サブスクリプションAPI

    サブスクリプション APIは、大きく二つの種類に分けることができます。

    一つ目は、save_subscription、delete_subscription、get_subscriptions、get_subscriptionResultsです。 これのAPIは、それぞれ、サブスクリプション情報の保存、削除、取得、更新情報の同期的取得の実行を行いますが、 いづれもサーバ(レジストリ)側で動作します。

    二つ目は、notify_subscriptionListenerで、保存したサブスクリプション情報に基づいて、 レジストリが更新情報の通知を行う際に、 サーバ(レジストリ)側からクライアント側を呼び出すAPIです。 そのため、これをクライアントサイドAPIと呼ぶことにします。 (本UDDIクライアントライブラリではクライアントサイドAPIはサポートしていません。)

    さて、サブスクリプション情報を登録すると、 その条件に合致する更新情報が取得できますが、 この取得方法には、以下の三つの方法があります。

  • サーバ側からのSOAP呼び出し
  • サーバ側からのメール送信
  • get_subscriptionResults APIを用いた更新情報の同期的取得
    •

    このうち、 「サーバ側からのSOAP呼び出し」と「サーバ側からのメール送信」は、 レジストリ側からクライアント側に通知を行う機能です。 これは更新情報の通知処理の主要な機能となるので、次節で説明します。

    「get_subscriptionResults APIを用いた更新情報の同期的取得」は、 クライアントが、get_subscriptionResulst APIを用いて、 自分の都合の良いタイミングで更新情報の取得を行うもので、 更新情報は、このAPIの呼び出しの返値として返されます。


    4.6.1.2. 更新情報の通知処理

    前節で述べたように、 サブスクリプションAPIによって登録されたサブスクリプション情報に基づいて、 UDDIデータの更新情報が、サブスクリプション情報の登録者に通知されますが、 その方法には、以下の二通りがあります。

  • サーバ側からのSOAP呼び出し
    notify_subscriptionListenerクライアントサイドAPIを用いてSOAPによる更新情報の通知を行います。 通知先のURLは、サブスクリプション情報 subscription要素 中のbindingKeyにより指示されるbindingTemplate中のaccessPointで指定され(http:かhttps:である必要があります)、 notify_subscriptionListenerクライアントサイドAPIを実装したSOAPサービスである必要があります。
  • サーバ側からのメール送信
    電子メールを用いて更新情報の通知を行います。 通知先の電子メールアドレスは、 通知先のURLは、サブスクリプション情報 subscription要素 中のbindingKeyにより指示されるbindingTemplate中のaccessPointで指定され(mailto:である必要があります)、 電子メールの本体は、notify_subscriptionListenerクライアントサイドAPIで通知されるSOAP Bodyになります。
    • この通知処理は、UDDIレジストリが主体的に行います。

    以上、前2節の内容をふまえ、 サブスクリプションAPIの使用形態を図示すると以下のようになります。

    サブスクリプション通知処理の概要 サブスクリプション通知処理の概要


    4.6.2. 構成

    WebOTX UDDI Resitryでは、 サブスクリプション通知機能を実現するために以下のような二つのプログラムからなる構成になっています。

    1. WebOTX UDDI Registry (本体)
    2. サブスクリプション通知サーバ
    これを図示したもの以下です。

    サブスクリプション通知機能の構成 サブスクリプション通知機能の構成

    WebOTX UDDI Registryは、 サブスクリプション情報の保存/変更/削除などを行うための Subscription APIの処理を行います。

    これに対して、サブスクリプション通知サーバは、 SOAP/電子メールによる更新情報の通知と、 そのための更新情報の作成を行うための専用サーバで、 WebOTX UDDI Registry (本体)とは独立して動作します。 このため、 サブスクリプションの通知処理が高くなることが想定される場合には、 サブスクリプション通知サーバを、 WebOTX UDDI Registry (本体)とは別のマシンで動作させることも可能です。


    4.6.3. 設定

    サブスクリプション通知機能を使用するには、 サブスクリプション通知サーバを正しく起動するために、 WebOTX UDDI Registryのプロパティファイル server.properties に、 サブスクリプション通知サーバのホスト名とポート番号を指定しておく必要があります。

    また、後述する電子メールによる通知機能を利用する場合、 server.propertiesに、 メール配送に使用するSMTPサーバのアドレスと 配送に使われる電子メールアドレス(Fromアドレス)を指定する必要があります。

    詳しくは3. WebOTX UDDI Registry環境設定の3.3.1. server.propertiesを参照してください。

    続いてサブスクリプション通知サーバの動作環境の設定を行います。

    サブスクリプション通知サーバの動作環境の設定は、 サブスクリプション通知サーバの起動スクリプトファイルを編集することで行います。 ${WebOTXのインストール先ディレクトリ}/UDDIReg/bin/ を参照してください。
    Windows系をお使いの場合は subscriptionServer.bat を、
    UNIX系/Linux系をお使いの場合は subscriptionServer.shを開いてください。

    subscriptionServer.bat

    rem
    rem JAVA OPTIONS
    rem
    set JAVA_OPTS=-Duddi.server.properties="C:\Program Files\NEC\WebOTX\UDDIReg\conf\server.properties"

    subscriptionServer.sh

    #
    # JAVA OPTIONS
    #
    JAVA_OPTS="-Duddi.server.properties=/opt/WebOTX/UDDIReg/conf/server.properties"

    太線の部分を、 お使いのWebOTX UDDI Registryの server.properties の存在する実際のパスを指定するよう、 必要に応じて修正してください。

    次に、使用するデータベースのJDBCドライバを設定します。

    subscriptionServer.bat

    rem Please specify JDBC Driver.
    set CLASSPATH=%CLASSPATH%;..\lib\ojdbc14.jar
    set CLASSPATH=%CLASSPATH%;..\lib\postgresql.jar

    subscriptionServer.sh

    # Please specify JDBC Driver.
    CLASSPATH=$CLASSPATH:../lib/ojdbc14.jar
    CLASSPATH=$CLASSPATH:../lib/postgresql.jar

    太線の部分を、 お使いのWebOTX UDDI Registryで使用しているJDBCドライバの置いてあるパスを指定するよう、 必要に応じて修正してください。 上記の例では、Oracle用(ojdbc14.jar)とPostgreSQL用(postgresql.jar)の双方を指定していますが、 一方を指定するだけで十分です。


    4.6.4. 起動と停止

    続いて、サブスクリプション通知サーバを起動/停止を行う手順について説明します。

    サブスクリプション通知サーバを起動するには、コマンドプロンプト等から下記のようにコマンドを入力します。

    Windows環境の場合は
    
CMD> D:\Program Files\NEC\WebOTX\UDDIReg\bin\startup.bat
    Unix、Linux環境の場合は
    
$ /opt/WebOTX/UDDIReg/bin/startup.sh

    サブスクリプション通知サーバを停止するには、コマンドプロンプト等から下記のように入力します。

    Windows環境の場合は
    
CMD> D:\Program Files\NEC\WebOTX\UDDIReg\bin\shutdown.bat
    Linux環境の場合は
    
$ /opt/WebOTX/UDDIReg/bin/shutdown.sh

    起動に成功した場合以下のように表示されます

    - SubscriptionServer
- starting up ...
- initialize
- initialize
- createNewTask
- successfully started.
- SubscriptionServer was started successfully.
- SubscriptionServer uses 9009 port.

    サブスクリプション通知サーバが起動していれば、 5.2. 管理コンソールから、 通知機能の起動/停止を行うことが出来ます。 通知機能の起動方法については、 5. WebOTX UDDI Registryツールガイドの 5.2.7.6. 通知処理の起動と停止を参照してください。

    サブスクリプション通知サーバが起動し通知機能が動作している場合、 その間に行われたsave_subscription APIとdelete_subscription APIの結果が記録され、 各サブスクリプション情報の<notificationInterval>要素に記された通知間隔ごとに、 サブスクリプション通知サーバが各サブスクリプションの<subscriptionFilter>内に記されたデータ検索用のAPIの要素を用いて、 更新情報を取得します。 

    <?xml version="1.0" encoding="UTF-8"?>
<subscription xmlns="urn:uddi-org:sub_v3">
  <subscriptionKey>uddi:subscriptioserver-findBusiness</subscriptionKey>
  <subscriptionFilter>
    <find_business xmlns="urn:uddi-org:api_v3">
      <authInfo>admin</authInfo>
      <findQualifiers>
        <findQualifier>uddi:uddi.org:findQualifier:approximateMatch</findQualifier>
      </findQualifiers>
      <name xml:lang="en">%### for subscriptionServer ###%</name>
    </find_business>
  </subscriptionFilter>
  <maxEntities>100</maxEntities>
  <notificationInterval>PT30S</notificationInterval>
  <expiresAfter>2004-04-29T11:47:00</expiresAfter>
  <bindingKey xmlns="urn:uddi-org:api_v3">uddi:bindingKey_001</bindingKey>
</subscription>

    このサブスクリプション通知サーバを使用したサブスクリプション通知の実行を行うには、 上の例で太字で示した、 サブスクリプション情報(<subscription>要素)内の<bindingKey>要素(オプション要素)を、 通知先の情報を表すbindingTemplate情報を指示するよう適切に指定する必要があります。

    このbindingKey要素で指定するbindingTemplate情報は、 WebOTX UDDI Registryの5.2. 管理コンソールでは、「アクセスポイント」に対応します。 アクセスポイントの参照方法については、 5.2. 管理コンソールの5.2.4.7. アクセスポイント情報詳細を参照してください。 アクセスポイントは、 5. WebOTX UDDI Registryツールガイドの 5.2.4.12. UDDIデータのアップロードを利用して新規登録や更新を行うことができます。

    5.2. 管理コンソール上では「アクセスポイント」となる bindingTemplate要素は、二つの情報： アクセス先の情報を表すaccessPoint要素の値と、 オプションのuseType属性(5.2. 管理コンソールは「種別」)からなります。


    <accessPoint useType="endPoint">http://someserver/uddireg/services/UDDIService</accessPoint>

    <accessPoint useType="endPoint">mailto:nectaro@sample.nec.com</accessPoint>

    例えば、 上のように、 http://(あるいはhttps://)で始まるURLが アクセスポイント(bindingTemplate要素)に指定された場合、 サブスクリプション情報内で指定された、 通知間隔ごとに、 照会APIによって指定される特定の条件にマッチしたUDDIデータの更新情報が、 notify_subscriptionListener クライアントサイドAPIの呼び出し形式による SOAP呼び出しにより、クライアントに通知されます。

    同様にmailto:で始まるURL形式でメールアドレスが指定された場合、 更新情報は指定されたメールアドレス宛に電子メールで通知されます。


    4.7. サブスクリプションを用いたデータ連携

    「サブスクリプションによるデータ連携」の機能は、 サブスクリプション機能を利用して、 他レジストリから自レジストリにUDDIデータを取り込むための機能です。 本機能を利用することで、他レジストリ内に保存されているUDDIデータ(の一部)を、 自レジストリに自動的に取り込むことが可能になります。


    4.7.1. 概要

    UDDIのデータは、通常、各レジストリに個別に保存され、 その間でデータの共有を行う仕組みは、 UDDI仕様では定義されていません。

    このため、 複数のホストにそれぞれ別のレジストリを設置し、 データを多重化することによって、 耐障害性を向上しようと思っても、 (照会APIと発行APIを用いて、 特定のデータをあるレジストリから別のレジストリに、 データのコピーを行うようなアプリケーションを自分で作成する以外には) 異なるレジストリ間でデータの連携を行うことが出来ませんでした。

    UDDI仕様では、データの複製を行うためのレプリケーションという機構が定義されており、 この機能を用いることで複数のホストの間でデータを同一に保つことが出来ます。 (WebOTX UDDI Registryもレプリケーション機能を実装しています。 「4.5. レプリケーション」を参照してください。 )

    しかし、 レプリケーションは、同一レジストリ内のノード間でデータの同期を行うものであり (逆にいうと、 レプリケーションによってデータが同期された「ノード」の集合を、 UDDI Version 3仕様では「レジストリ」と定義しています。)、 異なるレジストリ間ではデータの同期を行うことは出来ません。

    また、レプリケーションを用いる場合、全てのデータが同期の対象となるため、 他のホストからデータの一部だけを取り入れたりすることは出来ません。

    「サブスクリプションによるデータ連携」機能は、 サブスクリプション機能を利用することで、 他のレジストリから、 別のレジストリに特定のUDDIデータを取り込むことができる機能です。


    4.7.2. 構成と動作

    次に「サブスクリプションによるデータ連携」機能の構成と動作について説明します。

    サブスクリプションによるデータ連携機能は、 二つのレジストリ間で(一部の)データの取り込みを行う機能です。 まず、以降の説明のために以下の用語を用いることにします。

    他レジストリ
    データの提供側になるレジストリです。 サブスクリプションAPIを実装している必要があります。
    自レジストリ
    データの取得側になるレジストリです。
    データ連携ツール
    「サブスクリプションによるデータ連携機能」を実現しているプログラムです。 サブスクリプションAPIを用いて「他レジストリ」に接続するため、 他レジストリにSOAPで接続できる必要があります。

    自レジストリと他レジストリ、データ連携ツールの関係は以下のようになります。

    サブスクリプションによるデータ連携機能の構成図
    サブスクリプションによるデータ連携機能の構成図

    次にデータ連携ツールの動作の概要について説明します。

    データ連携ツールを実行すると、以下のような処理を行います。

    1. 他レジストリに対し、 事前に登録したサブスクリプション情報を指定しget_subscriptionResults APIを発行し、 他レジストリでの更新情報を取得する。
    2. データが追加/変更された場合、 そのUDDIデータを他レジストリから自レジストリに取り込む。
    3. データが削除された場合(deleted属性がtrueとなった<keyBag>要素に当該データが含まれる場合)、 自レジストリでもそのUDDIデータを削除する。

    データ連携ツールで指定できるサブスクリプション情報は、 サブスクリプション情報中の(subscriptionFilter要素で指定される) サブスクリプション・フィルタが、 find_business API、find_tModel API を呼び出すものである必要があります。 (find_binding API/find_service APIは使用できません。 find_binding API/find_service APIは、bindingTemplate/businessServiceを検索対象としますが、 UDDI仕様では、bindingTemplate/businessServiceは、 そのトップレベルの親であるbusinessEntityなしには存在できないからです。)

    また、取り込みの対象データが以下のようなものは取り込むことは出来ません。

    1. businessServiceがサービス射影(service projection)が含まれる場合
    2. bindingTemplateがhostingRedirectorを持つ場合
    3. accessPointのuseTypeがhostingRedirectorをもつ場合
    4. tModelが相互参照している場合

    4.7.3. 事前準備

    本機能を使用するためには、 事前に他レジストリに取得したい更新情報に関するサブスクリプション情報を登録する必要があります。

    サブスクリプション情報を登録するには、 Subscription APIを(発行するプログラムを作成し)使用する必要がありますが、 他レジストリがWebOTX UDDI Registryの場合には、 5.3. データ・マネージャを使用して、 WebブラウザベースのGUI画面から簡単に登録することが出来ます。 詳しくは、 「5.3.7.4. サブスクリプションのアップロード」を参照してください。

    登録するサブスクリプション情報は、 そのsubscriptionFilterにfind_businessかfind_tModelを指定してください。

    また、 サブスクリプション情報を登録すると、 そのサブスクリプション情報を一意に識別するサブスクリプション・キーが割り当てられますが、 このキーが「4.7.4. 設定」で説明する設定の際に必要になりまので、 保存しておいてください。


    4.7.4. 設定

    データ連携ツールを実行する前に、以下のように環境設定を行って下さい。まず、 ${WebOTXのインストール先ディレクトリ}/UDDIReg/bin/subscriptionRegister.propertiesを開き、 以下の太線の項目をお使いの環境に応じて適宜変更してください。 

    # source URL.
publicInquiryURL=http://localhost/uddi/services/UDDIService
publicPublishURL=http://localhost/uddi/services/UDDIService
publicSubscriptionURL=http://localhost/uddi/services/subscription

    他レジストリのURLです。localhost の部分をデータの提供元になるUDDIレジストリに合わせて変更してください。

    # destination URL.
localInquiryURL=http://localhost/uddi/services/UDDIService
localPublishURL=http://localhost/uddi/services/UDDIService

    自レジストリのURLです。localhost の部分をデータの受取り元になるUDDIレジストリに合わせて変更してください。 

    # UserName and Password of source node.
publicUser=admin
publicCred=adminadmin

    他レジストリにアクセスするためのユーザ名とパスワードです。

    # UserName and Password of destination node.
localUser=admin
localCred=adminadmin

    自レジストリにクセスする際のユーザ名とパスワードです。

    # It is of type xsd:duration and specifies how often change notifications
# are to be provided to a subscriber.
interval=P7D

    他レジストリへサブスクリプションを実行する際の、実行間隔指定です。 この例では7日間毎に他レジストリへサブスクリプション情報を取得しに行きます。 実行間隔内に何らかの変更が加えられたエンティティが検索されます。 必要であれば変更してください。 

    # period of time for which they would like the subscription to exist.
# It is of the XML Schema type xsd:dateTime.
expiresAfter=2005-01-19T10:15:30.123

    他レジストリへ、サブスクリプションを実行する際の終了時刻指定です。 この例では西暦2005年1月19日10時15分30.123秒を過ぎると、サブスクリプションの実行が終了します。 必要であれば変更してください。 

    # subscriptionKey.
subscriptionKey=uddi:00000000-0000-0000-abcd-000000000001

    他レジストリ上に登録したサブスクリプションを情報のサブスクリプションキーの指定です。

    以上でファイルsubscriptionRegister.propertiesの設定は終了です。

    次に、 データ連携ツール実行用のバッチファイル/シェルファイルの設定を行います。

    Windows系をお使いであれば

    ${WebOTXのインストール先ディレクトリ}/UDDIReg/bin/subscriptionRegister.bat
    を、UNIX系/Linux系であれば同ディレクトリのsubscriptionRegister.shを開いてください (下の例では見易いよう改行を入れています)。

    subscriptionRegister.bat

    rem
    rem JAVA OPTIONS
    rem
    set JAVA_OPTS=-Duddi.subscription.register.properties=
    "D:\Program Files\NEC\WebOTX\UDDIReg\conf\subscriptionRegister.properties"

    subscriptionRegister.sh

    #
    # JAVA OPTIONS
    #
    JAVA_OPTS=-Duddi.subscription.register.properties=
    /opt/WebOTX/UDDIReg/conf/subscriptionRegister.properties"

    太字の部分を、先に編集・設定した subscriptionRegister.propertiesファイルが存在するパス名を指定してください。


    4.7.5. 起動実行

    設定が終わったら、 先のバッチファイル/シェルファイルをコマンドプロンプト上から実行し、 データ連携ツールを起動します。

    Windows環境の場合は
    
CMD> subscriptionRegister.bat
    Unix、Linux環境の場合は
    
$ subscriptionRegister.sh

    更新された情報があった場合、例えば以下のようなメッセージが表示されます。 

    Using JAVA_HOME:       C:\jdk1.*.*_**
- initialize done.
- sleep for 60000msec till the next execution.
- woke up.
...(中略)...
- businessEntity (uddi:businessKey_001) is saved successfully.
- businessEntity (uddi:businessKey_002) is deleted successfully.
...(中略)...
- SubscriptionRegister is completed successfully.

    逆に、更新された情報がなかった場合、以下のようなメッセージが表示されます。 

    Using JAVA_HOME:       C:\jdk1.*.*_**
- initialize done.
- sleep for 60000msec till the next execution.
- woke up.
...(中略)...
- SubscriptionRegister is completed successfully.