UDDI を使用する Web サービスの記述と発見 (第 1 部)
Karsten Januszewski
Microsoft Corporation
October 3, 2001
日本語版最終更新日 2001 年 11 月 26 日
この記事のソース コードの表示とダウンロード。
※この記事のリンク先：http://msdn.microsoft.com/ja-jp/library/aa480517.aspx
はじめに
これまでの At Your Service コラムでは、ビジネスに影響する初期設計ドキュメントから最終的な配置に至るまで、Web サービスを構築する方法に関する現実的な事例を説明してきました。次の論理的な検討段階は、Web サービスに関心を示すクライアントが Web サービスを容易に発見でき、クライアントのアプリケーションで利用できるように、この Web サービスを公開する方法です。 現在、 この要求を実現する発見のメカニズムが UDDI (Universal Description Discovery and Integration) です。 UDDI は、テクノロジやプラットフォームにまたがって Web サービスの発見をサポートする業界全体のイニシアティブです。
At Your Service コラムの著者は、 私にゲスト コラムニストとして、UDDIの紹介と登録プロセスに関する記事を書くことを熱心に勧めてくれたので、 私は喜んでこの依頼を引き受けることにしました。 まず、技術的な観点とビジネスの観点の両方から UDDI の影響を見ていきます。 次に、UDDI と Web サービス記述言語 (WSDL) との関係を見ていきます。 最後に、UDDI の登録手順と UDDI の潜在能力を最大限に引き出すための必要なことを検討します。 次回のコラムでは、この記事の第 2 部として、 UDDI を十分に活用するために At Your Service チームが実行した手順を検証する予定です。
UDDI?Web サービスのグローバル レジストリ
UDDI は、ビジネスやサービスに関する情報を、 構造化して保管するように設計されたパブリック レジストリです。 UDDI を使用して、 ビジネスや Web サービスに関する情報を公開および発見できます。 このデータは、標準的な分類法を使用して分類されているので、 分類を基準に情報を検索できます。 最も重要なことは、 UDDI がビジネスのサービスの技術的なインターフェイスに関する情報を保持することです。 SOAP ベースの XML API 呼び出しのセットを使って、 デザイン時と実行時の両方で UDDI と対話して、 サービスを起動および使用できるような技術的なデータを発見できます。 この方法では、 UDDI は Web サービスに基づくソフトウェアの全体像のインフラストラクチャとして動作します。
なぜ UDDI なのでしょうか。 このようなレジストリの必要性とは何でしょうか。 数千、あるいはおそらく数百万の Web サービスのソフトウェアの全体像に目を向けると、 以下のような困難な問題が浮かび上がってきます。
- どのような方法で Web サービスを発見するのでしょうか。
- どのように、この情報を意味のある方法で分類するのでしょうか。
- ローカリゼーションにはどんな影響があるのでしょうか。
- 独自の周辺テクノロジにはどんな影響があるでしょうか。 どうしたら、発見メカニズムに相互運用性を保証できるのでしょうか。
- アプリケーションを Web サービスに依存するようにした場合、 どうしたら実行時にこのような発見メカニズムと対話できるのでしょうか。
このような問題に応えるために、UDDI イニシアティブが誕生しました。 Microsoft、IBM、Sun、Oracle、Compaq、Hewlett Packard、Intel、SAP などの多くの企業を始めとして、 300 を超えるその他の企業 (完全なリストについては UDDI: Community
をご覧ください) が、 これらの諸問題を解決するためのオープン標準に基づき、 専用のテクノロジを使用しない仕様の開発に共同で取り組んできました。 その結果が、 ユーザーが自由に検索と公開ができる、複数のオペレータ ノードでホストされたグローバル ビジネス レジストリでした。 これは、2000 年 12 月にベータとして運用が開始され、 2001 年 5 月に実稼働環境に移行されました。
このように Web サービスのインフラストラクチャが決まった場所に存在することによって、 Web サービスに関するデータは、 一般的で、完全にベンダ中立の立場の一貫性のある、信頼できる方法で検索できるようになります。 分類による正確な検索を、 拡張可能な分類システムと識別を使用して実行できます。 実行時 UDDI 統合をアプリケーションに組み込むことができます。 その結果、Web サービス環境がさらに充実します。
どのように機能するか
UDDI データはオペレータ ノードによってホストされます。 オペレータ ノードとは、 UDDI.org コンソーシアムが管理する仕様に準拠するパブリック ノードを運用していることを表明している企業のことです。 現在は、バージョン 1 UDDI 仕様に準拠する 2 つのパブリック ノードが存在します。 1 つは Microsoft がホストするノードで、もう 1 つは IBM がホストするノードです。 また、Hewlett Packard もバージョン 2 仕様でノードをホストすることを表明しています。 全体的な UDDI 集団に冗長性を持たせるために、 ホスト オペレータはセキュリティで保護されたチャネルを経由して、 別の ホスト オペレータとの間でデータを複製する必要があります。 あるノードに公開されたデータは、複製が行われた後に別の ノードで発見できます。 現時点では、24 時間間隔で複製が行われていますが、 今後は、多くのアプリケーションが UDDI データに依存するようになるので、 複製と次の複製の間隔は短くなっていくでしょう。
ホスト オペレータがノードを実装する方法に関する限り、 専用の必要条件が存在しないことは注目に値します。 ノードは単に UDDI 仕様に準拠する必要があるだけです。 たとえば、Microsoft のノード (http://uddi.microsoft.com/default.aspx) は、 全体が C# で記述され、.NET Beta 2 共通言語ランタイムの稼働環境で実行されます。 コード ベースの多くの部分で、.NET システム クラスが提供するネイティブな SOAP サポートや、 シリアル化を利用しています。 Microsoft オペレータ ノードは、 バックエンドで Microsoft® SQL Server 2000 をデータ ストアとして利用しています。 IBM ノードについては、ノードを運用するのに別のテクノロジを使用している言うにとどめておきましょう。 しかし、これら 2 つのノードは同じ SOAP ベースの XML API 呼び出しに準拠しているので、 同じように動作します。 クライアント ツールはどちらのノードともシームレスに相互運用できます。 このように、 UDDI のパブリック集団は、 XML Web サービス モデルが異なる環境にまたがって、いかに機能するかを示す主要な例になります。
UDDI イニシアティブを理解する次の段階として、 どのようなデータが UDDI に格納され、どのような方法で構造化されるかを見ていきましょう。 UDDI は比較的簡易な形式で、"リポジトリ" ではなく、"レジストリ" としてデザインされています。 その違いは微妙ですが、 きわめて重要です。 リポジトリが実際の情報ストアであるのに対して、 レジストリはユーザーをリソースにリダイレクトします。 一例として Microsoft® Windows® レジストリを考えてみましょう。 このレジストリは基本的な設定やパラメータを含みますが、 最終的にはアプリケーションをリソースまたはバイナリに導きます。 プログラム ID に基づいて COM コンポーネントを検索すると、 まずクラス ID に導かれ、 このクラス ID がバイナリ自体の場所に導きます。
UDDI の動作もこれに似ています。 Windows レジストリと同様に、 GUID (グローバル一意識別子) に依存して、 リソースの場所の検索と決定を実行することを保証します。 UDDI クエリは最終的にインターフェイス (WSDL ファイル、XSD ファイル、DTD ファイルなど)、 または別のサーバーに存在する実装 (ASMX ファイルまたは ASP ファイルなど) に導きます。 このように、UDDI は以下のような疑問点に答えます。
- 「指定した業界向けに、WSDL に基づく Web サービス インターフェイスはどのようなものが公開され、実現されているでしょうか」
- 「どのような企業が、これらのインターフェイスの 1 つに関連する実装を作成しているでしょうか」
- 「一定の方法で分類されている Web サービスは、 どのようなものが現在提供されているでしょうか」
- 「指定した企業はどんな Web サービスを提供しているでしょうか」
- 「企業の Web サービスの使用に関して誰に連絡すればよいでしょうか」
- 「特定の Web サービスの実装の詳細はどのようになっているでしょうか」
WSDL と UDDI
WSDL は、Web サービス プロトコル スタックの重要な一部として出現しました。 したがって、 UDDI と WSDL が互いにどのように機能するか、 インターフェイスと実装の概念が各プロトコルにどのように組み込まれているかを把握しておくことは重要です。 WSDL と UDDI は共に抽象的なメタデータと具体的な実装の区別を明確にするようにデザインされました。 そのため、この区別の意味を理解することが、 WSDL と UDDI を理解する上できわめて重要になります。
たとえば、WSDL はメッセージとポートを明確に区別しています。 メッセージは、Web サービスで必要な構文と意味を示し、常に抽象的です。 それに対して、 ポートは Web サービスを起動できるネットワーク アドレスで、常に具体的なものです。 WSDL ファイルにポート情報を提供する必要はありません。 WSDL には抽象的なインターフェイス情報だけを含めることができ、 具体的な実装データはまったく提供しません。 このような WSDL ファイルが有効だと考えられます。 この手法により、WSDL ファイルが実装から切り離されます。
このことが意味する最も重要なことの 1 つは、 1 つの WSDL インターフェイスに対して複数の実装があり得るということです。 このデザインにより、 異種のシステムが同じインターフェイスの実装を記述でき、 その結果そのシステムが別のシステムと対話できることを保証します。 異なる 3 社が同じ WSDL ファイルを実装していて、 クライアント ソフトウェアの一部に WSDL インターフェイスからのプロキシ/スタブ コードを作成すると、 そのクライアント ソフトウェアは単純にアクセス ポイントを変更するだけで、 同じコード ベースでこれら 3 つの実装すべてと通信できます。
UDDI では、抽象と実装の同様の違いを tModels の概念を使って説明しています。 tModel は "Technology Model" の省略形です。 tModel 構造は、技術的な特徴、インターフェイス、およびメタデータの抽象型を表します。 tModel は、必然的に 1 つ以上の tModel の具体的な実装であるバインディング テンプレートになります。 バインディング テンプレートの内部では、 tModel の特定の実装のアクセス ポイントを登録します。 WSDL のスキーマがインターフェイスと実装の切り離しを可能にしたのと同様に、 tModel と tModel を参照するバインディング テンプレートとを別に公開できるので、 UDDI も同じようなメカニズムを提供します。 たとえば、標準そのもの、または業界グループが特定の業界向けに基準となるインターフェイスを公開すると、 このインターフェイスの実装を複数の企業が作成できます。 したがって、これらのビジネスの実装はそれぞれ同じ tModel を参照することになるでしょう。 WSDL ファイルは、UDDI tModel の完全な例です。
UDDI での登録
UDDI に公開することは、比較的簡単なプロセスです。 最初の手順は、 企業とそのサービスを UDDI にモデル化する方法に関する基本的な情報を決定することです。 これを決定した後の次の手順は、 登録を実際に実行することです。 登録は、Web ベースのユーザー インターフェイスからでも、 プログラムからでも実行できます。 最後の手順は、 エントリが正しく登録されているか、 および異なる種類の検索やツールを使って期待通りに表示されるかを確認するために、 エントリをテストします。
手順 1: UDDI エントリのモデル化
上記で概説したデータ モデルを考えると、 UDDI エントリを確立する前に、収集しておく必要のある重要なデータがいくつかあります。
- Web サービスの実装に使用する tModel (WSDL ファイル) を決定します。
COM コンポーネントの開発と同様に、 Web サービスは既存のインターフェイスに基づいて、 または独自にデザインしたインターフェイスを使用して開発されます。 Web サービスが既存の WSDL に基づいている場合は、 UDDI にその WSDL ファイルが登録されているかどうかを調べる必要があるでしょう。 登録されている場合は、その名前と tModelKey を記録しておく必要があります。 tModelKey は、その WSDL ファイルが登録されたときに UDDI が生成した GUID です。
一方、Web サービスが WSDL ファイルに基づいていて、 その WSDL ファイルが UDDI に登録されていない場合は、 このインターフェイスを表す新しい tModel を作成する準備が必要になります。 この tModel は URI (Uniform Resource Identifiers) 形式の名前 (たとえば MyCompany-com:SampleWebService-interface:v1) を持ち、 WSDL ファイルの場所を指している必要があります。
Web サービスが Microsoft® Visual Studio® .NET サービスの場合は、 ASMX ファイルからのクエリ文字列 (たとえば ) を使用して、 WSDL 記述を生成できます。 ただし、Visual Studio .NET が生成する WSDL ファイルは、 その Web サービスを呼び出すためのアクセス ポイントと密接に結び付けられており、 これは Web サービスが複数の実装を持つ場合は適切ではない場合があります。 WSDL ファイルに複数の実装を持たせるつもりがなければ、 このことは問題になりません。
- 企業名および企業の簡単な説明を、必要に応じて複数の言語で提供し、 企業内の Web サービスの主な連絡先を決定します。
UDDI は xml:lang 名前空間をサポートします。 この名前空間を使って、ビジネスが複数の言語で企業の説明を提供できるようにします。 また、UDDI は電子メール、電話番号、住所情報などの連絡先を一覧することを可能にします。 この連絡先リストは、 その企業の Web サービスに関して問い合わせを行う場合の企業内のリソースの一覧に使用します。 たとえば、誰かがその企業の Web サービスを使い始めたいと考えたときに、 適切な取引関係の責任者に接触する必要がある場合は、 それが誰であるかを記載します。 その Web サービスの使用に関して技術的な連絡先がある場合は、 その担当者も同様に一覧します。
- 企業にとって適切な分類と ID を決定します。
UDDI で現在サポートされている分類については、 Microsoft UDDI ノード (http://uddi.microsoft.com/default.aspx) をご覧ください。 現在サポートされている分類は、 North American Industry Classification System (NAICS)、 Universal Standard Products and Services Codes (UNSPSC)、 ISO 3166、 Standard Industry Classification (SIC)、および GeoWeb Geographic Classification です。 企業を表す最適なカテゴリを選択します。
- 企業が UDDI を使って提供する Web サービスを決定します。
次に、企業がパブリック UDDI ノードに登録する Web サービスを決定します。 このサービスに対して複数のアクセス ポイントが存在しますか。 クライアントがこの Web サービスを利用するために必要なその他のパラメータや情報はありますか。
Web サービスを UDDI に登録することが、 誰でもそれにアクセスできることにつながるわけではないことを理解することは重要です。 セキュリティ、認証、および承認を、UDDI レジストリ エントリと連係させることができます。 「Web サービスが存在することを知った人がだれでも実際にそれを呼び出せるわけではありません。」 Web サービスに対するアクセス権を許可する前に、 企業間で別の手段でやり取りすることが一般的です。
- サービスにとって適切な分類を決定します。
企業を分類したのと同様に、Web サービスも同様に分類できます。 したがって、企業がビジネス レベルで NAICS: Software Publisher (51121) として分類されても、 その企業のホテル予約 Web サービスはサービス レベルで NAICS: Hotels and Motels (72111) として分類されることもあります。
手順 2: UDDI エントリの登録
モデル化の実施が完了した後の次の手順は、企業を登録することです。 UDDI レジストリを使うアカウントを入手する必要があります。 利用同意書に同意する必要があるので、アカウントの取得をプログラムから行うことはできません。 Microsoft ノードは認証に Passport を使用しているので、 登録を進めるには Passport (http://www.passport.com/Consumer/default.asp) を取得する必要があります。
登録には 2 つの選択肢があります。 1 つは Microsoft ノードが提供する Web ユーザー インターフェイスを使用する方法で、 もう 1 つはそのノード自体に SOAP API 呼び出しを発行し、プログラムから登録を行う方法です。 エントリに多くの変更を行う予定がない場合、 またはエントリが比較的簡単な場合は、 Web ユーザー インターフェイスを使う方法で十分です。 しかし、頻繁に更新する予定がある場合、 またはエントリがかなり複雑な場合は、 Microsoft UDDI SDK を使用して登録プロセスをスクリプト化することは意味があります。 また、Microsoft ユーザー インターフェイスはほかの言語にはローカライズされていません。 その結果、UDDI API の機能を利用する場合も、プログラムから登録する必要があります。
Microsoft の Web ユーザー インターフェイスの使用
Microsoft の Web ユーザー インターフェイスを使用して登録することは、 比較的直感的な処理です。 まず、Administer ページ (http://uddi.microsoft.com/administer.aspx) にナビゲートします。 ログインすると、 tModels とビジネスを登録するオプションが表示されます。 以下に処理の過程で知ることになることを少し示しておきます。
- プロセスの後半で tModel が必要とするので、 サービスを登録する前に必ず WSDL ファイルを tModel として登録します。
- WSDL ドキュメントを tModel として登録するときは、 UDDI Types Taxonomy を使用して、 その tModel を分類する必要があります。 少なくとも、WSDL は "Specification for a Web Service" (wsdlSpec) として分類される必要があります。
この方法で分類することにより、 tModel が 「UDDI レジストリにおける WASL の使用」 ベストプラクティス ドキュメント に従って分類されることが保証されます。 tModels は WSDL ファイル以外のドキュメントへの参照を保持できるので、 tModel に何らかの分類を提供することは重要です。 Visual Studio .NET などのツールは、 実行したクエリの結果セットを絞り込むためにこのような分類に依存します。
- WSDL インターフェイスを tModel として登録した後に、 適切な連絡先情報と分類情報と共にビジネスを追加する必要があります。 適切だと思われる数の分類を追加できます。
- UDDI を使用して公開したい Web サービスの追加に進みます。 サービスは複数の実装を持つことができるので、 追加するサービスごとにバインディングを追加する必要があります。 バインディングごとに、 Web サービスのアクセス ポイント、 つまり を提供する必要があります。
- 各バインディングは、 サポートするインターフェイスへの参照を作成する必要があります。 Microsoft UI はこれらを "specification signatures" と呼んでいます。 specification signature は WSDL インターフェイスを含む tModel です。 Microsoft UI は、その URN に基づいた tModel を検索できる画面を用意しています。 この tModel は、手順 1 で登録したものか、 誰かほかの人が登録した WSDL ファイルの tModel のいずれかです。
- 最後に、 Web サービスの特定のインスタンスに関する概要ドキュメントの http 位置と任意の適切なインスタンス パラメータを提供するオプションが表示されます。
Microsoft UDDI .NET SDK を使用したプログラムからの登録
登録のもう 1 つの選択肢は、 プログラムから登録することです。 Microsoft UDDI SDK を使用することで、 これを簡単に行えます。 Web UI を使用して UDDI アカウントを取得する必要がありますが、 その作業が完了すれば、 残りのプロセスはスクリプトを使用して処理できます。 まず、http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrvuddi.asp から UDDI SDK をダウンロードして、インストールします。 次に、Visual Studio .NET を使用して新規 C# コンソール アプリケーションを作成します。 Microsoft UDDI SDK dll への参照設定を追加します。 この DLL は既定では C:\Program Files\Microsoft UDDI SDK\VS7\Microsoft.Uddi.Sdk.dll にインストールされます。 その後、コードの先頭で以下のようにいくつか名前空間参照を追加します。
using Microsoft.Uddi;
using Microsoft.Uddi.Binding;
using Microsoft.Uddi.Business;
using Microsoft.Uddi.Service;
using Microsoft.Uddi.ServiceType;
static void Main (string[] args) 関数に次のコードを追加します。
//次のサイトでのテスト登録に対してこのプログラムを最初に実行します。
//https://test.uddi.microsoft.com/publish
Publish.Url = "https://uddi.microsoft.com/publish";
Publish.User = "取得したアカウントを記述します";
Publish.Password = "************";
これにより、アカウントの認証が確立されます。 次に、WSDL ファイルを tModel として発行するために、以下のコードを追加します。
//tModel を作成します。
SaveTModel stm = new SaveTModel();
stm.TModels.Add();
stm.TModels[0].Name = "ここに URN を記述します";
stm.TModels[0].Descriptions.Add("en","ここに説明を記述します");
stm.TModels[0].OverviewDoc.OverviewURL = "ここに WSDL の URL を記述します";
//次の行は、tModel を適切に分類するために必要です。
stm.TModels[0].CategoryBag.Add
( "uddi-org:types",
"wsdlSpec",
"uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" );
string sTModelKey = "";
//UDDI に送信します。
try
{
TModelDetail tmd = stm.Send();
sTModelKey = tmd.TModels[0].TModelKey;
}
catch (UddiException ue)
{
Console.WriteLine ( ue.Message );
return;
}
catch (Exception e)
{
Console.WriteLine ( e.Message );
return;
}
正しく保存されたときに、 UDDI は新しい一意な tModelKey を生成します。 tModelKey は、後で Web サービスのバインディングに使用します。 続いて、ビジネス エントリを作成します。
//ビジネスを作成します。
SaveBusiness sb = new SaveBusiness();
sb.BusinessEntities.Add();
sb.BusinessEntities[0].Name = "ここにビジネス名を記述します";
sb.BusinessEntities[0].Descriptions.Add("en","ここに説明を記述します");
//ビジネス サービスを作成します。
sb.BusinessEntities[0].BusinessServices.Add();
sb.BusinessEntities[0].BusinessServices[0].Name = "ここにサービス名を記述します";
sb.BusinessEntities[0].BusinessServices[0].Descriptions.
Add("en","ここにサービスの説明を記述します");
//バインディング テンプレートを作成します。
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates.Add();
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
Description.Add("en","ここにバインディングの説明を記述します");
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
AccessPoint.Text = "ここにアクセス ポイントを記述します";
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
AccessPoint.URLType = Microsoft.Uddi.Api.URLTypeEnum.Http;
//tModel のインスタンス情報を作成します。
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos.Add();
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos[0].Descriptions.
Add("en","ここに説明を記述します");
//上記の tModelKey 文字列を使用します。
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos[0].TModelKey = sTModelKey;
//UDDI に送信します。
try
{
BusinessDetail bd = sb.Send();
//xml を表示します。
Console.WriteLine ( bd );
}
catch (UddiException ue)
{
Console.WriteLine ( ue.Message );
return;
}
catch (Exception e)
{
Console.WriteLine ( e.Message );
return;
}
この時点で、WSDL 定義とビジネス情報の両方が UDDI に保存されます。 適切なキーを渡すことによって、 今後常にこのエントリを編集できます。
手順 3: エントリを UDDI で検索する
エントリを UDDI に登録後、3 つの確認を行うことをお勧めします。 まず、 Microsoft Web ユーザー インターフェイスを使用して、 名前と分類に基づいて登録したビジネスを検索し、 返される結果セットを確認します。 次に、 Visual Studio .NET を開き、 [Web 参照の追加] ダイアログ ボックスに登録したビジネスが表示されることを確認します。 表示されない場合は、 おそらく tModel が上記で説明した uddi-org:types 分類を使用して正しく分類されていません。 プロジェクトにその Web サービスを追加でき、 WSDL ファイルに基づくプロキシ コードを生成できます。 最後に、24 時間後に登録したエントリが IBM ノードに複製されるので、 https://www-3.ibm.com/services/uddi/protect/find でその UI を使ってエントリを検索して確認します。
まとめ
UDDI と WSDL は、 Web サービスに基づくソフトウェアの全体像を有効にすることを支援する優れた仕様です。 WSDL は、次世代のリモート プロシージャ コールを実現できるように、 Web サービスを定義するベンダ中立の、公式の手段を提供します。 それに対して、UDDI は Web サービスを記述し、発見できるように、 広範な、標準化されたインフラストラクチャを提供します。 これら 2 つの標準を組み合わせることによって、 Web サービスの世界を広げていくことができます。
次週のコラムでは、 Favorites Service を UDDI にモデル化し、 登録するときに At Your Service チームが経験したことを検証してみましょう。
