Webサービスは、ネットワークを通じて呼び出し可能な分散アプリケーションを構築するフレームワークであると定義されています。これは主として技術面に注目した捉え方ですが、一方ではビジネスのあり方そのものを変える重要なパラダイムとしても認識されています。伝統的なEDIによるデータ交換やECサイトでおこなわれている現在のビジネスのあり方を越えて、新たな価値を作り出すための基盤になると考えられています。
今後は、さまざまなビジネスがWebサービスの形で利用者に提供されるようになり、その数も増えていきます。いずれWebサービスを整理・分類して、エンドユーザが容易に利用できるような仕組みが必要になってくるでしょう。
World Wide Webの黎明期、すなわちWebページを利用した情報共有が広まりつつあった頃、Yahooはインターネットに存在するさまざまなWebページへのリンクを収集し、独自のカテゴリ階層によって分類することで、ユーザが求める情報を容易に見つけられるようなディレクトリサービスを提供しました。いわば、Webページの「電話帳」（イエローページ）を作り上げたと言えます。
通常のWebページとは異なり、Webサービスを呼び出して利用するのは必ずしも人間とは限りません。あらかじめプログラムされたソフトウェアが自動的にアクセスするケースも考えられます。したがって、Webサービスを利用するためには誰がどんな内容のサービスを提供しているかといったイエローページ的な情報のほかに、どのような技術・プロトコルでサービスが提供されるのか、アクセスポイントとなるURLはどこか、サービスを受けるにはどのようなリクエストメッセージを送ればよいのか、といった技術的な情報も必要になります。
UDDI（Universal Description, Discovery and Integration）はWebサービスの情報を登録・検索するためのレジストリ仕様です。Webサービス時代の「電話帳」の役割を果たす、重要な基盤技術として注目されています。UDDI仕様では、Webサービスを記述するためのデータ構造や、レジストリにアクセスしてサービスを登録・検索するためのメッセージ形式（UDDI API）などが規定されています。
UDDIプロジェクトは、2000年9月に米IBM社、米Microsoft社、米Ariba社の3社により設立され、合わせて最初のUDDI v1仕様も公開されました。その後、2001年6月にはv2仕様が公開されました。仕様を検討しているメンバーも上記3社に加えて、富士通、米HP社、米Intel社、米Oracle社、独SAP社、米Sun Microsystems社など15社あまりが参加しています。
UDDIレジストリの利用モデルは、だいたい次のようになります。最初に、Webサービスを提供する組織（企業・団体など）が、そのサービスの名前・内容説明・アクセスポイント・サービスの分類情報・利用するプロトコルの情報などを、UDDI仕様で決められた形式（スキーマ）で記述し、レジストリに登録します。
一方で、Webサービスを利用したい者はUDDIレジストリにアクセスし、自らの要件に合うようなWebサービスを検索します。検索の条件としてはサービスの種類や提供企業の名前、提供されるサービスの技術情報などを用いて、要件に合うようなサービスを探すことができます。UDDIレジストリは、Webサービスを提供する者と利用する者が出会うポイントの一つになります（図1）。
伝統的な企業間取引通信では、あらかじめ人間が介在して（通信プロトコルやデータフォーマットなどについて）十分な意識合わせを行なってシステムを構築した後に、一対一の関係でデータ交換の通信をするのが一般的です。
UDDIレジストリに登録される情報の中には、そのサービスを利用するにはどのような方法でアクセスすればよいかといった技術的な情報も含まれます。検索によりUDDIレジストリからWebサービスを「発見」できれば、たとえそのサービスの提供者と事前にネゴをしていなくても、レジストリの情報をもとに適切にサービスを利用することができるのです。
WebサービスをUDDIレジストリに登録して広く公開することは、潜在的なビジネスパートナーに「発見」されるチャンスを増やすことにつながります。これまでつき合いがなかった分野の相手ともビジネスがスタートする可能性も孕んでおり、新たなビジネスチャネルの構築につながります。
UDDIレジストリの具体的な役割や使われ方については、運用形態の観点から、「UDDIビジネスレジストリ」と「プライベートUDDIレジストリ」の2つに分けて整理してみます。
UDDIビジネスレジストリ（UDDI Business Registry、UBR）は、UDDIを推進する企業グループ数社によって運営されるUDDIレジストリです。UDDI v1仕様を実装したv1サイトは米IBM社、米Microsoft社によって2001年5月にスタートしました。2001年12月には、v2仕様を実装したβサイトがIBM社、Microsoft社、米Hewlett-Packard社、独SAP社によって公開されました。誰でもWebサービスの登録・検索ができるように運用されています。
UDDIビジネスレジストリ（図2）は複数のサイトで構成されます。それぞれのサイトはレジストリノードあるいは単にノード（Node）と呼ばれ、実際にクライアントからのUDDIリクエストを受け取って、データの検索や更新作業をおこないます。
UDDIビジネスレジストリに登録されるすべてのデータは、レプリケーション機能により全ノードにコピーされます。UDDIクライアントがどのノードに対して検索リクエストを送っても、得られる結果はすべて同一になります。そのため、UDDIビジネスレジストリは論理的には全世界でただ一つのレジストリと言えます。次節で述べるプライベートレジストリとの対比で「パブリックレジストリ」と呼ばれることもあります。
UDDIビジネスレジストリとは異なり、プライベートUDDIレジストリは、限定されたメンバーだけを対象に運用されるUDDIレジストリです。サービスを一般には公開せず、限定されたメンバー間で共有したい場合に適した運用形態です。使われ方や利用シーンはいろいろ考えられますが、典型的なケースを以下に挙げます。
いずれの場合も限定された環境で運用されるため、標準のAPIで誰でもアクセスできるUDDIビジネスレジストリの機能に加えて、さまざまな付加価値機能を提供することも可能です。以下に例を挙げます。
UDDI v2仕様は次の4つの部分から成っています。データ構造とAPIについては次章以降でもう少し詳しく解説します。
WebサービスをUDDIレジストリに登録するには、UDDIデータ構造仕様にしたがってサービスを記述します。UDDIデータ構造は図3に示されるようにbusinessEntity（企業情報）をルートとする木構造になっています。
サービスを提供する主体（例えば企業、団体、個人など）がbusinessEntityに相当します。それぞれのbusinessEntityによって提供されるサービスはbusinessServiceとして登録されます。bindingTemplateはサービスが提供される実装ポイントを示すもので、アクセス先URLのほか、プロトコルやトランスポートなど個々のサービスを利用するために必要な技術情報が列挙されます。TModelについては後述します。
UDDIレジストリに登録されたbusinessEntity、businessService、bindingTemplate、tModelには、それぞれ一意な識別子（UUID）が付けられます。
サービスに付随して列挙される技術情報のセットはWebサービスの技術的な特徴（technical fingerprint）を示しており、Webサービスの「型」と呼ばれます。提供されるサービスの型と、利用者のシステムが対応できるサービスの型が一致すれば、当然ながら両者は技術的には何の問題もなく通信できることになります。
それでは、サービスの型とは具体的にはどのようなものでしょうか。例として、Tempuri社という企業が業界標準のフレームワークABCXMLに準拠するWebサービスを提供していて、UDDIレジストリに情報を登録するというシナリオを想定してみましょう。Tempuri社のサービスの「型」情報としてはどのようなものがあるでしょうか？ − 例えば、ABCXMLフレームワークに準拠している、メッセージ形式はabcxml.xsdというスキーマにしたがっている、プロトコルはHTTPを利用してブラウザベースのサービスである等々、いろいろ考えられます。
これらの技術的特徴を検索条件として利用するには、ある程度形式的に記述されている必要があります。しかし、サービスの型を一般的に記述するのは簡単ではなく、標準的な方法は存在しません。
UDDIではこの問題に対処するために「tModel」という概念を作り出しました。端的には、tModelは何かを指し示す参照であると言えます。その「何か」とは、例えばプロトコル仕様であったり、B2Bフレームワークであったりとさまざまです。図3でbindingTemplateからtModelに向かって伸びている矢印に注目してください。bindingTemplateで記述されるサービスの実装ポイントが、関係する技術情報のtModelを参照しています。UDDIではbindingTemplateとtModelを関連付けることで、サービスの「型」を形式的に記述することができます。
具体例で見てみましょう。先ほどのTempuri社の例をもとにbusinessService情報を記述してみました。
| < businessService serviceKey="86e46aad-..." businessKey="0076b468-.."> |
| <name>Tempuri Online Shop Web Service</name> |
| <description xml:lang="en">Online shop</description> |
| <bindingTemplates> |
| < bindingTemplate serviceKey="86e46aad-..." bindingKey="98a459b.. "> |
| <description xml:lang="en">Tempuri Online shop Web Service</description> |
| <accessPoint URLType="http">http://buy.tempuri.com/</accessPoint> |
| <tModelInstanceDetails> |
| <tModelInstanceInfo tModelKey="uuid:68de9e80-ad09..."> ← tModelへの参照 |
| <description xml:lang="en">HTTP based Web service</description> |
| </tModelInstanceInfo> |
| <tModelInstanceInfo> …… </tModelInstanceInfo> |
| </tModelInstanceDetails> |
| < /bindingTemplate > |
| </bindingTemplates> |
| < /businessService > |
サービスの実装ポイントを表わすbindingTemplateの中にtModelInstanceInfoという要素があります。これが関連する技術情報tModelへの参照です。サービスの型を記述しています。上の例では "HTTP based Web service" tModelを参照しています。
それでは次に、このtModelはどのような構造になっているのか見ていきましょう。"HTTP based Web service" という技術仕様を表現するtModelです。
| < tModel tModelKey="uuid:68de9e80-ad09..." xmlns="urn:uddi-org:api"> |
| <name>uddi-org:http</name> |
| <description xml:lang="en">HTTP based Web service</description> |
| <overviewDoc> |
| <description xml:lang="en">This tModel is used to ...</description> |
| <overviewURL>http://www.uddi.org/specification.html</overviewURL> |
| </overviewDoc> ↑”HTTP based Web service”を規定している仕様書。この例ではHTML文書 |
| <categoryBag> |
| <keyedReference tModelKey="uuid:c1acf26d-..." ← このtModelの分類情報を記述 |
| keyName="tModelType" |
| keyValue="transport" /> |
| </categoryBag> |
| < /tModel > |
名前や概要、分類情報に加えて、このtModelが表わしている “HTTP based Web service” の仕様書の存在場所がoverviewURLという要素で示されています。
UDDIレジストリに登録するデータの中でサービスの型を指定するためにtModelを参照するには、事前にそのtModelをレジストリに登録しなければなりません。http、homepage、smtp、ftp、faxなどの基本的な技術については、仕様書中で定義されています。標準化団体等によって策定される技術仕様については、それぞれの団体がUDDIビジネスレジストリに登録することが期待されています。例えば、RosettaNetという団体は電子部品業界を中心としたグローバルなサプライチェーンを構築するためのB2Bフレームワーク仕様を開発していますが、その中で、発注処理や在庫照会など既存のさまざまな業務プロセスをPIP（Partner Interface Processes）として定義し、モデル化しています。それらのPIPは、tModelとしてUDDIビジネスレジストリにも登録されました。
tModelはUDDIに特有の概念であり、Webサービスの型を記述するために重要な役割を果たしています。tModelにはもう一つ重要な使われ方がありますが、それについては次節で解説します。
UDDIレジストリでは、名前（企業名、団体名など）でサービスの提供者を検索できるだけでなく、提供されるサービスの業種や製品の分類情報を利用して検索することができるようになっています。さらには、相手を一意に特定するための企業識別コードを利用して検索することもできます。これは、レジストリに登録されるサービスの記述中に、サービス・製品の分類（Classification）や提供者の識別（Identification）の情報が付加されているからです。
分類情報とは、例えば「Software Publisher」や「Electronic Computer Manufacturing」のように提供者が属する業種の分類であったり、「Hard drives」や「Transaction server software」のような製品の分類のことです。UDDI仕様では、前者の業種分類体系としてはNAICS（North American Industry Classification System）が、また後者の製品・サービス分類としてはUNSPSC（Universal Standard Products and Services Classification）が標準のタクソノミ（Taxonomy. 分類の体系）としてtModelが用意されています。また、地理的な情報を記述する体系としてはISO 3166が採用されています。
識別情報には、企業や団体などを一意に識別するコード体系が用いられます。UDDI仕様では、D-U-N-SナンバーとThomas Register Supplier Identifierが標準で用意されています。前者は米国を中心に企業間取引などで広く用いられ、RosettaNetなどXMLを利用した最近のB2Bフレームワークでも採用されています。
上のようなコード体系を利用して分類情報や識別情報を記述するには少なくとも、（1）識別・分類コード体系を特定する情報、（2）実際のコード番号の二つが必要になります。他にあれば便利な情報としては、（3）人間が理解可能な説明文があればよいでしょう。（2）や（3）の記述については一般に数字列や文字列が使われます。（1）を記述するには表記の揺れなどの曖昧さを排除しなければならないため、体系名などの単なる文字列ではなく、より形式的な方法が必要になります。このためにtModelが使われます。
UDDIのデータ構造には、分類・識別情報を付加するためにcategoryBagとidentifierBagという二種類の構造が用意されています。前者が分類情報の格納に、後者が識別情報の格納に使われます。サービスの提供者に直接関連する分類・識別情報については、businessEntityの子要素であるcategoryBag・identifierBagにそれぞれ書くことになります。また、businessServiceはcategoryBagを直下に持つことができるため、それぞれのサービスに関する分類情報をそこに記述することになります。
| < businessEntity > |
| < businessService > |
| <categoryBag>このサービスの分類情報</categoryBag> |
| < /businessService > |
| <identifierBag>サービス提供者の識別情報</identifierBag> |
| <categoryBag>サービス提供者の分類情報</categoryBag> |
| < /businessEntity > |
分類・識別情報を記述する（1）、（2）、（3）の情報はすべて、これらのcategoryBag・identifierBagの中のkeyedReference要素に記述します。次の例はNAICSの 334111（"Electronic Computer Manufacturing"）という業種の分類情報を記述しています。
| <categoryBag> |
| < keyedReference tModelKey="uuid:c0b9fe13-...." keyValue="334111" |
| keyName="NAICS:Electronic Computer Manufacturing" /> |
| </categoryBag> |
tModelKeyにはNAICS分類コード体系を表わすtModelのUUIDが書かれています。これは（1）の情報に相当します。keyValue属性の値がNAICSのコードで、（2）の情報に相当します。keyName属性の値は人間が読んで理解するための情報であり、（3）に相当します。この属性はあくまで補助的な情報であるため、レジストリでの検索には使われません 。
標準となっているコード体系については、それを管理する団体がUDDIビジネスレジストリに登録することが期待されています。固有のコード体系を利用している場合でも、UDDIレジストリにtModelとして登録してしまえばサービスの分類情報などに利用できます。
UDDI APIは、サービスの提供者がUDDIレジストリにサービス情報を登録するときや、利用者がレジストリで情報を検索・取得するときに発行するメッセージです。XMLで記述され、通信層のプロトコルにはSOAPが使われます。
UDDI APIは、発行（Publishing）APIと照会（inquiry）APIの二つに大きく分けられます。ここではそれぞれのAPIについて概要を挙げるにとどめます。それぞれの詳細な挙動についてはAPI仕様書（UDDI v2 Programmer's API Specification）を参照してください。
UDDIレジストリは、APIの使い方により3つのビューで検索することができます。（図4）。
これらの３つの見方がどのようにして実現されるのかを、UDDI APIメッセージの使用例と対比させて示します。
サービス提供者の名前を利用して検索します。
| < find_business xmlns="urn:uddi-org:api" maxRows="100"> |
| < name>Tempuri</name > |
| < /find_business > |
サービス提供者の業種分類で検索します。下の例ではNAICS分類体系（"uuid:c0b9fe13-..."で参照されるtModelはNAICSを指しています）の51121の業種に該当する提供者を検索しています。
| < find_business xmlns="urn:uddi-org:api" maxRows="100"> |
| <categoryBag> |
| < keyedReference tModelKey="uuid:c0b9fe13-..." keyName="" keyValue="51121"/ > |
| </categoryBag> |
| </ find_business > |
サービスの型を特定して提供者を検索します。下の例では検索条件としてtModel "uuid:d7bffc50-5aa7-..." を指定しています。これはRosettaNet PIP3A4を表すtModelです。PIP3A4を実装しているサービスの提供者が検索結果として返されることになります。
| <f ind_business xmlns="urn:uddi-org:api" maxRows="100"> |
| <tModelBag> |
| < tModelkey>uuid:d7bffc50-5aa7-...</tModelKey > |
| </tModelBag> |
| </ find_business > |
実際にUDDI APIのメッセージを使用して、レジストリを検索する例を挙げます。どのようなUDDIメッセージが、クライアントとレジストリの間で交換されるのか具体的に見ていきましょう。前章で紹介したイエローページの検索メッセージを例にします。
サービス利用者が、ソフトウェア開発企業が提供するWebサービスを検索すると仮定しましょう。この場合の検索条件としては業種分類を用いるのが適当です。NAICS分類コードのソフトウェア開発業に相当する”51121”（Software Publisher）をcategoryBagに指定して、find_businessメッセージをUDDIビジネスレジストリに送信します。
| < find_business xmlns="urn:uddi-org:api" maxRows="100"> |
| <categoryBag> |
| <keyedReference tModelKey="uuid:c0b9fe13-..." keyName="" keyValue="51121"/> |
| </categoryBag> ↑検索時にはkeyNameは使われません |
| </ find_business > |
レジストリは、指定された条件に合うサービス提供者をデータベースから検索します。条件に合致するサービス提供者のサマリ情報がbusinessInfo構造にまとめられ、検索結果の全体は次に示すようなbusinessList情報として返されます。
| <businessList operator="Microsoft Corporation" xmlns="urn:uddi-org"> |
| <businessInfos> |
| .... |
| <businessInfo businessKey="0076b468-eb27-..."> |
| <name>Tempuri Corporation</name> |
| <description xml:lang="en">...description for Tempuri</description> |
| <serviceInfos> |
| <serviceInfo serviceKey="86e46aad-..." businessKey="0076b468-.."> |
| <name>Tempuri Online Shop Web Service</name> |
| </serviceInfo> |
| ... |
| <serviceInfo>...</serviceInfo> |
| ... |
| </serviceInfos> |
| </businessInfo> |
| ... |
| </businessInfos> |
| </businessList> |
検索されたTempuri Corporationの詳細な情報を得るために、businessKeyを指定してget_businessDetailメッセージをレジストリに送信します。
| < get_businessDetail xmlns="urn:uddi-org:api"> |
| <businessKey>0076b468-eb27-...</businessKey> |
| </ get_businessDetail > |
レジストリは、UUIDが "0076468-eb27-..." で識別されるbusinessEntityをデータベースより取り出し、businessDetail情報として返します。
| <businessDetail operator="Microsoft Corporation" xmlns="urn:uddi-org"> |
| < businessEntity businessKey="0076b468-eb27-..." authorizedName="John"> |
| <discoveryURLs> |
| <discoveryURL useType="businessEntity"> |
| http://uddi.microsoft.com/discovery?businessKey=0076b468-.... |
| </discoveryURL> |
| </discoveryURLs> |
| <name>Tempuri Corporation</name> |
| <description xml:lang="en">...description for Tempuri</description> |
| <contacts> |
| <contact useType="Corporate Addresses"> |
| <description xml:lang="en">Corporate Addresses</description> |
| <phone useType="Headquarters">+1-123-456-7890</phone> |
| <address useType="Headquarters"> |
| <addressLine>123 Tempuri street</addressLine> |
| <addressLine>Tempuri, CA 12345</addressLine> |
| <addressLine>USA</addressLine> |
| </address> |
| </contact> |
| </contacts> |
| <businessService> |
| < businessServices serviceKey="86e46aad-..." businessKey="0076b468-.."> |
| <name>Tempuri Online Shop Web Service</name> |
| <description xml:lang="en">Online shop</description> |
| <bindingTemplate> |
| < bindingTemplates serviceKey="86e46aad-..." bindingKey="98a459b..> |
| <description xml:lang="en">Tempuri Online Web shop</description> |
| <accessPoint URLType="http">http://buy.tempuri.com/</accessPoint> |
| <tModelInstanceDetails> |
| <tModelInstanceInfo tModelKey="uuid:68de9e80-ad09..."> |
| <description xml:lang="en">HTTP based Web service</description> |
| </tModelInstanceInfo> |
| </tModelInstanceDetails> |
| </ bindingTemplates > |
| </bindingTemplates> |
| </ businessService > |
| ... |
| <businessService>...</businessService> |
| ... |
| </businessSservices> |
| <identifierBag> |
| <keyedReference tModelKey="uuid:8609c81e-ee1f-..." keyName="D-U-N-S" |
| keyValue="12-345-6789" /> |
| </identifierBag> |
| <categoryBag> |
| < keyedReference tModelKey="uuid:c0b9fe13-179f-..." |
| keyName="NAICS:Software Publisher" keyValue="51121" /> |
| </categoryBag> ↑確かに最初に指定した分類情報を持っている |
| </ businessEntity > |
| </businessDetail> |
得られたBusinessEntity直下のcategoryBagを見ると、最初にfind_businessで指定した分類情報にマッチする情報、つまりNAICS産業分類コードの “51121” が確認できます。
個々のUDDI APIはどれも単純でプリミティブな機能しか持っていませんが、このようにAPIを組み合わせることでレジストリを自由に検索できます。
UDDIレジストリは、Webサービスの基本的な情報を登録・検索できるレジストリです。UDDIデータ構造やレジストリの機能自体はシンプルですが、tModelという抽象的な概念を活用することで、さまざまな情報を付加して格納情報を拡張していくことができます。
しかしながら、その柔軟さゆえに、何かの情報をUDDIレジストリに格納するためモデル化を試みると、複数の方法で実現できてしまう場合もあります。もちろん、ローカルな範囲でのみ利用する情報ならば、その範囲内で方法を決めて運用するのでも構いません。しかし、デファクト技術として既に使われているような技術、例えばWebサービスのインターフェースの記述方法や、Webサービスのフローの記述方法、ebXMLやRosettaNetフレームワークの利用などをモデリングするケースについては、相互運用性を確保するためにも、モデリングの標準ガイドラインが望まれます。