1

INTRODUCCIÓN

En los últimos años, el uso de los dispositivos móviles se ha incrementado a nivel mundial. En Colombia, estas nuevas tecnologías están lideradas por tres compañías: Comcel, quien introdujo 3GSM, Bellsouth con CMDA y Colombia Móvil utilizando UMTS (PCS). El gran auge que han tenido los dispositivos móviles en las últimas décadas ha ocasionado que el desarrollo de aplicaciones para estos dispositivos se vuelva necesario. Sin embargo, esta tarea se ha convertido en un reto para la comunidad de desarrolladores, debido a las limitaciones presentadas por estos dispositivos: limitada capacidad de almacenamiento y procesamiento, ancho de banda limitado, alta latencia e intermitencia de la comunicación. Como respuesta, ha surgido la necesidad de que algunos paradigmas de componentes distribuidos entren como respuesta a estos inconvenientes. Con la aparición de nuevas tecnologías, como Bluetooth y el surgimiento del paradigma de comunicación P2P, se abre un interesante espectro de nuevas aplicaciones que se enfocan hacia la ubicuidad, mostrando así un futuro en el que la información puede estar disponible desde cualquier tipo de dispositivos como lo son pda, teléfonos celulares, agendas electrónicas, computadores portátiles, tarjetas inteligentes, etc. no limitándolo a computadores conectados en redes TCP/IP. El objetivo de este proyecto es analizar, diseñar, implementar y validar una arquitectura adecuada para un ambiente con dispositivos móviles, basada en una aproximación de componentes distribuidos. Dicho con otras palabras, desarrollar una arquitectura que sea extensible de tal forma que se puedan adicionar nuevos servicios para compartir recursos; segura tanto en la integridad como en la disponibilidad de los servicios; escalable al incrementar el número de recursos y de usuarios; transparente para el usuario y el programador independiente del hardware o sistema operativo y, que conviva con las limitaciones inherentes a los dispositivos móviles mencionadas anteriormente. Para el desarrollo de este proyecto se siguió una metodología de investigación que consta de los siguientes pasos: investigación, análisis, diseño, implementación, pruebas y caracterización. Durante la fase de investigación se realizó la recolección de gran cantidad de

2

información referente al tema de investigación, logrando un marco teórico que se analizó para convertirse así en el punto de referencia. Durante el diseño e implementación se realizó una investigación constante del tema, debido a que es algo innovador del cual no se tiene mucho conocimiento. Adicionalmente, se establecieron los criterios de una buena arquitectura, con el fin de poder tener un punto de referencia en el momento de evaluar el resultado final de la arquitectura desarrollada. Después de establecer los criterios para una buena arquitectura, se plantearon algunas alternativas de posibles casos de estudio para poder validar la arquitectura. Después de evaluar las posibilidades, se eligió como caso de estudio una simulación de un aeropuerto y así se validó la arquitectura utilizando un tipo de investigación experimental. En la fase de implementación de la arquitectura se siguió el Modelo Cascada de desarrollo de software que incluye las siguientes fases: análisis, diseño, implementación, pruebas y mantenimiento. El mismo método se utilizó en el desarrollo de la aplicación con la que se validó y depuró la arquitectura. Esta iteración se realizó internamente dentro de cada actividad que se llevó a cabo. Durante la fase de implementación de la arquitectura y de la aplicación se aplicó el paradigma de programación orientada a agentes (POA). El problema de la aplicación se pensó en términos de estas entidades y se realizó un modelo de interacción para cada una de ellas. En la fase de pruebas ser realizaron pruebas unitarias y de integración tanto de la arquitectura como de la aplicación. Finalmente se caracterizó la arquitectura utilizando las pruebas realizadas en la fase anterior. La arquitectura MAD desarrollada en este proyecto hace un aporte a la Ingeniería de Sistemas, permitiendo que el desarrollo de nuevos tipos de aplicaciones móviles sea más rápido y eficiente. MAD se basa en el concepto de redes peer to peer lo que le permite escalar fácilmente y estar acorde con las nuevas tendencias. De igual manera, MAD ofrece la flexibilidad para ser implementada utilizando diferentes tecnologías de comunicación inalámbrica como es el caso de Bluetooth o de 802.11.x. MAD permite desarrollar aplicaciones distribuidas dando soporte al roaming de los dispositivos móviles de una manera transparente para el desarrollador usando componentes previamente desarrollados como el acceso inalámbrico. Finalmente, es importante destacar que la arquitectura MAD lidia con las limitaciones de procesamiento y almacenamiento de los dispositivos móviles permitiendo más flexibilidad y mejor uso de los recursos. Este documento está dividido en siete capítulos, los primeros abarcan el marco teórico recolectado durante la primera etapa del proyecto y que sirvió como punto de referencia para el desarrollo de la arquitectura. En el capítulo 4 se explica de manera detallada las diferentes vistas del modelo de la

3

arquitectura. El diseño y la implementación de la arquitectura se explican en el capítulo 5. Para validar la arquitectura se desarrolló una aplicación que se explica en el capítulo 6 junto con las pruebas realizadas tanto a la arquitectura como a la aplicación. Finalmente, se plantean las conclusiones obtenidas durante el desarrollo del proyecto y los trabajos futuros que se pueden realizar con base en la arquitectura MAD.

1. TECNOLOGÍAS

En los últimos años, se ha visto un creciente desarrollo de las tecnologías inalámbricas, dando lugar al incremento del uso de los dispositivos móviles a nivel mundial. Se estima que para el año 2005 habrá más de 100 millones de suscriptores de telefonía celular [IEC2003]. En este capítulo se da una visión general de las tecnologías inalámbricas que se encuentran en el mercado. Primero se realiza una breve descripción de los conceptos de tecnologías TDMA, CMDA, 3GSM y PCS. Después se tocan los temas de tecnologías de comunicación como son Bluetooth y 802.11x y tecnologías inalámbricas para conexión a Internet donde encontramos WAP e I-Mode. Finalmente, se habla sobre los frameworks que existen para el desarrollo de aplicaciones móviles. Se dan unos conceptos generales de .Net Compact Framework y J2ME, profundizando en la tecnología escogida para el desarrollo de nuestra arquitectura de acuerdo a las ventajas y desventajas detectadas presentadas en la sección 1.4.

1.1 TECNOLOGÍAS DE TELEFONÍA CELULAR

La telefonía celular comenzó en Colombia en 1994 usando TDMA (multiplexación por división de tiempos) en donde una sola celda se encargaba del tráfico y el ancho de banda era relativamente bajo (800 MHz). Ahora, se han introducido las tecnologías 3GSM, GPRS y CDMA. A continuación se explican las 4 tecnologías mencionadas anteriormente, dividiéndolas en dos secciones, técnicas de multiplexación y técnicas de transmisión.

1.1.1 TÉCNICAS DE MULTIPLEXACIÓN

Se entiende como multiplexación a la forma de combinar dos o más señales dentro de un mismo canal que posteriormente se pueden volver a separar. El canal de comunicación puede ser compartido de diferentes maneras entre las que se encuentran TDMA y CDMA. Estas dos técnicas son utilizadas en la telefonía celular. A continuación se explican las características principales de cada una.

1.1.1.1 TDMA (Time Division Multiple Access)

TDMA es un concepto bastante antiguo en los sistemas de radio. En los sistemas modernos celulares y digitales, TDMA implica el uso de técnicas de compresión de voz digitales, que permite a múltiples usuarios compartir un canal común utilizando un orden temporal. La codificación de voz moderna, reduce mucho el tiempo que se lleva en transmitir mensajes de voz, eliminando la mayoría de la redundancia y periodos de silencio en las comunicaciones de voz. Otros usuarios pueden compartir el mismo canal durante los períodos en que éste no se utiliza. Los usuarios comparten un canal físico en un sistema TDMA, donde están asignados unos slots de tiempo. A todos los usuarios que comparten la misma frecuencia se les asigna un slot de tiempo, que se repite dentro de un grupo de slots que se llama trama [GSM2004].

1.1.1.2 CDMA (Code Division Multiple Access)

La técnica procede de la segunda guerra mundial, cuando se buscaba un sistema que no se pudiera interceptar. En la actualidad el sistema CDMA es propiedad de la compañía Qualcomm [PES2000]. CDMA es una tecnología genérica que puede describirse, como un sistema de comunicaciones por radio celular digital que permite que un elevado número de comunicaciones de voz o datos en forma simultánea, compartan el mismo medio de comunicación, es decir, utilizan simultáneamente un pool común de canales de radio, de manera que cada usuario puede tener acceso a cualquier canal de forma temporal; el canal es un trozo de espectro de radio que se asigna por un lapso de tiempo a un tema específico, como por ejemplo, una llamada telefónica [GRA2004]. Debido a que un gran número de comunicaciones comparten el mismo medio de comunicación se dice que CDMA es una técnica de acceso múltiple. En CDMA, cada comunicación se codifica digitalmente utilizando una clave de encriptación que solamente conocen los terminales involucrados en el proceso de comunicación. La codificación digital y la utilización de la técnica de espectro esparcido, otra característica inherente a CDMA se pueden considerar como los puntos de identificación de esta tecnología [GRA2004]. La distribución celular y la reutilización de frecuencias son dos conceptos estrechamente relacionados con la tecnología CDMA; el objetivo es realizar una subdivisión en un número importante de celdas para cubrir grandes áreas de servicio. Desde un punto de vista de distribución celular, la tecnología CDMA se puede contemplar como una superación de la tradicional subdivisión celular hexagonal [GRA2004].

1.1.2 TÉCNICAS DE COMUNICACIÓN

Dos técnicas de comunicación utilizadas en la telefonía móvil se explican a continuación 3GSM y PCS. Estas técnicas de comunicación o transmisión utilizan las técnicas de multiplexación mencionadas anteriormente.

1.1.2.1 3GSM (Global System for Mobile Communications)

El GSM es un estándar internacional para las comunicaciones radio digitales creado por el Instituto Europeo para los Estándares en Telecomunicaciones ETSI en el año 1991 utilizando las definiciones establecidas por la Unión Internacional de Telecomunicaciones ITU-T. Este estándar permite las comunicaciones móviles en los diferentes mercados [TER2004]. En Europa se aplica en dos bandas de frecuencia, a 900 MHz y a 1800 MHz (GSM 900 y GSM 1800 respectivamente), mientras que en EUA se aplica en la banda de 1900 MHz (GSM 1900) y en el Sureste Asiático y Japón a 850 MHz (GSM 850) [TER2004]. El 3GSM viene siendo lo mismo que GPRS (Global Packet Radio Service), una arquitectura para redes de área amplia (WAN) la cual está compuesta de sistemas y protocolos de comunicaciones claramente definidos y estandarizados. Dichos sistemas hacen posible la transmisión de datos en forma de paquetes a través de una red celular [COM2004]. GPRS 3GSM tiene como fundamento el protocolo IP (Internet Protocol) ampliamente utilizado a nivel mundial, que proporciona compatibilidad y facilidad para operar como una extensión de las redes de datos tradicionales. Es una tecnología diseñada específicamente para transmisión inalámbrica de datos en ráfagas, usando la infraestructura de la red celular, por lo que garantiza un gran cubrimiento, servicio e implementación a bajos costos, alta calidad, seguridad y velocidad en transmisiones de información [COM2004]. La red GPRS 3GSM aprovecha la infraestructura de canales de Radio Frecuencia (RF), existentes en la telefonía celular tradicional, para proporcionar la transmisión digital de datos. Múltiples usuarios pueden compartir el mismo canal de RF el cual puede ser dedicado para transmisión de datos o compartido también para comunicaciones de voz. La capacidad máxima para envío de datos es de 171 Kbps [COM2004].

1.1.2.2 PCS (Personal Communication Services)

PCS es un sistema que opera con teléfonos similares a los celulares, pero con mayor ancho de banda, lo que le facilita transmitir voz, datos e imágenes con más velocidad. A estos dispositivos se les asigna una banda de 1900 MHz [IEC2004].

