Descubrimiento de servicios web en WCF: ¿Ws-Discovery o UDDI?
Pregunta
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.
Solución
.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.
Otros consejos
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
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.