PROCEDIMIENTO DE GESTIÓN AUTOMÁTICO DE ASOCIACIONES ENTRE SERVICIOS EN UN ENTORNO DISTRIBUIDO.

Procedimiento de gestión de asociaciones entre componentes solicitantes de servicios y componentes proveedores de servicios en un entorno distribuido,

describiéndose dichos componentes, en una etapa de escritura, en un lenguaje de programación objeto, comprendiendo dicho procedimiento las siguientes etapas: - descubrimiento dinámico, por medio de al menos un protocolo de descubrimiento de servicios distribuido, de servicios solicitados, - anuncio, por medio de al menos un protocolo de descubrimiento de servicios distribuido, de servicios proporcionados, y - realización de una conexión entre al menos un componente solicitante de servicios y al menos un componente proveedor de servicios; caracterizado porque dicho procedimiento comprende las siguientes etapas: - en el transcurso de dicha etapa de escritura: • asociación de al menos un componente solicitante de servicios a un archivo declarativo en el que se declaran dichos servicios solicitados, • asociación de al menos un componente proveedor de servicios a un archivo declarativo en el que se declaran dichos servicios proporcionados, integrándose dichos componentes solicitante y proveedor de servicios en una plataforma local (A, B, C) que forma parte del entorno distribuido, - puesta en marcha de dicho componente solicitante de servicios, análisis del archivo declarativo al cual está asociado, identificación de servicios pedidos, y después realización de dicha etapa de descubrimiento dinámico, - puesta en marcha de dicho componente proveedor de servicios, análisis del archivo declarativo al que está asociado, identificación de servicios proporcionados, y después realización de dicha etapa de anuncio, - selección, entre tipos de comunicación disponibles, de un tipo de comunicación que es compatible con el componente solicitante de servicios y el componente proveedor de servicios, - realizándose dicha conexión entre el componente solicitante de servicios y el componente proveedor de servicios con ayuda de un tipo de comunicación compatible identificada

Procedimiento de gestión automático de asociaciones entre servicios en un entorno distribuido.

La presente invención se refiere a un procedimiento de gestión automático de asociaciones entre componentes solicitantes de servicios y componentes proveedores de servicios en un entorno distribuido.

La invención encuentra una aplicación particularmente ventajosa en el campo de las redes domésticas y de pequeñas redes empresariales o también de la red interna de un automóvil, un barco o un satélite.

Es posible en efecto a día de hoy instalar en el domicilio una red doméstica y equipos electrónicos que se conecten a esta red. Estos equipos van del ordenador clásico hasta equipos electrodomésticos (frigorífico, lavavajillas y así sucesivamente) pasando por agendas personales (PDA), teléfonos inteligentes ("smart phones"), equipos audiovisuales (televisión, magnetoscopio, lector de DVD y así sucesivamente). Sobre una pequeña red empresarial, estos equipos son por ejemplo una impresora, un escáner, un telefax, servidores de aplicaciones (mensajería, herramientas empresariales), un visor para presentaciones. Cualquiera que sea el tipo de red, también pueden instalarse sensores o accionadores conectados a esta red.

Por consiguiente, la invención propuesta está destinada a desplegarse sobre equipos electrónicos inteligentes a domicilio, en la empresa o en lugares en los que se utilizan redes locales. En todos los casos, existen tecnologías que permiten a los equipos que requieren servicios descubrir los equipos proveedores de estos servicios e interconectarse. Gracias a la invención, es posible desarrollar aplicaciones independientemente del conocimiento de la tecnología de descubrimiento y de interconexión seleccionada por los equipos.

El procedimiento propuesto por la invención se basa en la noción de Arquitectura Orientada a Servicios, la cual se obtiene de la Programación Orientada al Objeto y de la Programación por Componentes.

