DOCUMENTO DE ARQUITECTURAS DE SOFTWARE

Una arquitectura de software es la base para representar la estructura de un sistema de una manera abstracta y que sea fácil de interpretar el modelo que encapsula. Una buena arquitectura explica claramente los elementos que la forman y la manera en que se comunican entre ellos.

En este capítulo hablaremos de manera general sobre las arquitecturas de software, sus característicos y estilos arquitectónicos. Posteriormente, explicaremos algunas arquitecturas basadas en agentes, P2P y de dispositivos móviles, analizando sus ventajas y desventajas.

Finalmente, haremos un análisis comparando las diferentes arquitecturas para poder obtener lo mejor de cada una y que nos sirva de base para nuestro proyecto de grado.

1. GENERALIDADES

Para poder hablar de algún tema en particular lo primero que se debe tener claro es su definición y características. A continuación, hablaremos de una manera general sobre qué es una arquitectura de software, sus elementos, objetivos y cómo debe ser el lenguaje que se utiliza para expresarla. Finalmente, hablaremos sobre los diferentes estilos arquitectónicos que existen, analizando sus ventajas y desventajas.

1.1. DEFINICIÓN:

La arquitectura de software de un programa o de un sistema computacional está definida por la estructura, comprendida por los elementos de software, las propiedades visibles de esos elementos y las relaciones entre ellos. Se incluyen los siguientes elementos:

• La descripción de los componentes (servidores, clientes, bases de datos, filtros, capas en un sistema jerárquico, etc. ) con los cuales se construyen los sistemas

• Las interacciones (llamadas a procedimientos, protocolos C/S, protocolos de acceso a BD, etc) entre esos componentes

• Patrones para guiar la composición

• Restricciones sobre dichos patrones [AC2004].

1.2. OBJETIVOS:

Algunos de los objetivos que se buscan alcanzar al diseñar una arquitectura de software son los siguientes:

• Comprender y mejorar la estructura de las aplicaciones complejas.

• Reutilizar dicha estructura (o partes de ella) para resolver problemas similares.

• Planificar la evolución de la aplicación, identificando las partes que cambian y las que permanecen constantes de la misma, así como los costos de los posibles cambios.

• Analizar la corrección de la aplicación y su grado de cumplimiento respecto a los requisitos iniciales.

• Permitir el estudio de algunas propiedades específicas del dominio.

Una de las mayores utilidades de utilizar una arquitectura es que un mismo diseño arquitectónico puede servir para dos aplicaciones distintas (ej. los patrones de diseño). Esto facilita el desarrollo de nuevas aplicaciones y reduce el tiempo que se invierte en dicho proceso. Pero así como trae beneficios, toca tener mucho cuidado en el momento de elegir una arquitectura ya que, una arquitectura errónea puede traer consigo muchos problemas.

1.3. LDA

Un LDA es un lenguaje o notación para describir una arquitectura software e incluye principalmente :

• La descripción de componentes, conectores y enlaces entre ellos [MN2004].

• Las herramientas para la verificación de la arquitectura y el prototipado rápido [MN2004].

Existen LDAs de propósito general y otros de dominio específico (DSLs). Los requisitos que debe tener estos lenguajes se pueden clasificar de la siguiente manera [AC2004]:

• Composición

o Debe describir el sistema como una composición de partes

• Configuración

o Debe describir la arquitectura independientemente de los componentes

• Abstracción

o Debe describir los roles abstractos que juegan los componentes

• Reutilización

o Debe permitir reutilizar componentes, conectores, y arquitecturas

• Heterogeneidad

o Debe permitir combinar descripciones heterogéneas

• Análisis

o Debe permitir diversas formas de análisis de la arquitectura

1.4. ESTILOS ARQUITECTÓNICOS

Un estilo de arquitectura es una clasificación de los sistemas de software en grandes familias cuyos integrantes comparten un patrón estructural común. Este estilo captura paradigmas de computación y comunicación utilizados para tratar con los problemas de programación de una clase en particular [HO2004]. En otras palabras, indican los tipos de componentes y conectores involucrados en una arquitectura. Los diferentes estilos de las arquitecturas tiene sus fortalezas y debilidades y, ciertos estilos hacen que sea más fácil o más difícil trabajar con diferentes obstáculos Las propiedades que caracterizan cada estilo es lo que determina la elección de uno u otro.

Un estilo de arquitectura debe tener tres elementos básicos:

• Una notación bien definida para capturar el estilo de desarrollo de la arquitectura.

• Un método bien definido para producir y analizar formalmente modelos basados en la especificación capturada en la notación.

• Un método bien definido para producir una implementación basada en la especificación capturada en la notación.

Un estilo provee la semántica para realizar los diagramas de arquitectura. Es decir, un estilo establece el significado de los diferentes conectores que se pueden dibujar entre los componentes funcionales.

Los sistemas complejos, en su mayoría, son descritos mediante la combinación de dos o más estilos básicos de arquitectura.

1.5. CLASIFICACIÓN DE ESTILOS

Los estilos arquitectónicos se clasifican en diferentes categorías. En la tabla No. 1 vemos la clasificación general.

Categoría Estilos

SISTEMAS BASADOS EN FLUJOS

Filtros y Pipes

Procesamiento por lotes

SISTEMAS CALL/RETURN Sistemas Principal/subrutinas

Sistemas OO

Capas jerárquicas

COMPONENTES INDEPENDIENTES

Procesos de comunicación

Cliente / Servidor

Sistemas de Acontecimientos o Eventos

MÁQUINAS VIRTUALES

Interpretes

Sistemas basados en el conocimiento

SISTEMAS CENTRADOS EN DATOS

Bases de Datos (Repositorios)

Sistemas de HiperTexto

Sistemas de pizarra

Tabla 1Clasificación Estilo Arquitectónico

1.5.1. SISTEMAS BASADOS EN FLUJOS

Se basan en el patrón “pipes and filtres” (tuberías y filtros). Este consta de un conjunto de componentes denominados filtros conectados entre sí por tuberías que transmiten datos desde un componente al siguiente. Cada filtro trabaja de manera independiente de los componentes que se encuentran situados antes y después de ella. Se diseñan de tal modo que se esperan un conjunto de datos en un determinado formato y obtiene como resultado otros datos de salida en un formato específico. Si el formato degenera en una única línea de transformación, se denomina secuencial batch (Procesamientos por lotes) [EU2001].

FILTROS Y TUEBERÌAS

Este estilo está compuesto por un grupo de filtros (filters), los cuales tienen un conjunto de entradas y un conjunto de salidas. Cada componente lee las entradas y las transforma en salidas. La comunicación entre los filtros se realiza a través de tuberías (pipes). En la figura No. 1 vemos el esquema de este estilo arquitectónico.

Figura 1 Filtros y Tuberías

