API de consulta para el registro UDDI Versión 3
La API de consulta proporciona cuatro formas de consulta que siguen ampliamente los convenios utilizados que cubren las necesidades de software que generalmente se utilizan en los registros.
- Patrón de navegación
- Patrón de profundización
- Patrón de invocación
- Funciones de consulta de API
Patrón de navegación del registro UDDI
Software que se utiliza para explorar y examinar datos, específicamente los datos jerárquicos, requiere posibilidades de navegador. El patrón de navegación generalmente requiere que se comience por una información general, se realice una búsqueda, se busque los conjuntos de resultados generales y luego se seleccione una información algo más específica que filtrar.
Las especificaciones de la API de UDDI acomodan el patrón de navegación mediante las llamadas a la API find_xx. Estas llamadas constituyen las posibilidades de búsqueda que proporciona la API. Estas llamadas se contrastan con los mensajes de retorno resumidos que devuelven información general acerca de la información registrada que se ha asociado al tipo de mensaje de consulta y al criterio de búsqueda especificado en la consulta.
Una sentencia de navegación típica sería buscar si hay información registrada acerca de una empresa que conoce. Esta secuencia empezaría con una llamada a find_business, probablemente pasando los primeros caracteres de un nombre de empresa que conoce. Esta acción devuelve un resultado businessList. Este resultado es una información general que incluye claves, nombres y descripciones, derivados de la información businessEntity registrada que coincide con el fragmento de nombre que ha proporcionado. Si se encuentra la empresa que busca en esta lista, puede utilizar la llamada a la API find_service para filtrar la información de businessService correspondiente y buscar modelos técnicos específicos como, por ejemplo, compra o envío. Del mismo modo, si conoce la huella digital, es decir, la firma tModel, de una interfaz de software concreta y desea ver si la empresa que está buscando proporciona un servicio web que dé soporte a dicha interfaz, puede utilizar el mensaje de consulta find_binding.
Patrón de profundización del registro UDDI
Cuando tiene una clave para uno de los cuatro tipos de datos principales gestionados mediante un registro UDDI, puede utilizar esta clave para acceder a la información detallada registrada de una instancia de datos específica. Los tipos de datos UDDI son businessEntity, businessService, bindingTemplate y tModel. Puede acceder a la información registrada completa para cualquiera de estas estructuras pasando un tipo de clave relevante a una de las llamadas a la API get_xx.
Continuando el ejemplo de la sección anterior, uno de los elementos de datos que devuelven todos los conjuntos de retorno find_x es información de clave. En el caso de la empresa en la que teníamos un tipo de interés, el valor businessKey devuelto en el contenido de una estructura businessList se puede pasar como un argumento para get_businessDetail. La devolución correcta de este mensaje es un mensaje businessDetail que contiene la información completa registrada para la entidad cuyo valor clave se ha pasado. Esta información será una estructura businessEntity completa.
Patrón de invocación del registro UDDI
Para que una aplicación pueda beneficiarse de un servicio web remoto que otra entidad o empresa ha registrado en el registro UDDI, debe preparar la aplicación para que utilice la información que aparece en el registro para el servicio específico que se está invocando.
Los datos bindingTemplate que se obtienen del registro UDDI representan los detalles específicos acerca de una instancia de un tipo de interfaz determinado, incluida la ubicación en la que se un programa comienza a interactuar con el servicio. La aplicación o programa que realiza la llamada almacena en la memoria caché esta información y la utiliza para ponerse en contacto con el servicio en la dirección registrada cuando la aplicación que efectúa la llamada necesite comunicarse con la instancia del servicio.
En las tecnologías de procedimientos populares en el pasado, las herramientas automatizaban las tareas asociadas a la información de almacenamiento en memoria caché, codificación o ubicación. No obstante, existían problemas cuando un servicio remoto se trasladaba y los que efectuaban llamadas no lo sabían. Hay muchos motivos por los que un servicio remoto tiene que trasladarse, por ejemplo, porque se ha actualizado el servidor, por una recuperación ante siniestro, por una adquisición de servicio o por un cambio de nombre de la empresa.
Cuando una llamada no se ejecuta correctamente utilizando la información almacenada anteriormente en la memoria caché y que se ha obtenido del registro UDDI, el comportamiento correcto es consultar en el registro UDDI la información más reciente sobre bindingTemplate. Si los datos devueltos son diferentes de la información almacenada en la memoria caché, la invocación del servicio intenta volver a invocarla utilizando la información reciente. Si el resultado de este reintento es correcto, la nueva información sustituye a la información almacenada en la memoria caché.
Si se utiliza este patrón con los servicios web, una empresa que utilice el registro UDDI puede automatizar la recuperación de un gran número de patrones sin los costes excesivos que suponen las comunicaciones excesivas y su coordinación. Por ejemplo, si una empresa ha activado un sitio de recuperación ante siniestro, la mayor parte de las llamadas de los asociados no se ejecutan correctamente cuando intenten invocar los servicios del sitio que ha dado error. Al actualizar la información UDDI con la nueva dirección para el servicio, los asociados que utilizan el patrón de invocación automáticamente localizarán la nueva información de servicio y se recuperarán sin que sea necesaria ninguna acción de administración adicional.