Service Registry con Capacidad de búsqueda avanzada, Parte 1: Conceptos, proceso y componentes

Sepa por qué necesita la capacidad de búsqueda avanzada en un registro

En esta Parte 1 de la serie conocerá cuáles son los motivos que exigen capacidad de búsqueda avanzada en un registro de servicios/servicios web SOA. Los registros actualmente disponibles no suministran esta capacidad de búsqueda avanzada, los cuales se basan en UDDI o en otros esquemas (por ej. WSRR). En este artículo, conocerá el proceso conceptual básico y los componentes de software que se requerirán para implementar dicha capacidad avanzada. En la Parte 2 de esta serie aprenderá cómo implementar este proceso conceptual y los componentes de software asociados.

Dr. Waseem Roshen, Master IT Architect, IBM  

Waseem RoshenEl Dr. Waseem Roshen obtuvo su doctorado en la Universidad del Estado de Ohio, Columbus, Ohio (Estados Unidos) y cuenta con más de 18 años de experiencia práctica en el campo de la Tecnología Informática (TI). Actualmente trabaja como IT Architect en el Centro de Excelencia Enterprise Architecture and Technology de IBM. Tiene amplia experiencia en el ámbito de la computación distribuida, incluyendo arquitectura orientada a servicios (SOA). Además, su experiencia abarca el desarrollo personalizado, la arquitectura de integración y J2EE (ahora conocida como JEE). En la actualidad, el Dr. Roshen se dedica a SOA y servicios web, computadoras Quantum y cloud computing. Publicó más de 60 artículos, registró 37 patentes y es miembro de IEEE y de la Sociedad de Computación IEEE. Es autor único del libro “SOA-Based Enterprise Integration: A step-by-step guide to services-based application integration” [Integración empresarial basada en SOA: Guía paso a paso para la integración de aplicaciones basadas en servicios].



05-08-2011

Introducción

Service Registry es un importante componente de la Arquitectura orientada a servicios (SOA). El registro se usa para publicar servicios nuevos y para descubrir los servicios existentes. La información que se puede publicar y descubrir incluye información sobre interfaces de servicios así como información sobre implementaciones de servicios específicas como la dirección (URL) de la implementación específica. La información sobre interfaces de servicios incluye las firmas de diferentes operaciones del servicio, el tipo de mensaje como SOAP, y el protocolo de comunicaciones como HTTP.

Descubrimiento, descripción e integración universal (UDDI) es un estándar industrial en el cual se puede basar un Registro ya que describe estándares para publicar y descubrir servicios. Además de otras facilidades, UDDI incluye dos interfaces API para publicar y descubrir información de servicios. En este artículo nos focalizamos en la función de descubrimiento del Registro. La interfaz API de descubrimiento suministrada por UDDI incluye métodos como getServiceDetails que devuelve los detalles de la interfaz e implementación de servicio mediante la entrada de una ID de servicio.

Sin embargo, a diferencia de otros servicios web estándares como XML, WSDL y SOAP, UDDI no ha sido adoptado tan ampliamente en la industria. Esto se debe principalmente a que se comprobó que las interfaces API incluidas en UDDI son demasiado engorrosas de usar. IBM particularmente adoptó una ruta de acceso diferente. El producto de registro, WebSphere Registry and Repository (WSRR) IBM, no usa las interfaces API de UDDI para la publicación y el descubrimiento de servicios. En cambio WSRR usa expresiones XPath para encontrar los servicios que se publicaron anteriormente. La consulta de XPath toma como entrada el nombre del servicio. En el Listado 1 se muestra un ejemplo de XPath. La consulta de XPath que aparece en el Listado 1 se usa para encontrar la descripción de servicio de un servicio llamado TickerService.

Listado 1. Ejemplo de consulta de XPath
/WSRR/WSDLService[@name='TickerService']

Necesidad de capacidad de búsqueda avanzada