En la tabla No. 2, que se presenta a continuación, se analizan las ventajas, desventajas y restricciones de este estilo.

Restricciones Ventajas Desventajas

Los filtros deben ser independientes. No deben compartir estado con otros filtros.

Los filtros realizan la labor independientemente del flujo de entrada.

Permite entender el sistema global en términos de la combinación de componentes

Soporta de buena manera la reutilización. Los filtros son independientes de sus vecinos

Facilidad de Mantenimiento y mejora

Facilidad de diagnóstico (rendimiento, deadlocks)

Soportan la ejecución concurrente

No aconsejado para cuando se necesita interactividad

Problemas de performance ya que los datos se transmiten en forma completa entre filtros

Tabla 2 Filtros y Tuberías

1.5.2. SISTEMAS CALL/RETURN

Los estilos agrupados en esta categoría permiten a los desarrolladores de software realizar estructuras de programación fáciles de modificar y escalar.

SISTEMAS OO

Este estilo arquitectónico ha tenido gran aceptación y es de mucho uso en el desarrollo de aplicaciones. Las representaciones de los datos y las

operaciones están encapsuladas en un tipo abstracto de datos u objeto. Por lo tanto, los componentes son objetos y se relacionan entre ellos a través de invocaciones de métodos.

En la figura No. 2 vemos un diagrama que representa el estilo de los Sistemas Orientados a Objetos.

Figura 2 Sistemas OO

El Sistema OO tiene algunas restricciones. Estas se muestran en la tabla No. 3 junto con las ventajas y desventajas de este estilo.

Restricciones Ventajas Desventajas

Los objetos son responsables de la integridad de sus representaciones

Dicha representación es ocultada al resto de los objetos

Gracias al invariante de ocultación es posible reemplazar la Implementación sin que afecte a los clientes

Para invocar métodos de un objeto se debe conocer su identidad

Efectos colaterales

Tabla 3 Sistemas OO

CAPAS JERÁRQUICAS

Al hablar de capas jerárquicas hacemos referencia al estilo organizado jerárquicamente en capas, donde cada capa provee servicios a la capa superior y es servido por la capa inferior.

Los componentes de este estilo corresponden a cada una de las capas las cuales se conectan entre ellas utilizando protocolos de interacción (Llamadas a procedimientos. Llamadas a métodos).

Cada nivel tiene asociado una funcionalidad:

• Niveles bajos: Funciones simples, ligadas al hardware o al entorno.

• Niveles altos: Funciones más abstractas.

La figura No. 3 nos ilustra gráficamente el estilo jerárquico. En la figura se distingue cómo se comunican las diferentes capas y que funcionalidad va en cada capa.

Figura 3 Capas Jerárquicas

//VOY AQUI Restricciones

• La interacción está limitada a las capas adyacentes Ventajas

• Facilita la descomposición del problema en varios niveles de abstracción. • Soporta la mejora, los cambios solo afectan a las capas vecinas • Se pueden cambiar las implementaciones respetando las interfaces con las

capas adyacentes. Desventajas

• No todos los sistemas pueden estructurarse en capas. • Es difícil encontrar la separación en capas adecuada

Aplicación

• Torres de protocolos de comunicación. • Sistemas operativos. • Compiladores.

2.1.3 COMPONENTES INDEPENDIENTES 2.1.3.1 Sistemas de Acontecimientos o Eventos

Descripción

• En lugar de invocaciones de procedimientos explicitas o directas, un componente anuncia uno o más eventos y otros componentes registran el interés en un evento asociando un procedimiento a dicho evento.

• La ocurrencia de un evento causa la invocación “implícita” de procedimientos en otros módulos.

• Los componentes son los módulos cuyas interfaces ofrecen un conjunto de procedimientos y de eventos

• Los conectores incluyen llamadas a procedimientos tradicionales así como el ligado de eventos con llamadas a procedimientos

Restricciones

• Quien anuncia el evento no conoce a que componentes afecta el evento • No se pueden hacer asunciones acerca del orden de procesamiento

Ventajas

• Provee un robusto soporte de reusabilidad • Facilita la evolución del sistema

Desventajas

• Perdida de control en el comportamiento del sistema • Problemas en el intercambio de datos • Es difícil asegurar la corrección global del sistema

2.1.4 SISTEMAS CENTRADOS EN DATOS Como parte central de esta arquitectura aparece un almacén de datos, el cual es accedido de manera frecuente por otros componentes que actualizan, añaden, borran

o modifican dichos almacenes. El software cliente accede a un repositorio central [EU2001]. 2.1.4.1 Sistemas de pizarra

Descripción

• Existen dos tipos de componentes • Una estructura central de datos (representa el estado del proceso) • Componentes independientes (operan en función del depósito de datos) • Las interacciones entre el repositorio y los demás componentes es variable: • La entrada de los datos es seleccionada por los componentes • El estado de los datos del repositorio selecciona el proceso a ejecutar

(pizarra) Ventajas

• Posibilita la integración de agentes. • Adecuado para la resolución de problemas no deterministas. • Se puede resumir el estado de conocimiento en cada momento del proceso

Desventajas

• Estructura de datos común a todos los agentes • Problemas de carga a la hora de chequear y vigilar el estado de la pizarra.

1. ARQUITECTURAS BASADA EN AGENTES

Los agentes pueden ser concepto de estudio de varias áreas, como lo son inteligencia artificial, sistemas distribuidos, ingeniería de software, redes y sistemas autónomos

entre otras, lo cual hace que su definición este influenciada según sea el área en la cual tengamos nuestro interés [JAS200], nosotros creemos que una definición apropiada de agente es: “Los agentes son simplemente un sistema computacional con la capacidad de tomar acciones autónomas en un medio, para así cumplir sus objetivos”[GW2001]. Según la anterior definición, encontramos que los agentes como tal están ligados directamente a su medio, y por lo tanto podrán modificar este medio con la finalidad de cumplir su objetivo (igual que las personas). También, los agentes, en ocasiones tendrán la oportunidad de basar sus decisiones según criterios mas estructurados, como puede ser información histórica o experiencias del agente con el medio, pero vale aclarar que esto no es obligatorio (según la definición). Los agentes como tal pueden comunicarse con otros agentes, fo rmando sociedades de agentes, que le sirven al mismo para cumplir sus tareas; al igual que lo hacen las personas los agentes pueden delegar tareas a otros agentes o pueden competir por un recurso, y esto hace que nazca un lenguaje o protocolo con el cual los agentes se puedan comunicar fácilmente y sin ambigüedades de definiciones en los conceptos que quieren dar a entender de un agente a otro(a diferencia de las personas). El protocolo que se a definido para la comunicación entre agentes es el KQML que sinifica “Knowledge query and manipulation language”.La estructura de este protocolo es [GW2001]:

