Web サービスにおける専用 UDDI ノードの役割: 第 1 回 6 種類のUDDI

Steve Grahamは、Web Servicesディスカバリーを支える概念を紹介し、UDDI (Universal Description, Discovery and Integration) の概要について述べています。また、UDDIレジストリーの6つのバリエーションを検討し、これらの各レジストリーがサービス指向アーキテクチャーでどのような役割を果たしているかについて解説しています。

Steve Graham, Web Services Architect, IBM Emerging Internet Technologies

Steve Grahamは、IBM Software GroupのEmerging Technologies部門の設計者です。彼はこの 数年間、サービス指向アーキテクチャーの仕事に取り組んでおり、最近では、IBM Web Services Initiativeに参画しています。Steveは、この仕事に参加する前は、JavaやXMLなどの各種の新規テクノロジーを担当するテクノロジスト兼コンサルタントとして働きました。その前は、IBM Smalltalkコンサルティング部門のアーキテクト兼コンサルタントとして勤めていました。

IBMに入る前、Steveは、Sybaseのデベロッパー、コンサルタントとして働いたり、University of WaterlooのDepartment of Computer Scienceの教職員(注:"faculty member"は通常、教授/助教授/講師などの教官を指して使われます)として働いていました。Steveは、University of Waterlooから情報科学のBMathおよびMMathを授与されています。



2001年 5月

サービス指向アーキテクチャーでは、サービス・リクエスターとサービス・プロバイダー間の疎結合を維持する場合に、サービス記述とメタデータが重要な役割を果たしています。サービス・プロバイダーによって公開されるサービス記述を利用すれば、サービス・リクエスターとサービス・プロバイダーとを結合できます。サービス・リクエスターは、さまざまな技法を使ってサービス記述を取得します。つまり、「電子メールでサービス記述を送ってください」といった簡単な方法や、いまだに根強い人気のスニーカー・ネット方法といったものから、MicrosoftのDISCOや、これらから説明するUDDIのような高度なサービス・レジストリーを利用する技法にいたるまで各種のアプローチがあります。

UDDI

UDDIでは、バージョン1.0のデータ・モデルの中で4つの基本データ・エレメントを定義しています。すなわち、businessEntity (ビジネス情報のモデル化)、businessService (高レベル・サービス記述)、tModel (テクノロジー・タイプまたはサービス・タイプのモデル化)、およびbindingTemplate (businessServicetModels 間のマッピング) がそれです。この記事では、これらのエレメントの詳細については述べませんので、UDDIについての基本情報が必要な場合は、先へ進む前にUDDI Webサイトにアクセスしてください (参考文献を参照)。

UDDIビジネス・レジストリーと呼ばれる運営者ノードのセット、つまりUDDI運営者クラウド は、設計時サービス・ディスカバリーという特徴を持った特定のプログラミング・モデルを意味しています。設計時ディスカバリーが必要なのは、過度の複雑さのために実行時に動的な発見を実施できないことがよくあるからです。

しかし、IBM Web Servicesイニシアチブが提唱するジャストインタイム統合 の考え方によれば、企業は実行時にWeb Servicesの動的発見と動的結合を行うことができます。これを行うには、設計時にAPI特性と他の非機能要件をビジネス・ポリシーとして指定します。この柔軟性は、企業内および企業間で疎結合エンタープライズ・アプリケーション統合を行うための重要な特性です。

動的スタイルのWeb Services結合をサポートするUDDIクラウドの役割は、現在は制限されています。それでも、UDDI APIとデータ・モデル規格は、サービス指向アーキテクチャーで役割を果たすことができます。専用UDDIノードまたは非運営者UDDIノードの考え方は、動的スタイルのサービス指向アーキテクチャーを生み出すために不可欠なものです。


6種類のUDDI

UDDIは、実際上、次の2つのものから構成されています。1.運営者ノードのUDDIクラウド。Web Servicesメタデータ用のインターネット規模のリポジトリーです(ホワイト、イエロー、およびグリーン・ページからなります)。2. Web Servicesメタデータ・リポジトリー用のAPIおよびデータ・モデル 規格。前者はデータをホストし、後者はそれにアクセスする方法を提供します。