Esencialmente, la Arquitectura Orientada a Servicios resulta de la idea de que una aplicación puede considerarse como la composición de servicios. Los servicios son "contratos" que deben respetar los proveedores de servicios. Estos publican su identidad declarando los servicios que pueden ofrecer desde un directorio de servicios, o directamente desde una lista de clientes o solicitantes de servicios descubiertos dinámicamente, o por difusión sobre un canal multidifusión. Los solicitantes de servicios formulan peticiones desde el directorio de servicios, o directamente desde los proveedores de servicios descubiertos dinámicamente, por ejemplo por petición en multidifusión, para conocer y seleccionar el proveedor de servicios adecuado. Para el servicio, el solicitante se relaciona con el proveedor solicitado y puede solicitarle efectuar las acciones propuestas en el "contrato".

Estas arquitecturas se desarrollan normalmente en el paradigma de "Objeto". Los servicios son interfaces. Los proveedores de servicios son objetos obtenidos de clases que implementan estas interfaces. Cada solicitante de servicios puede relacionarse con un proveedor de servicios descubierto de acuerdo con uno de los métodos citados a continuación. Por tanto puede requerir los métodos declarados por la interfaz dirigida al objeto proveedor.

Los objetos proveedores y los objetos solicitantes pueden formar parte de entidades más importantes o estar ellos mismos compuestos por otros objetos más elementales. En esta memoria, los dos objetos solicitantes de servicios o proveedores de servicios se denominan "componentes". Se observará que un componente puede, si procede, ser a la vez demandante de un servicio y proveedor de un (otro) servicio.

La ventaja de las arquitecturas orientadas al servicio es que permiten un acoplamiento laxo entre las entidades que la componen. Estas sólo interaccionan por conocimiento de los servicios definidos de manera genérica. La implementación de estos servicios puede efectuarse, y por tanto proporcionarse, de muchas maneras. Una entidad puede sustituirse fácilmente por otra en este tipo de arquitectura con la única condición de que proporcione los mismos servicios.

Una arquitectura orientada al servicio puede ser distribuida o no. Si es distribuida, las entidades pueden repartirse sobre equipos diferentes. La conexión entre las entidades utiliza por tanto un protocolo de comunicación remota.

En el estado de la técnica se conoce con el nombre "Service Binder" un servicio para automatizar la gestión de las dependencias de los servicios sobre una plataforma Java de servicios no distribuida, denominada OSGi. Este sistema permite adaptar dinámicamente una aplicación a partir de informaciones proporcionadas por los componentes que la constituyen. Las aplicaciones construidas de esta manera pueden ensamblarse y adaptarse de manera dinámica.

Diseñado sobre un modelo de componentes OSGi, el Service Binder automatiza el descubrimiento de servicios y la conexión entre componentes desplegados sobre la plataforma OSGi. A cada componente se le asocia un archivo descriptivo de servicios suministrados y solicitados que analiza el Service Binder. Este análisis permite la adaptación automática de cada componente a la evolución de la composición de la plataforma: salida o instalación de nuevos componentes, registro o supresión de servicios.

Es importante observar que este sistema está adaptado a la construcción de aplicaciones no distribuidas. Esto hace que la plataforma de servicios OSGi sea en si misma no distribuida.

Por otro lado, también se conocen tecnologías que pueden utilizarse en un entorno informático distribuido.

Se conoce así, por ejemplo, la tecnología propuesta en la solicitud WO 01/86419 a nombre de SUN MICROSYSTEMS. De acuerdo con el procedimiento de descubrimiento de servicios descrito por esta solicitante, un "cliente" emite una petición incluyendo criterios de búsqueda, después se comparan los criterios de búsqueda con los ofrecimientos de los servicios en el entorno distribuido y después el cliente recibe mensajes que indican los ofrecimientos de los servicios que obedecen a sus criterios de búsqueda. Las peticiones y los ofrecimientos de los servicios se expresan en un lenguaje de representación de datos adecuado, por ejemplo, el lenguaje XML ("eXtensible Markup Language"). Se observará, que para poder aplicar el descubrimiento de servicios remotos y su utilización de acuerdo con la solicitud WO 01/86419, es necesario que un desarrollador asociado al "cliente" escriba y envíe una serie de mensajes (que requiere métodos de una interfaz dedicada designada "API layer 102"). Por tanto, esta tecnología requiere obligatoriamente una intervención humana durante la ejecución.

