Documento de Arquitectura Generalidades y Moviles

DOCUMENTO DE ARQUITECTURAS DE SOFTWARE
Una arquitectura de software es la base para representar la estructura de un
sistema de una manera abstracta y que sea fácil de interpretar el modelo que
encapsula. Una buena arquitectura explica claramente los elementos que la
forman y la manera en que se comunican entre ellos.
En este capítulo hablaremos de manera general sobre las arquitecturas de
software, sus característicos y estilos arquitectónicos. Posteriormente,
explicaremos algunas arquitecturas basadas en agentes, P2P y de dispositivos
móviles, analizando sus ventajas y desventajas.
Finalmente, haremos un análisis comparando las diferentes arquitecturas para
poder obtener lo mejor de cada una y que nos sirva de base para nuestro
proyecto de grado.
1. GENERALIDADES
Para poder hablar de algún tema en particular lo primero que se debe tener
claro es su definición y características. A continuación, hablaremos de una
manera general sobre qué es una arquitectura de software, sus elementos,
objetivos y cómo debe ser el lenguaje que se utiliza para expresarla.
Finalmente, hablaremos sobre los diferentes estilos arquitectónicos que
existen, analizando sus ventajas y desventajas.
1.1.
DEFINICIÓN:
La arquitectura de software de un programa o de un sistema computacional
está definida por la estructura, comprendida por los elementos de software,
las propiedades visibles de esos elementos y las relaciones entre ellos. Se
incluyen los siguientes elementos:
•
La descripción de los componentes (servidores, clientes, bases de
datos, filtros, capas en un sistema jerárquico, etc. ) con los cuales se
construyen los sistemas
•
Las interacciones (llamadas a procedimientos, protocolos C/S,
protocolos de acceso a BD, etc) entre esos componentes
•
Patrones para guiar la composición
•
Restricciones sobre dichos patrones [AC2004].
1.2.
OBJETIVOS:
Algunos de los objetivos que se buscan alcanzar al diseñar una arquitectura
de software son los siguientes:
•
Comprender y mejorar la estructura de las aplicaciones complejas.
•
Reutilizar dicha estructura (o partes de ella) para resolver problemas
similares.
•
Planificar la evolución de la aplicación, identificando las partes que
cambian y las que permanecen constantes de la misma, así como los
costos de los posibles cambios.
•
Analizar la corrección de la aplicación y su grado de cumplimiento
respecto a los requisitos iniciales.
•
Permitir el estudio de algunas propiedades específicas del dominio.
Una de las mayores utilidades de utilizar una arquitectura es que un mismo
diseño arquitectónico puede servir para dos aplicaciones distintas (ej. los
patrones de diseño). Esto facilita el desarrollo de nuevas aplicaciones y
reduce el tiempo que se invierte en dicho proceso. Pero así como trae
beneficios, toca tener mucho cuidado en el momento de elegir una
arquitectura ya que, una arquitectura errónea puede traer consigo muchos
problemas.
1.3.
LDA
Un LDA es un lenguaje o notación para describir una arquitectura software e
incluye principalmente :
•
La descripción de componentes, conectores y enlaces entre ellos
[MN2004].
•
Las herramientas para la verificación de la arquitectura y el
prototipado rápido [MN2004].
Existen LDAs de propósito general y otros de dominio específico (DSLs).
Los requisitos que debe tener estos lenguajes se pueden clasificar de la
siguiente manera [AC2004]:
•
Composición
o Debe describir el sistema como una composición de partes
•
Configuración
o Debe describir la arquitectura independientemente de los
componentes
•
Abstracción
o Debe describir
componentes
•
los
roles
abstractos
que
juegan
los
Reutilización
o Debe permitir
arquitecturas
reutilizar
componentes,
conectores,
y
•
Heterogeneidad
o Debe permitir combinar descripciones heterogéneas
•
Análisis
o Debe permitir diversas formas de análisis de la arquitectura
1.4.
ESTILOS ARQUITECTÓNICOS
Un estilo de arquitectura es una clasificación de los sistemas de software en
grandes familias cuyos integrantes comparten un patrón estructural común.
Este estilo captura paradigmas de computación y comunicación utilizados
para tratar con los problemas de programación de una clase en particular
[HO2004]. En otras palabras, indican los tipos de componentes y conectores
involucrados en una arquitectura. Los diferentes estilos de las arquitecturas
tiene sus fortalezas y debilidades y, ciertos estilos hacen que sea más fácil
o más difícil trabajar con diferentes obstáculos Las propiedades que
caracterizan cada estilo es lo que determina la elección de uno u otro.
Un estilo de arquitectura debe tener tres elementos básicos:
•
Una notación bien definida para capturar el estilo de desarrollo de la
arquitectura.
•
Un método bien definido para producir y analizar formalmente
modelos basados en la especificación capturada en la notación.
•
Un método bien definido para producir una implementación basada
en la especificación capturada en la notación.
Un estilo provee la semántica para realizar los diagramas de arquitectura.
Es decir, un estilo establece el significado de los diferentes conectores que
se pueden dibujar entre los componentes funcionales.
Los sistemas complejos, en su mayoría, son descritos mediante la
combinación de dos o más estilos básicos de arquitectura.
1.5.
CLASIFICACIÓN DE ESTILOS
Los estilos arquitectónicos se clasifican en diferentes categorías. En la tabla
No. 1 vemos la clasificación general.
Categoría
SISTEMAS
FLUJOS
BASADOS
SISTEMAS CALL/RETURN
Estilos
EN Filtros y Pipes
Procesamiento por lotes
Sistemas Principal/subrutinas
Sistemas OO
Capas jerárquicas
Procesos de comunicación
COMPONENTES
INDEPENDIENTES
Cliente / Servidor
Sistemas de Acontecimientos o Eventos
MÁQUINAS VIRTUALES
Interpretes
Sistemas basados en el conocimiento
SISTEMAS
DATOS
CENTRADOS
EN Bases de Datos (Repositorios)
Sistemas de HiperTexto
Sistemas de pizarra
Tabla 1Clasificación Estilo Arquitectónico
1.5.1.
SISTEMAS BASADOS EN FLUJOS
Se basan en el patrón “pipes and filtres” (tuberías y filtros). Este consta de
un conjunto de componentes denominados filtros conectados entre sí por
tuberías que transmiten datos desde un componente al siguiente. Cada filtro
trabaja de manera independiente de los componentes que se encuentran
situados antes y después de ella. Se diseñan de tal modo que se esperan
un conjunto de datos en un determinado formato y obtiene como resultado
otros datos de salida en un formato específico. Si el formato degenera en
una única línea de transformación, se denomina secuencial batch
(Procesamientos por lotes) [EU2001].
FILTROS Y TUEBERÌAS
Este estilo está compuesto por un grupo de filtros (filters), los cuales tienen
un conjunto de entradas y un conjunto de salidas. Cada componente lee las
entradas y las transforma en salidas. La comunicación entre los filtros se
realiza a través de tuberías (pipes). En la figura No. 1 vemos el esquema de
este estilo arquitectónico.
Figura 1 Filtros y Tuberías
En la tabla No. 2, que se presenta a continuación, se analizan las ventajas,
desventajas y restricciones de este estilo.
Restricciones
Ventajas
Desventajas
Los filtros deben ser
independientes.
No
deben compartir estado
con otros filtros.
Permite entender el sistema
global en términos de la
combinación
de
componentes
No aconsejado para
cuando se necesita
interactividad
Los filtros realizan la
labor
independientemente del
flujo de entrada.
Soporta de buena manera
la reutilización. Los filtros
son independientes de sus
vecinos
Problemas
de
performance ya que
los
datos
se
transmiten en forma
completa entre filtros
Facilidad de Mantenimiento
y mejora
Facilidad de diagnóstico
(rendimiento, deadlocks)
Soportan
la
concurrente
ejecución
Tabla 2 Filtros y Tuberías
1.5.2.
SISTEMAS CALL/RETURN
Los estilos agrupados en esta categoría permite n a los desarrolladores de
software realizar estructuras de programación fáciles de modificar y escalar.
SISTEMAS OO
Este estilo arquitectónico ha tenido gran aceptación y es de mucho uso en
el desarrollo de aplicaciones. Las representaciones de los datos y las
operaciones están encapsuladas en un tipo abstracto de datos u objeto. Por
lo tanto, los componentes son objetos y se relacionan entre ellos a través de
invocaciones de métodos.
En la figura No. 2 vemos un diagrama que representa el estilo de los
Sistemas Orientados a Objetos.
Figura 2 Sistemas OO
El Sistema OO tiene algunas restricciones. Estas se muestran en la tabla
No. 3 junto con las ventajas y desventajas de este estilo.
Restricciones
Ventajas
Los
objetos
responsables
de
integridad
de
representaciones
son Gracias al invariante de
la ocultación es posible
sus reemplazar
la
Implementación sin que
Dicha representación es afecte a los clientes
ocultada al resto de los
objetos
Desventajas
Para invocar métodos
de un objeto se debe
conocer su identidad
Efectos colaterales
Tabla 3 Sistemas OO
CAPAS JERÁRQUICAS
Al hablar de capas jerárquicas hacemos referencia al estilo organizado
jerárquicamente en capas, donde cada capa provee servicios a la capa
superior y es servido por la capa inferior.
Los componentes de este estilo corresponden a cada una de las capas las
cuales se conectan entre ellas utilizando protocolos de interacción
(Llamadas a procedimientos. Llamadas a métodos).
Cada nivel tiene asociado una funcionalidad:
•
Niveles bajos: Funciones simples, ligadas al hardware o al entorno.
•
Niveles altos: Funciones más abstractas.
La figura No. 3 nos ilustra gráficamente el estilo jerárquico. En la figura se
distingue cómo se comunican las diferentes capas y que funcionalidad va en
cada capa.
Figura 3 Capas Jerárquicas
//VOY AQUI
Restricciones
•
La interacción está limitada a las capas adyacentes
Ventajas
•
•
•
Facilita la descomposición del problema en varios niveles de abstracción.
Soporta la mejora, los cambios solo afectan a las capas vecinas
Se pueden cambiar las implementaciones respetando las interfaces con las
capas adyacentes.
Desventajas
•
•
No todos los sistemas pueden estructurarse en capas.
Es difícil encontrar la separación en capas adecuada
Aplicación
•
•
•
Torres de protocolos de comunicación.
Sistemas operativos.
Compiladores.
2.1.3 COMPONENTES INDEPENDIENTES
2.1.3.1 Sistemas de Acontecimientos o Eventos
Descripción
•
•
•
•
En lugar de invocaciones de procedimientos explicitas o directas, un
componente anuncia uno o más eventos y otros componentes registran el
interés en un evento asociando un procedimiento a dicho evento.
La ocurrencia de un evento causa la invocación “implícita” de
procedimientos en otros módulos.
Los componentes son los módulos cuyas interfaces ofrecen un conjunto de
procedimientos y de eventos
Los conectores incluyen llamadas a procedimientos tradicionales así como el
ligado de eventos con llamadas a procedimientos
Restricciones
•
•
Quien anuncia el evento no conoce a que componentes afecta el evento
No se pueden hacer asunciones acerca del orden de procesamiento
Ventajas
•
•
Provee un robusto soporte de reusabilidad
Facilita la evolución del sistema
Desventajas
•
•
•
Perdida de control en el comportamiento del sistema
Problemas en el intercambio de datos
Es difícil asegurar la corrección global del sistema
2.1.4 SISTEMAS CENTRADOS EN DATOS
Como parte central de esta arquitectura aparece un almacén de datos, el cual es
accedido de manera frecuente por otros componentes que actualizan, añaden, borran
o modifican dichos almacenes. El software cliente accede a un repositorio central
[EU2001].
2.1.4.1 Sistemas de pizarra
Descripción
•
•
•
•
•
•
Existen dos tipos de componentes
Una estructura central de datos (representa el estado del proceso)
Componentes independientes (operan en función del depósito de datos)
Las interacciones entre el repositorio y los demás componentes es variable:
La entrada de los datos es seleccionada por los componentes
El estado de los datos del repositorio selecciona el proceso a ejecutar
(pizarra)
Ventajas
•
•
•
Posibilita la integración de agentes.
Adecuado para la resolución de problemas no deterministas.
Se puede resumir el estado de conocimiento en cada momento del proceso
Desventajas
•
•
Estructura de datos común a todos los agentes
Problemas de carga a la hora de chequear y vigilar el estado de la pizarra.
1. ARQUITECTURAS BASADA EN AGENTES
Los agentes pueden ser concepto de estudio de varias áreas, como lo son inteligencia
artificial, sistemas distribuidos, ingeniería de software, redes y sistemas autónomos
entre otras, lo cual hace que su definición este influenciada según sea el área en la
cual tengamos nuestro interés [JAS200], nosotros creemos que una definición
apropiada de agente es:
“Los agentes son simplemente un sistema computacional con la capacidad de tomar
acciones autónomas en un medio, para así cumplir sus objetivos”[GW2001].
Según la anterior definición, encontramos que los agentes como tal están ligados
directamente a su medio, y por lo tanto podrán modificar este medio con la finalidad
de cumplir su objetivo (igual que las personas). También, los agentes, en ocasiones
tendrán la oportunidad de basar sus decisiones según criterios mas estructurados,
como puede ser información histórica o experiencias del agente con el medio, pero
vale aclarar que esto no es obligatorio (según la definición).
Los agentes como tal pueden comunicarse con otros agentes, fo rmando sociedades
de agentes, que le sirven al mismo para cumplir sus tareas; al igual que lo hacen las
personas los agentes pueden delegar tareas a otros agentes o pueden competir por
un recurso, y esto hace que nazca un lenguaje o protocolo con el cual los agentes se
puedan comunicar fácilmente y sin ambigüedades de definiciones en los conceptos
que quieren dar a entender de un agente a otro(a diferencia de las personas).
El protocolo que se a definido para la comunicación entre agentes es el KQML que
sinifica “Knowledge query and manipulation language”.La estructura de este
protocolo es [GW2001]:
(KQML-performative
:sender <palabra>
(nombre agente que envía el mensaje)
:reciver <palabra>
(nombre agente que recibe el mensaje)
:language <palabra> (lenguaje en que se comunican(ejemplo prolog))
:ontology <palabra>
:content <expresión> (puede ser vació si el tipo del mensaje lo define))
ejemplo:
(Cancelar
:sender Hugo
:reciver Alex
:language prolog
:ontology mundo-tesis
:content (esta vació ya que el mismo tipo de mensaje define la acción)).
3.1 FIPA (Foundation for intelligent Physical Agents)
Es una organización que desarrolla estándares para software de agentes para así
permitir que diferentes sistemas de agentes interactúen, mas claramente se puede ver
una definición de lo que es FIPA en su misión:
“la promoción de tecnologías y especificaciones de interoperabilidad que permitan
el trabajo interno de sistemas de agentes inteligentes dentro del comercio y la
industria”[FIPA].
En la siguiente figura podemos ver y aclarar lo que propone FIPA con respecto a la
construcción de plataformas de agentes:
En la figura diferenciamos seis(6) aspectos importantes en los cuales se debe basar
cualquier plataforma de agentes, y estos son[FIPASC00023J]:
•
AMS(Agent Management System): Es un servicio de paginas blancas, que
tiene como funciones principales:
o Es el encargado de mantener un directorio de agentes y encargarse
del ciclo de vida de un agente.
o Controla y supervisa el uso de la plataforma.
•
DF(Directory Facilitator):Es un servicio opcional. Donde los agentes
publican sus servicios para que otros agentes los puedan utilizar. (Un
Servicio de paginas amarillas)
•
MTS(Message Transport System): es la forma que existe para la
comunicación entre dos agentes en diferentes plataformas de
agentes[FIPA00067].
•
Agente: Es un proceso computacional que implementa la autonomía y la
funcionalidades de comunicación dentro de una aplicación. Los agentes se
comunican usando un lenguaje de comunicación entre agentes llamado ACL
(Agent Comunication Language). Un agente es el actor fundamental de una
plataforma de agentes quien combina una o mas servicios que son publicados
en el DF.
•
Plataforma de Agentes(AP): Es la infrastuctura física en donde se
desarrollan los agentes. El AP esta compuesto por las maquinas, sistemas
operativos, el software que soporta los agentes,los componentes de manejo
de un agente definidos por FIPA (DF, AMS , MTS), y los agentes.
•
Software: Describe todo lo que no es una agente pero que este utiliza para
ejecutar instrucciones o alguna funcionalidad en especifico.
Existen en la actualidad muchas plataformas de agentes basadas en las
especificaciones de FIPA, pero en este artículo nos vamos a detener a analizar la
plataforma JADE y BESA.
3.2 JADE(Java Agent DEvelopment Framework):
JADE es un framework de agentes que está basada en FIPA, y como tal debe tener
unos aspectos que debe cumplir toda plataforma de agentes que sea FIPA complaint,
y estos son el AMS, DF, agentes y la definición de un protocolo que permita
intercambiar mensajes entre agentes, estos mensajes son comúnmente llamados los
ACL(agent comunication language) que viene siendo una abstracción del tipo de
mensajes que se definieron atrás como KQML.
Como tal una plataforma jade tiene un contenedor principal llamado main en donde
residen el AMS y el DF, este contenedor main es el primero que debe arrancar en
una plataforma jade y posteriormente pueden empezar otros contenedores con sus
respectivos agentes , pero siempre teniendo en cuenta que se deben registrar los
agentes al contenedor principal (el main).Esto nos da como resultado un sistema de
comunicación P2P híbrido[BEL2003] tal y como se muestra en la siguiente figura:
Sistema P2P híbrido
Deteniéndose un poco en este punto se podría pensar que la plataforma jade tiene un
punto de falla en el contenedor principal (el main) ya que si este se cae entonces la
plataforma toda se vendría al piso, sin embargo los creadores de Jade previeron esto
y hicieron que este main, aunque es un (1) agente, puede estar en varias maquinas al
mismo tiempo, tal y como lo muestra la siguiente figura[BEL12003]:
En la plataforma del lado izquierdo solo existe un main pero jade da la opción que
puedan existir mas de un main tal y como vemos en la figura del lado derecho, así si
por ejemplo el main-container-1 no prestara mas este servicio por cualquier motivo
entonces, la plataforma quedaría de la siguiente manera [BEL12003]:
3.2.1 Ventajas de JADE [RIM2003]:
•
•
Es una plataforma probada y sobre la cual se han desarrollado aplicaciones.
Se tiene una extensión de jade para dispositivos móviles llamada LEAP,
donde aparentemente la extensión de agentes desarrollados para JADE
normal es igual para un agente desarrollado en LEAP.
•
•
Se tiene un contenedor principal que es donde reside el AMS, con la
flexibilidad de tenerlos en forma de cluster para así dar una plataforma que
es tolerable a fallos.
La comunicación entre agentes dentro de una misma plataforma puede ser
vía RMI o por medio de llamados locales, esta complejidad es resuelta por el
contenedor que es el que sabe donde se podría encontrar el agente, esto se
hace a través de técnicas de cache en donde cada contenedor mantiene una
tabla (cache)llamada LADP (Local Agent Descriptor Table), mientras el
contenedor principal tiene una tabla global de toda la plataforma, llamada
GADP (Global Agent Descriptor Table).
3.2.2Desventajas de Jade:
•
•
No tiene desarrollado el mecanismo de guardas, que es el que nos permite
darle una mejor selección a los mensajes que llegan a un agente, por lo tanto
esto es
tarea del programador a la hora de implementar cada
comportamiento.
Como un agente para jade es un solo hilo que tiene su propio control, puede
darse el caso que debido a un comportamiento mal programado el agente
pierda reactividad ante el entorno.
3.3 BESA(Behavior-oriented, Event-driven and Social-based Agent Framework):
La arquitectura besa esta compuesta por tres niveles: nivel de agente, nivel social y
nivel del sistema. En el nivel de agente se trata todo lo referente a sus
comportamientos y a los eventos a los cuales reacciona el agente. En el nivel social
se trata lo referente a la comunicación que existe entre agentes(a través de un
modelo de programación de eventos), “una interacción se puede modelar por un
evento bien definido, que se puede asociar a una guarda”. En el nivel de sistema es
donde se define el ciclo de vida de los agentes y la administración de éstos
[GON2003].
3.3.1 Ventajas:
•
•
•
•
Es un sistema que maneja muy bien el mecanismo de guardas, lo que permite
al programador definir un nivel muy fino de granularidad a la hora de
plantear los comportamientos de un agente.
Los comportamientos corren sobre su propio hilo lo que hace que estos no
bloqueen el funcionamiento total del agente, al contrario de cómo sucede en
JADE.
Besa deja que el programador solo piense en los comportamientos de su
agente llevándolo a un nivel de abstracción mas alto.
Se puede ver como una plataforma P2P ya que la comunicación entre los
agentes es punto a punto y lo mismo pasa con los contenedores de los
agentes.
3.3.2 Desventajas:
•
Usa el mecanismo de multicast para la comunicación entre contenedores, lo
cual lo limita a un dominio.
•
•
•
Se puede afectar el rendimiento de la red en casos en que los agentes tengan
un tiempo de vida muy corto. Esto debido al multicast que es utilizado para
mantener las tablas actualizadas del directorio de páginas blancas que tiene
cada contenedor.
La poca documentación que lo soporta.
No se ha probado con muchos ejemplos como si ha sucedido con otras
plataformas de agentes.
2. PEER 2 PEER
La ventaja más importante de las redes P2P radica en que cualquier peer puede
proveer servicios (potencialmente), actuando en determinadas ocasiones como un
servidor y en otras como un cliente. Esto permite que un servicio no dependa
directamente de un solo punto sino por el contrario este servicio puede ser
suministrado por cualquier punto dando así soluciones mas escalables donde el
servicio no depende de una sola maquina.
La computación distribuida es una manera de resolver problemas por medio de
separar el problema en subproblemas que pueden ser solucionados de manera
independiente por diferentes equipos. Se espera que en el futuro la computación
distribuida aproveche las ventajas de redes P2P.
Los puntos son configurados para descubrirse de una manera espontánea en la red.
Casi siempre solo necesitan interactuar con un número pequeño de peers (vecinos o
“amigos”). Los peers pueden unirse o dejar la red en cualquier momento, pero deben
siempre anunciar que la comunicación puede perderse a cualquier peer con el que se
este comunicando.
Los peers se organizan en grupos. Un grupo es una colección de peers que tienen
algún interés en común. Cada grupo es identificado por un único ID. JXTA no
define cuando, como o porque se crean los grupos. Solo describe como los peers
pueden publicar, descubrir, unirse y monitorear los grupos de peers.
JXTA define un grupo de seis protocolos basados en XML que estandarizan la
manera como los peers son organizados dentro de los grupos de peers, publicando y
descubriendo recursos, comunicándose y monitoreándose mutuamente. JXTA
establece una red virtual sobre la red física, permitiendo que los puntos interactúen
directamente y se organicen independientemente de su localización y conectividad.
Los protocolos han sido diseñados para ser fácilmente implementados.
Un punto JXTA puede ser cualquier dispositivo conectado (sensores, teléfonos,
PDA, PC, servidores, etc) que implementa los protocolos básicos de JXTA. Cada
punto es identificado por un único ID, son autónomos y operan independientemente
y asincrónicamente de otros puntos. Puede existir alguna dependencia de puntos
debido a requerimientos especiales, tales como la necesidad de un gateway, proxies
o routers.
Cada punto puede publicar servicios y recursos (CPU, almacenamiento, bases de
datos, documentos, etc) para que sean usados por otros puntos.
4.1 Conceptos básicos de P2P
4.1.1 Peer:
Cualquier entidad capaz de hacer un trabajo útil y poder comunicar los resultados
del trabajo a otra entidad en la red bien sea directa o indirectamente.
•
•
•
Simple peer
Rendeveus peer guarda en memoria información acerca de otros peers
Router peer: se encarga de dar una ruta a un peer que no tiene conexión
directa con otro peer.
4.1.2 Pe er group
Conjunto de peers que tienen un mismo interés. Los Peer Groups pueden proveer
servicios a los otros peers que pertenezcan al grupo.
Este grupo como tal puede ofrecer una serie de servicios que se pueden descubrir a
través del advertisement que identifican este grupo en especifico, vale aclarar que
uno de los servicios que se debe implementar es el de unirse al grupo(membresía)
para que así otros peers puedan vincularse al grupo, si este servicio no es
implementado entonces cualquiera puede entrar al grupo fácilmente.
4.1.3 Servicios de red:
•
Servicio de peer: si el punto muere el servicio también se muere, muchos
puntos pueden tener el mismo servicio pero con identificaciones diferentes.
•
Servicio de grupo : esta compuesto por instancias del servicio corriendo en
múltiples miembros del grupo. Y este se publica como parte del peer group
advertisement.
4.1.4 Advertisement:
Es la representación de una entidad (Peer), servicio o recurso que este prestando un
peer o un peer group como parte de una red p2p.
Es necesario que en una red p2p sean definidos protocolos que permitan:
• Encontrar un peer en la red.
• Encontrar un servicio que un peer este prestando.
• Obtener información de otros peers.
• Utilizar los servicios que preste un peer.
• Crear, unirse y dejar un grupo.
• Crear datos de coneccion para otros peers
• Enrutar un mensaje para otros peers.
4.2 JXTA
JXTA
Applications
Samp le App licat io ns
Insta nt Messa ging
File S har ing
Collabora t ive
JXTA
Services
Conte nt Viewe rs
Samp le Ser vices
Searc h
JXTA
Core
Reso urc e Shar ing
Inde xing
Disco ve r
Me mbers hip
Peer Gro up s
Peer P ipes
Peer Mo nitor ing
Peer
Peer IDs
Secur it y
Any Connected Device
4.2.1 Protocolos de Jxta:
4.2.1.1 Peer Resolver Protocol(PRP)
Permite enviar y recibir consultas (queries) genéricos a través de un manejador
(handler) que es el responsable de identificar el servicio no importando en que peer
se encuentre, solo viendo si el peer proporciona el servicio.
Este protocolo es definido por dos tipos de mensajes (XML):
•
•
Resolver query esta compuesto por los siguientes tags: credencial, nombre
del manejador, id de la consulta, numero de hops por los que la consulta a
viajado y el query.
Resolver response esta compuesto por los siguientes tags: credencial,
nombre del manejador, id de la consulta y la respuesta.
4.2.1.2 Peer information Protocol(PIP)
Sirve para obtener información acerca de un peer en especifico. Se pueden ver dos
tipos de mensajes en este protocolo:
•
•
Ping request que se compone por una credencial, id de origen , id destino.
PeerInfo response compuesto por una credencial, id de origen , id destino
,tiempo , timestamp y un advertisement que representa al peer.
4.2.1.3 Endpoint routing prtocol(PEP):
Define un conjunto de mensajes request/response procesados por el servicio de
enrutamiento con la finalidad de ayudar a un peer a que su mensaje llegue a su
destino.
Cuando un peer que tiene el perfil de enrutador recibe una consulta acerca de una
ruta, si conoce la ruta la envía. En caso contrario busca por la ruta para así poderla
devolver.
Un endpoint se identifica por una dirección que tiene la siguiente forma
<protocolo>://<dirección de red>/<nombre del servicio>/<parámetros que recibe el
servicio>
•
•
•
•
<protocolo>—el nombre de la red que se utiliza para enviar el mensaje.
Ejemplos: tcp, http, y jxtatls.
<protocolAddress>— la dirección de red con el Puerto por ejemplo
127.0.0.1:80
<serviceName>—un unico identificador que permite encontrar el servicio
remoto
<serviceParameters>—algunos parámetros únicos que identifican el servicio
y su manejador
Usando el protocolo jxta , un peer puede enviar mensajes por medio del Endpoint
Routing Protocol tal y como si estuviera directamente conectado al peer remoto, sin
embargo el mensaje puede viajar a través de diferentes peers.
Si dos peers no se pueden conectar directamente, este protocolo les permite
encontrar la forma para que estos peers puedan intercambiar mensajes. a través de
rutas de información que se descubren.
4.2.1.4 Peer discovery Protocol(PDP):
Permite encontrar recursos que están representados en forma de advertisement
(peers, peer groups , pipe etc). La forma en que este protocolo busca estos
advertisements es buscando en su cache. Si no lo encuentra, este le delega la tarea a
un rendezveus que tiene pre configurado o buscando uno en la red y este finalmente
le devuelve el advertisement que el estaba solicitando, no sin antes guardarlo en
memoria para que se pueda utilizar en un futuro. Un peer que no tenga perfil de
rendevouz no tiene la obligación de guardar en memoria advertisements pero esto
puede mejorar notablemente el desempeño en las búsquedas de advertisements.
Este protocolo es definido por dos tipos de mensajes:
•
•
Discovery query.
Discovery response
4.2.1.5 Rendezvous Protocol(PRP)
Permite propagar mensajes y controla esta propagación. Este protocolo esta
definido por tres tipos de mensajes:
•
•
•
Lease Request Message — Usado por un peer para obtener permiso de
conectarse al rendezvous
Lease Granted Message — Usado por el rendezvous para aprobar los peers
Lease Cancel Message — Usado por un peer para desconectarse del
rendezvous.
4.2.1.6 Pipe Binding Protocolo(PBP)
Usado por las aplicaciones y servicios para comunicarse con otros peers. Pipe es un
canal virtual entre dos endpoints este protocolo se basa en la funcionalidad del
protocolo endpoint.
Los Pipes son canales de comunicación virtuales usados para enviar y recibir
mensajes entre servicios o aplicaciones. Proveen la ilusión de un mailbox virtual de
entrada y salida que es independiente de la localización de un peer y también es
independiente de la topología de la red.
Pueden ser implementados diferentes QoS por un pipe. Por ejemplo:
•
•
•
•
•
Asincrónico unidireccional: El punto final envía un mensaje. No hay garantía
de que la entrega sea hecha.
Sincrónico request-response: El punto final envía un mensaje y recibe una
respuesta confirmándolo.
Transferencia en lotes: Transferencia confiable de datos binarios.
Streaming: Transferencia eficiente
Seguro: Transferencia segura de datos.
Existen varios tipos de conexiones usadas por un pipe y estas son:
•
JxtaUnicast que solo tiene uno que envía y uno que recibe.
•
•
JxtaUnicastSecur es lo mismo que JxtaUnicast pero la conexión es segura
usando el Transport Layer Security (TLS) protocol.
JxtaPropagate proporciona la funcionalidad de broadcast entre muchos
endpoints que envían y muchos endpoints que reciben.
El PBP define dos tipos de mensaje para encontrar un pipe
•
•
The Pipe Binding Query Message—sirve a un peer para preguntarle a otro si
este tiene el pipe que el esta buscando(con el pipe id).
The Pipe Binding Answer Message—para enviar una respuesta a la consulta.
4.3 POINT TO MULTIPOINT
La arquitectura P2MP consiste en una estación central que sirve a varios sectores
dentro de un rango. Cada sector consiste en un radio de comunicación con un
número amplio de usuarios. El ancho de banda es compartido entre los usuarios del
sector.
Esta arquitectura tiene una topología de árbol por lo que tiene una raíz (Point) que
se va abriendo en muchas hojas (Multipoint). Las hojas no pueden comunicarse
directamente P2P, siempre tienen que ir primero a la raíz.
[PJ2004]
La arquitectura P2MP es por lo general utilizada en la última milla. En este tipo de
arquitectura pueden participar más nodos pero el performance sufre ya que están
compartiendo el ancho de banda.
4.4 POINT TO CONSECUTIVE POINT (P2CP)
Una serie de puntos están unidos consecutivamente uno con otro formando una
topología de anillo. Los datos van pasando de un punto al otro de manera secuencial
pero en el momento en que se llegue a caer un anillo, el tráfico se enruta
automáticamente en sentido contrario.
Este sistema es más costoso pero tiene un ancho de banda mayor que los
tradicionales P2P que en cierta manera son limitados en el número de puntos que
puedan tener.
5. J2ME
Esta versión de Java está enfocada a la aplicación de la tecnología Java en
dispositivos electrónicos con capacidades computacionales y gráficas muy
reducidas, tales como teléfonos móviles, PDAs o electrodomésticos inteligentes.
Esta edició n tiene unos componentes básicos que la diferencian de las otras
versiones, como el uso de una máquina virtual denominada KVM (Kilo Virtual
Machine, debido a que requiere sólo unos pocos Kilobytes de memoria para
funcionar) en vez del uso de la JVM clásica, inclusión de un pequeño y rápido
recolector de basura y otras diferencias.
J2ME contiene una mínima parte de las APIs de Java. Esto es debido a que la
edición estándar de APIs de Java ocupa 20 Mb, y los dispositivos pequeños
disponen de una cantidad de memoria mucho más reducida. En concreto, J2ME usa
37 clases de la plataforma J2SE provenientes de los paquetes java.lang, java.io,
java.util. Esta parte de la API que se mantiene fija forma parte de lo que se
denomina “configuración”. J2EE es un superconj unto de J2SE pues contiene toda la
funcionalidad de éste y más características, así como J2ME es un subconjunto de
J2SE (excepto por el paquete javax.microedition) ya que, como se ha mencionado,
contiene varias limitaciones con respecto a J2SE.
5.1 ENTORNO DE EJECUCIÓN
Un entorno de ejecución determinado de J2ME se compone entonces de una
selección de:
a) Máquina virtual (KVM).
b) Configuración (una configuración es el conjunto mínimo de APIs Java que
permiten desarrollar aplicaciones para un grupo de dispositivos CLDC O CDC).
c) Perfil (bibliotecas Java de clases específicas orientadas a implementar
funcionalidades de más alto nivel para familias específicas de dispositivos).
d) Paquetes Opcionales.
Cada una de las configuraciones mencionadas anteriormente tiene características
propias. Como consecuencia, cada una requiere su propia máquina virtual. La VM
(Virtual Machine) de la configuración CLDC se denomina KVM y la de la
configuración CDC se denomina CVM.
5.1.1 KVM
Su nombre KVM proviene de Kilobyte (haciendo referencia a la baja ocupación de
memoria, entre 40Kb y 80Kb). Se trata de una implementación de Máquina Virtual
reducida y especialmente orientada a dispositivos con bajas capacidades
computacionales y de memoria. La KVM está escrita en lenguaje C. Fue diseñada
para ser:
•
•
•
•
Pequeña, con una carga de memoria entre los 40Kb y los 80 Kb,
dependiendo de la plataforma y las opciones de compilación.
lta portabilidad.
Modulable.
Lo más completa y rápida posible y sin sacrificar características para las que
fue diseñada.
Sin embargo, esta baja ocupación de memoria hace que posea algunas limitaciones
con respecto a la clásica Java Virtual Machine (JVM):
1. No hay soporte para tipos en coma flotante. No existen por tanto los tipos
double ni float. Esta limitación está presente porque los dispositivos carecen del
hardware necesario para estas operaciones.
2. No existe soporte para JNI (Java Native Interface) debido a los recursos
limitados de memoria.
3. No existen cargadores de clases (class loaders) definidos por el usuario. Sólo
existen los predefinidos.
4. No se permiten los grupos de hilos o hilos daemon. Cuándo queramos utilizar
grupos de hilos utilizaremos los objetos Colección para almacenar cada hilo en
el ámbito de la aplicación.
5. No existe la finalización de instancias de clases. No existe el método
Object.finalize().
6. No hay referencias débiles.
7. Limitada capacidad para el manejo de excepciones debido a que el manejo de
éstas depende en gran parte de las APIs de cada dispositivo por lo que son éstos
los que controlan la mayoría de las excepciones.
8. Reflexión
5.1.2 CVM
La CVM (Compact Virtual Machine) ha sido tomada como Máquina Virtual Java de
referencia para la configuración CDC y soporta las mismas características que la
Máquina Virtual de J2SE. Está orientada a dispositivos electrónicos con
procesadores de 32 bits de gama alta y en torno a 2Mb o más de memoria RAM. Las
características que presenta esta Máquina Virtual son:
1. Sistema de memoria avanzado.
2. Tiempo de espera bajo para el recolector de basura.
3. Separación completa de la VM del sistema de memoria.
4. Recolector de basura modularizado.
5. Portabilidad.
6. Rápida sincronización.
7. Ejecución de las clases Java fuera de la memoria de sólo lectura (ROM).
8. Soporte nativo de hilos.
9. Baja ocupación en memoria de las clases.
10. Proporciona soporte e interfaces para servicios en Sistemas Operativos de
Tiempo Real.
11. Conversión de hilos Java a hilos nativos.
12. Soporte para todas las características de Java2 v1.3 y librerías de seguridad,
referencias débiles, Interfaz Nativa de Java (JNI), invocación remota de métodos
(RMI), Interfaz de depuración de la Máquina Virtual (JVMDI).
5.2 CONFIGURACIONES
5.2.1 CDC
La CDC está orientada a dispositivos con cierta capacidad computacional y de
memoria. Por ejemplo, decodificadores de televisión digital, televisores con internet,
algunos electrodomésticos y sistemas de navegación en automóviles.
La CDC está enfocada a dispositivos con las siguientes capacidades:
•
•
•
•
•
Procesador de 32 bits.
Disponer de 2 Mb o más de memoria total, incluyendo memoria RAM y
ROM.
Poseer la funcionalidad completa de la Máquina Virtual Java2.
Conectividad a algún tipo de red.
5.2.2 CLDC
La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en
cuanto a capacidad gráfica, cómputo y memoria. Un ejemplo de estos dispositivos
son: teléfonos móviles, buscapersonas (pagers), PDAs, organizadores personales,
etc.
Los dispositivos que usan CLDC deben cumplir los siguientes requisitos:
•
•
•
•
Disponer entre 160 Kb y 512 Kb de memoria total disponible. Como mínimo
se debe disponer de 128 Kb de memoria no volátil para la Máquina Virtual
Java y las bibliotecas CLDC, y 32 Kb de memoria volátil para la Máquina
Virtual en tiempo de ejecución.
Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad.
Ofrecer bajo consumo, debido a que éstos dispositivos trabajan con
suministro de energía limitado, normalmente baterías.
Tener conexión a algún tipo de red, normalmente sin cable, con conexión
intermitente y ancho de banda limitado (unos 9600 bps).
5.2.3 CDC vs CLDC
A continuación se presentan las diferencias entre las librerías que soportan cada una
de las configuraciones mencionadas anteriormente.
La Tabla 1.1 nos muestra las librerías incluidas en la CDC.
La Tabla 1.2 nos muestra las librerías incluidas en la CLDC.
Como podemos ver, el número de librerías incluidas en la configuración CDC es
mucho mayor que las de la CLDC.
5.3 PERFILES
Un perfil es un conjunto de APIs que dotan a una configuración de funcionalidad
específica.
Existen unos perfiles que se construyen sobre la configuración CDC y otros sobre la
CLDC. Para la configuración CDC tenemos los siguientes perfiles:
•
•
•
Foundation Profile.
Personal Profile.
RMI Profile.
y para la configuración CLDC tenemos los siguientes:
•
•
PDA Profile.
Mobile Information Device Profile (MIDP). Las aplicaciones que se realizan
utilizando MIDP reciben el nombre de MIDlets.
También existe una gran cantidad de paquetes opcionales que amplían los perfiles;
éstos incluyen Wireless Messaging API*, Mobile Media API*, J2ME RMI Optional
Package* y el paquete opcional JDBC para CDC Foundation Profile*, al igual que
otros que aún están en el proceso de especificación, tal como J2ME Web Services.1.
5.4 COMPONENTES APLICACIONES J2ME
Una aplicación J2ME está formada por un archivo JAR que es el que contiene a la
aplicación en sí y un archivo JAD (Java Archive Descriptor) que contiene diversa
información sobre la aplicación.
El gestor de aplicaciones o AMS (Application Management System) es el software
encargado de gestionar los MIDlets. El AMS realiza dos grandes funciones:
•
•
Por un lado gestiona el ciclo de vida de los MIDlets.
Por otro, es el encargado de controlar los estados por los que pasa el MIDlet
mientras está en la memoria del dispositivo, es decir, en ejecución.
Cuándo un MIDlet comienza su ejecución, está en el estado “Activo” pero, ¿qué
ocurre si durante su ejecución recibimos una llamada o un mensaje? El gestor de
aplicaciones debe ser capaz de cambiar el estado de la aplicación en función de los
eventos externos al ámbito de ejecución de la aplicación que se vayan produciendo.
En este caso, el gestor de aplicaciones interrumpiría la ejecución del MIDlet sin que
se viese afectada la ejecución de éste y lo pasaría al estado de “Pausa” para atender
la llamada o leer el mensaje. Una vez que terminemos de trabajar con el MIDlet y
salgamos de él, éste pasaría al estado de “Destruido” dónde sería eliminado de la
memoria del dispositivo. Cuándo decimos que el MIDlet pasa al estado “Destruido”
y es eliminado de memoria, nos referimos a la memoria volátil del dispositivo que es
usada para la ejecución de aplicaciones. Una vez finalizada la ejecución del MIDlet
podemos volver a invocarlo las veces que queramos ya que éste permanece en la
zona de memoria persistente hasta el momento que deseemos desinstalarlo.
MIDlet puede cambiar de estado mediante una llamada a los métodos
MIDlet.startApp(), MIDlet.pauseApp() o MIDlet.destroyApp(). El gestor de
aplicaciones cambia el estado de los MIDlets haciendo una llamada a cualquiera de
los métodos anteriores. Un MIDlet también puede cambiar de estado por sí mismo.
6. SATIN
Los creadores de esta arquitectura tratan de resolver el problema que se presenta
actualmente con respecto a las aplicaciones que modelan sistemas móviles,
partiendo del beneficio de usar sistemas que se organicen por si solos (SelfOrganized System) teniendo en cuenta la lógica móvil como base de esta
arquitectura.
1
Pini
Mike.
Diseño
de
aplicaciones
http://www.intel.com/espanol/update/contents/mo11031.htm
inalámbricas
móviles
en
6.1. Problemática:
El problema que se divisa en aplicaciones para sistemas móviles, según la
problemática que muestra SATIN, es la poca adaptabilidad de las aplicaciones con
respecto al constante cambio de los requerimientos. Teniendo en cuenta las
dificultades que se presentan en sis tema que se auto organizan, y estas son:
•
•
•
•
•
El medio cambiante y las necesidades del usuario, teniendo como
limitaciones la heterogeneidad en cuanto a hardware, software, protocolos de
comunicación y redes en que se encuentran en los dispositivos.
El desarrollo estático que muestra el comportamiento de las aplicaciones,
refiriéndose a la poca adaptabilidad que tienen en cuanto al usuario.
Las limitaciones que se tienen cuando se especifica que una aplicación sea
auto organizable.
La forma en que se monitorea el medio cambiante en que se encuentra el
dispositivo es difícil de manejar, debido a su flexibilidad (redes ad- hoc).
Es difícil garantizar la seguridad.
“Un sistema que se auto-organiza es aquel que automáticamente se reconfigura con
la finalidad de acomodarse a nuevos requerimientos”[ZAC2003].
6.3. Lógica Móvil:
Teniendo en cuanta la perspectiva que muestra SATIN la arquitectura se basa
en unas primitivas de lógica móvil (LM) que ayudan a:
•
La interoperabilidad con aplicaciones remotas y medios que no fueron
tenidos en cuenta al momento de diseño de una aplicación.
• La lógica móvil permite tener actualizados los diferentes componentes y
añadir nuevas funcionalidades a una aplicación.
• La lógica móvil permite usar adecuadamente los recursos de un punto,
dando la posibilidad de delegar cálculos complejos al medio en que se
encuentra el dispositivo.
• La lógica móvil permite usar eficientemente los recursos locales; por
ejemplo si una funcionalidad dentro del PC no esta siendo utilizada
puede removerse.
“La lógica móvil se refiere a la habilidad de mover partes de una aplicación o
migrar un proceso completo de un medio de procesamiento a otro”
[ZAC2003].
6.4. Arquitectura:
Satin define su arquitectura básica en forma de capacidades en donde la unidad
básica es la “capacidad”(Capability) en donde una “capacidad” incluye metadata, versión, identificador único y una lista de dependencias a otras
capacidades. En donde una funcionalidad se representa por el conjunto de
“Capacidades” que pueden ser actualizadas dinámicamente en medios
dinámicos (redes ad-hoc).
El modelo de arquitectura que plantea SATIN es el siguiente:
• Advertiser Capability: implementa capacidades de “advertising”.
• Discovery Capability: implementa técnicas de descubrimiento de
Capacidades.
• Core Capability: es el registro de todas las capacidades, todo
dispositivo que tenga SATIN debe tener un core.
• Registrar Capability: es el responsable de registrar “capacidades”.
La anterior figura muestra la arquitectura Satin en un host, que es un conjunto
de “capacidades” registradas en un core.
Esta arquitectura nos muestra una posibilidad que permite utilizar la lógica
móvil para el beneficio de auto-organizar el desarrollo de aplicaciones para
sistemas móviles. Las ventajas que esboza esta arquitectura es apenas natural
para dispositivos móviles según las ventajas que plantea la lógica móvil como
tal. Por otra parte la forma en que se modulariza la funcionalidad de una
aplicación es interesante y cabe anotar que puede ser de gran beneficio para el
futuro planteamiento de nuestra arquitectura ya que puede ser una idea a
seguir.
Pensamos que la idea de lógica móvil y de modularización de la arquitectura
según sus capacidades es totalmente moldeable al paradigma de agentes, en
donde la lógica móvil se puede ver en la movilidad del agente, y la capacidad
se puede ver en agentes especializados que están inmersos dentro de la
arquitectura que se pudiere plantear.
7.
DISEÑO E IMPLEMENTACIÓN DE UN
MECANISMOS DE SERIALIZACIÓN EN J2ME
SERVIDOR
HTTP
Y
El objetivo es proveer el funcionamiento de un servidor http dentro de un
dispositivo móvil, con la finalidad de dar funcionalidades dentro de J2ME que no
son soportadas, pero que son necesarias para el buen funcionamiento de una
plataforma de agentes; las funcionalidades no soportadas por la arquitectura J2ME
son:
•
Carga dinámica de clases.
•
Serialización de objetos.
7.1 Puntos Centrales:
Viendo estas limitaciones la tesis (que ya fue desarrollada) la dividen en dos grandes
puntos de investigación, el primero es la comunicación a través de sockets dentro
del perfil MIDP 1.0 (que es un perfil dentro de la arquitectura J2ME) y el segundo
es dar un mecanismo de serialización de objetos para la arquitectura J2ME, esto para
lograr implementar un servidor http dentro de un dispositivo móvil teniendo en
cuanta que este enfoque puede ser utilizado dentro de una plataforma de agentes en
dispositivos móviles.
7.2 Arquitectura:
La arquitectura que se plantea en este proyecto es la siguiente:
Arquitectura Propuesta
Según la figura podemos ver que este proyecto lo que consiguió fue ampliar las
funcionalidades de la arquitectura J2ME, con el objetivo primordial de poder
concebir una plataforma de agentes dentro de los dispositivos móviles, ya que los
agentes móviles se ven como algo natural dentro de un ambiente móvil (según la
perspectiva de la tesis).
La idea referente a los agentes y el servidor http en dispositivos móviles esta
plasmada en el siguiente párrafo:
“Lo que se pretende conseguir es que estos dispositivos no solo puedan utilizar estos
servicios, si no que puedan ser también ellos mismos los que los proporcionan,
dando acceso tanto a dispositivos móviles como a los que no lo son sin la necesidad
de un servidor intermedio”[ SAN2002].
Vemos que una opción para plantear una arquitectura es poder ampliar otra
arquitectura ya existente y que a sido validada, en este caso la ampliación de la
arquitectura J2ME; también tendremos en cuenta la funcionalidad que se desarrollo
en esta tesis en miras a facilitar el desarrollo de nuestra arquitectura o para el
desarrollo de la aplicación que valide nuestra arquitectura.
8. Wireless Resource Manager (WRM)
Esta arquitectura está abierta a estándares existentes y es accesible para futuras
aplicaciones QoS y redes inalámbricas.
El WRM es el primer elemento funcional de la arquitectura. Considera el tráfico y
los requerimientos de QoS de la aplicación y el estado del canal por el cual se ha
accedido. Tiene una arquitectura de jerarquía modular. Las WDMI (Wireless
Dependent Management Interfaces) interactúan con el WRM para tecnologías
inalámbricas específicas [MR2003]
Debido a las limitaciones de los dispositivos móviles, tanto el WRM como las
WDMI, tienen una complejidad mínima procesando. Al clasificar cada petición la
cantidad de negociaciones entre el dispositivo móvil y las redes de acceso es
minimizada por el procesamiento [MR2003]
La ubicación dinámica de la red de acceso es permitida por WDMI que a su vez
informa al WRM permitiendo negociar con las QoS de las aplicaciones para que de
esta forma lo enrute para la red más apropiada de acuerdo a las preferencias del
usuario, costos y servicios que pida [MR2003]
.
9. WIRELESS APPLICATION PROTOCOL (WAP)
WAP es una solución unificada para los servicios de valor añadido existentes y
futuros. El protocolo incluye especificaciones para las capas de la torre OSI de
sesión y de transporte, así como funcionalidades de seguridad. WAP también define
un entorno de aplicaciones. WAP es escalable, permitiendo así a las aplicaciones
disponer de las capacidades de pantalla y recursos de red según su necesidad y en un
gran número de tipos de terminales.
En el caso del WAP, el cliente utiliza un micro navegador que envía su petición al
WAP Gateway. Éste la decodifica y la envía al servidor Web, en el cual está
presente el contenido requerido. Este último servidor envía las páginas pedidas al
WAP Gateway. Éste las codifica y las envía al cliente del WAP.
Como ocurre con la Web, también el WAP define un modelo de síntesis para los
nombres compatibles con la www, los tipos de contenido y los formatos y
protocolos que se utilizan. El WAP Gateway tiene como única finalidad el convertir
los paquetes de datos del protocolo WAP ( WSP, WTP, WTSL, WDP), en paquetes
del protocolo WWW (HTTP Y TCP/IP) y viceversa. Los datos enviados al cliente
se comprimen y codifican en código binario con el fin de reducir su dimensión. La
arquitectura del WAP (Stack WAP) permite tener un ambie nte seguro y extensible
gracias a un diseño realizado en layer en el que cada uno es accesible por el layer
superior o por otros servicios y aplicaciones.
[WA2004]
Los protocolos de WAP se expresan en la siguiente tabla:
[WA2004]
10. WIRELESS ARCHITECTURE FOR ACCESS TO REMOTE SERVICES
(WIARS)
Los principales componentes de la arquitectura WiARS son el WAP Enabled User
Agent (WAEU), el WAP gateway, el Lookup Service de Jini y otros servicios
[TA2000].
Esta arquitectura funciona de la siguiente manera:
•
•
•
•
•
•
•
El WAEU solicita un servicio (Request).
El Request lo maneja el gateway al cual el WAEU está suscrito.
El gateway actúa como un cliente Jini en nombre del WAEU y busca un
Lookup Service de Jini.
El Lookup Service regresa una lista de servicios actualmente disponibles del
que solicitó el WAEU.
El WAP gateway le comunica esa lista al WAEU.
EL WAEU le responde al gateway con el servicio seleccionado.
El gateway, con la ayuda del Lookup Service de Jini, establece una conexión
con el servicio.
Esta arquitectura tiene un envío de datos de manera bidireccional y cualquier entidad
puede iniciar el envío de mensajes.
REFERENCIAS
[AC2004]
Acuña César Javier. Arquitecturas de Software. Universidad Rey Juan
Carlos.
[GON2003]
Enrique Gonzalez, Jamir Antonio Avila y Cesar Bustacara, “Besa
Arquitectura para la construcción de sistemas Multi- Agentes”, 2003.
[EU2001]
EPSA UCLAM. Ingeniería del Software. Arquitectura de Software. 2001
[FIPASC00023J]
[FIPA00067]
[BEL2003]
www.fipa.org número del documento SC00023J, “Fipa Agent
management Specification”, 2002/12/03.
www.fipa.org FIPA Agent Message Transport Service Specification.
http://www.fipa.org/specs/fipa00067/
F. Bellifemine, G. Caire, A. Poggi, G. Rimassa“Jade a white paper”,
Septiembre del 2003.
[BEL12003] F. Bellifemine, G. Caire, Tizana Trucco, “Jade administrator guide” jade
3.1 , 15 de Diciembre del 2003.
[SAN2002]
Guillermo Diez-Andino Sancho (gdandino@it.uc3m.es), “Diseño e
implementación de un servidor http y mecanismos de serializaciòn en
J2ME”, proyecto fin de carrera, universidad Carlos III de Madrid. 23 de
Septiembre del 2002.
[RIM2003]
Giovanni Rimaza , “Runtime Suport for Distributed- multi- Agent
systems” , Enero del 2003.
[GW2001]
Gerhard Weiss, “Multagent System”, 2001.
[HO2004]
Honeywell. What is a Domain-Specific Software Architecture? en
http://www.htc.honeywell.com/projects/dssa/dssa_whatis.html
[JAS2000]
Juan Ángel Sampedro Martínez, José David Ciórraga López, Francisco
Jesús Martínez Mimbrera, “AgentOS”.
[KJ2003]
Knudsen Jonathan. Gírele s Java: Developing with J2ME. Segunda
Edición. Ed. Apress. Estados Unidos de América. 2003
[MN2004]
Moreno Navarro Juan José. Arquitecturas de Software. Curso de
Software basado en Componentes
[MR2003]
Malyan R. Lenaghan A. A Multi-service Architecture to Support Mobile
IP Applications over Heterogeneous Wireless Networks. Networking and
Communications Group, Kingston University. Reino Unido. 2003
[PJ2003]
Project
JXTA.
JXTA
v2.0
Protocols
Specification
en
http://spec.jxta.org/v1.0/docbook/JXTAProtocols.html#intro-fjp. 2003
[PIC2004]
Pickens John. Point to Multi Point (P2MP). Com21.
[ZAC2003]
Stefanos Zachariadis (s.zachariadis@cs.ucl.ac.uk), “Use of Logical
Mobility for Mobile Self-Organisation”, Department of Computer
Science University College London University of London, Noviembre
del 2003.
[TA2000]
Thakkar Amisha. Wireless Architecture for access to Remote Services
(WIARS). State University of New York at Buffalo. 2000
[WA2004]
Overview
of
Wireless
Architectures
and
Products
http://www.cs.purdue.edu/homes/fahmy/reports/leynawap.htm
en