(KQML-performative :sender <palabra> (nombre agente que envía el mensaje) :reciver <palabra> (nombre agente que recibe el mensaje) :language <palabra> (lenguaje en que se comunican(ejemplo prolog)) :ontology <palabra> :content <expresión> (puede ser vació si el tipo del mensaje lo define)) ejemplo: (Cancelar :sender Hugo :reciver Alex :language prolog :ontology mundo-tesis :content (esta vació ya que el mismo tipo de mensaje define la acción)).

3.1 FIPA (Foundation for intelligent Physical Agents) Es una organización que desarrolla estándares para software de agentes para así permitir que diferentes sistemas de agentes interactúen, mas claramente se puede ver una definición de lo que es FIPA en su misión: “la promoción de tecnologías y especificaciones de interoperabilidad que permitan el trabajo interno de sistemas de agentes inteligentes dentro del comercio y la industria”[FIPA]. En la siguiente figura podemos ver y aclarar lo que propone FIPA con respecto a la construcción de plataformas de agentes:

En la figura diferenciamos seis(6) aspectos importantes en los cuales se debe basar cualquier plataforma de agentes, y estos son[FIPASC00023J]:

• AMS(Agent Management System): Es un servicio de paginas blancas, que

tiene como funciones principales:

o Es el encargado de mantener un directorio de agentes y encargarse del ciclo de vida de un agente.

o Controla y supervisa el uso de la plataforma.

• DF(Directory Facilitator):Es un servicio opcional. Donde los agentes publican sus servicios para que otros agentes los puedan utilizar. (Un Servicio de paginas amarillas)

• MTS(Message Transport System): es la forma que existe para la comunicación entre dos agentes en diferentes plataformas de agentes[FIPA00067].

• Agente: Es un proceso computacional que implementa la autonomía y la

funcionalidades de comunicación dentro de una aplicación. Los agentes se comunican usando un lenguaje de comunicación entre agentes llamado ACL (Agent Comunication Language). Un agente es el actor fundamental de una plataforma de agentes quien combina una o mas servicios que son publicados en el DF.

• Plataforma de Agentes(AP): Es la infrastuctura física en donde se

desarrollan los agentes. El AP esta compuesto por las maquinas, sistemas operativos, el software que soporta los agentes,los componentes de manejo de un agente definidos por FIPA (DF, AMS , MTS), y los agentes.

• Software: Describe todo lo que no es una agente pero que este utiliza para

ejecutar instrucciones o alguna funcionalidad en especifico.

Existen en la actualidad muchas plataformas de agentes basadas en las especificaciones de FIPA, pero en este artículo nos vamos a detener a analizar la plataforma JADE y BESA. 3.2 JADE(Java Agent DEvelopment Framework): JADE es un framework de agentes que está basada en FIPA, y como tal debe tener unos aspectos que debe cumplir toda plataforma de agentes que sea FIPA complaint, y estos son el AMS, DF, agentes y la definición de un protocolo que permita intercambiar mensajes entre agentes, estos mensajes son comúnmente llamados los ACL(agent comunication language) que viene siendo una abstracción del tipo de mensajes que se definieron atrás como KQML. Como tal una plataforma jade tiene un contenedor principal llamado main en donde residen el AMS y el DF, este contenedor main es el primero que debe arrancar en una plataforma jade y posteriormente pueden empezar otros contenedores con sus respectivos agentes , pero siempre teniendo en cuenta que se deben registrar los agentes al contenedor principal (el main).Esto nos da como resultado un sistema de comunicación P2P híbrido[BEL2003] tal y como se muestra en la siguiente figura:

Sistema P2P híbrido

Deteniéndose un poco en este punto se podría pensar que la plataforma jade tiene un punto de falla en el contenedor principal (el main) ya que si este se cae entonces la plataforma toda se vendría al piso, sin embargo los creadores de Jade previeron esto y hicieron que este main, aunque es un (1) agente, puede estar en varias maquinas al mismo tiempo, tal y como lo muestra la siguiente figura[BEL12003]:

En la plataforma del lado izquierdo solo existe un main pero jade da la opción que puedan existir mas de un main tal y como vemos en la figura del lado derecho, así si por ejemplo el main-container-1 no prestara mas este servicio por cualquier motivo entonces, la plataforma quedaría de la siguiente manera [BEL12003]:

3.2.1 Ventajas de JADE [RIM2003]:

• Es una plataforma probada y sobre la cual se han desarrollado aplicaciones. • Se tiene una extensión de jade para dispositivos móviles llamada LEAP,

donde aparentemente la extensión de agentes desarrollados para JADE normal es igual para un agente desarrollado en LEAP.

• Se tiene un contenedor principal que es donde reside el AMS, con la flexibilidad de tenerlos en forma de cluster para así dar una plataforma que es tolerable a fallos.

• La comunicación entre agentes dentro de una misma plataforma puede ser vía RMI o por medio de llamados locales, esta complejidad es resuelta por el contenedor que es el que sabe donde se podría encontrar el agente, esto se hace a través de técnicas de cache en donde cada contenedor mantiene una tabla (cache)llamada LADP (Local Agent Descriptor Table), mientras el contenedor principal tiene una tabla global de toda la plataforma, llamada GADP (Global Agent Descriptor Table).

3.2.2Desventajas de Jade:

• No tiene desarrollado el mecanismo de guardas, que es el que nos permite darle una mejor selección a los mensajes que llegan a un agente, por lo tanto esto es tarea del programador a la hora de implementar cada comportamiento.

• Como un agente para jade es un solo hilo que tiene su propio control, puede darse el caso que debido a un comportamiento mal programado el agente pierda reactividad ante el entorno.

3.3 BESA(Behavior-oriented, Event-driven and Social-based Agent Framework):

La arquitectura besa esta compuesta por tres niveles: nivel de agente, nivel social y nivel del sistema. En el nivel de agente se trata todo lo referente a sus comportamientos y a los eventos a los cuales reacciona el agente. En el nivel social se trata lo referente a la comunicación que existe entre agentes(a través de un modelo de programación de eventos), “una interacción se puede modelar por un evento bien definido, que se puede asociar a una guarda”. En el nivel de sistema es donde se define el ciclo de vida de los agentes y la administración de éstos [GON2003]. 3.3.1 Ventajas:

• Es un sistema que maneja muy bien el mecanismo de guardas, lo que permite al programador definir un nivel muy fino de granularidad a la hora de plantear los comportamientos de un agente.

• Los comportamientos corren sobre su propio hilo lo que hace que estos no bloqueen el funcionamiento total del agente, al contrario de cómo sucede en JADE.

• Besa deja que el programador solo piense en los comportamientos de su agente llevándolo a un nivel de abstracción mas alto.

