UDDIサービス　シナリオ

テレコムアプリケーションを簡単に作成できるって本当ですか？はい、本当です。 CTServerを使用すれば電話自動応答システム、ＣＴＩシステムのテレコムアプリケーションが簡単に作成できます。

最新更新日：

　UDDIサービス　シナリオ

TOPページへ

UDDIとは

UDDIとは

Universal Description Discovery and Integration　産業界のプロジェクトUDDIの仕様。
UDDI仕様

－サービスプロバイダと記述用のスキーマ－公開及び検索用のSOAP API
－インターネット標準に基づいて開発（XML、HTTP、TCP/IP、SOAP）
－ XMLと非XMLの両サービスをサポートする
UDDIの機能

ISOAPインターフェイスを持つWeb Serviceのディレクトリ・サービスである。インターネット上でサービス（Web Service）を提供したい企業は、サービスの内容や利用方法などをUDDIディレクトリに登録する。そしてサービスを利用したい企業は、このUDDIディレクトリを検索する。
UDDIの実装

公開及びプライベートでの導入
UDDIのディレクトリ

次の3つのカテゴリで構成されている。－ White pages：名前（企業名、製品名、サービス名など）でサービスを検索する。－ Yellow pages：サービス内容やカテゴリ、型情報でサービスを検索する。－ Green pages：個々のサービスに関する詳細な技術情報からサービスを検索する。UDDIディレクトリに登録されるWeb Serviceの具体的なサービス内容は、Web Service記述言語のWSDLによって記述されている。またこのUDDIディレクトリ自身もWeb Serviceとして構成されており、SOAPインターフェイスを用いて、サービスの登録や検索をソフトウェアだけで行うことが可能である。

UDDIの動作方法

プロバイダ

－　例：　経理部門、企業のアプリケーションサーバー
－　名前、説明、サポート情報
－　分類情報及び識別情報
サービス

－　例：　注文書サービス、給与振込サービス
－　名前、説明
－　分類情報
バインディング

－　記述、アクセスポイント、パラメータ
－　例：　Webサービスのアクセスポイント（Http://…）

UDDIの動作方法

tModel = テクノロジモデル
コンセプト又は構造をユニークに表す汎用メタデータ構造
インターフェースプロトルコの定義も含む
強力な抽象的モデリングシステム
例： WSDLファイル、XMLスキーマ、名前空間、分類スキーム

UDDI情報モデル（一）

UDDI情報モデル（二）

UDDI情報モデル（三）

IT管理者はUDDIサービスを設定して、読み取り/書き込み権限を適切利用者に付与します。
企業の開発者はUDDIとtModel（WSDLファイルその他のインターフェース）を設定します。
実装を作成したプロバイダも、そのアプリケーションを登録します。
UDDIは自動的に、各エンディディにユニークな識別子を割り当てます。
これで開発者は、設計時にコンポーネントとアプリケーションを再利用可能な共有リソースとしてUDDIサービスを使用できます。
実行時にはWebサービスクライアントは、Webサービスをダイナミックに発見して利用するように構成できます。

UDDI実装シナリオ　―　企業のWebサービスのサポート

見通しのよさと共有―Web サービスインターフェースの仕様

－顧客

大手自動車メーカー (企業)

－目標とする対象者

情報システムマネージャ、部門の中堅、一般開発者、IT 業務部門および管理部門

－課題

企業内で利用できるサービスとアプリケーションはどこにあるのか、またそれにどうアクセスすればよいか？

－シナリオ

