Descubrimiento de servicios web en WCF: Ws-Discovery o UDDI?

Question

Conozco la distinción entre UDDI y Ws-Discovery (ubicación bien conocida para buscar un servicio frente a la transmisión). Pero mi pregunta es: ¿cuál es la forma más sencilla de descubrir un servicio web en WCF? Por simple me refiero a lo que ya está implementado en WCF y se puede utilizar ahora? No he visto ninguna implementación incorporada en WCF para UDDI o Ws-Discovery.

¿Tiene algún enlace o experiencia para compartir sobre estos dos protocolos en WCF?

ACTUALIZACIÓN

Ahora estoy pensando en tres soluciones, a la espera de WS-descubrimiento de .NET 4.0, o tal vez la creación de la unión con el Peer to Peer unión proporcionada por WCF mi propio descubrimiento. De esta manera puedo transmitir una solicitud. O usando la implementación proporcionada por el enlace de eed3si9n.

Creo que haré una interfaz de puerta de enlace para cambiar fácilmente la implementación más tarde.

Answer 1

.NET 4.0 tendrá WS-Discovery. Ver Messaging enhancements in .NET 4.0: (Discovery Part I)Using WS-Discovery in WCF 4.0. Mientras tanto, Claudio Masieri ha proporcionado una implementación. Ver WS-Discovery for WCF.

También hay una implementación de detección personalizada realizada de forma similar a UDDI. Ver Windows Communication Service Discovery.

Imagine que tiene 200 clientes que usan su funky servicio Wcf.Todos ellos se tener en su archivo de configuración una sección como éste:

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

Ahora, decide cambiar el punto final (lado del servidor) existente por uno nuevo que utiliza SSL para razones de seguridad. ¿Cómo se actualiza a sus clientes ? Puede ver rápidamente que puede convertirse en tedioso. Así que la idea que quiero al detalle aquí es implementar un servicio de localización similar a lo que UDDI hace y utilizar una resolución de metadatos para obtener la configuración fuera del servicio en fin de crear dinámicamente un proxy permitiendo al cliente discutir con el servicio.

Esta persona tiene una preocupación similar a la suya y parece tener una solución de trabajo.

Answer 2

UDDI proporciona un registro central para almacenar información acerca servicios disponibles. Proporciona un catálogo donde los consumidores de pueden encontrar servicios que cumplen con sus necesidades. Este directorio similar al de la libreta permite a los consumidores encontrar servicios por nombre, dirección, contrato, categoría o por otros datos. Se puede pensar en UDDI como el DNS de los servicios web.

Por otro lado, WS-Discovery proporciona un protocolo para descubrir servicios que van y vienen desde una red. Como un servicio se une a la red , informa a sus pares de su llegada transmitiendo un mensaje de saludo ; Del mismo modo, cuando los servicios caen fuera de la red, emiten un mensaje de alerta . WS-Discovery no confía en un solo nodo para alojar información sobre todos los servicios disponibles como lo hace UDDI . Por el contrario, cada nodo remite información sobre los servicios disponibles de forma ad hoc. Esto reduce la cantidad de infraestructura de red necesaria para descubrir servicios y facilita el arranque.

Cita de: http://travisspencer.com/blog/2007/09/post.html

Aquí hay una buena lista de propiedades: http://laflour.spaces.live.com/Blog/cns!7575E2FFC19135B4!728.entry

Answer 3

jUDDI tiene un cliente .NET que puede usar. Simplifica en gran medida varias cosas para trabajar con UDDI.

Por experiencia, solo hay dos o tres implementaciones en funcionamiento de WS-Discovery.

• Apache CXF, pero sólo cuando corrió fuera de un contenedor
• Este: https://code.google.com/p/java-ws-discovery/ que no funciona en Jboss y sin mantenimiento es
• Microsoft .NET 4.0ish

que UDDI puede acceder desde cualquier cosa. Hay muchas implementaciones de cliente y servidor. (Sólo el material de la versión 3 está aquí)

• IBM WS-Registro
• Apache jUDDI
• Microsoft UDDI v3 con Biztalk (es gratis con el servidor 2008)
• HP SOA/Systinet o lo que es llama ahora
• WSO2 tiene algo
• ebXML tiene algún tipo de puente o un adaptador de

Incluso hay un punto final REST para UDDI3 (jUDDI 3.2 lo tiene, respuestas XML o JSON) que abre esto a muchas más posibilidades.

Además, los datos que se pueden compartir con WS-Discovery son algo limitados en comparación con los datos prácticamente ilimitados que puede adjuntar a UDDI.

Eso es solo mis 2 centavos.