• Se puede ver como una plataforma P2P ya que la comunicación entre los agentes es punto a punto y lo mismo pasa con los contenedores de los agentes.

3.3.2 Desventajas:

• Usa el mecanismo de multicast para la comunicación entre contenedores, lo cual lo limita a un dominio.

• Se puede afectar el rendimiento de la red en casos en que los agentes tengan un tiempo de vida muy corto. Esto debido al multicast que es utilizado para mantener las tablas actualizadas del directorio de páginas blancas que tiene cada contenedor.

• La poca documentación que lo soporta. • No se ha probado con muchos ejemplos como si ha sucedido con otras

plataformas de agentes.

2. PEER 2 PEER

La ventaja más importante de las redes P2P radica en que cualquier peer puede proveer servicios (potencialmente), actuando en determinadas ocasiones como un servidor y en otras como un cliente. Esto permite que un servicio no dependa directamente de un solo punto sino por el contrario este servicio puede ser suministrado por cualquier punto dando así soluciones mas escalables donde el servicio no depende de una sola maquina. La computación distribuida es una manera de resolver problemas por medio de separar el problema en subproblemas que pueden ser solucionados de manera independiente por diferentes equipos. Se espera que en el futuro la computación distribuida aproveche las ventajas de redes P2P. Los puntos son configurados para descubrirse de una manera espontánea en la red. Casi siempre solo necesitan interactuar con un número pequeño de peers (vecinos o “amigos”). Los peers pueden unirse o dejar la red en cualquier momento, pero deben siempre anunciar que la comunicación puede perderse a cualquier peer con el que se este comunicando. Los peers se organizan en grupos. Un grupo es una colección de peers que tienen algún interés en común. Cada grupo es identificado por un único ID. JXTA no define cuando, como o porque se crean los grupos. Solo describe como los peers pueden publicar, descubrir, unirse y monitorear los grupos de peers. JXTA define un grupo de seis protocolos basados en XML que estandarizan la manera como los peers son organizados dentro de los grupos de peers, publicando y descubriendo recursos, comunicándose y monitoreándose mutuamente. JXTA establece una red virtual sobre la red física, permitiendo que los puntos interactúen directamente y se organicen independientemente de su localización y conectividad. Los protocolos han sido diseñados para ser fácilmente implementados. Un punto JXTA puede ser cualquier dispositivo conectado (sensores, teléfonos, PDA, PC, servidores, etc) que implementa los protocolos básicos de JXTA. Cada punto es identificado por un único ID, son autónomos y operan independientemente y asincrónicamente de otros puntos. Puede existir alguna dependencia de puntos debido a requerimientos especiales, tales como la necesidad de un gateway, proxies o routers.

Cada punto puede publicar servicios y recursos (CPU, almacenamiento, bases de datos, documentos, etc) para que sean usados por otros puntos. 4.1 Conceptos básicos de P2P 4.1.1 Peer: Cualquier entidad capaz de hacer un trabajo útil y poder comunicar los resultados del trabajo a otra entidad en la red bien sea directa o indirectamente.

• Simple peer • Rendeveus peer guarda en memoria información acerca de otros peers • Router peer: se encarga de dar una ruta a un peer que no tiene conexión

directa con otro peer. 4.1.2 Peer group Conjunto de peers que tienen un mismo interés. Los Peer Groups pueden proveer servicios a los otros peers que pertenezcan al grupo. Este grupo como tal puede ofrecer una serie de servicios que se pueden descubrir a través del advertisement que identifican este grupo en especifico, vale aclarar que uno de los servicios que se debe implementar es el de unirse al grupo(membresía) para que así otros peers puedan vincularse al grupo, si este servicio no es implementado entonces cualquiera puede entrar al grupo fácilmente. 4.1.3 Servicios de red:

• Servicio de peer: si el punto muere el servicio también se muere, muchos puntos pueden tener el mismo servicio pero con identificaciones diferentes.

• Servicio de grupo : esta compuesto por instancias del servicio corriendo en

múltiples miembros del grupo. Y este se publica como parte del peer group advertisement.

4.1.4 Advertisement:

Es la representación de una entidad (Peer), servicio o recurso que este prestando un peer o un peer group como parte de una red p2p. Es necesario que en una red p2p sean definidos protocolos que permitan:

• Encontrar un peer en la red. • Encontrar un servicio que un peer este prestando. • Obtener información de otros peers. • Utilizar los servicios que preste un peer. • Crear, unirse y dejar un grupo. • Crear datos de coneccion para otros peers • Enrutar un mensaje para otros peers.

4.2 JXTA 4.2.1 Protocolos de Jxta: 4.2.1.1 Peer Resolver Protocol(PRP) Permite enviar y recibir consultas (queries) genéricos a través de un manejador (handler) que es el responsable de identificar el servicio no importando en que peer se encuentre, solo viendo si el peer proporciona el servicio. Este protocolo es definido por dos tipos de mensajes (XML):

SSaammpp llee AApppp lliiccaatt iioonnss

SSaammpp llee SSeerrvviicceess

JXTA Applications

JXTA Services

JXTA Core

PPeeeerr GGrroouuppss PPeeeerr PP iippeess PPeeeerr MMoonniittoorr iinngg

PPeeeerr SSeeccuurr iittyy

Any Connected Device

PPeeeerr IIDDss

SSeeaarrcchh IInnddeexxiinngg DDiissccoovvee rr MMeemmbbeerrsshhiipp

IInnssttaanntt MMeessssaaggiinngg FFiillee SS hhaarr iinngg RReessoouurrccee SShhaarr iinngg

CCoollllaabboorraa tt iivvee CCoonntteenntt VViieewweerrss

• Resolver query esta compuesto por los siguientes tags: credencial, nombre del manejador, id de la consulta, numero de hops por los que la consulta a viajado y el query.

• Resolver response esta compuesto por los siguientes tags: credencial, nombre del manejador, id de la consulta y la respuesta.

4.2.1.2 Peer information Protocol(PIP) Sirve para obtener información acerca de un peer en especifico. Se pueden ver dos tipos de mensajes en este protocolo:

• Ping request que se compone por una credencial, id de origen , id destino. • PeerInfo response compuesto por una credencial, id de origen , id destino

,tiempo , timestamp y un advertisement que representa al peer. 4.2.1.3 Endpoint routing prtocol(PEP): Define un conjunto de mensajes request/response procesados por el servicio de enrutamiento con la finalidad de ayudar a un peer a que su mensaje llegue a su destino. Cuando un peer que tiene el perfil de enrutador recibe una consulta acerca de una ruta, si conoce la ruta la envía. En caso contrario busca por la ruta para así poderla devolver. Un endpoint se identifica por una dirección que tiene la siguiente forma <protocolo>://<dirección de red>/<nombre del servicio>/<parámetros que recibe el servicio>

