Webサービスを発見する仕組み〜UDDI：Webサービスのキホン（7）

Webサービスを登録し発見する

　ネットワーク上に数多く存在するWebサービスを効果的に利用するためには、Webサービスを登録・公開し、検索する仕組みが必要になる。この、標準的手法を提供する仕様が、今回のテーマであるUDDI（Universal Description, Discovery and Integration）だ。

　UDDIは、Yahoo!やGoogleなどの検索サイトと似ている。検索サイトは入力されたキーワードから目的のWebサイトを検索するようになっている。一方、UDDIには企業名、サービス内容、識別コード、分類などがあらかじめ登録されており、これらのデータによって精度の高い検索を行える。また、前述の検索サイトがHTMLによる結果を返してくるのに対し、UDDIはコンピュータが処理しやすいXMLをベースに入出力を実現しているため、コンピュータによる問い合わせ、結果分析を自動化することが容易だ。

データベースとなるUDDIレジストリ

　UDDIには、Webサービス提供者の企業名や連絡先、その企業が提供しているサービスの内容などさまざまな情報を登録しておく必要がある。その情報を登録する場所を「UDDIレジストリ」という。

図1　UDDIレジストリ

　図1のように、Webサービス提供者は事前にWebサービスについての情報をUDDIレジストリに登録しておく。Webサービス利用者はUDDIレジストリを検索し、目的のWebサービスを発見する。そして、その参照先に接続し、サービスについて記述されたWSDL文書を取得し、サービスのやりとりが始まる。UDDIレジストリとやりとりするためのAPIも用意されており、それらは「UDDIプログラマAPI」と呼ばれる。

　通常の企業間取引では、まず条件に合う企業を探し、その企業との間で何度もやりとりを重ねた上でやっとサービスが始まる。しかしUDDIでは、WSDL文書の取得によって技術的な情報も取得でき、検索からサービスの開始まで自動的に処理されるというわけだ。

　UDDIは、バージョン1.0が2000年9月に公開され、標準化団体UDDI.orgによって検討が進められてきた。バージョン3.0が2002年7月にOASISに提出され、UDDI.orgもOASISの傘下に入って現在も開発が進められている。本稿は、現時点で最新のUDDIバージョン3.0に基づいて解説することにする。

UDDIレジストリがないとWebサービスを使えない？

　本連載第1回「Webサービスの主役、SOAP誕生の背景」で、Webサービスを「インターネットの標準技術を使ってネットワーク上に分散したアプリケーションを連携させる技術」と定義した。この意味でのWebサービスを使って、社内や取引実績のある企業など、接続相手があらかじめ特定されているアプリケーション同士を連携させることも少なくない。この場合、接続先に対してあらためてWebサービスを公開したり発見してもらったりする必要はなく、接続先に直接接続すればよい。つまり、社内や取引先など、すでに密接なつながりのある組織とWebサービスを使って接続するのであれば、UDDIレジストリを使わずに、SOAPとWSDLを静的に連携させればWebサービスを利用できる。

　一方、社内や業界団体内などでも、あらかじめ決められたメンバーだけが利用できるようにWebサービスを公開したい場合がある。こうした目的で、アクセス権のあるユーザーだけが登録・検索を行えるUDDIレジストリを「プライベートUDDI」という。プライベートUDDIは、登録されるWebサービスをその運営者が審査し、その質や信用度を保持できるというメリットがある。

　利用者が限定されているプライベートUDDIに対し、Webサービスの登録や検索が誰にでも許可されているUDDIレジストリを「パブリックUDDI」（あるいは「UDDIビジネスレジストリ（UBR）」）という。例えば、マイクロソフトが運営するMicrosoft UDDI Business Registry、IBMのUDDI Business Registry、SAPのSAP UDDI Business Registry、そして日本のNTTコミュニケーションズによるUDDIビジネスレジトリなどが公開されている。パブリックUDDIはだれでもアクセスできるため、セキュリティを確保し、登録されるWebサービスを評価する仕組みが必要になる。

　パブリックUDDIには評価やセキュリティの課題があるため、近年はプライベートUDDIの重要性が高まっている。UDDIバージョン3.0では、「ルートレジストリ」という概念が新たに取り入れられ、パブリックUDDIを「ルートレジストリ」ととらえて、プライベートUDDIと連携するシナリオが紹介されている。パブリックUDDIを「ルート」、プライベートUDDIを「アフィリエイト（affiliate）」とする階層構造を形成し、レジストリ間でデータを共有できるような仕組みを提供している。

UDDIのデータ構造

　ここからは、UDDIレジストリにはどのようなデータが登録されているのか、それをどのように操作するのか、について紹介していく。

　UDDIレジストリに登録されているデータは、大きく分けて5つの要素を持つ。

図2　UDDIレジストリのデータ構造

　UDDIレジストリには、基本的には情報は企業単位に登録され、その企業についての情報を記述するbusinessEntity要素が最上位要素になる。

　businessEntity要素は、Webサービスについての情報を記述するbusinessService要素を子要素に、Webサービスの技術的な情報を記述するbindingTemplate要素を孫要素に持つ。

　businessEntity要素とbusinessService要素は、お互いを一意に特定するためのbusinessKey属性により結び付けられており、businessService要素とbindingTemplate要素はお互いを一意に特定するためのserviceKey属性により結び付けられている。また、1つの企業が複数のサービスを提供していることもあるため、1つのbusinessEntity要素が複数のbusinessService要素を持つことも可能だ。

