| 2. UDDIレジストリについて |
本章では、UDDIレジストリの概要とWebOTX UDDI Registryについての説明を行います。
| 2.1. UDDIとは |
ここではUDDIについて説明します。
| 2.1.1. UDDIとSOAP、WSDL |
UDDI(Universal Description, Discovery and Integration)は、 Webサービスに関する情報を公開したり検索したりすることができる 「Webサービスのためのディレクトリサービス」を提供するもので、 SOAP(Simple Object Access Protocol(注))、WSDL(Web Service Description Language) と並んでWebサービスを実現するための最も重要な要素技術の一つです。
Webサービスを用いることで、 従来Webブラウザを用いて人手で行っていた作業をコンピュータで自動処理することが可能になります。 例えば、Webブラウザベースの本の購入を自動的に処理するシステムを作ることを考えてみましょう。 元来、ブラウザによる利用を想定したWebサイトに対して本の購買処理をコンピュータで処理するのですから、 相手のシステムがどのような画面構成をとるのか、 入出力フィールドはどうなっているのかを詳細に知らなければ、 正しく動作するシステムを構築することはできません。 またWebページは、いつ変更されるか容易にわからないので、 一度構築したシステムがある日突然動かなくなることも予想されます。
WebサービスではHTTPとXMLを利用したSOAPを利用することで、 ファイヤウォールを越えてアクセスできるWebブラウザの高い接続性を保持したまま、コンピュータによる自動処理が可能になります。 また、WSDLを用いることで各サービスにアクセスするためのインターフェースが厳密に定義されるため、 相手のサービスの呼び出し方の検査や呼び出すためのプログラムの一部を自動生成することができるようになります。
しかし、これだけでは利用したいサービスを見つけることができません。 Webサービスにも、Webページを見つけるためのポータルサイト・検索サイトに相当するものが必要になります。 これこそが、UDDIのWeb サービスにおける役割に他なりません。 UDDIは、Webサービスで利用可能なサービスへのアクセス方法やサービスの仕様を登録・検索するためのディレクトリシステムとして機能します。 Webサービスの利用者はUDDIを使用することで会社名やサービスの種類などから、 Webサービスへのアクセス方法やそのサービス仕様を入手することができるようになります。
サービスの利用者と提供者・UDDIとの関係は、次のように図示することができます。
UDDIの仕様に基づいてWebサービスのための情報を提供するWebサービスのコンポーネントをUDDIレジストリといいます。 UDDIレジストリはそれ自身がWebサービスになっており、SOAPを用いてアクセスすることができます。
| 2.1.2. UDDIの役割と意義 |
Webサービスを用いることで、従来のシステムよりも容易に企業をまたがるようなインターネット上のシステムが構築できるようになります。 これは単に物理的に分散したサイトから構成されるシステムが構築できるということだけを意味するのではありません。 世界中のあらゆるサイトが相互にアクセスできるということは、 世界中の企業がそのビジネスの必要性に応じて相互に接続するような柔軟性の高いB2Bシステムが構築可能だということであり、 これにより新たなビジネスの創出が期待できるということです。 このような点から考えるとUDDIは新しいビジネスパートナを発見し、 その間のやり取りをサポートするという重要な役割を担っているといえます。
| 2.1.3. UDDIとその標準 |
UDDIは、Version 2仕様まで、UDDI Projectでその仕様が定められてきましたが、 2002年7月30日に最新仕様のVersion 3.0が公開と同時にUDDI仕様は標準化団体のOASISに移管されました。 (UDDI Projectは300社以上が参加する UDDI仕様の作成と普及を行う業界団体で、 NECもadvisory memberとしてUDDI Projectに参加していました。) OASISは、XMLやWebサービス関連仕様の作成と普及を行う業界団体で、NECもOASISに参加しています。 UDDIの仕様はすべてOASISのWebサイト(http://uddi.org)からダウンロードすることができます。
2003年5月20日に、OASISはUDDI Version 2仕様をOASISオープン標準として最終承認しました。 引き続き、OASISのUDDI仕様技術委員会はVersion 3.0の承認作業を進めており、 今後のUDDI標準となると考えられます。 このような動向を受け、WebOTX UDDI Registryは最新のUDDI仕様Version3.0にいち早く対応しました。
| 2.1.4. パブリックUDDIとプライベートUDDI |
UDDIは遠い将来に実現する未来の技術というわけではありません。 現在でも下記の4社がUDDI仕様Version2に対応したUDDIレジストリサービスを行っており、 NTT Communicationsを除く3社が初期公開ベータテストという形でUDDI仕様Version3.0に対応したUDDIレジストリの試験運用を行っています。
(注)試験運用は2006年1月12日をもって終了いたしました。
このUDDIレジストリでは、誰もが登録されているデータの検索を行うことができます。 また、ユーザ登録すれば独自情報をUDDIに登録することもできます。 近い将来これらのUDDIレジストリが正式運用に入れば、これらのUDDIレジストリ を利用したWebサービスのシステムが、 そしてそれを利用したビジネスが続々と構築されてくるでしょう。 このように誰もがアクセス可能なUDDIはパブリックUDDIレジストリなどと呼ばれています。
これに対して、社内やグループ企業間など特定のサイトだけで利用可能なUDDIシステムも考えられます。 社内で利用されるシステムにもWebサービス技術を用いることで、 社内のサブシステム間の相互接続性/柔軟性を確保することができるようになります。 このような場合に運用されるUDDIレジストリは、 社内からのアクセスに対してのみ情報を提供するものになるでしょう。 このようなUDDIはプライベートUDDIレジストリなどと呼ばれます。
WebOTX UDDI Registry 3.xを用いることで、 このプライベートUDDIレジストリを容易に構築することができます。 また、WebOTX UDDI Registry 3.xは、最新のUDDI仕様Version3.0で定義されるマルチバージョン機能を実装しているので、 現在、広く使われているUDDI仕様Version2との互換性もあります。
| 2.2. UDDIレジストリとそのデータ構造 |
ここではUDDIレジストリが保持するデータ構造について説明します。
| 2.2.1. UDDIレジストリとデータ構造 |
UDDIレジストリで提供される情報は、 概念的には次の三種類に分けることができます。
UDDIは従来のディレクトリと異なり、 Webサービスで自動接続を行うためのGreen Pageを提供している点に特徴があります。 このような情報とその検索を 提供するためにUDDIでは、次の5種類の基本的なデータ構造を管理しています。
データ構造間の関係は、次のように図 示することができます。
5種類のデータ構造それぞれについて説明します。
businessEntityは、サービスの集合に関する情報を公開している当事者に関する情報を保持するデータ構造です。 一般的には、サービスを提供する企業に関する情報で、その名称・連絡先を始め業種や地理情報(存在する場所)などのコードを付与することができます。
businessServiceは、サービス提供者の業務の種類に関する情報を 保持するデータ構造で一つの論理的なサービスに相当します。 一般的には、企業の提供するサービス一つに対応します。businessServiceには、そのサービスを提供するサービス提供者を表すbusinessEntityが一つ必要です。 逆に、businessEntityは提供するサービスの種類に応じて複数のbusinessServiceを持つことができます。
bindingTemplateは、サービスを利用するためのアクセス先(URLなど)に関する情報を保持するデータ構造です。 一般的には、あるサービスを実現するためのアクセス先の一つに対応します。 アクセスするための方法などの仕様に関する情報はtModelに記述されます。 bindingTemplateには、そのサービスを提供するサービス提供者を表すbusinessServiceが一つ必要です。 逆に、businessServiceはそのサービスの提供するアクセス先の種類に応じて複数のbindingTemplateを持つことができます。
tModelは、具体的なサービスの仕様に関する情報を保持するデータ構造です。 一般的には、標準団体が定める標準仕様を一つのtModelに対応させることで、tModelを指定することが特定のサービスを利用するための仕様に準拠していることを表現できます。 tModelにWSDLが関連付けられている場合は、それを取得することによってサービスの仕様を取得することできます。 しかし、UDDI仕様自身はtModelによって必ずしも WSDLの情報を提供することを想定しているわけではなく、その他の形式の情報を与えることもできます。 サービスの仕様は、異なる企業やサービスの間で共有できるようにbindingTemplateとは分離されており、複数のbindingTemplateから共有することもできます。
UDDI Version 2より導入された新しいデータ構造で二つの businessEntityの間の関係を表明するために使用されます。 二つの企業 が「親会社・子会社の関係にある」「提携している」といった関係を表 現することができます。
これら五つのデータ構造がUDDIレジストリの中の最も基本的なデータ構造です。 Webサービスでの典型的な使用法では、標準の一つであるWSDLをtModelに関連付けUDDIを通してWSDLを取得することで、 未知の相手に対してSOAP呼び出しを行うことを可能にします。
UDDIレジストリは、これらの情報の検索や登録を行うための仕様を"UDDI Version 3.0仕様"で定めていますが、 この検索にもSOAP呼び出しが使われておりUDDI自身も一つのWebサービスになっています。
| 2.3. UDDIの利用 |
UDDIから検索を行うにはUDDI仕様書に定義されたSOAP呼び出しを行います。 WebOTX UDDIクライアントライブラリはこのUDDI向けSOAP呼び出しを行うための専用のJava言語ライブラリで、 これを用いることでJavaプログラムからUDDIレジストリの検索などを簡単に行うことができます。
WebOTX UDDI Registry、WebOTX UDDIクライアントライブラリともにUDDI標準仕様に対応しているため、 WebOTX UDDIクライアントライブラリ以外のAPIライブラリからWebOTX UDDI Registryを検索することができます。 逆にWebOTX UDDIクライアントライブラリでWebOTX UDDI Registry以外のUDDIレジストリを検索することもできます。
UDDI Version 3.0のAPIは、登録されている情報の検索を行う照会(Inquiry)APIと、 レジストリへのデータの登録・更新・削除などを行う発行(Publication)API、 そしてユーザ認証を行う認証(Security Policy)APIの三つが主要なAPIです。 通常、照会APIによる検索は誰もが行えるため認証などの必要はありませんが、 発行APIの使用は、事前に登録されているユーザが自分のデータのみを操作できるように認証APIを用いた認証により制限されています。
| 2.3.1. UDDIレジストリからの検索…照会API |
照会APIは、検索を行うための"find_"で始まるAPIと、 検索結果からその具体的な内容を取得するための"get_"で始まるAPIの二つに分かれます。
businessEntityの検索と、その詳細情報の取得に使用します。
businessServiceの検索と、その詳細情報の取得に使用します。
bindingTemplateの検索と、その詳細情報の取得に使用します。
tModelの検索と、その詳細情報の取得に使用します。
データの作成日時、更新日時、登録時のUDDIレジストリのIDなどの取得に使用します。
| 2.3.2. UDDIレジストリへのデータの登録・更新・削除…発行API |
発行APIは、businessEntity、businessService、bindingTemplate、tModelに対しては登録・更新を行う"save_"で始まるAPIと、 削除を行う "delete_"で始まるAPIがあります。
businessEntityの登録・更新・削除に使用します。
businessServiceの登録・更新・削除に使用します。
bindingTemplateの登録・更新・削除に使用します。
tModelの登録・更新・削除に使用します。
publisherAssertionの追加登録・削除・状態監視・一覧取得・更新などに使用します。
自分で登録したデータの一覧を得るのに使用します。
| 2.3.3. 認証用トークンの取得・廃棄…認証API |
発行APIは、UDDIレジストリのデータを登録・更新・削除します。 通常、これを行えるのは事前に登録されているユーザ(UDDIレジストリ上でサービスを提供するサービス提供者)のみが使用することができます。 そのため、発行APIを使用するには、まず認証を行いUDDIレジストリ上のデータへのアクセス権限を得なければなりません。 これに関連するAPIは次のものがあります。
認証を行いUDDIにアクセスするためのトークンの取得と、操作終了時にトークンを廃棄します。
| 2.3.4. その他のAPI |
その他のAPIとして、以下の3種のAPIがあります。
管理権および所有権の委譲を行うためのAPIです。２つのAPI get_transferToken、 transfer_entitiesにより、権限の委譲を行います(他にtransfer_custodyというAPIもありますが、 これはUDDIレジストリのサーバ側で使用されます)。
UDDIレジストリに加えられた変更をサーバ側からクライアント側に通知するための機構を提供するAPIです。 通知のための登録情報を三つのAPI save_subscription、delete_subscription、get_subscriptionsにより登録・削除・一覧取得します。 クライアント側が実装する notify_subscriptionListener APIをサーバから呼び出すことで非同期的に更新情報の通知を行ったり、 あるいはクライアント側がget_subscriptionResults APIを用いてサーバ側より同期的に通知情報を取得することもできます。
UDDIレジストリに登録された情報の正当性を「UDDIレジストリが」評価するためのAPIです。 validate_values APIによりWebサービスを用いて値の検証を行ったり、 get_allValidValues APIにより正しい値の集合をWebサービス経由で取り寄せることができます。
値検査(Value Set) APIはWebOTX UDDI Registryでは実装されていません。
| 2.4. WebOTX UDDI Registry |
WebOTX UDDI RegistryはUDDI Version 3.0仕様に対応したUDDIレジストリ を構築するためのソフトウェアです。 WebOTX UDDI RegistryはWebブラウザからUDDIレジストリのユーザ管理などの運用管理を行うためのGUIを提供しています。
WebOTX UDDI Registryは、 JavaプログラムからUDDIレジストリを利用することができる「WebOTX UDDI クライアントライブラリ」を提供しています。 「WebOTX UDDI クライアントライブラリ」を用いることで、Javaプログラムから容易にUDDIレジストリにアクセスすることができます。
WebOTX UDDI Registry、WebOTX UDDI クライアントライブラリは、 ともにUDDI Version 3.0仕様に対応しているので、 他のUDDI Version 3.0対応クライアントからWebOTX UDDI Registryにアクセスしたり、 また、WebOTX UDDI クライアントライブラリから他のUDDI Version 3.0対応のUDDIレジストリにアクセスすることができます。
また、WebOTX UDDI Registry、WebOTX UDDI クライアントライブラリは、 UDDI仕様Version3.0の電子署名機能に対応しています。 WebOTX UDDI Registryは電子署名付きのUDDIのデータの保存/更新/検索/取得を行うことができます(署名の検証は行いません)。 また、WebOTX UDDI クライアントライブラリは、データ送信時の署名を付加、署名付データの検証を行うことができます。
さらに、WebOTX UDDI クライアントライブラリは、NEC独自のマルチーバージョン機能を備えており、 単一のプログラムで、V2とV3、いずれのバージョンのレジストリにも接続可能なプログラムを作成可能にしています。
| 2.4.1. WebOTX UDDI Registryの実装状況 |
ここではWebOTX UDDI Registryの実装状況について説明しています。
| 2.4.1.1. WebOTX UDDI Registryの機能制限事項 |
WebOTX UDDI Registryは、UDDI Version 3.0仕様のうち以下を実装していません。
| 2.4.1.2. WebOTX UDDI Registryの互換性について |
WebOTX UDDI Registryは、UDDI Version 3.0仕様のマルチバージョン機能を実装しており、 照会APIと発行APIはUDDI Version 2互換で動作することができます。