• <protocolo>—el nombre de la red que se utiliza para enviar el mensaje. Ejemplos: tcp, http, y jxtatls.

• <protocolAddress>— la dirección de red con el Puerto por ejemplo 127.0.0.1:80

• <serviceName>—un unico identificador que permite encontrar el servicio remoto

• <serviceParameters>—algunos parámetros únicos que identifican el servicio y su manejador

Usando el protocolo jxta , un peer puede enviar mensajes por medio del Endpoint Routing Protocol tal y como si estuviera directamente conectado al peer remoto, sin embargo el mensaje puede viajar a través de diferentes peers. Si dos peers no se pueden conectar directamente, este protocolo les permite encontrar la forma para que estos peers puedan intercambiar mensajes. a través de rutas de información que se descubren. 4.2.1.4 Peer discovery Protocol(PDP):

Permite encontrar recursos que están representados en forma de advertisement (peers, peer groups , pipe etc). La forma en que este protocolo busca estos advertisements es buscando en su cache. Si no lo encuentra, este le delega la tarea a un rendezveus que tiene pre configurado o buscando uno en la red y este finalmente le devuelve el advertisement que el estaba solicitando, no sin antes guardarlo en memoria para que se pueda utilizar en un futuro. Un peer que no tenga perfil de rendevouz no tiene la obligación de guardar en memoria advertisements pero esto puede mejorar notablemente el desempeño en las búsquedas de advertisements. Este protocolo es definido por dos tipos de mensajes:

• Discovery query. • Discovery response

4.2.1.5 Rendezvous Protocol(PRP) Permite propagar mensajes y controla esta propagación. Este protocolo esta definido por tres tipos de mensajes:

• Lease Request Message — Usado por un peer para obtener permiso de conectarse al rendezvous

• Lease Granted Message— Usado por el rendezvous para aprobar los peers • Lease Cancel Message— Usado por un peer para desconectarse del

rendezvous. 4.2.1.6 Pipe Binding Protocolo(PBP) Usado por las aplicaciones y servicios para comunicarse con otros peers. Pipe es un canal virtual entre dos endpoints este protocolo se basa en la funcionalidad del protocolo endpoint. Los Pipes son canales de comunicación virtuales usados para enviar y recibir mensajes entre servicios o aplicaciones. Proveen la ilusión de un mailbox virtual de entrada y salida que es independiente de la localización de un peer y también es independiente de la topología de la red. Pueden ser implementados diferentes QoS por un pipe. Por ejemplo:

• Asincrónico unidireccional: El punto final envía un mensaje. No hay garantía de que la entrega sea hecha.

• Sincrónico request-response: El punto final envía un mensaje y recibe una respuesta confirmándolo.

• Transferencia en lotes: Transferencia confiable de datos binarios. • Streaming: Transferencia eficiente • Seguro: Transferencia segura de datos.

Existen varios tipos de conexiones usadas por un pipe y estas son:

• JxtaUnicast que solo tiene uno que envía y uno que recibe.

• JxtaUnicastSecur es lo mismo que JxtaUnicast pero la conexión es segura usando el Transport Layer Security (TLS) protocol.

• JxtaPropagate proporciona la funcionalidad de broadcast entre muchos endpoints que envían y muchos endpoints que reciben.

El PBP define dos tipos de mensaje para encontrar un pipe

• The Pipe Binding Query Message—sirve a un peer para preguntarle a otro si este tiene el pipe que el esta buscando(con el pipe id).

• The Pipe Binding Answer Message—para enviar una respuesta a la consulta. 4.3 POINT TO MULTIPOINT La arquitectura P2MP consiste en una estación central que sirve a varios sectores dentro de un rango. Cada sector consiste en un radio de comunicación con un número amplio de usuarios. El ancho de banda es compartido entre los usuarios del sector. Esta arquitectura tiene una topología de árbol por lo que tiene una raíz (Point) que se va abriendo en muchas hojas (Multipoint). Las hojas no pueden comunicarse directamente P2P, siempre tienen que ir primero a la raíz.

[PJ2004]

La arquitectura P2MP es por lo general utilizada en la última milla. En este tipo de arquitectura pueden participar más nodos pero el performance sufre ya que están compartiendo el ancho de banda. 4.4 POINT TO CONSECUTIVE POINT (P2CP)

Una serie de puntos están unidos consecutivamente uno con otro formando una topología de anillo. Los datos van pasando de un punto al otro de manera secuencial pero en el momento en que se llegue a caer un anillo, el tráfico se enruta automáticamente en sentido contrario.

Este sistema es más costoso pero tiene un ancho de banda mayor que los tradicionales P2P que en cierta manera son limitados en el número de puntos que puedan tener.

5. J2ME

Esta versión de Java está enfocada a la aplicación de la tecnología Java en dispositivos electrónicos con capacidades computacionales y gráficas muy reducidas, tales como teléfonos móviles, PDAs o electrodomésticos inteligentes. Esta edición tiene unos componentes básicos que la diferencian de las otras versiones, como el uso de una máquina virtual denominada KVM (Kilo Virtual Machine, debido a que requiere sólo unos pocos Kilobytes de memoria para funcionar) en vez del uso de la JVM clásica, inclusión de un pequeño y rápido recolector de basura y otras diferencias. J2ME contiene una mínima parte de las APIs de Java. Esto es debido a que la edición estándar de APIs de Java ocupa 20 Mb, y los dispositivos pequeños disponen de una cantidad de memoria mucho más reducida. En concreto, J2ME usa 37 clases de la plataforma J2SE provenientes de los paquetes java.lang, java.io, java.util. Esta parte de la API que se mantiene fija forma parte de lo que se denomina “configuración”. J2EE es un superconjunto de J2SE pues contiene toda la funcionalidad de éste y más características, así como J2ME es un subconjunto de J2SE (excepto por el paquete javax.microedition) ya que, como se ha mencionado, contiene varias limitaciones con respecto a J2SE. 5.1 ENTORNO DE EJECUCIÓN

Un entorno de ejecución determinado de J2ME se compone entonces de una selección de:

a) Máquina virtual (KVM). b) Configuración (una configuración es el conjunto mínimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos CLDC O CDC). c) Perfil (bibliotecas Java de clases específicas orientadas a implementar funcionalidades de más alto nivel para familias específicas de dispositivos). d) Paquetes Opcionales.

Cada una de las configuraciones mencionadas anteriormente tiene características propias. Como consecuencia, cada una requiere su propia máquina virtual. La VM (Virtual Machine) de la configuración CLDC se denomina KVM y la de la configuración CDC se denomina CVM. 5.1.1 KVM Su nombre KVM proviene de Kilobyte (haciendo referencia a la baja ocupación de memoria, entre 40Kb y 80Kb). Se trata de una implementación de Máquina Virtual reducida y especialmente orientada a dispositivos con bajas capacidades computacionales y de memoria. La KVM está escrita en lenguaje C. Fue diseñada para ser:

• Pequeña, con una carga de memoria entre los 40Kb y los 80 Kb, dependiendo de la plataforma y las opciones de compilación.

• lta portabilidad. • Modulable. • Lo más completa y rápida posible y sin sacrificar características para las que

fue diseñada.

Sin embargo, esta baja ocupación de memoria hace que posea algunas limitaciones con respecto a la clásica Java Virtual Machine (JVM):

1. No hay soporte para tipos en coma flotante. No existen por tanto los tipos double ni float. Esta limitación está presente porque los dispositivos carecen del hardware necesario para estas operaciones. 2. No existe soporte para JNI (Java Native Interface) debido a los recursos limitados de memoria. 3. No existen cargadores de clases (class loaders) definidos por el usuario. Sólo existen los predefinidos. 4. No se permiten los grupos de hilos o hilos daemon. Cuándo queramos utilizar grupos de hilos utilizaremos los objetos Colección para almacenar cada hilo en el ámbito de la aplicación. 5. No existe la finalización de instancias de clases. No existe el método Object.finalize(). 6. No hay referencias débiles. 7. Limitada capacidad para el manejo de excepciones debido a que el manejo de éstas depende en gran parte de las APIs de cada dispositivo por lo que son éstos los que controlan la mayoría de las excepciones. 8. Reflexión

5.1.2 CVM La CVM (Compact Virtual Machine) ha sido tomada como Máquina Virtual Java de referencia para la configuración CDC y soporta las mismas características que la Máquina Virtual de J2SE. Está orientada a dispositivos electrónicos con procesadores de 32 bits de gama alta y en torno a 2Mb o más de memoria RAM. Las características que presenta esta Máquina Virtual son:

1. Sistema de memoria avanzado. 2. Tiempo de espera bajo para el recolector de basura. 3. Separación completa de la VM del sistema de memoria. 4. Recolector de basura modularizado. 5. Portabilidad. 6. Rápida sincronización. 7. Ejecución de las clases Java fuera de la memoria de sólo lectura (ROM). 8. Soporte nativo de hilos. 9. Baja ocupación en memoria de las clases. 10. Proporciona soporte e interfaces para servicios en Sistemas Operativos de Tiempo Real. 11. Conversión de hilos Java a hilos nativos. 12. Soporte para todas las características de Java2 v1.3 y librerías de seguridad, referencias débiles, Interfaz Nativa de Java (JNI), invocación remota de métodos (RMI), Interfaz de depuración de la Máquina Virtual (JVMDI).

5.2 CONFIGURACIONES

5.2.1 CDC La CDC está orientada a dispositivos con cierta capacidad computacional y de memoria. Por ejemplo, decodificadores de televisión digital, televisores con internet, algunos electrodomésticos y sistemas de navegación en automóviles. La CDC está enfocada a dispositivos con las siguientes capacidades:

• Procesador de 32 bits. • Disponer de 2 Mb o más de memoria total, incluyendo memoria RAM y • ROM. • Poseer la funcionalidad completa de la Máquina Virtual Java2. • Conectividad a algún tipo de red.

5.2.2 CLDC La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en cuanto a capacidad gráfica, cómputo y memoria. Un ejemplo de estos dispositivos son: teléfonos móviles, buscapersonas (pagers), PDAs, organizadores personales, etc. Los dispositivos que usan CLDC deben cumplir los siguientes requisitos:

• Disponer entre 160 Kb y 512 Kb de memoria total disponible. Como mínimo se debe disponer de 128 Kb de memoria no volátil para la Máquina Virtual Java y las bibliotecas CLDC, y 32 Kb de memoria volátil para la Máquina Virtual en tiempo de ejecución.

• Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad. • Ofrecer bajo consumo, debido a que éstos dispositivos trabajan con

suministro de energía limitado, normalmente baterías. • Tener conexión a algún tipo de red, normalmente sin cable, con conexión

intermitente y ancho de banda limitado (unos 9600 bps). 5.2.3 CDC vs CLDC A continuación se presentan las diferencias entre las librerías que soportan cada una de las configuraciones mencionadas anteriormente. La Tabla 1.1 nos muestra las librerías incluidas en la CDC.

La Tabla 1.2 nos muestra las librerías incluidas en la CLDC.

Como podemos ver, el número de librerías incluidas en la configuración CDC es mucho mayor que las de la CLDC. 5.3 PERFILES Un perfil es un conjunto de APIs que dotan a una configuración de funcionalidad específica. Existen unos perfiles que se construyen sobre la configuración CDC y otros sobre la CLDC. Para la configuración CDC tenemos los siguientes perfiles:

• Foundation Profile. • Personal Profile. • RMI Profile.

y para la configuración CLDC tenemos los siguientes:

• PDA Profile. • Mobile Information Device Profile (MIDP). Las aplicaciones que se realizan

utilizando MIDP reciben el nombre de MIDlets.

También existe una gran cantidad de paquetes opcionales que amplían los perfiles; éstos incluyen Wireless Messaging API*, Mobile Media API*, J2ME RMI Optional Package* y el paquete opcional JDBC para CDC Foundation Profile*, al igual que otros que aún están en el proceso de especificación, tal como J2ME Web Services.1. 5.4 COMPONENTES APLICACIONES J2ME Una aplicación J2ME está formada por un archivo JAR que es el que contiene a la aplicación en sí y un archivo JAD (Java Archive Descriptor) que contiene diversa información sobre la aplicación. El gestor de aplicaciones o AMS (Application Management System) es el software encargado de gestionar los MIDlets. El AMS realiza dos grandes funciones:

• Por un lado gestiona el ciclo de vida de los MIDlets. • Por otro, es el encargado de controlar los estados por los que pasa el MIDlet

mientras está en la memoria del dispositivo, es decir, en ejecución. Cuándo un MIDlet comienza su ejecución, está en el estado “Activo” pero, ¿qué ocurre si durante su ejecución recibimos una llamada o un mensaje? El gestor de aplicaciones debe ser capaz de cambiar el estado de la aplicación en función de los eventos externos al ámbito de ejecución de la aplicación que se vayan produciendo. En este caso, el gestor de aplicaciones interrumpiría la ejecución del MIDlet sin que se viese afectada la ejecución de éste y lo pasaría al estado de “Pausa” para atender la llamada o leer el mensaje. Una vez que terminemos de trabajar con el MIDlet y salgamos de él, éste pasaría al estado de “Destruido” dónde sería eliminado de la memoria del dispositivo. Cuándo decimos que el MIDlet pasa al estado “Destruido” y es eliminado de memoria, nos referimos a la memoria volátil del dispositivo que es usada para la ejecución de aplicaciones. Una vez finalizada la ejecución del MIDlet podemos volver a invocarlo las veces que queramos ya que éste permanece en la zona de memoria persistente hasta el momento que deseemos desinstalarlo. MIDlet puede cambiar de estado mediante una llamada a los métodos MIDlet.startApp(), MIDlet.pauseApp() o MIDlet.destroyApp(). El gestor de aplicaciones cambia el estado de los MIDlets haciendo una llamada a cualquiera de los métodos anteriores. Un MIDlet también puede cambiar de estado por sí mismo.