Para describirlo de una manera sencilla, el PCS es como el TDMA que se tiene, pero además con un canal llamado DCCH (Digital Control Channel que es una mejora a uno de los canales existentes en TDMA. Este DCCH mejora considerablemente la comunicación por tiempos, gracias a la mayor utilización de celdas por comunicación. El PCS con el DCCH busca, mientras se habla, ocupar un número mayor de celdas y a la vez, va saltando de una a otra, para mantener el tráfico lo más libre posible para el tipo de uso que se le está haciendo al dispositivo móvil. No es lo mismo hablar con otro móvil que enviar y recibir mensajes de texto (SMS, Short Message Service) [IEC2004]. Hay una diferencia importante con los otros sistemas y es la duración de la batería. El sistema PCS maneja dos estados en el móvil, "Sleep mode" y "Stand by" lo cual alarga la duración de las baterías [IEC2004].

1.2 TECNOLOGÍAS DE COMUNICACIÓN

Existen distintos protocolos que nos facilitan la comunicación inalámbrica entre diferentes dispositivos. A continuación se explican dos de las tecnologías inalámbricas de corto alcance, Bluetooth y 802.11x. Finalmente, se hace una comparación entre las dos. Las tecnologías inalámbricas de larga distancia no se contemplan debido a que el enfoque particular de la arquitectura que se propone en este proyecto es para dispositivos móviles como celulares y pda que, por lo general, contienen tecnologías para distancias cortas.

1.2.1 BLUETOOTH

El protocolo Bluetooth es una especificación global para redes inalámbricas de corto alcance. Es muy útil ya que permite la interconectividad entre dispositivos de diferentes fabricantes. Es muy utilizado para eliminar los cables y alambres que conectan a los dispositivos como las impresoras, scanners, entre otros. A nivel de telefonía celular, cuando un dispositivo que tiene Bluetooth se encuentra cerca de otro dispositivo con la misma especificación, se conectan automáticamente de manera gratuita porque no utilizan la infraestructura telefónica. Bluetooth fue diseñado para operar en un entorno de radio frecuencia ruidosa, utiliza un esquema de reconocimiento rápido y saltos de frecuencia para garantizar la robustez del enlace. Bluetooth opera en la banda de frecuencia de 2.4 GHz, libre para ISM (Industrial, Scientific, Medical). Los módulos de radio Bluetooth eliminan la interferencia con otras señales saltando a una nueva frecuencia inmediatamente después de transmitir o recibir un paquete. Comparado con otros sistemas que operan en la misma

frecuencia, Bluetooth salta más rápido y usa paquetes más pequeños. Esto le hace más robusto que la mayoría de otros sistemas [ROB2003]. En cuanto a la transmisión, el protocolo Bluetooth puede soportar un canal de datos asíncrono, hasta tres canales síncronos de voz simultáneos, o un canal que simultáneamente soporta datos asíncronos y voz síncrona. Cada canal de voz permite un enlace síncrono de 64 kb/s. El canal asíncrono permite un enlace asimétrico de 721 kb/s y 57.6 kb/s en la respuesta, o un enlace simétrico de 432.6 kb/s. Los paquetes de voz no se retransmiten, debido a que el método de codificación (CVSD) permite que la voz sea audible incluso con altos niveles de ruido [ROB2003].

1.2.2 IEEE 802.11 Wi - Fi

Es un estándar creado por la IEEE en 1999. Para la transmisión de los datos trabaja en una frecuencia de 2.4 GHz [ITAM2000]. El método de modulación seleccionado se conoce como espectro de difusión de secuencia directa complementaria (DSSS), utiliza la llave de código complementario (CCK) y hace que las velocidades de los datos sean tan altas como 11 Mbps lo que equivaldría a una red ethernet tradicional. El alcance de esta tecnología es de 100 metros. IEEE 802.11b define dos componentes; una estación inalámbrica, la cual puede ser una PC o una Laptop con una tarjeta de red inalámbrica (NIC - Network Interface Card), y un Punto de Acceso (AP - Access Point), el cual actúa como puente entre la estación inalámbrica y la red cableada o con otros dispositivos inalámbricos [ITAM2000] .

1.2.3 BLUETOOTH vs 802.11b

Recopilando lo expuesto anteriormente se puede decir que Bluetooth y el estándar 802.11b comparten la misma banda de transmisión (2.4-2.485 GHz). Para evitar las múltiples interferencias que se pueden presentar como consecuencia de que la banda ISM está abierta a cualquier tecnología, se utiliza un sistema que busque una parte no utilizada del espectro (802.11.b) y un sistema de salto de frecuencia (Bluetooth) [BOR2004]. Bluetooth es mejor para pequeños dispositivos mientras que 802.11b es mejor en configuraciones WLAN. Este estándar ha sido implementado básicamente para redes rápidas y confiables de negocios, por lo que es utilizado para expandir y asociarse con redes cableadas y también las puede reemplazar. La diferencia primordial entre Bluetooth y el estándar 802.11b es la velocidad. Bluetooth opera a una velocidad alrededor de 720kbps, que es muy inferior a la del estándar 802.11b que es aproximadamente de 11mbps

[ZON2001]. Adicionalmente, Bluetooth tiene un alcance de 10 metros mientras que 802.11 alcanza los 100 metros. Bluetooth fue diseñado para conectar dispositivos Point-to-Point mientras que 802.11b fue diseñado para actuar como una red normal pero lógicamente puede conectar un computador directamente a otro. Bluetooth es más favorable para conectar un dispositivo en una red pequeña donde la rapidez no es indispensable y el bajo consumo de energía es fundamental. Por otro lado, el estándar 802.11b es mejor cuando un computador móvil necesita conectarse a Internet (gracias a su rapidez), pero su desventaja aparece cuando se quiere conectar un dispositivo rápidamente en un ambiente seguro.

1.3 TECNOLOGÍAS INALÁMBRICAS PARA CONEXIÓN A INTERNET

A continuación se describe brevemente dos de las tecnologías inalámbricas que se utilizan para poder acceder a Internet desde un dispositivo móvil.

1.3.1 I-MODE

I-Mode es básicamente un servicio de transmisión por paquetes que permite una conexión continua con Internet a través de los teléfonos móviles. Con este sistema de información por paquetes no es necesario que cada usuario reciba la información a través de un solo canal de radio, lo que permite que un gran número de personas puedan acceder a la información simultáneamente. I-Mode usa un subconjunto de HTML llamado HTML compacto (cHTML) para la presentación de la información. Los servicios más utilizados por los usuarios son mail "I-Mode", banca móvil e información de transporte en general. Las tarifas se basan en el volumen de información enviada y recibida [WML2004].

1.3.2 WAP (Wireless Application Protocol)

WAP es un conjunto de protocolos que toma las características tanto de Internet como de los estándares desarrollados para terminales móviles. En este sentido puede funcionar tanto en redes de transporte GSM como en GPRS o UMTS [GAR2004]. Los protocolos WAP son análogos a los existentes en la tecnología utilizada en Internet, solo que optimizados para la potencia que ofrecen los dispositivos portátiles, y limitados por el ancho de banda que ofrece la tecnología inalámbrica y cubren tanto la capa de aplicación (WML y WMLScript), como las capas de transporte [GAR2004]. A continuación se enuncian los protocolos:

Wireless Application Environment (WAE) Wireless Session Layer (WSL) Wireless Transport Layer Security (WTLS) Wireless Transport Layer (WTP)

El WAP Gateway manda un contenido WML al dispositivo WAP, y el Gateway se debe comunicar con el Web Server usando el protocolo HTTP [GAR2004].

1.3.3 I-MODE vs WAP

En la tabla 1.1 se encuentra una comparación entre I-Mode y WAP que resume las principales características de estas dos tecnologías.

I-MODE Wireless Application Protocol (WAP)

Desarrollado por NTT DoCoMo Desarrollado por Wireless Phone Industry

Es un estándar de un propietario Está abierto para todo el mundo (estándar)

Usa cHTML (HTML compacto) Usa wml (hecho con XML)

Solo está en Japón y Hong Kong Está en todo el mundo

Color screens (256 colors) No tiene color

Siempre al aire (es más sencillo) Tiene que marcar para obtener el servicio

El contenido es mostrado usando HTTP con un centro I-Mode bajo el control de DoCoMo

WAP gateways para todo el mundo que tenga conexión a Internet

Cargo por los datos transmitidos Cargo por lo que esté conectado

Servicio inalámbrico de Internet Es un protocolo

Puede usar .GIF imágenes No puede utilizar imágenes

Enfocado al consumidor y al entretenimiento

Aplicaciones de Negocio

Tabla 1.1. I-Mode vs WAP [MOB2004]

1.4 FRAMEWORK PARA DISPOSITIVOS MÓVILES

En los últimos años ha surgido un gran interés por el desarrollo de aplicaciones para dispositivos móviles. Para facilitar a los desarrolladores este proceso se han creado principalmente dos herramientas Java 2 Mobile Edition (J2ME) y .Net Compact Framework (.NET CF). Primero se hace una comparación entre estos dos frameworks. Posteriormente, se profundiza un poco más en la plataforma escogida para el desarrollo del proyecto como resultado de la comparación mencionada anteriormente.

1.4.1 J2ME vs .NET CF

Tanto J2ME como .Net CF son plataformas para el manejo de dispositivos móviles. Comparadas con las tecnologías de mini browsers como WAP, estas herramientas nos apoyan en el manejo de interfaces (UIs) y apoyan esquemas más flexibles de integración y de seguridad. Por un lado tenemos .Net CF que es la versión para dispositivos móviles del tradicional .Net de Microsoft. El Common Language Runtime (CLR) de .Net CF corre de manera estándar aplicaciones Byte Code de .Net. El Compact Framework contiene un subconjunto de las librerías estándares de .Net que son necesarias para desarrollar aplicaciones para dispositivos móviles. El mayor inconveniente que tiene esta plataforma es que solo funciona con Windows Ce / PDAs con Pocket PC [JUN2002]. En el campo de Java, la situación es un poco más compleja. J2ME tiene dos componentes, las configuraciones y los perfiles diseñados para proporcionar un mejor funcionamiento para una variada gama de dispositivos móviles. Las configuraciones apoyan la base de los APIs de Java y están ligadas a una máquina virtual. Los perfiles se construyen encima de las configuraciones para apoyar las características específicas de los dispositivos tales como el manejo de la red y de las interfaces gráficas [JUN2002]. Dependiendo de las características de los dispositivos se utiliza determinada configuración y perfil. A continuación se enumeran las características que deben tener los dispositivos según la configuración:

J2ME CDC: Esta configuración está ligada a la máquina virtual CVM, orientada a dispositivos que tienen mínimo 2 MB de memoria, un procesador de 32 bits y una conexión con un buen ancho de banda sobre TCP/IP [ROB2004]. Algunos ejemplos son TV digitales y electrodomésticos.

J2ME CLDC: Esta configuración corre sobre la máquina virtual KVM, la cual es altamente portable y compacta diseñada para dispositivos con poca memoria, poca capacidad de procesamiento, limitaciones de batería y conexiones de red intermitentes. Por lo anterior, la

configuración CLDC junto con la KVM es ideal para dispositivos que tengan de 160 KB a 512 KB de memoria, procesador de 16 o 32 bits, operados con pilas: potencia limitada y con una conexión con ancho de banda limitado [ROB2004].

En la tabla 1.2 se encuentra una comparación de algunos aspectos importantes de las 3 tecnologías: .Net CF, J2ME CDC y J2ME CLDC.

.NET Compact Framework

J2ME CDC J2ME CLDC

Requerimiento del dispositivo

Costosos y con una buena capacidad de memoria y procesamiento

Costosos y con una buena capacidad de memoria y procesamiento

Baratos y con capacidades limitadas

Costo Alto Alto Mediano

Soporte de Lenguajes

C#, VB .Net Java Java

Plataformas Pocket PC, Windows

La mayoría de las plataformas excepto Palm OS

Todas las plataformas

Compatibilidad de Byte Code

.Net CLR J2SE No es compatible con J2SE ni con CDC

Compatibilidad del API

Subconjunto de .Net

Subconjunto de J2SE más paquetes opcionales.

Compatibilidad parcial con CDC más paquetes adicionales.

Proceso de Especificación

Microsoft Comunidad Java Comunidad Java

Modelo de Seguridad

Modelo simplificado de .Net

Soporta todo el manejo de seguridad de Java

Limitado al modelo de Java que provee la especificación OTA (on the air)

Tabla 1.2. Comparación Frameworks [JUN2002]

Para desarrollar el proyecto se escogió utilizar la plataforma J2ME y en especial la configuración CLDC. Las principales razones que se tuvieron en cuenta para escoger esta opción son: el costo, que va dirigido a dispositivos con poca capacidad de procesamiento y memoria y que es portable entre muchas de las plataformas existentes.

1.4.2 J2ME

Como se mencionó anteriormente, J2ME es una versión de Java que es, tanto un lenguaje de programación, como una plataforma desde la que se puede descargar y ejecutar aplicaciones en los terminales móviles de forma abierta y sencilla. Los terminales que integran J2ME permiten descargar bajo demanda, aplicaciones escritas en esta tecnología, para ser utilizadas directamente desde el móvil, permitiendo una mayor personalización [VNU 2002]. Con J2ME, el dispositivo móvil se convierte en un dispositivo programable similar en funciones a un pequeño ordenador, ya que el usuario puede personalizarlo con las aplicaciones que le sean más útiles e interesantes. Las aplicaciones se descargan en la terminal y el usuario las ejecuta como local cuando lo desee. Por otro lado, J2ME aporta riqueza de gráficos, sonidos y animaciones que hacen "más amigable" el uso del servicio [VNU 2002]. Una configuración define las capacidades mínimas de librerías y de máquina virtual de Java que se esperan que estén disponibles en los dispositivos, de acuerdo a los requerimientos similares de tamaño de memoria y capacidad de procesamiento. La figura 1.1 muestra la plataforma J2ME con sus configuraciones y perfiles, donde se encuentran las características mencionadas anteriormente, y que se explican un poco más detalladas a continuación.

Figura 1.1. Plataforma J2ME [ROB2004]

J2ME tiene dos configuraciones básicas: CLDC Y CDC CLDC (Connected Limited Device Configuration): Configuración que

establece como requerimientos mínimos 160 kb de memoria no volátil y 32 kb de memoria volátil, un procesador de 16 o 32 bits, bajo consumo de energía (normalmente batería), conexión inalámbrica y no soporta el punto flotante. Con esta configuración se busca bajar dinámicamente aplicaciones a dispositivos móviles así como el desarrollo de software para estos dispositivos. CLDC no implementa en su totalidad el modelo de seguridad de J2SE; sin embargo, cuenta con un modelo de 2 partes. La primera es un nivel bajo de seguridad en la virtual machine que nos dice que una aplicación que esté corriendo en la virtual machine no debe dañar un dispositivo de ninguna manera. Esto se logra a través del verificador del tipo de archivos. La segunda es la seguridad a nivel de aplicaciones a través del Sandbox Model. En este caso sólo un limitado conjunto de los APIs de Java está disponible para el programador de aplicaciones, quien no puede sobrescribir el mecanismo de carga de clases estándar ni tampoco el sistema de clases de la máquina virtual [TAI2003].

CDC (Connected Device Configuration): Configuración que establece como especificaciones mínimas: 512 kb de memoria ROM, 256 kb de

memoria RAM, maneja un ancho de banda de 9600 bps o menor. Es un súper conjunto de la configuración anterior, CLDC. Soporta la especificación completa de Java 2 Full Virtual Machine, CVM virtual machine y las librerías y APIs mínimos para que un sistema corra. Sin embargo, removieron todos los APIs que no fueran críticos o que no sean utilizados [SUN2003].

En la Figura 1.2 vemos en resumen de manera gráfica como son los dos tipos de configuraciones.

Figura 1.2. CDC vs CLDC [ROB2004]

J2ME Profil

e4

J2ME CDC Libraries

Compact Virtual Machine

J2ME Profil

e5

J2ME Profil

e6

256 KB RAM 512 KB ROM 32 bit processor

Java Language

J2ME Profil

e1

J2ME CLDC Libraries

K Virtual Machine

J2ME Profil

e2

J2ME Profil

e3

32 KB memoria volátil 16 32 bit processor

Java Language

2. ARQUITECTURA DE SOFTWARE PARA DISPOSITIVOS MÓVILES

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 se explican algunas arquitecturas para dispositivos móviles, analizando sus ventajas y desventajas. Posteriormente, se hace un análisis comparando las diferentes arquitecturas, distinguiendo lo que tienen en común y cuáles son sus fortalezas frente a las demás arquitecturas. El análisis anterior sirve como base para el desarrollo de la arquitectura MAD (Mobility supported by Agent-based Devices).

2.1 INTRODUCCIÓN

Con el aumento del uso de dispositivos móviles, se han implementado diferentes arquitecturas para desarrollar aplicaciones móviles. Cada una de estas arquitecturas ataca en cierta forma las limitaciones de los dispositivos móviles. A continuación se hace una descripción de algunas de las arquitecturas para dispositivos móviles.

2.2 PEER TO PEER (P2P)

Se conoce como P2P a las redes descentralizadas y distribuidas, en las cuales las aplicaciones pueden comunicarse entre sí, intercambiando información sin la intervención de un servidor central. La clave fundamental de P2P es que los nodos son tratados de igual a igual [BON2004]. La figura 2.1 representa una arquitectura P2P.

Figura 2.1 Arquitectura P2P [BON2004]

Las principales características de P2P son [BON2004]: Descentralización

o Hay ausencia de un servidor central para el control o Los participantes pueden comunicarse directamente entre sí. o Todos los nodos o puntos actúan como clientes y servidores.

De esta manera, desaparece la organización jerárquica Distribución

o La información no está alojada en un solo sitio o punto. Balance de Carga

o Se intenta equilibrar la carga entre todos los participantes colaborando entre los nodos.

Balanceo de tráfico o Se utilizan mejor las redes de comunicaciones debido a que

sólo se tiene una comunicación directa con el punto que se necesita y no pasan por un servidor central.

Alta disponibilidad o La caída de un nodo no bloquea el servicio

Existen dos esquemas diferentes de la arquitectura P2P: PMP (point to multipoint) y P2CP (point to consecutive point).

2.2.1 POINT TO MULTIPOINT (P2MP)

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. La figura 2.2 muestra la diferencia entre una arquitectura P2P y una arquitectura P2MP.

Figura 2.2 P2P vs P2MP [PIC2004] 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.

2.2.2 POINT TO CONSECUTIVE POINT (P2CP)

Una serie de puntos que 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. La figura 2.3 ilustra el concepto de la arquitectura P2CP [PIC2004].

Figura 2.3 P2CP [PIC2004]

P2P Banda ancha dedicada

P2MP Banda ancha compartida

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.

2.2.3 VENTAJAS Y DESVENTAJAS

La principal ventaja de la arquitectura 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 que pueda ser suministrado por cualquier punto dando así soluciones más escalables donde el servicio no depende de una sola máquina. Adicionalmente tienen las siguientes ventajas [BON2004]:

Cualquier peer puede actuar como servidor o cliente. Al añadir un nodo a la red se le da lo mismo que a los otros nodos de

la red, por lo tanto no es necesario reestructurar la red al añadir nodos.

A gran escala, la comunidad P2P puede organizarse de forma natural en millones de redes virtuales de grupos pequeños agrupados según intereses específicos. Así, la organización de los nodos es independiente de si un nodo está conectado o no. Esto permite conectividad variable y escalabilidad.

Minimización de la congestión debido a que las conexiones se realizan punto a punto y no existen cuellos de botella.

La arquitectura P2P también presenta algunos inconvenientes, los más relevantes son:

Al tener una estructura descentralizada, la gestión es más compleja y, por lo tanto más cara, y existe una mayor probabilidad de que sea insegura.

No se puede recargar los equipos con mayor capacidad de procesamiento, debido a que todos los equipos hacen de todo..

2.3 SATIN

SATIN es un proyecto en el cual los desarrolladores buscan resolver el problema que se presenta actualmente con las aplicaciones que modelan sistemas móviles, empleando sistemas que se organicen por si solos (Self-Organized System) y teniendo en cuenta la lógica móvil. [ZAC2003]. SATIN utiliza la tecnología Bluetooth debido a que un gran número de dispositivos móviles cuentan con Bluetooth.

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. En este punto surge un concepto de sistemas que se auto organizan, los cuales automáticamente se reconfiguran con la finalidad de acomodarse a nuevos requerimientos [ZAC2003]. Sin embargo, presentan algunos inconvenientes:

El medio cambiante y las necesidades del usuario, teniendo como limitaciones la heterogeneidad en cuanto a hardware, software, protocolos de comunicación y redes 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.

2.3.1 ARQUITECTURA SATIN

La arquitectura SATIN se basa en unas primitivas de lógica móvil (LM), entendiendo lógica móvil como la habilidad de mover partes de una aplicación o migrar un proceso completo de un medio de procesamiento a otro [ZAC2003]. Esta lógica móvil ayuda a:

La interoperabilidad con aplicaciones remotas y medios que no fueron tenidos en cuenta al momento del 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 está siendo utilizada puede removerse.

Satin define su arquitectura básica en forma de capacidades en donde la unidad básica es la capacidad (Capability) incluyendo meta-data, versión, identificador único y una lista de dependencias a otras capacidades. Una funcionalidad es representada por el conjunto de capacidades que pueden

ser actualizadas dinámicamente en medios dinámicos (redes ad-hoc) [ZAC2003]. La figura 2.4 muestra la arquitectura Satin en un host y se describe a continuación:

Advertiser Capability: implementa capacidades de publicación de funcionalidades.

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.

Figura 2.4 Arquitectura SATIN [ZAC2003]

2.3.2 VENTAJAS

Las principales ventajas que presenta esta arquitectura son [ZAC2003]: Utiliza la lógica móvil para auto organizarse lo que permite que pueda

reaccionar al constante cambio de requerimientos, añadiendo y/o modificando las funcionalidades de la aplicación.

La forma en que se modulariza la funcionalidad de una aplicación según sus capacidades permite que cada capacidad preste un servicio y sólo se tengan activas las que estén siendo utilizadas en ese momento.

2.3.3 DESVENTAJAS

Es un proyecto que está en desarrollo por lo que no se tiene la certeza que funcione correctamente la idea planteada.

Utiliza Bluetooth por lo que está restringido a un alcance de 10 metros.

2.4 SERVIDOR HTTP Y SERIALIZACIÓN EN J2ME

El objetivo es proveer el funcionamiento de un servidor HTTP dentro de un dispositivo móvil, con la finalidad de proveer funcionalidades que no son soportadas por J2ME pero que son necesarias para el buen funcionamiento de una plataforma de agentes [DIE2002]. Las funcionalidades que no son soportadas por la arquitectura J2ME son:

Carga dinámica de clases. Serialización de objetos.

Esta arquitectura se divide en dos grandes puntos de investigación: la comunicación a través de sockets dentro del perfil MIDP 1.0 y el mecanismo de serialización de objetos para la arquitectura J2ME [DIE2002].

2.4.1 ARQUITECTURA

Este proyecto consiguió 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 [DIE2002]. La arquitectura que se plantea en este proyecto se ilustra en la figura 2.5.

Figura 2.5 Servidor HTTP y serialización en J2ME [DIE2002]

Con esta arquitectura, los dispositivos no solo pueden utilizar servicios, si no que pueden ser también ellos mismos los que los proporcionan, dando acceso tanto a dispositivos móviles como a los que no lo son sin necesidad de un servidor intermedio [DIE2002].

2.4.2 VENTAJAS

La principal ventaja que presenta esta arquitectura es que permite ampliar las funcionalidades que ofrece J2ME para la integración con una plataforma de agentes.

2.4.3 DESVENTAJAS

El proyecto fue desarrollado utilizando MIDP 1.0. Ya está disponible la versión 2.0 la cual trae incorporadas algunas de las funcionalidades que se desarrollaron en este proyecto.

2.5 WIRELESS RESOURCE MANAGER

El objetivo de esta arquitectura es tener un Wireless Resource Manager (WRM) que elija el mejor acceso a la red teniendo en cuenta los estándares de calidad de servicio (QoS) requeridos por la aplicación, los costos del servicio y la disponibilidad de la red [MAL2003].

2.5.1 ARQUITECTURA

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 [MAL2003]. 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 [MAL2003]. 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 solicite [MAL2003]. La figura 2.6 ilustra la arquitectura del WRM y WDMI.

Figura 2.6 WRM [MR2003]

2.5.2 VENTAJAS

La ventaja más relevante que presenta esta arquitectura es que permite enrutar a la red más apropiada de acuerdo a las preferencias del usuario.

2.5.3 DESVENTAJAS

La principal desventaja de esta arquitectura es que tiene un único punto de falla, el WRM. Esto ocasiona que pueda existir cuello de botella y el rendimiento no sea el más óptimo.

2.6 WIRELESS APPLICATION PROTOCOL

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.

2.6.1 ARQUITECTURA

En el caso de WAP, el cliente utiliza un micro navegador que envía su petición al WAP Gateway. Este gateway 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, el cual las codifica y las envía al cliente del WAP [FAH2004]. La figura 2.7 ilustra este proceso.

Figura 2.7 WAP [WAP2004]

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 capas. en el que cada uno es accesible por la capa superior o por otros servicios y aplicaciones. La figura 2.8 ilustra el proceso de envío y recibo de paquetes de datos [FAH2004].

Figura 2.8 WAP Arquitectura [FAH2004]

2.6.2 VENTAJAS

La principal ventaja que se encuentra en WAP es que se puede navegar desde los dispositivos móviles independientemente de la plataforma operativa y del hardware.

2.6.3 DESVENTAJAS

Una desventaja que presenta WAP es que la presentación de la información depende de cada dispositivo cuando se utilizan los tags especializados, por lo que se debe realizar una presentación para cada tipo de dispositivo que se desee soportar.

2.7 WIRELESS ARCHITECTURE FOR ACCESS TO REMOTE

SERVICES

El objeto de WIARS es la creación de un ambiente plug and play donde diferentes tipos de dispositivos y servicios pueden trabajar conjuntamente sin que eso implique un gran esfuerzo. Es una arquitectura que requiere un proceso de instalación mínimo para acceder a servicios remotos de una manera sencilla utilizando el protocolo de acceso inalámbrico WAP y JINI.

2.7.1 ARQUITECTURA

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 [THA2000]. Esta arquitectura permite que cualquier entidad inicie el envío de mensajes, el cual se realiza de una manera bidireccional. El funcionamiento de la arquitectura se describe a continuación: 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.

2.7.2 VENTAJAS

La arquitectura WIARS tiene principalmente dos ventajas: Cualquier entidad puede iniciar la transmisión de mensajes. La comunicación se realiza de manera bidireccional.

2.7.3 DESVENTAJAS

La principal desventaja de WIARS es que es un proyecto y no está completamente probado.

2.8 ANÁLISIS DE LAS ARQUITECTURAS

La tabla 2.1 muestra un cuadro comparativo de las arquitecturas para dispositivos móviles presentadas anteriormente. En este cuadro se describe que limitación de los dispositivos móviles ataca, si tiene un único punto de acceso, si utiliza un gateway, que metodología utiliza para encontrar las otras entidades de la arquitectura, sus ventajas y desventajas.

Limitación Dispositivos Móviles

Puntos Único de Acceso

Gateway Protocolos de Comunicación

Método para buscar entidades

Ventajas Desventajas

P2MP Procesamiento limitado

Si aplica Si aplica HTTP, TCP/IP Busca en la raíz del árbol y establece después la conexión directa

Facilidad de búsqueda de las otras entidades.

Comparte el ancho de banda. A mayor nodos menor rendimiento.

P2CP Procesamiento limitado

No aplica No aplica HTTP, TCP Los datos se van pasando consecutivamente de uno a otro y si alguno falla empieza a girar en sentido contrario

Tiene un mayor ancho de banda

Es más costoso, más demorado

WRM Procesamiento limitado

Si aplica Si aplica HTTP, TCP A través del WDMI (Wireless Dependent Management Interfaces)

Permite enrutar a la red más apropiada de acuerdo a las preferencias del usuario

Tiene un punto único de falla. El rendimiento no es óptimo.

Limitación Dispositivos Móviles

Puntos Único de Acceso

Gateway Protocolos de Comunicación

Método para buscar entidades

Ventajas Desventajas

WIARS Intermitencia. Procesamiento limitado

Si aplica Si aplica Lookup Service de Jini

No aplica Envío de datos de forma bidireccional y cualquier entidad puede empezar la transmisión.

Es un proyecto y no está probado todavía.

SATIN Poca adaptabilidad de las aplicaciones con respecto al constante cambio de los requerimientos. Manejo de recurso de memoria

No aplica No aplica Bluetooth Chip Bluetooth Auto - organización automática de requerimientos. Si la memoria se está agotando elimina las aplicaciones menos utilizadas.

Es un proyecto. Al ser Bluetooth está restringido a 10 metros

HTTP / J2ME

Ninguna No aplica No aplica Sockets, TCP/IP No aplica Más funcionalidades de J2ME

MIDP 2,0 cubre algunas de las funcionalidades propuestas.

WAP Ninguna Si aplica Si aplica HTTP, TCP/IP No aplica Se puede navegar desde los dispositivos móviles.

La presentación de las aplicaciones depende de cada dispositivo.

Tabla 2.1 Análisis Arquitecturas

La mayoría de las arquitecturas para dispositivos móviles expuestas en este capítulo atacan la limitación de procesamiento. Lo anterior lo logran colaborando entre diferentes dispositivos como es el caso de P2P, P2MP y P2CP o enrutando la carga a otros dispositivos como lo hace Satín. Este concepto de colaboración y distribución de carga es clave para la arquitectura MAD (Mobility supported by Agent-based Devices) planteada en el capítulo 4. El concepto de comunicación bidireccional empleado por la arquitectura WIARS, en el cual cualquier entidad puede iniciar la comunicación y transmisión de datos es utilizado en la arquitectura MAD.

3. PLATAFORMAS PEER 2 PEER

La ventaja más importante de las redes P2P radica en que cualquier peer puede proveer servicios, actuando en determinadas ocasiones como un servidor y en otras como un cliente. Lo anterior permite que un servicio no dependa directamente de un solo punto sino por el contrario este servicio pueda ser suministrado por cualquier punto dando así soluciones más escalables donde el servicio no depende de una sola máquina [PJT2003]. En este capítulo se explican tres plataformas P2P: JXTA, JADE y BESA. Primero se describe la arquitectura de la plataforma JXTA junto con sus principales ventajas y desventajas. Posteriormente, se da una breve introducción a las arquitecturas basadas en agentes describiendo algunos conceptos generales de agentes y los estándares FIPA. Después de realizar esta introducción se plantea la estructura de la plataforma de agentes JADE. Finalmente, se describe la plataforma BESA que es la plataforma elegida para la implementación de la arquitectura MAD.

3.1 INTRODUCCIÓN

Como se mencionó en el capítulo 2, el término P2P hace referencia a redes descentralizadas y distribuidas en las cuales las aplicaciones pueden comunicarse entre sí, intercambiando información sin la intervención de un servidor central. La clave fundamental de P2P es que los nodos son tratados de igual a igual [BON2004]. Este concepto se aplica en diferentes plataformas entre las cuales se encuentra JXTA, JADE y BESA, analizadas a continuación.

3.2 JXTA

La computación distribuida es una manera de resolver problemas mediante la división del problema en subproblemas, los cuales pueden ser solucionados de manera independiente por diferentes equipos. Este concepto es la base de las redes P2P, donde los diferentes peers o puntos interactúan entre sí para lograr una meta en común. JXTA es una plataforma P2P por esta razón, es importante tener claro los conceptos de este tipo de red. A continuación se explican estos conceptos aplicados a JXTA [BRE2002]:

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. En la plataforma JXTA, estos puntos son de tres tipos.

o Simple peer: es el tipo más simple de peer sobre la red P2P, provee y consume recursos de otros peers de la red.

o Rendevous peer: punto que provee un mecanismo para descubrir otros peers de la red.

o Router peer: punto que se encarga de enrutar un peer que no tiene conexión directa con otro peer.

Peer group: conjunto de peers que tienen un interés en común. Los peers se auto organizan en grupos de peers los cuales tienen una identificación única. Los peer gropus proveen un grupo de servicios básicos implementados por los diferentes protocolos que forman parte de JXTA. Sin embargo, se pueden añadir nuevos servicios si se necesitan.

Advertisement: son meta datos que describen los recursos de una red. Estos advertisement son capturados, publicados e intercambiados entre peers para descubrir los recursos disponibles.

Los puntos son configurados para descubrirse de una manera espontánea en la red. Casi siempre sólo 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 esté comunicando. La figura 3.1.ilustra de manera general la interacción entre los puntos de una arquitectura JXTA.

Figura 3.1 Peers JXTA

3.2.1 ARQUITECTURA

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 [BRE2002]. 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 independiente y asincrónicamente con otros puntos. Puede existir alguna dependencia de puntos debido a ciertos 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. En la figura 3.2 se observan las tres capas principales de la arquitectura JXTA: aplicaciones, servicios y core.

Figura 3.2 Arquitectura JXTA

SSaammppllee AApppplliiccaattiioonnss

SSaammppllee SSeerrvviicceess

JXTA Applications

JXTA Services

JXTA Core

PPeeeerr PPeeeerr PPeeeerr

PPeeeerr SSeeccuurriitt

Any Connected Device

PPeeeerr

SSeeaarrcchh IInnddeexxiinngg DDiissccoovveerr MMeemmbbeerrsshhii

IInnssttaanntt FFiillee RReessoouurrccee

CCoollllaabboorraattiivvee CCoonntteenntt

3.2.1.1 PROTOCOLOS JXTA

En una red P2P es necesario que sean definidos protocolos que permitan: Encontrar un peer en la red. Encontrar un servicio que un peer esté prestando. Obtener información de otros peers. Utilizar los servicios que preste un peer. Crear, unirse y dejar un grupo. Crear datos de conexión para otros peers Enrutar un mensaje para otros peers.

Como se dijo anteriormente, JXTA define un conjunto de seis protocolos los cuales se describen a continuación [BRE2002]:

Peer Resolver Protocol (PRP): permite enviar y recibir consultas (queries) genéricas a través de un manejador (handler) que es el responsable de identificar el servicio sin importar en que peer se encuentre. Este protocolo es definido por dos tipos de mensajes XML:

o Resolver query: compuesto por los tags: credencial, nombre del manejador, id de la consulta, número de hosts por los que la consulta ha viajado y el query.

o Resolver response: compuesto por: credencial, nombre del manejador, id de la consulta y la respuesta.

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:

o Ping request: se compone de una credencial, id de origen, id destino.

o PeerInfo response: compuesto por una credencial, id de origen, id destino, tiempo, timestamp y un advertisement que representa al peer.

Endpoint Routing Protocol (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 previamente, la envía. En caso contrario, busca por la ruta para así poderla devolver.

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.

Peer Discovery Protocol (PDP): permite encontrar recursos que están representados en forma de advertisement. La forma en que este protocolo busca estos advertisements es buscando en su caché. Si no lo encuentra, éste le delega la tarea a un rendezvous que tiene pre configurado o buscando uno en la red y este peer finalmente le devuelve el advertisement que estaba solicitando. Este protocolo es definido por dos tipos de mensajes:

o Discovery query. o Discovery response

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

o Lease Request Message: usado por un peer para obtener permiso de conectarse al rendezvous

o Lease Granted Message: usado por el rendezvous para aprobar los peers

o Lease Cancel Message: usado por un peer para desconectarse del rendezvous.

Pipe Binding Protocol (PBP): Usado por las aplicaciones y servicios para comunicarse con otros peers. 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:

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

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

o Transferencia en lotes: Transferencia confiable de datos binarios.

o Streaming: Transferencia eficiente o Seguro: Transferencia segura de datos.

Existen varios tipos de conexiones usadas por un pipe y estas son: o JxtaUnicast: solo tiene uno que envía y uno que recibe. o JxtaUnicastSecur: similar a la anterior, pero la conexión es

segura usando el Transport Layer Security (TLS) protocol. o JxtaPropagate: proporciona la funcionalidad de broadcast entre

muchos endpoints que envían y que reciben. El PBP define dos tipos de mensaje para encontrar un pipe

o The Pipe Binding Query Message: sirve a un peer para preguntarle a otro si tiene el pipe que está buscando (con el pipe id).

o The Pipe Binding Answer Message: para enviar una respuesta a la consulta.

3.2.2 VENTAJAS

JXTA presenta varias ventajas. Las principales son: JXTA es un conjunto de protocolos P2P generalizados y abiertos que

permiten a cualquier dispositivo en Red, desde sensores a servidores de gran capacidad, conectarse, comunicarse y colaborar con otro dispositivo en una red, ya sea en una red local o en Internet.

Permite centrar los recursos de desarrollo en áreas en las que pueden crear e implementar nuevas soluciones, sin que haya que inventar o reinventar una infraestructura P2P.

Es una de las plataformas P2P líderes disponibles basadas en estándares de código fuente abierto.

3.2.3 DESVENTAJAS

JXTA, al tener un enfoque P2P tiene ciertas desventajas, tales como: La complejidad de los procedimientos necesarios para que los

componentes se encuentren unos a otros. Es inseguro debido a la vulnerabilidad a los virus y programas

maliciosos que pueden viajar con mayor libertad en un entorno P2P al tener conexión directa entre los puntos.

3.3 ARQUITECTURAS BASADAS EN AGENTES

A continuación se describe de manera general el concepto de agente, seguido por la descripción de los estándares FIPA. En las siguientes

secciones se explica la arquitectura de la plataforma de agentes JADE y BESA.

3.3.1 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 se tenga interés [SAM2000]. Una aproximación a la definición general 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” [WEI2001]. Según la anterior definición, 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 más estructurados, como puede ser información histórica o experiencias del agente con el medio, pero es importante aclarar que esto no es obligatorio (según la definición). Los agentes como tal pueden comunicarse con otros agentes, formando sociedades de agentes, que le sirven 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. El protocolo que se ha definido para la comunicación entre agentes es el KQML que significa “Knowledge Query and Manipulation Language”.

3.3.2 FIPA (Foundation for Intelligent Physical Agents)

FIPA es una organización cuya misión es “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 otras palabras, FIPA se encarga de desarrollar estándares para software de agentes, permitiendo así que diferentes sistemas de agentes interactúen. En la figura 3.3 se puede ver lo que propone FIPA con respecto a la construcción de plataformas de agentes.

Figura 3.3 Plataformas FIPA [DIN2004]

En la figura 3.3 se distinguen seis aspectos importantes en los cuales se debe basar cualquier plataforma de agentes [FIPA2002]:

AMS (Agent Management System): es un servicio de páginas blancas, que tiene como funciones principales:

o Mantener un directorio de agentes y encargarse del ciclo de vida de un agente.

o Controlar y supervisar 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 páginas amarillas)

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

Agente: es un proceso computacional que implementa la autonomía y las 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 uno o más servicios que son publicados en el DF.

Plataforma de Agentes (AP): es la infraestructura física en donde se desarrollan los agentes. El AP está compuesto por las máquinas, 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 un agente pero que este utiliza para ejecutar instrucciones o alguna funcionalidad en específico.

Existen en la actualidad muchas plataformas de agentes basadas en las especificaciones de FIPA como son LEAP, AAP, GRASSHOPER, entre otras [FIPA2003]. Sin embargo, en este capítulo sólo se analizan la plataforma JADE y BESA, ambas implementadas en Java.

3.4 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: 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) y son una abstracción del tipo de mensajes KQML.

