- 1. Motivación
- 2. Especificación del contenido de MAS y el intercambio de contexto
- 3. Características y limitaciones del modelo FIPA
- 4. Especificaciones FIPA en relación con otras normas
- 5. Discusión del estado actual de FIPA y direcciones futuras
- Agradecimientos
- Bibliografía
FIPA: Especificación de protocolos para la interacción de sistemas de múltiples agentes
License: Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or direct commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or permissions@acm.org. C 2007 ACM 1556-4665/2007/11-ART15 $5.00 DOI 10.1145/1293731.1293735 http://doi.acm.org/ 10.1145/1293731.1293735Editor: ACM Transactions on Autonomous and Adaptive Systems, Vol. 2, No. 4, Article 15, Publication date: November 2007.
DOI: http://dx.doi.org/10.1145/1293731.1293735
Last revision: 2022-07-24 11:07:56:49:44 +0100
Resumen: Los Multi-Agent Systems (MAS), representan un poderoso modelo de computación distribuida, que permite a los agentes cooperar y completarse entre sí e intercambiar contenido semántico y un contexto semántico para interpretar el contenido de manera más automática y precisa. Se han propuesto muchos tipos de agentes individuales y modelos de MAS desde mediados de la década de 1980 pero, la mayoría de estos han llevado a sistemas MAS homogéneos de un solo desarrollador. Durante más de una década, la actividad de estándares de FIPA ha trabajado para producir especificaciones MAS públicas, actuando como un facilitador con un papel clave en respaldar la interoperabilidad, la interacción de servicios abiertos y en respaldar el desarrollo heterogéneo. Se presentan las principales características del modelo FIPA para MAS y un análisis del diseño, opciones de diseño y características del modelo. Además, se presenta una comparación del modelo FIPA para la interoperabilidad del sistema con los de otros organismos de estándares, junto con una discusión sobre el estado actual de FIPA y las direcciones futuras.
1. Motivación
Los sistemas multiagente, o MAS, son sistemas distribuidos, compuestos por varias entidades de software autónomas denominadas agentes. En teoría, los MAS suelen caracterizarse en términos de comportamientos internos e interacción externa entre agentes. Las principales propiedades para caracterizar el comportamiento interno de los agentes son: el tipo de cognición y medida de desempeño que utilizan para elegir cómo actuar, esto es; modo reactivo, basado en patrones, basado en objetivos y basado en el camino más útil; cómo de adaptables son; cómo caracterizan el entorno en el que se sitúan, incluida su infraestructura informática y su entorno social con otros agentes; y el grado de autonomía de sus acciones en su entorno con respecto a otros agentes, frente al actor humano, y en cuanto a su ejecución. Las principales propiedades para caracterizar el comportamiento observable externo de la interacción entre agentes son: cómo interactúan para compartir tareas y compartir información; cómo interactúan como parte de diferentes tipos de organizaciones sociales; y su grado de cooperación con otros agentes.
Los MAS representan un modelo poderoso para resolver problemas de computación distribuida, incluida la capacidad de adaptar su operación en entornos abiertos y dinámicos en los que el contenido y la carga de trabajo cambian continuamente. Los MAS pueden utilizar otros agentes para la resolución cooperativa de problemas distribuidos cuando los agentes individuales no desean o no pueden realizar tareas dentro de ciertas restricciones o no tienen la competencia para realizar tareas por sí mismos. Los agentes pueden cooperar mediante el uso de un lenguaje de comunicación de agentes (ACL) para respaldar el intercambio de un rico entendimiento acordado sobre la semántica del contenido del mensaje y la semántica del contexto de comunicación del contenido del mensaje. La semántica del contenido normalmente define información y tareas compartidas con respecto a algún dominio, como un servicio específico o un dominio de aplicación. La semántica del contexto de comunicación define explícitamente las relaciones entre un mensaje particular en relación con un contexto como: el flujo de trabajo actual del agente emisor, un protocolo de interacción acordado, metas y planes, o con respecto a las creencias, deseos e intenciones del agente receptor. Los agentes pueden diseñarse para operar de manera más competitiva en los mercados que en forma cooperativa, de modo que los agentes puedan seleccionar los servicios de una variedad de otros agentes que mejor se adapten a las restricciones para cumplir sus objetivos.
Aunque sus principales comportamientos internos y externos los caracterizan como un tipo único de sistema de cómputo distribuido, en la práctica los MAS deben estar respaldados por una infraestructura de cómputo distribuida genérica o un conjunto de servicios de middleware. Los agentes de software deben poder transportar mensajes, descubrir qué capacidades de servicio pueden ofrecerles otros y poder invocar los servicios de otros proveedores. También necesitan un entorno de ejecución y servicios de gestión, incluidos seguridad y almacenamiento. Estos servicios de middleware los proporciona el entorno de tecnología de la información y las comunicaciones (TIC) de un agente, a menudo denominado plataforma MAS, en el que están integrados los agentes. Es posible que la plataforma de agentes en sí misma no se modele en términos de agentes porque ya existen especificaciones maduras de servicios públicos para algunos tipos de servicios, por ejemplo, descubrimiento de servicios, almacenamiento de datos, transporte de mensajes, etc. Envolver o reemplazar estos con el agente equivalente puede presentar desventajas como una sobrecarga adicional en la invocación de mensajes y diseños de servicios menos robustos. Por lo tanto, los agentes no solo necesitan interactuar con otros agentes, sino también invocar servicios de software de software que no son agentes. La interacción de los agentes suele ser local dentro de una plataforma de agentes, pero podría implicar una interacción remota con agentes en una o más plataformas de agentes, es decir, modelos de sistemas. Es probable que en el futuro los MAS sigan siendo bastante heterogéneos; por ejemplo, el entorno de ejecución suele ser específico del lenguaje de programación o del sistema operativo. Los MAS también deben actuar como sistemas abiertos, incluidos otros MAS y servicios que no sean agentes y, admitir cierto grado de autonomía para que los sistemas y sus miembros puedan aparecer, desaparecer y actualizarse dinámicamente.
Dados los beneficios potenciales de la interacción MAS y la amplia gama de comportamientos heterogéneos de agentes internos y externos y plataformas de agentes, es evidente que la interoperabilidad entre agentes heterogéneos y MAS heterogéneos es un gran desafío. El impulso y la capacidad de los agentes para interoperar en entornos MAS abiertos y dinámicos de información y servicios se ve facilitado por el uso de especificaciones públicas y estándar para MAS.
El propósito de este artículo es presentar un análisis crítico de las especificaciones del estándar de FIPA (Fundación para Agentes Físicos Inteligentes) para la interoperabilidad MAS. Los modelos FIPA MAS son tan relevantes y valiosos para modelar servicios informáticos distribuidos heterogéneos hoy como lo han sido en el pasado. De hecho, se puede argumentar que el potencial del modelo FIPA MAS es mayor hoy porque es ahora cuando está surgiendo una infraestructura informática y de comunicaciones básica y ubicua para que residan múltiples agentes, y además están surgiendo impulsores reales para implementarlos. Los impulsores de MAS son un mundo interconectado y aumentado digitalmente que contiene dispositivos y servicios digitales en red funcionalmente más complejos que son más interoperables, heterogéneos y adaptables. Estos impulsores conducen a la aparición de varios modelos SOA (Arquitectura Orientada a Servicios) de computación distribuida, desarrollados dentro de múltiples foros de estándares. Los modelos SOA permiten que sus componentes individuales tengan cierta autonomía local y administración descentralizada, pero que puedan organizarse a lo largo de múltiples dimensiones, como información, servicios, procesos, tipos de interacción organizacional empresarial y tipos de administración, y para equilibrar la satisfacción de necesidades locales versus globales.
No hay ningún trabajo informado que haya adoptado un enfoque holístico para analizar los modelos de interacción MAS, que haya analizado una amplia gama de especificaciones MAS según lo especificado por la principal actividad de estándares MAS, FIPA, y que haya criticado los diversos factores de diseño y compensaciones en crear especificaciones de interacción MAS. Estos son los objetivos de este artículo.
Este artículo está organizado de la siguiente manera. La motivación para modelar modelos de interacción MAS de tipo semántico ya se ha dado en esta sección. En la Sección 2 se proporciona una descripción general del conjunto de protocolos de interacción (IP) de agentes FIPA MAS. A continuación, en la Sección 3, se realiza un análisis de las opciones y características de diseño importantes para el modelo FIPA AIPS. En la Sección 4, se ofrece una comparación del modelo FIPA para la interoperabilidad con el de otros estándares. Finalmente, en la Sección 5 se brinda una discusión sobre el estado actual de FIPA y las direcciones futuras.
2. Especificación del contenido de MAS y el intercambio de contexto
2.1. Propiedades MAS
Se propone, para que las especificaciones apoyen una interoperabilidad rica y flexible, que estas deberían especificar: protocolos de comunicación, no algoritmos; mensajes que son legibles por máquina e interpretables por máquina, es decir, semántica y sintaxis; un intercambio del contexto del mensaje así como del contenido del mensaje; y soporte para sistemas abiertos, es decir, sistemas de sistemas heterogéneos. Especificar el intercambio de mensajes como un protocolo, es concentrarse en especificar un conjunto de reglas que los mensajes deben obedecer para formarse correctamente mientras que, los algoritmos, solo especifican cómo generar los mensajes definidos por un protocolo. Se pueden usar diferentes algoritmos, por ejemplo, implementados en diferentes Kits de herramientas de agentes, para generar el mismo protocolo de mensaje y ser interoperables. A veces, los investigadores establecen una heurística que dice que “la comunicación [agente] se puede modelar mejor como el intercambio de declaraciones declarativas” [Genesereth y Ketchpel 1994], sin embargo, las declaraciones pueden ser declarativas sin definiciones de apoyo o reglas de apoyo, es decir, sin algunas de las construcciones básicas necesarias para definir un protocolo.
Al especificar el intercambio de mensajes sintácticos, el enfoque está en definir explícitamente la construcción correcta del mensaje, como un patrón particular de bytes o incluso bits. Sin embargo, la interpretación, o semántica, de un byte no suele definirse explícitamente de forma que sea inequívocamente interpretable por la máquina, por ejemplo, protocolos que se definen como flujos de bits agrupados en campos (e.g. vídeo, imagen o sonidos). Existe una gama de expresividad de las representaciones semánticas, desde semánticas más ligeras, como listas de tuplas, hasta jerarquías anidadas simples, como XML, gráficos de propiedades de clase o semánticas de tipo objetivista, como sistemas de conocimiento basados en marcos y RDF-S, hasta tipos cognitivos más pesados y, la semántica que incluye restricciones lógicas como OWL, el lenguaje de ontología de la Web.
Se necesita un contexto de mensaje para guiar la semántica de modo que se pueda lograr la congruencia sobre la semántica entre el remitente y el receptor y permitir que un agente oriente la semántica a una aplicación o circunstancia específica. Por ejemplo, el contexto de un mensaje podría usarse para identificar un mensaje y poder verificar que, el intercambio de mensajes sea: confiable, idempotente, oportuno, impulsado por procesos y coordinado y que cumpla con las políticas organizacionales. De hecho, sería muy difícil hacer que los remitentes y los receptores no tuvieran estado, sin información de contexto, y que todo el contexto se defina en el mensaje mismo, haciendo referencia a recursos identificables de forma única para contener la información de contexto, es decir, usar un modelo REST. [Campo 2000]. Por lo tanto, los emisores y receptores de la interacción MAS semántica tienden a tener estado. La interacción semántica MAS se puede especificar a lo largo de las siguientes tres dimensiones:
-
Comportamiento de los agentes internos: selección y ejecución de acciones.
-
Interacción externa (del propio agente) para intercambiar:
a. Contenido de la interacción en si misma, que incluye información y tareas.
b. Contexto de la Interacción y de su relación con una organización formada por agentes.
-
Servicios del sistema o plataforma: transporte de mensajes, descubrimiento, ejecución de acciones, gestión e interacción entre plataformas.
2.2. El modelo de conjunto de Protocolos de Interacción de agentes FIPA
El foro de estándares de agentes FIPA [Poslad y Charlton 2001] se centra en la especificación de protocolos para la interacción externa y los servicios de plataforma en lugar de “el “comportamiento” del agente interno, ya que este último no es fácilmente accesible y observable, en contraste con la interacción de agentes externos. Además, los algoritmos adecuados para especificar los “comportamientos” internos de diferentes tipos de agentes son difíciles de estandarizar, ya que a menudo son una combinación entre ser específicos para resolver un problema, ser específicos para una aplicación y, la necesidad de las organizaciones que los mantienen como software privado en lugar de hacerlos públicos.
Fig. 1. FIPA especifica la interacción MAS usando especificaciones para una plataforma AIPS y MAS.
El modelo FIPA (de interacción de agentes), a menudo denominado FIPA-ACL, es más un conjunto de protocolos de interacción de agentes (AIPS) que un lenguaje de comunicación de agente declarativo único. El AIPS contiene varios protocolos semánticos distintos para la comunicación de agentes, incluidos: proceso de interacción, actos comunicativos, lógica de contenido y ontologías de contenido. El AIPS también define varios protocolos sintácticos distintos para especificar la estructura de los mensajes, su codificación y su transporte de mensajes, (ver, Figura 2). Estos se explican con más detalle a continuación.
El protocolo de Actos Comunicativos (CA) es el corazón del modelo FIPA-ACL y define la comunicación como un conjunto de diferentes CA basadas en la teoría de actos de habla [Searle 1969]. Se necesitan parámetros adicionales para definir los CA, por ejemplo, un CA de tipo de solicitud requiere una subacción como registro, esto es, para comunicar una solicitud hay que registrar una descripción de servicio. El protocolo CA define una definición semántica lógica para cada tipo de CA en términos del contexto BDI intercambiado entre los agentes emisor y receptor. El proceso de interacción o protocolo IP, denominado protocolo de interacción por FIPA, permite que un CA se utilice como parte de secuencias de mensajes o flujos de trabajo definidos, para respaldar el intercambio de información y la delegación de tareas. El proceso IP proporciona un contexto alternativo orientado al proceso para el intercambio de mensajes. FIPA ha estandarizado varios protocolos de interacción, como la solicitud, el reclutamiento, la suscripción, las subastas y la red de contratos. El protocolo de ontología de contenido, denominado lenguaje de ontología por FIPA, se utiliza para referirse a una o más ontologías de aplicación, para definir una semántica de tipo objetivista para el contenido. No se especifica una representación de ontología específica. El protocolo de lógica de contenido, denominado lenguaje de contenido por FIPA, define fórmulas lógicas generales, predicados que calculan valores de verdad y operaciones algebraicas para combinar y seleccionar los conceptos de ontología de aplicación en el mensaje. El AIPS los separa de los propios conceptos de aplicación que se definen en el protocolo de ontología. FIPA ha estandarizado un tipo de expresión de contenido, FIPA-SL, [FIPA 2002]. También se han especificado otros tipos de expresión de contenido, como W3C-RDF y un lenguaje de restricción, pero estos no maduraron hasta convertirse en especificaciones estándar.
Fig. 2. La interacción MAS se especifica en términos de una lista de campos con encabezados para definir los protocolos AIPS particulares utilizados y otros campos como el remitente, el receptor, etc.
Los protocolos de mensajería a menudo se definen en términos de una estructura sintáctica simple (metadatos) para mensajes como una secuencia ordenada de campos clave-valor, por ejemplo, protocolos IETF TCP/IP o estructuras de datos jerárquicas, por ejemplo, el lenguaje de marcado extensible W3C. XML. Los metadatos para ayudar a la comunicación del agente generalmente incluyen los nombres del remitente y el receptor vinculados a las direcciones de red, el tipo de mensaje (el tipo de acto comunicativo FIPA), el tipo de interacción (proceso) del que forma parte, la ontología del contenido y la lógica del contenido que se utiliza, el tiempo salidas para respuestas e ID de mensajes para identificar otros mensajes a los que responde. El protocolo de codificación permite que el intercambio de mensajes use múltiples codificaciones como Stings, XML y bit-eficiente, esta última fue diseñada para usarse en enlaces de red de menor ancho de banda. La especificación FIPA FIPA00084 define el uso de múltiples protocolos de transporte de mensajes asíncronos confiables para el intercambio de mensajes, por ejemplo, HTTP asíncrono [FIPA 2002].
El Lenguaje Semántico (SL) se utiliza para definir la semántica de los actos comunicativos de FIPA CAs como una lógica de actitudes y acciones mentales, formalizada en un lenguaje modal de primer orden con identidad; consulte la Especificación de la biblioteca de actos comunicativos de FIPA (véase [FIPA 2002] para obtener detalles de esta lógica). Para que el remitente planee o pretenda establecer un acto comunicativo, se deben especificar tanto las condiciones previas (las razones por las que se selecciona el acto) como las condiciones (posteriores) que deben cumplirse cuando se completa el acto.
Fig. 3. Ejemplo de fórmula lógica modal de primer orden para definir la semántica de un mensaje de acto comunicativo de tipo petición.
Fig. 4. Sintaxis para intercambiar mensajes tipo Acto Comunicativo (CA).
Para un acto comunicativo dado, el primero se denomina efecto racional o RE, y el segundo, condiciones previas de factibilidad o FPs, que son las calificaciones del acto. Para cada CA, su semántica se ha definido en términos del estado intencional expresado por el agente emisor y el RE y FP asociados para seleccionar y enviar el CA enviado. La Figura 3 define la semántica del mensaje para una intención expresa del remitente para un mensaje de tipo CA de solicitud de ejemplo de un agente remitente (sender agent) AC a un agente receptor (receiver agent) AH. En un marco informático típico que implementa el modelo FIPA CA, los mensajes se representan en una codificación de tipo cadena o XML para el intercambio (Figura 4).
La mayoría de los protocolos de mensajería también describen y definen elementos arquitectónicos activos que actúan como nodos de mensajería para enviar y recibir mensajes. Normalmente se definen tres tipos principales de elementos arquitectónicos activos de mensajería: iniciadores de mensajes o clientes de comunicación para solicitar servicios; participantes que reciben solicitudes de mensajes y actúan como proveedores de servicios; y mediadores como intermediarios o servicios de directorio que actúan entre estos [Decker et al. 1997].
FIPA especificó originalmente tres tipos distintos de elementos mediadores activos: un servicio de transporte de mensajes; un servicio de directorio; y un servicio de asociación de nombres unido al servicio de gestión. Por motivos de eficiencia de mensajería, la mensajería no se modeló como una entidad de servicio activo distinta en especificaciones de arquitectura posteriores, como la especificación de arquitectura abstracta FIPA0001 [FIPA 2002]. La especificación de la arquitectura abstracta se puede cosificar en diferentes plataformas de agentes concretos; consulte la Figura 1. En la Especificación de gestión de agentes, FIPA00023 [FIPA 2002], se define un modelo de plataforma de agente de tipo específico que reifica el modelo de arquitectura abstracta. Esto define un servicio de directorio basado en agentes y un nombre basado en agentes y un servicio de administración de agentes. Estos se pueden consultar para descubrir otros agentes en la plataforma y su estado.
3. Características y limitaciones del modelo FIPA
No existe un modelo semántico holístico para vincular los protocolos individuales en el AIPS, por ejemplo, para facilitar la verificación cruzada de que, el tipo de solicitud CA definido por una instancia de protocolo de mensaje, tiene una subacción coincidente definida por una instancia de protocolo de lógica de contenido y que, un CA de tipo de consulta definida por una instancia de protocolo de mensaje, tiene una variable libre coincidente definida por una instancia de protocolo de lógica de contenido para contener los resultados de una consulta. Esta falta de estructura holística se complica aún más por la falta de una representación de ontología común en los diferentes protocolos del AIPS. Por ejemplo, el CA se define mediante una lógica modal, la IP se define mediante AUML que no tiene una semántica interpretable por máquina y la estructura del mensaje se define como una sintaxis. Cranefield et al. [2005] propusieron una ontología que se puede usar para interconectar los conceptos en diferentes subcapas de ACL para tener una representación en línea de la semántica estructural de toda la ACL. Sin embargo, hay una desventaja en el uso de una sola representación de ontología pesada para todo el mensaje. Esto hace que el análisis de los mensajes sea más complejo. limita el rendimiento de las aplicaciones de mensajería de tipo de alto rendimiento y restringe el razonamiento lógico, por ejemplo, para manejar la lógica de predicados de primer orden pero no, para manejar una lógica basada en la incertidumbre.
3.1. Protocolo Acto Comunicativo
3.1.1. Uso de las semántica BDI en los Actos Comunicativos
La semántica de los CA se ha definido formalmente en términos de una lógica modal. Hay varias ventajas de usar un modelo lógico formal de este tipo para la comunicación, como una mayor expresividad. Por ejemplo, la capacidad de diferenciar entre las dos verdades de que un agente que conoce una acción específica, o un conjunto de acciones, logra un objetivo frente a un agente que cree que se puede lograr un objetivo, sin conocer un conjunto específico de acciones para ayudar a lograrlo [Louis y Martinez 2004].
La semántica FIPA CA es vista por la actitud mental del remitente o modelo BDI. Aunque existen principios para transferir la actitud mental en términos de creencia e intención del emisor al receptor, inherentes al modelo, la interpretación real del efecto intencional del emisor en el agente receptor se considera relativa a cada agente y personalizable por cada agente. FIPA no especifica los algoritmos para que los motores de reglas BDI interpreten la intención del remitente en el receptor, aunque esto ha sido propuesto y discutido varias veces en las reuniones de FIPA.
El significado de una CA varía según el contexto. Es probable que la estandarización de la semántica de una CA funcione en algunos contextos, pero no en todos. Ejemplos de esto incluyen: un agente que no necesita ser estrictamente sincero, un agente que desea confirmar un acuerdo anterior, un agente que actualiza información continuamente y un agente que desea retirar información específica de agentes seleccionados en lugar de desconfirmar información. [Pitt y Mamdani 1999]. Red et al. [2002] también presentan un argumento similar para no fijar absolutamente la semántica de la CAN individual, sino para especificar un marco que permita que algunas dimensiones de una CA varíen en tiempo de ejecución. Proponen un enfoque que denominan fijación semántica en el que las condiciones previas y posteriores de una CA y las creencias de la CA pueden variar y controlarse según la posición que tome un agente y su libertad para actuar en relación con las normas que se establecen durante la interacción de tipo de contrato. Sin embargo, se necesitan subinteracciones adicionales, que pueden implicar múltiples rondas y votaciones para acordar la semántica de la CA entre las partes. Sin embargo, esto puede aumentar significativamente la sobrecarga de cálculo de la interacción y este enfoque extendido propuesto para corregir la semántica aún puede no ser universal.
Se presume que los agentes actúan con sinceridad en las interacciones, que siempre dicen la verdad y se creen unos a otros. La suposición de sinceridad se usa en muchos modelos MAS, ya que es más fácil diseñar una interacción cooperativa cuando se supone que esto es cierto. Los agentes no pueden tratar de mentir sobre las creencias que comunican. Sin embargo, esta postura parece poco realista en el comercio electrónico real.
Otras críticas y limitaciones del modelo BDI son las siguientes. Hay una serie de variaciones diferentes de las teorías de BDI en términos del número y la elección de las modalidades, por ejemplo, la intención se implica como una modalidad o se define directamente como una modalidad. Los modelos BDI tienen axiomizaciones incompletas y pueden ser computacionalmente complejos o incluso intratables. El modelo BDI se centra en la transferencia privada de creencias e intenciones entre individuos. No tiene en cuenta la interacción social o de terceros y las limitaciones asociadas. Los modelos BDI rara vez se enfocan en cuestiones pragmáticas como la gestión de creencias e intenciones, por ejemplo, cómo se establecen las creencias, cómo lidiar con la precedencia inconsistente, parcial, probabilística, conflictiva, cíclica y de creencias en un sistema abierto. Estos pueden hacer que el modelo sea computacionalmente complejo o incluso intratable. Tampoco está claro cómo la actitud mental de un remitente percibe las operaciones que no son de un agente, por ejemplo, aquellas que resultan en fallas inexplicables.
Algunas construcciones del lenguaje, como las construcciones temporales Before y After, se referencian implícitamente pero no se definen formalmente en la especificación semántica de CA. Además, la semántica está subespecificada en el sentido de que mientras los agentes receptores reciben CA sobre las intenciones y creencias del emisor, los agentes receptores son libres de llevar a cabo sus acciones internas, como cambiar creencias, que pueden ser consistentes o inconsistentes con las del emisor. CALIFORNIA. Además, el agente remitente no recibe información de que el efecto deseado, es decir, el objetivo o la razón para realizar la acción, ha resultado [Pitt 1999]. Por lo tanto, Wooldridge [2000] argumenta que la semántica no es verificable.
La semántica FIPA ACL se enfoca en transferir la actitud mental del emisor a uno o más receptores pero no se consideran modelos de sociedad o terceros [Singh 1998]. En un modelo semántico de tipo sociedad, los agentes desempeñan diferentes roles dentro de la sociedad y estos roles definen compromisos sociales asociados que restringen la forma en que los agentes que desempeñan un rol deben actuar y comunicarse. Por ejemplo, un agente puede asignar una tarea a otros agentes, lo cual es consistente con su actitud mental, pero la tarea puede no estar permitida debido a restricciones organizacionales, es decir, el agente no tiene la autoridad para llevar a cabo la tarea a pesar de que tiene la capacidad para hacerlo.
3.1.2. Uso de semántica alternativa (a BDI) para FIPA-ACL.
Semántica del modelo de programación de contratos: la comunicación del agente se puede especificar sin especificarse formalmente. Hay muchos MAS patentados que interactúan en sistemas cerrados de esta manera. Por ejemplo, el modelo KQML o Knowledge Query Metal Language utiliza un tipo de modelo de programación por contrato para especificar su semántica en términos de condiciones previas, condiciones posteriores y condiciones de finalización para cada una de las CA KQML. Al establecer las condiciones previas, se especifica un filtro o restricciones para desencadenar el manejo de eventos. Las condiciones posteriores describen los estados de las partes que interactúan, suponiendo que se completen con éxito. Las condiciones de finalización definen el estado de lo que realmente sucedió.
Contexto IP como CA la Semántica:
El modelo del Protocolo de interacción FIPA hace un intento rudimentario de modelo social en el sentido de que la interacción está relacionada con los roles organizacionales de las partes que interactúan y la semántica de cada CA en una IP se interpreta dentro del contexto de la IP.
Compromisos semánticos basados en convenciones sociales:
Jones y Parent [2003] argumentan que los compromisos de los agentes a menudo confunden dos tipos de normas denominadas “preservativas” y “constitutivas”.
Los primeros son los que controlan previamente las actividades existentes, por ejemplo, la regulación del tránsito, mientras que los segundos son los que crean o constituyen la actividad misma, por ejemplo, las reglas del juego. De ahí que Jones abogue por un modelo de actos de comunicación basado no en intenciones o compromisos, sino en convenciones públicas. Este tipo de modelo también ha sido retomado en un nuevo subcampo propuesto de MAS llamado Sistemas Normativos de Agentes Múltiples, especificaciones de MAS basadas en el comportamiento normativo (como debería ser) en lugar del comportamiento real (como es), que mantuvo su primera conferencia principal en 2005.
Un artículo de introducción de Boella et al. [2005] cita un trabajo anterior de Meyer y Wieringa [1993], que explica que los sistemas normativos están íntimamente relacionados con la lógica deóntica. La lógica deóntica proporciona un medio para especificar lo que debería suceder si ocurren comportamientos ilegales pero posibles. Los nuevos operadores modales se utilizan para indicar el estado del comportamiento: es decir, si es o no legal (normativo). FIPA discutió la semántica de tipo de lógica deóntica a principios de la década de 2000, pero esto no maduró para ingresar a ninguna especificación estándar.
3.1.3. La definición del conjunto estándar de CA.
FIPA ha estandarizado un conjunto básico de CA que figura en la Tabla I. Hay varias clasificaciones distintas pero relacionadas para los tipos de CA que se centran principalmente en la postura intencional de la CA en términos de: afirmar la veracidad de la información, dirigir o delegar acciones, prometer comprometerse a acciones futuras, expresando el estado mental del remitente y actos declarativos por parte del remitente. En la Tabla I, se utiliza una clasificación ampliada para las CA basada en parte en las funciones de comunicación genéricas de Roman Jakobson, citado en Ferber [1999] y en parte basada en una clasificación de CA según la postura intencional. Las principales adiciones realizadas por Jakobson son la definición de CA de tipo fático que buscan establecer, controlar, prolongar e interrumpir, es decir, ayudar a controlar la comunicación. Además, se distingue entre directivas mediadas y directivas no mediadas. La extensibilidad del modelo de CA se puede lograr mediante la composición de nuevas CA compuestas a partir de las existentes; por ejemplo, ver la CA de basura en la Tabla I.
Tabla I. Tipos de Actos Comunicativos FIPA (CAs)
Sin embargo, hay algunos tipos de CA que faltan en el conjunto básico de FIPA como se indica a continuación.
— Las CA de FIPA son en su mayoría asertivas y directivas, como consultas y solicitudes; Se pueden simular compromisos que prometen un compromiso con alguna acción futura (por ejemplo, una interacción de acuerdo con la solicitud se usa como algo similar a prometer tratar de cumplir con la solicitud en el futuro; no hay directivas de tipo permisivo o prohibitivo que se usen para administrar, para autorizar el acceso a los componentes de la infraestructura, no hay CA declarativas o expresivas poéticas [Singh 1998].
Tabla II. Protocolos de interacción FIPA
— Labrou et al. [1999] argumentan que faltan FIPA CA para apoyar la facilitación, como intermediación, recomendación y contratación. Sin embargo, desde entonces, se agregaron las CA de Propagación y Proxy de FIPA y se definieron las IP de Intermediación y Reclutamiento.
— Aunque las CA de FIPA incluyen algunas CA de tipo fático, por ejemplo, la CA de rechazo, falla, no entendido, acuerdo y cancelación, esto está incompleto. FIPA, por ejemplo, no admite especificaciones para comandos básicos como sondeo y comprobación y para modalidades de control como bloqueo, inmediato, etc. [Charlton et al. 2000; Elio y Petrinjak 2005].
— KQML tiene dos subtipos de tipo asertivo de CA, tell (un mensaje para crear, eliminar o modificar información y responder (un mensaje síncrono para responder a un mensaje anterior), mientras que FIPA-CA solo incluye informar.
3.2. Patrones de CA: características del modelo IP
En la práctica, una CA individual se usa con frecuencia en patrones de interacción. Un diseñador de un MAS tiene que decidir si dejar que la semántica de los mensajes individuales determine la semántica de las conversaciones o dejar que la semántica de los mensajes individuales esté determinada en cierta medida por el contexto de la interacción y poder variar esto entre diferentes conversaciones En la práctica, los agentes practicantes utilizan ambos enfoques. La forma más sencilla de diseñar interacciones es utilizar protocolos preespecificados o estereotipos de interacción. Sin embargo, los agentes pueden entablar una conversación significativa con otros agentes, simplemente siguiendo cuidadosamente el protocolo conocido que se relaciona con los roles de cada uno en la interacción y las organizaciones. FIPA ha estandarizado un conjunto de conversaciones estéreo típicas o IP que van más allá del tipo de interacción de solicitud-respuesta sincrónica o notificación asincrónica utilizada en la computación distribuida convencional; véase la Tabla II.
Las direcciones IP estándar tienen cierta flexibilidad limitada, por lo que el iniciador puede cancelar las conversaciones, rechazarlas u otros participantes pueden fallar. A nivel de aplicación, el modelo IP también es extensible porque las interacciones se pueden anidar dentro de otras interacciones; por ejemplo, una interacción puede necesitar la autorización de otra autoridad para llevar a cabo alguna acción solicitada.
Un enfoque más flexible es generar interacciones sobre la marcha según el estado actual y el contexto de las comunicaciones, pero esto es computacionalmente intensivo y, a menudo, se evita en la práctica. Hay varios otros candidatos útiles para las IP estándar, por ejemplo, para respaldar las introducciones y votaciones de agentes sin mediación.
Los aspectos de la comunicación fática, como los efectos de la cancelación de acciones, la asincronía y la terminación anormal o inesperada de IP y cómo señalar explícitamente un cambio a IP anidadas, no se abordan explícitamente. También hay un problema relacionado con la semántica BDI de la CA de cancelación, que se define para cancelar cualquier CA única que tenga duración. Esto da problemas cuando queremos que la CA afecte a una IP que tiene duración y que está formada por CA individuales que individualmente no tienen una duración significativa, es decir, no podemos cancelar, o impedir que se complete, una CA individual que ya está hecho, por ejemplo, registrar una instancia de la CA de solicitud en la IP de Suscripción. Es posible que los PI deban diseñarse a nivel individual para que sean reversibles.
3.3. Plataforma de agentes (AP)
Como se mencionó anteriormente, es importante no reemplazar los servicios maduros actuales con los equivalentes de los agentes a menos que los beneficios superen las desventajas. En las primeras versiones de las especificaciones FIPA (1997–1998), la especificación de transporte de mensajes se modelaba como un agente, pero esto tiene una desventaja: menor eficiencia. La transferencia de un solo mensaje entre agentes siempre requería enviar al menos dos mensajes, uno para pedirle al agente de transporte que enviara un mensaje y el otro para que el agente de transporte enviara el mensaje. Por lo tanto, en especificaciones FIPA posteriores, el transporte de mensajes se modela como un servicio sin agentes.
En algunos casos, es útil especificar las interfaces de servicio en un nivel más abstracto que se puede cosificar en diferentes especificaciones concretas específicas porque las especificaciones concretas evolucionan o porque las especificaciones de servicio necesitan ajustarse a las limitaciones de infraestructuras informáticas particulares. En las primeras versiones de la Especificación de transporte de agentes, FIPA especificó el uso de un único transporte de mensajes de línea base, el transporte IIOP del grupo de gestión de objetos, que era ideal para usar en transacciones de bajo volumen, redes alámbricas y redes privadas (sin cortafuegos). Sin embargo, cuando se consideró el uso de agentes FIPA a través de firewalls, para el procesamiento de muchas transacciones y para entornos inalámbricos, el transporte IIOP se consideró menos que ideal. Luego quedó claro que las interfaces de servicio de los agentes debían ser más flexibles y poder admitir múltiples protocolos de transporte de mensajes.
Hay varias restricciones en la gestión de agentes actuales y los servicios intermedios. Muchos modelos MAS, como el modelo de arquitectura abstracta, exigen el uso de un servicio de directorio, pero es posible que no sean necesarios para la acción entre pares. La interfaz de gestión de agentes se define mediante una ontología basada en marcos. El servicio de directorio actual modelado como el agente DF en la especificación de administración de agentes FIPA no admite tipos adicionales de interacción, como consultas e interacciones de suscripción. Los DF no se pueden federar para admitir los registros de servicio de los agentes que no son de servicio, como los agentes de usuario. La ontología de servicio para un agente especifica el protocolo de interacción que admite un agente, pero no incluye el rol del agente dentro de la interacción. La ontología del servicio DF tampoco define la competencia o la confiabilidad del proveedor del servicio. FIPA ha intentado respaldar un modelo de sistema de sistemas, pero solo ha especificado una organización plana para múltiples servicios de directorio.
Los problemas de transporte incluyen la suposición de un transporte confiable para que los mensajes no se desordenen. Se agregaron campos como un campo de respuesta al encabezado del mensaje de ACL para admitir la administración de mensajes mediante la definición de un identificador para instancias de direcciones IP, pero no se especifica una sintaxis estándar para la estructura de dichos campos.
4. Especificaciones FIPA en relación con otras normas
Actualmente existen entre diez y veinte iniciativas de estándares importantes que están involucradas en la estandarización de la interoperabilidad de sistemas distribuidos y FIPA es solo un tipo particular de estos. Por ejemplo, Singh y Huhn [2005] enumeran nueve cuerpos de estándares diferentes que están desarrollando estándares para SOA: IETF (internet, mensajería y protocolos de gestión de comunicaciones), OMG (lenguaje de modelado UML, CORBA y arquitecturas MDA) W3C (XML, WSDL, SOAP, RDF y OWL), OASIS (UDDI y BPEL4WS), UN/CEFACT (ebXML), WS I (perfiles de interoperabilidad de servicios web), BMI.org (lenguaje de modelado de procesos comerciales), WfMC (coalición de gestión de flujo de trabajo), y FIPA. A esto se pueden sumar, al menos, SQL (interoperabilidad de bases de datos relacionales), los OGC (estándares de Grid and Utility Computing) y Rosettanet (estándares abiertos de procesos de comercio electrónico). Además, los estándares W3C se pueden agrupar en tres subgrupos: la web HTML, la web XML con servicios web y la web semántica (RDF-S, OWL) con servicios asociados.
Sería útil caracterizarlos, compararlos y contrastarlos, evaluar cuáles son los puntos en común y cuáles son las diferencias clave, y luego quizás sugerir algunas direcciones futuras para desarrollar estándares particulares. Hay dos formas principales de abordar dicho análisis. En primer lugar, se podría definir un nuevo marco de referencia canónico; un gran espacio multidimensional donde se mapean y comparan las principales características de cada estándar y los múltiples niveles de comunicación e interacción. En segundo lugar, uno de los estándares podría comparar solo sus propias características con las de los demás. En este subartículo, el alcance es limitado, por lo que el enfoque está en el segundo enfoque, las características de FIPA se usan como dimensiones para comparar selectivamente las características de otros organismos de estándares, es decir, para usar el análisis del modelo FIPA AIPS y AP combinado ; ver Figura 1.
La mayoría de los organismos de normalización enumerados anteriormente basan sus especificaciones de transporte de mensajes en el transporte HTTP y en los formatos de intercambio y codificación XML. El otro grupo más pequeño de OMG, FIPA e IETF son más abstractos y tienen los beneficios de poder intercambiar protocolos y codificaciones de manera más flexible para su uso en entornos particulares, por ejemplo, donde el uso de XML más detallado, es decir, comparar el N3 codificación de RDF en comparación con la codificación XML equivalente para RDF. En un nivel sintáctico de interacción, FIPA ha desarrollado codificaciones más eficientes (en bits) que se pueden usar para la interacción a través de transportes de bajo ancho de banda (inalámbricos) a través de dispositivos móviles a servicios. Esto se demostró en el proyecto CRUMPET [Poslad et al. 2001].
En el nivel de aplicación de la interacción, existen varias distinciones importantes entre FIPA y otros enfoques. La Web y SQL se basan en un enfoque minimalista para especificar el conjunto de primitivas de comunicación. Gran parte de la interacción web se basa en dos primitivas de comunicación; notificaciones de tipo solicitud-respuesta síncrona y respuesta asíncrona. El intercambio de información SQL se basa en el llamado conjunto CRUD de primitivas de comunicación de Crear, Leer o consultar, Actualizar y Eliminar. Por el contrario, FIPA define unas veinte primitivas de comunicación diferentes. Menos puede parecer mejor ya que esto minimiza la redundancia y la confusión al seleccionar el uso de primitivas de comunicación superpuestas.
En la Web y en los modelos informáticos distribuidos convencionales, los protocolos diferencian entre diferentes tipos de respuesta utilizando códigos de respuesta específicos del protocolo de aplicación de valor único. Esto hace que el control y las transcodificaciones sean más complejos cuando es necesario orquestar servicios que utilizan diferentes protocolos. Por el contrario, en el modelo FIPA AIPS, los mensajes de tipo de control se abstraen de los protocolos específicos de la aplicación en un subconjunto genérico de CA de mensajes de control fáticos como falla, rechazo, no entendido, acordado, etc. Estos pueden usarse en un estándar a través de aplicaciones y protocolos heterogéneos, lo que facilita el control y la coordinación. El modelo FIPA CA naturalmente permite incluir más contexto semántico en los mensajes.
Esto puede brindar a las aplicaciones información más comprensible sobre eventos inesperados. Además, el conjunto más rico de primitivas FIPA CA puede conducir a procesos de interacción más flexibles. Las empresas y las aplicaciones suelen utilizar patrones específicos de primitivas de comunicación individuales y esta es actualmente un área de gran actividad en muchos organismos de normalización. Aquí se aplican varios términos relacionados, algunos organismos de normalización se centran en los procesos, otros en los flujos de trabajo, otros en la coordinación, otros en las conversaciones, otros en la orquestación (controlador centralizado) y otros en la coreografía (control descentralizado). La semántica de estos enfoques no está clara y, por lo tanto, no está claro en qué se diferencian. Una comparación también se ve agravada por el alto estado de flujo de diferentes especificaciones, ya que el interés en ellas cambia en un corto espacio de tiempo.
FIPA ha definido un conjunto de patrones y procesos de interacción reutilizables que son genéricos y se pueden usar convenientemente en protocolos y dominios de aplicaciones heterogéneos. La semántica de los modelos de proceso de interacción FIPA actualmente es débil y se basa en gráficos AUML. Un ejemplo de la falta de expresividad semántica de la representación del modelo FIPA IP es que es típico en una subasta en inglés que el participante que hace la última oferta no envíe ninguna respuesta al siguiente CFP, pero no está claro cómo especificar mejor esto. . Parece evidente que otros estándares de interoperabilidad han especificado un apoyo más explícito a la flexibilidad y cambian dinámicamente las interacciones. Van der Aalst et al. [2002] presentan un análisis basado en patrones de flujo de trabajo y lenguajes de comunicación como BPML, BPEL4WS, XLANG, WSFL y WSCI. Estos usan diferentes patrones explícitos para dividir y fusionar interacciones, algo que el modelo FIPA IP no define explícitamente.
FIPA se ha centrado desde el principio en el soporte y la semántica asociada para el intercambio de contenido (información y tareas) y para los servicios. Toda esta área aún está madurando, y bien puede pasar al menos una década antes de que haya un intercambio y acuerdos generalizados para datos y servicios semánticos; esto se debe principalmente a que los acuerdos para un mundo TIC diverso se volverán más desafiantes. Actualmente, la mayoría de los estándares de interacción empresarial siguen siendo mucho más sintácticos que semánticos.
Hay una diferencia clave en la forma en que se ha incorporado la semántica del contenido en el Modelo FIPA en comparación con la Web Semántica. La Web Semántica parece haberse centrado en dos modelos: el uso de una ontología liviana sin lógica, como RDF y RDF-S, y el uso de una ontología pesada con una lógica incorporada específica, como OWL, el Lenguaje Web de Ontologías. Por el contrario, FIPA desde el principio ha especificado un modelo en el que las ontologías específicas de la aplicación se pueden asociar con lógicas de tipos múltiples. Este último tiene la ventaja de que, por ejemplo, en el dominio de las predicciones meteorológicas, el dominio del tiempo se puede asociar con la lógica de incertidumbre para responder preguntas como la probabilidad de que haya viento y lluvia en verano en el Reino Unido1.
Mientras que en el dominio del transporte, se puede usar el razonamiento temporal para asegurarse de que el almuerzo terminará antes de que comience la reunión de la tarde. Tenga en cuenta que todavía hay una falta de consenso dentro de la Web Semántica sobre cómo modelar y combinar el razonamiento del tipo de regla dentro del modelo de la Web Semántica, más de 5 años desde que se propuso por primera vez [Horrocks et al. 2005]. No se prevé que se pueda crear una única lógica universal para satisfacer diversas necesidades de razonamiento.
Sin embargo, es ciertamente cierto que una serie de iniciativas de estándares han realizado un esfuerzo significativo para madurar los modelos de servicios semánticos. La motivación para evolucionar a partir de los servicios web es que mediante el uso de anotaciones semánticas para describir servicios y recursos, las tareas de descubrimiento, selección, negociación y vinculación de servicios podrían automatizarse. Petrie et al. [2007] informan los resultados de un ejercicio de copa de desafío para mejorar mejores enfoques y desarrollar una comprensión común de las diversas tecnologías destinadas a facilitar la automatización de la mediación, la coreografía y el descubrimiento de servicios web utilizando anotaciones semánticas.
Las ventajas y desventajas se exploran entre los enfoques existentes, como DIANE (un método para el emparejamiento, la selección, el enlace y la invocación de servicios automatizados, que se utiliza en los escenarios de descubrimiento), WebML/Webratio, jABC/jETI, WSMX (entorno de ejecución de modelado de servicios web, la implementación de referencia de WSMO, la ontología de modelado de servicios web), METEOR-S (proyecto de procesos y servicios web semánticos de la Universidad de Georgia) y SAWSDL (anotaciones semánticas para WSDL). Estos seis enfoques se están implementando y analizando con respecto a dos escenarios: un escenario de mediación se refiere a hacer que un sistema de gestión de pedidos heredado sea interoperable con sistemas externos, y un escenario de descubrimiento se refiere al descubrimiento dinámico, selección, vinculación e invocación del servicio de envío más apropiado. para un conjunto de solicitudes de envío dadas. Esto todavía está bajo investigación. En comparación, el modelo de servicio semántico de FIPA es bastante simple y es anterior al uso de WSDL o OWL-S. Se basa en un servicio de directorio de agentes que admite una IP de solicitud y una ontología de descripción de servicio basada en tramas.
Lyell [2002] informa sobre el desarrollo de una puerta de enlace entre Web Services y FIPA MAS, que permite a los agentes que ofrecen servicios externos a un AP anunciarlos en un Registro UDDI. Se presentó un mapeo que permite mapear la “Descripción del servicio” de FIPA en entradas UDDI de manera ad hoc.
FIPA se ha centrado en especificar e intercambiar un contexto de comunicación semántica por contenido para dominio genérico. Esto es muy controvertido y contrasta con un historial de procesos de servicio de codificación fija y el contexto del proceso en servicios de aplicación específicos. FIPA ha propuesto dos modelos de contexto de comunicación semántica diferentes hasta la fecha: uno basado en una lógica modal de intención de creencia para las CA y otro basado en un modelo de proceso de interacción.
Finalmente, la combinación de los modelos FIPA AIPS y AP, en contraste con los modelos de servicio web y web semántica, forma naturalmente un modelo holístico, que puede usar múltiples transportes y codificaciones de mensajes y que puede admitir semántica multilógica para el intercambio de contenido y contexto de comunicación. .
5. Discusión del estado actual de FIPA y direcciones futuras
El desarrollo de los estándares FIPA MAS ha involucrado a una variedad de partes interesadas que intentan especificar protocolos que sean lo suficientemente expresivos para que los diseñadores e implementadores los usen y que puedan integrarse en las infraestructuras existentes. A menudo, los estándares pueden necesitar una fase de mantenimiento y es posible que no funcionen bien inicialmente en aplicaciones específicas. Es posible que los estándares no siempre puedan garantizar un diseño uniforme y la interoperabilidad en un entorno de servicio abierto. Los beneficios de los estándares como un habilitador clave para apoyar la interoperabilidad y la interacción de servicios abiertos en la práctica conducen a una masa crítica de usuarios y promueven una mayor aceptación.
FIPA (la Fundación para Agentes Físicos Inteligentes) se estableció en 1996 como una asociación internacional sin fines de lucro de empresas que acordaron compartir esfuerzos para producir especificaciones estándar de tecnologías de agentes genéricos que fueran: producidos de manera oportuna, acordados internacionalmente y utilizables en un gran número de aplicaciones, de modo que se logre un alto nivel de interoperabilidad entre aplicaciones. Desde entonces, FIPA ha involucrado en varias etapas a más de 60 miembros de más de 20 países diferentes en todo el mundo y generó un conjunto de especificaciones que pasaron por 3 ciclos de revisión: FIPA97, FIPA98 y FIPA2000.
Varias plataformas de agentes distintas, aplicaciones y cientos de proyectos colaborativos han utilizado las especificaciones FIPA. El conjunto básico de especificaciones, disponible en FIPA [2002], se ha utilizado durante varios años, y es lo suficientemente sólido y efectivo como para ser promovido a Estándar y creía que estas especificaciones ahora eran estables, maduras, bien entendidas y listas. para la implementación comercial y el despliegue. En 2005, FIPA se convirtió en una nueva actividad de estándares IEEE.
El principal impacto del FIPA se puede resumir en:
— Especificaciones estándar para MAS AIPS y AP, siendo FIPA ACL el modelo más utilizado para MAS.
— Muchos despliegues de proyectos en, por ejemplo, FACTS, MARINER, Agentcities, etc. En una encuesta en Internet realizada en 2003 por el autor, se identificaron 80 proyectos diferentes que reportaron el uso de FIPA.
— Se han desarrollado de diez a veinte conjuntos de herramientas FIPA MAS diferentes, incluidos cinco de código abierto. De los de código abierto, uno todavía está vivo (JADE), pero todavía hay varios comerciales que admiten FIPA, como JACK. JADE tiene una gran cantidad de extensiones de terceros, incluido un complemento de entorno Protegee Ontology que permite exportar ontologías modeladas visualmente fuera de línea para su uso con agentes JADE.
— JADE Board: cinco empresas de telecomunicaciones crearon un foro para promover el kit de herramientas JADE FIPA para aplicaciones de telecomunicaciones móviles.
— JCP o Java Community process ha desarrollado JAS, Java Agent Service, JSR87, una API de referencia para la arquitectura abstracta FIPA y el protocolo de mensajes FIPA.
— La interoperabilidad de FIPA MAS y el cumplimiento de FIPA se han probado en varios ensayos y proyectos.
— AUML, el lenguaje de modelado de agentes, se originó en FIPA Modeling TC.
— El modelo FIPA que puede reutilizar otras especificaciones estándar, por ejemplo, codificaciones de mensajes XML y transporte HTTP.
5.1. Proyectos FIPA
Uno de los primeros proyectos importantes para probar las especificaciones FIPA97 y FIPA98 fue el proyecto EU FACTS, 1998–2000. Esto utilizó tres aplicaciones de dominio principales para probar los estándares en escenarios de la vida real: mercado de viajes personales (PTM), comercio electrónico y entretenimiento y transmisión audiovisual (AVEB). Núñez-Suárez et al. [2000] reportan sus principales experiencias en el desarrollo de la aplicación PTM de la siguiente manera: el modelo FIPA redujo la cantidad de trabajo requerido para lograr la interoperabilidad a nivel de aplicación; El soporte de FIPA proporciona un entorno informático distribuido abierto para integrar componentes dispares y, si bien el uso de tecnologías como protocolos de interacción, lenguajes de comunicación de agentes y ontología puede ser común dentro de la comunidad de agentes, no lo son dentro de la industria de desarrollo de software convencional. También informaron que el protocolo CA era lo suficientemente intuitivo y completo para usarse en la mayoría de los casos y que había un problema de interoperabilidad de transporte al usar el transporte IIOP en un entorno de múltiples proveedores. Charlton et al. [2000] informaron experiencias en el desarrollo de la aplicación FACTS AVEB que se centró en la semántica de la comunicación MAS.
La semántica de ACL se basa en el intercambio de un modelo privado de creencias e intenciones. Los desarrolladores de aplicaciones convencionales las encuentran complejas de construir y operar y, a menudo, no pueden distinguir entre intenciones y deseos en la implementación. La semántica de ACL se basa en una agencia social o modelo organizacional que puede usarse para superar los problemas del modelo de agencia mental. Tenga en cuenta que desde entonces, FIPA ha especificado un conjunto de protocolos de interacción predefinidos con un modelo de agencia social asociado. El manejo de errores es una preocupación cuando los agentes son autónomos. Los agentes pueden retrasar las respuestas, lo que hace que el remitente no esté seguro de lo que sucedió. Desde este informe, FIPA ha agregado campos de tiempo de espera a los encabezados de protocolo. También hay un soporte limitado para depurar y monitorear plataformas, pero desde entonces esto se ha abordado en los kits de herramientas MAS.
Pitt y Mamdani [1999] informan sobre sus experiencias en el uso de las especificaciones FIPA en el proyecto MARINER para desarrollar un MAS para control de carga en redes inteligentes. Sus principales críticas a los estándares FIPA ACL son, en primer lugar, que no está claro si la semántica ACL debe interpretarse como una especificación informativa que brinda orientación a los desarrolladores, o como una especificación normativa que brinda condiciones que los propios agentes son responsables de satisfacer. En segundo lugar, cualquier semántica de comunicación variará según el contexto y, por lo tanto, será difícil de estandarizar.
Argumentan que los protocolos de interacción o las conversaciones deberían ser el punto focal para la estandarización de la ACL, ya que pueden proporcionar el contexto para la comunicación.
El principal objetivo del proyecto Agentcities.rtd, 2001–2003, fue crear un sistema abierto global para proporcionar las condiciones en las que probar: Agentes basados en FIPA, servicios y otras tecnologías tales como delegación, coordinación, modelado de dinámica y en particular comunicación basada en la semántica formal [Willmott 2002]. Los principales logros fueron un modelo de arquitectura de red, un modelo de referencia para la interoperabilidad de servicios semánticos en entornos abiertos, un marco para la composición de servicios en un entorno abierto, un conjunto de pruebas para plataformas de agentes compatibles con FIPA y varios servicios de agentes basados en ontologías multidominio y una red de banco de pruebas en vivo que se utilizó activamente. En un proyecto asociado de Agentcites.Net, cerca de 150 MAS autónomos se conectaron al banco de pruebas.
5.2. API de software y herramientas FIPA
Los desarrolladores de aplicaciones suelen utilizar kits de herramientas de agentes, en lugar de tener que desarrollar sus propias implementaciones de software de las especificaciones FIPA, y superponer su software de aplicación. Esto facilita el desarrollo y la cantidad de pruebas, suponiendo que los conjuntos de herramientas de los agentes se sometan a algún tipo de evaluación. Durante la vigencia de FIPA, se han desarrollado decenas de kits de herramientas de agentes FIPA que han implementado conjuntos de especificaciones FIPA. Aquí mencionamos algunas de las principales iniciativas de código abierto: JADE [Bellifemine et al. 1999], FIPA-OS [Poslad et al. 2000] y ZEUS [Nwana et al. 1999], ya que se utilizaron en las pruebas de interoperabilidad FIPA. Además, un proceso JCP o Java Community desarrolló JAS, Java Agent Service, JSR87, API de referencia para la especificación de arquitectura abstracta FIPA que se implementó en el kit de herramientas del agente KAoS [Bradshaw et al. 2004]. Estos kits de herramientas suelen admitir implementar y proporcionar API y herramientas de la siguiente manera:
— API e implementaciones de códecs para analizar mensajes FIPA ACL de acuerdo con FIPA CA y otras especificaciones ACL relacionadas. — API para soportar la gestión de agentes según se define en la especificación FIPA 00023 [FIPA 2002].
— Diferentes tipos de plantillas de agentes para producir agentes que luego pueden comunicarse entre sí utilizando soporte de múltiples capas.
— Gestión de mensajes y conversaciones para soportar protocolos de interacción. —Configuraciones de plataformas dinámicas para admitir múltiples plataformas de agentes, múltiples tipos de persistencia, lo que permite la integración con software de persistencia heredado y múltiples codificaciones.
— Interfaces abstractas y patrones de diseño de software. — Herramientas de diagnóstico y visualización.
Las API de software y los analizadores para modelos computacionales de las especificaciones se pueden desarrollar fácilmente para intercambiar mensajes ACL a nivel sintáctico. Uno de los desafíos técnicos clave es cómo implementar un software que pueda manejar los mensajes de ACL a nivel semántico. Dejando de lado por el momento las preocupaciones sobre la validez y la verificabilidad de la semántica CA, Louis y Martinez [2004] han informado de su esfuerzo por desarrollar un marco de trabajo informático para manejar la semántica CA. Esto se ha implementado como un complemento de JADE. Este marco tiene cuatro elementos: un ciclo de actividad para enviar y recibir mensajes, operaciones reflexivas para acceder y actualizar sus creencias, una representación semántica (SR) para procesar mensajes con creencias expresadas en FIPA-SL y principios de interpretación semántica (SIP) para producir y consumir SR.
Consideran tres formas principales de implementar su modelo: usar un motor de inferencia dedicado para la lógica modal, pero estos tienden a no estar disponibles públicamente; usar un motor de reglas de propósito general para ayudar a procesar los mensajes, pero esto requiere cierto mapeo del modelo semántico a las reglas del motor de reglas; y finalmente desarrollar un motor de reglas ad hoc patentado. Tenga en cuenta que su marco se centra en la transferencia de creencias pero no en la transferencia de intenciones, aunque afirman que esta última se puede agregar fácilmente.
Un enfoque alternativo es que la mayoría de los desarrolladores de aplicaciones de agentes eligen en la práctica no usar e implementar la semántica de CA, sino usar alguna semántica informal basada en el contexto de interacción. La semántica intencional de un agente, es decir, el significado de la CA, vendrá determinada por el estado en que se encuentre el agente, en relación con el protocolo de interacción (IP) acordado a priori y el tipo de la próxima CA recibida o enviada. En Pitt y Bellifemine [1999], se describe una implementación JADE de dicha semántica intencional impulsada por IP.
5.3. Pruebas de interoperabilidad y cumplimiento de FIPA
Varios autores, como Wooldridge [2000], Pitt [1999] y Louis y Martinez [2004], han señalado que la conformidad con la especificación solo requiere que el remitente respete la condición de factibilidad para enviar el mensaje, pero no requiere la receptor de un mensaje para respetar la parte del efecto racional de la semántica CA. Hay otros desafíos relacionados con el modelo intencional mencionado anteriormente. También existe el problema adicional de la manejabilidad de la computación cuando se verifica la interacción de servicios abiertos, donde un sistema interactúa con su entorno y cuyo comportamiento depende de esta interacción, un problema que no se considera en las referencias anteriores. Estos problemas hacen que los modelos computacionales y las pruebas de conformidad de MAS con la semántica formal sean un desafío en la práctica.
La preocupación de los desarrolladores y usuarios de aplicaciones es menos si la comunicación de la aplicación se puede verificar formalmente con algún modelo teórico subyacente que si pueden aplicar un modelo y si el modelo funciona como se espera. En la práctica, las implementaciones computacionales de los modelos, no los modelos teóricos, pueden evaluarse para pasar una serie de pruebas. La construcción de estas pruebas ad hoc y la especificación de las condiciones de prueba y las propiedades de prueba es específica de la aplicación.
Hay varias formas en que las implementaciones de las especificaciones se probaron en la práctica. Las especificaciones se prueban como parte de la fase experimental en el progreso de una especificación de preliminar a experimental a estándar. Las especificaciones se prueban como parte de una buena práctica de desarrollo dentro de proyectos específicos que utilizaron estas especificaciones.
Además, se realizaron varias pruebas específicas de las especificaciones en reuniones seleccionadas de FIPA, en 1999 y 2001, en las que se probó la interoperabilidad entre las plataformas de agentes JADE, FIPA-OS y ZEUS. Los resultados de esta prueba demostraron que las especificaciones de FIPA se consideraron bastante completas, en el sentido de que solo se necesitaron cambios menores para permitir que las “funciones centrales” se probaran e interoperaran.
5.4. Actividades Actuales y Direcciones Futuras para FIPA
Después del intenso interés en MAS y su estandarización por parte de FIPA a fines de la década de 1990 y principios de la de 2000, el despliegue generalizado de MAS parece estar todavía lejos en el futuro. En 2004, como resultado del proyecto Agentlink3 de la UE, Luck et al. publicaron una hoja de ruta actualizada para la tecnología de agentes. [2004]. En este artículo, los autores expresan varios juicios y predicciones, incluido el desarrollo por etapas de MAS desde MAS cerrado en aproximadamente 2004, a algunos sistemas cerrados de dominios cruzados, hasta sistemas abiertos en dominios específicos y, finalmente, a MAS abierto verdaderamente abierto y totalmente escalable. en la 4ª fase, alrededor de 2009 en adelante. Ya estamos comenzando a ver más organismos de estándares principales que realizan investigación y desarrollo aplicados que tradicionalmente eran dominio exclusivo de la comunidad MAS.
Están poniendo un esfuerzo humano significativo para progresar en elementos particulares, como el intercambio de información basado en ontologías y, más recientemente, los servicios semánticos. Recientemente, parece que los servicios de la Web Semántica están siendo impulsados más por el servicio Web que por la comunidad de la Web Semántica. Esto lleva a la pregunta natural sobre si la especificación de MAS debe detenerse dentro de una organización dedicada como FIPA o ser absorbida por esfuerzos más convencionales que ciertamente tienen mayores recursos, a menudo están más orientados a los negocios y se basan en necesidades reales versus percibidas.
Sin embargo, aún quedan por abordar toda una serie de desafíos de I + D de MAS. Una estrategia sensata parece que es mejor dejar que los problemas de definición del intercambio de información semántica y el uso de la semántica para descubrir e invocar automáticamente los servicios continúen progresando fuera de FIPA con FIPA explicitando cómo los agentes pueden utilizar mejor este esfuerzo.
Hay dos cuestiones centrales: primero, ¿qué debería hacer FIPA con sus especificaciones actuales? ¿Debería trazar una línea o tratar de desarrollarlas de una manera evolutiva versus revolucionaria? Esto podría generar incompatibilidades con las especificaciones existentes, según algunas de las limitaciones destacadas anteriormente en este artículo. Las oportunidades de mejora incluyen la definición de mecanismos para sintetizar de manera más flexible las nuevas CA y el desarrollo de una especificación de una visión multilateral de la semántica de las CA en lugar de una única, como las actitudes mentalistas. Se podría proponer una interacción de servicio de middleware de agente más flexible que aproveche modelos como los servicios de directorio que se han avanzado en otros organismos de normalización.
En segundo lugar, es necesario identificar las áreas novedosas y fructíferas en las que FIPA puede trabajar de manera rentable. Estos se ilustran con las actividades actuales de FIPA en los siguientes grupos de trabajo; consulte [FIPA 2007] para obtener más detalles sobre estos y cómo participar. El objetivo principal del Grupo de Trabajo de Interoperabilidad de Agentes y Servicios Web (AWSI WG) es llenar el vacío de comunicación entre los agentes y los servicios Web. Los agentes deben poder ubicar, negociar e interactuar con los servicios web sin problemas y viceversa.
El Grupo de Trabajo de Comunicaciones de Agentes Humanos (HAC WG) está trabajando para proponer extensiones, es decir, CA adicionales a FIPA AIPS para facilitar la comunicación de agentes con humanos en general. El objetivo del Grupo de Trabajo de Agentes Móviles (MA WG) es definir nuevas especificaciones para interfaces de comunicación y protocolos de red para la reubicación eficiente, confiable y segura de códigos y datos, seguimiento de ubicación y comunicación transparente de ubicación, gestión de infraestructura en forma de superposición redes para el descubrimiento de servidores de agentes y definición dinámica de itinerarios e interoperabilidad entre diferentes kits de herramientas de agentes móviles en tiempo de ejecución. El objetivo del Grupo de Trabajo de Agentes Nómadas P2P (P2PNA WG) es desarrollar y definir una especificación para Agentes Nómadas P2P, capaz de ejecutarse en dispositivos pequeños o integrados, y para respaldar la implementación distribuida de aplicaciones para dispositivos de consumo, comunicaciones celulares y robots. a través de una red P2P pura.
Agradecimientos
Las opiniones expresadas en este artículo son las del autor. Los debates anteriores de los miembros activos de FIPA, en particular de los miembros de la Revisión del Grupo de estudio de especificaciones de FIPA (ROFS-SG), han hecho valiosas contribuciones a este artículo y se reconocen. También se agradece la crítica constructiva de los revisores para ayudar a enfocar este artículo.
Bibliografía
AGENTCITIES.RTD Project. 2002. Deliverable D1.4 Final Report. Available from http://www. agentcities. org/EURTD/.
BELLIFEMINE, F., POGGI, A., AND RIMASSA, G. 1999. JADE—A FIPA-compliant agent framework. In Proceedings of the 4th International Conference and Exhibition on the Practical Application of Intelligent Agents and Multi-Agents (PAAM’ 99), 97–108.
BOELLA, G., VAN DER TORRE, L., AND VERHAGEN H. 2005. Introduction to normative multiagent systems. In Proceedings of the 1st International Symposium on Normative Multiagent Systems (NorMAS05), 1–7.
BRADSHAW, J.M., ET AL. 2004. Making agents acceptable to people. In N. Zhong and J. Liu, Eds., In telligent Technologies for Information Analysis: Advances in Agents, Data Mining, and Statistical Learning, Springer-Verlag, 355–400.
CHARLTON, P., CATTONI, R., POTRICH, A., AND MAMDANI, E. 2000. Evaluating the FIPA Standards and its role in achieving cooperation in multi-agent systems. In: Multi-Agent Systems, Internet and Application, Minitrack Proceedings of the 33rd Annual Hawaii International Conference on System Sciences.
CRANEFIELD, S., PURVIS, M., NOWOSTAWSKI, M., AND HWANG, P. 2005. Ontologies for interaction protocols, In Ontologies for Agents: Theory and Experiences, V. Tamma, S. Cranefield, T. Finin, and S. Willmott, Eds., Basel, Birkhauser, 1–17. ¨
DECKER, K., SYCARA, K., AND WILLIAMSON, M. 1997. Middle-agents for the Internet. In Proceedings of the 15th International Joint Conference on Artificial Intelligence, Nagoya Japan, 578–583. ELIO, R. AND PETRINJAK, A. 2005. Normative communication models for agent. Auton. Agents Multi-Agent Syst. 11, 3, 273–305.
EHRLER, L. AND CRANEFIELD, S. 2004. Executing agent UML diagrams. In Proceedings of the 3rd International Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS’04). ACM Press, 906–913.
FERBER, J. 1999. Multi-Agent Systems: An Introduction to Artificial Intelligence. Addition-Wesley. FIELDING, R. T. 2000. Architectural styles and the design of network-based software architectures, PhD thesis, University of California, Irvine.
FIPA SPECIFICATIONS. 2002. Multi-agents system standard specifications. http://www.fipa.or/ specifications.
FIPA WORKING GROUPS AND STUDY GROUPS. 2007. Multi-agents system standard specifications. http://www.fipa.org/subgroups.
GENESERETH, M. R. AND KETCHPEL, S. P. 1994. Software agents. Commun. ACM, 37, 7, 48– 53. HORROCKS, I., PARSIA, B., PATEL-SCHNEIDER, P., AND HENDLER, J. 2005. Semantic Web architecture: Stack or two towers? In Principles and Practice of Semantic Web Reasoning (PPSWR05). Springer Verlag, 37–41.
JONES, A. J. I. AND PARENT X. 2003. Conventional signalling acts and conversation. Workshop on agent communication languages. In Advances in Agent Communication: International Workshop on Agent Communication Languages, Dignum, F., Ed. Lecture Notes Computer Science, 2922, Springer, 1–17.
LABROU, Y., FININ, T., AND PENG, Y. 1999. The current landscape of agent communication languages. Intell. Syst. 14, 2, 45–52.
LOUIS, V. AND MARTINEZ, T. 2005. An operational model for the FIPA-ACL semantics. In Proceed ings of the AAMAS Workshop on Agent Communication (AC05). 101–113.
LUCK, M., MCBURNEY, P., AND PREIST, C. 2004. A manifesto for agent technology: towards next generation computing J. Autonom. Agents Multi-Agent Syst. 9, 3, 203–252.
LYELL, M. 2002. Interoperability, standards, and software agent systems. In Proceedings of the 23rd Army Science Conference, Orlando, FL.
MEYER, J-J. AND WIERINGA, R., EDS. 1993. Deontic logic: A concise overview. In Deontic Logic in Computer Science: Normative System Specification. John Wiley, 3–16.
NUÑEZ-SUÁREZ,, J. 2000. Experiences in the use of FIPA agent technologies for the development of a personal travel application. In Proceedings of the 4th International Conference on Autonomous Agents, 357–364.
NWANA, H., NDUMU, D., LEE, L., AND COLLIS, J. 1999. ZEUS: A tool-kit for building distributed multi-agent systems. In Appl. AI. J. 13, 1, 129–186.
ODELL, J., VAN DYKE, P.H., AND BAUER, B. 2001. Representing agent interaction protocols in UML. In Ciancarini, P. and Wooldridge, M., Eds., Agent-Oriented Software Engineering, Springer, 121– 140.
PETRIE, C., MARGARIA, T., KUSTER ¨ , U., LAUSEN, H., AND ZAREMBA, M. 2007. SWS challenge: Status, perspectives and lessons learned so far. Special Session Comparative Evaluation of Semantic Web Service Frameworks at the 9th International Conference on Enterprise Information Systems (ICEIS07).
PITT, J. AND MAMDANI, A. 1999. Some remarks on the semantics of FIPA’s agent communication language. Autonom. Agents Multi-Agent Syst. 2, 4, 333–356.
PITT, J.V. AND BELLIFEMINE, F. 1999. A protocol-based semantics for FIPA’97 ACL and its imple mentation in JADE. In Proceedings of the 6th Congress of the Italian Association for Artificial Intelligence (AI*IA’99).
POSLAD, S. J., BUCKLE, P., AND HADINGHAM, R. 2000. The FIPA-OS agent platform: Open source for open standards. In Proceedings of the 5th International Conference on the Practical Application of Intelligent Agents and Multi-Agents (PAAM00), 355–368.
POSLAD, S. AND CHARLTON, P. 2001. Standardizing agent interoperability: The FIPA approach. In M. Luck, V. Mar´ik, O. Stepankov ´ a, and R. Trappl, Eds. ´ Multi-Agent Systems and Applications, Lecture Notes Computer Science, vol. 2086, Springer Verlag, 98–117.
REED, C. A., NORMAN, T. J., AND JENNINGS, N. R. 2002. Negotiating the semantics of agent communication languages. Comput. Intel. 18, 2, 229–252.
SEARLE, J. R. 1969. Speech Acts. Cambridge University Press, Cambridge, UK SINGH, M. 1998. Agent communication languages: Rethinking the principles. IEEE Comput. 13, 12, 40–47.
SINGH, M.P. AND HUHN, M.N. 2005. Service-Oriented Computing: Semantics, Processes, Agents. John Wiley & Sons, Ltd.
VAN DER AALST, W.M.P., DUMAS, M., TER HOFSTEDE, A.H.M., AND WOHED, P. 2002. Pattern based analysis of BPML (and WSCI). Tech. rep. FIT-TR-2002-05, Queensland University of Technology, Brisbane.
WILLMOTT, S. CALISTI, M., AND ROLLON, E. 2002. Challenges in large-scale open agent mediated economies. Lecture Notes in Computer Science, vol. 2531, Springer Verlag, 325–340.
WOOLDRIDGE, M. 2000. Semantic issues in the verification of agent communication languages. Autonom. Agents Multi-Agent Syst. 3, 1, 9–13.
-
The Summer of 2007 was unusually one of the wettest on record in the UK. ACM ↩