6. SATIN

Los creadores de esta arquitectura tratan de resolver el problema que se presenta actualmente con respecto a las aplicaciones que modelan sistemas móviles, partiendo del beneficio de usar sistemas que se organicen por si solos (Self-Organized System) teniendo en cuenta la lógica móvil como base de esta arquitectura.

1 Pini Mike. Diseño de aplicaciones inalámbricas móviles en http://www.intel.com/espanol/update/contents/mo11031.htm

6.1. Problemática:

El problema que se divisa en aplicaciones para sistemas móviles, según la problemática que muestra SATIN, es la poca adaptabilidad de las aplicaciones con respecto al constante cambio de los requerimientos. Teniendo en cuenta las dificultades que se presentan en sis tema que se auto organizan, y estas son:

• El medio cambiante y las necesidades del usuario, teniendo como limitaciones la heterogeneidad en cuanto a hardware, software, protocolos de comunicación y redes en que se encuentran en los dispositivos.

• El desarrollo estático que muestra el comportamiento de las aplicaciones, refiriéndose a la poca adaptabilidad que tienen en cuanto al usuario.

• Las limitaciones que se tienen cuando se especifica que una aplicación sea auto organizable.

• La forma en que se monitorea el medio cambiante en que se encuentra el dispositivo es difícil de manejar, debido a su flexibilidad (redes ad-hoc).

• Es difícil garantizar la seguridad.

“Un sistema que se auto-organiza es aquel que automáticamente se reconfigura con la finalidad de acomodarse a nuevos requerimientos”[ZAC2003]. 6.3. Lógica Móvil:

Teniendo en cuanta la perspectiva que muestra SATIN la arquitectura se basa en unas primitivas de lógica móvil (LM) que ayudan a:

• La interoperabilidad con aplicaciones remotas y medios que no fueron

tenidos en cuenta al momento de diseño de una aplicación. • La lógica móvil permite tener actualizados los diferentes componentes y

añadir nuevas funcionalidades a una aplicación. • La lógica móvil permite usar adecuadamente los recursos de un punto,

dando la posibilidad de delegar cálculos complejos al medio en que se encuentra el dispositivo.

• La lógica móvil permite usar eficientemente los recursos locales; por ejemplo si una funcionalidad dentro del PC no esta siendo utilizada puede removerse.

“La lógica móvil se refiere a la habilidad de mover partes de una aplicación o migrar un proceso completo de un medio de procesamiento a otro” [ZAC2003].

6.4. Arquitectura:

Satin define su arquitectura básica en forma de capacidades en donde la unidad básica es la “capacidad”(Capability) en donde una “capacidad” incluye meta-data, versión, identificador único y una lista de dependencias a otras capacidades. En donde una funcionalidad se representa por el conjunto de “Capacidades” que pueden ser actualizadas dinámicamente en medios dinámicos (redes ad-hoc).

El modelo de arquitectura que plantea SATIN es el siguiente:

• Advertiser Capability: implementa capacidades de “advertising”. • Discovery Capability: implementa técnicas de descubrimiento de

Capacidades. • Core Capability: es el registro de todas las capacidades, todo

dispositivo que tenga SATIN debe tener un core. • Registrar Capability: es el responsable de registrar “capacidades”.

La anterior figura muestra la arquitectura Satin en un host, que es un conjunto de “capacidades” registradas en un core.

Esta arquitectura nos muestra una posibilidad que permite utilizar la lógica móvil para el beneficio de auto-organizar el desarrollo de aplicaciones para sistemas móviles. Las ventajas que esboza esta arquitectura es apenas natural para dispositivos móviles según las ventajas que plantea la lógica móvil como tal. Por otra parte la forma en que se modulariza la funcionalidad de una aplicación es interesante y cabe anotar que puede ser de gran beneficio para el futuro planteamiento de nuestra arquitectura ya que puede ser una idea a seguir.

Pensamos que la idea de lógica móvil y de modularización de la arquitectura según sus capacidades es totalmente moldeable al paradigma de agentes, en donde la lógica móvil se puede ver en la movilidad del agente, y la capacidad se puede ver en agentes especializados que están inmersos dentro de la arquitectura que se pudiere plantear.

7. DISEÑO E IMPLEMENTACIÓN DE UN SERVIDOR HTTP Y MECANISMOS DE SERIALIZACIÓN EN J2ME

El objetivo es proveer el funcionamiento de un servidor http dentro de un dispositivo móvil, con la finalidad de dar funcionalidades dentro de J2ME que no son soportadas, pero que son necesarias para el buen funcionamiento de una plataforma de agentes; las funcionalidades no soportadas por la arquitectura J2ME son:

• Carga dinámica de clases.

• Serialización de objetos.

7.1 Puntos Centrales:

Viendo estas limitaciones la tesis (que ya fue desarrollada) la dividen en dos grandes puntos de investigación, el primero es la comunicación a través de sockets dentro del perfil MIDP 1.0 (que es un perfil dentro de la arquitectura J2ME) y el segundo es dar un mecanismo de serialización de objetos para la arquitectura J2ME, esto para lograr implementar un servidor http dentro de un dispositivo móvil teniendo en cuanta que este enfoque puede ser utilizado dentro de una plataforma de agentes en dispositivos móviles.

7.2 Arquitectura:

La arquitectura que se plantea en este proyecto es la siguiente:

Arquitectura Propuesta

Según la figura podemos ver que este proyecto lo que consiguió fue ampliar las funcionalidades de la arquitectura J2ME, con el objetivo primordial de poder concebir una plataforma de agentes dentro de los dispositivos móviles, ya que los agentes móviles se ven como algo natural dentro de un ambiente móvil (según la perspectiva de la tesis).

La idea referente a los agentes y el servidor http en dispositivos móviles esta plasmada en el siguiente párrafo:

“Lo que se pretende conseguir es que estos dispositivos no solo puedan utilizar estos servicios, si no que puedan ser también ellos mismos los que los proporcionan, dando acceso tanto a dispositivos móviles como a los que no lo son sin la necesidad de un servidor intermedio”[ SAN2002].