En estos dos enfoques (UDDI y WSRR) el nombre de la ID del servicio usado en la consulta (o búsqueda) como entrada debe coincidir exactamente con el nombre o la ID del servicio existente en el registro de servicio. Es sumamente aconsejable que esta restricción sea flexible por los siguientes motivos:

  • Una de las metas de los servicios web y de la Arquitectura orientada a servicios (SOA) es independizar todo lo posible al proveedor del servicio del consumidor del servicio. Como nexo al momento del desarrollo, el consumidor del servicio por lo general es un programador o desarrollador que escribe una aplicación de cliente, en tanto que el proveedor del servicio es otro programador o desarrollador que desarrolla un servicio. Como el programador o desarrollador del consumidor sólo puede descubrir una descripción de servicio (incluyendo interfaz del servicio y detalles de la implementación específica) a través de un registro, si él/ella conoce la clave o el nombre exacto, necesitará comunicarse directa o indirectamente con el programador o desarrollador del proveedor del servicio, generando así un fuerte nexo entre los desarrolladores del proveedor del servicio y los del consumidor del servicio.
  • Una posible manera de solucionar esta cuestión, es que el programador o desarrollador del consumidor del servicio trate de adivinar el nombre del servicio. Sin embargo, adivinar la clave o el nombre exacto de un servicio, sin una comunicación directa con el proveedor del servicio, se complica por el hecho de que el uso de palabras difiere según las distintas localizaciones. Por ejemplo, la palabra elevator (ascensor) comúnmente usada en los Estados Unidos, se reemplaza por la palabra lift en el Reino Unido. Además, aún en la misma localización, se pueden usar alternativamente distintas palabras con el mismo significado. Por ejemplo, para la palabra comúnmente usada get (conseguir) se puede usar también la palabra fetch (ir a buscar) o la palabra obtain (obtener). Así mismo, en lugar de la palabra comúnmente usada car (auto), se puede usar también la palabra automobile (automóvil) o la palabra vehicle (vehículo).
  • La incapacidad de adivinar el nombre o la clave, y por lo tanto descubrir la definición del servicio, habitualmente implica que el programador del consumidor del servicio no pueda incorporar el servicio en su código hasta tanto el programador del proveedor del servicio complete su tarea en el servicio e informe directa o indirectamente al programador del lado del cliente sobre la clave o el nombre específico que eligió para que el servicio registre al servicio en un registro. Esto normalmente provocará demoras en el desarrollo de las aplicaciones del consumidor o del cliente para un determinado servicio.
  • La capacidad de descubrir una definición de servicio sin saber la clave o el nombre exacto también promoverá la portabilidad de las aplicaciones del cliente o consumidor. Como ejemplo, tomemos a concesionarias de autos de diferentes marcas como GM, Ford, Toyota, Mazda, etc. Supongamos que cada una de estas marcas desarrolla un servicio para obtener el precio de un auto. Cada uno nombra a este mismo servicio de una manera obvia, pero levemente diferente, usando nombres como getCarPrice (conseguirPrecioAuto), getVehiclePrice (conseguirPrecioVehículo), getAutomobilePrice (conseguirPrecioAutomóvil), obtainCarPrice (obtenerPrecioAuto), etc. Estos nombres diferentes para esencialmente el mismo servicio significa que se necesitarán aplicaciones de consumidor individuales para cada una de las concesionarias de las diferentes marcas que usen los registros actuales, pero si el registro es capaz de reconocer que todos estos nombres se refieren al mismo servicio, podrá devolver la definición del servicio, aunque el nombre en el registro y en la aplicación del cliente no coincidan exactamente, por lo tanto sólo se necesita desarrollar una aplicación de consumidor con cualquiera de los nombres obvios y podrá servir para las concesionarias de todas las marcas.
  • También es importante tener en cuenta que, con respecto a la consulta sobre información del servicio de tiempo de ejecución, como dirección IP y nombre de puerto, puede haber varios proveedores de servicios para un determinado servicio. Cada uno de estos proveedores de servicios puede llamar al mismo servicio de maneras levemente diferentes. En este caso la capacidad de descubrir el servicio sin saber el nombre exacto del mismo resultará muy útil.

Método y proceso

Habiéndonos convencido de la necesidad de contar con un registro de servicios con la capacidad de búsqueda avanzada, de manera tal que pueda reconocer nombres similares de un determinado servicio; ahora describiremos el método que se puede usar para habilitar esta capacidad en un registro.

