UDDIって何だ？：SOAPの仕掛け（3）（3/4 ページ）

[米持幸寿，日本アイ・ビー・エム株式会社]

UDDIの仕様の中心「UDDIビジネスレジストリ」

　UDDIが定めている仕様の中心になるのは、UDDIビジネスレジストリである。それらは、SOAPメッセージ（SOAPに入れるという意味で）のXMLスキーマ定義とUDDIプログラマーAPI仕様からなる。その中ではWebサービスを検索して利用するときに必要となる情報を以下の4つのカテゴリに分けて考え、それぞれがXMLの要素として定義されている。これらの情報が構造化されてレジストリに登録され、検索に使われることになる。

	ビジネス情報（business information）	<businessEntity>
	業務情報（service information）	<businessService>
	バインド情報（binding information）	<bindingTemplate>
	サービス記述（specification about services）	<tModel>

図2　UDDIは4つの情報を登録するレジストリ

■ビジネスレジストリの構造

■<businessEntity>

　ビジネス情報は、<businessEntity>という要素で記述される。このXML要素は、企業体などを表すためのものだ。企業名、連絡先、企業を特定（確認）するための何らかのID番号などを記述する。

　企業を探す場合、この要素を使って検索することになる。<businessEntity>要素での検索のことを「ホワイトページ」と呼んでいる。

　どのような業務を提供しているかという情報は、ビジネス情報内部に持つことになる。つまり、ある企業が提供するサービスにはどのようなものがあるかを記述することになる。

■<businessService>

　業務情報は、<businessService>という要素で記述される。このXML要素は、企業がどのような業務を提供しているかを示すものだ。Ver1では、業務の登録に、3つの分類標準をサポートしている。

• 業種： NAICS （Industry codes - US Govt.）
• 製品/サービス： UN/SPSC （ECMA）
• 場所： Geographical taxonomy

　これらは、それぞれが幾つかのWebサービスのセットとして提供されることになる。提供されている業務でサービスを探す場合、この要素を使って検索することになる。<businessService>要素単位での検索を「イエローページ」と呼んでいる。

■<bindingTemplate>

　どのWebサービスを使うかは、<bindingTemplate>という要素によって記述される。

　あるWebサービスを持っている取引相手に、自分が発注しなければならないとしよう。このとき、相手のURLだけが分かっても発注はできない。どのような形式の注文データを送ればよいのか、レスポンスはどのようなものなのか、プロトコルは？ セキュリティは？ こういった情報が必要である。

　具体的にどのようなやり方をするかは、さらに1つ下の層で記述することになっている。なぜなら、「同じモデル」でサービスを提供する企業はたくさんあるはずだから、ここに記述するのでは冗長な記述が発生するなどの不具合があるためだ。

　バインド情報は、Webサービスを提供しているURLと<tModel>要素への参照によって、これらを表現する。だから、「どのようなWebサービスか」ではなく、「どのWebサービスを使うか」なのである。

　ある特定のWebサービスを探す場合、この要素を使って検索することになる。<bindingTemplate>要素単位での検索を「グリーンページ」と呼んでいる。

■<tModel>

　<tModel>は、具体的なWebサービスの仕様を記述するための要素であるが、Webサービスの仕様を記述するためのメタデータとなっており、これ自体がWebサービスの記述であるわけではない。Webサービスの仕様は、UDDIの中では定義されないことになっている。UDDIに登録されるWebサービスの仕様は、「どこのだれが作った何という仕様で、詳細はこちらに記述してあるよ」ということが記述されるのである。

　<tModel>には、名前、仕様を策定した団体、仕様へのURLなどが記述される。

■UDDIビジネスレジストリの使われ方

　UDDIビジネスレジストリは幾通りもの使い方が考えられるであろうが、UDDIらしい使い方のストーリーをご紹介しよう。

■tModelの登録

　tModelは、Webサービスの仕様を登録するためのものである。仕様を策定した団体や企業などが登録することになる。例えば、RosettaNetの、あるPIPで策定された方式は1つのtModelとして登録される。また、またソフトウェアベンダが作ったソフトウェアが独自のWebサービスの方式を持っていれば、それを登録することも考えられるだろう。ホテルチェーンが独自のプログラムを提供していれば、それを登録することもできる。

■ビジネス、業務、Webサービスの登録

