ES2351093T3 - Procedimiento de gestión automático de asociaciones entre servicios en un entorno distribuido. - Google Patents
Procedimiento de gestión automático de asociaciones entre servicios en un entorno distribuido. Download PDFInfo
- Publication number
- ES2351093T3 ES2351093T3 ES06820254T ES06820254T ES2351093T3 ES 2351093 T3 ES2351093 T3 ES 2351093T3 ES 06820254 T ES06820254 T ES 06820254T ES 06820254 T ES06820254 T ES 06820254T ES 2351093 T3 ES2351093 T3 ES 2351093T3
- Authority
- ES
- Spain
- Prior art keywords
- service
- services
- component
- provider
- components
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2807—Exchanging configuration information on appliance services in a home automation network
- H04L12/2809—Exchanging configuration information on appliance services in a home automation network indicating that an appliance service is present in a home automation network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
Landscapes
- Engineering & Computer Science (AREA)
- Automation & Control Theory (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
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.
Description
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.
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
automatizar el descubrimiento de los servicios solicitados.
También se conocen los Servicios Web, cuya
arquitectura aparece para permitir que las aplicaciones heterogéneas
que se ejecutan dentro de diferentes empresas puedan
inter-operar a través de los servicios ofrecidos por
las aplicaciones. La heterogeneidad de las aplicaciones no sólo se
considera a nivel de los lenguajes de implementación de las
aplicaciones, sino también a nivel de los modelos de interacción
definidos por los protocolos de comunicación.
La descripción de los servicios Web se realiza
en un lenguaje denominado WSDL ("Web Service Description
Language"). Este lenguaje, basado sobre una gramática XML,
permite describir la interfaz del servicio, los tipos de datos
empleados en los mensajes, el protocolo de transporte empleado en la
comunicación y las informaciones que permiten localizar el servicio
especificado. El directorio de servicios denominado UDDI
("Universal Description Discovery and Integration")
admite la grabación de las descripciones de servicios (denominados
tipo de servicios) y de proveedores de servicios de empresas. El
protocolo de comunicación por defecto es SOAP.
En resumen, actualmente numerosas tecnologías
permiten que los equipos electrónicos se interconecten sobre una red
y se desconecten de la red sin perturbar el funcionamiento global:
los protocolos de descubrimiento de servicios distribuidos como Jini
(propuesto por la sociedad Sun Microsystems), UPnP, Web Services y
así sucesivamente, permiten a los equipos anunciar sus servicios y
descubrir los servicios suministrador sobre la red, particularmente
en los que estos se necesitan. Estas tecnologías también facilitan
medios para relacionar a los clientes y a los proveedores de
servicios gracias a protocolos de conexión remota como SOAP
utilizado por UPnP y Servicios Web, RMI utilizado por Jini y
CORBA/IIOP utilizado por CORBA.
Estas tecnologías permiten relacionar un
componente "proveedor de servicios" y un componente
"solicitante de servicios" situados sobre nudos diferentes de
red. No obstante, el programador debe escribir el código no
funcional, es decir unido a una preocupación externa a las
funcionalidades iniciales del software, de manera que:
- la programación de la búsqueda de un servicio
tenga las propiedades buscadas por el solicitante del servicio,
- la espera de determinados tratamientos como la
activación y el anuncio de servicios suministrados mientras que los
servicios solicitados no estén disponibles, y
- la detección y el tratamiento de eventos de
grabación, supresión y modificación de servicios.
El Service Binder descrito anteriormente trata
precisamente estos aspectos, pero en el contexto no distribuido
OSGi, ya que asume el ensamblaje y el desensamblaje de componentes
en función de criterios descritos en un archivo de metadatos que
obedece a una sintaxis XML: servicios suministrados y propiedades
asociadas, servicios solicitados con sus criterios de aceptabilidad
(filtros).
Se constata en resumen que hasta ahora ninguna
solución técnica conocida permite la gestión automática de
dependencias de servicios entre proveedores y solicitantes en un
entorno distribuido.
La invención propone por tanto un procedimiento
de gestión automático de asociaciones entre componentes solicitantes
de servicios y componentes proveedores de servicios en el entorno
distribuido, que comprende 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.
Este procedimiento se caracteriza porque,
integrándose cada componente en una plataforma local que forma parte
del entorno distribuido,
- al menos uno de dichos componentes está
asociado a un archivo declarativo en el cual se declaran dichos
servicios solicitados y/o dichos servicios proporcionados y
- durante la puesta en marcha de dicho al menos
un componente, está previsto un análisis de dicho archivo
declarativo dentro de la plataforma en la cual está integrado este
componente.
De esta manera, la invención aplica la gestión
automática de asociaciones proveedores-solicitantes
a partir de una declaración previa de dependencias de servicios de
cada componente, es decir de servicios proporcionados y/o
solicitados por cada componente de la aplicación. Esta declaración
previa puede escribirse, por ejemplo, ventajosamente en una sintaxis
simple, tal como la sintaxis XML. El descubrimiento del servicio
puede, por ejemplo, proceder de una petición presentada por una
aplicación "cliente", o de la recepción de un anuncio
espontáneo emitido por un proveedor de servicios.
La invención se refiere por tanto,
correlativamente, a un archivo declarativo en el cual se declaran
los servicios solicitados y/o los servicios proporcionados por un
componente asociado a dicho archivo, caracterizado porque es apto
para analizarse por un objeto gestionado durante la puesta en marcha
de este componente dentro de una plataforma que forma parte de un
entorno distribuido.
De acuerdo con características particulares, el
procedimiento de acuerdo con la invención puede comprender además,
después del análisis de dicho archivo declarativo dentro de la
plataforma y por al menos un servicio solicitado declarado en dicho
archivo, una etapa de mantenimiento dinámico del conocimiento de los
componentes proveedores disponibles y, si procede, una etapa de
conexión de dicho componente considerado con un componente proveedor
disponible para proporcionar dicho servicio
pedido.
pedido.
Gracias a estas disposiciones, se garantiza de
manera automática la obtención de un servicio pedido por un
componente.
De acuerdo con otras características
particulares, el procedimiento de acuerdo con la invención puede
comprender además, después del análisis de dicho archivo declarativo
dentro de la plataforma y por al menos un servicio suministrado
declarado en dicho archivo, una etapa de anuncio de dicho servicio
suministrado dentro del entorno distribuido.
Gracias a estas disposiciones, se garantiza de
manera automática la puesta a disposición de un servicio
suministrado por un componente.
De acuerdo aún con otras características
particulares, el procedimiento de acuerdo con la invención puede
comprender además 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 este
componente anteriormente proveedor de ese servicio ya no proporcione
ese servicio.
Ventajosamente también pueden eliminarse uno o
más relaciones que ya no son útiles.
Por otra parte, la invención permite
ventajosamente al desarrollador elaborar su aplicación con
independencia de las tecnologías de descubrimiento de servicio y de
las tecnologías de comunicación presentes en la red durante la
ejecución. La invención permite por tanto la utilización
transparente de todos los protocolos de descubrimiento y todos los
protocolos de comunicación existentes, sin que deba limitarse a un
solo representante de estos protocolos.
En particular, la invención es compatible con
cualquier tipo de protocolo de descubrimiento de servicios
distribuidos. Por ejemplo, al menos un protocolo de descubrimiento
de servicios distribuidos puede seleccionarse entre los protocolos
SLP, Jini, UDDI, UPnP/SSDP, CORBA y WS-SD.
De acuerdo con un modo de realización, para al
menos una pareja de solicitante de servicios/
proveedor de servicios, dicha conexión puede realizarse por medio de un protocolo de comunicación remota. Por ejemplo, dicho protocolo de comunicación remota puede seleccionarse entre los protocolos RMI, SOAP y CORBA/IIOP.
proveedor de servicios, dicha conexión puede realizarse por medio de un protocolo de comunicación remota. Por ejemplo, dicho protocolo de comunicación remota puede seleccionarse entre los protocolos RMI, SOAP y CORBA/IIOP.
En ese modo de realización, algunos componentes
que aplican el protocolo de comunicación remota y/o algunos
componentes que aplican un protocolo de descubrimiento de servicio
distribuido pueden instalarse ventajosamente por medio de una
descarga automática en función de eventos predeterminados, tales
como la creación de una conexión entre dos componentes o la
instalación de un componente declarante de un servicio.
Por otro lado, de acuerdo con un modo de
realización, para al menos una pareja solicitante de
servicios/proveedor de servicios alojados en una misma plataforma,
dicha conexión puede realizarse naturalmente por medio de una
comunicación local.
Como se ha explicado anteriormente, la invención
está destinada a aplicarse en entorno distribuido. Por este motivo
se refiere, también, a una plataforma que forma parte de dicho
entorno y que comprende:
- al menos un componente asociado a un archivo
declarativo en el que se declaran los servicios solicitados y/o los
servicios proporcionados por este componente y
- al menos un objeto de gestión adecuado para
analizar dicho archivo declarativo durante la puesta en marcha de
este componente en el interior de dicha plataforma.
La invención también se refiere a programas de
ordenador.
Se refiere así, en primer lugar, a un programa
de ordenador, denominado corazón, que comprende instrucciones del
código de programa para interpretar, por un lado, archivos
declarativos de servicios solicitados por un componente solicitante
de servicios y archivos declarativos de servicios proporcionados por
un componente proveedor de servicios en un entorno distribuido y,
por otro lado, seleccionar entre los protocolos disponibles un
protocolo de comunicación compatible con dicho componente
solicitante de servicios y dicho componente proveedor de servicios,
cuando un ordenador ejecuta dicho programa del corazón.
De esta manera, el programa corazón puede
identificar que servicios pueden ser objeto de una asociación entre
un solicitante y un proveedor de servicio. Ventajosamente, este
programa no necesita conocer con detalle cuales son los protocolos
de descubrimiento de servicio o los tipos de comunicación
disponibles.
Por este motivo la invención se refiere, en
segundo lugar, a un programa de ordenador, denominado de
implementación, destinado a ser requerido por un programa corazón
tal como se describe anteriormente de manera breve, que comprende
instrucciones del código de programa para aplicar al menos un
protocolo de descubrimiento de servicios distribuido y/o al menos un
protocolo de comunicación remota, cuando un ordenador ejecuta dicho
programa de implementación.
El hecho de prever así, por un lado, un programa
corazón (instalado en todas las plataformas) y, por otro lado,
programas de implementación (que sólo pueden instalarse en algunas
de estas plataformas) presenta la ventaja de no imponerse a todos
los nudos del sistema de gestión del programa de ordenador completo
necesario para aplicar la invención. Sin embargo, es evidente que
esta disposición de programas que poseen diferentes funcionalidades
sólo se menciona en este documento a modo preferencial y en absoluto
es indispensable para poder aplicar la invención.
La siguiente descripción, en relación con los
dibujos adjuntos, de los modos de realización proporcionados como
ejemplos no limitativos, hará que se comprenderá bien en qué
consiste la invención y cómo puede realizarse.
La figura 1 es un esquema de funcionamiento de
una aplicación sobre varias plataformas distribuidas.
La figura 2 es un esquema del corazón de la
infraestructura adaptada a un solo protocolo de descubrimiento de
servicios y a un solo protocolo de comunicación, de acuerdo con un
primer modo de realización de la invención.
La figura 3 es un esquema relativo a la
publicación de un servicio, de acuerdo con un primer modo de
realización de la invención.
La figura 4 es un esquema relativo al
descubrimiento de un servicio registrado, de acuerdo con un primer
modo de realización de la invención.
La figura 5 es un esquema relativo a una llamada
remota de los métodos de un proveedor de servicio, de acuerdo con un
primer modo de realización de la invención.
La figura 6 es un esquema de los mecanismos
aplicados en segundo modo de realización de la invención.
La figura 7 es un esquema de funcionamiento de
una aplicación sobre varias plataformas distribuidas y varios
equipos.
La figura 8 es un esquema del corazón de la
infraestructura adaptada a múltiples tecnologías, de acuerdo con un
segundo modo de realización de la invención.
La figura 9 es un esquema relativo a la
publicación de un servicio, de acuerdo con un segundo modo de
realización de la invención.
La figura 10 es un esquema relativo al
descubrimiento de un servicio registrado, de acuerdo con un segundo
servicio de realización de la invención.
La figura 11 es un esquema relativo a una
llamada remota de los métodos de un proveedor de servicios, de
acuerdo con un segundo modo de realización de la invención.
A continuación se describirá detalladamente un
primer modo de aplicación de la invención que comprende un sólo
protocolo de descubrimiento de servicio y un solo protocolo de
comunicación remota de una plataforma de servicios de tipo OSGi. El
entorno OSGi proporciona un ejemplo práctico de realización,
pudiendo extenderse la invención en cualquier entorno de ejecución
de componentes basados en un servicio equivalente al del "Service
Binder".
En el caso particular de la plataforma OSGi, se
utilizará la terminología denominada "bundle" (en lo sucesivo,
"paquete") que define una unidad de despliegue o un elemento de
programa desplegable en esta plataforma. La invención consiste en un
conjunto de paquetes que pueden desplegarse total o parcialmente
sobre cada uno de los nudos de una red de equipos electrónicos
inteligentes tales como ordenadores.
La realización propuesta comprende un conjunto
de clases y de interfaces genéricas que definen los procesos de
base, como la exportación, la conexión, el descubrimiento de un
entorno distribuido, a saber:
- noción de "fábrica a exportar": conjunto
de clases y de interfaces útiles para la exportación. La función de
dicha fábrica es fabricar para un objeto cualquiera una
"referencia de exportación" que contenga todas las
informaciones que permitan atender este objeto desde un nudo de red,
por ejemplo una URL;
- noción de "fábrica de conexión": conjunto
de clases y de interfaces útiles para la conexión. La función de
dicha fábrica es fabricar, a partir de una "referencia de
exportación", un objeto de conexión que permita invocar los
métodos del objeto remoto;
- noción de "servicio de descubrimiento":
conjunto de clases y de interfaces útiles para aplicar este
concepto; la función de un servicio de descubrimiento es permitir a
los servidores publicar las referencias del servicio en la red, y
a los clientes descubrir los servicios así publicados.
Estas interfaces y clases pueden proporcionarse
en un solo paquete, para un despliegue más rápido, o en varios
paquetes separados, para un mantenimiento modular. La presencia de
este paquete o de este conjunto de paquetes es necesaria en cada
plataforma que utiliza la invención. Todas estas interfaces pueden
incluirse en un único y mismo componente como el denominado
"corazón de infraestructura distribuida" en la figura 2.
Los paquetes de implementación proporcionan:
- una implementación de la interfaz "servicio
de descubrimiento" que aplica el protocolo SLP (Service Location
Protocol) o cualquier otro protocolo seleccionado como protocolo de
descubrimiento de servicios distribuidos para ampliar el
descubrimiento de servicios a más plataformas;
- una implementación de la interfaz "fábrica
de conexión" que utiliza un protocolo de comunicación remota,
como RMI ("Remote Method Invocation"); y
- una implementación de la interfaz "fábrica a
exportar" que utiliza dicho protocolo de comunicación remota.
Los mecanismos de Service Binder se recuperan y
se extienden con mecanismos distribuidos. El ciclo de vida de los
componentes se respeta. Cada componente descrito en el archivo
descriptivo también se adjunta a un administrador automático de
dependencias. Cada vez que el administrador de dependencias de un
componente efectúa una operación de descubrimiento o de conexión de
servicio, el mecanismo se extiende de la siguiente manera.
- La búsqueda de un tipo de servicio solicitado
teniendo en cuenta las propiedades definidas por el componente se
efectúa en primer lugar localmente en la plataforma. Si se encuentra
un número suficiente de proveedores de este servicio, la búsqueda
es concluyente y se interrumpe. Las conexiones a los componentes
descubiertos son por tanto exclusivamente locales. Si el número de
proveedores de servicio descubiertos en la plataforma no es
suficiente y si la descripción de la dependencia menciona que
eventualmente puede satisfacerse de manera remota, por ejemplo por
medio de un valor booleano añadido en la sintaxis de la descripción,
el administrador efectúa entonces su petición por el protocolo de
descubrimiento mencionado anteriormente. Si las referencias
descubiertas convienen, el administrador requiere a la fábrica de
conexión para proporcionar un representante del objeto remoto
proveedor del servicio, objeto de implementación de la interfaz del
servicio, al componente solicitante. Se efectúa de esta manera una
conexión "remota". La interfaz del objeto proporcionado en el
caso de una conexión remota es similar en todos los aspectos a la
del objeto que se proporcionarla si el proveedor fuera local. La
diferencia es que el objeto proporcionado tramita las solicitudes
como delegado, o "proxy" y retransmite las peticiones al objeto
remoto.
- El registro de un servicio proporcionado se
efectúa en primer lugar en la plataforma local. Si el archivo
descriptivo del componente menciona que el servicio puede proponerse
de manera remota, entonces el administrador requiere a la fábrica a
exportar para construir una referencia de exportación, a
continuación efectúa el registro de esta referencia de acuerdo con
el protocolo de descubrimiento. La referencia de exportación del
componente contiene información suficiente de un cliente para que
la fábrica de conexión actual construya un "proxy" que permita
el acceso a este componente remoto.
La escritura del código del corazón sólo
necesita conocer las "interfaces de base" descritas
anteriormente. En la figura 2, las interfaces de bases y el código
del corazón se reúnen en el paquete "corazón de infraestructura
distribuida". Para un funcionamiento en modo distribuido, el
corazón necesita que en cada plataforma OSGi se instale el paquete
de fábrica de conexión RMI para los servicios solicitados, el
paquete de fábrica a exportar RMI para los servicios proporcionados
y el paquete que permite el acceso al descubrimiento SLP (figura 2).
En la figura 1, el corazón de la infraestructura no se representa en
cada plataforma sino que cada paquete instalado utiliza los
mecanismos ofrecidos por el corazón de la infraestructura.
El mecanismo distribuido del procedimiento de
acuerdo con un primer modo de realización de la invención se
describe ahora con referencia a las figuras 3, 4 y 5.
La figura 3 muestra tres plataformas en la misma
red local: A, B, C. El usuario solicita la instalación de una
aplicación. La instalación comprende la instalación del paquete b1
(t1) en la plataforma A. Uno de los componentes de este paquete
registra, mediante el corazón de la infraestructura, un servicio S
hacia el directorio de servicios asociados a la plataforma A (t2),
después lo registra a los directorios remotos denominados DA
(Directory Agent, entidad definida por SLP) (t3).
La figura 4 muestra la presencia del paquete b2
en la plataforma B, en la que uno de los componentes formula una
petición de servicios. La petición es en primer lugar local (t4). En
este ejemplo, o el servicio S deseado no está registrado en la
plataforma B, o la descripción de b2 indica que b2 requiere la
conexión de todos los proveedores de ese servicio. Por
consiguiente, el paquete b2 se dirige a uno de los directorios
remotos DA (t5). Como la referencia registrada por b1 conviene, el
componente solicitante analiza entonces los parámetros RMI unidos a
la referencia para requerir los métodos sobre el servicio remoto
(t6) en la plataforma A como se ilustra en la figura 5.
La invención propuesta está destinada para
instalarse en equipos electrónicos inteligentes a domicilio, en
empresas o en el ámbito de redes locales. Estos equipos se
suministran habitualmente con una arquitectura de componentes
clásica. Los componentes de arquitectura y los componentes
aplicativos pueden instalarse en remoto de acuerdo con las
necesidades. Para un buen funcionamiento, los paquetes que describen
las interfaces de base y el "corazón de la infraestructura
distribuida" deben instalarse en cada plataforma que efectuará
conexiones remotas o necesitará servicios remotos.
De manera habitual, el desarrollador define en
primer lugar las interfaces de los servicios internos o externos a
su aplicación. Estas interfaces en todos los modelos orientados al
servicio se definen por:
- un nombre de interfaz,
- nombres de métodos, denominados también
acciones o funciones, con sus argumentos de entrada y de
retorno.
A continuación, se escribe el código de la
aplicación utilizando esas interfaces. De manera habitual, una
parte del código está unida a las tecnologías de descubrimiento y
de conexión remota utilizadas. El ámbito de la invención, el
desarrollador escribe el código de sus componentes de acuerdo con un
modelo de programación convencional (en este documento OSGi). Sólo
se añade un archivo descriptivo particular a cada componente para
declarar los servicios a proporcionar de manera distribuida y los
servicios solicitados. La invención permite generar automáticamente
los objetos "proxy", intermediarios útiles en la adaptación
del descubrimiento y de la comunicación de acuerdo con el modelo
considerado. El código por tanto es genérico y se adapta
automáticamente al descubrimiento y a la conexión de los servicios
remotos.
El archivo descriptivo también es útil en la
ejecución. De acuerdo con la invención, un objeto
"administrador" analiza este archivo al arrancar el componente.
Para cada servicio solicitado, activa un objeto que mantiene
dinámicamente el conocimiento de los proveedores disponibles para la
utilización de las tecnologías de descubrimiento disponibles, une o
desune al componente solicitante con los proveedores. Cuando se
proporcionan todos los servicios solicitados, el administrador
anuncia entonces los servicios proporcionados por la tecnología de
descubrimiento, utilizada para el anuncio o registro de servicios en
ese caso. Las aplicaciones se componen de manera espontánea sin
configuración explícita antes de la ejecución. Durante la ejecución,
la modificación del entorno (comandos del usuario, llegada y salida
de equipos, y así sucesivamente) tiene como consecuencia la
aparición o la supresión de los servicios. Como cada componente
reacciona dinámicamente a estos eventos, la aplicación se
reconfigura automáticamente.
En particular, ventajosamente se podrá prever la
supresión de una o más conexiones entre componentes solicitantes
de un servicio y un componente anteriormente proveedor de ese
servicio que ha hecho saber que ya no proporcionará este servicio a
partir de un momento dado.
De manera general, el administrador instala sus
equipos provistos de su plataforma de servicios. Puede instalar
directamente o en remoto el "corazón de la infraestructura
distribuida" y las unidades que implementan la fábrica a
exportar, la fábrica de conexión y el acceso al servicio de
descubrimiento remoto.
El usuario puede instalar componentes
aplicativos en las plataformas donde se instala la invención,
gracias, por ejemplo, a un catálogo disponible en internet, no
siendo el despliegue una problemática dirigida por la invención. Sin
configuración previa, los equipos publican los servicios
proporcionados, descubren los servicios disponibles e interaccionan
con objeto de ofrecer todas las funcionalidades de la aplicación
deseada.
A continuación se describe con detalle un
segundo modo de realización de la invención que combina todas las
tecnologías posibles para el descubrimiento del servicio y la
comunicación remota sobre una plataforma de servicios de tipo OSGi.
Este segundo modo de realización abarca el primer modo de
realización a una arquitectura orientada al servicio que utiliza
todos los protocolos de descubrimiento de servicios y de
comunicación remota disponibles (figura 6).
La realización propuesta comprende un conjunto
de clases y de interfaces genéricas que definen los procesos de
base, a saber:
- noción de "meta-fábrica a
exportar": la función de dicha fábrica es mantener al día la
lista de "fábricas a exportar" disponibles en la plataforma; la
meta-fábrica puede requerir a todas las fábricas a
exportar disponibles para crear y unir los parámetros útiles a las
diferentes tecnologías de comunicación remota para cada registro de
un servicio proporcionado;
- noción de "meta-fábrica de
conexión": la función de dicha fábrica es mantener al día la
lista de fábricas de conexiones disponibles en la plataforma; la
meta- fábrica puede crear la conexión remota adecuada a partir del
conocimiento de una referencia del objeto remoto y
- noción de "meta-servicio de
descubrimiento": la función de esta entidad es mantener al día la
lista de servicios de descubrimiento disponibles; permite a los
proveedores de servicios publicar las eferencias del servicio en la
red de acuerdo con cualquiera de las tecnologías de descubrimiento
de servicios presentadas y a los clientes descubrir los servicios
así publicados.
Estas interfaces y clases pueden proporcionarse
en un solo paquete o en varios paquetes separados. La presencia de
este paquete (o de este conjunto de paquetes) es necesaria en cada
plataforma que utiliza la invención. Todas las interfaces pueden
incluirse en un solo y mismo componente como el que se denomina
"corazón de infraestructura distribuida" en la figura 8.
Los paquetes de implementación que aplican las
nociones definidas anteriormente en los paquetes de base son por
ejemplo:
- fábricas a exportar especializadas
(RMI,
SOAP para los servicios UPnP, SOAP para los servicios Web, CORBA/IIOP) que implementan las interfaces de bases;
SOAP para los servicios UPnP, SOAP para los servicios Web, CORBA/IIOP) que implementan las interfaces de bases;
- fábricas de conexión especializadas (mismas
tecnologías que las anteriores) que implementan las interfaces de
base;
- paquetes que contienen componentes que
implementan la noción del servicio de descubrimiento utilizando un
protocolo de descubrimiento clásico (SLP, Jini,
WS-SD, UDDI, UPnP/SSDP, Corba Traiding Service) o
ad hoc, basado por ejemplo en una tecnología "Peer to
Peer".
Para que un solicitante que funciona en una
plataforma A pueda utilizar un proveedor que funciona en una
plataforma B, basta con que esté desplegado sobre A al menos una
"fábrica de conexión" compatible con una "fábrica a
exportar" desplegada sobre B. Incluso, para que el solicitante
pueda descubrir al proveedor, basta con que se despliegue en las dos
plataformas un paquete que encapsule el mismo protocolo de
descubrimiento. Si el cliente (resp. servidor) es un equipo que
utiliza tecnologías convencionales, el servidor (resp. cliente)
también debe utilizar las mismas tecnologías de descubrimiento, de
exportación y de conexión.
Este segundo modo de realización de la invención
propone interfaces y mecanismos genéricos para adaptar el
procedimiento, de acuerdo con el primer modo de realización
anteriormente descrito, en todas las tecnologías de descubrimiento
de servicios y todas las tecnologías de comunicación remota.
Los mecanismos del procedimiento según el primer
modo de realización se toman y se amplían para adaptarlos a
tecnologías variadas. Cada componente desarrollado se describe en el
archivo descriptivo y se adjunta un administrador automático de
dependencias. Cada vez que el administrador de dependencias de un
componente efectúa una operación de descubrimiento o de conexión del
servicio, el mecanismo se amplia a todos los protocolos pertinentes
presentes. El paquete "corazón" está constituido en si mismo
por tres componentes:
- un componente que implementa el
"meta-servicio de descubrimiento" que requiere
localmente todos los componentes instalados que proporcionan un
servicio de descubrimiento'',
- un componente que implementa la
"meta-fábrica de conexión" que requiere
localmente todos los componentes instalados proporcionando una
fábrica de conexión, y
- un componente que implementa la
"meta-fábrica a exportar" que requiere
localmente todos los componentes instalados proporcionando una
fábrica de exportación.
El código del paquete "corazón" utiliza
estos tres componentes para aplicar los siguientes mecanismos
distribuidos.
Como en el procedimiento según el primer modo de
realización, la búsqueda de un tipo de servicio solicitado valorando
las propiedades definidas por el componente se efectúa en primer
lugar localmente en la plataforma. Si la descripción de la
dependencia menciona que eventualmente puede satisfacerse de manera
remota, por ejemplo, por un valor booleano añadido en la sintaxis de
la descripción, el administrador efectúa entonces su petición
sucesivamente al lado de cada servicio de descubrimiento disponible.
Después de cada solicitud, si los proveedores de los servicios
descubiertos convienen y pueden conectarse al componente
solicitante, la búsqueda se declara concluyente y se interrumpe.
Un proveedor de servicios descubierto puede
conectarse al componente solicitante con la siguiente condición: el
proveedor descubierto debe registrarse al menos con una referencia
de exportación compatible con una fábrica de conexión disponible
sobre la pasarela, conocida por el corazón La fábrica de conexión
compatible proporciona entonces un representante del objeto remoto
proveedor del servicio, es decir, un objeto que implementa la
interfaz del servicio, en el componente solicitante a partir de
parámetros útiles inscritos en la referencia de exportación. La
interfaz del objeto proporcionado es similar en todos los aspectos a
la del objeto que se proporcionarla si el proveedor fuera local. La
diferencia es que el objeto proporcionado tramita las solicitudes
como delegado, o "proxy" y retransmite las peticiones al objeto
remoto.
Como en el procedimiento según el primer modo de
realización, el registro de un servicio suministrado se efectúa en
primer lugar en la plataforma local. Si el archivo descriptivo del
componente menciona que el servicio puede proponerse de manera
remota, entonces el registro se efectúa sucesivamente al lado de
cada servicio de descubrimiento disponible en la plataforma,
conocido por el corazón. El componente se registra por tanto con las
referencias de exportación construidas por cada fábrica a exportar
disponible en la plataforma, conocida por el núcleo.
La escritura del código del corazón sólo
necesita conocer las "interfaces de base" descritas
anteriormente. En la figura 8, las interfaces de base y el código
del corazón se reúnen en el paquete "corazón de infraestructura
distribuida". Para un funcionamiento en modo distribuido, el
corazón necesita que se instale en cada plataforma OSGi uno o más
paquetes de fábrica de conexión para los servicios solicitados, uno
o más paquetes de fábrica a exportar para los servicios
proporcionados y uno o más paquetes proponiendo un servicio de
descubrimiento (figura 7). En la figura 7, el corazón de la
infraestructura solo se representa en cada plataforma pero cada
paquete instalado utiliza los mecanismos ofrecidos por el corazón de
la infraestructura.
Ahora se describe el mecanismo de reparto del
procedimiento de acuerdo con el segundo modo de realización de la
invención, en referencia a las figuras 9, 10 y 11.
La figura 9 muestra tres plataformas en la misma
red local: A, B, C. El usuario solicita la instalación de una
aplicación. La instalación comprende la instalación del paquete b1
(t1) en la plataforma A. Uno de estos componentes de este paquete
registra, mediante el corazón de la infraestructura, un servicio S
al lado del directorio de servicios asociados a la plataforma A (t2)
después lo registra al lado de los directorios remotos según los
servicios de descubrimiento disponibles (t3). El registro asocia la
mención de las referencias de exportación según diferentes
protocolos de comunicación (en este caso x e y).
La figura 10 muestra la presencia del paquete b2
en la plataforma B, en la que uno de los componentes formula una
petición de servicios. La petición es en primer lugar local (14). Se
considera el caso en el que el servicio deseado no se registre en la
plataforma B y/o la descripción de b2 indique que b2 requiere la
conexión de todos los proveedores de este servicio incluso a
distancia. Por consiguiente, el corazón dirige sucesivamente la
petición a cada servicio de descubrimiento; una petición se emite,
por ejemplo, a un directorio externo en la figura 10 (15). Como la
referencia registrada por b1 conviene, el componente solicitante
analiza las referencias remotas. El paquete b2 conserva la
referencia asociada al protocolo de comunicación adecuado x para
requerir los métodos sobre el servicio remoto (t6) (figura 11).
El segundo modo de realización de la invención
está destinado para instalarse sobre equipos electrónicos
inteligentes a domicilio, en la empresa o en redes locales. Estos
equipos se suministran habitualmente con una arquitectura clásica.
Los componentes de arquitectura y los componentes aplicativos pueden
instalarse en remoto según las necesidades. Para un buen
funcionamiento, los paquetes que describen las interfaces de base y
el "corazón de la infraestructura distribuida" deben instalarse
en cada plataforma destinada para efectuar conexiones remotas o que
necesitan servicios remotos. A continuación, cada plataforma puede
albergar todos o parte de los paquetes de implementación
disponibles, en función de las necesidades y de las capacidades de
la plataforma: típicamente, se instalarán en un PC todos los
paquetes de implementación disponibles, por lo que sólo podrá
instalarse un subconjunto en un sistema embarcado de capacidad de
memoria limitada.
De manera habitual, el desarrollador define en
primer lugar las interfaces de los servicios internos o externos a
su aplicación. Esta interfaces en todos los modelos orientados al
servicio se definen por:
- un nombre de interfaz; y
- nombres de métodos, denominados también
acciones o funciones, con sus argumentos de entrada y de
retorno.
De manera usual, una parte del código depende de
las tecnologías de descubrimiento y de las conexiones utilizadas. En
el ámbito de la invención, el desarrollador escribe el código de sus
componentes según un modelo de programación clásico. A cada
componente se adjunta sólo un archivo descriptivo particular con
objeto de declarar los servicios a proporcionar de manera
distribuida y los servicios solicitados. La invención le permite
generar automáticamente los objetos "proxy", intermediarios
útiles a la adaptación del descubrimiento y de la comunicación según
los modelos múltiples considerados (figura 6). El código es por
tanto genérico y se adapta automáticamente a cualquier tecnología de
descubrimiento y de conexión remota, siempre que se hayan
desarrollado los adaptadores correspondientes.
El archivo descriptivo se utiliza en la
ejecución. Un objeto "gestor" analiza ese archivo cuando se
arranca el componente. Para cada servicio solicitado, activa un
objeto que mantiene dinámicamente el conocimiento de los proveedores
disponibles para la utilización de las tecnologías de descubrimiento
disponibles, une el componente a los proveedores o los desune.
Cuando se proporcionan todos los servicios solicitados, el
administrador anuncia entonces los servicios proporcionados por
todas las tecnologías de descubrimiento disponibles, utilizadas en
este caso para el anuncio o el registro de los servicios. Las
aplicaciones se componen de manera espontánea sin configuración
explícita antes de la ejecución. Durante la ejecución, la
modificación del entorno (comandos del usuario, llegada y salida de
los equipos y así sucesivamente) tiene como consecuencia la
aparición o la supresión de los servicios. Cada componente reacciona
dinámicamente con estos eventos, la aplicación se reconfigura
automáticamente.
En particular, ventajosamente se podrá prever la
supresión de una o más conexiones entre componentes solicitantes de
un servicio y un componente anteriormente proveedor de ese servicio
que ha hecho saber que ya no proporcionará este servicio a partir de
un momento dado.
Particularmente pueden construirse dos tipos de
aplicación:
- las aplicaciones que funcionan según el primer
modo de la realización para un solo protocolo de descubrimiento de
servicios y un solo protocolo de comunicación; y
- las aplicaciones según el segundo modo de
realización que aplican varios equipos heterogéneos tomando
diferentes tecnologías de descubrimiento de servicios o de conexión
remota; algunas de estas aplicaciones pueden haberse aplicado
puntualmente de manera clásica; después de la descarga y puesta en
marcha de los componentes sobre la pasarela, estos componentes se
descubren, descubriendo los equipos preexistentes (es decir que
funcionan por medio de un código puesto a punto independientemente
de la invención y que utilizan mecanismos clásicos de descubrimiento
y de comunicación remota) y se interconectan cualquiera que sean las
tecnologías presentes con objeto de hacer posibles diferencias
funcionales de aplicación.
Si otros componentes del modelo propuesto u
otros equipos publican sus servicios en la red, las conexiones se
modifican o se añaden dinámicamente. Si los componentes del modelo
propuesto o equipos abandonan la red, las conexiones
correspondientes se rompen o se modifican.
El usuario puede poseer previamente equipos que
anuncian sus servicios según tecnologías convencionales diversas
(Jini, UPnP, Servicios Web y así sucesivamente). El usuario no
necesita conocer los detalles de estas tecnologías. También posee al
menos un equipo electrónico tal como un ordenador en el que se
instala la invención. El usuario puede instalar componentes
aplicativos en las plataformas dónde se instala la invención, por
ejemplo, gracias a un catálogo disponible en internet, no siendo el
despliegue un problema dirigido por la invención. Sin configuración
previa, los equipos publican los servicios proporcionados según las
tecnologías por ellos conocidas, y gracias a la invención, los
componentes descubren los servicios proporcionados, publican sus
propios servicios utilizando las tecnologías disponibles e
interaccionando para ofrecer todas las funcionalidades de la
aplicación deseada.
Pueden considerarse numerosas utilizaciones de
la invención:
- aplicaciones ofimáticas (impresora, escáner,
fax y así sucesivamente): tanto en la oficina como en casa,
numerosos equipos se diseñan para compartirse o estar compuestos por
diversas aplicaciones; algunos de estos equipos se anuncian
espontáneamente en la red según tecnologías clásicas (Jini, UPnP,
servicios web, CORBA y así sucesivamente); la instalación de la
invención en un ordenador permite el descubrimiento y el uso de
estos equipos; el ordenador podrá proponer espontáneamente, es decir
sin configuración previa, la impresión de documentos en una
impresora UPnP o Jini y así sucesivamente; además, podrá componer
los servicios ofrecidos incluso si los equipos proporcionados no son
compatibles a priori; por ejemplo, el servicio ofrecido por
un escáner CORBA podrá componerse con el servicio de impresión
ofrecido por la impresora Jini para ofrecer un servicio de
fotocopiadora;
- aplicaciones domóticas (calefacción,
ventilación, aire acondicionado, luces decorativas, estores y así
sucesivamente): la invención permite componer los servicios
domóticos ofrecidos según diversas tecnologías; si los equipos
domóticos se programan para descubrirse de acuerdo con protocolos
conocidos, la invención permite descubrirlos y proponer servicios
compuestos; un ejemplo de aplicación es la programación de la puesta
en marcha de equipos de acuerdo con un horario; por ejemplo, una
hora antes de que suene el despertador, los radiadores Web Services
se ponen en marcha, y cuando suena el despertador, la cafetera UPnP
se pone en marcha y la tostadora Jini puede comenzar a tostar
rebanadas de pan;
- aplicaciones audiovisuales (telemando,
división de contenido, restitución); otras aplicaciones pueden
componerse en el campo audio-visual; los equipos
correspondientes pueden ser servidores de contenido ("Media
Server"), equipos de restitución ("Media Renderer") o
equipos como el "Set-Top-Box"
que conecta la televisión a la red de internet; los servidores de
contenido multimedia y los servicios de restitución se distribuyen
en la casa y pueden descubrirse y conectarse; un ordenador o un
asistente personal equipado de la invención puede proponer una
aplicación que descubra todos los equipos; la aplicación permite
explorar los contenidos multimedia, transferir un contenido de un
espacio de almacenaje a otro y visionar un elemento en un equipo de
restitución con la televisión del salón o el ordenador de la
habitación;
- servicios exteriores: actualmente, se ofrecen
numerosos servicios en forma de servicios Web en internet; por lo
tanto es posible, gracias a la invención, desarrollar aplicaciones
que utilicen los servicios descubiertos y componerlos con servicios
de redes locales; por ejemplo, puede identificarse un mal
funcionamiento de la lavadora UPnP y notificarse a un servicio de
vigilancia de equipos que advierta al usuario por un mensaje a su
agenda personal, la cual puede contactar con los Servicios Web
(páginas amarillas o servicio post venta del constructor) ofrecidos
en internet con objeto de proponerle una lista de soluciones
posibles para paliar el mal funcionamiento; la solución puede ser
llamar al reparador más próximo o avisar directamente al servicio
post venta que propondrá entonces los medios a aplicar.
Claims (12)
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:
\bullet asociación de al menos un componente
solicitante de servicios a un archivo declarativo en el que se
declaran dichos servicios solicitados,
\bullet 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.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0553085 | 2005-10-11 | ||
| FR0553085A FR2891972A1 (fr) | 2005-10-11 | 2005-10-11 | Procede de gestion automatique des associations entre services dans un environnement distribue |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2351093T3 true ES2351093T3 (es) | 2011-01-31 |
Family
ID=36655018
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06820254T Active ES2351093T3 (es) | 2005-10-11 | 2006-10-04 | Procedimiento de gestión automático de asociaciones entre servicios en un entorno distribuido. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US20080201723A1 (es) |
| EP (1) | EP1943809B1 (es) |
| AT (1) | ATE478510T1 (es) |
| DE (1) | DE602006016316D1 (es) |
| ES (1) | ES2351093T3 (es) |
| FR (1) | FR2891972A1 (es) |
| WO (1) | WO2007042713A1 (es) |
Families Citing this family (76)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11244545B2 (en) | 2004-03-16 | 2022-02-08 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
| US11489812B2 (en) | 2004-03-16 | 2022-11-01 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
| US10522026B2 (en) | 2008-08-11 | 2019-12-31 | Icontrol Networks, Inc. | Automation system user interface with three-dimensional display |
| US20170118037A1 (en) | 2008-08-11 | 2017-04-27 | Icontrol Networks, Inc. | Integrated cloud system for premises automation |
| US10142392B2 (en) | 2007-01-24 | 2018-11-27 | Icontrol Networks, Inc. | Methods and systems for improved system performance |
| US10237237B2 (en) | 2007-06-12 | 2019-03-19 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11916870B2 (en) | 2004-03-16 | 2024-02-27 | Icontrol Networks, Inc. | Gateway registry methods and systems |
| US11582065B2 (en) | 2007-06-12 | 2023-02-14 | Icontrol Networks, Inc. | Systems and methods for device communication |
| US10721087B2 (en) * | 2005-03-16 | 2020-07-21 | Icontrol Networks, Inc. | Method for networked touchscreen with integrated interfaces |
| US11811845B2 (en) | 2004-03-16 | 2023-11-07 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
| US20090077623A1 (en) | 2005-03-16 | 2009-03-19 | Marc Baum | Security Network Integrating Security System and Network Devices |
| US11343380B2 (en) | 2004-03-16 | 2022-05-24 | Icontrol Networks, Inc. | Premises system automation |
| US11368429B2 (en) | 2004-03-16 | 2022-06-21 | Icontrol Networks, Inc. | Premises management configuration and control |
| US20050216302A1 (en) | 2004-03-16 | 2005-09-29 | Icontrol Networks, Inc. | Business method for premises management |
| US7747733B2 (en) | 2004-10-25 | 2010-06-29 | Electro Industries/Gauge Tech | Power meter having multiple ethernet ports |
| US11615697B2 (en) | 2005-03-16 | 2023-03-28 | Icontrol Networks, Inc. | Premise management systems and methods |
| US10999254B2 (en) | 2005-03-16 | 2021-05-04 | Icontrol Networks, Inc. | System for data routing in networks |
| US11496568B2 (en) | 2005-03-16 | 2022-11-08 | Icontrol Networks, Inc. | Security system with networked touchscreen |
| US11700142B2 (en) | 2005-03-16 | 2023-07-11 | Icontrol Networks, Inc. | Security network integrating security system and network devices |
| US20120324566A1 (en) | 2005-03-16 | 2012-12-20 | Marc Baum | Takeover Processes In Security Network Integrated With Premise Security System |
| US20110128378A1 (en) | 2005-03-16 | 2011-06-02 | Reza Raji | Modular Electronic Display Platform |
| US20170180198A1 (en) | 2008-08-11 | 2017-06-22 | Marc Baum | Forming a security network including integrated security system components |
| US10079839B1 (en) | 2007-06-12 | 2018-09-18 | Icontrol Networks, Inc. | Activation of gateway device |
| US9432628B2 (en) * | 2006-06-15 | 2016-08-30 | Saturn Licensing Llc | Information processing device, information processing method, and computer program |
| US8616976B2 (en) | 2006-11-07 | 2013-12-31 | Core Wireless Licensing S.A.R.L. | Gaming via peer-to-peer networks |
| US7734717B2 (en) * | 2006-12-05 | 2010-06-08 | Nokia Corporation | Software distribution via peer-to-peer networks |
| US11706279B2 (en) | 2007-01-24 | 2023-07-18 | Icontrol Networks, Inc. | Methods and systems for data communication |
| US7633385B2 (en) | 2007-02-28 | 2009-12-15 | Ucontrol, Inc. | Method and system for communicating with and controlling an alarm system from a remote server |
| US8451986B2 (en) | 2007-04-23 | 2013-05-28 | Icontrol Networks, Inc. | Method and system for automatically providing alternate network access for telecommunications |
| GB2450471A (en) * | 2007-05-18 | 2008-12-31 | Thales Holdings Uk Plc | Managing nodes in a distributed system by registering and making available nodal information to nodes. |
| WO2008148096A1 (en) * | 2007-05-25 | 2008-12-04 | Exceptional Innovation, Llc | Customizable remote control device |
| US11646907B2 (en) | 2007-06-12 | 2023-05-09 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11212192B2 (en) | 2007-06-12 | 2021-12-28 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11601810B2 (en) | 2007-06-12 | 2023-03-07 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11316753B2 (en) | 2007-06-12 | 2022-04-26 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11218878B2 (en) | 2007-06-12 | 2022-01-04 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US12003387B2 (en) | 2012-06-27 | 2024-06-04 | Comcast Cable Communications, Llc | Control system user interface |
| US10523689B2 (en) | 2007-06-12 | 2019-12-31 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
| US11423756B2 (en) | 2007-06-12 | 2022-08-23 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| KR20080112914A (ko) | 2007-06-22 | 2008-12-26 | 삼성전자주식회사 | 이벤트 메시지 수신 방법, 이벤트 메시지 전송 방법,피제어 장치 및 제어 포인트 |
| WO2009020332A2 (en) * | 2007-08-06 | 2009-02-12 | Samsung Electronics Co, . Ltd. | Method and apparatus for providing/receiving web-based service of plurality of service providers |
| US10223903B2 (en) | 2010-09-28 | 2019-03-05 | Icontrol Networks, Inc. | Integrated security system with parallel processing architecture |
| US11831462B2 (en) | 2007-08-24 | 2023-11-28 | Icontrol Networks, Inc. | Controlling data routing in premises management systems |
| EP2056196A1 (fr) * | 2007-10-26 | 2009-05-06 | France Telecom | Procédé de réalisation et de traitement d'appel de procédure, système et produit programme d'ordinateur correspondant |
| US20090161579A1 (en) * | 2007-12-20 | 2009-06-25 | Mika Saaranen | Method, system, and apparatus for implementing network capable input devices |
| US11916928B2 (en) | 2008-01-24 | 2024-02-27 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
| US20170185278A1 (en) | 2008-08-11 | 2017-06-29 | Icontrol Networks, Inc. | Automation system user interface |
| US10530839B2 (en) | 2008-08-11 | 2020-01-07 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
| US11758026B2 (en) | 2008-08-11 | 2023-09-12 | Icontrol Networks, Inc. | Virtual device systems and methods |
| US11792036B2 (en) | 2008-08-11 | 2023-10-17 | Icontrol Networks, Inc. | Mobile premises automation platform |
| US11729255B2 (en) | 2008-08-11 | 2023-08-15 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
| US8638211B2 (en) | 2009-04-30 | 2014-01-28 | Icontrol Networks, Inc. | Configurable controller and interface for home SMA, phone and multimedia |
| CN102377796B (zh) * | 2010-08-05 | 2015-06-10 | 中国人民解放军国防科学技术大学 | 基于OSGi的异构服务集成系统及方法 |
| US8836467B1 (en) | 2010-09-28 | 2014-09-16 | Icontrol Networks, Inc. | Method, system and apparatus for automated reporting of account and sensor zone information to a central station |
| FR2966310A1 (fr) * | 2010-10-14 | 2012-04-20 | France Telecom | Decouverte de services web dans un reseau local |
| US8914465B2 (en) * | 2010-10-27 | 2014-12-16 | Samsung Electronics Co., Ltd. | Platform system with provider controlling mechanism and method of operation thereof |
| US10275840B2 (en) * | 2011-10-04 | 2019-04-30 | Electro Industries/Gauge Tech | Systems and methods for collecting, analyzing, billing, and reporting data from intelligent electronic devices |
| US10771532B2 (en) | 2011-10-04 | 2020-09-08 | Electro Industries/Gauge Tech | Intelligent electronic devices, systems and methods for communicating messages over a network |
| US10303860B2 (en) | 2011-10-04 | 2019-05-28 | Electro Industries/Gauge Tech | Security through layers in an intelligent electronic device |
| US10862784B2 (en) | 2011-10-04 | 2020-12-08 | Electro Industries/Gauge Tech | Systems and methods for processing meter information in a network of intelligent electronic devices |
| US11816465B2 (en) | 2013-03-15 | 2023-11-14 | Ei Electronics Llc | Devices, systems and methods for tracking and upgrading firmware in intelligent electronic devices |
| US9111214B1 (en) | 2014-01-30 | 2015-08-18 | Vishal Sharma | Virtual assistant system to remotely control external services and selectively share control |
| US11405463B2 (en) | 2014-03-03 | 2022-08-02 | Icontrol Networks, Inc. | Media content management |
| US11734396B2 (en) | 2014-06-17 | 2023-08-22 | El Electronics Llc | Security through layers in an intelligent electronic device |
| CN104202427A (zh) * | 2014-09-24 | 2014-12-10 | 国家电网公司 | 一种分布式节点间的服务调用方法及系统 |
| CN111414222A (zh) | 2014-12-11 | 2020-07-14 | 微软技术许可有限责任公司 | 能够实现可动作的消息传送的虚拟助理系统 |
| EP3357205B1 (en) | 2015-09-28 | 2022-01-05 | Microsoft Technology Licensing, LLC | User assistant for unified messaging platform |
| US10353474B2 (en) | 2015-09-28 | 2019-07-16 | Microsoft Technology Licensing, Llc | Unified virtual reality platform |
| US10958435B2 (en) | 2015-12-21 | 2021-03-23 | Electro Industries/ Gauge Tech | Providing security in an intelligent electronic device |
| CN105721562B (zh) * | 2016-01-28 | 2019-01-29 | 武汉大学 | 一种基于代理的异构服务调用方法与协同调用系统 |
| US10430263B2 (en) | 2016-02-01 | 2019-10-01 | Electro Industries/Gauge Tech | Devices, systems and methods for validating and upgrading firmware in intelligent electronic devices |
| US11734704B2 (en) | 2018-02-17 | 2023-08-22 | Ei Electronics Llc | Devices, systems and methods for the collection of meter data in a common, globally accessible, group of servers, to provide simpler configuration, collection, viewing, and analysis of the meter data |
| US11686594B2 (en) | 2018-02-17 | 2023-06-27 | Ei Electronics Llc | Devices, systems and methods for a cloud-based meter management system |
| US11754997B2 (en) | 2018-02-17 | 2023-09-12 | Ei Electronics Llc | Devices, systems and methods for predicting future consumption values of load(s) in power distribution systems |
| US11647095B1 (en) * | 2018-10-02 | 2023-05-09 | Intuit Inc. | Method and system for orchestrating communications between application services through a unified connector platform |
| US11863589B2 (en) | 2019-06-07 | 2024-01-02 | Ei Electronics Llc | Enterprise security in meters |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6910068B2 (en) * | 1999-06-11 | 2005-06-21 | Microsoft Corporation | XML-based template language for devices and services |
| US6892230B1 (en) * | 1999-06-11 | 2005-05-10 | Microsoft Corporation | Dynamic self-configuration for ad hoc peer networking using mark-up language formated description messages |
| US6594700B1 (en) * | 1999-06-14 | 2003-07-15 | International Business Machines Corporation | System and method for implementing a universal service broker interchange mechanism |
| US7191236B2 (en) * | 2000-05-02 | 2007-03-13 | Canon Kabushiki Kaisha | Transparent telecommunications system and apparatus |
| US6643650B1 (en) * | 2000-05-09 | 2003-11-04 | Sun Microsystems, Inc. | Mechanism and apparatus for using messages to look up documents stored in spaces in a distributed computing environment |
| US6862594B1 (en) * | 2000-05-09 | 2005-03-01 | Sun Microsystems, Inc. | Method and apparatus to discover services using flexible search criteria |
| US6970869B1 (en) * | 2000-05-09 | 2005-11-29 | Sun Microsystems, Inc. | Method and apparatus to discover services and negotiate capabilities |
| US7194689B2 (en) * | 2000-08-22 | 2007-03-20 | Microsoft Corporation | Generic user control point tool for universal plug and play (UPnP) devices |
| WO2002057917A2 (en) * | 2001-01-22 | 2002-07-25 | Sun Microsystems, Inc. | Peer-to-peer network computing platform |
| US20020187750A1 (en) * | 2001-06-12 | 2002-12-12 | Majumdar Kalyan Sankar | Method and apparatus for service management, delegation and personalization |
| US7299304B2 (en) * | 2001-11-20 | 2007-11-20 | Intel Corporation | Method and architecture to support interaction between a host computer and remote devices |
| US8561069B2 (en) * | 2002-12-19 | 2013-10-15 | Fujitsu Limited | Task computing |
| US7631033B2 (en) * | 2003-01-15 | 2009-12-08 | Xerox Corporation | Hosted method and system for automated proxy creation of device resident services |
| US7685288B2 (en) * | 2003-06-30 | 2010-03-23 | Microsoft Corporation | Ad-hoc service discovery protocol |
| US20050097087A1 (en) * | 2003-11-03 | 2005-05-05 | Punaganti Venkata Murali K. | System and method for providing a unified framework for service discovery |
| US7398327B2 (en) * | 2003-11-25 | 2008-07-08 | Robert Bosch Gmbh | Apparatus, method and system for providing automated services to heterogenous devices across multiple platforms |
| EP1560094A1 (de) * | 2004-01-27 | 2005-08-03 | Siemens Aktiengesellschaft | Bereitstellung von Diensten innerhalb eines Netzwerks mit gekoppelten Rechnern |
| US7653916B2 (en) * | 2004-02-20 | 2010-01-26 | Microsoft Corporation | Uniform resource discovery |
| US7467384B2 (en) * | 2004-02-20 | 2008-12-16 | Microsoft Corporation | Uniform resource discovery with multiple computers |
| US20050193106A1 (en) * | 2004-03-01 | 2005-09-01 | University Of Florida | Service discovery and delivery for ad-hoc networks |
| US7933290B2 (en) * | 2004-03-30 | 2011-04-26 | Nokia Corporation | System and method for comprehensive service translation |
| WO2005109908A2 (en) * | 2004-04-30 | 2005-11-17 | Vulcan Inc. | Maintaining a graphical user interface state that is based on a selected piece of content |
-
2005
- 2005-10-11 FR FR0553085A patent/FR2891972A1/fr active Pending
-
2006
- 2006-10-04 EP EP06820254A patent/EP1943809B1/fr active Active
- 2006-10-04 DE DE602006016316T patent/DE602006016316D1/de active Active
- 2006-10-04 AT AT06820254T patent/ATE478510T1/de not_active IP Right Cessation
- 2006-10-04 US US12/089,909 patent/US20080201723A1/en not_active Abandoned
- 2006-10-04 ES ES06820254T patent/ES2351093T3/es active Active
- 2006-10-04 WO PCT/FR2006/050991 patent/WO2007042713A1/fr active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| US20080201723A1 (en) | 2008-08-21 |
| EP1943809B1 (fr) | 2010-08-18 |
| WO2007042713A1 (fr) | 2007-04-19 |
| DE602006016316D1 (de) | 2010-09-30 |
| FR2891972A1 (fr) | 2007-04-13 |
| EP1943809A1 (fr) | 2008-07-16 |
| ATE478510T1 (de) | 2010-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2351093T3 (es) | Procedimiento de gestión automático de asociaciones entre servicios en un entorno distribuido. | |
| Arnold | The Jini architecture: dynamic services in a flexible network | |
| Im et al. | IoT mashup as a service: cloud-based mashup service for the Internet of things | |
| Lee et al. | Enabling smart spaces with OSGi | |
| Hall et al. | Challenges in building service-oriented applications for OSGi | |
| Hall et al. | An OSGi implementation and experience report | |
| US7516201B2 (en) | Communication device and software for operating multimedia applications | |
| TW406509B (en) | A home audio/video network with updatable device control modules | |
| Bardin et al. | Towards an automatic integration of heterogeneous services and devices | |
| Costa et al. | Reconfigurable component-based middleware for networked embedded systems | |
| KR20010073003A (ko) | 브리징 다수의 홈 네트워크 소프트웨어 아키텍처 | |
| US20080256225A1 (en) | Osgi-Based Dynamic Service Management Method for Context-Aware Systems | |
| US20060095551A1 (en) | Extensible service processor architecture | |
| CN102375894B (zh) | 一种管理不同类型文件系统的方法 | |
| Cheng et al. | OSGi-based smart home architecture for heterogeneous network | |
| Royon et al. | Multiservice home gateways: business model, execution environment, management infrastructure | |
| Bottaro et al. | Home SOA- facing protocol heterogeneity in pervasive applications | |
| Warriach et al. | An interplatform service-oriented middleware for the smart home | |
| US7584302B1 (en) | Business integration component for containers | |
| Nicholson et al. | Dynamic fog computing platform for event-driven deployment and orchestration of distributed Internet of Things applications | |
| Yang et al. | A framework for service morphing and heterogeneous service discovery in smart environments | |
| Saif | Architectures for ubiquitous systems | |
| Bottaro et al. | Pervasive spontaneous composition | |
| Yang | Design and implement of the home networking service agent federation using open service gateway | |
| Gorissen et al. | H2O metacomputing–jini lookup and discovery |