El artículo de P. Grace, G.S. Blair y S. Samuel "A Reflective Framework for Discovery and Interaction in Heterogeneous Mobile Environments" (ACM Sigmobile Mobile Computing and Communications Review, vol. 9(1), páginas 2 a 14, enero de 2005) aborda el problema de la interoperabilidad entre los protocolos existentes y propone una plataforma denominada "ReMMoC" (iniciales de las palabras en inglés "Reflective Middleware to Support Mobile Client Operability").

Si la tecnología ReMMoC resuelve el problema de compatibilidad entre diferentes tecnologías de descubrimiento de servicio y entre diferentes tecnologías de comunicación remota, no trata el problema de la automatización de la gestión de dependencias de servicios, y la aplicación de ReMMoC para cualquier búsqueda de servicios requiere la intervención de un desarrollador.

Además, ReMMoC no presenta la posibilidad de no utilizar más que llamadas a métodos locales cuando una misma máquina proporciona los servicios, mientras que las llamadas a métodos locales en un lenguaje de programación son más rápidas que las llamadas a métodos remotos.

También se conoce la tecnología UPnP ("Universal Plug and Play")/SSDP, que se basa en una arquitectura distribuida de servicios dinámicos para periféricos de red (televisión, iluminación, direccionador ADSL, lector de DVD, persianas desplegables y así sucesivamente) y puntos de control (PDA, televisión, interruptor mural y así sucesivamente) conectados entre ellos por una red ad hoc. La tecnología UPnP/SSDP define sus protocolos de descubrimiento de servicio. Los protocolos de comunicación remota se toman de SOAP ("Simple Object Access Protocol"). De nuevo, no se proporciona ningún mecanismo para...

1. Procedimiento de gestión de asociaciones entre componentes solicitantes de servicios y componentes proveedores de servicios en un entorno distribuido, describiéndose dichos componentes, en una etapa de escritura, en un lenguaje de programación objeto, comprendiendo dicho procedimiento las siguientes etapas:

- descubrimiento dinámico, por medio de al menos un protocolo de descubrimiento de servicios distribuido, de servicios solicitados,

- anuncio, por medio de al menos un protocolo de descubrimiento de servicios distribuido, de servicios proporcionados, y

- realización de una conexión entre al menos un componente solicitante de servicios y al menos un componente proveedor de servicios;

caracterizado porque dicho procedimiento comprende las siguientes etapas:

- en el transcurso de dicha etapa de escritura:

• asociación de al menos un componente solicitante de servicios a un archivo declarativo en el que se declaran dichos servicios solicitados,

• asociación de al menos un componente proveedor de servicios a un archivo declarativo en el que se declaran dichos servicios proporcionados, integrándose dichos componentes solicitante y proveedor de servicios en una plataforma local (A, B, C) que forma parte del entorno distribuido,

- puesta en marcha de dicho componente solicitante de servicios, análisis del archivo declarativo al cual está asociado, identificación de servicios pedidos, y después realización de dicha etapa de descubrimiento dinámico,

- puesta en marcha de dicho componente proveedor de servicios, análisis del archivo declarativo al que está asociado, identificación de servicios proporcionados, y después realización de dicha etapa de anuncio,

- selección, entre tipos de comunicación disponibles, de un tipo de comunicación que es compatible con el componente solicitante de servicios y el componente proveedor de servicios,

- realizándose dicha conexión entre el componente solicitante de servicios y el componente proveedor de servicios con ayuda de un tipo de comunicación compatible identificada.

