MÉTODO Y SISTEMA DE COORDINACIÓN DE SISTEMAS SOFTWARE BASADO EN ARQUITECTURAS MULTIPARADIGMA
OBJETO DE LA INVENCIÓN
La presente invención, según se expresa en el
enunciado de esta memoria descriptiva, se refiere a un
método de coordinación para sistemas software basados en
arquitecturas multiparadigma, que hace uso de eventos con semántica alterable dinámicamente, y que tiene por obj eto simplificar la coordinación entre entidades de sistema software, facilitando la adición de nuevas entidades a coordinar en el sistema sin necesidad de que éstas sean diseñadas para que puedan intercambiar información en un instante de tiempo o deban sincronizarse, es decir, interrumpir su fluj o de ej ecución hasta que otra entidad haya alcanzado un punto concreto en su propio flujo.
Es otro objeto de la invención el asegurar un orden de ejecución correcto, cuando dos o más entidades se ejecutan de manera concurrente y, por tanto, proporcionar un estado final del sistema que cumpla con los objetivos con los que las entidades fueron diseñadas originalmente. También es obj eto de la invención el mej orar la eficiencia de la coordinación entre entidades gracias a la eliminación de la necesidad de los sondeos de estado desde una entidad a otras mediante el uso de eventos con una semántica formal y alterable dinámicamente. Ello permite informar de los cambios de estados únicamente a aquellas entidades que expresen previamente la necesidad de recibir la información de estado automáticamente cada vez que sea modificada.
La invención es aplicable a entidades que presentan una arquitectura orientada a servicios, agente, multiagente, dirigida por eventos, procesos de sistemas operativos, o cualquier combinación de las anteriores.
ANTECEDENTES DE LA INVENCIÓN
El desarrollo de sistemas software distribuidos complejos plantea una gran dificultad en cuanto a la correcta coordinación entre las diferentes entidades que los conforman y que cooperan entre sí para alcanzar determinados objetivos, ya que los métodos de coordinación propuestos hasta el momento son rígidos en cuanto a la necesidad de concretar qué entidades van a ser coordinadas. Por tanto, cuando se desea incorporar una nueva entidad al sistema, es necesario volver a desarrollar/modificar gran parte del resto de las entidades para que se cumplan los requisitos de coordinación que se deseen en cada instante o caso particular.
Además, los métodos de coordinación existentes implican el bloqueo en el fluj o de ej ecución de al menos una de las entidades del sistema, ya que la coordinación, hasta la fecha, se resuelve mediante una operación de sincronización.
Además la introducción de distintos tipos de entidades (servicios, agentes, emisores de eventos o receptores de eventos, procesos de sistemas operativos, etc.) , en un sistema software distribuido agrega una mayor complejidad, ya que dificulta la aplicación de métodos de coordinación bajo un único método común que proporcione la uniformidad y la adecuada integración que se necesita en nuestros sistemas para posibilitar que las diversas entidades cooperen entre sí. La falta de propuestas en este sentido lleva a utilizar y a aplicar soluciones ad-hoc para la coordinación entre entidades, con el inconveniente que ello conlleva.
DESCRIPCIÓN DE LA INVENCIÓN
Para conseguir los objetivos y resolver los
inconvenientes anteriormente indicados, la invención
proporciona un nuevo método para sistemas software basados
en arquitecturas multiparadigma, basado en eventos con
semántica alterable dinámicamente, que comprende las
siguientes fases:
a) generar en una entidad destino, en un punto concreto de ejecución en el que se requiere realizar una coordinación con al menos una entidad origen asociada a un tipo concreto de evento, un evento de requerimiento indicativo de la necesidad de recibir notificaciones cada vez que al menos una entidad origen genera el tipo de evento concreto al que está asociada.
b) Recibir el evento de requerimiento en una entidad coordinadora, asociada a todo tipo de eventos, para recibir cualquiera de los eventos que se pueden producir en el sistema.
c) Procesar e inferir, en la entidad coordinadora, eventos relacionados con la información requerida en el
evento de requerimiento recibido, a partir de reglas previamente establecidas que asocian semánticamente los tipos de eventos entre sí.
d) A continuación, la entidad coordinadora notifica a cada una de las entidades origen del sistema los tipos de evento concretos que deben de notificar a dicha entidad coordinadora.
e) Seguidamente, la entidad coordinadora recibe las notificaciones de los eventos concretos producidos en las diferentes entidades origen.
f) Finalmente, la entidad coordinadora transmite, a la entidad destino, los eventos inferidos y las notificaciones recibidas de las entidades origen.
El método de la invención, además, comprende opcionalmente una fase en la que, si se modifica la estructura de un evento en las fases d-f, se pasa a la fase c) .
Además, opcionalmente, el método de la invención comprende una fase en la que cuando se define un nuevo evento en las fases d-f, se pasa igualmente a la fase c) .
También opcionalmente, el método comprende una fase en la que, si la entidad destino cambia de necesidades en las fases d-f, se pasa nuevamente a la fase c) .
Cuando el evento de requerimiento indica la necesidad de recibir notificaciones coordinadas de más de una entidad
origen, la notificación transmitida desde la entidad coordinadora a la entidad destino se constituye por un nuevo evento de notificación resultante de realizar una composición de la información contenida en la notificación de cada entidad origen, de forma que la entidad coordinadora compone la información que contiene cada uno de los eventos para producir nuevos eventos de otros tipos distintos a las notificaciones generadas por las entidades origen, resultantes de la combinación de los eventos que recibió. En el caso de que en esta tarea de composición se obtenga un evento de un tipo determinado al que alguna de las entidades del sistema (entidad destino) expresó su interés previo en recibirlo automáticamente, se realiza una transmisión de estos eventos hacia estas últimas entidades.
En base a la descripción realizada, se deduce fácilmente que una entidad destino puede quedar a la espera de un tipo de evento que sólo puede originarse debido a la composición de la información provista por una o más entidades con las que se desea coordinarse. Gracias a ello se evita que el flujo de ejecución de una entidad avance hasta que otras entidades del sistema hayan llegado a un punto concreto en el flujo de ejecución de cada uno de ellos. En consecuencia, es posible la coordinación entre entidades de un sistema. Además, gracias a que la entidad coordinadora es la encargada de realizar la composición de información de eventos y de recibir y transmitir los nuevos eventos generados, cada entidad origen y destino solo requieren conocer la existencia de esta única entidad coordinadora. Por tanto, las entidades origen y destino permanecen desacopladas entre sí, lo cual favorece la obtención de propiedades de calidad de un sistema software, tales como mantenibilidad y reusabilidad. Por último, el uso de un modelo de eventos en el método de coordinación permite que las entidades a coordinar origen y destino puedan mantener la ejecución de parte de su flujo de ejecución en todo momento, incluso si se encuentran a la espera de un evento determinado para realizar una operación concreta, ya que las entidades son notificadas cuando se recibe asíncronamente un evento.
En consecuencia, el método de la invención permite que la coordinación se lleve a cabo de manera asíncrona, aunque obviamente también puede efectuarse de forma síncrona, y se evita que las entidades deban de tener un conocimiento explícito de la existencia de otras entidades, permitiéndose la posibilidad de agregar nuevas entidades a un sistema sin necesidad de rediseñar ni reiniciar el resto de entidades a ejecutar o ya en ejecución en el sistema.
Por último, cabe señalar que el método de coordinación de la invención es único para el sistema software y común para los distintos tipos de entidades, proporcionando la uniformidad e integración requerida en estos sistemas para posibilitar que las diversas entidades cooperen entre sí.
Ello evita la necesidad de utilización de métodos ad-hoc
que convencionalmente se usan en la coordinación de
entidades.
Por otro lado, cabe señalar que la configuración
descrita permite que la invención sea aplicable en sistemas software basados en arquitecturas para sistemas software distribuidos en los que las entidades pueden ser conceptualmente distintas, permitiendo que la invención se aplique a entidades con una arquitectura orientada a servicios, agente, multiagente, dirigida por eventos, procesos de sistemas operativos, o una combinación cualquiera de las anteriores.
En una realización añadida de la invención se prevé que el método comprende mecanismos para almacenar la información intercambiada entre las entidades, lo que contribuye a mejorar el proceso de análisis, verificación y mantenimiento de un sistema software. Para ello hace uso de una base de conocimiento donde se almacena meta-información acerca de la información intercambiada entre las entidades.
Adicionalmente, si el método de la invención es incorporado como parte de un sistema software que se encargue de resolver las tareas de comunicación entre ·
· •
·
entidades, se pueden combinar métodos de comunicación y coordinación síncronos y asíncronos que contribuyan a cumplir con los requisitos de coordinación en cada instante y para cada sistema software concreto y que aporten una mayor facilidad de desarrollo de sistemas software distribuidos.
Finalmente, al realizarse la coordinación mediante una notificación de información de manera asíncrona, es posible continuar con parte del flujo de ejecución de las entidades, no introduciendo, por tanto, tantos tiempos de parada en el flujo de ejecución como otros métodos ya existentes de coordinación, que suponen implicar la sincronización entre los flujos de ejecución.
Además la invención se refiere a un sistema de
coordinación de sistemas software basado en arquitecturas
multiparadigma de acuerdo con el método anteriormente
descrito.
Son independientes del objeto de la invención la
implementación concreta de las entidades origen y destino a coordinar, de la entidad coordinadora y del sistema software distribuido concreto sobre el que se aplica el método descrito, así como los detalles accesorios que puedan presentarse, siempre y cuando no afecta a sus características esenciales.
A continuación, para facilitar una mejor comprensión de esta memoria descriptiva y formando parte integrante de la misma, se acompañan una serie de figuras en las que con carácter ilustrativo y no limitativo se ha representado el objeto de la invención.
BREVE DESCRIPCIÓN DE LAS FIGURAS
Figura 1. -Muestra una representación esquemática de un sistema software basado en arquitecturas multiparadigma al que se aplica el método de coordinación de la invención.
Figura 2. -Muestra el sistema software de la figura anterior en el que las entidades origen están determinadas por un sensor de humedad y un sensor de ruido, en tanto que
la entidad destino está determinada por un sensor de
temperatura.
DESCRIPCIÓN DE LA FORMA DE REALIZACIÓN PREFERIDA
A continuación se realiza una descripción de la
5 invención basada en las figuras anteriormente comentadas.
En el ej emplo de realización de la figura 1 se han
representado "n" entidades origen 1, cada una de ellas
asociada a un tipo concreto de evento T1-Tn respectivamente,
de forma que mediante una entidad coordinadora 2 que está
10 asociada a todo tipo de eventos, es decir está configurada
de forma que pueda recibir cualquier tipo de evento, se
coordina el funcionamiento de las entidades origen 1 con
una entidad destino 3, de acuerdo con el método de la
invención.
15 Previamente es necesario definir los eventos T1-Tn con
una semántica normal, con un conjunto de información
asociada a cada tipo de evento y dotados de una estructura
que relacione unos tipos con otros.
Para conseguir la coordinación comentada, el método de
20 la invención comprende una fase a) en la que la entidad
destino 3 genera, en un punto concreto de ejecución en el
que se requiere realizar una coordinación con al menos una
de las entidades origen 1, un evento de requerimiento
indicativo de la necesidad de recibir notificaciones cada
25 vez uno o más de las entidades origen 1 genera el tipo de
evento concreto al que está asociada.
A continuación sigue una fase b) en la que la entidad
coordinadora 2 recibe el evento de requerimiento, siguiendo
una fase c) en la que procesa e infiere eventos
3 O relacionados con la información requerida en dicho evento
de requerimiento recibido, mediante un conjunto de reglas
preestablecidas que asocian semánticamente los tipos de
eventos entre si. A continuación sigue una fase d) en la
que la que la entidad coordinadora 2 notifica a cada una de
35 las entidades origen 1 los tipos de eventos que deben
notificar a la entidad coordinadora; siguiendo una fase e)
en la que la entidad coordinadora 2 recibe las
notificaciones de los eventos T1-Tn concretos producidos en las diferentes entidades origen 1, de forma que el procedimiento finaliza según una fase f) en la que la entidad coordinadora 2 realiza diversas composiciones de la información contenida en los eventos T1-Tn recibidos e inferidos, componiendo nuevos eventos Ti -Tj de forma que dicha entidad coordinadora 2 transmite los eventos inferidos y las notificaciones recibidas de las entidades origen 1 según los nuevos eventos Ti -Tj hacia la entidad origen 3. De esta forma, la entidad coordinadora 2 cuando se encuentre una composición con la que se obtenga un evento Ti -Tj se notificará el nuevo evento a la entidad
I
destino 3. Cuando ésta reciba la notificación de este evento, podrá continuar con la parte de su flujo de ejecución que requería del método de coordinación descrito, para posibilitar que las diversas entidades cooperen entre sí.
En la figura 2 se muestra una particularización de un ejemplo de realización de la figura anterior en el que las entidades origen 1 están constituidas por un sensor de humedad la y un sensor de ruido lb, en tanto que la entidad de destino está constituida por un sensor de temperatura 3. En este ejemplo se requiere una coordinación en la que el sensor de temperatura 3 sólo podrá notificar una medición si previamente se han notificado mediciones por parte del sensor de humedad la y del sensor de ruido lb.
Según la fase a) del método de coordinación señalada, dado que hay más de una unidad origen 1, se deberá expresar desde el sensor de temperatura 3, mediante un evento de requerimiento, que se desea la recepción automática de aquellos eventos cuya información asociada sea el resultado de la composición de la información extraída de los eventos notificados por los sensores de ruido la y de humedad lb. Tras recibirse el evento de requerimiento en la entidad coordinadora 3, y tal y como se describe en la fase c) , la entidad coordinadora 3 procesa e infiere que los eventos requeridos para la combinación son aquellos que son
notificados por el sensor de humedad la y el sensor de
ruido lb. Asimismo, como se explicita en la fase d) se
notificará a los sensores de humedad 1 y de ruido la para
que se aplique el método de coordinación mediante el inicio
5 de la notificación de eventos generados por dichos
sensores.
Tras la notificación de eventos realizada por los
sensores de humedad la y ruido lb, la entidad coordinadora
2 compone la información asociada a cada evento, resultando
10 en la construcción de un nuevo evento asociado
semánticamente tanto con "humedad" como con "ruido", el
cual será notificado en consecuencia, tal y como fue
descrito en la fase d) del método. Al haber expresado
previamente desde el sensor de temperatura 3 la necesidad
15 de recibir automáticamente el nuevo evento generado, este
sensor recibirá automáticamente el nuevo evento resultante
de la composición. Como consecuencia de la recepción de la
notificación de uno de esos eventos, se realiza una
notificación de un evento por parte del sensor de
20 temperatura 3 incluyendo información acerca del valor
cuantificado de ésta. De esta forma, cada vez que se reciba
un nuevo evento asociado semánticamente tanto con "humedad"
como con "ruido", el sensor de temperatura 3 realiza la
notificación pertinente y, en consecuencia, se cumple con
25 la coordinación requerida para el sistema: el sensor de
temperatura 3 solo podrá notificar una medición si
previamente se han notificado mediciones por parte del
sensor de humedad la y del sensor de ruido lb.
Por último, cabe señalar que se deberá volver a la
3 O fase c) cuando en alguna de las fases d) a f) se dan las
siguientes circunstancias: cambia la estructura interna de
alguno de los eventos, se definen nuevos eventos como
consecuencia, por ejemplo, de la incorporación de nuevas
entidades al sistema, y/o cambian las necesidades de la
35 entidad origen 3, por ejemplo, si la regla de coordinación
impuesta solo tiene vigencia durante un tiempo limitado o
tras un número predeterminado de eventos recibidos.
Las entidades origen 1 y destino 3 pueden ser diseñadas tal y como se requiera: agentes, servicios, multiagente, por eventos, procesos de sistemas operativos, etc. La entidad coordinadora 2 también puede ser considerada un servicio como un agente o un emisor/consumidor de eventos. La entidad coordinadora 2 de debe poseer, al menos, una interface pública que permita la comunicación con el resto de entidades 1 y 3 para permitir la asociación entre una entidad 1 y 3 Y un tipo de evento, la notificación de un evento a una entidad destino 3 interesada y, por último, el envío de un evento desde una entidad origen 1 cualquiera hacia la entidad coordinadora 2.
La entidad coordinadora 2 debe poder acceder a una base de conocimiento 4 donde pueda comprobar el tipo de cada uno de los eventos recibidos, para que la composición de información resulte eficiente en el tiempo, es necesario también consultar esta base de conocimiento 4 y solo realizar las composiciones que estén recogidas en ella.
La base de conocimiento 4 puede ser cualquier tipo de sistema software que permita almacenar y recuperar información, propiedades acerca de esta información (metainformación) y las relaciones entre diferentes clases de información. Por ej emplo, una base de conocimiento podrá ser una base de datos relacional, una ontología y sus instancias, etc .
El método de coordinación puede ser integrado en un
sistema software encargado de resolver los distintos
mecanismos de comunicación entre entidades de un sistema
software distribuido.
Además la invención también se refiere a un sistema
que comprende los medios necesarios para llevar a cabo el método descrito, presentando las ventajas que fueron indicadas en el apartado descripción de la invención.
