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

Question

Conozco la distinción entre UDDI y Ws-Discovery (conozco bien la ubicación 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 más simple me refiero a lo que ya está implementado en WCF y se puede usar ahora. No he visto ninguna implementación integrada en WCF para UDDI o Ws-Discovery.

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

UPDATE

Ahora estoy pensando en tres soluciones, esperando WS-discovery en .NET 4.0, o tal vez creando mi propio enlace de descubrimiento con el enlace Peer to Peer proporcionado por WCF. De esta manera puedo transmitir una solicitud. O utilizando 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 posterior.

Answer 1

.NET 4.0 tendrá WS-Discovery. Ver Mejoras de mensajería en .NET 4.0: (Discovery Part I) Uso de WS-Discovery en WCF 4.0 . Mientras tanto, Claudio Masieri ha proporcionado una implementación. Consulte WS-Discovery for WCF .

También hay una implementación de descubrimiento personalizada realizada de manera similar a UDDI. Consulte Descubrimiento del servicio de comunicación de Windows .

  

Imagine que tiene 200 clientes usando   su funky servicio Wcf. Todos ellos   tener en su archivo de conf una sección como   este:

<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, decides cambiar el existente   punto final (lado del servidor) con uno nuevo   que usa SSL por razones de seguridad. Cómo   ¿actualizas a tus clientes? Usted puede   ver rápidamente que puede convertirse   tedioso. Entonces la idea que quiero detallar   aquí es para implementar un descubrimiento   servicio similar a lo que hace UDDI y   utilizar un solucionador de metadatos para obtener el   configuración fuera del servicio en   para crear dinámicamente un proxy   permitiendo que el cliente discuta con   el servicio.

Esta persona tiene una preocupación similar a la tuya y parece tener una solución que funciona.

Answer 2

  

UDDI proporciona un registro central para   almacenar información sobre disponible   servicios. Suministra un catálogo donde   los consumidores pueden encontrar servicios que cumplan   sus necesidades. Esta guía telefónica   directorio de información permite   consumidores para 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   de una red. Como un servicio se une   la red, informa a sus pares de   su llegada transmitiendo un Hola   mensaje; Del mismo modo, cuando los servicios caen   fuera de la red multicast un adiós   mensaje. WS-Discovery no se basa en   un solo nodo para alojar información   acerca de todos los servicios disponibles como UDDI   hace. Más bien, cada nodo reenvía   información sobre servicios disponibles   de manera ad hoc. Esto reduce   la cantidad de infraestructura de red   necesario 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 enormemente varias cosas para trabajar con UDDI.

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

• Apache CXF, pero solo cuando se ejecuta fuera de un contenedor
• Este: https://code.google.com/p/java- ws-discovery / que no funciona en Jboss y no se mantiene
• Microsoft .NET 4.0ish

UDDI puede acceder desde cualquier cosa. Hay muchas implementaciones de cliente y servidor. (Solo las cosas de la versión 3 se enumeran aquí)

• IBM WS-Registry
• Apache jUDDI
• Microsoft UDDI v3 con Biztalk (es gratis con el servidor 2008)
• HP SOA / Systinet o como se llame ahora
• WSO2 tiene algo
• ebXML tiene algún tipo de puente o adaptador

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.