2. Procedimiento de acuerdo con la reivindicación 1, caracterizado porque adicionalmente comprende una etapa de supresión de una conexión entre al menos un componente solicitante de un servicio y al menos un componente anteriormente proveedor de ese servicio, cuando ese componente anteriormente proveedor de ese servicio ya no proporciona ese servicio.

3. Procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 2, caracterizado porque, para al menos una pareja solicitante de servicios/proveedor de servicios, el tipo de comunicación utilizado es un protocolo de comunicación remota.

4. Procedimiento de acuerdo con la reivindicación 3, caracterizado porque dicho protocolo de comunicación remota se selecciona entre los protocolos RMI, SOAP y CORBA/IIOP.

5. Procedimiento de acuerdo con la reivindicación 3 o la reivindicación 4, caracterizado porque al menos un componente que aplica un protocolo de comunicación remota se instala por medio de una descarga automática en función de eventos predeterminados.

6. Procedimiento de acuerdo con una de las reivindicaciones 3 a 5, caracterizado porque al menos un componente que aplica un protocolo de descubrimiento de servicio distribuido se instala por medio de una descarga automática en función de eventos predeterminados.

7. Procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 2, caracterizado porque, para al menos una pareja solicitante de servicios/proveedor de servicios alojada en una misma plataforma (A, B, C), el tipo de comunicación es local.

8. Procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 7, caracterizado porque dicha declaración de servicios se efectúa en sintaxis XML.

9. Procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 8, caracterizado porque dicho al menos un protocolo de descubrimiento de servicios distribuido se selecciona entre los protocolos SLP, Jini, UDDI, UPnP/SSDP, CORBA y WS-SD.

10. Programa de ordenador, denominado de corazón, para aplicar un procedimiento que comprende todas las etapas de un procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 9.

11. Programa de ordenador, denominado de implementación, destinado a ser requerido por un programa de corazón de acuerdo con la reivindicación 10, que comprende instrucciones de código de programa para:

- implementar una interfaz adecuada para aplicar dicho protocolo de descubrimiento de servicios distribuido,

- implementar una interfaz adecuada para aplicar dicha conexión entre dichos componentes solicitante y proveedor de servicios,

cuando dicho programa de implementación es ejecutado por un ordenador.

12. Dispositivo de gestión de asociaciones entre componentes solicitantes de servicios y componentes proveedores de servicios en un entorno distribuido, estando escritos dichos componentes en un lenguaje de programación objeto, que comprende:

- medios de descubrimiento dinámico, por medio de al menos un protocolo de descubrimiento de servicios distribuidos, de servicios solicitados,

- medios de anuncio, por medio de al menos un protocolo de descubrimiento de servicios distribuidos, de servicios proporcionados, y

- medios de realización de una conexión entre al menos un componente solicitante de servicios y al menos un componente proveedor de servicios;

caracterizado porque el dispositivo de gestión, al igual que los componentes solicitantes y proveedores de servicios, está integrado en una plataforma local (A, B, C) que forma parte del entorno distribuido, habiéndose asociado previamente al menos un componente solicitante de servicios a un archivo declarativo en el que están declarados dichos servicios solicitados y habiéndose asociado previamente al menos un componente proveedor de servicios a un archivo declarativo en el que están declarados dichos servicios proporcionados, consistiendo el dispositivo de gestión en un objeto adecuado para:

- por un lado, poner en marcha dicho componente solicitante de servicios, analizar el archivo declarativo al que está asociado, identificar los servicios solicitados, realizar un descubrimiento dinámico,

- por otro lado, poner en marcha dicho componente proveedor de servicios, analizar el archivo declarativo al que está asociado, identificar los servicios proporcionados, y realizar un anuncio,

- seleccionar, entre tipos de comunicación disponibles, un tipo de comunicación que sea compatible con el componente solicitante de servicios y el componente proveedor de servicios,

- establecer la conexión entre el componente solicitante de servicios y el componente proveedor de servicios usando un tipo de comunicación compatible identificado.