　これら親子関係にある3つの要素とは独立した構造として、tModel要素とpublisherAssertion要素が存在する。tModel要素は“technical Model”の略で、“技術情報”という意味だ。businessEntity以下の要素とは独立した構造になっており、bindingTemplate要素から参照されるようになっている。

　tModelには、サービスのタイプ、つまりプロトコルやメッセージ配信方法などが記述される。ユーザーとサービス提供者の「サービスのタイプ」が同じであればやりとりすることができるというわけだ。ただし、tModelでサービスのタイプが詳細に記述されるわけではなく、その仕様書のURLが記述されているにすぎない。UDDIでは、多種多様なサービス・タイプを記述する文書を参照するという方式を取っている。

　publisherAssertion要素は、fromKey要素やtoKey要素によって企業間の関係を表現する。この情報によりユーザーは目的の企業だけでなくその関連企業を見つけることができる。例えば旅行会社を検索するときには、JTBとJTB関連の信頼できる関連企業を見つけられる。UDDIは企業の信頼性を保証する仕組みは持たないが、信頼できる企業の関連企業の中から目的の企業を選ぶ、といったことができる。また関連企業間でサービスを共有することで、単独で登録するよりも高いヒットを獲得することができるという、サービス提供者側のメリットも表現できる。

　また、businessEntity要素、businessService要素、tModel要素の下位のkeyedReference要素には、製品分類や産業分類などの分類情報や識別情報が格納されており、分類や識別コードによる検索が可能だ。このように、UDDIはXML形式で構造化されて登録されており、企業名、サービス内容、分類情報、識別コードなど複数の検索項目を指定して精度の高い検索を行える。

UDDIに格納されるデータの実際

　簡単にそれぞれの要素のデータを紹介しよう（本稿のリストでは、簡略化のため名前空間を一部省略してある）。

<?xml version="1.0" encoding="utf-8" ?>
<businessEntity businessKey="企業のID">
  <discoverURLs>
    <discoveryURL useType="businessEntity">
      ……企業情報の取得先URL……
    </discoveryURL>
  </discoverURLs>
  <name>企業名</name>
  <description>企業についての説明</description>
  <contact>
    ……連絡先情報……
  </contact>
  <businessServices>
    ……
  </businessServices>
</businessEntity>

　businessEntity要素の子要素に、businessServices要素がある。

<businessServices>
  <businessService serviceKey="サービスのID" businessKey="企業のID">
    <name>サービスの名前</name>
    <description>サービスについての説明</description>
    <bindingTemplates>
      ……
    </bindingTemplates>
  </businessService>
  <businessService serviceKey="サービスのID" businessKey="企業のID">
    ……
  </businessService>
  ……
</businessServices>

　businessServices要素の子要素にbindingTemplate要素がある。

<bindingTemplates>
  <bindingTemplate serviceKey="サービスのID" bindingKey="技術情報のID">
    <description>技術情報の説明</description>
    <accsessPoint>サービスに接続するためのアドレス</accsessPoint>
    <tModelInstanceDetails>
      <tModelInstanceInfo tModelKey="tModelのID">
        ……
      </tModelInstanceInfo>
    </tModelInstanceDetails>
  </bindingTemplate>
</bindingTemplates>

　bindingTemplateデータの中のtModelInstanceDetails要素の部分に、下記のようなtModel要素への参照情報が組み込まれる。

<tModel tModelKey="tModelのID">
  <name>サービスの名前</name>
  <description>サービスについての説明</description>
  <overviewDoc>
    <description>Webサービスの仕様についての説明</description>
    <overviewURL>Webサービスの仕様のURL</overviewURL>
  </overviewDoc>
  ……
</tModel>

　publisherAssertion要素では、fromKey要素とtoKey要素を使って2社の関係を定義する。

<publisherAssertion>
  <fromKey>A社のビジネスキー</fromKey>
  <toKey>B社のビジネスキー</toKey>
  <keyedReference keyName="2社の関係を示すキー名" keyValue="2社の関係"
tModelKey="関連付けシステム"/>
</publisherAssertion>

UDDIレジストリを利用するためのAPI

　UDDIには、UDDIプログラマAPIと呼ばれるAPIが用意されており、SOAPメッセージの本体 （body）部分に組み込まれてやりとりされる。UDDIプログラマAPIは以下の6つからなる。

　それぞれのAPIセットには以下のAPIが含まれている。

　このように、「UDDIプログラマAPI」を使って、ユーザー認証、登録、検索、情報取得などを行うことができる。例えば、ユーザー認証を行う際にUDDIビジネスレジストリに送信するデータは次のようになる。

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope ……>
  <soapenv:Body>
    <get_authToken cred="test" generic="2.0" userID="uddi-test@utj.co.jp"
xmlns="urn:uddi-org:api_v2"/>
  </soapenv:Body>
</soapenv:Envelope>

　7回にわたって、Webサービスを支える3つの中核技術、SOAP、WSDL、UDDIについて解説してきた。Webサービスは、これら3つの技術を柱に、メッセージ技術やセキュリティ技術などさまざまな技術を包含する複合的な技術だ。まだ策定中の仕様も多いとはいえ、いまやWebサービスは現実のソリューションとして実装されつつある。仕様の標準化や実装動向に注目するとともに、仕様策定の背景や基本的な考えをしっかりと理解しておきたい。