Web-Service-Discovery in WCF: Ws-Discovery oder UDDI?

Question

Ich kenne die Unterscheidung zwischen UDDI und Ws-Discovery (gut bekannt Ort, um einen Dienst vs Broadcast zu suchen). Aber meine Frage ist: Was ist der einfachste Weg, einen Webservice in WCF zu entdecken? Mit einfachsten meine ich, was ist bereits in WCF implementiert und kann jetzt verwendet werden? Ich habe keine integrierte Implementierung in WCF für UDDI oder Ws-Discovery gesehen.

Haben Sie einen Link oder Erfahrung, um über diese beiden Protokolle in WCF zu teilen?

UPDATE

Jetzt denke ich über drei Lösungen, auf .NET 4.0 für WS-Discovery warten, oder vielleicht meine eigene Entdeckung zu schaffen mit dem Peer-Bindung durch WCF bereitgestellt to-Peer-Bindung. Auf diese Weise kann ich eine Anfrage senden. Oder verwenden Sie die Implementierung über den Link von eed3si9n.

Ich denke, dass ich eine Gateway-Schnittstelle tun werde, um die Implementierung letzter zu ändern.

Answer 1

.NET 4.0 wird WS-Discovery haben. Siehe Messaging enhancements in .NET 4.0: (Discovery Part I)Using WS-Discovery in WCF 4.0. In der Zwischenzeit hat Claudio Masieri eine Implementierung zur Verfügung gestellt. Siehe WS-Discovery for WCF.

Es gibt auch eine benutzerdefinierte Discovery-Implementierung in ähnlicher Weise wie UDDI getan. Siehe Windows Communication Service Discovery.

Stellen Sie sich vor, Sie haben 200 Kunden mit Ihren funky Wcf-Service.Sie würden alle haben in ihrer conf-Datei einen Abschnitt wie diese ein:

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

Jetzt entscheiden Sie, die vorhandene Endpunkt (Server-Seite) zu ändern, um mit einem neuen , die SSL verwendet für Sicherheitsgrund. Wie aktualisieren Sie Ihre Kunden? Sie können schnell sehen, dass es langweilig werden kann. So ist die Idee, die ich hier zum Detail wollen, ist eine Entdeckung Service ähnlich wie das umzusetzen, was UDDI tut und einen Metadaten-Resolver zu verwenden, um die Konfiguration aus dem Dienst in zu schaffen, um dynamisch einen Proxy ermöglicht den Client zu erhalten, besprechen Sie mit den Service.

Diese Person hat ähnliche Bedenken wie Sie und scheint eine funktionierende Lösung zu haben.

Answer 2

UDDI bietet eine zentrale Registrierungs speichern Informationen über verfügbare Dienstleistungen. Es liefert einen Katalog, wo Verbraucher Dienste finden können, die ihre Bedürfnisse erfüllen. Dieses Telefonbuch-ähnliche Verzeichnis von Informationen ermöglichen Verbraucher, um Dienste mit Namen, Adresse, Vertrag, Kategorie oder durch andere Daten zu finden. UDDI kann man sich als DNS von Webdiensten vorstellen.

Auf der anderen Seite, WS-Discovery- bietet ein Protokoll Dienstleistungen zu entdecken, und von einem Netz gehen kommen. Wenn ein Dienst das Netzwerk verbindet, informiert es seine Peers von seine Ankunft durch Senden einer Hello Nachricht; Ebenso, wenn Dienste aus dem Netzwerk fallen lassen, senden sie eine Bye Nachricht per Multicast. WS-Discovery verlässt sich nicht auf ein einzelner Knoten, um Information über alle verfügbaren Dienste zu hosten, wie UDDI tut. Stattdessen gibt jeder Knoten Informationen über verfügbare Dienste in einer Ad-hoc-Weise weiter. Dies reduziert die Menge der Netzwerkinfrastruktur benötigt, um Dienste zu entdecken und erleichtert Bootstrapping.

Zitat aus: http://travisspencer.com/blog/2007/09/post.html

Hier ist eine gute Liste der Eigenschaften: http://laflour.spaces.live.com/Blog/cns!7575E2FFC19135B4!728.entry

Answer 3

jUDDI hat einen .NET-Client, den Sie verwenden können. Es vereinfacht eine Menge Dinge beim Arbeiten mit UDDI.

Aus Erfahrung gibt es nur zwei oder drei funktionierende Implementierungen von WS-Discovery.

• Apache CXF, aber nur, wenn lief außerhalb eines Behälters
• Dieses: https://code.google.com/p/java-ws-discovery/, die nicht in Jboss funktioniert und ist nicht betreut
• Microsoft .NET 4.0ish

UDDI Sie kann von allem zugreifen. Es gibt viele Client- und Serverimplementierungen. (Nur die Version 3 Zeug ist hier aufgelistet)

• IBM WS-Registry
• Apache jUDDI
• Microsoft UDDI v3 mit Biztalk (seinem freien mit 2008-Server)
• HP SOA/Systinet oder was auch immer es ist genannt jetzt
• WSO2 hat etwas
• ebXML hat eine Art Brücke oder Adapter

Es gibt sogar einen REST-Endpunkt für UDDI3 (jUDDI 3.2 hat es, XML- oder JSON-Antworten), was dies für viele weitere Möglichkeiten öffnet.

Darüber hinaus sind die mit WS-Discovery gemeinsam nutzbaren Daten im Vergleich zu den praktisch unbegrenzten Daten, die Sie an UDDI anhängen können, etwas eingeschränkt.

Das sind nur meine 2 Cent.