3.4.1 ARQUITECTURA

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). La figura 3.4 ilustra la arquitectura JADE.

Figura 3.4 Arquitectura JADE [DIN2004]

La plataforma JADE tiene un único punto de falla en el contenedor principal (el main) debido a que si el main se cae entonces la plataforma toda se vendría al piso. Sin embargo, los desarrolladores de JADE previeron esto e hicieron que este main, aunque es un agente, puede estar en varias máquinas al mismo tiempo, tal y como lo muestra la figura 3.5 [BEL2003]:

Figura 3.5 Distribución del agente main [BEL2003]

En la plataforma del lado izquierdo sólo existe un main pero JADE da la opción que pueda existir más de un main tal y como se ve en la figura 3.5 del lado derecho. Así, si por ejemplo el main-container-1 no prestara más este servicio por cualquier motivo entonces, la plataforma quedaría como se ilustra en la figura 3.6 [BEL2003]:

Figura 3.6 Plataforma con dos main [BEL2003]

3.4.2 VENTAJAS

Es una plataforma probada y sobre la cual se han desarrollado aplicaciones [RIM2003].

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 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.4.3 DESVENTAJAS

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.

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, es tarea del programador a la hora de implementar cada comportamiento implementar el manejo de guardas.

3.5 BESA (Behavior-oriented, Event-driven and Social-based Agent

Framework)

BESA es una plataforma de agentes compatible con los estándares FIPA. Fue desarrollada en la Pontifica Universidad Javeriana y, como su nombre lo indica, se basa en tres conceptos principalmente [GON2003]:

Es orientada a la descomposición en comportamientos del agente. Utiliza una técnica de control orientada a eventos que implementa un

mecanismo de selección tomado de la programación concurrente. Maneja un soporte basado en mecanismos sociales para lograr la

cooperación entre agentes.

3.5.1 ARQUITECTURA

La arquitectura BESA está compuesta por tres niveles: nivel de agente, nivel social y nivel del sistema.

Nivel de Agente En el nivel de agente se trata todo lo referente a sus comportamientos y a los eventos a los cuales reacciona el agente [GON2003]. La figura 3.7 ilustra los componentes que forman un agente y la interconexión que hay entre ellos.

Figura 3.7 Arquitectura Interna de un Agente [GON2003].

Un agente está compuesto por un canal, un conjunto de comportamientos y un estado. El canal es el encargado de recibir todos los eventos que van dirigidos al agente. Estos eventos incluyendo los internos se procesan utilizando un selector de guardas que es quien filtra los eventos entrantes según el tipo que sean y los redirecciona al puerto correspondiente. Un comportamiento es un proceso que trabaja en paralelo con otros comportamientos para lograr las metas de un agente. Los comportamientos se registran ante las guardas asociadas a los eventos para poder recibir una notificación cuando el evento se realice. El código que implementa un comportamiento es genérico y el diseñador del agente tiene que construir solo la estructura de cómo reacciona ante determinado evento.

Nivel Social En el nivel social se trata lo referente a la comunicación que se lleva a cabo entre agentes a través de un modelo de programación de

eventos, donde una interacción se puede modelar por un evento bien definido, que se puede asociar a una guarda. En este nivel, se observa el concepto de organización, la cual está compuesta por un conjunto de agentes asociados y un agente mediador que es una entidad que actúa como facilitador del trabajo cooperativo entre los agentes que forman parte de la organización [GON2003].

Nivel de Sistema En el nivel de sistema es donde se define el ciclo de vida de los agentes y la administración de éstos [GON2003]. La figura 3.8 ilustra los componentes de un sistema típico BESA.

Figura 3.8 Modelo del Nivel de Sistema [GON2003].

El sistema contiene un único punto compatible con FIPA que es utilizado para establecer comunicación con otros sistemas externos. BESA puede estar formada por uno o más contenedores, entendiendo un contenedor como un espacio de ejecución donde habitan los agentes y es el encargado de manejar el ciclo de vida de éstos. Los contenedores manejan un sistema de replicación. Estos contenedores se encargan de registrar los agentes en las páginas blancas y si es necesario registran los servicios en las páginas amarillas.

3.5.2 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 éstos 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 más 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.

Disponibilidad del código y conocimiento detallado del mismo y del modelo de clases que los soporta

3.5.3 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 y amarillas 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.

4. ARQUITECTURA MAD (MOBILITY SUPPORTED BY AGENT-BASED

DEVICES)

Este capítulo explica de una manera detallada la arquitectura MAD (Mobility Supported by Agent-Based Devices) comenzando con una breve introducción que permite situarse dentro del contexto; posteriormente, se muestran las diferentes opciones que se tuvieron en cuenta en el momento de desarrollar la arquitectura. Finalmente, se plantean tres diferentes vistas de la arquitectura: general, física, lógica, y un ejemplo de una aplicación simple de la arquitectura MAD.

4.1 INTRODUCCIÓN

Después de analizar algunas Arquitecturas de dispositivos móviles entre ellas Satin [ZAC2003], Wireless Architecture for Access to Remote Services [THA2000] y Wireless Resource Manager [MAL2003], sus ventajas y desventajas, se rescataron algunos aspectos importantes que hacen referencia al manejo de las limitaciones de los dispositivos móviles. Estos aspectos sirvieron como punto de partida para plantear la arquitectura MAD (cf Capítulo 2). MAD es una arquitectura híbrida (P2P y P2MP), enfocada a aplicaciones para dispositivos móviles en “ambientes cerrados”, entendiendo un ambiente cerrado como un lugar que se puede definir dentro de unas fronteras físicas establecidas; por ejemplo, un centro comercial, un estadio, un hospital, un museo, un aeropuerto, entre otras. La arquitectura permite desarrollar aplicaciones que convivan con las limitaciones inherentes a los dispositivos móviles, como lo son:

Limitada capacidad de procesamiento y almacenamiento. Reducida duración de la energía. Intermitencia en la comunicación

Tomando los puntos anteriores como los requerimientos base de la arquitectura MAD se establecieron los siguientes conceptos fundamentales que caracterizan la arquitectura:

Un mundo se define como un conjunto de dispositivos con ciertas características en común ubicados en una determinada área geográfica. La arquitectura presenta dos mundos:

o SE: es el mundo estático en el cual los dispositivos permanecen fijos en un sitio geográfico determinado.

o DE: es el mundo dinámico en el cual los dispositivos son móviles, poseen las limitaciones que se mencionan anteriormente y pueden cambiar de ubicación geográfica continuamente.

La arquitectura tiene una estructura de red Peer to Peer la cual consiste en un grupo de entidades que se comunican cada uno directamente con los otros.

Los dispositivos móviles pueden cambiar de ubicación geográfica continuamente. La arquitectura soporta de manera transparente el cambio de sitio de los dispositivos a medida que se van desplazando utilizando los conceptos de roaming.

En el mundo estático SE, algunos de los servidores alojan recursos como bases de datos, archivos, Web Services a los cuales se accede manejando un esquema multicapa.

Debido a la reducida capacidad de almacenamiento que existe en los dispositivos móviles, la arquitectura maneja el concepto de repositorio de información en el cual se almacenan paquetes de datos llamados artefactos pertenecientes a los dispositivos móviles que no son utilizados en ese momento.

4.2 PROPUESTAS PLANTEADAS

Durante el proceso de análisis y diseño de la arquitectura surgieron varias posibilidades que atacaban una o varias de las limitaciones de los dispositivos móviles. Estas ideas fueron el punto de partida para la propuesta final. A continuación se enumeran las propuestas más relevantes clasificadas según la limitación que atacan.

4.2.1 LIMITADA CAPACIDAD DE PROCESAMIENTO

Para contrarrestar la reducida capacidad de procesamiento que tienen los dispositivos móviles se plantearon algunas posibilidades que se relacionan entre sí.

Una APP es una aplicación que se define como un conjunto de procesos que colaboran entre sí para cumplir una meta en común. Parte de los procesos de la APP están en el mundo estático SE y la otra parte en un dispositivo móvil MD. Cuando un proceso que está en el mundo dinámico DE no puede desarrollar su funcionalidad de una manera óptima puede solicitarle a otro proceso del mundo estático SE que le ayude a procesar la información y le devuelva el resultado cuando esté listo. Este concepto de aplicación APP distribuida entre el mundo estático y el dinámico es una parte importante de la arquitectura.

Los procesos del dispositivo móvil MD, al acercarse éste a un punto de acceso al mundo estático SE, establecen una conexión con él y crean imágenes suyas, llamadas representantes. El representante es el responsable de realizar el procesamiento pesado de las aplicaciones que requieren los procesos de la aplicación móvil. Cuando finaliza el procesamiento requerido, el representante envía el resultado al proceso del dispositivo móvil MD para que continúe con su funcionamiento. Este procedimiento sucede de una manera transparente para el usuario-programador. En caso de que el dispositivo móvil MD pierda la conexión, el representante es pasivado.

Una propuesta complementaria a la anterior, incluye además servidores en el mundo estático SE con gran capacidad de procesamiento. Los procesos de la aplicación móvil que necesitan ejecutar un procesamiento pesado solicitan el servicio. Cuando el servidor ha ejecutado el trabajo solicitado, envía los datos y/o la respuesta obtenida al solicitante. Este tipo de solución es adecuada si se utiliza una aproximación distribuida con múltiples servidores, evitando de esta forma cuellos de botella o puntos críticos de falla. Este concepto de servidores distribuidos que permiten un acceso controlado a los recursos y procesamiento por demanda es una parte importante de la arquitectura.

4.2.2 REDUCIDA CAPACIDAD DE ALMACENAMIENTO

Dada la limitación de almacenamiento de los dispositivos móviles se plantea un repositorio de datos que puede ser de dos maneras:

o Centralizado o Distribuido

En la arquitectura se utiliza el esquema de repositorio distribuido. El repositorio permite almacenar solamente artefactos que el dispositivo móvil no utilice en determinado momento. Las únicas operaciones permitidas sobre

estos artefactos son guardar y recuperar. Si el dispositivo móvil propietario desea realizar alguna modificación sobre el artefacto debe recuperarlo, realizar la operación y después volver a almacenarlo. Por cada artefacto se tendrá un comprobante con un identificador único de artefacto, el identificador del dispositivo móvil propietario, fecha de depósito y tiempo máximo de almacenamiento. El repositorio de información utiliza un directorio donde lleva el registro de los comprobantes de los artefactos que tiene almacenados. Si una aplicación APP1 desea que otra aplicación APP2 recupere su artefacto, la APP1 le envía el comprobante para que así la APP2 pueda recuperarlo.

4.2.3 REDUCIDA DURACIÓN DE ENERGÍA E INTERMITENCIA EN LA

COMUNICACIÓN

La intermitencia en la comunicación y la reducida duración de la energía, a pesar de ser dos limitaciones diferentes, tienen como consecuencia que el dispositivo móvil queda temporalmente sin conexión con el mundo estático. Por esta razón, se atacan de una manera similar. A continuación se explica la propuesta que surgió con respecto a este tema.

La arquitectura tiene un componente que funciona como un proxy, el cual es el encargado de verificar el estado del canal de comunicación entre los dispositivos del mundo estático SE y los del dinámico DE. Si la conexión de este canal se interrumpe, el proxy almacena temporalmente los mensajes que no se pueden enviar en una cola hasta que se restablezca la comunicación. Para el manejo de los mensajes almacenados en la cola surgen diferentes opciones:

o Verificar periódicamente si el canal se ha restablecido, y en caso dado enviar todos los mensajes pendientes.

o Disponer de un mecanismo asincrónico, soportado por el driver del dispositivo de comunicación, que notifique cuando el canal se ha restablecido.

o Adicionalmente a la detección del estado del canal, se puede incorporar un mecanismo de time-out a los mensajes. Después de cierto tiempo de espera se le notifica a la entidad que solicitó el envío del mensaje que no se pudo trasmitir por fallas en el canal de comunicación.

La solución adoptada para la arquitectura MAD es disponer de un mecanismo que notifique cuando el canal se ha restablecido. Adicionalmente, se incorpora el mecanismo de time-out a los mensajes. De esta manera se evita que la aplicación APP quede bloqueada.

4.3 VISTAS DE LA ARQUITECTURA

Teniendo en cuenta la variedad de elementos que conforman la arquitectura MAD, se organizó la presentación en diferentes vistas. Cada vista muestra una parte de la arquitectura. Todas las vistas tienen una relación entre si, y mirándolas en conjunto se tiene la visión completa del sistema. Se manejan cuatro vistas principales: general, lógica, física y la integración de las dos últimas.

4.3.1 MODELO DEL AMBIENTE GENERAL DE TRABAJO

A nivel general, la arquitectura MAD está conformada por dos mundos, el mundo dinámico DE y el mundo estático SE, que se comunican a través de un acceso inalámbrico WA. La figura 4.1 ilustra tanto la división de los dos mundos, como los dispositivos que se encuentran dentro de ellos. El mundo dinámico DE se entiende como el conjunto de dispositivos móviles MD que pueden cambiar continuamente de ubicación geográfica. Estos dispositivos móviles MD tiene un acceso inalámbrico WA para comunicarse con el mundo estático SE el cual se denomina acceso inalámbrico móvil MWA. El mundo estático SE es una agrupación de dispositivos estáticos SD, los cuales incluyen computadores personales, servidores, entre otros que no cambian de ubicación física, y de dispositivos livianos WSD. Los SD y los WSD están comunicados entre ellos a través de una red LAN o WAN que puede incluir una conexión inalámbrica. Así como los dispositivos móviles MD, los dispositivos del Mundo estático tienen un acceso inalámbrico WA que se llama acceso inalámbrico estático SWA. Tanto el acceso inalámbrico móvil MWA como el acceso inalámbrico estático SWA tienen un área de cubrimiento que puede variar dependiendo de la tecnología y el protocolo de comunicación que se utilice entre los dos mundos. Al conjunto de estas áreas de cubrimiento se le conoce como ambiente físico cerrado. Las áreas de cubrimiento pueden superponerse entre ellas, lo cual no es obligatorio. También pueden ser distantes, incluso estar en diferentes redes LAN o WAN. Por ejemplo, en la figura 4,1 los dispositivos móviles MD utilizan Bluetooth por lo cual tienen un alcance limitado en un ambiente libre de obstáculos. El dispositivo móvil MD1 se encuentra dentro del área de cubrimiento del dispositivo estático SD1; los dispositivos MD2 y MD3 dentro del área de cubrimiento del dispositivo liviano WSD1; y finalmente, el dispositivo MD4 se encuentra dentro del área de cubrimiento del dispositivo estático SD2. El dispositivo móvil MD1 establece comunicación con el dispositivo estático SD1; los dispositivos MD2 y MD3 establecen comunicación con el dispositivo

liviano WSD1; finalmente, el dispositivo MD4 establece una comunicación con el dispositivo estático SD2. Dos o más unidades Bluetooth que comparten un mismo canal forman una red conocida como piconet. En la figura 4.1 se observan 3 piconets, se ve que la segunda y la tercera piconet están en áreas de cobertura superpuestas, a lo que se le conoce como scatternet [BOR2004]. Adicionalmente, la figura 4,1 muestra que la primera piconet se encuentra distante de la segunda y tercera piconet.

SWA

SD1

SWA

WSD1

SWA

SD2

MD1

MWA

MD3

MWA

MD4

MWA

MD2

MWA

MUNDO ESTÁTICO SE

MUNDO DINÁMICO DE

SD Dispositivo EstáticoWSD Dispositivo LivianoSWA Acceso Inalámbrico EstáticoMD Dispositivo MóvilMWA Acceso Inalámbrico Móvil

LAN/WAN

Piconet Piconet

Piconet

Scatternet

Figura 4.1 Modelo del Ambiente General de Trabajo

4.3.2 MODELO FÍSICO DETALLADO

La arquitectura da la flexibilidad para que el mundo estático SE pueda estar compuesto por uno o más tipos de redes, que se comunican entre sí a través de un punto de acceso AP. De esta manera, se forma una red LAN o WAN utilizando el protocolo TCP/IP y se permite el acceso a través de Internet. Diferentes secciones de un mundo estático SE se pueden comunicar entre sí de una manera transparente utilizando Internet. La figura 4.2 ilustra estos conceptos de una manera clara. Por ejemplo, en la figura 4.1 se tiene un dispositivo móvil MD1 que se encuentra un Museo en un sitio A representado por la primera piconet observando la exposición de un artista. Al tener el dispositivo móvil MD1

dentro del área de cubrimiento de las obras de este artista representadas por el dispositivo estático SD1 se le informa que hay una exposición especial de esta obra en un Museo en un sitio B representado por la tercera piconet. Utilizando la idea que se planteó anteriormente se puede garantizar que el usuario de la aplicación APP que está en el sitio A acceda a la información que se tiene de esta obra en el sitio B de una forma transparente. Con respecto mundo dinámico DE y su comunicación con el mundo estático SE se presentan algunos obstáculos como lo son:

o Los dispositivos móviles MD cambian continuamente de ubicación geográfica.

o Existe intermitencia en la comunicación entre el mundo dinámico DE y el mundo estático SE.

El acceso inalámbrico WA es el encargado de amortiguar los problemas de comunicación y manejar el roaming de los dispositivos móviles MD entre las diferentes áreas de cubrimiento. Es importante recalcar que la comunicación entre el mundo estático SE y el mundo dinámico DE es asíncrona para poder manejar la intermitencia en la comunicación. Un MD se comunica con el SE a través de un acceso inalámbrico estático SWA pero como el MD puede desplazarse, podría recibir su respuesta desde otro SWA.

MD

MWA

MD

MWA

MDMWA

MDMWA

MDMWA

MDMWA

MDMWASD

WSD WSD WSD

SD

SDSWA

SWA

SWA

SD Dispositivo EstáticoWSD Dispositivo LivianoSWA Acceso Inalámbrico EstáticoMD Dispositivo MóvilMWA Acceso Inalámbrico MóvilAP Punto de Acceso

SWA SWA SWA

APRED INALAMBICA

TCP /IP

WAN - LAN TCP /IP

Figura 4.2 Detalle Soporte Físico

4.3.3 MODELO LÓGICO

El modelo lógico es una representación de las entidades que forman parte de la arquitectura a nivel de Software. Estas entidades se pueden clasificar en dos grupos: modelo de la aplicación APP y modelo de servicios.

4.3.3.1 MODELO DE LA APLICACIÓN APP

En este modelo se describen todas las entidades que hacen parte de una aplicación APP, colaborando entre ellas para que la APP pueda funcionar correctamente. La figura 4.3 muestra la representación de una APP y sus entidades internas.

APS

SP

SP

MP

MP

APPi

MP Peer MóvilSP Peer EstáticoAPP AplicaciònAPS Servidor de Punto de Acceso

SE

DE

APS

SP

SP

MP

MP

APPj

SE

DE

APS -A PSPeer 2 Peer

Figura 4.3 Aplicación APP

Una aplicación APP es un conjunto de procesos que permiten cumplir con una meta. Los procesos de la APP se pueden encontrar distribuidos entre los dos mundos, el mundo estático SE y el mundo dinámico DE. La ubicación de estos procesos se establece en el momento de hacer el despliegue de la APP. Las entidades que la conforman son:

o P: es un proceso, peer, que se define como cualquier entidad capaz de hacer un trabajo útil en el contexto de una aplicación APP y poder comunicarse con otra entidad en la red de una manera P2P. [BRE2002]. Hay dos tipos de peer:

o MP: se conoce como peer móvil y son los procesos que se encuentran dentro de una APP en el dispositivo móvil MD en el mundo dinámico DE.

o SP: se conoce como peer estático y son los peers P que se encuentran inmersos dentro de una aplicación APP en el mundo estático SE. Típicamente se encargan de procesar la información para que sólo se transmita los datos que la aplicación APP del dispositivo móvil necesita. De esta manera, se minimiza el tráfico de la red. Adicionalmente, se encarga de procesar las solicitudes de las aplicaciones APP de un dispositivo móvil, solicitando los servicios que se encuentran en el mundo estático SE. Los peer de diferentes aplicaciones pueden compartir los dispositivos donde se encuentran físicamente; sin embargo, están claramente separados en el mundo lógico. De esta manera, los peers P solo se comunican con peers P de la misma aplicación APP. Cuando se requiere comunicar un peer móvil MP con un peer estático SP se realiza a través del acceso inalámbrico WA en forma transparente.

o APS: es un peer que sirve como servidor de punto de acceso para permitir que los peer estáticos SP y móviles MP de una aplicación APPi se comuniquen con los SP o MP de una aplicación APPJ. El APS es un peer P que se caracteriza por ser el único punto de entrada y salida para la comunicación entre aplicaciones APP. Con lo anterior se busca encapsular una APP como una unidad cerrada y aumentar en cierta medida la seguridad. Para lograrlo, los peers de una misma aplicación APP comparten un password que se incluye en todos los mensajes.

4.3.3.2 MODELO DE SERVICIOS

El modelo de servicios muestra todas las entidades externas a una aplicación APP que le permiten acceder a un recurso como Bases de Datos, Web Services, Archivos, Dispositivos Físicos Externos, entre otras para consultar y procesar información que necesita para su correcto funcionamiento. La figura 4.4 muestra las entidades del modelo de servicios, empezando con las que se encuentran en el mundo estático SE y, posteriormente las que se encuentran en el mundo dinámico DE. Todos los recursos se acceden a través de una entidad llamada servicio S. Si el recurso se encuentra en el mundo X, el servicio S debe encontrarse en el mismo mundo.

SPBBR APP1

SSP

S1

R2

SE

APP1

S

R

DE

S ServicioR RecursoSSP Proveedor de Servicios EstáticosBR Recurso Base SPB Proveedor de Servicios BaseBS Servicio Base

SB

Figura 4.4 Modelo de Servicios

En el mundo estático SE se encuentran las siguientes entidades: o R: es un recurso que se define como un conjunto de elementos

disponibles para resolver una necesidad o llevar a cabo una tarea. Los recursos pueden ser: Bases de Datos, Web Services, GUI, Sensores, entre otras.

o S: es un servicio que se define como métodos que permiten realizar las operaciones CRUD (create, read, update, delete) sobre determinadas entidades recursos R que son necesarios para el funcionamiento de la aplicación. El S contiene la información del driver necesario para acceder al R. Por esta razón, el acceso a los recursos R siempre se realiza mediante un S y el servicio S siempre está controlando el acceso al R. La relación entre un recurso y un servicio es 1 a 1.

o SSP: es un proveedor de servicios estático que realiza una actividad de coordinación encargándose de invocar a uno o varios servicios S para poder recuperar la información que necesita la aplicación APP para cumplir con sus funciones. Dentro del proveedor de servicios estático SSP se puede realizar algún procesamiento sobre la información recuperada, brindando un mayor nivel de abstracción sobre el recurso. Un proveedor de servicios estático SSP puede acceder a varios SSP que se encuentren en la misma sección del mundo

estático SE y que realicen alguna funcionalidad de procesamiento que el SSP necesite.

En el mundo dinámico DE se encuentran las siguientes entidades: o BR: es un recurso base que se define como un conjunto de

elementos disponibles dentro de un dispositivo móvil para interactuar con el cliente; por ejemplo, el teclado, la pantalla, entre otros.

o BS: son métodos que se encargan de manejar el acceso a los recursos base BR del dispositivo móvil MD. El BS no tiene movilidad porque su característica principal es que están cerca del recurso base BR. La relación entre un BS y un BR es 1 a 1.

o SPB: es un proveedor de servicios base encargado de procesar las solicitudes realizadas por el peer móvil MP. Para cumplir lo anterior, el SPB accede a los recursos base BR a través de invocaciones a métodos de un servicio base BS y, si es necesario, realizan algún procesamiento.

Todas las entidades se ejecutan sobre un una plataforma operativa, la cual se define como una extensión de un lenguaje mediante una o más jerarquías de clases que implementan una funcionalidad y que (opcionalmente) pueden ser extendidas [ANT2004]. En el caso específico de la arquitectura MAD, la plataforma operativa debe ser capaz de encargarse de todas las interacciones de comunicación, soportando un directorio de páginas amarillas y páginas blancas. Adicionalmente, la plataforma operativa debe soportar la comunicación entre el mundo dinámico DE y el mundo estático SE y roaming.

4.3.3.3 Integración Modelo de Servicios y Modelo de la AP (Aplicación)

La figura 4.5 muestra la distribución de los componentes mencionados anteriormente en la arquitectura, distribuidos en los dos mundos, el mundo estático SE y el mundo dinámico DE.

APS1

SP11

SP12

MP12

SPB1

BR1APP1

MP11

APS2

SP21

SP22

MP22

SPB2

BR2APP2

MP21

SSP1SSP2

S2S1

R1R2

S ServicioSSP Proveedor de Servicios EstáticoR RecursoAPS Servidor de Punto de AccesoSP Peer EstáticoMP Peer MóvilBS Servicio BaseBR Recurso BásicoSPB Proveer de Servicios BaseAPP Aplicación

SE

DE

S-R SSP-S SP-SSP APS-APS SPB-BR BS-SPB P2P MP-SPB

BS1BS2

SP13

MP23

Figura 4.5 Modelo Lógico Abstracto

Los peers P de una aplicación APP se encuentran distribuidos en un dispositivo móvil MD y un dispositivo estático SD. Lo anterior le da ventajas a la arquitectura en cuanto al procesamiento y la limitación de memoria debido a que todo el trabajo pesado se podría hacer en el lado estático. El diseñador de la aplicación APP decide el número de peers móviles MP y peers estáticos SP que debe tener la APP, la funcionalidad de cada uno de ellos y el protocolo de interacción entre ellos. Sin embargo, cabe recalcar que para que la aplicación APP sea móvil el diseñador debe garantizar que por lo menos haya un peer móvil MP. La arquitectura permite que los peers móviles MP se muevan temporalmente al mundo estático SE. De esta manera se ataca la limitada capacidad de procesamiento de los dispositivos móviles.

Los peer móviles MP pueden tener acceso a los recursos base BR que se encuentran en el dispositivo móvil MD a través del proveedor de servicios base SPB. El mundo estático SE funciona de una manera similar al mundo dinámico DE. Los peers estáticos SP pueden acceder a los recursos R a través de los proveedores de servicios estáticos SSP. Los SSP invocan a los servicios S que se encuentran dentro de este mundo para poder acceder a los recursos R, los cuales se encuentran distribuidos dentro del SE. Los servicios pueden ubicarse según dos criterios:

Cercanía del recurso R: Los servicios S son el único punto de acceso a los R y manejan todo lo relacionado con el driver para acceder a ellos. Por esta razón deben estar siempre junto al R que van a acceder y la relación es de 1 a 1.

Comunicación con los proveedores de servicios estáticos: El servicio S es el punto intermedio entre los SSP y los R. Un proveedor de servicios estáticos SSP le solicita a un servicio S que acceda a un recurso R para obtener cierta información. El S está junto al R para poder recuperar los datos.

En el mundo estático SE, una aplicación APP puede tener un servidor de punto de acceso APS que permite que los peers estáticos SP de una aplicación APPi se comuniquen con los SP de una aplicación APPj. Lo anterior permite que haya una colaboración entre los procesos de diferentes aplicaciones APP y a su vez haya un nivel de confidencialidad de los peers P de una APP. El APS expone los servicios que prestan los P de su APP pero no especifica que P realiza determinada tarea. En la figura 4.5 se observa que la mayoría de las comunicaciones entre las entidades de la arquitectura MAD utilizan el protocolo RR (Request Reply). Por ejemplo, un peer estático SP le solicita un servicio a un proveedor de servicios estático SSP (request) y el SSP después de procesar la solicitud le devuelve una respuesta (reply). Sin embargo, el diseñador puede especificar que protocolo de comunicación desea utilizar entre los peers P propios de la aplicación APP. A continuación se explican las comunicaciones ilustradas en la figura 4.5. La nomenclatura utilizada para distinguir cada comunicación está formada por la sigla representativa de la entidad donde se origina la comunicación y la sigla de la entidad que recibe el mensaje.

S-R: Esta comunicación es la que utiliza un servicio S para acceder a un recurso R. El servicio S establece la conexión con el recurso, ya sea una base de datos, un Web Service, etc. y realiza la operación.

SSP-S: En esta comunicación el proveedor de servicios estático SSP hace una invocación a un método del servicio S para consultar o

modificar cierta información en un recurso R. El S procesa la petición y le devuelve el resultado al SSP.

SP-SSP: Un peer estático SP le solicita (Request) a un proveedor de servicios estático SSP cierta información. El SSP procesa la petición del SP y le devuelve (Reply) la respuesta a su solicitud. El protocolo que utiliza esta comunicación es RR.

APS-APS: La comunicación entre los servidores de punto de acceso APS es en cualquier dirección. Un APS perteneciente a la aplicación APPi solicita un servicio a la APPj. La APPi le envía a la APPj la respuesta del servicio que solicitó. Esta comunicación utiliza el protocolo RR y puede realizarse también de la APj a la APi.

BS-BR: La comunicación entre el servicio base BS y el recurso base BR es similar a la comunicación S-R. Se establece la conexión con el BR y el BS realiza la operación que necesite sobre el recurso base BR. El BR le devuelve los datos que solicitó.

SPB-BS: Esta comunicación, similar al a SSP-S del mundo estático SE, el proveedor de servicios base SPB hace una invocación a un método del servicio base BS para consultar o modificar cierta información en un recurso BR. El BS procesa la petición y le devuelve al SPB la información solicitada

MP-SPB: Esta comunicación es similar a la SP-SSP. Un peer móvil MP le solicita (Request) a un servicio base SPB cierta información que se encuentra en un recurso base BR del dispositivo móvil MD. El SPB procesa la petición y le devuelve (Reply) los datos solicitantes al MP.

P2P: La comunicación entre los peers P, ya sean móviles MP o estáticos SP, utiliza un protocolo de interacción entre los peers. El diseñador especifica según lo crea conveniente la comunicación entre los peers P y el servidor de punto de acceso APS, el cual es dependiente de la aplicación.

4.4 Integración del Modelo Físico y Lógico

Hasta el momento se han descrito tres vistas de la arquitectura MAD, la general, la lógica y la física. En la figura 4.6 se hace una integración de la vista lógica y la física para tener una idea completa de la arquitectura. Se distinguen los dos mundos, el estático SE y el dinámico DE. En el DE se observan las áreas de cobertura de los accesos inalámbricos WA dentro de las cuales están los dispositivos móviles MD. Estos MD tiene un acceso inalámbrico móvil MWA que es el que se encarga de la comunicación con el mundo estático SE a través del acceso inalámbrico estático SWA. Dentro de los MD hay ciertos recursos base BR que son locales a los MD. En el mundo

estático se encuentran los dispositivos fijos que se comunican entre ellos utilizando el protocolo una red WAN o LAN. Todos los MP de una aplicación APP se encuentran en el mismo dispositivo móvil MD. En el caso de los peers estáticos SP se pueden encontrar distribuidos en varios dispositivos estáticos SD. Esta es una decisión del diseñador.

Figura 4.6 Integración Lógico-Físico

4.5 Funcionamiento de la arquitectura

Para ilustrar de una manera clara el funcionamiento de la arquitectura MAD se plantea un ejemplo que se desarrolla en un Aeropuerto. Este ejemplo, además servirá para depurar y probar la arquitectura en la etapa de implementación.

4.5.1 Descripción de la Aplicación

El Aeropuerto es una aplicación de carácter informativa que, como su nombre lo indica, funciona dentro del ambiente cerrado de un aeropuerto. Un usuario que posee un dispositivo Móvil con un protocolo de comunicación

compatible con el de la arquitectura puede ejecutar la Aplicación y disfrutar de sus ventajas. El Aeropuerto presta diferentes funcionalidades:

Consultar salida y llegada de vuelos. Consultar el clima de la ciudad. Consultar el mapa de la ciudad. Consultar los principales sitios turísticos. El usuario, al llegar al Aeropuerto, ejecuta la Aplicación que tiene en el

dispositivo Móvil y puede realizar cualquiera de las consultas mencionadas anteriormente.

Para este ejemplo, se muestra el funcionamiento de la funcionalidad de Consulta de salida y llegada de vuelos.

4.5.2 Modelo Físico

En el modelo físico se muestra la distribución de los dispositivos tanto en el mundo estático SE como en el mundo dinámico DE. La figura 4.7 permite observar de una manera clara cómo está distribuido. Existen dos usuarios, A y B, con sus respectivos MD1 y MD2. Se encuentran distribuidos en el mundo dinámico DE y acaban de ingresar al ambiente cerrado del Aeropuerto. En el mundo estático SE se tienen dos dispositivos estáticos SD1 y SD2, que se comunican entre ellos a través del protocolo TCP/IP. Existen dos servidores, R1 y R2, que tienen una base de datos donde se encuentra la información que va a consultar la aplicación APP.

MD1

MWA

MD2

MWA

WSD

SD1

SWA

SD Dispositivo EstáticoSWA Acceso Inalámbrico EstáticoMD Dispositivo MóvilMWA Acceso Inalámbrico MóvilR Recurso

WAN - LAN TCP / IP

SD2SWA

R1

R2

Figura 4.7 Modelo Físico Ejemplo

4.5.3 Modelo Lógico

En el modelo lógico se muestra la distribución de los servicios S, los peers P y de las aplicaciones APP. La figura 4.8 ilustra la distribución de estas entidades dentro del ejemplo del Aeropuerto. Hay dos aplicaciones APP1 y APP2, corriendo dentro del ambiente cerrado. La APP1 tiene dos peers móviles MP y tres peers estáticos SP. La AP2 tiene tres peers móviles MP y dos peers estáticos SP. Hay dos servicios, S1 y S2 que acceden a los R1 y R2 respectivamente. Hay dos proveedores de servicios estáticos SSP1 Y SSP2, que utilizan los SP para acceder a la información de los Recursos.

APS1

SP11

SP12

MP12

SPB1

BR1APP1

MP11

APS2

SP21

SP22

MP22

SPB2

BR2APP2

MP21

SSP1SSP2

S2S1

R1R2

S ServicioSSP Proveedor de Servicios EstáticoR RecursoAPS Servidor de Punto de AccesoSP Peer EstáticoMP Peer MóvilBS Servicio BaseBR Recurso BásicoSPB Proveer de Servicios BaseAPP Aplicación

SE

DE

S-R SSP-S SP-SSP APS-APS SPB-BR BS-SPB P2P MP-SPB

BS1BS2

SP13

MP23

Figura 4.8 Modelo Lógico Ejemplo

4.5.4 Integración Modelo Físico y Modelo Lógico

La integración del modelo físico y lógico se muestra claramente en la figura 4.9.

Los MP de la APP1 se encuentran en el dispositivo móvil del usuario A, MD1. Por su parte, los MP de la APP2 se encuentran en el MD del usuario B, MD2. A diferencia de los MP, los SP de una APP se encuentran distribuidos en varios dispositivos. Dos de los SP de la APP1 se encuentran en el SD1 y uno en el SD2. La APP2 tiene sus dos SP en el SD1.

Los servicios S se encuentran en el servidor de base de datos al que están accediendo. El SSP1 se encuentra en el SD1 y el SSP2 en el SD2 y pueden acceder a cualquier S.

SP31

SP12

SP11

RED TCP/IP

SD1 SD

2

MD1 MPi1

MPij

BRk

SWA SWA

MWA

SD Dispositivo EstáticoMD Dispositivo MóvilMWA Acceso Inalámbrico MóvilSWA Acceso Inalàmbrico EstàticoSP Peer EstáticoMP Peer MóvilBR Recurso BásicoS ServicioSSP Proveedor de Servicios EstáticoR Recurso

SE

DE

MD1

MWAMP21

MP23

BRk

MWA

MP22

MWA

MD2

SP22

SP21

R1

R2

S1 S2

SSP1

SSP2

Figura 4.9 Modelo integración Ejemplo

4.5.5 Funcionamiento

El usuario A y B llegan al aeropuerto y corren la APP1 y APP2 respectivamente. Después de un tiempo, el usuario A decide consultar los vuelos de salida. Para realizar esta consulta, el usuario A selecciona la opción en su menú e instantes más tarde le aparece en su pantalla la información de todos los vuelos de salida. Por su parte, el usuario B que se encuentra esperando a una persona, decide consultar los vuelos de llegada de la aerolínea X. El usuario B selecciona la opción en su menú, el sistema le despliega las opciones de aerolíneas disponibles, el usuarios elige la opción X. En seguida le aparece en su pantalla la información correspondiente a los vuelos de llegada de la aerolínea que eligió. Todo lo anterior sucede de manera transparente para el usuario. Pero por detrás, en la arquitectura se establecieron comunicaciones, se realizaron consultas a las bases de datos, se enviaron y recibieron mensajes, entre otras actividades. En el momento en que el usuario A eligió la opción de consultar los vuelos de salida, el MP1, encargado de recibir peticiones del usuario y enrutarlas, envió la solicitud de consulta al SP1 de la APP1 que se encuentra en el SD1. El SP1 le solicita al SSP2 que se encuentra en el SD2 que le envíe la información de los vuelos de salida del día de hoy. El SSP2 accede al S1 que

es el encargado de ir al R1 (contiene información de vuelos) en el servidor 1 y le solicita la información. S1, al conocer la manera de acceder a R1, hace la consulta a la base de datos y devuelve la información al SSP2. El SSP2 devuelve la consulta al SP1 y el SP1 le envía los datos al MP1 que se la solicitó. El MP1 le envía los datos organizados al MP2 de la APP1 que es quien el que conoce cómo desplegar la información en pantalla. Finalmente, el MP2 realiza su función y el usuario A puede ver los vuelos de salida. Para mayor claridad en la figura 4.10 se ilustra claramente las etapas de este proceso.

SP31

SP12

SP11

5.

RED TCP/IP

SD1 SD

2

MD1

MP11

MP12

SWA SWA

MWA

SD Dispositivo EstáticoMD Dispositivo MóvilMWA Acceso Inalámbrico MóvilSWA Acceso Inalàmbrico EstàticoSP Peer EstáticoMP Peer MóvilS ServicioSSP Proveedor de Servicios EstáticoR Recurso

SE

DEMWA

R1

S1

SSP2

1.

2. 3.R1

4.

Figura 4.10 Usuario A

El caso del usuario B es más complejo. Cuando el usuario B elige la opción de consultar los vuelos de llegada de la aerolínea X se encuentra en el área de cubrimiento del SD1. Por esta razón, el MP1 de la APP2 recibe la solicitud del usuario y se la envía al MP2 que es el encargado de realizar las peticiones al SE (mundo estático). El MP2 le envía la petición al SP1 el cual le solicita al SSP2 que le envíe la lista de aerolíneas que hay en el sistema. El SSP2 sabe que el encargado de acceder a R2 (está la información de las aerolíneas) es el S2. Por esta razón le hace la solicitud a S2. En ese momento, S2 realiza la consulta a la Base de datos y regresa la información al SSP2. Mientras S2 realizaba su trabajo, SSP2 realizo una consulta a S1 con el nombre de aerolíneas que tiene vuelos durante el día. Cuando ambos Servicios le responden, SSP2 realiza un procedimiento para retornar sólo las aerolíneas con vuelos para ese día. El SSP2 envía esta información al SP1, quien envía los datos al MP2. El MP2 organiza la información y se la envía al

MP3 que es el que se encarga de mostrar la información en pantalla. Esta primera parte de la funcionalidad del APP2 se ilustra en la figura 4.11