Vemos que una opción para plantear una arquitectura es poder ampliar otra arquitectura ya existente y que a sido validada, en este caso la ampliación de la arquitectura J2ME; también tendremos en cuenta la funcionalidad que se desarrollo en esta tesis en miras a facilitar el desarrollo de nuestra arquitectura o para el desarrollo de la aplicación que valide nuestra arquitectura.

8. Wireless Resource Manager (WRM)

Esta arquitectura está abierta a estándares existentes y es accesible para futuras aplicaciones QoS y redes inalámbricas.

El WRM es el primer elemento funcional de la arquitectura. Considera el tráfico y los requerimientos de QoS de la aplicación y el estado del canal por el cual se ha accedido. Tiene una arquitectura de jerarquía modular. Las WDMI (Wireless Dependent Management Interfaces) interactúan con el WRM para tecnologías inalámbricas específicas [MR2003]

Debido a las limitaciones de los dispositivos móviles, tanto el WRM como las WDMI, tienen una complejidad mínima procesando. Al clasificar cada petición la cantidad de negociaciones entre el dispositivo móvil y las redes de acceso es minimizada por el procesamiento [MR2003]

La ubicación dinámica de la red de acceso es permitida por WDMI que a su vez informa al WRM permitiendo negociar con las QoS de las aplicaciones para que de esta forma lo enrute para la red más apropiada de acuerdo a las preferencias del usuario, costos y servicios que pida [MR2003]

.

9. WIRELESS APPLICATION PROTOCOL (WAP) WAP es una solución unificada para los servicios de valor añadido existentes y futuros. El protocolo incluye especificaciones para las capas de la torre OSI de sesión y de transporte, así como funcionalidades de seguridad. WAP también define un entorno de aplicaciones. WAP es escalable, permitiendo así a las aplicaciones disponer de las capacidades de pantalla y recursos de red según su necesidad y en un gran número de tipos de terminales. En el caso del WAP, el cliente utiliza un micro navegador que envía su petición al WAP Gateway. Éste la decodifica y la envía al servidor Web, en el cual está presente el contenido requerido. Este último servidor envía las páginas pedidas al WAP Gateway. Éste las codifica y las envía al cliente del WAP.

Como ocurre con la Web, también el WAP define un modelo de síntesis para los nombres compatibles con la www, los tipos de contenido y los formatos y protocolos que se utilizan. El WAP Gateway tiene como única finalidad el convertir los paquetes de datos del protocolo WAP ( WSP, WTP, WTSL, WDP), en paquetes del protocolo WWW (HTTP Y TCP/IP) y viceversa. Los datos enviados al cliente se comprimen y codifican en código binario con el fin de reducir su dimensión. La arquitectura del WAP (Stack WAP) permite tener un ambiente seguro y extensible gracias a un diseño realizado en layer en el que cada uno es accesible por el layer superior o por otros servicios y aplicaciones.

[WA2004]

Los protocolos de WAP se expresan en la siguiente tabla:

[WA2004]

10. WIRELESS ARCHITECTURE FOR ACCESS TO REMOTE SERVICES (WIARS)

Los principales componentes de la arquitectura WiARS son el WAP Enabled User Agent (WAEU), el WAP gateway, el Lookup Service de Jini y otros servicios [TA2000]. Esta arquitectura funciona de la siguiente manera:

• El WAEU solicita un servicio (Request). • El Request lo maneja el gateway al cual el WAEU está suscrito. • El gateway actúa como un cliente Jini en nombre del WAEU y busca un

Lookup Service de Jini. • El Lookup Service regresa una lista de servicios actualmente disponibles del

que solicitó el WAEU. • El WAP gateway le comunica esa lista al WAEU. • EL WAEU le responde al gateway con el servicio seleccionado. • El gateway, con la ayuda del Lookup Service de Jini, establece una conexión

con el servicio. Esta arquitectura tiene un envío de datos de manera bidireccional y cualquier entidad puede iniciar el envío de mensajes.

REFERENCIAS [AC2004] Acuña César Javier. Arquitecturas de Software. Universidad Rey Juan

Carlos. [GON2003] Enrique Gonzalez, Jamir Antonio Avila y Cesar Bustacara, “Besa

Arquitectura para la construcción de sistemas Multi-Agentes”, 2003. [EU2001] EPSA UCLAM. Ingeniería del Software. Arquitectura de Software. 2001 [FIPASC00023J] www.fipa.org número del documento SC00023J, “Fipa Agent

management Specification”, 2002/12/03. [FIPA00067] www.fipa.org FIPA Agent Message Transport Service Specification.

http://www.fipa.org/specs/fipa00067/ [BEL2003] F. Bellifemine, G. Caire, A. Poggi, G. Rimassa“Jade a white paper”,

Septiembre del 2003. [BEL12003] F. Bellifemine, G. Caire, Tizana Trucco, “Jade administrator guide” jade

3.1 , 15 de Diciembre del 2003. [SAN2002] Guillermo Diez-Andino Sancho (gdandino@it.uc3m.es), “Diseño e

implementación de un servidor http y mecanismos de serializaciòn en J2ME”, proyecto fin de carrera, universidad Carlos III de Madrid. 23 de Septiembre del 2002.

[RIM2003] Giovanni Rimaza , “Runtime Suport for Distributed-multi- Agent

systems” , Enero del 2003. [GW2001] Gerhard Weiss, “Multagent System”, 2001. [HO2004] Honeywell. What is a Domain-Specific Software Architecture? en

http://www.htc.honeywell.com/projects/dssa/dssa_whatis.html

[JAS2000] Juan Ángel Sampedro Martínez, José David Ciórraga López, Francisco Jesús Martínez Mimbrera, “AgentOS”.

[KJ2003] Knudsen Jonathan. Gíreles Java: Developing with J2ME. Segunda Edición. Ed. Apress. Estados Unidos de América. 2003

[MN2004] Moreno Navarro Juan José. Arquitecturas de Software. Curso de

Software basado en Componentes [MR2003] Malyan R. Lenaghan A. A Multi-service Architecture to Support Mobile

IP Applications over Heterogeneous Wireless Networks. Networking and Communications Group, Kingston University. Reino Unido. 2003

[PJ2003] Project JXTA. JXTA v2.0 Protocols Specification en

http://spec.jxta.org/v1.0/docbook/JXTAProtocols.html#intro-fjp. 2003 [PIC2004] Pickens John. Point to Multi Point (P2MP). Com21. [ZAC2003] Stefanos Zachariadis (s.zachariadis@cs.ucl.ac.uk), “Use of Logical

Mobility for Mobile Self-Organisation”, Department of Computer Science University College London University of London, Noviembre del 2003.

[TA2000] Thakkar Amisha. Wireless Architecture for access to Remote Services

(WIARS). State University of New York at Buffalo. 2000 [WA2004] Overview of Wireless Architectures and Products en

http://www.cs.purdue.edu/homes/fahmy/reports/leynawap.htm