Pregunta

¿RESTFUL WebServices tiene registros de servicio como el UDDI? ¿O UDDI también puede mantener los servicios web RESTful?

¿Fue útil?

Solución

UDDI se puede utilizar para servicios REST. WSDLS se puede utilizar para describir los servicios web HTTP, pero, francamente, creo que no es una combinación real para una arquitectura de recursos de descanso.

En el nivel más básico, UDDI es simplemente mapeo de atributos a los puntos finales de servicio. Entonces, si simplemente está buscando un sistema que pueda hacer eso, entonces UDDI se ajustará a la factura.

UDDI no es popular en Internet salvaje y amplio, pero se usa "detrás de escena" como componente de orquestación.

Como mencionó Darrel, DNS es otro mecanismo de descubrimiento válido.

Mi queja personal con DNS es simplemente que, aunque DNS tiene todas las ventajas que se mencionan en el artículo que cita, la desventaja es que DNS es una parte tan crítica del tejido de la red, tiende a no estar disponible para los desarrolladores. Por lo general, las personas de las operaciones de red (que tienden a ser más notorias que incluso los DBA) tienen infraestructura como DNS bastante cerca. Finalmente, si bien DNS es bastante capaz de estas tareas, en muchos casos la configuración predeterminada estándar y la implementación de DNS pueden necesitar cambiarse. Por ejemplo, hemos comenzado a servir certificados de DNS, por ejemplo, y tuvimos que habilitar TCP para DNS. Nuevamente, esto significó una mayor participación de las operaciones de red.

Además de eso, si bien hay mucha experiencia y conocimiento de DNS en el mundo, el conocimiento y la experiencia de HTTP y "hacer cosas" en un servidor web es mucho mayor. Esa consecuencias de eso simplemente significa que cuando los desarrolladores piensan y buscan algún tipo de solución a este problema, el primer lugar que van a ver es probablemente una solución basada en HTTP.

Entonces, en ese sentido, Uddi es posiblemente una mejor solución, solo en términos de poder implementarlo rápidamente con poca molestia.

Por supuesto, UDDI es un servicio basado en jabón. Eso no es tan importante, de verdad. No es una gran opción para un sistema relajante, pero no es horrible. Funcional, si un poco "impuro".

En cuanto a un registro de servicio basado en HTTP estándar, no hay nada que conozca. Es razonablemente simplemente adhoc uno simplemente con HTML, por ejemplo. El hecho de que Uddi no haya despegado en el mundo en general no es tan limitación o leve contra Uddi. Más bien, es simplemente que la visión de descubrir servicios arbitrarios no se ha concretado realmente, la necesidad simplemente no es del todo allí. Hay mucho más involucrado fuera de la banda con el descubrimiento de servicios más allá de la ubicación y la semántica, como las relaciones comerciales y demás.

Internamente, dentro de la empresa, esa logística se resuelve, por lo que el descubrimiento de servicios tiene valor. En la naturaleza, no tanto.

Otros consejos

No esta muerto;)

  • Firmó un desarrollador de Juddi Juddi.apache.org

EDITAR: También está el descubrimiento de WS compatible con CXF y WCF. Vale la pena echarle un vistazo.

FWIW, UDDIV3 especifica una interfaz REST, sin embargo, no creo que nadie más que Juddi lo haya implementado. Se incluirá con V3.2 y arriba usando CXF, Jettison y WADL. Fuente: http://svn.apache.org/repos/asf/juddi/trunk/juddi-rest-cxf/src/main/java/org/apache/juddi/api/impl/rest/uddiinquiryjaxrs.java

UDDI fue diseñado para servicios de jabón, sin embargo, ni siquiera se usa para aquellos que más. Uddi estaba prácticamente muerto a partir de 2006.

Este El artículo muestra cómo usar DNS para hacer descubrimiento.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top