RED TCP/IP

SD1 SD

2

MD1

SWA SWA

SD Dispositivo EstáticoMD Dispositivo MóvilMWA Acceso Inalámbrico MóvilSWA Acceso Inalàmbrico EstàticoSP Peer EstáticoMP Peer MóvilBR Recurso BásicoS ServicioSSP Proveedor de Servicios EstáticoR Recurso

SE

DE

SP22

SP21

R1

R2

S1

S2

SSP2

MD1

MP21

MP23

MWA

MP22

MWA

MD2

1.

2.

3.4.

5.

8.

R1

R2

67.

Figura 4.11 Usuario B Parte 1

El usuario B elige la aerolínea que desea consultar y se inicia el mismo proceso que para el usuario A. Pero, cuando el SP1 le va a enviar el resultado al MP2 se da cuenta que el dispositivo móvil ya no está en el área de cubrimiento del SD1. Por esta razón, el SP1 se mueve al SD2 (el diseñador decidió que los SP tenían movilidad) y como se da cuenta que si está en el área de cubrimiento del SD2 procede a enviar la información. El MP2 recibe los datos, se los reenvía al MP3 quien los despliega en la pantalla. Como en el caso del usuario A, esto es transparente para el usuario. En la figura 4.12 a y 4.12b se muestran las diferentes etapas que se llevaron a cabo para poder completar la solicitud del usuario.

SP22

SP21

RED TCP/IP

SD1 SD

2

MD2 MP

22

MP21

SWA SWA

MWA

SD Dispositivo EstáticoMD Dispositivo MóvilMWA Acceso Inalámbrico MóvilSWA Acceso Inalàmbrico EstàticoSP Peer EstáticoMP Peer MóvilS ServicioSSP Proveedor de Servicios EstáticoR Recurso

SE

DEMWA

R1

S1

SSP2

2.

3. 4..R1

5.

MP23

1.

Figura 4.12a Usuario B Parte 2.a

SP22

SP21

RED TCP/IP

SD1 SD

2

SWA SWA

SD Dispositivo EstáticoMD Dispositivo MóvilMWA Acceso Inalámbrico MóvilSWA Acceso Inalàmbrico EstàticoSP Peer EstáticoMP Peer MóvilS ServicioSSP Proveedor de Servicios EstáticoR Recurso

SE

DE

R1

S1

SSP2R1

MD2 MP

22

MP21

MWAMWA

MP23

6.

7.

Figura 4.12b Usuario B Parte 2.b

5. IMPLEMENTACIÓN DE LA ARQUITECTURA MAD

Para implementar un desarrollo de software existen diferentes metodologías que se pueden seguir. Para la implementación de la arquitectura MAD, Mobility supported by Agent-based Devices, se siguió el modelo cascada en donde se establecen las etapas de análisis, diseño, implementación, pruebas y mantenimiento. Este capítulo abarca las etapas de análisis, diseño e implementación de la arquitectura. Primero se realiza una introducción explicando qué incluye cada etapa. Posteriormente, se plantean los requerimientos tanto funcionales como no funcionales de la arquitectura MAD. A continuación, se muestra el diseño que se realizó teniendo en cuenta los requerimientos especificados. Finalmente, se realiza una descripción de cómo se implementó la arquitectura mostrando el modelo de interacción de las entidades involucradas.

5.1 INTRODUCCIÓN

El ciclo de vida del software es una sucesión de etapas por las que atraviesa un producto software a lo largo de su desarrollo y existencia [LOP2004]. En el caso de la arquitectura MAD se eligió el modelo cascada estableciendo las siguientes etapas:

Análisis: consiste en un análisis de las características y el comportamiento del sistema del cual el software va a formar parte. En los capítulos 1,2 y 3 se encuentra el resultado del análisis previo que se realizó al planteamiento de la arquitectura. Se analizaron las diferentes tecnologías y protocolos de comunicación que existen para los dispositivos móviles. De igual manera, se consideraron diferentes arquitecturas que existen para desarrollar aplicaciones para dispositivos móviles. Adicionalmente, se detectaron los requerimientos funcionales y no funcionales de la arquitectura MAD. Estos requerimientos se presentan en este capítulo en la sección 5.2.

Diseño: en esta etapa se establece la estructura que tiene la arquitectura. En el capítulo 4 se presentan las diferentes vistas que componen la arquitectura: general, física, lógica y de integración. Adicionalmente, se realizaron los diagramas de clases, el modelo de interacción entre agentes, el diseño de los servicios y del manejo de artefactos.

Implementación: consiste en la traducción del diseño que se realizó a un formato que sea legible para la máquina. En este capitulo se explica la metodología que se siguió para la implementación, los principales componentes y como interactúan entre ellos.

Pruebas: Una vez que se tiene el software realizado, comienza la fase de pruebas. El capítulo 6 muestra las pruebas que se realizaron sobre la arquitectura MAD utilizando un caso de estudio específico.

5.2 ANÁLISIS DE REQUERIMIENTOS

El propósito de la etapa de análisis es recolectar la información necesaria para el desarrollo de la arquitectura MAD. En esta etapa se establecen los requisitos que debe cumplir la arquitectura. Los requisitos se dividen en dos grupos: los funcionales y los no funcionales. Los primeros son los servicios que el sistema debe prestar, su funcionalidad. Los segundos representan aquellos atributos que debe exhibir la arquitectura, pero que no son una funcionalidad específica. Por ejemplo requisitos de fiabilidad, eficiencia, portabilidad, entre otros.

5.2.1 REQUERIMIENTOS FUNCIONALES

El análisis de los requerimientos funcionales se dividió en 6 grupos: recursos y servicios, aplicación, directorios, repositorio, peers y dispositivo móvil. De acuerdo a esta división, a continuación se enumeran los requerimientos funcionales de la arquitectura MAD con una breve descripción de los mismos.

Recursos y Servicios: dentro de este grupo se tiene 4 requerimientos que se ilustran en la figura 5.1 y se explican a continuación.

Figura 5.1 Recursos y Servicios

1. Consultar recurso: un servicio realiza una consulta a un recurso según la petición realizada por el proveedor de servicios. Corresponde al Read de las operaciones CRUD.

2. Modificar recurso: un servicio actualiza, ingresa o modifica información de un recurso según la petición realizada por el proveedor de servicios. Este requerimiento corresponde al Create, Update y Delete de las operaciones CRUD.

3. Solicitar servicio: los proveedores de servicios solicitan un servicio a servicio para llevar a cabo alguna tarea de la aplicación o acceder a un recurso.

4. Solicitar servicio al proveedor de servicios: un peer estático SP o móvil MP le solicita a un proveedor de servicios estático SSP o móvil BSP un servicio para que la aplicación APP cumpla su meta.

Aplicación: este grupo está conformado por 4 requerimientos que se ilustran en la figura 5.2 y se describen a continuación.

Figura 5.2 Aplicación

5. Comunicar aplicaciones APP: las aplicaciones APP se pueden comunicar a través de los servidores de punto de acceso APS para utilizar las funciones de otra aplicación APP y así, reutilizar código.

6. Correr aplicación APP: el usuario inicia la aplicación APP que desee utilizar en el dispositivo móvil MD. En ese momento se crean los peers P que sean necesarios en ambos mundos según lo diseñe el desarrollador de la aplicación APP.

7. Destruir aplicación APP: cuando el usuario del dispositivo móvil MD no desee seguir utilizando la aplicación APP, se destruyen los peers P que se habían creado en ambos mundos.

8. Deploy aplicación APP: para que el usuario del dispositivo móvil MD pueda utilizar la aplicación APP, se debe realizar previamente el deploy en el dispositivo móvil MD y en el mundo estático.

Directorios: la figura 5.3 muestra los requerimientos relacionados con el manejo de los directorios. Posteriormente, se realiza una breve descripción de los mismos.

Figura 5.3 Directorios

9. Consultar directorios: las diferentes entidades de la arquitectura, tanto en el mundo estático como en el dinámico, pueden consultar los directorios de páginas amarillas y páginas blancas para poder localizar a las otras entidades con las cuales van a establecer una comunicación.

10. Registrarse en directorios: las diferentes entidades deben registrarse ante los directorios incluyendo sus servicios para que otras entidades las puedan acceder.

Repositorio: para el manejo del repositorio se establecieron 3 requerimientos funcionales. En la figura 5.4 se ilustran estos requerimientos y posteriormente se describen.

Figura 5.4 Repositorio

11. Almacenar datos: la arquitectura soporta el manejo de un repositorio de datos en el mundo estático SE en el cual los

dispositivos móviles del mundo dinámico DE almacenan artefactos que no necesitan en ese momento.

12. Recuperar datos: el usuario del dispositivo móvil puede recuperar en cualquier momento la información almacenada en el repositorio de datos para realizar alguna operación sobre los datos.

13. Generar comprobantes: para identificar que artefacto le pertenece a cada dispositivo móvil se generarán unos comprobantes que contienen el identificador del propietario, del artefacto y el tiempo que debe ser almacenado.

Peers: este grupo comprende 4 requerimientos principalmente, los cuales se muestran en la figura 5.5 seguidos de una descripción.

Figura 5.5 Peers

14. Crear peer: se pueden crear peers estáticos SP o móviles MP a medida que se necesiten.

15. Destruir peer: así como se pueden crear peers, se pueden destruir peers según lo solicite la aplicación APP.

16. Comunicar peers: se pueden comunicar los peers de una aplicación APP que se encuentren en el mismo mundo entre ellos de una manera transparente, enviando solicitudes y respuestas para que la aplicación APP cumpla con sus objetivos.

Dispositivo Móvil: finalmente, este grupo abarca 2 requerimientos ilustrados en la figura 5.6 y descritos a continuación.

Figura 5.6 Dispositivos Móviles

17. Detectar dispositivo móvil MD: El acceso inalámbrico estático SWA debe detectar los dispositivos móviles MD que se encuentren dentro de su área de cubrimiento para poder establecer la comunicación.

18. Soportar Roaming: La arquitectura debe soportar la movilidad de los dispositivos móviles MD de tal manera que la aplicación APP corra sin importar la localización del dispositivo móvil MD dentro del ambiente cerrado.

5.2.2 REQUERIMIENTOS NO FUNCIONALES

La arquitectura MAD cumple con los siguientes requerimientos no funcionales:

Extensible y escalable: permite adicionar nuevos servicios, recursos, peers, dispositivos estáticos y móviles de manera transparente para el usuario y para el programador.

Segura: la arquitectura es segura tanto en la integridad como en la disponibilidad de los servicios. Adicionalmente, los peers de una aplicación APP sólo se pueden comunicar entre ellos y sólo se puede acceder a otra aplicación APP a través del servidor de punto de acceso APS.

Transparente: el manejo de la arquitectura es transparente tanto para el usuario como para el programador.

Portable: la arquitectura funciona correctamente independientemente del hardware, sistema operativo o versión de Java que utilicen.

Robusta: debe ser adaptable a las limitaciones de los dispositivos móviles.

Dentro de los requerimientos no funcionales se encuentran los requerimientos estructurales. Estos requerimientos se enumeran a continuación:

Ambiente Cerrado: La arquitectura soporta aplicaciones que corran en un lugar definido dentro de unas fronteras físicas establecidas; por ejemplo, un centro comercial, un estadio, un hospital, un museo, un aeropuerto, entre otras.

Orientada a Servicios: La arquitectura debe ofrecer una serie de Servicios a los que se puede acceder para poder cumplir con los objetivos de la aplicación APP.

Peer 2 Peer (P2P): La arquitectura tiene una estructura de red P2P la cual consiste en un grupo de dispositivos que se comunican cada uno directamente con los otros, siendo al mismo tiempo cliente y servidor.

Recursos Distribuidos: Para que exista tolerancia a fallos a la hora de dar disponibilidad y replicación de la información, los recursos deben ser distribuidos.

5.3 DISEÑO

Teniendo en cuenta los requerimientos identificados durante la etapa de análisis, se realiza el diseño de la arquitectura MAD. A continuación se enumera de manera general cómo se satisfacen cada uno de los requerimientos. Posteriormente, se muestra el modelo de interacción que existe entre cada una de las entidades que forman parte de la arquitectura MAD. Finalmente, se expone el diseño del acceso inalámbrico.

5.3.1 DISEÑO GENERAL DE LA ARQUITECTURA

El mundo estático SE y el mundo dinámico DE presentan una clara diferencia, el primero abarca todo tipo de dispositivos livianos o estáticos, mientras que el segundo encierra únicamente a los dispositivos móviles Sin embargo, los dos mundos tienen muchos requerimientos en común como son el manejo de directorios, peers, recursos y servicios. Para cumplir con estos requerimientos, la arquitectura MAD utiliza una plataforma de agentes que le brinda soporte de manera transparente en el manejo de la comunicación, la ubicación de los servicios S, recursos R y peers P. Se analizaron tres plataformas: JADE, JXTA y BESA (cf. Capítulo 3), y se eligió la plataforma BESA (Behavior-oriented, Event-driven and Social-based Agent Framework) debido al conocimiento que se tiene sobre el funcionamiento de la plataforma. BESA es una plataforma de agentes que cumple con los estándares FIPA; presta varias funcionalidades entre las que

se encuentran el manejo de páginas amarillas, páginas blancas, la creación de agentes y el envío de mensajes entre ellos. A continuación se menciona de manera global cómo se cumplieron con los requerimientos identificados durante la etapa de análisis:

Para cumplir con los requerimientos agrupados en recursos y servicios, directorios y peers se decidió que tanto en el mundo estático como en el dinámico, los servicios, peers, servidores de puntos de acceso y proveedores de servicios estén representados por agentes; aprovechando de esta manera todas las funcionalidades que ofrece la plataforma BESA.

Una aplicación APP es una asociación de peers, estáticos y móviles, que interactúan entre ellos para lograr una meta en común. Dado que los peers son agentes, para cumplir con los requerimientos agrupados en aplicación también se utiliza BESA.

El acceso a los recursos y al repositorio de datos se realiza a través de un agente llamado servicio que conoce cómo acceder al recurso o al repositorio de datos. En el caso del repositorio, el servicio conoce el funcionamiento del manejo de los comprobantes y cómo recuperar la información. Cuando se trate de cualquier otro recurso, el servicio contiene la información del driver y de esta manera sabe como acceder al recurso para realizar cualquier operación solicitada por la aplicación APP. De esta manera, se cumplen los requerimientos funcionales agrupados en manejo de directorios y recursos y servicios.

Finalmente, para cumplir los requerimientos necesarios para conectar el mundo estático SD con el mundo dinámico DE, agrupados en dispositivo móvil, se desarrolló un acceso inalámbrico WA que utiliza la tecnología de comunicación Bluetooth con la que cuentan un gran número de dispositivos móviles MD.

A continuación se muestra el modelo de interacción de agentes en donde se explica de manera detallada el funcionamiento de los anteriores componentes.

5.3.2 MODELO DE INTERACCIÓN

La arquitectura MAD está conformada por cuatro agentes: Peer: este agente depende de la aplicación APP, por lo que es

decisión del desarrollador determinar cómo se implementa. Puede ser móvil o estático y es el encargado de procesar las solicitudes del usuario.

APS: este agente es el único punto de entrada y salida de una aplicación APP. Es el encargado de solicitar y prestar servicios entre aplicaciones APP.

AM: este agente es el encargado de almacenar y recuperar los artefactos en el repositorio.

SSP: este agente es el encargado de invocar los servicios para acceder a los diferentes recursos ya sea un Web Service, una Base de Datos, etc.

La plataforma MAD provee una implementación de las funcionalidades básicas de cada agente. Esta implementación se hereda y cada desarrollador puede extender su funcionamiento según las necesidades de la aplicación APP que esté desarrollando. A continuación se presenta el modelo de interacción existente entre los cuatro agentes que conforman la arquitectura MAD. A1. Agente Peer: A continuación se plantea el análisis de las funcionalidades básicas de este agente.

a. Estado: 1. Referencia al agente APS. 2. Password de aplicación a la que pertenece. 3. Identificador de la aplicación a la que pertenece 4. Referencia al directorio de páginas amarillas y blancas. 5. Propio de cada aplicación.

b. Metas: M11. Enrutar artefacto para almacenar en repositorio. M12. Recuperar artefacto almacenado previamente en un

repositorio. M13. Registrarse en el servidor de punto de acceso APS. M14. Solicitar servicio prestado por otra aplicación APP. M15 Solicitar servicio de operaciones CRUD (create, read, update,

delete) sobre un recurso. M16. Prestar servicios a otras aplicaciones APP.

c. Entradas Sensoriales: i. Asincrónicas

No hay. ii. Sincrónicas

S.1.1. Encontrar al agente AM en las páginas blancas y amarillas.

S.1.2. Encontrar al agente SP en las páginas blancas y amarillas.

S.1.3. Encontrar al agente APS en las páginas blancas y amarillas.

S.1.4. Encontrar a otro agente Peer en las páginas blancas y amarillas.

d. Actuadores: S.1.5. Registrarse en las páginas amarillas y blancas.

e. Comportamientos: B1.1. Almacenar artefacto. Cumple con la meta M11 Mensaje / Evento: Artefact_Store_Reply, devolución de un mensaje que contiene si la acción se pudo realizar o no y el comprobante que identifica al artefacto que ha sido almacenado, la aplicación del dispositivo móvil a la que pertenece, el id del AM y la fecha de almacenamiento. Acción: El agente almacena en una tabla el comprobante recibido para poder recuperarlo en cualquier momento.

AM

1. Artefact_Store_Request

Peer

Repositorio Servicio

2. Almacenar artefacto

3. Arterfact_Store_Reply

B1.2. Recuperar artefacto. Cumple con la meta M12. Mensaje / Evento: Arterfact_Retrieve_Reply, se le devuelve el artefacto solicitado que se encontraba almacenado en el repositorio. Si se presenta una excepción, se devuelve la notificación correspondiente Acción: Almacena el artefacto mientras espera una instrucción final.

AM

1. Artefact_Retrieve_Request

Peer

Repositorio Servicio

2. Recuperar artefacto3. Artefact_Retrieve_Reply

B1.3. Solicitar servicio. Cumple con la meta M15. Mensaje / Evento: Service_Reply, se le devuelve la respuesta de acuerdo al servicio que solicitó. Si ocurre alguna excepción, se le retorna una notificación de lo sucedido. Acción: El desarrollador de la aplicación establece que se debe realizar de acuerdo a la respuesta obtenida y al objetivo de la aplicación APP.

ServiceProvider

1. Service_Request

Peer

Recurso Servicio

2. Procesar solicitud3. Service_Reply

B1.4. Registrar servicio Cumple M13. Mensaje / Evento: Service_Register_Reply, devuelve un mensaje de ACK indicando si el registro se realizó satisfactoriamente o ha fallado. Acción: El desarrollador de la aplicación establece que se debe realizar dependiendo del contenido del mensaje de ACK que reciba.

APS

1. Service_Register_Request

Peer

2. Service_Register_Reply

B1.5. Prestar servicio a otra aplicación APP. Cumple M14 Mensaje / Evento: Service_A_Request, se le envía un mensaje indicándole que servicio se requiere y los parámetros necesarios para llevarlo a cabo. La estructura que maneja estos parámetros la define el desarrollador. Acción: el Peer ejecuta el servicio solicitado de acuerdo al código programado por el desarrollador.

2. Service_A_Reply

1. Service_A_Request

APSPeer

B1.6. Solicitar servicio de otra aplicación APP. Cumple M14 Mensaje / Evento: Service_APP_Reply, devuelve un mensaje con la respuesta del servicio solicitado. Este mensaje puede ser de acuse de recibo ACK o con información dependiendo de cómo el desarrollador haya implementado el servicio. Acción: El desarrollador de la aplicación establece que se debe realizar dependiendo del contenido del mensaje que le llegue.

1. Service_APP_Request

2. Service_APP_Reply

APSPeer

A2. Agente SP

a. Estado: 1. Referencia al directorio de páginas amarillas 2. Referencia a los servicios S que puede acceder.

b. Metas: M21.Solicitar operación CRUD (create, read, update, delete).

c. Entradas Sensoriales: Asincrónicas

No hay. Sincrónicas

No hay. d. Actuadores:

S.2.1. Registrarse en las páginas amarillas y blancas. e. Comportamientos:

B2.1. Solicitar servicio. Cumple con M21 Mensaje / Evento: Service_Request, solicitud de realizar una operación CRUD en un recurso. La solicitud está compuesta por el tipo de operación que se desea realizar, y los datos necesarios para poder llevar a cabo la operación. Acción: El SSP hace una invocación al servicio encargado de realizar la operación solicitada, enviándole el tipo de operación y los datos necesarios. Respuesta: Se envía un mensaje con la respuesta del servicio solicitado al Peer que lo invocó. Si por alguna razón el servicio no se pudo llevar a cabo satisfactoriamente, se envía una excepción.

ServiceProvider

1. Service_Request

Peer

Recurso Servicio

2. Procesar solicitud3. Service_Reply

A3. Agente AM

a. Estado: 1. Referencia al directorio de páginas amarillas 2. Referencia al servicio S que puede acceder para el manejo del

repositorio. b. Metas:

M31. Almacenar artefacto. M32. Recuperar artefacto.

c. Entradas Sensoriales: Asincrónicas

No hay. Sincrónicas

No hay. d. Actuadores:

S.3.1. Registrarse en las páginas amarillas y blancas. e. Comportamientos:

B3.1. Almacenar artefacto. Cumple con M31 Mensaje / Evento: Artefact_Store_Request, solicitud de almacenamiento de un artefacto en el repositorio. La solicitud está compuesta por un mensaje que indica el identificador de la

aplicación dueña del artefacto, el tiempo que debe ser almacenado el artefacto y el artefacto para almacenar. Acción: El AM hace una invocación al servicio encargado de almacenar el artefacto en el repositorio, enviándole el artefacto, el id de la aplicación, su id (AM) y el tiempo que debe ser almacenado. Cuando se realiza el almacenamiento, el servicio le devuelve un comprobante que contiene el identificador de la aplicación que envió el artefacto, el identificador único del artefacto, el id del AM que solicitó el servicio y la fecha de almacenamiento. El servicio almacena el comprobante en una tabla. Respuesta: Se envía un comprobante hacia el peer P que envió la solicitud.

AM

1. Artefact_Store_Request

Peer

Repositorio Servicio

2. Almacenar artefacto

3. Arterfact_Store_Reply

B3.2. Recuperar artefacto. Cumple con M32 Mensaje / Evento: Arterfact_Retrieve_Request, solicitud para recuperar un artefacto que se encuentra en el repositorio. La solicitud está compuesta por un mensaje que indica el identificador de la aplicación que solicita el artefacto y el comprobante.