現在、UDDIの最も重要な形態はUDDI運営者クラウドです。UDDI運営者クラウドとは、任意の運営者ノードからWeb Servicesメタデータに一様なアクセスを行えるようにするための、運営者の合意に基づいて調整されたUDDIノードの集合です。ある運営者ノードにWeb Servicesメタデータを入力した場合、一定時間後に、他の任意の運営者ノードからそれを取り出すことができます。これらの運営者ノードは、適切に定義された複製方式を使用してそのデータを共用します。

UDDI仕様の構造は、専用UDDIノードも許しています。専用UDDIノードでは、UDDI V1.0仕様によって定義されたすべてのUDDI APIをインプリメントできますが、UDDI運営者の合意によって定義された複製方式は使用されません。

わたしは、UDDIの6つのバリエーション (わたしはこれを「種類」と呼んでいます) を以下のように識別しました。

  1. UDDI運営者ノード
  2. e-marketplace UDDI
  3. ポータルUDDI
  4. パートナー・カタログUDDI (検証済みパートナーまたは名刺整理箱・スタイルのUDDI)
  5. 内部エンタープライズ・アプリケーション統合UDDI
  6. テスト・ベッドUDDI

最初の種類のUDDI運営者ノードを除くすべての種類は、専用ノードまたは非運営者ノードと見なされます。データ・ボリュームが多いこと、業界、地理、対象製品などが広範囲にわたっていること、また運営者合意に準拠する必要があることなどのために、運営者ノードでは、提供できる追加の動作や動作の種類に制限があります。専用ノードでは、このような制限はありません。

次に、それぞれのタイプのUDDIノードについて簡単に説明します。


UDDI運営者

UDDIと聞いて、ほとんどの人がまず思い浮かべるのがこのタイプです。これらのUDDIノードは、www.uddi.org (参考文献を参照) からアクセスできる運営者クラウド機能を形成します。このノードの最適例が、現在IBM、Microsoft、および間もなく参加するHP間で複製されているUDDIビジネス・レジストリーです (参考文献を参照)。以前運営者であったAribaは、つい最近、Web Services登録係の役割へシフトしようとしていると発表しました。


e-marketplace UDDI

この専用UDDIノードは、e-marketplace、規格団体、または業界に参加したりそこで競合したりする企業のコンソーシアムによってホストされます。このUDDIノードの場合、すべての照会API (つまり、publish およびfind) は、任意のメンバー企業がインターネットを介してアクセスできるように展開されます。

この種類のUDDIの項目は、特定の業界または狭い範囲の関連業界と関係しています。このようなメンバーシップ・プロセスでは、前もって項目をフィルターに掛け、業界に参加している合法的な企業しか含めないようにすることができます。このメンバーシップ・プロセスでは、UDDIノードに対してfind操作を起動できる人を制限することもできます。たとえば、製鉄会社の業界が、UDDIノードをホストすることで、そのメンバーが自分のビジネスやWeb Servicesを登録できるようにすることができます。

e-marketplace UDDIは、特定のe-marketplaceまたは業界内で取引を行うためのWeb Servicesメタデータを見つけ出す際に役立つターゲット・リッチな環境です。e-marketplace UDDIは、業界固有のカスタム分類法 (標準製品コーディング階層、North American Industry Classification System [NAICS] カテゴリーへの限定) や、業界の共通ビジネス・プロセスの標準Web Serviceインターフェース定義 (tModel) を見つけ出すための論理的な場所です。たとえば、ベンダーは、e-marketplaceのUDDIに含まれているtModelを調べることにより、製鉄業界で通常行われている発注のタイプを確認することができます。標準Web Servicesインターフェース定義についての各業界の合意が増えていくのに伴い、Web Servicesの採用が促進されます。

このスタイルの専用UDDIノードを利用すれば、e-marketplaceは、パートナーのWeb Services応答時間に関するサービス品質モニターや、メンバーのWeb Servicesビジネス慣行に関するBetter Business Bureauスタイルの業界セルフ・モニターなどの、付加価値を提供することができます。