El método involucra primero desglosar las diferentes palabras que componen el nombre del servicio de entrada usando un componente analizador. Por ejemplo, el analizador descompondrá el nombre del servicio getCarPrice en palabras individuales (get, Car, y Price). Luego el registro usa un componente de diccionario (interno o externo) para construir listas de sinónimos para cada palabra que compone el nombre. Para el ejemplo anterior, se construirán tres listas de sinónimos correspondientes a las palabras get, car, y price. Con respecto a la palabra get la lista de sinónimos puede estar compuesta por las palabras get, obtain, y fetch. Así mismo, con respecto a la palabracarla lista de sinónimos puede estar compuesta por las palabras car, automobile, y vehicle. Después de construir la lista de sinónimos, se utiliza el componente de composición de nombre del servicio para integrar estas palabras en el orden correcto con el fin de obtener todos los nombres posibles del servicio. En el caso del ejemplo anterior, estos nombres incluirán getCarPrice, obtainCarPrice, fetchCarPrice, getAutomobilePrice, obtainAutomobilePrice, y fetchAutomobilePrice. En el paso siguiente, se verifica cada nombre de servicio compuesto para corroborar que coincida con el registro del servicio. Si alguno de los nombres coincide con un nombre en el registro, el sistema devuelve al usuario la descripción de ese servicio, aún cuando el nombre del servicio no coincida con el nombre original suministrado por el usuario del registro. En la Figura 1 se muestran los destalles del proceso de este método para un sistema de registro avanzado.

Figura 1. Flujo de proceso para registro con capacidad de búsqueda avanzada
Flujo de proceso para registro con capacidad de búsqueda avanzada

Componentes requeridos

El proceso que se muestra en la Figura 1 requiere cuatro componentes de software básicos para el sistema de registro avanzado. Estos cuatro componentes y sus interacciones se resumen en la Figura 2.

Figura 2. Componentes requeridos para registro con capacidad de búsqueda avanzada
Componentes requeridos para registro con capacidad de búsqueda avanzada

A continuación se describe brevemente las funciones de cada uno de estos componentes.

Registro clásico

Este componente brinda tres funciones: (1) Publicación de servicios nuevos. Esta publicación equivale a la entrada de un libro nuevo en el catálogo de la biblioteca al momento en que se recibe. (2) Búsqueda de un servicio mediante un nombre o ID determinado. (3) Administración de servicios después de haber sido implementados. En este contexto, la capacidad de búsqueda por nombre es la función más importante que vamos a usar. En otras palabras, el registro clásico toma el nombre como entrada y devuelve como salida la descripción y otras características del servicio, si existe un servicio con ese nombre exacto en el registro. Es decir, si se publicó anteriormente en el registro un servicio con ese nombre exacto. El registro WSSR actualmente tiene esta función incorporada.

Analizador de nombre

Este componente toma como entrada el nombre del servicio que generalmente está compuesto por varias palabras, y devuelve una lista de palabras que componen ese nombre. Por ejemplo, si el nombre de entrada es getCarPrice, la salida contendrá las siguientes palabras get, car, y price.

Compositor de nombre

Este componente brinda una función opuesta a la del componente de analizador de nombre, toma como entrada una lista de palabras y las combina en el orden correcto suministrando un nombre de servicio posible. Por ejemplo, la entrada podría contener las siguientes palabras get, car, y price. Entonces la salida podría ser el nombre de servicio getCarPrice.

Diccionario

El diccionario, en el contexto actual, es un componente que toma una palabra como entrada. La salida del diccionario es una lista de palabras que tienen un significado parecido o similar a la palabra original. Por ejemplo, si la entrada es la palabra get, entonces la salida podría contener las siguientes palabras get, fetch, y obtain.


Conclusión

Conoció los motivos por los cuales se necesita una capacidad de búsqueda avanzada en un registro SOA. Particularmente, queremos un registro SOA que pueda reconocer nombres similares de los servicios y luego devolver al usuario información sobre desarrollo y el tiempo de ejecución del servicio aún cuando no haya una coincidencia exacta para los nombres del servicio en el registro. Además, conoció el proceso que necesitará para implantar dicha capacidad avanzada. Por último, aprendió acerca de los cuatro componentes de software que serán necesarios. En la siguiente entrega, la Parte II de esta serie, aprenderá cómo implantar estos cuatro componentes.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=475712
ArticleTitle=Service Registry con Capacidad de búsqueda avanzada, Parte 1: Conceptos, proceso y componentes
publish-date=08052011