Acción: El AM verifica que el identificador de la aplicación que solicita el artefacto y la aplicación autorizada para recuperar el artefacto según el comprobante sea el mismo. Si esto se cumple, el AM hace una invocación al servicio encargado de recuperar el artefacto en el repositorio, enviándole el comprobante. Respuesta: Se devuelve el artefacto al Peer que lo solicitó. Si surgió alguna excepción porque la aplicación que solicitaba el artefacto no estaba autorizada para consultarlo o porque el tiempo de almacenamiento se había excedido, se envía la notificación respectiva.

AM

1. Artefact_Retrieve_Request

Peer

Repositorio Servicio

2. Recuperar artefacto3. Artefact_Retrieve_Reply

A.4. Agente APS

a. Estado: 1. Referencia al directorio de páginas amarillas 2. Tabla de usuarios y passwords autorizados para utilizar los

servicios que presta la aplicación. 3. Tabla de servicios prestados por la aplicación y el Peer que

presta el servicio.

b. Metas: M41. Registrar servicio. M42. Solicitar servicio a otra aplicación. M43. Prestar servicio a otra aplicación.

c. Entradas Sensoriales: i. Asincrónicas

S.4.1. No hay. ii. Sincrónicas

S.4.2. Consultar páginas amarillas y páginas blancas. d. Actuadores:

S.4.3. Registrarse en las páginas amarillas e. Comportamientos:

B4.1. Registrar servicio. Cumple con M41 Mensaje / Evento: Service_Register_Request, solicitud de registro del servicio que presta Peer a otra aplicación. El mensaje está compuesto por el identificador del peer, el identificador del servicio y los parámetros necesarios para llevar a cabo el servicio. Acción: El APS registra en su tabla el identificador del peer, el identificador del servicio y los parámetros necesarios para llevar a cabo el servicio. Respuesta: Se envía un acuse de recibo hacia el Peer que envió la solicitud de registro indicándole si fue exitosa o no.

APS

1. Service_Register_Request

Peer

2. Service_Register_Reply

B4.2. Solicitud de un servicio entre aplicaciones APP. Cumple con M42 y M43

Mensaje / Evento: Service_APS_Request, solicitud de consulta de un servicio que ofrece la otra aplicación APP. El mensaje está compuesto por el usuario y password, el identificador del servicio y los parámetros necesarios para llevar a cabo el servicio.

Acción: El APS verifica en su tabla de usuarios y password que estos sean correctos. Posteriormente, busca en su tabla de prestación de servicios y realiza la solicitud al peer correspondiente enviándole el identificador del servicio y los parámetros necesarios para llevar a cabo el servicio. Respuesta: Si el usuario y password no son válidos se retorna un mensaje de error. Si son válidos el usuario y el password, se retorna el resultado enviado por el peer que ejecute la solicitud. Mensaje / Evento: Service_APS_Reply, resultado que obtuvo el APS al solicitar el servicio a la otra aplicación APP. Acción: El APS reenvía el resultado al peer que le solicitó el servicio.

APS1

1. Service_APS_Request

2. Service_APS_Reply

APS2

B4.3. Solicitud servicio de un Peer a otra aplicación APP.

Cumple con M43 Mensaje / Evento: Service_APP_Request, solicitud de consultar un servicio en otra aplicación APP. La solicitud está compuesta por el identificador del servicio y los datos necesarios para ejecutar el servicio. Acción: El APS busca en las páginas amarillas que aplicación APP presta ese servicio y reenvía la solicitud. Respuesta: Se envía un mensaje con la respuesta del servicio solicitado. Si por alguna razón el servicio no se pudo llevar a cabo satisfactoriamente, se envía una excepción.

1. Service_APP_Request

2. Service_APP_Reply

APSPeer

B4.4. Solicitud por parte del APS a un servicio de un Peer.

Cumple con M43 Mensaje / Evento: Service_A_Reply, solicitud que contiene la respuesta del servicio solicitado al Peer. Acción: El APS reenvía la respuesta al APS que le solicitó el servicio.

2. Service_A_Reply

1. Service_A_Request

APSPeer

5.3.3 COMUNICACIÓN: ACCESO INALÁMBRICO

La arquitectura tiene dos tipos de accesos inalámbricos WA, uno en el mundo estático SE y otro en el mundo dinámico DE. Estos accesos inalámbricos WA son los encargados de manejar la comunicación y el roaming de los dispositivos móviles. A continuación se observa el diseño del acceso inalámbrico y el funcionamiento del envío y recibo de mensajes.

La implementación de los accesos inalámbricos se dividió en tres partes:

Dispositivo Móvil: En la figura 5.7 se observa todos los componentes encargados de comunicar al dispositivo móvil MD con el mundo estático. Así mismo, se encargan de encaminar los mensajes que le lleguen al dispositivo móvil al contenedor de agentes respectivo. El camino de salida al mundo estático SE de un mensaje proveniente de un agente del contenedor es un objeto llamado FachadaSalida, el cual se explicará más adelante. El mecanismo de entrada de los mensajes provenientes del mundo estático es el SensorDE, el cual también se explicará posteriormente.

Figura 5.7 Dispositivo Móvil

SWA: es el encargado de enrutar los mensajes correctamente. Si los mensajes provienen del mundo dinámico, el SWA los enruta automáticamente a la plataforma que está en el mundo estático. Si,

por el contrario, los mensajes provienen del mundo estático, el SWA verifica si hay canal con el dispositivo móvil respectivo. Si el canal funciona adecuadamente, enruta el mensaje al dispositivo móvil. En caso contrario, lo almacena en un vector al que se conoce como cola hasta que se reestablezca la conexión con el canal o hasta que el dispositivo móvil se conecte con otro SWA. Si se da este último caso, el SWA original le transfiere todos los mensajes encolados al nuevo SWA. La figura 5.8 ilustra cómo está conformado el SWA.

Figura 5.8 SWA

Plataforma: La figura 5.9 muestra los componentes de la plataforma. El componente más importante de esta parte es el SensorSE porque es el punto de entrada y salida a la plataforma de peers estáticos desde un dispositivo móvil MD.

Figura 5.9 Plataforma.

Todas las comunicaciones entre los peers pertenecientes a los dos mundos, el estático y el dinámico, cuentan con un método de verificación de envío y recepción de mensaje conocido como ACK (acuse de recibo). Por cada request y por cada reply se genera un ACK al peer que hizo la petición. El peer que hace la solicitud queda bloqueado hasta no recibir el acuse de recibo o cumplirse un time out. Las entidades que conforman el acceso inalámbrico pueden ser de cuatros tipos: hilos, componentes, objetos y agentes. La figura 5.10 muestra una visión completa del WA.

Figura 5.10 Acceso Inalámbrico

Hilos: el acceso inalámbrico está compuesto por ocho entidades implementadas como hilos, las cuales se enumeran a continuación:

o Sender_SWA: se encuentra en el mundo estático. Por cada dispositivo móvil, se crea un hilo Sender_SWA y es el encargado de enviar los mensajes hacia el dispositivo móvil.

o Receiver_SWA: se encuentra en el mundo estático. Al igual que el anterior, se crea un Receiver_SWA y es el encargado de recibir los mensajes que proceden del dispositivo móvil.

o ConectionManager_SWA: inicia el SWA para que pueda buscar dispositivos en el área de cubrimiento. Adicionalmente, tiene el hashtable de todos los dispositivos móviles en el área de cubrimiento

o Listener: este hilo forma parte del componente de comunicación Bluetooth, se encuentra en el mundo estático y reacciona al evento para encontrar un dispositivo móvil en el área de cubrimiento,

o Sender_MWA: se encuentra dentro del dispositivo móvil en el mundo dinámico y sólo puede haber uno por dispositivo móvil. Este hilo es el encargado de enviar los mensajes hacia el mundo estático.

o Receiver_MWA: se encuentra dentro del dispositivo móvil en el mundo dinámico. El Receiver_MWA es el encargado de recibir los mensajes que proceden del mundo estático.

o ConectionManager_MWA: inicia la conexión poniendo al dispositivo móvil en un estado tal que pueda ser encontrado por el SWA.

o Servicio: se encuentra en el dispositivo móvil y es el encargado de publicar el servicio cuando el dispositivo no está en un área de cubrimiento así, cuando llegue puede ser encontrado por un SWA.

Componentes: el acceso inalámbrico está conformado por ocho componentes, los cuales se mencionan a continuación:

o PaginasAmarillas_SE: este componente se encuentra en el mundo estático y es donde se encuentran expuestos los servicios prestados por los agentes de la arquitectura MAD.

o PaginasBlancas_SE: este componente también se encuentra en el mundo estático y tiene la referencia a todos los agentes utilizados para el funcionamiento de la arquitectura MAD.

o Sensor_SE: se encuentra en el mundo estático y es el mediador que le permite realizar el tratamiento adecuado a los mensajes. Estos tratamientos pueden ser de dos maneras:

o Enviar un mensaje a un peer en el mundo estático que proviene de algún dispositivo móvil.

o Recibir un ACK para así desbloquear el proceso que mandó un mensaje a algún dispositivo móvil.

o Proxy_SWA: encapsula la manera en que el SWA manda y recibe los mensajes del sensor_SE. En estos momentos se hace por sockets pero, en un futuro podría ser memoria compartida, RMI o un Web Service.

o Bluetooth: la comunicación entre el dispositivo móvil y el mundo estático se realiza la tecnología de comunicación Bluetooth (c.f. Capítulo 2).

o Sensor_DE: es un mediador que recibe los mensajes del mundo estático y les da el tratamiento adecuado, el cual puede ser de dos formas:

o Mandar el mensaje que llego a la plataforma de agentes del dispositivo móvil y, posteriormente, mandar un mensaje ACK al mundo estático para así desbloquear el proceso que envió un mensaje a este dispositivo.

o Recibir un ACK y así desbloquear el mensaje que está esperando el acuse de recibido.

o PaginasBlancas_DE: este componente se encuentra dentro del dispositivo móvil en el mundo dinámico y es donde se encuentran expuestos los agentes que corren en la aplicación APP dentro del mundo dinámico.

o PaginasAmarillas_DE: este componente también se encuentra dentro del dispositivo móvil en el mundo dinámico y contiene la información de los servicios prestados por los agentes de la arquitectura MAD dentro de la aplicación APP del mundo dinámico.

Objetos: el acceso inalámbrico tiene 4 objetos, enumerados a continuación:

o FachadaSalida: es un objeto que se encarga de encaminar los mensaje que vienen del mundo estático hacia el dispositivo móvil y de enrutar los mensajes que se dirigen al mundo estático a través del proceso Sender_DE.

o MesageManager_SE: es un objeto en el mundo estático que almacena los mensajes de los peers que pertenecen a la aplicación APP del dispositivo móvil MD. También almacena los mensajes de acuse de recibo ACK que se quieran enviar al dispositivo móvil MD. Este objeto no tiene movilidad. En futuras versiones de la arquitectura, se puede introducir la movilidad a las colas.

o MesageManager_DE: es un objeto en el mundo dinámico que se encuentra dentro del dispositivo móvil y almacena los mensajes que se van a enviar al mundo estático así como los mensajes de acuse de recibo

o Facilitador: es un objeto en el mundo estático que sirve para ubicar la cola perteneciente a cada dispositivo móvil.

Todos los elementos mencionados anteriormente son los encargados de realizar la comunicación entre los dos mundos, el estático y el dinámico, brindándole a MAD la transparencia de envío de mensajes entre peers estáticos SP y peers móviles MP. La implementación de MAD se realizó empleando la tecnológica de comunicación Bluetooth. Esta tecnología permite a los dispositivos móviles ofrecer un servicio en la parte del MWA y, en el SWA un listener que busca continuamente los dispositivos móviles que tienen el servicio Bluetooth publicado. De esta forma se ofrece al dispositivo un punto de entrada al mundo estático y, al mundo estático un punto de entrada al dispositivo a través de los streams de comunicación que se abren cuando el SWA encuentra un dispositivo móvil. Lo anterior posibilita la comunicación de los agentes que están en BESA-CE (plataforma de agentes que se encuentra en cada dispositivo móvil) con los agentes que están en BESA (plataforma de agentes distribuida en el lado estático) de una manera transparente. Al cambiar la tecnología de comunicación de Bluetooth a 802.11x es necesario que en el MWA se pueda publicar un servicio y que en el SWA se tenga un listener que permita ubicar dispositivos móviles que tengan el servicio activo. El servicio y el listener nos permitirán abrir streams de comunicación, los cuales se utilizarán en el proceso de envío y recepción de mensajes tanto en el dispositivo móvil como en el SWA sin importar la tecnología de comunicación. La idea anterior nos lleva a que lo fundamental al cambiar de tecnología de comunicación en la plataforma MAD es poder abrir los streams de comunicación por medio de un servicio publicado en los dispositivos móviles y un listener que está en todos los SWA buscando el servicio publicado y ya, cuando se tiene el manejo de streams, es igual sin importar la tecnología de comunicación que se tenga. Sin embargo se debe tener presente lo siguiente:

Cuando un DM no está en el área de cubrimiento, entonces éste publica el servicio para que así cuando entre al área de cubrimiento de algún SWA el dispositivo móvil pueda ser encontrado por el SWA.

Cuando un dispositivo móvil es encontrado por algún SWA, el dispositivo deja de publicar el servicio y el SWA registra el dispositivo como que está en su alcance.

Cuando un dispositivo móvil sale del área de cubrimiento de un SWA éste, a través de su listener, se da cuenta que el dispositivo ya no está en su área de cubrimiento y lo que hace es desregistrarlo para que así, cuando entre a través de otro SWA éste pueda registrarlo y solicitar los mensajes que pertenecen al dispositivo móvil.

6. CARACTERIZACIÓN DE LA ARQUITECTURA

Como proceso de validación y de verificación se entiende cualquier actividad orientada a determinar si los objetivos se han cumplido o no [MOL2003]. Más específicamente:

Verificación: comprueba la consistencia del software con respecto a especificaciones y requisitos.

Validación: comprueba si lo que se ha especificado (e implementado) es lo que el usuario realmente desea.

En este capítulo se muestra el proceso que se realizó para validar y caracterizar la arquitectura MAD. Para este proceso se utilizó un caso de estudio que se desarrolló con la plataforma MAD. El caso de estudio sirvió para verificar y validar los diferentes requerimientos presentados en el capítulo 5. Primero se presentan las diferentes alternativas de caso de estudio que se evaluaron, los criterios de selección y el caso de estudio seleccionado. Posteriormente, se explica brevemente el caso de estudio con su modelo de interacción respectivo. A continuación se muestran las pruebas que se realizaron y se presenta el análisis respectivo. Finalmente, se caracteriza la arquitectura determinando sus ventajas y desventajas.

6.1 CASO DE ESTUDIO

Durante la investigación surgieron diferentes opciones de casos de estudio con diferentes enfoques a la hora de implementarlos. Estos casos de estudio se evaluaron con respecto a unos criterios que se establecieron para confrontar la arquitectura MAD. A continuación se enuncian estos criterios para posteriormente presentar la evaluación de los diferentes casos de estudio presentados.

6.1.1 CRITERIOS

Para poder validar la arquitectura MAD se debe seleccionar un caso de estudio que permita evaluar los aspectos más importantes que la caracterizan. A continuación se explican los criterios que se establecieron para evaluar los diferentes casos de estudio:

Debe respetar las limitaciones de la arquitectura: o Ambiente Cerrado: la aplicación del caso de estudio se debe

ubicar en un ambiente delimitado por el área de cubrimiento. o Orientada a servicios: el ambiente cerrado debe ofrecer unos

servicios que lo describan como tal. Debe ser un reto frente a la arquitectura:

o Servicios y recursos distribuidos: para que exista tolerancia a fallos a la hora de dar disponibilidad.

o Servicios coordinados para acceder a ellos y reunir información: se deben ofrecer servicios que se compongan de otros servicios.

o Servicios en los dispositivos móviles: deben existir servicios para acceder a los recursos que se encuentran en el dispositivo móvil.

o Páginas amarillas y blancas: debe existir un directorio de páginas blancas y/o amarillas para lograr la ubicación de servicios y dispositivos dentro del ambiente cerrado

o Tenga comunicación entre los componentes de la arquitectura: debe existir una comunicación continua entre el mundo estático y mundo dinámico para poder atacar la limitación de intermitencia en la comunicación que tienen los dispositivos móviles.

o Permita almacenar datos en bodega: debe tener la opción de almacenar datos en un repositorio para de esta manera atacar la limitación de almacenamiento de los dispositivos móviles.

o Proyección: la proyección de la aplicación del caso de estudio puede ser comercial o social.

6.1.2 ALTERNATIVAS Y CASO DE ESTUDIO SELECCIONADO

Para validar la arquitectura MAD se plantearon 5 posibles aplicaciones: Agenda: esta aplicación es de carácter personal y consiste en

conectar varios dispositivos permitiendo organizar reuniones, consultar horarios disponibles de otras personas, solicitar números telefónicos, entre otras.

Vendedor ambulante: esta aplicación es de carácter empresarial y consiste en que los vendedores de las compañías puedan realizar consultas de disponibilidad de productos, clientes y su historial, registrar ventas, entre otras.

Museo: esta aplicación es de carácter informativo y consiste en que cuando un visitante del museo ingresa, se conecta automáticamente y puede consultar información sobre los cuadros, esculturas, los artistas y obtener información de otras exposiciones que se estén realizando sobre el mismo tema.

Aeropuerto: esta aplicación es de carácter informativo y permite a un usuario cuando ingresa a un aeropuerto consultar los vuelos para determinada ciudad, generar un itinerario de viaje, consultarlo, localizar a otra persona, entre otras.

Centro Comercial: esta aplicación es de carácter informativo y permite al usuario que cuando ingresa a determinado centro comercial pueda consultar las ofertas, las películas que se estén ofreciendo, localizar personas, entre otros.

Para realizar la evaluación de las diferentes aplicaciones se definieron los siguientes niveles para la tabla de comparación:

Alto: Satisface el requerimiento 100%. (5) Medio Alto: Satisface el criterio de un 75% a un 99%.(4) Medio: Satisface el criterio de un 50% a un 75%.(3) Medio Bajo: Satisface el criterio de un 25% a un 49%.(2) Bajo: Satisface el criterio de un 0.1% a un 24%.(1)

En la tabla 6.1 se muestra la matriz de las aplicaciones contra los criterios que debe cumplir para poder ser utilizada como caso de estudio. Agenda

Vendedor ambulante.

Museo Aeropuerto

Centro comercial

Ambiente cerrado

Medio Baja Alto Alto Alto

Servicios y recursos distribuidos

Medio Alto Medio Alto

Medio Alto Medio Alto

Servicios coordinados para acceder a ellos

Medio Bajo Alto Medio Alto

Alto Alto

Servicios en los dispositivos móviles

Alto Alto Medio Bajo

Medio Alto Medio

Agenda

Vendedor ambulante.

Museo Aeropuerto

Centro comercial

Paginas amarilla y blancas

Medio Medio Medio Alto

Alto Alto

Descompuesta en módulos

Alto Alto Alto Alto Alto

Tenga Comunicación

Alto Alto Medio Alto

Medio Alto Medio Alto

Permita almacenar datos en bodega

Medio Alto Bajo Medio Bajo Medio

Impacto tecnológico

Bajo Bajo Medio Alto

Alto Medio Alto

Proyección Comercial Comercial Social Comercial ComercialTotal 66,67% 73,33% 73,33 86,67% 84,44%

Tabla 6.1 Comparación entre aplicación y criterios Teniendo en cuenta el análisis realizado anteriormente, se escogió la aplicación del Aeropuerto por ser la que mejor cumple los criterios establecidos.

6.2 CASO DE ESTUDIO: AEROPUERTO

Como se explicó en el capítulo 4, el aeropuerto es una aplicación de carácter informativa que funciona dentro del ambiente cerrado de un aeropuerto. Para probar la arquitectura MAD, se desarrolló esta aplicación con las siguientes funcionalidades:

Consultar vuelos a una ciudad para determinada fecha. Generar un itinerario con base en las ciudades ingresadas por el

usuario, los días que desea permanecer en cada ciudad y la fecha de partida y almacenarlo en un repositorio.

Consultar el itinerario generado anteriormente. Localizar a otro usuario que esté dentro del aeropuerto. El usuario, al llegar al Aeropuerto, ejecuta la Aplicación que tiene en el

dispositivo Móvil y puede realizar cualquiera de las funcionalidades mencionadas anteriormente.

Las funcionalidades anteriores se eligieron porque permitían probar todos los aspectos claves de la arquitectura MAD. Sin embargo, se pueden implementar otras funcionalidades sin problema. A continuación se muestra el modelo de interacción de los agentes que forman parte de la aplicación Aeropuerto.

6.2.1 MODELO DE INTERACCIÓN

La figura 6.1 muestra de manera general el modelo de interacción entre los agentes de dos aplicaciones APP.

MP1MP2

SP1

MP3

APS1

AM SSP

S1

SPB

# vuelo counter

user passwd

service peerserviceserviceservice

APS2

MP1MP2

SP1MP3

SPB

S2

S3

WEB SERVICE

user passwd

service peerserviceserviceservice

BS1 BS2

# vuelo aerolinea hora destino

Figura 6.1 Modelo de Interacción.

A continuación se muestra el modelo de interacción de cada agente en particular. El agente AM y el SSP pertenecen a MAD y no son propios de la aplicación. De todas maneras se muestran a continuación para tener una visión completa del problema. A1. Agente MP1 (Recuperar Artefacto):

a. Estado: 1. Password de aplicación a la que pertenece.

2. Identificador de la aplicación a la que pertenece 3. Referencia al directorio de páginas amarillas y blancas.

b. Metas: M11. Recuperar itinerario (artefacto) almacenado previamente en

un repositorio.

c. Entradas Sensoriales: iii. Asincrónicas

No hay. iv. Sincrónicas

S.1.1. Encontrar al agente AM en las páginas blancas y amarillas.

d. Actuadores:

S.1.2. Registrarse en las páginas amarillas y blancas.

e. Comportamientos: B1.1. Recuperar artefacto. Cumple con la meta M11. Mensaje / Evento: Arterfact_Retrieve_Reply, se le devuelve el itinerario solicitado que se encontraba almacenado en el repositorio. Si se presenta una excepción, se devuelve la notificación correspondiente Acción: Le muestra el itinerario en pantalla al usuario utilizando el SPB del dispositivo móvil.

AM

1. Artefact_Retrieve_Request

MP1

Repositorio Servicio

2. Recuperar artefacto3. Artefact_Retrieve_Reply

A2. Agente ConsultarVuelos (MP3):

a. Estado: 1. Password de aplicación a la que pertenece. 2. Identificador de la aplicación a la que pertenece 3. Referencia al directorio de páginas amarillas y blancas.

b. Metas: M21 Solicitar servicio de consulta de vuelos.

c. Entradas Sensoriales: i. Asincrónicas

