UDDIが目指していることは、UDDIのホームページからダウンロードできるホワイトペーパー(白書)に記述されている。公開されているホワイトペーパーと仕様には、次のものがある。
Executive White Paper | 目的などの概要を記述したもの | |
Technical White Paper | 簡単な技術解説 | |
Programmer's API Specification | レジストリアクセスのAPI | |
UDDI Data Structure Reference | レジストリのデータ構造 | |
必要に応じてダウロードして読んでみよう(ただし、残念ながらすべて英語)。
ホワイトペーパーによれば、UDDIでは以下のようなことを解決しようとしている。
まず、インターネットの価値を振り返ってみよう。皆さんはインターネットをブラウザで見る際、見るサイトを運営している人と「契約」を結んで参照するだろうか? 旅行をする際に、インターネットでホテルを探すとき、いつもの常宿のホテルのページしか見られないということがあるだろうか? 答えは“ノー”のはずである。インターネットは、検索機能などを使って、「昨日まで名前も知らなかった」相手を見つけて接続することができる(実際、存在していなかったかもしれない)。自分がホームページを公開する際にも、「ページを公開すれば、その瞬間には、世界中からそれを見ることができる」のである。これによって、インターネットはビジネスチャンスのルツボであるといわれた。これがインターネットのすごいところであったはずだ。
しかし、インターネットにホームページを単純に公開しただけでは、「誰も見てくれない」ページになってしまう。なんとかして宣伝する必要がある。クチコミでもよいが、ポータルサイトに登録して見てもらうのが一番簡単な方法だ。そういった意味で、インターネットにおけるポータル機能は重要な位置付けにあるといってよいだろう。
HTML時代のインターネットの利用者はもっぱら人間だったが、XMLをベースにして、プログラム(ソフトウェア)によるインターネット利用が可能になってきた。その後、多くのコミュニティ(団体)ができ、XMLスキーマが定義され、交換手順が策定されてきた。
しかし、これらの仕様は、お互いによく知り合っている同士のシステム間が接続されることが前提になる。ある企業が購買システムを構築する際には、もともと取引のあった卸売業者とシステムを接続する、ということである。ここに「割り込む」ためには、従来と同じ、足を使った営業活動が必要であり、接続をする際にも、たくさんの時間を費やして擦り合わせをする必要がある。ここに、ポータルの論理が必要になる。
幾つかの団体においては、これらに着眼し、解決しようとしてきた。だが、いずれも「その団体の中で検索と統合が可能」というものが多い。もし、団体Aの仕様でカタログが参照でき、団体Bの仕様で取引を始められる企業を探す、ということをするには、それなりの実装が必要となってしまう。これでは、真に動的な接続は実現できない。
UDDIでは、こういった問題を解決すべく、グローバルで、団体や仕様にニュートラルなレジストリを目指している。それを実現することによって、インターネット上で行われるビジネス取引に、大きな進化を生み出そうとしているのだ。
UDDIを説明する前に、UDDIと並び称され、よく比較される規格を2つほど紹介しておこう(この2つが良いとか悪いとかそういうことではないので、誤解のないようにしてほしい)。
ebXMLでは、単純にXMLスキーマなどを決めるだけでなく、マーケットプレイスにおいて企業間がどうやって契約を結び、どうやってお互いのやりとりを決めていくかというプロセスを決めているところが特徴的だ。ごく最近だが、トランスポートにSOAPを取り入れることを発表したり、ebXMLレジストリをUDDIレジストリと融合することを検討するなど、注目すべき動きがある。
Copyright © ITmedia, Inc. All Rights Reserved.