　ある企業が、自社の業務をWebサービスとしてインターネットに公開することが決まった。サービスは自社開発するかもしれないし、Webサービスを提供するソフトウェアを購入して構築するかもしれない。

　公開されるWebサービスは、UDDI登録されるなら、いずれかの方式に対応しており、UDDIにはtModelが登録されている必要がある。独自の方式なら、そのtModelを自ら登録する必要がある。企業はUDDIに自社を<businessEntity>として登録するとともに、自社が提供しているサービスを<businessService>や<bindingTemplate>で登録する。このとき、サービスを提供するURLと、どのtModelに対応しているかが登録される。

　1つの企業は複数の業務を登録することができるし、1つの業務は複数のWebサービスで提供して登録することもできる。例えば、あるホテルが空き室情報検索と予約のサービスを始めたとする。空き室情報のサービスはあるソフトウェアで提供されるし、予約はホテル協会が決めたやり方にのっとっているものと、そのホテルのホテルチェーンのやり方、すなわち独自の方法の2種類で提供する、ということが考えられる。また、同一のサービスを複数のURLで提供することにより、負荷分散や障害時のバックアップとして使うこともできる。

■検索、発見と利用

　ある企業がサービスを利用するときに、利用したいサービスを探すことになる。これは「人間が探す」という感覚ではない。ソフトウェアが探して、動的に接続するのである。

　探したいサービスは「企業」「業務」「プロトコル」「方式」といった観点で探すことができる。

　例えば、ある旅行会社が、利用者の希望に合わせたツアーを自動的に組むシステムを構築するとしよう。このシステムには、tModelに登録されている方式に対応しているソフトウェアを採用すれば、対象にするホテルをUDDIで探すことができる。空き室情報を検索する部分はパッケージソフトで提供されているし、予約方式に関してはホテル協会で決められた方式に合わせて自作した。

　ここで、UDDIらしいやり方になる。「このパッケージソフトの方式に対応しているサービスを提供しているホテルを探せ」「このホテル協会の方式に対応しているホテルを探せ」とUDDIで検索する。それぞれが複数のホテルを結果として返すだろう。旅行会社では両方に対応していないと取引が成立しないので、両方のリストに出てくるホテルを抽出し、空き室の確認、予約などを行うことになる。UDDIでは、こういった抽出が、UDDI-APIによって可能になっている。

　UDDIをこのように使うことによって、インターネットに公開されるWebサービスを、相互に運用する基盤が整うのである。

■UDDIプログラマーAPI

　UDDIレジストリは、4つのXML要素によってWebサービスを登録する。このレジストリにアクセスするためには、特定のXMLをレジストリに送信して、結果をXMLとして受け取るというインターフェイスが決められている。ここには、HTTPとSOAPが使われる。SOAPは単純に入れ物として使われている。中に入れられるのはXML文書である。

図3　UDDIレジストリはSOAPサーバ

　HTTPで、SOAPを使ってXML文書を交換し、レジストリにアクセスするように作られるのがUDDIレジストリということになる。そして、そのアクセス時にSOAPエンベロープの中に入れられるXML文書の仕様がUDDIプログラマーAPI（Programmer's API）である。

　UDDIプログラマーAPIは、大きく2つに分けられる。1つが参照API（Inquiry API）であり、もう一方が発行API（Publication API）である。それぞれは、さらに2つに分けられる。

■参照API

• find_XXX
  　find_XXXは、キーワードなどを用いた検索のためのAPIである。ある企業を探す、ある業務を探す、あるWebサービスを探す、といったときに使われる。ここでXXXには検索の対象となるbusinessEntity、businessService、bindingTemplate、tModelなど特定の要素が指定できる。検索の結果は対象となった要素のキーがリスト形式で返される。
• get_XXX
  　get_XXXは、find_XXXで検索された特定の要素（businessEntity、businessService、bindingTemplate、tModel）のキーから、その実体（内容）を取り出すときに使う。

■発行API

• save_XXX
  　名前から分かるように、レジストリを保管するためのAPIである。businessEntity、busienssService、bindingTemplate、tModelといったデータごとに命令が存在する。
• delete_XXX
  　こちらも名前から分かるとおり、レジストリのエントリを削除するためのものである。saveと同様に、4つの要素ごとに命令が存在する。

■認証

　発行APIに関しては、認証が必要である。あらかじめ登録された企業が（個人や団体でもよいが）、IDとキーを使ってレジストリを改変できることになっている。