No hay. ii. Sincrónicas

S.2.1. Encontrar al agente SSP en las páginas blancas y amarillas.

d. Actuadores:

S.2.2. Registrarse en las páginas amarillas y blancas.

e. Comportamientos:

B2.1. Solicitar servicio consulta vuelos general. Cumple con la meta M21.

Mensaje / Evento: Service_General_Flights_Reply, se le devuelve la respuesta con todos los vuelos del día según el destino que haya escogido. Los datos regresados son el número de vuelo, el counter, la hora de salida y la aerolínea. Si ocurre alguna excepción, se le retorna una notificación de lo sucedido. Acción: El MP3 muestra la información en la pantalla al usuario utilizando el SPB del dispositivo móvil. Si existe una excepción, se le notifica al usuario que la operación no se pudo realizar.

ServiceProvider

1. Service_General_Flights_Request

MP3

Recurso Servicio

2. Procesar solicitud3. Service_General_Flights_Reply

A3. Agente MP2 (Localizador):

a. Estado: 1. Password de aplicación a la que pertenece. 2. Identificador de la aplicación a la que pertenece 3. Referencia al directorio de páginas amarillas y blancas.

4. Referencia al APS.

b. Metas: M31 Solicitar servicio prestado por otra aplicación APP. M32 Registrarse en el servidor de punto de acceso APS. M33 Prestar servicios a otras aplicaciones APP. M34 Solicitar servicio de generar itinerario al SP1.

c. Entradas Sensoriales: i. Asincrónicas

No hay. ii. Sincrónicas

No hay.

d. Actuadores: S.3.1. Registrarse en las páginas amarillas y blancas.

e. Comportamientos:

B3.1. Solicitar servicio de otra aplicación APP. Cumple M31 Mensaje / Evento: Service_ Position_Reply, devuelve un mensaje con la respuesta del servicio solicitado. Este mensaje contiene la localización de la persona que se buscó. Acción: El MP2 le muestre la ubicación en la pantalla al usuario de la aplicación APP a través del SPB del dispositivo móvil.

1. Service_Position_Request

2. Service_APP_Reply

APSMP2

B3.2. Registrar servicio Cumple M32. Mensaje / Evento: Service_Register_Reply, devuelve un mensaje de ACK indicando si el registro se realizó satisfactoriamente o ha fallado.

Acción: Si el registro en el APS falló, se reintenta una vez más.

APS

1. Service_Register_Request

MP2

2. Service_Register_Reply

B3.3. Prestar servicio a otra aplicación APP. Cumple M33 Mensaje / Evento: Service_Position_Request, se le envía un mensaje solicitándole el servicio de localización. Acción: el localizador retorna la ubicación en la que se encuentra el dispositivo móvil dueño de esta aplicación.

1. Service_Position_Request

2. Service_APP_Reply

MP2APS

B3.4. Solicitar generación de itinerario. Cumple M34 Mensaje / Evento: Service_ Schedule_Reply, devuelve un mensaje indicando si se generó exitosamente el itinerario o no. Acción: El MP2 le muestre el mensaje de éxito en la pantalla al usuario de la aplicación APP a través del SPB del dispositivo móvil.

SP1

1. Service_Schedule_Request

MP2

2. Service_Schedule_Reply

A4. Agente SSP

a. Estado: 1. Referencia al directorio de páginas amarillas 2. Referencia al servicio de la base de datos y del web service.

b. Metas: M41. Solicitar consulta a una Base de Datos. M42. Solicitar consulta a un Web Service.

c. Entradas Sensoriales: Asincrónicas

No hay. Sincrónicas

No hay.

d. Actuadores: S.4.1. Registrarse en las páginas amarillas y blancas.

e. Comportamientos:

B4.1. Solicitar consulta a un servicio. Cumple con M41 y M42. Mensaje / Evento: Service_General_Flights_Request, solicitud de realizar una consulta con el número de vuelo, el counter, la aerolínea, la hora según la ciudad destino que llega como parámetro. Esta solicitud puede venir del SP1 o del MP3. Acción: El SSP hace una invocación al servicio S1 que tiene la información de todos los números de los vuelos y los counters respectivos. Posteriormente, hace una invocación al servicio S2 que tiene la información de todos los números de los vuelos, la aerolínea, la hora y el destino del vuelo. El SSP hace un procesamiento y filtra los resultados por la ciudad de destino que le llegó como parámetro y combina la información de los

servicios para devolverle al agente que realizó la solicitud el número de vuelo, el counter, la aerolínea, la hora y ciudad destino de todos los vuelos del día. Respuesta: Se envía un mensaje con la respuesta del servicio solicitado al agente que lo invocó. Si por alguna razón el servicio no se pudo llevarse a cabo satisfactoriamente, se envía una excepción.

ServiceProvider

1. Service_General_Flights_Request

SP1

Recurso Servicio

2. Procesar solicitud3. Service_General_Flights_Reply

A5. Agente AM

a. Estado: 1. Referencia al directorio de páginas amarillas 2. Referencia al servicio S3.

b. Metas: M51. Almacenar artefacto. M52. Recuperar artefacto.

c. Entradas Sensoriales:

Asincrónicas No hay.

Sincrónicas No hay.

d. Actuadores: S.5.1. Registrarse en las páginas amarillas y blancas.

e. Comportamientos:

B5.1. Almacenar artefacto. Cumple con M51 Mensaje / Evento: Artefact_Store_Request, solicitud de almacenamiento de un itinerario (artefacto) en el repositorio. La solicitud está compuesta por un mensaje que indica el identificador de la aplicación dueña del artefacto, el tiempo que debe ser almacenado el artefacto y el artefacto para almacenar. Acción: El AM hace una invocación al servicio encargado de almacenar el artefacto en el repositorio, enviándole el artefacto, el id de la aplicación, su id (AM) y el tiempo que debe ser almacenado. Cuando se realiza el almacenamiento, el servicio le devuelve un comprobante que contiene el identificador de la aplicación que envió el artefacto, el identificador único del artefacto, el id del AM que solicitó el servicio y la fecha de almacenamiento. El servicio almacena el comprobante en una tabla. Respuesta: Se envía un comprobante hacia el peer SP1 que envió la solicitud.

AM

1. Artefact_Store_Request

SP1

Repositorio Servicio

2. Almacenar artefacto

3. Arterfact_Store_Reply

B5.2. Recuperar artefacto. Cumple con M52 Mensaje / Evento: Arterfact_Retrieve_Request, solicitud para recuperar un artefacto que se encuentra en el repositorio. La solicitud está compuesta por un mensaje que indica el identificador de la aplicación que solicita el artefacto y el comprobante. Acción: El AM verifica que el identificador de la aplicación que solicita el artefacto y la aplicación autorizada para recuperar el artefacto según el comprobante sea el mismo. Si esto se cumple, el AM hace una invocación al servicio encargado de recuperar el artefacto en el repositorio, enviándole el comprobante. Respuesta: Se devuelve el artefacto al MP1 que lo solicitó. Si surgió alguna excepción porque la aplicación que solicitaba el artefacto no estaba autorizada para consultarlo o porque el tiempo de almacenamiento se había excedido, se envía la notificación respectiva.

AM

1. Artefact_Retrieve_Request

MP1

Repositorio Servicio

2. Recuperar artefacto3. Artefact_Retrieve_Reply

A.6. Agente APS

a. Estado: 1. Referencia al directorio de páginas amarillas 2. Tabla de usuarios y passwords autorizados para utilizar los

servicios que presta la aplicación. 3. Tabla de servicios prestados por la aplicación y el Peer que

presta el servicio.

b. Metas: M61. Registrar servicio. M62. Solicitar servicio a otra aplicación. M63. Prestar servicio a otra aplicación.

c. Entradas Sensoriales: iii. Asincrónicas

No hay. iv. Sincrónicas

S.6.1. Consultar páginas amarillas y páginas blancas.

d. Actuadores:

S.6.2. Registrarse en las páginas amarillas

e. Comportamientos: B6.1. Registrar servicio. Cumple con M61 Mensaje / Evento: Service_Register_Request, solicitud de registro del servicio de localización que presta MP2 a otra aplicación. El mensaje está compuesto por el identificador del agente MP2, el identificador del servicio de localización y los parámetros necesarios para llevar a cabo el servicio (en este caso ningún parámetro). Acción: El APS registra en su tabla el identificador del peer MP2, el identificador del servicio y los parámetros necesarios para llevar a cabo el servicio. Respuesta: Se envía un acuse de recibo hacia el MP2 que envió la solicitud de registro indicándole si fue exitosa o no.

APS

1. Service_Register_Request

MP2

2. Service_Register_Reply

B6.2. Solicitud de un servicio entre aplicaciones APP. Cumple con M62

Mensaje / Evento: Service_APS_Request, solicitud de consulta de un servicio que ofrece la otra aplicación APP. El mensaje está compuesto por el usuario y password, el identificador del servicio de localización Acción: El APS verifica en su tabla de usuarios y password que estos sean correctos. Posteriormente, busca en su tabla de prestación de servicios y realiza la solicitud al peer MP2 enviándole el identificador del servicio de localización. Respuesta: Si el usuario y password no son válidos se retorna un mensaje de error. Si son válidos el usuario y el password, se retorna el resultado enviado por el MP2 que ejecute la solicitud.

Mensaje / Evento: Service_APS_Reply, resultado que obtuvo el APS al solicitar el servicio de localización a la otra aplicación APP. Acción: El APS reenvía el resultado al MP2 que le solicitó el servicio.

APS1

1. Service_APS_Request

2. Service_APS_Reply

APS2

B6.3. Solicitud de MP2 al APS de un servicio que presta otra

aplicación APP. Cumple con M62 Mensaje / Evento: Service_APP_Request, solicitud de consultar el servicio de localización en otra aplicación APP. La solicitud está compuesta por el identificador del servicio de localización. Acción: El APS busca en las páginas amarillas que aplicación APP presta ese servicio y reenvía la solicitud. Respuesta: Se envía un mensaje con la respuesta del servicio solicitado. Si por alguna razón el servicio no se pudo llevar a cabo satisfactoriamente, se envía una excepción.

1. Service_APP_Request

2. Service_APP_Reply

APSMP2

B6.4. Solicitud por parte del APS al servicio de localización del

MP2. Cumple con M63 Mensaje / Evento: Service_Position_Reply, solicitud que contiene la respuesta del servicio de localización solicitado a MP2. Acción: El APS reenvía la respuesta al APS que le solicitó el servicio.

1. Service_Position_Request

2. Service_APP_Reply

MP2APS

A7. Agente SP1:

a. Estado: 1. Password de aplicación a la que pertenece. 2. Identificador de la aplicación a la que pertenece

3. Referencia al directorio de páginas amarillas y blancas.

b. Metas: M71 Generar itinerario. M72 Guardar artefacto

c. Entradas Sensoriales: iii. Asincrónicas

No hay. iv. Sincrónicas

S.7.1. Encontrar al agente SSP en las páginas blancas y amarillas.

d. Actuadores:

S.7.2. Registrarse en las páginas amarillas y blancas.

e. Comportamientos:

B7.1. Solicitar servicio consulta vuelos general. Cumple con la meta M71.

Mensaje / Evento: Service_General_Flights_Reply, se le devuelve la respuesta con todos los vuelos del día según el destino que haya escogido. Los datos regresados son el número de vuelo, el counter, la hora de salida y la aerolínea. Si ocurre alguna excepción, se le retorna una notificación de lo sucedido. Acción: El SP1 genera el itinerario de acuerdo a la información que acaba de recibir y a las ciudades y días que le llegó en el evento Service_Schedule_Request y la almacena en un repositorio. Si existe una excepción, se le notifica al usuario que la operación no se pudo realizar.

ServiceProvider

1. Service_General_Flights_Request

SP1

Recurso Servicio

2. Procesar solicitud3. Service_General_Flights_Reply

B7.2. Solicitar generación de itinerario. Cumple M71 Mensaje / Evento: Service_ Schedule_Request, llega solicitud de generación de itinerario con la fecha de partida, las ciudades que quiere visitar, y el tiempo que desea permanecer en ellas. Acción: El SP1 le solicita al SSP la información de los vuelos para el primer destino. Escoge el primer vuelo, establece la fecha de llegada a la ciudad destino, le suma los días que va a permanecer y vuelve a solicitar la información al SSP del vuelo para esa fecha para la ciudad destino2. Y así sucesivamente hasta tener todo el itinerario. Si en algún momento no se consigue un vuelo disponible para esa fecha retorna error. Cuando se tenga el itinerario completo lo envía al repositorio.

SP1

1. Service_Schedule_Request

MP2

2. Service_Schedule_Reply

B7.3. Almacenar artefacto. Cumple con M72 Mensaje / Evento: Arterfact_Store_Reply, mensaje de éxito si el itinerario ha sido almacenado satisfactoriamente y el comprobante para poderlo recuperar posteriormente. Acción: El SP1 le notifica al usuario que su itinerario ha sido almacenado exitosamente a través del SPB.

AM

1. Artefact_Store_Request

SP1

Repositorio Servicio

2. Almacenar artefacto

3. Arterfact_Store_Reply

6.3 PRUEBAS

Utilizando el caso de estudio descrito anteriormente, se realizaron las pruebas de la arquitectura para poder caracterizarlo. Primero se realizaron las pruebas funcionales. Posteriormente se realizaron pruebas de stress y escalabilidad. Los resultados obtenidos y el análisis realizado se presentan a continuación. Las pruebas, como se había establecido en el anteproyecto, se realizaron en emuladores. Los simuladores con los que se trabajaron presentaron algunas limitantes en cuanto a la conexión Bluetooth y la conexión a través de un socket de un teléfono a una máquina conectada a una red TCP. El aplicativo del aeropuerto que está sobre la arquitectura MAD se intentó probar en dispositivos reales, pero se encontró un inconveniente muy grande con respecto a las máquinas virtuales debido a que no ofrecían el API de Bluetooth. Por esta razón, era imposible acceder al hardware que permitía una comunicación vía esta tecnología. Las máquinas virtuales con las que se probaron fueron:

Websphere everyplace micro Enviroment: que está disponible para los sistemas operativos Windows-ce y Palm OS. “HTTP://www-306.ibm.com/software/wireless/weme/library.html”

La máquina virtual que ofrece sun microSystem, pero solo está disponible para midp 1.0 HTTP://java.sun.com.

Las siguientes son algunas de las limitantes más importantes en cuanto a la simulación de Bluetooth en los teléfonos:

No se puede simular una conexión Bluetooth entre un teléfono y una máquina conectada a una red TCP y además que tenga el chip de conexión Bluetooth.

No se puede simular que un master Bluetooth (teléfono) tenga en su área de cubrimiento más de cuatro teléfonos.

Al subir un emulador con Bluetooth, no se le podrá configurar la dirección Bluetooth sino que siempre escogerá de una lista que no se puede modificar.

En cuanto a la primera limitante se resolvió poniendo el SWA en un teléfono y que este se comunicara con la plataforma a través de sockets. En cuanto a la segunda limitante, se convivió con ella y se hicieron las pruebas sabiendo que existía.

6.3.1 PRUEBAS FUNCIONALES

Usando la aplicación descrita anteriormente se probaron y corroboraron los requerimientos propuestos en el capítulo 5 de la arquitectura MAD. En la tabla 6.2 se muestra cómo cada caso de uso de la aplicación nos sirvió para demostrar la validez de la arquitectura:

Consultar vuelos

Localizar personas

Generar Itinerario

Consultar Itinerario

Consultar Recurso X X

Modificar Recurso X

Solicitar Servicio X X

Consultar vuelos

Localizar personas

Generar Itinerario

Consultar Itinerario

Solicitar servicio al proveedor de servicios

X X

Comunicar aplicaciones APP

X

Correr aplicación APP X X X X

Destruir aplicación APP

X X X X

Deploy aplicación APP

X X X X

Consultar directorios X X X X

Registrarse en directorios

X X X X

Almacenar datos X

Recuperar datos X

Generar comprobantes

X

Consultar vuelos

Localizar personas

Generar Itinerario

Consultar Itinerario

Crear peer X X X X

Destruir peer X X X X

Comunicar peers X X X X

Detectar dispositivo móvil

X X X X

Soportar roaming

Tabla 6.2 Requerimientos Funcionales Analizando la tabla 6.2 se observa que todos los requerimientos funcionales de la arquitectura se cumplieron excepto soportar roaming, el cual no se pudo probar por las limitaciones de los emuladores. Para comprobar los requerimientos no funcionales de la arquitectura se realizaron las pruebas de stress y escalabilidad.

6.3.2 PRUEBAS DE STRESS

Esta prueba consistió en poner un dispositivo móvil a solicitar consultas de vuelos durante determinado tiempo enviando 1000 mensajes continuos. Esta prueba se repitió 20 veces, obteniendo resultados similares. El objetivo de esta prueba fue medir que tan uniforme era el tiempo de respuesta cuando no se tenía un bombardeo de solicitudes. Para lograr lo anterior, se controló que ninguna solicitud se realizara hasta que la anterior solicitud no hubiera terminado. El servicio al que se accedía era una consulta a una base de datos con una conexión abierta que se encontraba en el mundo estático y era accedida desde el peer móvil en el mundo dinámico. La gráfica 6.2 ilustra los resultados obtenidos donde se muestra el tiempo que transcurre desde que se hace una solicitud de un peer móvil a un peer estático y se recibe la respuesta de la consulta realizada.

Figura 6.2 Número de solicitudes vs tiempo (1 MD)

En la figura 6.2 se observa que el tiempo de respuesta que hay desde el momento en que un peer móvil hace una solicitud a un peer estático y recibe la respuesta correspondiente se mantiene constante a medida que el número de solicitudes realizadas aumenta y corresponde a 63 milisegundos aproximadamente. Con lo anterior, se prueba que la arquitectura soporta un gran número de peticiones sin perder su eficiencia.

6.3.3 PRUEBAS DE ESCALABILIDAD

Para realizar las pruebas de escalabilidad se utilizó un agente en el mundo dinámico DE que realizara solicitudes permanentes a otro agente en el mundo estático, quien a su vez se encargaba de buscar un servicio determinado. El servicio era una consulta sencilla a una base de datos desde una conexión ya abierta con anterioridad. Se tomaron mediciones de tres tiempos: el tiempo en que sale la solicitud del agente del DE, el tiempo en que llega la solicitud al mundo estático SE y finalmente el tiempo en que la respuesta llega al agente en el DE. Estas mediciones se repitieron 20 veces. La figura 6.3 muestra el tiempo de respuesta cuando hay un solo proveedor de servicios SSP.

Figura 6.3 Tiempo de respuesta con 1 SSP

La diferencia que existe entre el primer tiempo medido hasta que el mensaje o la solicitud es encolada es constante y el tiempo desde que sale la solicitud hasta que llega la respuesta tiene un comportamiento lineal como se muestra en la figura 6.3 debido a que las solicitudes se van encolando. Lo anterior se puede representar de la siguiente manera:

T(i) = T(i-1) + tiempo que se demora el servicios para la solicitud i. Se realizó una regresión lineal de la gráfica de la figura 6.3 obteniendo una pendiente de 150.73. Este dato se utilizará más adelante para realizar una comparación entre experimentos. El mismo experimento, bajo las mismas características, fue realizado utilizando dos proveedores de servicios que eran accedidos de forma intercalada simulando un Round Robin desde el agente del mundo dinámico DE. Se obtuvo un tiempo de respuesta mucho menor debido a que la carga era dividida entre los dos proveedores de servicios disminuyendo el tiempo en que una solicitud permanecía en la cola. Este resultado se observa en la gráfica de la figura 6.4.

y = 24,82x + 191,42

0

200

400

600

800

1000

1200

1400

1600

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

# solicitudes realizadas

t res

pues

ta (m

s)

Figura 6.4 Tiempo de respuesta con 2 SSP

Es importante aclarar que los dos proveedores de servicios eran iguales y hacían una consulta a la misma base de datos desde una conexión ya establecida. Al igual que en el anterior experimento, se realizó una regresión lineal a la gráfica de la figura 6.4 obteniendo una pendiente de 24,82. Para aclarar el punto anterior, la figura 6.5 muestra la comparación entre el tiempo de respuesta (RR) con uno y con dos SSP.

Figura 6.5 Tiempo de respuesta con uno y dos SSP.

Como se ve en la figura 6.5, el tiempo de respuesta con dos proveedores de servicio se incrementa en un porcentaje mucho menor que cuando hay un solo proveedor. Retomando los valores de las pendientes obtenidos por la regresión lineal, vemos una clara diferencia debido a que con un SSP es de 150,73 mientras que con dos SSP es de tan solo 24.82. Con esto se demuestra que la arquitectura soporta escalabilidad, pudiéndose aumentar el número de agentes y recursos obteniendo mejores resultados.

6.4 CARACTERIZACIÓN DE LA ARQUITECTURA

La arquitectura MAD es una plataforma que facilita el desarrollo de aplicaciones móviles, haciendo que el tiempo de implementación de una aplicación disminuya notablemente. Lo anterior como consecuencia de las diferentes funcionalidades que ofrece MAD, entre las cuales están:

Permite heredar de clases abstractas ya probadas que ofrecen las funcionalidades necesarias para la comunicación entre el mundo dinámico DE y el mundo estático SE. En este momento, la arquitectura MAD utiliza un canal de comunicación Bluetooth. Sin embargo, MAD puede ser implementada utilizando cualquier tecnología de comunicación inalámbrica que soporte el dispositivo móvil.

Es una arquitectura que ofrece escalabilidad de servicios, recursos y peers, mejorando el desempeño. Lo anterior implica que la

arquitectura MAD permite trabajar en paralelo, haciendo clusters y ofreciéndole una mayor disponibilidad a los usuarios de los dispositivos móviles.

Un dispositivo móvil tiene recursos limitados de memoria; por esta razón, no puede almacenar mucha información. MAD le permite acceder a diferentes recursos ya sea una base de datos, un Web Service, una interface rmi, los cuales pueden estar distribuidos. Lo anterior sucede de una manera transparente para la aplicación que está corriendo en el dispositivo móvil.

Permite lidiar con las limitaciones inherentes a los dispositivos móviles como es la limitada capacidad de procesamiento permitiendo que las operaciones pesadas se realicen en el mundo estático y cuando esté listo el resultado se le envíe al dispositivo móvil en el mundo dinámico.

En la arquitectura MAD, una aplicación APP es independiente de cualquier otra aplicación APP a pesar de que una aplicación puede estar distribuida por toda la plataforma de agentes. Esto se garantiza mediante la implementación de un mecanismo de password, en el cual todos los peers pertenecientes a una aplicación APP comparten la misma clave. El único punto de entrada y salida de una aplicación APP es el APS; es decir, si una aplicación APP1 se quiere comunicar con otra aplicación APP2, debe hacerlo a través de los APS de cada aplicación.