e-marketplace UDDIノードでは、本格的なマシン間 (M2M) B2Bのfindが行われます。バイヤーは、業界内のさまざまなサプライヤーに見積依頼 (RFQ) を出すための準備として、e-marketplace UDDIノードにfindを出すことができます。このUDDIノードに対して、単にfindを行うことにより、Web Service呼び出しを介してRFQを受け取ることができるすべてのサプライヤーがわかります。これらのe-marketplaceは、UDDI運営者クラウドが非介入になることを防止するために、Web Servicesアリーナに移行しようとします。


ポータルUDDI

トランザクションWebとは、インターネットがどの程度M2M B2Bに使用されていることを指します。企業は、目で見えるWebページ (http://www.acme.com) 上にWebプレゼンスを持っていますが、同様に、トランザクションWeb (http://www.acme.com/uddi) 上にもプレゼンスを持っています。わたしはこのトランザクションWebプレゼンスをポータルUDDI と呼んでいます。

ポータルUDDIは、通常、企業のファイアウォールの非武装地帯に常駐していて、その企業のWeb Servicesに関連するメタデータだけが入っている専用ノードになっています。そのため、www.acme.com/uddiの項目は、acme.comが外部パートナーに提供しようとしているWeb Servicesのためのメタデータを反映しています。find APIをインターネットからアクセスできるようにしておくのは、明らかに企業の利益のためです。ただし、publish APIが除去され、内部プロセスからのpublishしかできないようになります。

acme.comは、Web Servicesを展開する場合、Web Services記述をポータルUDDIに公開します。次に、他の機能 (次回の記事で説明) が自動的に起動され、Web Servicesメタデータが他のUDDIノード (つまり、運営者クラウドや各種e-marketplace、キー・パートナー・カタログなど)に正しく反映されるようにします。

ポータルUDDIを使用すれば、企業は、Web Servicesを記述するメタデータをどのように使用するかを制御することができます。たとえば、企業はfindアクセスを制限することができます。また、自社データに対する検索の回数をモニターしたり管理したりすることもでき、どのパーティーが関心を示しているかについての情報を入手することもできます。

UDDI運営者クラウドに関しては、acme.comのbusinessEntity レコードの中で、acme.comトランザクションWebプレゼンスUDDIノードのURLをdiscoveryURL として使用することができます。


パートナー・カタログUDDI

この専用UDDIノードはファイアウォールの背後に常駐していて、それに対するfindとbindが行われます。このノードには、信頼のおけるビジネス・パートナー (つまり、acme.comとの正式な合意 / 関係を持つ組織) によって発行されたWeb Service記述メタデータのみが含まれています。publishおよびfind APIはインターネットでは使用できないため、内部アプリケーションのみがすべてのAPIにアクセスできます。

パートナー・カタログを使用すれば、企業は、設計時に確立されたWeb Servicesインターフェースを介したWeb Servicesの動的結合を利用して、サービス指向的にアプリケーションを作成することができます。Web Serviceインターフェース定義によって実現されたWeb ServicesとのAPI (たとえば、tModelの使用による従来のWSDLの使用) は、設計時に確定されます。しかし、トランスポートやセキュリティー・スタックといった他の特性は、実行時に動的に設定することができます。アプリケーションは、このUDDIに対して実行されたfindと一致するWeb Servicesを受け入れるようにコ-ディングされます。UDDIノードには承認済みビジネス・パートナーしか含まれていないため、この動的結合により、未知のサービス・プロバイダーと取引をするような危険が生じることはありません。

以下のシナリオを考えてみます。Buyer.comは、Web Services技法を使用してM2M e-businessを実行し、再発注などのサプライ・チェーン・タスクのトランザクション・コストを削減しようとしていますが、特定のベンダーとの取引に縛られたくはありません。Buyer.comのマネージメントは、acme.comとの取引に合意しています。Buyer.comのITスタッフは、acme.comのUDDI項目を調べ (運営者クラウド、e-marketplace UDDI、またはacme.comのポータルUDDIから)、これら約を結ぼうとしているすべてのベンダーについてこのプロセスを繰り返します。取引関係が形成されたり解消したりするのに伴い、サプライヤー・リストに変更が生じた場合、Buyer.comのパートナー・カタログUDDIノードに入っている項目の変更が更新されます。

プロキシーは、パートナー・カタログUDDIノードに対するfindを実行するために作成されたWSDL規格とアプリケーションから生成できます。これらのアプリケーションは、承認済みパートナーのリストの変更に対応するための再コードを行う必要はありません。これらのアプリケーションは、UDDI項目を使用して利用可能なWeb Servicesを判別し、所定のビジネス・ポリシーに基づいて、起動に最適のWeb Servicesを1つ以上選択してからWeb Servicesを起動します。

この動的結合アプリケーション・サポートを完全なものにするために、パートナー・カタログUDDIノードは、特定の基準を満たす項目のみ (たとえば、WSDLベースのtModelに関連するbusinessServicesのみ、または周知の業界標準購入オーダーtModelをサポートするbusinessServicesのみ) を使用するようにpublish機能を制限することができます。これによりアドミニストレーターは、UDDIノードに含める項目の形状を保証でき、したがって、find操作に対する応答としてアプリケーションが実行する処置も保証できます。

パートナー・カタログUDDIノードは、それをサポートするビジネスとはかかわりなく、tModelキーに基づくfind businessServiceや、WSDLタイプに基づくfind businessServiceなどの付加価値サービスもサポートします。これらの追加APIは上記のシナリオをサポートします。


内部エンタープライズ・アプリケーション統合UDDI

これはパートナー・カタログの種類と似ていますが、異なる点は、項目が企業内の他の部門またはグループによって提供されるWeb Services向けであることです。この種類の大きな特徴は、標準を規定することができる共通管理ドメインが持つ可能性です (たとえば、tModelの使用、WSDL portTypesの共用、など)。これにより、このUDDIノードは、パートナー・カタログUDDIの場合に推奨される制限とは異なるpublish制限で操作することができます。たとえば、このノードは新しいtModelの発行を制限できるため、固定セットのtModelに関連する項目のみを受け入れるようにbusinessServiceとbindingTemplateの発行を制限することができます。固定セットのtModelは、共通管理可能ドメインによって選択されたテクノロジー標準に対応しています。

もちろん、この種類は企業のファイアウォールの背後に完全に隠れて存在しています。publishおよびfind操作は、企業内のアプリケーションに限定されています。


テスト・ベッドUDDI

このタイプの専用UDDIノードはアプリケーションをテストします。このテストは、リクエスター・アプリケーションにもプロバイダーWeb Servicesにも行えます。

acme.comによりWeb Servicesが発注システムにアクセスできるようになると、acme.comは、このタイプのUDDIノードを使用して次の2つの点について確認します。1. Web ServicesのUDDI項目が正確であること。2. アプリケーションがWeb Service情報を使用して、Web ServicesにアクセスするためのプロキシーをUDDI項目から生成できること。

acme.comは、Web Servicesを使用するアプリケーションを作成した場合、アプリケーションが変種のWeb Service記述に対処できるかどうかを、テスト・ベッドUDDIの項目でテストします。acme.comは明らかに、運営者クラウドで発見された新規のUDDI項目、またはe-marketplace UDDIあるいはパートナーのトランザクションWebプレゼンスUDDIに対していくつかの試行を行おうとします。通常、ここではまず、項目のコピーが行われます。次に、アプリケーションが項目内の情報を使用できるかどうかを調べるために、一連のテストが行われます。さらに、テストの後でのみ、この項目が検査済みパートナーのUDDI、またはエンタープライズ・アプリケーション統合UDDIノードにプロモートされます。


結論

以上、UDDIがサービス指向アーキテクチャー内で果たすディスカバリーの役割の概要について述べ、それぞれがサービス指向アーキテクチャーの異なる使用をサポートする6つの種類のUDDIを示しました。次回の記事では、専用UDDIノードと運営者UDDIノードを使用するそれぞれのプログラミング・モデルを対比し、専用UDDIを使いやすくするための機能要件をレビューします。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=243768
ArticleTitle=Web サービスにおける専用 UDDI ノードの役割: 第 1 回 6 種類のUDDI
publish-date=052001