2009-03-15 1 views
9

私は、UDDIとWs-Discovery(サービスとブロードキャストを検索する場所をよく知っています)の違いを知っています。しかし、私の質問は:WCFのWebサービスを発見する最も簡単な方法は何ですか?最も簡単なことは、WCFで既に実装されているものを意味し、今すぐ使用できますか? UDDIまたはWs-Discovery用のWCFのビルトイン実装は見たことがありません。WCFでのWebサービスの検出:Ws-DiscoveryまたはUDDI?

WCFでこれらの2つのプロトコルに関するリンクや経験がありますか?

UPDATE

さて、私は、約3ソリューションを考えて、.NET 4.0でWS-発見を待っている、または多分WCFが提供するバインディングピアツーピアと結合自分自身の発見を作成しています。こうして、私はリクエストをブロードキャストできます。 またはeed3si9nのリンクで提供される実装を使用してください。

私は後者の実装を簡単に変更するためにゲートウェイインターフェイスを行うと思います。

+1

私はWebサービスの発見がまだ価値がないとは思っていません。これは単に、それが役に立つシナリオを見たことがないことを意味するかもしれません。私はあなたのシナリオを分かち合うことができれば興味があります - あなたは良いシナリオを見つけたかもしれません。 –

+0

こんにちはJohn、私はサービスに「話す」複数の端末を持っています。しかし、バインディングやサーバを変更した場合、メインテナンスの悪夢につながるので、端末の特定のエンドポイント+バインディングへのアプリケーションの設定ファイルには参照が必要ではありません。 –

+0

「メンテナンスの悪夢」?私たちは、ここで "n"のXMLファイルを更新することを話しています!私はそれを悪夢と呼ぶことはほとんどありません。 –

答えて

3

.NET 4.0 WS-ディスカバリーを持つことになります。 Messaging enhancements in .NET 4.0: (Discovery Part I)Using WS-Discovery in WCF 4.0を参照してください。その間、Claudio Masieriは実装を提供しました。 WS-Discovery for WCFを参照してください。

UDDIと同様の方法でカスタム検出を実装しています。 Windows Communication Service Discoveryを参照してください。

ファンキーなWcfサービス を使用して200のクライアントがあるとします。あなたがSSLを使用して新しいもの で既存の エンドポイント(サーバー側)を変更することを決定し、今

<client> 
    <endpoint configurationName="default" 
       address="http://localhost/servicemodelsamples/service.svc" 
       binding="wsHttpBinding" 
       bindingConfiguration="Binding1" 
       contract="IDataContractCalculator" /> 
</client> 
<bindings> 
    <wsHttpBinding> 
     <binding configurationName="Binding1" /> 
    </wsHttpBinding> 
</bindings> 

:彼らはすべての は彼らのconfファイルに のようなセクション、このいずれかを持っていますセキュリティ上の理由どのように クライアントを更新しますか? すぐにそれが 退屈になることができます参照してくださいすることができます。だから私はここでは詳しく にしたいという考えは、動的にクライアントを許可するプロキシ を作成するために ために、サービスのうち、 コンフィギュレーションを取得するには、メタデータのリゾルバを使用することを発見 UDDIが何に似たサービスと を実装することですサービスを と話し合う。

このユーザーはあなたと同様の懸念を抱いており、解決策があるようです。

2

UDDIは、利用可能な サービスに関する情報を に保存する中央レジストリを提供します。 の消費者は、 のニーズを満たすサービスを見つけることができるカタログを提供しています。この電話帳のような ディレクトリの情報は の消費者が の住所、契約、カテゴリ、または その他のデータによって名前でサービスを見つけることを可能にします。 UDDIは、WebサービスのDNSとして と考えることができます。一方、WS-Discovery は、 をネットワークから受信する サービスを検出するためのプロトコルを提供します。サービスが ネットワークに参加すると、 というメッセージをブロードキャストして、そのピアの到着を に通知します。同様に、サービスがネットワークから離れて をドロップすると、彼らはBye メッセージをマルチキャストします。 WS-Discoveryは、UDDI のように、利用可能なすべてのサービスについて 情報をホストする単一のノードを に依存しません。むしろ、各ノードは、 の利用可能なサービスに関する情報をアドホックな方法で転送する( )。これにより、 ネットワークインフラストラクチャの量が減少し、 はブートストラップを容易にします。

引用から:ここでhttp://travisspencer.com/blog/2007/09/post.html

は、特性の良好なリストである: http://laflour.spaces.live.com/Blog/cns!7575E2FFC19135B4!728.entry

+0

私はすでに知っていますが、WCFではWS-DiscoやUDDIを使う方が簡単だと分かりますか? WCFでこれらのプロトコルを使用するリンクや経験はありますか? –

+0

悲しいことに、私はUDDIの経験が限られています。 私はCodeprojectに関する詳細な記事を見つけましたが、あなたもそれを創設したと思います。 (http://www.codeproject.com/KB/WCF/uddiservicefactory.aspx) – boj

+0

私はそれを使用しようとします、私はWS-Discoが私のユースケースの方が良いと思っています(私は "中央"サーバー)、UDDIは何よりも優れています(つまり、239023802XML構成を構成します)。ありがとう –

0

jUDDIには、使用できる.NETクライアントがあります。 UDDIを使用するための多くの作業が大幅に簡素化されます。

経験上、WS-Discoveryの実装は2〜3つしかありません。

  • のApache CXFが、外側のコンテナ
  • のこの1を実行したときにのみ:JBossで働くとMicrosoftの.NET 4.0ish

UDDIあなた

  • メンテナンスされていないですしない https://code.google.com/p/java-ws-discovery/何でもアクセスできます。多くのクライアントとサーバーの実装があります。 BizTalk(2008サーバーとの自由)
  • HP SOA /にSystinetまたは何でもそれだと(わずか3のものがここに記載されているバージョン)

    • IBM WS-レジストリ
    • のApacheのjUDDI
    • マイクロソフトUDDI v3の何か
    • WSO2今していると呼ばれる
    • のebXMLは、ブリッジまたはアダプタのいくつかの種類があり

    UDDI3用のRESTエンドポイントもあります(jUDDI 3.2にはXML、JSONの応答があります)。これにより、これまで以上に多くの可能性が開かれます。

    さらに、WS-Discoveryで共有可能なデータは、UDDIに添付できる実質的に無制限のデータに比べていくぶん限定されています。

    これはちょうど私の2セントです。

  • 関連する問題