La arquitectura MAD es una plataforma que encapsula las limitaciones inherentes a los dispositivos móviles, permitiendo desarrollar una aplicación móvil en un corto tiempo y funcionando adecuadamente. MAD provee las funcionalidades básicas para acceder a recursos como bases de datos, Web Services, para que el procesamiento se realice en el lado estático y todo sea transparente para el usuario y el programador.

DISCUSIÓN Y CONCLUSIONES

El uso de dispositivos móviles se ha incrementado notablemente en los últimos años. Las tendencias indican que el uso de los dispositivos móviles será superior al de los computadores personales. Lo anterior ha ocasionado que un gran número de empresas estén interesadas en desarrollar aplicaciones móviles.

Los dispositivos móviles tienen ciertas limitaciones inherentes a ellos como son: limitada capacidad de procesamiento, de memoria, intermitencia en la comunicación y poca duración de energía. Día a día, los desarrolladores tienen que lidiar con estas limitantes en el momento de diseñar sus aplicaciones.

J2ME es una herramienta para desarrollar aplicaciones para dispositivos móviles basado en tecnología Java. J2ME tiene una parte de las librerías de J2SE; sin embargo, tiene limitaciones como no soporta rmi, serialización, introspección limitada, entre otras.

Se encuentran algunas arquitecturas ya planteadas para desarrollar aplicaciones para dispositivos móviles que conviven con ciertas limitaciones pero casi ninguna ofrece la flexibilidad ofrecida por MAD.

Las redes Peer 2 Peer ofrecen ventajas frente al modelo tradicional como por ejemplo a mayor número de usuarios mejor el rendimiento, permite realizar procesamiento distribuido, es tolerante a fallos, entre otras.

Los agentes son entidades que tienen su propia autonomía y actúan en un ambiente de colaboración para lograr metas en común; permitiendo así el desarrollo de sistemas más dinámicos, versátiles y reales.

BESA es una plataforma de agentes que permite encapsular los estados, comportamientos y metas de un agente para que interactúe con otros a través de eventos.

BESA tiene una ventaja frente a otras plataformas de agentes y es que es multithread, el cual puede ser manejado por el que utilice la plataforma.

MAD es una arquitectura para el desarrollo de aplicaciones móviles que convive con las limitaciones de los dispositivos móviles y facilita el desarrollo de las aplicaciones.

MAD permite el desarrollo de aplicaciones orientadas hacia la movilidad constante de los usuarios, los cuales sólo deben tener un dispositivo móvil con Bluetooth y una máquina virtual KVM para poder correr una aplicación.

En MAD, una aplicación está distribuida, parte en el dispositivo móvil en el mundo dinámico y parte en el mundo estático. El procesamiento pesado de una aplicación se realiza en el mundo estático delegando gran parte de la carga del dispositivo móvil y conviviendo así, con la limitación de procesamiento.

TRABAJOS FUTUROS

El modelo abstracto planteado en el capítulo 4 de la arquitectura MAD es adaptable a la evolución de la tecnología. Para probar que el modelo de la arquitectura era viable se eligieron ciertas tecnologías cómo Bluetooth, J2ME y la plataforma BESA; sin embargo, la arquitectura MAD puede ser implementada utilizando diferentes tecnologías como 802.11, JADE o .NET CF. De igual manera, se podrá utilizar las nuevas tecnologías que surjan en un futuro.

La arquitectura MAD, adicionalmente a complementar la plataforma de agentes BESA desarrollada por el grupo SIDRE de la Pontificia Universidad Javeriana, sirve como base para futuros proyectos. Un ejemplo claro de este punto es el proyecto que se está realizando sobre un ambiente groupware que tendrá como base la arquitectura MAD.

BIBLIOGRAFÍA Y FUENTES DE INFORMACIÓN

1. [ACU2004] Acuña César Javier. Arquitecturas de Software. Universidad Rey Juan Carlos. 2004

2. [ANT2004] Antoniucci Javier. Manual Básico de Struts. 2004 en HTTP://programacion.com/java/tutorial/joa_struts/1/.

3. [BEL2003] Bellifemine F., Caire G, Trucco Tizana, Jade administrator guide. 2003.

4. [BOR2004] Borches Juzgado Pedro Daniel. Java 2 Micro Edition Soporte Bluetooth. Versión 1.0. Universidad Carlos III de Madrid. Marzo 2004

5. [BON2004] Bonilla, Antonio, Aplicaciones Distribuidas: P2P Departamento de Arquitectura de Computadores en la Pontificia Universidad de Cataluña. 2004 en HTTP://docencia.ac.upc.es/FIB/CASO/seminaris/2q0304/M9.pdf

6. [BRE2002] Brendon J. Wilson. JXTA. Riders Publishing. 2002.

7. [COM2004] Comcel. Aplicaciones 3GSM, ¿Qué es GPRS 3GSM?. 2004 en HTTP://www.comcel.com/aplicaciones3gsm/que_es.php.

8. [DIE2002] Diez Andino Guillermo. Diseño e implementación de un servidor HTTP y mecanismos de serializaciòn en J2ME.Universidad Carlos III de Madrid. 2002.

9. [DIN2004] Dinos Rojas Juan Larry, Arquitectura de un sistema basado en agentes para la recuperación de metadatos rdf en base a una ontología de documentos., Universidad de Puerto Rico, 2004 en HTTP://grad.uprm.edu/tesis/dinosrojas.pdf.

10. [FAH2004] Fahmy Sonia. Overview of Wireless Architectures and Products. Department of Computer Sciences at Purdue University. 2004 en HTTP://www.cs.purdue.edu/homes/fahmy/reports/leynawap.htm

11. [FIPA2002] Foundation for Intelligent Physical Agents. Fipa Agent Management Specification. 2002.

12. [FIPA2003] Foundation for Intelligent Physical Agents. Specification Users grouped by organisation. 2003 en HTTP://www.fipa.org/resources/byorganisation.html

13. [GAR2004] García Arenas, María Isabel. Curso WAP. Universidad de Granada. España. 2004 en HTTP://geneura.ugr.es/~maribel/wap/introduccion/index.shtml#1.

14. [GON2003] González Enrique, Ávila Jamir, Bustacara César. BESA: Arquitectura para la construcción de Sistemas Multi-Agentes. Pontificia Universidad Javeriana, Ingeniería de Sistemas. Bogotá, Colombia. 2003

15. [GRA2004] Grado – Caffaro Ángeles, Grado – Caffaro Martín. La tecnología CDMA. 2004 en HTTP://www.umtsforum.net/mostrar_articulos.asp?u_action=display&u_log=35. ICTNet.

16. [GSM2004] GSMSpain. GSM: El interface de radio. 2004 en HTTP://www.gsmspain.com/info_tecnica/gsm/index8.php.

17. [IEC2003] The International Engineering Consortium. Global System for Mobile Communication (GSM). 2003.

18. [IEC2004] The International Engineering Consortium. Personal Communication Service (PCS). 2004 en HTTP://www.iec.org/online/tutorials/pcs/topic01.html.

19. [ITAM2000] Instituto Tecnológico Autónomo de México. Estándar IEEE 802.11.b. 2000 en HTTP://ccomputo.itam.mx/redes/servicios/wlan/802_11b.htm.

20. [JUN2002] Juntao Michael, Let the mobile games begin, Part 1. A comparison of the philosophies, approaches, and features of J2ME and the upcoming .Net CF. Página 1. 2002 en HTTP://www.javaworld.com/javaworld/jw-02-2003/jw-0221-wireless.html

21. [JXTA2003] Project JXTA. JXTA v2.0 Protocols Specification en HTTP://spec.jxta.org/v1.0/docbook/JXTAProtocols.html#intro-fjp. 2003

22. [MAL2003] 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

23. [MOB2004] MobileInfo. I-Mode, Business Approach: NTTDoCoMo vs. European and American Telecoms. 2004 en HTTP://www.mobileinfo.com/imode/buz_approach.htm

24. [MOL2003] Ramón Mollineda, Tanja Vos. Calidad y Testeo del Software Actualidad Tic. 2003 en HTTP://www.iti.upv.es/actualidadtic/2003/07/2003-07-calidad.pdf

25. [PES2000] Pescador Darío. El futuro se llama UMTS. 2000 en HTTP://www.baquia.com/com/legacy/12082.html.

26. [PIC2004] Pickens John. Point to Multi Point (P2MP). Com21. 2004

27. [PJT2003] Project JXTA. JXTA v2.0 Protocols Specification. 2003 en HTTP://spec.jxta.org/v1.0/docbook/JXTAProtocols.html#intro-fjp.

28. [RIM2003] Rimaza Giovanni. Runtime Support for Distributed-multi- Agent systems. 2003.

29. [ROB2003] Robotiker. Tecnología Bluetooth (2): características del enlace radio y el establecimiento de la conexión en Revista Robotiker No. 4 del 2003 en HTTP://revista.robotiker.com/articulos/articulo28/pagina1.jsp.

30. [ROB2004] Robles Tomás, Middleware para provisión de servicios móviles. DIT-UPM. 2004 en www.catedra-amena.etsit.upm.es/descargas/middleware.ppt.

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

32. [SUN2003] Sun Microsystems Connected Device Configuration (CDC) and the Foundation Profile. Technical White Paper. 2003

33. [TAI2003] Taivalsaari Antero. “Connected Limited Device Configuration (CLDC)” Java™ 2 Platform, Micro Edition (J2ME™). 2003

34. [TER2004] Terra.com. GSM Global System for Mobile Communications. 2004 en HTTP://www.terra.es/tecnologia/glosario/ficha.cfm?id_termino=1430.

35. [THA2000] Thakkar Amisha. Wireless Architecture for access to Remote Services (WIARS). State University of New York at Buffalo. 2000

36. [VNU2002] Vnunet. “Los terminales se hacen inteligentes gracias a Java”. Julio del 2002 en HTTP://www.umtsforum.net/mostrar_articulos.asp?u_action=display&u_log=61.

37. [WEI2001] Weiss Gerhard, “Multagent System”, 2001.

38. [WML2004] Wireless Markup Language Club. ¿Qué es el I-Mode? 2004 en HTTP://www.wmlclub.com/articulos/imode.htm.

39. [ZAC2003] Zachariadis Stefanos. Use of Logical Mobility for Mobile Self-Organisation. Department of Computer Science University College London, University of London, Noviembre del 2003.

40. [ZON2001] ZonaBluetooth. ¿Que es Bluetooth?. 2001 en HTTP://www.zonaBluetooth.com/que_es_Bluetooth.htm

TABLA DE CONTENIDO INTRODUCCIÓN................................................................................................................................. 1 1. TECNOLOGÍAS ......................................................................................................................... 4

1.1 TECNOLOGÍAS DE TELEFONÍA CELULAR.................................................................. 4 1.1.1 TÉCNICAS DE MULTIPLEXACIÓN.............................................................................. 4

1.1.1.1 TDMA (Time Division Multiple Access) ............................................................................ 5 1.1.1.2 CDMA (Code Division Multiple Access)............................................................................ 5

1.1.2 TÉCNICAS DE COMUNICACIÓN................................................................................. 6 1.1.2.1 3GSM (Global System for Mobile Communications) ......................................................... 6 1.1.2.2 PCS (Personal Communication Services) ............................................................................ 6

1.2 TECNOLOGÍAS DE COMUNICACIÓN............................................................................ 7 1.2.1 BLUETOOTH.................................................................................................................. 7 1.2.2 IEEE 802.11 Wi - Fi ........................................................................................................ 8 1.2.3 BLUETOOTH vs 802.11b................................................................................................ 8

1.3 TECNOLOGÍAS INALÁMBRICAS PARA CONEXIÓN A INTERNET.......................... 9 1.3.1 I-MODE........................................................................................................................... 9 1.3.2 WAP (Wireless Application Protocol)............................................................................. 9 1.3.3 I-MODE vs WAP ............................................................................................................10

1.4 FRAMEWORK PARA DISPOSITIVOS MÓVILES .........................................................11 1.4.1 J2ME vs .NET CF...........................................................................................................11 1.4.2 J2ME ..............................................................................................................................13

2. ARQUITECTURA DE SOFTWARE PARA DISPOSITIVOS MÓVILES ..........................16 2.1 INTRODUCCIÓN ..............................................................................................................16 2.2 PEER TO PEER (P2P) ........................................................................................................16

2.2.1 POINT TO MULTIPOINT (P2MP) ................................................................................17 2.2.2 POINT TO CONSECUTIVE POINT (P2CP) .................................................................18 2.2.3 VENTAJAS Y DESVENTAJAS........................................................................................19

2.3 SATIN.................................................................................................................................19 2.3.1 ARQUITECTURA SATIN...............................................................................................20 2.3.2 VENTAJAS .....................................................................................................................21 2.3.3 DESVENTAJAS ..............................................................................................................22

2.4 SERVIDOR HTTP Y SERIALIZACIÓN EN J2ME...........................................................22 2.4.1 ARQUITECTURA...........................................................................................................22 2.4.2 VENTAJAS .....................................................................................................................23 2.4.3 DESVENTAJAS ..............................................................................................................23

2.5 WIRELESS RESOURCE MANAGER...............................................................................23 2.5.1 ARQUITECTURA...........................................................................................................23 2.5.2 VENTAJAS .....................................................................................................................24 2.5.3 DESVENTAJAS ..............................................................................................................24

2.6 WIRELESS APPLICATION PROTOCOL.........................................................................24 2.6.1 ARQUITECTURA...........................................................................................................24 2.6.2 VENTAJAS .....................................................................................................................25 2.6.3 DESVENTAJAS ..............................................................................................................26

2.7 WIRELESS ARCHITECTURE FOR ACCESS TO REMOTE SERVICES .......................26 2.7.1 ARQUITECTURA...........................................................................................................26 2.7.2 VENTAJAS .....................................................................................................................27

2.7.3 DESVENTAJAS ..............................................................................................................27 2.8 ANÁLISIS DE LAS ARQUITECTURAS ..........................................................................27

3. PLATAFORMAS PEER 2 PEER .............................................................................................29 3.1 INTRODUCCIÓN ..............................................................................................................29 3.2 JXTA...................................................................................................................................29

3.2.1 ARQUITECTURA...........................................................................................................31 3.2.1.1 PROTOCOLOS JXTA .......................................................................................................32

3.2.2 VENTAJAS .....................................................................................................................34 3.2.3 DESVENTAJAS ..............................................................................................................34

3.3 ARQUITECTURAS BASADAS EN AGENTES ...............................................................34 3.3.1 AGENTES.......................................................................................................................35 3.3.2 FIPA (Foundation for Intelligent Physical Agents)........................................................35

3.4 JADE (JAVA AGENT DEVELOPMENT FRAMEWORK): ...........................................................37 3.4.1 ARQUITECTURA...........................................................................................................37 3.4.2 VENTAJAS .....................................................................................................................40 3.4.3 DESVENTAJAS ..............................................................................................................40

3.5 BESA (BEHAVIOR-ORIENTED, EVENT-DRIVEN AND SOCIAL-BASED AGENT FRAMEWORK).40 3.5.1 ARQUITECTURA...........................................................................................................41 3.5.2 VENTAJAS .....................................................................................................................42 3.5.3 DESVENTAJAS ..............................................................................................................43

4. ARQUITECTURA MAD (MOBILITY SUPPORTED BY AGENT-BASED DEVICES)...44 4.1 INTRODUCCIÓN ..............................................................................................................44 4.2 PROPUESTAS PLANTEADAS.........................................................................................45

4.2.1 LIMITADA CAPACIDAD DE PROCESAMIENTO .......................................................45 4.2.2 REDUCIDA CAPACIDAD DE ALMACENAMIENTO ..................................................46 4.2.3 REDUCIDA DURACIÓN DE ENERGÍA E INTERMITENCIA EN LA COMUNICACIÓN........................................................................................................................47

4.3 VISTAS DE LA ARQUITECTURA...................................................................................48 4.3.1 MODELO DEL AMBIENTE GENERAL DE TRABAJO ................................................48 4.3.2 MODELO FÍSICO DETALLADO ..................................................................................49 4.3.3 MODELO LÓGICO .......................................................................................................51

4.3.3.1 MODELO DE LA APLICACIÓN APP .............................................................................51 4.3.3.2 MODELO DE SERVICIOS ...............................................................................................52 4.3.3.3 Integración Modelo de Servicios y Modelo de la AP (Aplicación).....................................54

4.4 INTEGRACIÓN DEL MODELO FÍSICO Y LÓGICO.....................................................................57 4.5 FUNCIONAMIENTO DE LA ARQUITECTURA............................................................................58

4.5.1 Descripción de la Aplicación .........................................................................................58 4.5.2 Modelo Físico.................................................................................................................59 4.5.3 Modelo Lógico................................................................................................................60 4.5.4 Integración Modelo Físico y Modelo Lógico .................................................................61 4.5.5 Funcionamiento..............................................................................................................62

5. IMPLEMENTACIÓN DE LA ARQUITECTURA MAD.......................................................66 5.1 INTRODUCCIÓN ..............................................................................................................66 5.2 ANÁLISIS DE REQUERIMIENTOS.................................................................................67

5.2.1 REQUERIMIENTOS FUNCIONALES...........................................................................67 5.2.2 REQUERIMIENTOS NO FUNCIONALES ....................................................................71

5.3 DISEÑO..............................................................................................................................72 5.3.1 DISEÑO GENERAL DE LA ARQUITECTURA .............................................................72 5.3.2 MODELO DE INTERACCIÓN ......................................................................................73 5.3.3 COMUNICACIÓN: ACCESO INALÁMBRICO .............................................................85

6. CARACTERIZACIÓN DE LA ARQUITECTURA ...............................................................94 6.1 CASO DE ESTUDIO ..........................................................................................................94

6.1.1 CRITERIOS ....................................................................................................................94 6.1.2 ALTERNATIVAS Y CASO DE ESTUDIO SELECCIONADO ........................................95

6.2 CASO DE ESTUDIO: AEROPUERTO..............................................................................97 6.2.1 MODELO DE INTERACCIÓN ......................................................................................98

6.3 PRUEBAS.........................................................................................................................115 6.3.1 PRUEBAS FUNCIONALES .........................................................................................116 6.3.2 PRUEBAS DE STRESS ................................................................................................117 6.3.3 PRUEBAS DE ESCALABILIDAD................................................................................118

6.4 CARACTERIZACIÓN DE LA ARQUITECTURA .........................................................121 DISCUSIÓN Y CONCLUSIONES...................................................................................................123 TRABAJOS FUTUROS ....................................................................................................................125 BIBLIOGRAFÍA Y FUENTES DE INFORMACIÓN ...................................................................126

ÍNDICE DE ILUSTRACIONES

Tabla 1.1. I-Mode vs WAP [MOB2004] .................................................................... 10 Tabla 1.2. Comparación Frameworks [JUN2002] ...................................................... 12 Figura 1.1. Plataforma J2ME [ROB2004] .................................................................. 14 Figura 1.2. CDC vs CLDC [ROB2004]...................................................................... 15 Figura 2.1 Arquitectura P2P [BON2004] ................................................................... 16 Figura 2.2 P2P vs P2MP [PIC2004] ........................................................................... 18 Figura 2.3 P2CP [PIC2004] ........................................................................................ 18 Figura 2.4 Arquitectura SATIN [ZAC2003]............................................................... 21 Figura 2.5 Servidor HTTP y serialización en J2ME [DIE2002]................................. 22 Figura 2.6 WRM [MR2003] ....................................................................................... 24 Figura 2.7 WAP [WAP2004]...................................................................................... 25 Figura 2.8 WAP Arquitectura [FAH2004] ................................................................. 25 Tabla 2.1 Análisis Arquitecturas................................................................................. 28 Figura 3.1 Peers JXTA................................................................................................ 30 Figura 3.2 Arquitectura JXTA .................................................................................... 31 Figura 3.3 Plataformas FIPA [DIN2004].................................................................... 36 Figura 3.4 Arquitectura JADE [DIN2004] ................................................................. 38 Figura 3.5 Distribución del agente main [BEL2003].................................................. 39 Figura 3.6 Plataforma con dos main [BEL2003] ........................................................ 39 Figura 3.7 Arquitectura Interna de un Agente [GON2003]. ....................................... 41 Figura 3.8 Modelo del Nivel de Sistema [GON2003]. ............................................... 42 Figura 4.1 Modelo del Ambiente General de Trabajo ................................................ 49 Figura 4.2 Detalle Soporte Físico ............................................................................... 50 Figura 4.3 Aplicación APP ......................................................................................... 51 Figura 4.4 Modelo de Servicios .................................................................................. 53 Figura 4.5 Modelo Lógico Abstracto .......................................................................... 55 Figura 4.6 Integración Lógico-Físico.......................................................................... 58 Figura 4.7 Modelo Físico Ejemplo.............................................................................. 60 Figura 4.8 Modelo Lógico Ejemplo ............................................................................ 61 Figura 4.9 Modelo integración Ejemplo ..................................................................... 62 Figura 4.10 Usuario A................................................................................................. 63 Figura 4.11 Usuario B Parte 1..................................................................................... 64 Figura 4.12a Usuario B Parte 2.a ................................................................................ 65 Figura 4.12b Usuario B Parte 2.b................................................................................ 65 Figura 5.1 Recursos y Servicios.................................................................................. 67 Figura 5.2 Aplicación.................................................................................................. 68 Figura 5.3 Directorios ................................................................................................. 69

Figura 5.4 Repositorio................................................................................................. 69 Figura 5.5 Peers........................................................................................................... 70 Figura 5.6 Dispositivos Móviles ................................................................................. 71 Figura 5.7 Dispositivo Móvil ...................................................................................... 86 Figura 5.8 SWA .......................................................................................................... 87 Figura 5.9 Plataforma.................................................................................................. 88 Figura 5.10 Acceso Inalámbrico ................................................................................. 89 Tabla 6.1 Comparación entre aplicación y criterios.................................................... 97 Figura 6.1 Modelo de Interacción. .............................................................................. 98 Tabla 6.2 Requerimientos Funcionales ..................................................................... 117 Figura 6.2 Número de solicitudes vs tiempo (1 MD) ............................................... 118 Figura 6.3 Tiempo de respuesta con 1 SSP............................................................... 119 Figura 6.4 Tiempo de respuesta con 2 SSP............................................................... 120 Figura 6.5 Tiempo de respuesta con uno y dos SSP. ................................................ 121

ÍNDICE DE TABLAS

Tabla 1.1. I-Mode vs WAP ......................................................................................... 10 Tabla 1.2. Comparación Frameworks ........................................................................ 12 Tabla 2.1 Análisis Arquitecturas................................................................................. 28 Tabla 6.1 Comparación entre aplicación y criterios.................................................... 97 Tabla 6.2 Requerimientos Funcionales ..................................................................... 117