学習目的で、対話するパブリック UDDI レジストリを見つけようとしています。しかし、利用できるものはないようです。SO で次の質問をポップして、まだホストされている公開レジストリについて誰かが知っているかどうかを確認しましたが、回答はありませんでした。
IBM、Microsoft、および SAP のパブリック レジストリは、UDDI テクノロジのテストでした。ここから引用: UBR の主な目標は、公開実装を通じて UDDI 仕様の相互運用性と堅牢性を証明することでした。この目標は達成され、それをはるかに上回りました。
彼らは現在、自社製品で UDDI 仕様を引き続きサポートしています (そのため、さまざまな企業が自社の UBR を私的使用のためにホストすることができます)。
ここで、最初の質問を次のように変更します。公共の UDDI 運動は終わったのでしょうか、それとも生きていたのでしょうか?
どう思いますか？答えが「いいえ」の場合、既存のパブリック UDDI UBR の例を挙げていただけますか?
パブリックUDDIは確かに死んでいますが、企業内のプライベートレジストリでなんとか生き残りました。
UDDIレジストリの機能的な目的は、Webサービスに関するデータとメタデータの表現です。パブリックネットワークまたは組織の内部インフラストラクチャ内で使用するレジストリは、Webサービスを分類、カタログ化、および管理するための標準ベースのメカニズムを提供し、他のアプリケーションでWebサービスを検出して使用できるようにします。
これは定義と目的にとって悪いことではありませんが、残念ながらWebレベルで適用されました。
UDDIは、Webサービスの「イエローページ」であると想定されていました。特定の機能を提供するWebサービスを見つけたい場合は、UDDI内で検索します。
アイデアは、SOAビジネスコンポーネント間のオンライン相互作用に標準（ユニバーサル）メカニズムを使用することでした。次に、サービスを動的に検索し、それらに接続して、自動的にビジネスを行います。また、同様のサービスを選択する決定は、UBRで見つかったメタデータ（すべてが採用を思いとどまらせる非常に複雑なモデル内にある）に基づいて行われることになっており、サービスが実際に期待どおりに機能したかどうかを確認する方法はありません。 。
しかし、ビジネスは非常に異質であるため、すべてのやり取りを共通の基盤にすることは不可能でした。そして、ビジネスは依然として人、人間の活動、人間の決定を中心に展開しています。
取引は、徹底的な分析と交渉の後にのみ相互に取引を行うことを選択したパートナー間で行われ、最終的に取引を成立させ、すべての条件に同意します。そうして初めて、それらのインフラストラクチャが接続されます。そして、この時点で、UDDI定義は意味をなし始めます。これは、エンタープライズ内でUDDIを使用すると次のことができるためです。
..しかし、これらすべては、機能が十分に確立され、合意されている、事前に決定されたサービスの限定されたセット内にあります。
私の最初の質問、私のコメントの 1 つで、 John Saundersから回答を受け取りました。彼は正しいと思います。
要約すると：
IBM、Microsoft、および SAP のパブリック レジストリがUDDI ムーブメントだったため、パブリック UDDI ムーブメントは死んでいます。
UDDI は確かに死んでいます。3つのことがそれを殺しました：
UDDI ブローカが動的にサービス プロバイダを選択する場合、サービスのセキュリティについてデュー ディリジェンスを行う機会はありません。そして、ブローカーは私のためにセキュリティを確保するためにどれだけの手間をかけますか? 多くはありません、私はお勧めします。
Web サービスは一般に、ファイアウォールの内側で SOA の目的で使用され、アプリケーションをビジネス パートナーと統合し、よく知られた API を呼び出します。UDDI は、これらの目的には完全にやり過ぎです。大規模な組織には Web サービスのカタログが必要ですが、それは wiki ページのように単純なものでもかまいません。潜在的に有用な Web サービスを探している開発者は、その機能についての 1 つの段落の説明、連絡先担当者、およびいくつかの WSDL と技術文書を必要とします。そのためにUDDIは必要ありません。