この会社では、社内で利用可能なアプリケーションと情報サービスをどう特定するかが課題です。会社は複数のビジネス部門で構成されており、各部門には異なるプログラミング言語 (C++、C#、Visual BasicR、Perl、COBOL等) で書かれた独自のアプリケーションがあり、複数プラットフォーム (Windows、UNIX、Linux、MVS) が存在しています。さらに各部門は、SAP や Siebel などのベンダからビジネス用のパッケージアプリケーションを購入しています。幾つかの部門はもともと新しいテクノロジを早くから採用する部門で、SOAP/XML ベースの Web サービスを通してアプリケーションを公開しましたが、多くの部門は公開しませんでした。同様に一部の部門はアプリケーション用にきちんと定義された標準インターフェースを制定しましたが、多くの部門ではまだです。この会社の自動車およびレース部門は早くからテクノロジを採用する部門ですが、一般的に財務サービス部門はより保守的です。各部門は引き続き新システムを開発、導入していますが、部門を越えて利用可能なシステムを追跡することは普通は不可能で、時には部門内でさえ不可能であり、開発情報を部門間で共有することは制限されています。この情報は散逸していて組織化されていないため、会社のアプリケーション開発プロセスには多くの非効率が存在します。

①アプリケーションコードと機能は部門間で重複しており、時間と労力が浪費されています。

②開発者はアプリケーションの一般情報を一部持っていますが、特定のリソースやアプリケーションそのものを検索することは困難です。そのため他の開発者やIT マネージャと電子メールのやり取りや電話する時間が必要となり、情報の検索は時間がかかります。

③アプリケーションが検索されても、アプリケーションの動作方法やサポートしているプロトコルとインターフェース、提供するビジネス機能の仕様などを判断する標準の方法はありません。これはしばしば、アプリケーションについて学ぶため電子メールのやり取りや電話する時間を増加させます。部門のアプリケーション間で統合が実施されるようになると、開発者間での情報の共有や実装上の細かいトラブルに対応することに多くの時間が費やされます。
－ UDDI 機能
UDDI は、上に説明した多数の非効率を解決するため特に設計されました。XML と SOAP、UDDI に基づく標準ベースでプラットフォームから独立したソリューションは、企業内のサービスを発見するために問い合わせたり、サービスを公開する構造化されたメカニズムを提供します。UDDI は XML ベースの Webサービスと同様、レガシーアプリケーションもサポートするように設計されており、IT 部門はサービスを企業全体で構造化してカタログ化することが可能になるので、必要な時に適切なサービスを発見できます。内部 UDDI サーバーの導入はいくつかの部署で開発者とIT の効率の向上をもたらします。企業内開発者は Visual StudioR .NET を通してサービスやプロトコル仕様を検索して開発環境にインポートでき、サービスと通信するのに必要なコードを自動的に生成できます。企業が標準プロトコルのポートフォリオを制定すると、開発者は労力を付加価値機能に集中でき、基礎となるインフラストラクチャと通信するオーバーヘッドを減らすことができます。この機能は Visual Studio .NET だけに限りません。UDDI はオープン規格に基づいている為、UDDI 対応の開発ツールはどれも類似した機能を利用できます。
1. UDDI サーバーは、サービスを登録する単一の場所を提供します。このサービスは会社にとって有意義な方法で分類できるので、部門や製品、テクノロジ、地域などを越えてアプリケーションを記述して発見することができます。会社の開発者はUDDI サービスが利用可能なので、サービスを検索したり既存アプリケーションを書き換える代わりに、新しく必要なアプリケーションのプログラミングに集中できます。
2. UDDI は、基礎となるツールやテクノロジと特定の結びつきなしに、部門のシステムにアクセスして会社全体プロトコルの再利用を促すスキーマと規格をインデックス付けする機能をサポートしています。この結果、企業レベルまたは協力し合う部門間でシステムを統合する費用が削減されます。またこのプロトコルについての知識は、開発者がほかのシステムと情報交換すると共に、その学習曲線をなだらかにします。
3. UDDI は、開発ツールと統合化された開発環境 (IDE) から直接アクセスできる共通リソースを提供します。例えばVisualStudio.NET 機能は、WSDL (Web サービス記述言語) ファイルを利用する際に UDDIをサポートしています。
－ UDDI 開始ステップ

①基本登録

会社の企業テクノロジチームは、.NET 開発サービスインフラストラクチャの一部として UDDI サーバーを導入します。このソリューションは、開発スタッフ全員が利用できます。各開発者はそれぞれの部門の新規アプリケーションとサービスに従事しています。部門間でより多くの情報を共有しようというイニシアティブの一部として、財務部門と自動車部門は、次世代の信用業務と注文システムの統合に合意しました。財務部門は COBOLを使用してメインフレーム上にアプリケーションを開発しており、自動車部門は早くから Microsoft .NET を採用していて、XML や SOAP、Visual Studio.NET を使用しています。統合作業の一部として、通信をスムーズにするため調整チームが設置されました。この調整チームは UDDI サーバーを導入して、管理者はサービス情報を追加するため開発チームにアクセス権を追加しました。開発プロセスの最初のステップは、既にほかの部門で開発中のサービス情報を提供することです。各開発者には UDDI仕様とマニュアルが提供され、新規アプリケーションサービスを UDDIに登録するよう指示されます。2 つの開発チームが情報を公開するために従うプロセスは全く別です。Visual Studio.NETの開発者はネイティブのUDDI 統合を使用して、IDEからサービスを直接登録します。COBOL プログラマは UDDI サービスの一部として提供されるブラウザベースのUI を使用して、統合ポイントについての情報と仕様へのポインタ情報、ならびにファイル形式とドキュメントを定義するブックを直接追加します。このプロセスが完了すると、両チームはアプリケーションで利用可能なインターフェースについて共通した理解を得ることができ、成果を再利用できます。2 つの部門には、現在情報共有及びコード再利用という基盤があります。会社のチームは、もはや電話や電子メールに時間をかける必要はなく、代わってすべての開発ツールやプラットフォーム、テクノロジと連携した共通のソリューションを通して情報を共有できます。

②インターフェースの再利用

財務アプリケーションチームがこのプロジェクトを完了すると、チームは新しいツールへの移行を開始し、サービスプロファイルを更新して既存の成果の再利用を開始できます。さらに他の部門も、その部門の開発活動を追加して既に制定された基礎を利用する作業に参加できます。社内の開発者は新規プロジェクトを開始する前に、UDDI サーバーを参照してサービスが既に提供されているか検索したり、既に使用されているインターフェース仕様が利用可能なのか検索します。その結果重複した労力を減少させたり、完全に取り除くことができます。

③検索パラメータと豊富なサービスの記述

会社で、より多くの部門の開発チームがサービスとインターフェースをUDDI に公開するには、それらが、容易に配置でき、決められた検索基準に一致するように、整理されていることが重要です。プロジェクトの次の段階では、世界中の他拠点のアプリケーションチームや他のチームが新たに加わり、既に整理された情報を効率よく利用します。その結果 UDDI は比較的多数のサービスとインターフェースを持つようになり、開発者とアプリケーションが興味のあるデータを正しく検索できるよう、分類情報をサービス登録に追加することが重要となります。これをスムーズにするため、調整チームは会社に固有のニーズをターゲットとするメタ情報のセットを制定します。適切な産業やセキュリティメカニズム、機能エリア、サービスの品質 (QoS) に基づいてサービスの特性を決めるために、スキームが制定されます。これらの属性は、UDDI 内の既存サービスに追加され、新規登録から利用可能になります。サービスを検索中のアプリケーションや開発者は、今後正確に検索するための追加検索パラメータとしてこれを使用できます。

④コードの自動生成

Web サービステクノロジを採用し、WSDL の記述を使用してインターフェース定義を登録した開発チームは、会社全体に付加価値を提供することになります。このサービスの記述は Visual Studio .NET に直接インポートでき、サービスと通信するのに必要なクライアントコードは自動的に生成されます。今後社内の開発者は退屈な統合作業から開放され、付加価値アプリケーション機能の作成に集中できます。

⑤企業サービスの操作ビュー

開発チームの UDDI を利用することの副次効果として、企業の運営にまつわる複数システムの統合ビューが作成されます。アプリケーションサービス、その他登録された特性セットについての情報が、作業チームから利用可能です。これが手がかりとなって、確実にポートフォリオ全体を管理し、必要に応じてモニタすることができるようになります。
－ビジネスメリット
①開発者の効率
1. 部門間の開発作業の重複を取り除きます。
2. Visual Studio .NET と混合開発チームに共通のリソースを提供します。
②レガシの統合
1. 旧来のアプリケーションとインターフェース形式は、企業全体で発見が可能です。
2. サービス情報は、古い開発ツールやプログラミング言語を使用していても全開発者が利用できます。
③操作効率
1. 企業全体 (イントラネットやエクストラネット) でサービスの単一ビューが可能です。
Webサービスの実行時の発見―最適化およびフォールトトレランス

－顧客

証券会社 (企業)

－目標とする対象者

情報システムマネージャ、部門の中堅、一般開発者、IT 業務部門および管理部門

－課題

一つのサービスに対して複数のアクセスポイントが利用可能な場合、どうすれば最適な場所を検索できるか? 災害によりサービスが利用不能となったら、代替手段はどう提供されるか?

－シナリオ

この会社では、世界中のブローカーに情報サービスを提供しています。その XML Web サービスには、顧客のポートフォリオにアクセスしたり、ウォールストリートの分析や実行中のトレードから最新ニュースを受け取る機能が含まれています。一部の頻繁に利用されるサービスや基幹サービスについて、ローカルアクセスポイントが世界中で提供されています。たとえば、200 以上のサービスアクセスポイントがトレーディングサービス用に提供されています。こうした決断をした背景には、サービスへのアクセスを最適化して、ネットワークの待ち時間と通信コストを最小化したいという理由があります。この Web サービスをコア機能に組み込むために、単一の機能豊富なクライアントアプリケーションが会社の IT チームにより作成されました。アプリケーションの開発者が直面した課題は、アプリケーションが地域に基づいて最適なアクセスポイントを発見するメカニズムを提供することです。単一のコード基盤は、どのようにしてサービスの多数の異なるローカルアクセスポイントを知ることができるのでしょう? コードは特定のトレーダーやオフィスに最適なアクセスポイントをどのように動的に選択できるのでしょう? 新興市場では、需要の増加と共に新しいアクセスポイントが拡大されます。アプリケーションはこの新しいサービスをどのようにして発見して、自動的に設定を更新できるのでしょう?またこの会社は、パートナーとの契約で、北米で行った投資信託の取引ごとに売買報告書を印刷することになっています。取引が完了すると、48 時間以内に投資家が確実に報告書を受け取れるように、取引結果はパートナーのデータセンターに送信され、印刷工程に回されます。この情報は信頼性があって、すみやかに共有されることが重要です。信頼性を保証するため、UDDI エントリの一部としてプリンタはそれぞれのサービスに、プライマリサイト、バックアップセット、災害修復サイトという複数のアクセスポイントを提供しています。プライマリシステムが故障すると、会社のシステムは自動的にバックアップサービスを検索して通信する必要があります。重要な Web サービスのアクセスポイントを変更する必要がある場合、アプリケーションはどのように変更できるでしょう?カスタムソリューションを作成して問題を解決できればよいのですが、この会社の IT部門は非常に忙しく、長いコードをアプリケーションに追加する時間がありません。利用可能なサービスの情報をアプリケーションが動的に発見できるようにするためには、UDDI を利用した方がはるかに簡単で確実です。

－ UDDI 機能

上に説明したものとは別の、実行時のシナリオへの対策も、明らかに UDDI のコア機能の一部です。UDDIはオープンソリューションとして設計されており、設計時のユーザーによるブラウジングがスムーズになったばかりでなく、実行時のコンピュータによる呼出しと発見もスムーズとなりました。そのため UDDI は、当然の機能として最適化とフォールトトレランスの基盤を提供しています。例えばこの会社の最初の課題を検討してみましょう。多数の Web サービスに依存するニュース提供アプリケーションは、どうすれば、複数のサービスアクセスポイント (いつでも変更、更新される可能性があります) の情報を得られるでしょうか。この会社はこれらのアクセスポイントをハードコーディングする代わりに、アプリケーションの開始時にユーザーの居場所を識別して、最適なアクセスポイントを UDDI サーバーから取得してキャッシュするよう、アプリケーションを設計できるかもしれません。この結果、各 Web サービスの呼び出しに関連する通信コストと待ち時間が最小化されます。ベルリンのトレーダーはローカルアクセスポイントを通して通信しており、ニューヨークやシドニー向けの高価な、あるいはパフォーマンスの低いサービスと通信したりはしません。後々、ユーザーの居場所が変わった場合は、アプリケーションは UDDI に問い合わせし直してローカルサービスのキャッシュを更新します。会社の基幹トレーディング Web サービスのプライマリ、バックアップ、災害修復用のアクセスポイントが利用可能である場合、会社のトレーディング確認アプリケーションはプライマリサービスポイントが利用不能となった際に、代替ポイントとして UDDI に問合わせるよう設定されています。アルゴリズムでは、アプリケーションは適切な代替サーバーを直接検索することにより、故障したサーバーから迂回するように設定されています。致命的なエラーが起こった際には、UDDI 参照が修復環境の中で同一サービスをホストしている災害修復サイトの場所を指示します。UDDI によって自動的に検索されるバックアップセットにより、情報通信の信頼性が確保されます。

－ UDDI 開始ステップ

①サービス選択基準の決定

トレーディングアプリケーションで利用可能なサービスの発見を最適化するため、会社は選択に使用される特性セットを定義します。この特性の分類方法セットには、サービスの品質 (QoS) や通信コストと待ち時間、サービスポイントの物理的場所を含みます。そしてこの特性は、アプリケーションが呼び出すアクセスポイントの選択に使用するルールセットに組み込まれます。

②アプリケーションへの動的発見の追加

サービスインターフェースの選択ルールが制定されると、会社の開発チームは開始時に UDDI を参照するトレーディングアプリケーションを更新します。正しいアクセスポイントは、サービスが必要とされる時のためにアプリケーションによりキャッシュされます。この結果いつでも最適サービスが使用されます。このため会社の通信コストが可能な限り削減されながら、性能と信頼性が維持されます。

③アクセスポイントの登録

会社の作業チームは、トレーディングアプリケーションに利用可能なサービスの全アクセスポイントを登録します。作業チームはサービスの可用性についての基本情報に加えて、サービスの品質 (QoS) やネットワーク通信コスト、物理的場所を含む記述情報を追加します。この特性は上述のステップ 1 の定義と一貫しており、トレーディングアプリケーションによりサービス選択に使用されます。

④アクセスポイントの更新と拡大

会社のビジネスが成長しつづけるか、あるいは新規市場への参入を果たすと、トレーディング Web サービスのアクセスポイントセットは、サービスレベルの維持と通信コストの制御のために拡大されます。このために、作業チームはサービスの新規アクセスポイントをリストアップして、サービスプロファイルを更新します。たとえばコーヒーの需要が増大して関連する市場価格が上昇すると、プエルトリコの個人投資家数は劇的に増加します。会社がこの需要増加に対処するため支社を拡張すると、新規アクセスポイントが導入されます。地元ブローカーのアプリケーションは翌日からこのサービスを使用するように自動的に更新され、その後はマイアミに接続しません。

⑤フォールトトレランス/バックアップサイトの登録

会社は基幹サービスに対して、常にプライマリおよびバックアップサービスポイントを登録しています。何らかの理由でプライマリサービスポイントとの通信が失敗すると、予備のバックアップサービスポイントへの接続が試みられます。プエルトリコオフィスには、新規ローカルアクセスが利用不能の際に、マイアミサービスポイントを使用するオプションがあります。

⑥重要な最新情報の発見

大規模な致命的エラーが起きて会社全体のデータセンターが故障する場合に備えて、災害修復計画では外部設備に重要なサービスを導入しています。以前はこの通信の更新計画では、修復サイトと同じネットワークアドレスを再展開してリモートシステムに接続を再起動させました。あいにく、IP ルーティングの全情報の更新には長時間が必要です。災害修復チームは高速の修復メカニズムとして、UDDI 内に登録されている Web サービスのアクセスポイントを更新するので、すべてのアプリケーションは新しい情報に直接アクセスできます。その結果会社全体のサービス修復時間はかなり短縮されました。
－ビジネスメリット
①柔軟なアプリケーション
1. アプリケーションは自動的に最適サービスを呼び出します。
2. フォールトトレランスおよびバックアップサービスプロバイダはアプリケーションの設計時から存在するパートです。
②操作効率
1. 最適化された代替サービスポイントが自動的に使用されます。
2. 全アプリケーションは災害修復サイトおよびバックアップサイトと通信でき、故障時にそのサイトを発見できます。
UDDIの機能

－顧客

民間航空機メーカー (メーカー)

－目標とする対象者

情報システムマネージャ、部門の中堅、一般開発者、ビジネス開発マネージャおよびビジネスアナリスト、ビジネスパートナーの開発者およびマネージャ

－課題

数千にもおよぶビジネスパートナーには、Web サービスクライアントと非 XML 電子サービスの両方の開発及び設定に必要な情報を、どのようにして、拡張性に富んで効率的な方法で提供されるか?

－シナリオ

このメーカーには、民間機ビジネスだけで 18,000 以上のビジネスパートナーのネットワークがあります。完全な EDI ソリューションを導入するための技術的スキルとサポート予算があると表明しているのは、その内の比較的少数です。それ以外のパートナーグループは XML Web サービスを使用してメーカーと情報交換する準備ができており、次世代テクノロジを採用する戦略を制定しました。残りの大多数のパートナーは、まだ通信に電話と Fax を使用しています。 3 グループのビジネスパートナーのいずれかが電子的な通信に関係する部分を拡張したいというと、メーカーは大きな課題に直面します。各パートナーと個別に作業するため多額の経費と開発者の時間の消費を強いられ、パートナーは相互運用性の開発と構成、テストへのステップを踏む必要があります。一般に使用されている企業向けソフトウェアパッケージ (つまり Microsoft Great Plainsやほかの ISV 製品) が外部パートナーとの構成をサポートしている場合でも、メーカーは “最後の仕上げを行い”、大量の時間とリソースをかけることなく信頼性と互換性を確保する場面に直面します。一般に多数の下層、小規模パートナーに大型投資を見込むことは無理なため、非効率的でエラーの多い Fax や電子メールによるビジネスが続行されます。このアプローチは費用対効果も拡張性もないため、このメーカーは大多数のパートナーと e コマースを実現できません。メーカーはオープンな業界標準を通してこのプロセスの自動化を希望しているので、パートナーはタイムリーで効率的、費用対効果の高、自動的な方法で取引ネットワークに参加できます。メーカーは基本的に、パートナーの大部分が参加する独自の電子的取引コミュニティを作成しようとしています。どのようにしてそのサービスを、プラットフォームやソフトウェアパッケージの異なる多数の様々なパートナーに、各パートナーと個別に作業することなく提供できるでしょうか?

－ UDDI 機能

このメーカーはエクストラネット UDDI サーバーの導入を通して、標準化された発見メカニズムを提供しているので、パートナーはビジネスの遂行に必要なプロトコルとインターフェースを選択できます。たとえば小規模サプライヤは現在 Fax と電子メールを使用していますが、UDDI に問い合わせて会社の eコマースシステムと互換性のあるソフトウェアパッケージを選択できます。おそらく彼らはGreat Plains を互換性のあるシステムとして見出すでしょう。GreatPlains その他のMicrosoft ビジネスソフトウェアを購入することにより、メーカーの UDDI サーバーか発見したサービス定義に基づいて通信するよう簡単に構成できます。同様に Web サービスのコードを書く専門知識を持った開発チームのいる中規模の会社は、UDDI サーバーから直接通信するための要件を取得でき、ほとんど直接支援しないでアプリケーションを構成できます。このアプローチは、各ビジネスが低エントリコストで電子的商取引関係を作ることを可能にします。さらにこの会社は、上述のシナリオと同様にアプリケーションに実行時の動作を構成でき、一定のフォールトトレランスと信頼性を e コマースソリューションに付与できます。その上、大手パートナーはEDI のようなほかの XML および非 XML 電子サービスを使用して、相互運用性の基礎として UDDI を使用でき、開発チーム間の電話と電子メールによる通信時間を節約できます。UDDI による非XML サービスのサポートは、記述と発見において XML ベースの Web サービスのコアサポートと類似したメリットを提供しています。パッケージ化されたソフトウェアを購入する小規模の会社、独自の Web サービスを作成する中規模の会社、EDI インフラストラクチャをサポートできる大規模の会社という 3 つのシナリオでは、多様なパートナーを伴った大規模の会社でエクストラネットの UDDI 導入が可能なことを示しています。この会社はこの異なるシナリオを一か所から管理することにより、そのデータを保存する場所をセンター化できます。さらにメーカーは、ビジネスパートナーがサービスを UDDI サーバーに直接登録するよう要求できます。こうして会社はパートナーを追跡する最適のメカニズムとパートナーが使用しているプロトコルを手に入れて、通信の効率を相互的に上げることができます。このデータは IT プロフェッショナルにとっても、ビジネス開発マネージャやアナリストにとっても貴重です。アナリストは異なるサプライヤの様々な総合的情報を発見できます。
－ UDDI 開始ステップ
①サービス情報の UDDI への移植

メーカーはエクストラネット UDDI サーバーの導入後、パートナーの利用可能なサービス情報と効率的発見のための追加情報をそれに移植します。メーカーによる UDDI サーバーの移植は、いくつかの方法で達成できます。メーカーの開発者および IT マネージャは、UDDI と共に出荷される Web ブラウザインターフェースを使用して移植できます。または全プロセスをスクリプト化でき、UDDI と関連サービス情報は SOAP Web サービスインターフェースを通してプログラムにより移植できます。プロセスの自動化により、更新と変更は非常に単純となります。UDDI に追加される重要な情報には、
1. サードパーティ製のソフトウェアアプリケーションや EDI 情報などサポートされているインターフェースとプロトコル
2. 各種サービスのアクセスポイント、
3. メーカーのパートナーが UDDI エクストラネットサーバーにアクセスするのに必要な追加 ACL 情報またはセキュリティ情報があります。
②UDDI からパートナーへの通信の可用性

UDDI が移植されると、メーカーはパートナーに機能が利用可能であると通知します。この通知には、単なる電子メールからパートナー会議へのセッション追加などビジネスパートナーによっていろいろのチャンネルを利用できます。この新規 UDDI イニシアティブが理解されると、メーカーのパートナーは様々な方法で UDDI にアクセスします。パートナーはブラウザベースの UI を使用するか、UDDI 対応のクライアントツールを使ってメーカーのUDDI サーバーと対話します。UDDI はオープン XML 規格に基づいているので、パートナーのクライアントツールは特定のプラットフォームやテクノロジに縛られておらず、メーカーの UDDI サービスとの対話方法は大きな柔軟性を持ちます。

③ドキュメントを安全に送受信するためのアクセスポイントの構成

規模と関係なくメーカーのビジネスパートナーが電子的にビジネスする準備ができたら、実装の準備完了を通知してプロダクションサービスにアクセスする資格証明を要求します。するとメーカーのシステム管理者は、パートナーにサービスポイントへのアクセス権を割り当てます。

④パートナーのサービスをメーカーの UDDI サーバーに追加する

パートナーの操作が有効になると、メーカーはパートナーに Web サービスを登録して UDDI 内のポイントにアクセスするよう要求します。その結果メーカーは、購入注文状態や出荷状態の情報を得るため、パートナーのサービスを検索できます。またメーカーはUDDI に登録されたデータに基づいてレポートを実行して、オンラインにある取引パートナーの数を求めたり、パートナーが使用しているソフトウェアパッケージを知ることができます。これによりメーカーは、パートナーコミュニティ全体に制定された eコマースでの的確な関係を築けます。
－ビジネスメリット
①開発者の効率
1. 企業およびパートナーの開発者における相互運用性の労力を減少させます。
②パートナーとレガシーの統合
1. 密接なパートナーコミュニティを組織化して、プラットフォームやテクノロジ、開発言語とは無関係に、自動発見をスムーズにします。
2. ビジネスパートナーとの冗長な通信を最小化して、サービスの問合わせに標準的な手段を提供します。

TOPへ

株式会社オープンコム
〒102-0072　東京都千代田区飯田橋4-8-4　第二プレシーザビル3階
TEL: 03-3263-7885　FAX: 03-3263-7889
お問合せは webinfo@opencom.co.jp まで。