Tradicionalmente los middleware de comunicaciones han estado orientados a proporcionar una serie de servicios a aplicaciones de más alto nivel que necesitaban llevar a cabo un intercambio de información sin tener que gestionar cuestiones de bajo nivel como el soporte a la interacción entre diferentes tecnologías, protocolos, sistemas operativos, etc.
El uso de una tecnología middleware es por lo tanto fundamental para el desarrollo de aplicaciones distribuidas para sistemas heterogéneos en red. Así, por ejemplo, aplicaciones domóticas como aquéllas que identifican a la persona que está presente en la habitación y ajusta las condiciones del entorno (luminosidad, climatización, área de trabajo, etc.) a las preferencias del usuario son ya una realidad. Estas aplicaciones se basan en la existencia de una aplicación que, por un lado permite la detección del usuario presente en la sala (quizás a través del iris, huella, tarjeta RFID, etc.) y por otro, ha reconocido ciertos patrones en cómo esa persona configura el entorno. Una vez identificadas la persona y el patrón asociada a ésta, será necesario ajustar el termostato de la sala, la iluminación, música de ambiente etc.
En cualquier caso, a simple vista, puede comprobarse como el número de tecnologías hardware que deben ser soportadas e integradas es amplio y heterogéneo.
Existen numerosos middlewares de comunicación, tanto en el ámbito de la investigación como en el ámbito comercial/industrial, que dan respuesta a esta necesidad de integración de dispositivos heterogéneos. Quizás, entre los más conocidos podemos reseñar la tecnología de CORBA, JavaRMI, .NET, DDS o ZeroC ICE.
No es nuestro propósito llevar a cabo un análisis detallado de las fortalezas y debilidades de éstas y similares tecnologías. Por el contrario, lo que pretendemos es identificar una carencia común en todas ellas y ver cómo ésta está siendo abordada por nuestra tecnología middleware, conocida como DHARMA.
Uno de los principales campos de aplicación de los sistemas distribuidos ha sido el de los sistemas inteligentes, aplicados a entornos tan dispares como la ciudad (paradigma de la Smart City), el entorno que nos rodea (Ambient Intelligence), la supervisión de personas de la tercera edad (Ambient Assisted Living) o la salud (eHealth) entre otros.
A pesar de que todos estos paradigmas afirman interpretar y reconocer las actividades que se están desarrollando en el contexto, proporcionando respuestas inteligentes y adaptadas al mismo, la realidad es que esa inteligencia se limita a identificar una serie de patrones (más o menos flexibles) a los que el sistema deberá responder de una manera determinada. Aunque es probable que estos sistemas implementen ciertas capacidades de aprendizaje automático, lo cierto es que la mayoría de sistemas responderá sólo ante situations previamente programadas.
La principal razón de esta limitación la encontramos en la necesidad de disponer de un conocimiento preciso y cierto, tanto de los servicios disponibles en el sistema como de la manera en la que los mismos pueden ser utilizados. Un conocimiento previo, tan preciso, que no siempre estará disponible. Por ejemplo, en el contexto de los servicios web, el lenguaje estándar WSDL es el encargado de definir, para un determinado servicio, toda la información necesaria para que pueda ser utilizado remotamente (localización, interfaces o mecanismos de invocación, mensajes soportados, etc.). El desarrollo de clientes para este tipo de servicios implica que estos mismos deberán conocer, con antelación, no sólo la existencia del servicio sino también la información necesaria para poder desarrollar un cliente que se ajuste a los requisitos.
Como comentábamos, la principal limitación con la que se encuentran los sistemas inteligentes desarrollados para entornos como AmI, AAL, o Smart City es que sus capacidades están inicialmente limitadas a la capacidad de los servicios ofrecidos. Una manera de abordar esta limitación ha sido mediante la técnica de la composición automática de servicios, consistente en la generación de nuevos servicios, más complejos, a partir de otros más básicos. Por ejemplo, se puede componer un sistema de seguimiento indoor a partir de un sistema que identifique personas, de tal forma que cuando cambie de cámara pueda seguir siendo identificada, junto con un sistema de tracking en vídeo. El nuevo servicio compuesto, al generarse a partir de dos servicios básicos conocidos, podrá componerse y utilizarse sin problema.
Sin embargo, esta técnica también tiene sus limitaciones. La composición de servicios generalmente no requiere complejos mecanismos de adaptación de servicios básicos y suele consistir en tareas que conecten la salida de un servicio con la entrada del siguiente, quizás con ligeros ajustes. La composición tampoco es una solución lo suficientemente versátil para poder articular sistemas verdaderamente inteligentes, porque incluso cuando las distintas combinaciones posibles no están prefijadas de antemano y puedan calcularse en tiempo de ejecución a partir de una búsqueda guiada por el resultado que se desea obtener, la misma va a estar limitada por las entradas requeridas por los servicios básicos involucrados en la composición y los resultados que los mismos produzcan.
¿Qué se necesita entonces para poder hablar de sistemas inteligentes?
Para ilustrar la respuesta a esta pregunta recurriremos a un fragmento de la película Eagle Eye durante el cual la máquina ARIIA pretende conocer el contenido de una conversación. Para ello, la máquina trazará diferentes planes orientados todos ellos a conseguir su resultado. En primer lugar intenta activar el micrófono con el que el ascensor está equipado, pero el mismo está deshabilitado. Busca por lo tanto un plan alternativo, explorando todos los dispositivos y servicios disponibles en la habitación en la que las personas se encuentran. El siguiente plan consiste en activar el micrófono del teléfono que hay en la sala, pero también se encuentra deshabilitado. El siguiente paso consiste en intentar llevar a cabo un reconocimiento visual del habla, utilizando la cámara de la habitación, pero en este caso las personas consiguen que sus labios no sean capturados mientras hablan. Finalmente, el sistema recurre a buscar fuentes de vibración donde las ondas del sonido de la voz puedan reflejarse y a partir de la mismas poder reconocer las palabras. En la escena se identifica una taza con café con fuente de vibración.
Evidentemente se trata de una escena de ciencia ficción pero que refleja fielmente lo que necesita un sistema inteligente: un objetivo, un sistema de planificación y composición de servicios y conocimiento detallado del mundo real para guiar dicha composición.
Como seres racionales, podemos afirmar que toda acción conscientemente realizada por una persona está motivada por el objetivo que la misma persigue. Se necesita por lo tanto un mecanismo para poder especificar objetivos y verificar la proximidad al mismo o su satisfacción. El uso de modelos semánticos, especificados mediante ontologías, por ejemplo, nos proporcionan un mecanismo bastante eficiente para esta finalidad. Por ejemplo, en la escena anteriormente descrita el objetivo se describiría como un par “ACCIÓN + OBJETO”, más concretamente como EAVESDROP + CONVERSATION.
Una vez definidos los objetivos del sistema, el siguiente elemento necesario para hablar de sistema inteligente consiste en disponer de un mecanismo de composición semántica de servicios. Ya hemos comentado anteriormente que la composición, en sí misma, no es una solución al problema. Sin embargo, hablamos ahora de composición semántica.
¿Qué diferencia hay entre la composición y la composición semántica de servicios?
Pues en el caso de la composición básica, ésta se articulará considerando los servicios básicos como si se trataran de piezas de un puzzle. Esto quiere decir que sólo podrán componer aquellos servicios cuyas entradas y salidas coincidan, incluso aunque esta composición pueda no tener ningún sentido. Por ejemplo, en el contexto de la escena anterior, hablaremos de composición básica en el caso de la activación del micrófono del ascensor o el teléfono junto con otro servicio de reconocimiento de voz.
Sin embargo, cuando estos planes de composición más básica fracasan, el sistema debe recurrir a una composición más elaborada, para lo cual se requiere un profundo análisis de la versatilidad de los distintos dispositivos que están disponibles en el entorno. Es entonces cuando hablaremos de composición semántica.
En este sentido, el sistema dispone del conocimiento necesario para saber que una conversación implica a varias personas hablando y que para hablar es necesario mover los labios de una manera predeterminada para emitir los sonidos que componen las distintas palabras. Por lo tanto, esta composición semántica implicaría razonar que con un dispositivo capaz de grabar vídeo podría identificarse los labios de cada persona y a partir de ahí utilizar un software capaz de identificar los sonidos pronunciados a partir de los movimientos labiales.
Otro ejemplo de composición semántica se puede identificar en dicha escena cuando el sistema, en base al conocimiento del que dispone, intenta identificar objetos susceptibles de ser alterados por las vibraciones de la voz humana. En este caso el líquido contenido en la taza de café es un medio idóneo sobre el que analizar las vibraciones que reflejarán los sonidos pronunciados en la conversación. Este último ejemplo es el que implica una composición más compleja por cuanto hay que combinar módulos capaces de reconocer objetos en una escena de vídeo o el software con capacidad de reconocimiento de sonidos a partir de las vibraciones generadas, pero no sólo eso, este tipo de composición implica que el sistema domina información del tipo “una taza está destinada a contener líquidos” y “los líquidos son susceptibles a ser alterados por la vibración de la voz humana”.
Hablaremos de sistemas inteligentes cuando composiciones como estas últimas no hayan sido consideradas con antelación y proporcionadas al sistema a modo de reglas, sino que el sistema haya sido capaz de inferirlas simplemente a partir de descripciones básicas del mundo real y cómo éste funciona, con información del tipo: una taza es un recipiente, capaz de albergar en sus límites un contenido líquido o sólido, que generalmente se utiliza para beber líquidos.
¿Qué nos debe proporcionar el middleware para poder dar soporte a este tipo de sistemas inteligentes?
Una vez identificados los tres elementos básicos de todo sistema inteligente, como son los objetivos, el conocimiento y la herramienta de planificación que le permita diseñar planes tendentes a lograr dichos objetivos, será el rol del middleware permitir que dichos planes puedan ser articulados.
El uso de un middleware tradicional sería insuficiente para dar soporte a la articulación de planes creados ad-hoc, principalmente porque cada tipo de servicio responde a una interfaz específica, es decir, ofrece un conjunto de métodos que debe ser conocido de antemano por el cliente que desee instanciarlo.
Si los planes, o al menos el esqueleto de los planes, estuvieran predeterminado de antemano el uso de middlewares tradicionales bastaría para dar soporte a la ejecución del plan, pues la secuenciación de métodos de cada interfaz es conocida. Sin embargo, en el contexto como el de la película descrita, no existe un plan que diga, entre otros: para satisfacer el objetivo EAVESDROP CONVERSATION: 1º busca un elemento capaz de reflejar las perturbaciones producidas por las ondas de la voz; 2º utiliza un sistema de análisis de vibraciones y compáralo con los distintos sonidos. Por el contrario, la combinación de la base de conocimiento y el planificador será la que permita al sistema llegar a la conclusión de la lista de pasos que deberá dar para intentar satisfacer el objetivo. El primer obstáculo será por tanto disponer de un middleware los suficientemente versátil para automatizar la ejecución de las distintas acciones (proporcionadas por los servicios del middleware) que componen el plan.
¿Qué es DHARMA?
Dharma ha sido diseñado para que, ofreciendo la misma funcionalidad que un middleware tradicional, también dé soporte a la instanciación automática de servicios, independientemente de la interfaz que el mismo implemente, la tecnología, protocolos y demás detalles técnicos que haya por debajo.
Dharma consistirá entonces en una capa de encapsulamiento que se aplicará a los distintos servicios proporcionados sobre un middleware tradicional como es ZeroC ICE.
Al ser una capa aplicada sobre la interfaz que realmente implementen los servicios, esto implica que los dispositivos de bajo nivel no tendrán que soportar ninguna carga adicional pues la traducción podrá llevarse a cabo de manera totalmente transparente, utilizando para ello una librería diseñada específicamente para llevar a cabo dicha traducción.
¿Cómo utilizar DHARMA?
Para esto, mejor revisar el siguiente post: Interfaz Ice del modelo semántico Dharma
Si la semántica no está en la interfaz, porque es oculta, ¿cómo conozco los métodos o acciones proporcionados por un determinado servicio?
En los middleware tradicionales era necesario que el programador que implementara un cliente para un determinado servicio conociera de antemano los métodos que la interfaz ofrecía. La invocación de un método no proporcionado por la interfaz daría lugar a un error.
En el caso de DHARMA, el método a invocar es siempre el mismo: performAction, estando la diferencia entonces en el parámetro que dicho método recibe como argumento. La semántica estará en la base de conocimiento.
Como describíamos anteriormente, será en Scone donde se establezca que un dispositivo de tipo light emitter, implementa la interfaz light-service que a su vez ofrece dos acciones: light-up y light-down. O dicho de otro modo, el servicio light-service que implementa la interfaz service podrá ser instanciado a través del método performAction, recibiendo como argumento la acción “light-up” o “light-down”:
| (x-is-the-y-of-z {light-up} {performs-action} {light-service}) (x-is-the-y-of-z {light-down} {performs-action} {light-service}) |
Parece entonces evidente la necesidad de establecer de antemano un vocabulario común entre el middleware y la base de conocimiento, para lo cual recurriremos al uso de ontologías públicas y validadas por la comunidad, como son SOFIA2 y EnergyResoruce