u250961

•

SIN SIGLA

julieth guillen

21/4/2024

¡Este material tiene más páginas!

Vista previa del material en texto

© Copyright por Leonardo Varela Guevara y José Manuel Guerrero Serrano, 2004
2
Modelo de actores y la implementación del portal de servicios
para sistemas móviles en el lenguaje orientado a actores,
SALSA.

Por
Leonardo Varela Guevara
José Manuel Guerrero
Asesor: Rafael Gómez
Tesis de pregrado Universidad de los Andes 2004
TESIS

Parte de los requisitos de graduación de Ingeniería de
Sistemas y Computación en la Universidad De Los Andes.

Bogotá, Colombia
3
Dedicada por Leonardo:
A mis padres, por su amor, apoyo incondicional, consejos y
entendimiento.
A mis hermanos por su amor, soporte emocional y profesional y por su
tiempo.
A Gabriela por su amor, apoyo emocional, soporte profesional, por su
paciencia y entrega.
A Alejandro Martínez por que debió ser coautor de esta tesis, pero la
vida no le alcanzó.

Dedicada por José Manuel:
A Andreita por ser puro amor
A mi familia por ser el apoyo incondicional y el amor eterno
Al Mante por lo enseñado
A los BTFC por ser amigos del alma
4
AGRADECIMIENTOS

En primer lugar, nos gustaría agradecer a nuestro asesor, Profesor
Rafael Gómez, por ser un excelente mentor, pero sobretodo por
tratarnos como iguales y como amigos, por su confianza y por creer en
nuestro trabajo de investigación. Él nos ha ayudado a ver esta tesis de
una manera más abstracta y profunda.

También nos gustaría hacer extensivo este agradecimiento a los
profesores de Ingeniería de Sistemas y Computación de la Universidad
de los Andes: José Abasolo, Beatriz Acosta, Germán Bravo, Rodrigo
Cardoso, Ángela Carrillo, Gloria Cortés, Harold Cruz, Fernando de la
Rosa, Rafael García, Olga Lucia Giraldo, Ernesto Lleras, Olga Mariño, Luz
Adriana Osorio, Francisco Rueda, Sandra Rueda, Silvia Takahashi, Jeimy
Cano, Juan Diego Jiménez, Juan Pablo Quiroga, y todos los demás
miembros del departamento a quienes les debemos nuestra más
profunda gratitud por el indescriptible impacto que tuvieron en nuestras
vidas profesionales y en nuestro proceso de crecimiento profesional.

Y especiales gracias al grupo de desarrolladores de SALSA,
especialmente a Carlos Arturo Varela, que siempre estuvieron atentos y
disponibles a ayudarnos durante nuestro proceso de aprendizaje y
desarrollo de este trabajo de Tesis.

5
Agradecimientos de Leonardo

A mis padres, Carlos Arturo y Flor Alba, mis hermanos Carlos y Javier,
que siempre me han brindado amor incondicional, soporte emocional y
profesional, que me han hecho creer que es posible, cuando lo he
necesitado en momentos críticos de mis estudios de pregrado. A mi
papá que con su ternura y sabiduría me ha ayudado a mostrarme el
camino, a mi mamá por su ternura e inteligencia que me ha guiado en
momentos difíciles, a mis hermanos porque siempre conté con ellos en
todo momento y por brindarme apoyo en todo sentido.

A Gabriela Pizo, por permitirme compartir con ella mis momentos más
maravillosos, ella ha sido una fuente constante de amor, paciencia,
felicidad, entendimiento, valor, fuerza y progreso, por su continuo
apoyo profesional, por leer y hacer comentarios de este documento, por
su tiempo y por su casa.

A José Manuel Guerrero, coautor de la tesis, por su paciencia, su
dedicación, su amistad, su soporte, por permitirme compartirle cosas
diferentes a la tesis, por la confianza y la credibilidad que siempre hubo
como grupo, por su tiempo y por dejar que se estableciera mi casa
como sede de trabajo.

A mi abuela Ana Tulia, mis primos, primas, tíos, tías, que también han
sido un soporte emocional durante mi vida estudiantil, en especial a mis
6
sobrinas Tatiana y Catalina que me han brindado paz y alegría desde su
nacimiento, por ser especiales, y por su ternura.

A todas las personas que de una u otra manera hicieron placentera mi
vida estudiantil en la Universidad de los Andes: a mis amigos del equipo
de fútbol los Borrachos del Tablón FC: José Manuel, Carlos Alberto,
Miguel, Fabián, Javier Camilo, Daniel, Pachón, Jara, Lina, Jeisson, Hugo,
Pana, Darwin, a mis compañeros de proyectos en los diferentes cursos,
a Deicy, Sergio y todas las demás personas que me permitieron
disfrutar al máximo la época universitaria y que hicieron de ella una
experiencia inolvidable.

Agradecimientos de José Manuel
Gracias monumentales a Andreita, quien todo el tiempo estuvo a mi
lado, me dió todo su amor y me enseñó a soñar con un mundo mejor.
Quisiera agradecer enormemente a mi familia, a Pedro, Mary, Nando y
Rafa, porque junto a ellos sigo creciendo día a día, aprendiendo de cada
uno de ellos y compartiendo las alegrías y tristezas para hacer la vida
mucho más llevadera.
Muchas gracias a Leonardo, mi compañero de tesis, porque con su
confianza y entusiasmo me ayudó a creer en mi mismo y a emprender
este ambicioso proyecto que al final tuvo un muy buen desenlace.
A Alejandro Martínez, el Mante, por que alguna vez formó parte de esta
tesis y siempre será parte de nuestras vidas.
7
Y gracias totales a todos los BTFC, a los que alguna vez hicieron parte
del equipo pero en especial a Barre, Miguel, Leonardo, Fabián, Daniel,
Lina, Pana, Javier, Pachón y Jara quienes de una u otra menara hicieron
que existiera el Oso y por darme la oportunidad de vivir junto a ellos
momentos inolvidables.

TABLA DE CONTENIDO
1. INTRODUCCIÓN .................................................................................................... 11
2. EL MODELO DE ACTORES .................................................................................... 15
2.1. ACERCAMIENTO AL MODELO DE ACTORES ................................................................ 15
2.2. COMPUTACIÓN WORLDWIDE .................................................................................. 16
2.2.1. Nombramiento Universal ........................................................................ 17
2.2.2. Escenarios de aplicación ......................................................................... 18
2.2.2.1. Agentes de Internet ....................................................................................... 18
2.2.2.2. Problemas de “divide y conquistarás” con paralelismo. ............................... 19
2.2.2.3. Otros escenarios............................................................................................. 21
2.2.2.3.1. Aplicaciones por colaboración.................................................................. 21
2.2.2.3.2. Computación Coordinada ......................................................................... 21
2.2.3. Comunicación remota y migración......................................................... 22
2.2.3.1. Teatros ............................................................................................................ 23
2.2.3.2. Migración de actores universales................................................................... 23
2.2.3.3. Migración cast................................................................................................. 24
2.2.3.4. Migración de mensajeros ............................................................................... 24
2.2.4. Modelo jerárquico de coordinación ........................................................ 25
3. SALSA (SIMPLE ACTOR LANGUAGE, SYSTEM AND ARCHITECTURE)...... 26
3.1. COMPUTACIÓN WORLDWIDE EN SALSA.................................................................. 27
3.1.1. Modelo de nombramiento universal....................................................... 28
3.1.1.1. Nombres Universales de Actores ................................................................... 29
3.1.1.2. Localizadores Universales de Actores............................................................ 31
3.1.1.3. Nombramiento en el Computador Worldwide............................................... 32
3.1.1.3.1. Servicio de Nombramientopara actores universales.............................. 32
3.1.1.3.1.1. Protocolo UANP ..................................................................................... 33
3.1.2. Comunicación Remota y Migración ........................................................ 34
3.2. PROGRAMACIÓN ORIENTADA A ACTORES................................................................. 35
3.2.1. Creación de Actores ................................................................................ 36
3.2.2. Envío de Mensajes .................................................................................. 37
3.2.3. Cambios de Estados Internos................................................................. 37
3.3. MODELO DE COORDINACIÓN.................................................................................. 38
3.3.1. Token Passing Continuation ................................................................... 38
3.3.2. Join Continuation .................................................................................... 39
3.3.3. Named Tokens ........................................................................................ 40
3.3.4. First-Class Continuation .......................................................................... 40
4. PORTAL DE SERVICIOS PARA SISTEMAS MÓVILES......................................... 41
4.1 MODELO DEL SISTEMA........................................................................................... 41
4.2 ARQUITECTURA PROPUESTA DEL SISTEMA................................................................ 42
4.2.1 Agente Usuario ............................................................................................ 44
4.2.2 Espacio Activo .............................................................................................. 45
4.2.3 Unidad de Espacio Activo ............................................................................ 48
4.2.4 Gestor de Usuarios ...................................................................................... 49
9
4.2.5 Fuente de Posicionamiento ......................................................................... 50
4.2.6 Gestor Contexto Temporal .......................................................................... 50
5 IMPLEMENTACIÓN DEL PORTAL DE SERVICIOS PARA SISTEMAS
MÓVILES EN SALSA ....................................................................................................... 51
5.1 EL MODELO DE ACTORES EN LA ARQUITECTURA DEL PORTAL DE SERVICIOS PARA
SISTEMAS MÓVILES ............................................................................................................. 51
5.1.1 Definición de teatros ................................................................................... 52
5.1.1.1 Agente Usuario................................................................................................. 53
5.1.1.2 Espacio Activo ................................................................................................. 53
5.1.1.3 Unidad de Espacio Activo................................................................................. 54
5.1.2 Definición de actores estáticos ................................................................... 54
5.1.2.1 Agente Usuario Control .................................................................................... 55
5.1.2.2 Espacio Activo Control ..................................................................................... 55
5.1.2.3 Unidad Espacio Activo Control ......................................................................... 56
5.1.3 Definición de Servicios ofrecidos por los actores estáticos.............................. 57
5.1.3.1 Definición de los servicios que ofrecen los agentes usuarios............................... 57
5.1.3.2 Definición de los servicios que ofrecen los espacios activos. .............................. 57
5.1.3.3 Definición de los servicios que ofrecen las unidades de espacio activo................ 58
5.1.4 Definición de actores dinámicos..................................................................... 58
5.1.4.1 Agente Usuario Mensajero................................................................................ 59
5.1.4.2 Espacio Activo Mensajero................................................................................. 59
5.2 IMPLEMENTACIONES DEL PORTAL DE SERVICIOS PARA SISTEMAS MÓVILES USANDO
SALSA 59
5.2.1 Alcance de la implementación del portal de servicios para sistemas
móviles 60
5.2.2 Parsers de lectura de requerimientos y productos.................................... 61
5.2.2.1 Agente Usuario ............................................................................................... 61
5.2.2.2 Espacio Activo................................................................................................. 76
5.2.2.3 Unidad Espacio Activo .................................................................................... 77
5.2.3 Escenarios de implementación.................................................................... 81
5.2.3.1 Implementación utilizando un mensajero simple ................................................ 84
5.2.3.2 Implementación utilizando un mensajero inteligente .......................................... 84
5.2.4 Resultados Obtenidos.................................................................................. 86
5.2.4.1 Descripción del ambiente de ejecución .............................................................. 86
5.2.4.2 Comparación de los datos obtenidos .................................................................. 88
5.2.4.2.1 Resultados de la ejecución con el actor mensajero simple que migra a 10 UEA
88
5.2.4.2.2 Resultados de la ejecución con el actor mensajero inteligente que migra a 10
UEA 89
5.2.4.2.3 Resultados de la ejecución con el actor mensajeros inteligente que migra a 5 y a
10 UEA 89
5.2.4.3 Análisis de los resultados .................................................................................. 90
RECOMENDACIONES ..................................................................................................... 96
CONCLUSIONES .............................................................................................................. 99
LISTA DE FIGURAS....................................................................................................... 101
LISTA DE TABLAS ......................................................................................................... 102
LISTA DE EJEMPLOS DE CODIGO............................................................................. 103
ANEXOS ........................................................................................................................... 108
10
A. CÓMO DESCARGAR E INSTALAR EL PLUG-IN DE SALSA E INSTALARLO EN EDITPLUS.
108
B. COMO DESCARGAR SALSA Y EJECUTAR SU PRIMER PROGRAMA EN
SALSA.......................................................................................................................... 114
C. CÓMO COMPILAR Y EJECUTAR PROGRAMAS EN SALSA USANDO
SISTEMA OPERATIVO DIFERENTE A WINDOWS ............................................. 128
D. UN EJEMPLO CON MIGRACION. .................................................................. 130
E. EJEMPLO DEL USO DE NAMED TOKENS .................................................... 136
F. INSTALACION DEL PORTAL PARA SERVICIOS MOVILES, USO DEL CD
INCORPORADO. ....................................................................................................... 138

11
1. Introducción

El crecimiento de los recursos que se encuentran disponibles en Internet
hace de este un computador global con capacidad gigante, conocido en
el modelo de actores como el WWC (World Wide Computer). El objetivo
del WWC es convertir a la Web en una infraestructura unificada,
dependiente, lo cual la hace especial para la computación distribuida. Es
decir, aprovechatodos los recursos sub-utilizados para proveer a los
programadores la potencialidad de distribuir globalmente sus
aplicaciones; se trata de lograr ofrecer a los usuarios móviles y a los
colaboradores remotos una interfaz unificada para los datos y
programas. Varias aplicaciones en múltiples dominios, tan diversas
como computación paralela masiva, colaboración remota, computación
coordinada, y lo que nos interesa más en este trabajo de tesis que son
los agentes de Internet, son los temas que motivan el crecimiento y
desarrollo del WWC.

Dada la potencialidad encontrada en el WWC, este trabajo de tesis
pretende introducir este concepto en el siguiente escenario: imagine
entrar a un centro comercial o algún otro espacio activo y que su
dispositivo móvil sea capaz de ofrecer justo aquella oferta que usted
estaba buscando, o quizás una que no era la prioritaria pero que usted
desea, dado un historial de interacciones con los diferentes espacios
activos. Mas allá de esto, imagínese como empresa que pueda ofrecer
descuentos u ofertas a alguien que seguramente se interesa por sus
productos, y que, además, esas personas estén lo suficientemente
cercanas a usted. En general, imagine que cada vez que usted cambia
12
de espacio activo (espacio geográfico reducido) el servidor que computa
la generación de ofertas cambia dinámicamente en tiempo de ejecución.

El aporte de esta tesis es un desarrollo del problema anteriormente
introducido en un lenguaje de programación que soporta el modelo de
actores que se llama SALSA (Simple Actor Language, System and
Architecture), que implementa la teoría propuesta por este modelo.

Los niveles de adaptabilidad que exigen problemas como el planteado
anteriormente requieren de tecnologías que en el momento son
insuficientes; por ejemplo Java se usa mucho por su soporte para
contenido Web dinámico a través de applets, clases cargadas por red,
verificación de “bytecode”1, ejecución segura, código multi-plataforma, y
código de bytes compatible, para nombrar algunas.

Java es una tecnología promisoria para computación sobre Internet y
móvil, pero no facilita la programación orientada a actores, por esto,
SALSA nos ofrece una gran ventaja sobre Java, pues es un lenguaje de
programación basado en Java, que hace transparente al programador la
sincronización de mensajes y migración de actores, además de su
capacidad de reconfigurar dinámicamente las aplicaciones.

En esta tesis se pretende estudiar la potencialidad del uso del WWC, el
modelo de actores usando SALSA en la implementación de un problema
cuya arquitectura fue propuesta en el diseño del portal de servicios para

1 Código de bytes del inglés “bytecode”, código generado por el compilador de Java, para ser interpretado por la
máquina.

13
sistemas móviles. Este problema lo clasificamos como uno de los
escenarios de aplicación de los problemas que se resuelven usando
agentes móviles.

Pretendemos, además, hacer mediciones exactas en mejoras de tiempo,
usando diferentes maneras de atacar el problema. Para esto, se
plantearon diferentes escenarios que van a ser descritos a continuación:

• Agente simple: Imagine un mensajero que recorre un centro
comercial o espacio activo, buscando el producto que usted
necesita, y que obtenga para usted una lista de todas las ofertas
que se ajustan al producto que usted requiere. Este mensajero es
un agente simple, dado que no realiza ningún procesamiento
inteligente diferente de buscar un producto con unas
características dadas.

• Agente inteligente: Ahora imagine que este mensajero es capaz
de velar por sus intereses y filtrar algunas ofertas que usted no
tendrá en cuenta por alguna razón. De esta manera, usted
recibirá una lista más reducida y acorde con sus necesidades.

• Varios agentes: Ahora imagine que varios agentes simples se
reparten los locales de un espacio activo para hacer su trabajo y
de esta manera optimizar el tiempo de búsqueda del producto
deseado.
La estructura del documento consta de cuatro grandes partes: primero
se introducirá el modelo de actores, un acercamiento básico para el
14
entendimiento de este modelo; luego se continúa con una breve
introducción orientada hacia qué es el lenguaje SALSA, se exponen sus
componentes y su funcionalidad; se sigue con la explicación de cuál es
la estructura y diseño de la aplicación del portal de servicios para
sistemas móviles[2]; para terminar, se presenta una manera de adaptar
la especificación de diseño con el lenguaje. Al mismo tiempo se
intentará mostrar la potencialidad de SALSA con respecto a Java,
principalmente, y por qué usar un lenguaje de programación que
implemente el modelo de actores permite un gran avance en la
consecución de los objetivos de la especificación.
15

2. El modelo de actores

2.1. Acercamiento al modelo de actores

Los actores extienden los objetos secuénciales encapsulando un hilo
de control junto con procedimientos y datos en la misma entidad; de
esta manera proveen una unidad de abstracción y distribución
cuando se usa concurrencia. Los actores se comunican por paso de
mensajes asincrónicos (Figura 1); a menos que se fuercen maneras
de coordinación específicas, los mensajes se reciben en un orden
arbitrario que puede diferir del orden de envío.

Una implementación de este modelo normalmente provee para los
mensajes una caja de correo local, y no hay garantía de que los
mensajes sean procesados en el mismo orden en el cual son
recibidos. Los actores son intrínsecamente independientes,
concurrentes y autónomos, lo cual permite eficiencia en la ejecución
paralela [1].
16

Figura 1. Diagrama de un Actor
2.2. Computación Worldwide

La computación Worldwide estudia los aspectos relacionados con el
uso de plataformas de computación y colaboración usando redes de
áreas grandes, así como la Web y tecnologías de Internet para
tomar ventaja de todos los elementos relacionados con los
dispositivos que pueden estar conectados a estas redes.

El paradigma tradicional de uso de recursos locales es irrelevante
cuando este tipo de computación entra en juego, dado que la
capacidad de recursos que se pueden encontrar, geográficamente
distribuidos, es grande.

17
Toda esta infraestructura puede ser pensada y accedida
uniformemente como parte de un todo unificado: El computador
global (Word Wide Computer).

2.2.1. Nombramiento Universal

Es el mecanismo para referenciar sistemas móviles globales, y
para obtener dinámicamente referencias a objetos desde sus
nombres, independientemente de su ubicación actual.

En la computación Worldwide es indispensable el uso de
mecanismos de nombramiento universal. Estos mecanismos
tienen que facilitar la movilidad de los objetos, lo cual significa
que se debe abstraer de la ubicación del objeto, con el fin de una
migración independiente de ésta, en contraste con la
infraestructura de la Web, que usa referencias dependientes de la
ubicación (URL) y por ende pierde la capacidad de relocalización
transparente de documentos.

Es importante tener en cuenta los protocolos de comunicación de
los dispositivos disponibles que se encuentran conectados a
Internet; dada su naturaleza heterogénea, es de esta manera
que el mecanismo de nombramiento debe, además, ser
independiente de la plataforma e incluir el protocolo (o el
conjunto de protocolos) que se requieren para la comunicación
con el objeto.

18
2.2.2. Escenarios de aplicación

Los escenarios de aplicación únicamente pretenden mostrar los
diferentes ambientes, problemas, o circunstancias en las cuales el
desarrollo del modelo de actores es útil, y nos permite una
ventaja sobre otros modelos o paradigmas de programación. De
la misma manera,para mostrar como nuestro problema en
particular se encuentra dentro de esta gama de escenarios aptos
para el uso de actores.

2.2.2.1. Agentes de Internet

Es la representación de un objeto en diferentes escenarios
que son capaces de resolver dinámicamente situaciones dadas
para su representante. Estos agentes tienen la potencialidad
de viajar sobre Internet para lograr sus objetivos.

Como ejemplos de esto, podemos analizar los remates en
Internet y el caso que nos ocupa en esta tesis, que es el
portal de servicios para sistemas móviles. En el primero, el
agente es capaz de ofertar “inteligentemente” hasta un
máximo ofrecido por su representante y hasta el último
minuto del remate. Así mismo, en el segundo caso, cada
usuario del portal tiene su representación en el mismo, y este
es capaz de resolver “inteligentemente” requerimientos de
productos solicitados o informar de posibles ofertas de locales
de espacios activos (centros comerciales, lugares comerciales
19
concurridos) que sean de interés de su representado. A su
vez, cada representación de un usuario tiene un agente que
es capaz de representarlo en un espacio activo y este también
tiene representantes que buscan los requerimientos del
usuario en los diferentes locales que son agentes que
representan a los locales o sitios comerciales de estos
espacios activos; esto se explica mejor con la siguiente figura
(Figura 2).

Figura 2. Modelo del portal de servicios para sistemas
móviles

2.2.2.2. Problemas de “divide y conquistarás” con
paralelismo.

20
Existen problemas para los cuales se pueden identificar
claramente divisiones que pueden ser procesadas
paralelamente sin dependencia entre las partes, en estos, se
puede aplicar la estrategia “divide, distribuye y conquista”
donde el resultado son las soluciones parciales computadas
de manera distribuida.

Sin embargo este tipo de problemas requieren migración de
datos y código como un servicio básico ofrecido por el
lenguaje de programación para resolver el problema.

Los siguientes son algunos de los problemas que se
encuentran en este tipo de escenario: análisis de criptografía:
encontrar llaves criptográficas, rendering de animaciones e
imágenes complejas.

Actualmente SALSA esta siendo utilizado para resolver un
problema en física de partículas, identificado hace mas de 30
años, sobre la existencia de partículas subatómicas ("missing
baryons") no observadas anteriormente, y que requiere de
capacidades computacionales masivas para análisis de datos.
Referencia:

B. Szymanski, C. Varela, J. Cummings, and J. Napolitano,
Dynamically
Reconfigurable Scientific Computing on Large-Scale Heterogeneous
Grids,
21
Lecture Notes in Computer Science, vol. 3019, Springer Verlag,
Berlin,
2004, R. Wyrzykowski, J. Dongarra, M. Paprzycki and J.
Wasniewski (Eds.),
Proc. of the Fifth International Conference on Parallel Processing
and
Applied Mathematics (PPAM'2003). Czestochowa, Poland,
September 2003
(Revised papers), pp. 419-430.

2.2.2.3. Otros escenarios

Existen otros campos computacionales a los cuales el modelo
de actores aplica, los cuales vamos a mencionar, pero no
vamos a entrar en detalle.

2.2.2.3.1. Aplicaciones por colaboración

Son las que permiten la contribución humana remota
proveyendo una única interfaz a los datos; el famoso
(WYSIWIS) “Lo que usted ve es lo que yo veo” (del Ingles
“What You See Is What I See)”.

2.2.2.3.2. Computación Coordinada

Uno de los principales problemas de la computación
paralela es la coordinación de los componentes
autónomos, como, por ejemplo, los motores de búsqueda
22
distribuidos en la Web, las transacciones distribuidas, y la
computación punto a punto.

2.2.3. Comunicación remota y migración

La migración y la comunicación remotas exigen la localización y
acceso a los recursos computacionales asociados de una manera
independiente de la ubicación de estos. Es importante, entonces,
el nombramiento universal antes visto, con lo cual este modelo
de actores logra la abstracción de estos tipos de movilidad.

Las metas que pretende lograr este modelo son la transparencia
en la comunicación entre dos actores: el envío de mensajes entre
estos debe ser independiente de su ubicación, por lo cual, a los
actores no les debe importa si el mensaje se envía a una
ubicación remota o a una local. Sin embargo, esta transparencia
no debe ser comprometida por la movilidad de los actores; es
decir, si un actor migra mientras se le envía un mensaje, esto no
debe afectar la semántica de recepción.

Logrando estas metas, se asegura la posible reconfiguración de
aplicaciones en tiempo de ejecución de forma arbitraria, dada la
naturaleza asíncrona de los mensajes y la migración.

Existen, además, actores que, por su naturaleza, no son móviles
o fácilmente movibles; por ejemplo una salida de una pantalla, o
una gran base de datos. A estos actores se les denomina actores
23
de ambiente; de esta manera, cuando una actor migra,
automáticamente obtiene referencia de los actores de ambiente
en el teatro local.

Estas metas son de las más complicadas de obtener, dado que
una aplicación que corra en el computador global debe manejar
errores que no se dan en ambientes de ejecución locales, como,
por ejemplo, los fallos en hosts remotos. Esto es delicado de
implementar, si se quiere ofrecer la seguridad de que los
mensajes sean recibidos siempre. Los tipos de migración que se
manejan dentro del modelo son: migración de actores
universales, migración cast y migración de mensajero.

2.2.3.1. Teatros

En este modelo, los actores universales residen en teatros.
Los teatros proveen un sistema de ejecución para actores
universales, permitiendo la comunicación remota y la
migración, así como el acceso al ambiente local.

La comunicación remota se desarrolla mediante el envío de
mensajes asincrónicamente entre actores que pueden
encontrarse en diferentes teatros y pueden contener
referencia a otros actores universales y a otros objetos
serializables de Java.

2.2.3.2. Migración de actores universales
24

Es la libre migración de actores, de teatro en teatro, en
respuesta a un mensaje que le requiere al actor su migración.
Todos los “conocidos” del actor se mantienen igual, excepto
por los actores de ambiente, que se vuelven referencias a los
correspondientes a la entrada al nuevo teatro. Esta migración
hace que se actualice la base de datos del servidor de
nombres con la nueva ubicación del actor, y dejando en el
teatro original un actor temporal que reenvíe los mensajes
dirigidos al actor que se encuentra migrando al nuevo teatro,
mientras este los puede hacer llegar hasta su buzón de
correo.[3][4]

2.2.3.3. Migración cast

Por cast se entiende unidades de coordinación, es decir, una
reunión de actores que se agrupan con alguna característica
común, lo cual hace que tenga sentido la migración de toda
una unidad de una sola vez. Aunque algunas veces no es
posible migrar toda una unidad, entre más cercanos y
correlacionados se encuentren los actores, mejor desempeño
tendrá la aplicación.

2.2.3.4. Migración de mensajeros

Un mensajero es un actor especial que migra con el propósito
de llevar mensajes de un teatro local a un teatro remoto. Un
25
mensajero también puede tener otros comportamientos, tales
como hacer del envió de mensajes algo más robusto, dado
que, como es un actor, persistirá sobre fallas temporales en el
actor objetivo, intentar el retorno de mensajes, cuando hay
fallas en el envío, seguir actores móviles, realizar acuse de
recibo o procesamiento, manejar excepciones comunes en el
teatro del actor objetivo, estar a cargo de la red y lo que
tenga que ver con nombramiento.

En el caso particularde esta tesis, la función de los
mensajeros es cargar información para ser consultada en
otros teatros y regresar con resultados, que pueden ser de
diferentes maneras: procesados en el teatro remoto, o para
procesar en el teatro local cuando el mensajero regrese.

2.2.4. Modelo jerárquico de coordinación

La coordinación de actividades es uno de las tareas más difíciles
en las aplicaciones de computación global y es uno de los
aspectos de los cuales los desarrolladores de este tipo de
aplicaciones se preocupan más, específicamente la coordinación
concurrente, distribuida y las actividades móviles en sistemas
asíncronos. Los mecanismos tradicionales de coordinación están
basados en espacio compartido, y por esto no escalan a
ejecución global.

26
El modelo para coordinación de actores escalable, como base
para el razonamiento y la construcción de sistemas distribuidos
es introducido con SALSA (Simple Actor Language Systems, and
Applications). Sin embargo este tema se sale del alcance de
nuestra tesis y más información puede ser encontrada en los
libros y documentos que se dan como referencia en la bibliografía
de este trabajo.[5][6][7]

3. SALSA (Simple Actor Language, System and Architecture)

SALSA es un lenguaje de programación que implementa el modelo de
actores descrito en el capitulo anterior. Obviamente, tiene su propia
implementación de nombramiento universal, de comunicación remota, y
esconde al desarrollador la difícil tarea de manejar la concurrencia y la
coordinación entre actores.

Al ser SALSA un lenguaje de programación que se está escribiendo en
Java, le presenta al desarrollador una sintaxis muy parecida a la de este
último, además toda su potencialidad, dado que todo el código Java
puede ser reutilizado en SALSA.

Lo anterior se debe a que el código SALSA es preprocesado por el
compilador de salsa y convertido a código Java, el cual es compilado
junto con la librería de Actores de SALSA, a Bytecode de Java que
cualquier implementación de la maquina virtual de Java puede correr,
haciendo a SALSA, al igual que Java, un lenguaje multiplataforma, como
27
lo podemos observar en la siguiente figura
(Figura3).

Figura 3. Diagrama de compilación de un programa en
salsa

3.1. Computación Worldwide en SALSA

Vamos a entrar un poco en detalle de cómo es la
implementación que hace SALSA para solucionar el problema del
nombramiento universal, la comunicación remota, y la migración
en la computación Worldwide. SALSA soporta la especificación del
modelo de actores descrita en el capitulo anterior, de esta
manera, SALSA permite desarrollar programas que se puedan
28
ejecutar en el computador Worldwide (un conjunto de máquinas
virtuales que le dan “posada” o soporte a los actores universales,
llamadas teatros), y, aunque algunas cosas no serán
ampliamente detalladas en este capitulo, en las referencias se
podrán encontrar documentos que profundizan más acerca de
esta implementación.

3.1.1. Modelo de nombramiento universal

El modelo de nombramiento universal propuesto por SALSA está
basado en la estrategia de identificación uniforme de recursos
usando – Identificador Uniforme de Recursos [2]- (URI, del inglés
Uniform Resource Identifier), éstos incluyen Nombres Uniformes
de Recursos (URN, del inglés Uniform Resource Names), y
también Localizadores Uniformes de Recursos (URL, del inglés
Uniform Resource Locators), al igual que Citaciones Uniformes de
Recursos (URC, del inglés Uniform Resource Citations) que
contienen metadatos. Desafortunadamente, sólo los URL están
siendo desarrollados ampliamente, y con esto perdiendo toda la
movilidad transparente de los recursos de la Web.

SALSA especifica dos tipos de actores, los que no tienen nombre
universal y los que lo tienen y además su nombre es legible y
adivinable, de esta manera y siguiendo la convención para el
direccionamiento de documentos, se usan URI para los nombres
de los actores y sus ubicaciones.

29
La independencia de la ubicación se logra a través de un servicio
de nombramiento universal, que permite localizar a los actores
únicamente con su nombre y sin depender de su ubicación. Este
servicio se detallará en la sección 3.1.1.3.1

3.1.1.1. Nombres Universales de Actores

Los nombres universales de actores son identificadores
globales que persistente sobre la vida del actor y proveen una
respuesta sobre la ubicación del mismo como se puede ver en
la siguiente figura (Figura 4).

Figura 4. Nombres Universales de Actores

Esta estructura permite a los programas clientes localizar un
actor en cualquier momento inclusive si el actor migra muchas
veces en su ciclo de vida dado que su nombre seguirá siendo
el mismo todo el tiempo.

Un ejemplo de una UAN utilizada para la implementación en
SALSA del portal de servicios para sistemas móviles es el
siguiente:

31
uan://chie.uniandes.edu.co:3030/unidadEspacioActivo/calzado
Bosi

La respuesta de la ubicación actual del actor esta dada por un
servidor de UANs escuchando en el host de Internet
chie.uniandes.edu.co en el puerto 3030, el cual es el puerto
por defecto de los demonios de UANs y puede ser omitido.

3.1.1.2. Localizadores Universales de Actores

Esta basado en un URI y describe la ubicación actual de un
actor permitiéndole a los programas clientes el envío de
mensajes a un determinado actor en cualquier momento.

Un ejemplo de un UAL utilizado en la implementación en
SALSA del portal de servicios para sistemas móviles es el
siguiente:

rmsp://xue.uniandes.edu.co:4040/unidadEspacioActivo/ubicac
ionBosi
de esta manera, para enviarle mensajes a los actores, el
sistema se conecta a un servidor RMSP (Protocolo de envío de
mensajes remoto, del inglés Remote Message Sending
Protocol) en el host xue.uniandes.edu.co en el puerto 4040 el
cual es el puerto por defecto para los requerimientos RMSP y
puede ser omitido. El servidor RMSP usa una tabla de hashing
que mapea las UAL relativas –en el ejemplo
32
/unidadEspacioActivo/UbicacionBosi – para validar las
referencias a los actores dentro del teatro, una vez el mensaje
ha sido de-serializado, se coloca en el buzón de correo del
actor para su procesamiento local.

3.1.1.3. Nombramiento en el Computador Worldwide

El computador Worldwide permite los nombres de actores
universales y los localizadores de dos formas: La primera,
proveyendo un servicio de nombramiento de actores
universal, el cual mantiene un mapeo desde las UAN a las
UAL. Y, segundo, implementando construcciones de
programación de alto nivel para nombramiento para ser
usadas en programas desarrollados en SALSA.

3.1.1.3.1. Servicio de Nombramiento para actores
universales

Ofrece el servicio de registro de actores con su nombre y
ubicación para ser accedidos desde cualquier programa
cliente que desee obtener la ubicación de un actor a partir
de su nombre. Esto lo logra a partir del registro de las
UANs con sus respectivos UALs. Está implementado como
un conjunto de servidores que entienden el protocolo:
Protocolo del Nombramiento Universal de Actores (UANP,
del inglés Universal Actor Naming Protocol).

33
3.1.1.3.1.1. Protocolo UANP

Este protocolo es el usado por el servidor de nombres
para la creación, modificación y eliminación de
entradas de actores, sus nombres y sus ubicaciones.
Los métodos de este protocolo son mostrados a
continuación (Tabla 1):

Método Parámetros Acción
PUT UAN relativa, UAL Crea una nueva entrada en la base
de datos
GET UAN relativa Retorna la UAL correspondiente en
la base de datos
DELETE UAN relativa Elimina la entrada en la base de
datos
UPDATE UAN relativa, UAL Actualiza la UAL correspondiente en
la base de datos
Tabla 1: Métodos del protocolo UANP.El servicio de nombres no necesita ser centralizado,
existe una tesis de Master en RPI (Rensselaer
Polytechnic Institute) que desarrollo un servicio de
nombres descentralizado (basado en Chord) para que
no se dependa de un solo servidor de nombres para
enviarle mensajes a un actor universal. La referencia
es:

34
Cam Tolman, A Fault-Tolerant Home-Based Naming
Service for Mobile Agents Master's Thesis, Rensselaer
Polytechnic Institute, April 2003.

El proyecto Chord se trata de construir sistemas
distribuidos escalables, robustos usando ideas de peer-
to-peer (punto a punto). Chord es completamente
descentralizado y puede encontrar datos usando solo
log(N) mensajes, donde N es el número de nodos en el
sistema.

3.1.2. Comunicación Remota y Migración

SALSA utiliza el protocolo (RMSP) para el envío de mensajes a
actores remotos, y es usado automáticamente por el código
generado al compilar los programas escritos en SALSA. De esta
manera los programadores de SALSA, envían mensajes de la
misma manera a actores locales y actores remotos, escondiendo
la preocupación por la ubicación del actor.

Esto se logra creando una referencia local con el tipo del actor
remoto o del Actor universal (UniversalActor, que es como la
clase Object en Java), luego esta referencia es actualizada o
“mejorada” de una local a una referencia de un actor universal
usando el método getReferenceByName(UAN) o
getReferenceByLocation(UAL) del comportamiento
UniversalActor.
35

Cuando se completa este proceso, la referencia local, se vuelve
un alias al actor universal remoto, una vez obtenido este alias, un
mensaje puede ser enviado al actor de la misma manera que si
fuese local.

SALSA permite la migración de actores a teatros conocidos,
obteniendo primero una referencia al agente (actor) para luego
llamar el método migrate(UAL) que lanza la migración. Cuando el
actor migra, los actores universales conocidos por el actor son
pasados por referencia; los objetos serializables de Java y los
tipos primitivos son pasados por valor; los actores anónimos y los
objetos de Java no serializables generan excepciones de tiempo
de ejecución, los actores de ambiente se obtienen del nuevo
teatro.

3.2. Programación Orientada a Actores

Los programas en SALSA se agrupan en módulos, cada modulo es
capaz de contener comportamientos e interfaces. Existe la herencia
simple de la misma manera que en Java, pues un comportamiento
puede heredar de otro y, además, puede implementar múltiples
interfaces para simular la herencia múltiple.

Así como en Java, de la clase Object heredan todos los objetos, en
SALSA, del comportamiento UniversalActor heredan todos los
comportamientos.
36

3.2.1. Creación de Actores

La creación de actores en SALSA se logra de manera similar a
Java, pero teniendo en cuenta el nombramiento universal.

Cuando un actor se instancia, una referencia al nuevo actor es
retornada, un ejemplo de la creación de un actor es la siguiente:

EspacioActivoControl ea = new EspacioActivoControl();
bind(uanEspacioActivo, ualEspacioActivo);

donde se instancia EspacioActivoControl, y una referencia al
nuevo actor es retornada y gracias al bind es ubicado en el
servidor de nombres con la pareja UAN: uanEspacioActivo, UAL:
ualEspacioActivo. Sin embargo en versiones subsecuentes a la
usada esta creación de actores es deprecada, y en la
documentación de SALSA se encuentra la nueva forma de
creación de actores.

Las definiciones de comportamientos en SALSA que son similares
a las clases en Java también pueden contener constructores
(pueden ser varios siguiendo el polimorfismo que se usa en
Java), estos últimos son utilizados para la creación de nuevos
actores.

3.2.2. Envío de Mensajes

La implementación en SALSA del envío de mensajes es
potencialmente un llamado a un método en Java; los actores en
SALSA tienen un buzón de correo que guarda los mensajes
recibidos y el actor los procesa secuencialmente.

Para enviar un mensaje a un actor, se usa la referencia al mismo,
seguido por una flecha (<-) y el nombre del mensaje con sus
parámetros. Por ejemplo:

ea<-cargarAtributos(requerimiento,eaUAN);

Donde ea es la referencia al actor, que obtuvimos en el numeral
anterior, y cargar atributos es el mensaje de este actor que se
quiere poner en el buzón de correo de ea.

Si no se especifica el actor al que se le quiere enviar el mensaje,
este se pone en el buzón de correo de sí mismo.

3.2.3. Cambios de Estados Internos

Un actor puede cambiar el estado de las variables internas,
incluso sus variables privadas. Si se pretende cambiar los estados
de las variables de otros actores, se debe hacer por medio de
mensajes y solo las variables que no son privadas.
38

3.3. Modelo de Coordinación

SALSA usa tres tipos de continuaciones para coordinar la
comunicación entre múltiples actores que son autónomos y
asíncronos; ellas son descritas en los siguientes numerales.

3.3.1. Token Passing Continuation

Un token es el resultado de la invocación de un mensaje de un
comportamiento. La continuación de paso de tokens (Token
Passing Continuation) usa estos tokens como parámetros de
mensajes anidados de mensajes subsecuentes, el siguiente es un
ejemplo que ilustra este caso.

getMensaje()@standardOutput<-println(token);

Acá el valor de retorno del llamado del mensaje getMensaje() se
pasa como parámetro del mensaje println(token) que se le envía
al actor standardOutput.

El alcance de los tokens es el último mensaje de paso de tokens.
El paso de tokens, como se puede ver en el ejemplo anterior, se
indica por medio de una arroba (@); así múltiples mensajes
pueden ser anidados para formar una cadena del largo deseado
de paso de tokens, un ejemplo de esto es:

39
a1<-m1(args)@a2<-m2(token)@a3<-m3(token);

Acá el primer token se refiere al resultado de la evaluación de
a1<-m1(args) y el segundo token, hace referencia al resultado
de la evaluación de a2<-m2(token).

El tipo de retorno de los mensajes es token, y se resuelve
únicamente en tiempo de ejecución.

3.3.2. Join Continuation

Para establecer unos límites de sincronización, SALSA permite
continuaciones de join. En una expresión de continuación de join,
un actor cliente recibe un arreglo con los tokens retornados por
múltiples actores, una vez todos ellos hayan terminado de
procesar su mensajes. Un ejemplo de continuación de join es:

join
{
autor1<-escribirCapitulo(1);
autor2<-escribirCapitulo(2);
}@editor<-revisar @ imprenta<-imprimir;

El actor editor recibe el mensaje de revisar con un arreglo de
capítulos como parámetros y los pasa a la imprenta para ser
impresos. El mensaje revisar es enviado únicamente después de
40
que los actores autores terminan de procesar su respectivo
mensaje de escribirCapitulo().

3.3.3. Named Tokens

Los Named Tokens son una manera de extender y mejorar los
token-passing Continuations que permiten guardar el valor de un
Token y sincronizar con más control múltiples mensajes a
actores, y describir join blocks que permiten poner mecanismos
de control (como if o while) dentro de bloques de sentencias que
se sincronizan al final, a través de un join continuation

Es decir, a los tokens se les pueden asignar nombres y
declararlos de la manera que una variable es declarada en
SALSA. Es una forma útil de lograr multicast, lo cual le da a
SALSA mucho más poder expresivo, con el nombramiento de
tokens una continuación no necesita ser expresada
completamente en una sola línea y partes subsecuentes de una
continuación pueden ser basadas en partes de continuaciones
previas. Sin embargo los named tokens pueden ser usados
únicamente como argumentos de mensajes de SALSA. No puedenser usados en operaciones aritméticas.

Para un ejemplo de named tokens referirse a el apéndice E.

3.3.4. First-Class Continuation

41
Las continuaciones de primera clase tienen como fin asegurar la
terminación de la ejecución de los mensajes anidados anteriores
a su aparición. Esto se logra con un mensaje especial llamado
currentContinuation; a continuación se muestra un ejemplo de su
uso:

espacioActivoControl<-setRequerimiento(requerimiento)@
espacioActivoControl<-listarUEA()@
espacioActivoControl<-enviarMensajeros()@ currentContinuation;

acá el mensaje setRequerimiento(requerimiento) termina
completamente antes de enviar el mensaje listarUEA(), y este, a
su vez, termina completamente antes de enviar el mensaje
enviarMensajeros(); todo esto se logra dado que la ultima
continuación es un currentContinuation.

4. Portal de servicios para sistemas móviles.

4.1 Modelo del sistema

El portal de servicios para sistemas móviles se basa en la interacción
de un usuario móvil con distintos sitios de interés, tales como
centros comerciales, parques, sitios de recreación, universidades,
etc. Estos espacios están representados por diferentes módulos de
software que se encargan de gestionar autónomamente la relación
de estos espacios con los usuarios.
42
Basados en los espacios activos (EA) y sus respectivos locales o
unidades de espacio activo (UEA), y en la representación de los
usuarios en el sistema, que en este caso es el agente usuario (AU),
también existen varios elementos en los cuales se apoya el sistema
para lograr el objetivo del mismo, estos son: el Gestor de Usuarios
(GU), encargado de almacenar la información de los diferentes
usuarios que pertenecen al sistema y la Fuente de Información de
Posicionamiento (FIP), que permite determinar el momento en que
un usuario se encuentra dentro del área de influencia de un
determinado ambiente o espacio. Todos estos elementos se ven
representados en la siguiente figura:

2
Figura 5. Modelo Portal de Servicios para Sistemas Móviles.

4.2 Arquitectura propuesta del sistema

2 Tomado de la tesis de Darío Melo
43
La arquitectura del sistema está basada en los siguientes criterios:

• Independencia entre los componentes, sin dejar de lado la
colaboración de los mismos.

• Abstracción de estructuras del mundo real dentro del sistema.

• Definición de interfaces para la comunicación entro los
diferentes componentes del sistema.

La arquitectura propuesta se ve en la siguiente figura:

Figura 6. Arquitectura Portal de Servicios para Sistemas
Móviles.
44

4.2.1 Agente Usuario

El agente usuario es la representación del usuario ante el
sistema. Tiene asociadas varias funciones tales como:

• Tramitar la obtención de información solicitada por el
usuario durante la interacción del mismo con el sistema.

• Gestionar la solicitud de información de manera proactiva,
basado en el contexto en el cual se desenvuelve el
usuario.

• Regular las labores de filtraje de la información recibida de
los diferentes espacios activos.

• Actualizar la información del usuario que representa dada
por la interacción del mismo con el sistema.

4.2.1.1 Agente Usuario Services
Es la interfaz de los agentes usuarios. Aquí se encuentran los
servicios que pueden proveer el agente usuario, estos
servicios pueden ser utilizados ya sea por los diferentes
espacios activos o por los usuarios que interactúan con el
sistema, en este caso es el gestor de usuarios y los espacios
activos.
45

4.2.1.2 Agente Usuario Control
Este modulo se encarga de administrar, regular y ejecutar
procesos internos del mismo agente usuario y a su vez
delegar algunas responsabilidades a diferentes componentes
del sistema.

4.2.2 Espacio Activo

Los espacios activos son las representaciones de espacios
geográficos que unen varios locales o sitios comerciales que se
encuentran cerca físicamente. Sus funciones se basan en atender
el conjunto de solicitudes que los diferentes usuarios realizan;
para ello deben valerse de la integración y el acceso que tienen a
los diferentes UEA que se encuentran y hacen parte de su
espacio activo; he ahí otra función muy importante que es la de
integrar de manera eficiente a todos los UEA que conforman su
espacio activo. Por ultimo, su funcionalidad también maneja la
capacidad de generar de manera proactiva y reactiva propuestas
que interesen a los representantes de los diferentes agentes
usuarios.

La meta de los diferentes espacios activos es entregar
información de muy alta calidad y relevancia; es decir, poder
generar propuestas que sean definitivamente aceptados por el
agente usuario y este entregarlas a su respectivo representado.

46
Estas son las funciones que deben cumplir los diferentes espacios
activos:

• Generar propuestas a partir de solicitudes realizadas por
los usuarios

• Administrar las diferentes consultas realizadas por los
usuarios; es decir, manejar los query y request de tal
modo que estos sean procesados por los diferentes
componentes integrados en el sistema.

• Ofrecer maneras de suscripción de usuarios a su espacio
activo, para que este goce de los servicios ofrecidos por
las UEA que componen el espacio activo.

• A partir de la información del usuario, poder generar
propuestas proactivas que sean aceptadas por el agente
usuario a partir de la interacción de las UEA que lo
componen.

• Detectar a los usuarios cuando estos se encuentren en su
área de afluencia, apoyándose en las funciones de la
Fuente de Información de Posicionamiento.

• Avisar a las diferentes UEA del ingreso de usuarios al área
de influencia del espacio activo para que estos puedan
generar propuestas a estos usuarios.
47

• Registrar a los usuarios que así lo permitan para que el
espacio activo sea notificado del ingreso de estos a su área
de influencia.

Como se ha dicho anteriormente, los espacios activos están
conformados por partes más pequeña que se denominan
Unidades de Espacios Activo y que ofrecen servicios particulares,
dando al espacio activo la función de integrador de estas
unidades.

4.2.2.1 Espacio Activo Services
Es la interfaz de los espacios activos. Aquí se encuentran los
servicios que pueden proveer el espacio activo, estos servicios
pueden ser utilizados ya sea por los diferentes espacios
activos o por los usuarios que interactúan con el sistema, en
este caso son los agentes usuarios y las unidades de espacio
activo.

4.2.2.2 Espacio Activo Control
Este modulo se encarga de gestionar, coordinar y ejecutar, si
el caso, procesos internos del mismo espacio activo y a su vez
delegar algunas responsabilidades a diferentes componentes
del sistema, como lo son las unidades de espacio activo y los
agentes usuarios.

4.2.3 Unidad de Espacio Activo

Las unidades de espacio activo son la representación en el
sistema de los diferentes locales o sitios comerciales que se
encuentren en un determinado espacio activo. Como
representantes tienen las siguientes funciones fundamentales:

• Atender a las solicitudes de información realizados por el
espacio activo al cual pertenece. Estas solicitudes son
hechas a partir de los servicios registrados por parte de la
UEA en el espacio activo asociado.

• Realizar propuestas de manera preactiva cuando se le
informe que un determinado usuario se encuentra dentro
del área de influencia del espacio activo asociado. Estas
propuestas deben estar sustentadas por el perfil del
usuario para que sean aceptadas por este.

• Generar las propuestas solicitadas por parte de un usuario.
Estas peticiones se hacen por intermedio del espacio activo
asociado y de acuerdo con unas reglasque regulan su
comportamiento.

4.2.3.1 Unidad de Espacio Activo Services
Es la interfaz de las unidades de espacio activo. Aquí se
encuentran los servicios que pueden proveer la unidad de
49
espacio activo, estos servicios pueden ser utilizados ya sea
por los diferentes espacios activos o por los usuarios que
interactúan con el sistema.

4.2.3.2 Unidad de Espacio Activo Control

Este modulo se encarga de gestionar, coordinar y ejecutar, si
el caso, procesos internos de la mismo unidad de espacio
activo y a su vez delegar algunas responsabilidades a
diferentes componentes del sistema.

4.2.4 Gestor de Usuarios

El gestor de usuarios se encarga de administrar toda la
información de todos los usuarios del sistema; gracias a ello se
convierte en una herramienta capaz de integrar el análisis para
filtrar propuestas masivas.

Dentro de sus funciones se encuentran:

• Registrar las actividades realizadas por los diferentes
usuarios en el sistema.

• Evaluar las propuestas que van a ser entregadas a lo
usuarios para que estas sean de alta calidad y relevancia.

50
• Generar query estructuradas que luego serán ofertas
preactivas a los usuarios.

• Determinar el perfil de un usuario a partir de la interacción
del mismo con el sistema.

• Establecer comportamientos globales y particulares de los
usuarios basándose en la información centralizada que
posee.

4.2.5 Fuente de Posicionamiento
Se encarga de la recolección de datos de la ubicación física de
determinado usuario en coordenadas, así como también de la
entrega de datos que le sean solicitados.

4.2.6 Gestor Contexto Temporal

Es el encargado de administrar la información asociada a eventos
de tiempo y acontecimientos que afectan la conducta de las
personas de una sociedad de forma general.

Este sistema es utilizado a su vez por los espacios activo, los
cuales emplean esta información para orientarse sobre qué
propuestas generar dado un contexto situacional, y por los
agentes usuarios, los cuales usan este sistema como filtro de
información y para deducir el contexto situacional del individuo.
51

5 Implementación del portal de servicios para sistemas
móviles en SALSA

5.1 El modelo de actores en la arquitectura del portal de servicios
para sistemas móviles

El modelo de actores fue pensado para la implementación del
portal de servicios para sistemas móviles, dada su capacidad para
expresar agentes en términos de actores. Encontramos una
especial afinidad entre actores del sistema y personas de la vida
real; es el caso de los mensajeros del sistema, que se comportan
como mensajeros en la vida real, y la manera en que estos se
pueden configurar para lograr “comportarse” de maneras más
adecuadas que simplemente envío de mensajes, aprovechando la
movilidad del código y de los actores que ofrece SALSA.

Más allá de esto, identificamos los espacios activos y las unidades
de espacio activo como teatros dentro del sistema de actores, lo
cual corresponde con la realidad del problema que se quiere
atacar. También se puede identificar un teatro matriz: teatro
donde se crearían las instancias de actores o representantes de
los compradores en estos espacios activos, es decir, los usuarios
del sistema.

Es así como se quiso implementar el problema con el modelo de
actores, propuesto en el capítulo 2, en el lenguaje de
52
programación expuesto en el capítulo 3, y basándonos en la
arquitectura propuesta en el capítulo 4.

Como nos podemos dar cuenta, la utilización de este modelo para
la solución de la arquitectura propuesta necesitó de algunos
cambios, dadas las diferencias en el concepto entre modelo de
actores y modelo de objetos. A continuación, entraremos a
detallar el modelo de actores en esta arquitectura.

5.1.1 Definición de teatros

Como lo habíamos adelantado, dimos cabida a teatros para
las diferentes entidades de la arquitectura. Estas son: los
agentes usuarios (la representación del usuario en el
sistema), los espacios activos (la representación de los
centros comerciales o espacios donde se encuentren muchos
sitios comerciales) y las unidades de espacios activos (que
son los locales u objetivos finales).

Es importante aclarar que no es el teatro como tal el que crea
los actores mensajeros: es el lugar en el cual se crean y es el
sitio al cual llegan, pero la creación de mensajeros y la
migración de los mismos está a cargo de los actores
residentes en los diferentes teatros.

53
Estos teatros se caracterizan por ser ambientes de ejecución
independientes, que pueden llegar a ejecutarse en máquinas
físicamente separadas.

Vamos a describir los teatros y sus funciones a continuación
de manera detallada.

5.1.1.1 Agente Usuario

Para los agentes de usuarios, el sistema tiene
destinado un solo teatro, que es el que va a
registrar a los usuarios en un espacio activo, es
decir, le va a notificar al espacio activo de la
existencia de un usuario en su sistema. Este teatro
tiene la tarea de albergar al actor que lee los
requerimientos que hacen los usuarios, y de
ofrecerse como cuna de los mensajeros que crea
este actor, además de recibirlos cuando estos
terminen de procesar el requerimiento.

5.1.1.2 Espacio Activo

Para los espacios activos, se destinan diferentes
teatros, uno por cada espacio activo, de tal manera
que haya uno para los diferentes centros
comerciales u otros espacios que quieran pertenecer
54
al sistema. De esta manera, el teatro del espacio
activo aloja al centro comercial como tal pero no a
las locales de los espacios activos, y es capaz de
recibir mensajeros de agentes usuarios y de enviar
sus propios mensajeros a los diferentes teatros que
se encuentren registrados como locales o unidades
de espacio activo, con el fin de dar curso a los
requerimientos de los usuarios.

5.1.1.3 Unidad de Espacio Activo

Para las unidades de espacio activas, es decir, para
los locales o unidades más pequeñas del sistema,
existe un teatro particular: un solo teatro que aloja
a los actores de estas unidades. También aloja a los
mensajeros que llegan de los espacios activos
buscando respuestas o productos coincidentes con
los requerimientos del agente usuario.

5.1.2 Definición de actores estáticos

Se llamán actores estáticos, dada su naturaleza no móvil.
Ellos son residentes de sus teatros, y están a la espera de
mensajeros y mensajes con los cuales interactúan para hacer
del sistema algo interesante. Son, por definición, actores que
interactúan con otro tipo de actores: los móviles, y en ellos
55
regulan su coordinación y tienen el control de la ejecución:
cuándo es concurrente y cuándo no, asignándole tareas a los
mensajeros, y cargándolos y descargándolos de
requerimientos. También se hacen cargo de disparar los
comportamientos de los mensajeros por medio de mensajes y
se encargan de la creación dinámica de actores mensajeros.

5.1.2.1 Agente Usuario Control

Este actor es el encargado de escuchar propuestas
a su usuario representado y de enviar mensajeros
con los requerimientos que el usuario al que
representa hace. Esto lo logra creando un
mensajero que se cargará con el requerimiento del
usuario y haciéndolo migrar al espacio activo más
cercano a la ubicación de la persona a la que
representa.

5.1.2.2 Espacio Activo Control

Este actor es uno de los de mas importancia ya que
en él residen los comportamientos que forman la
columna vertebral del sistema, es decir, él sirve de
administrador del requerimiento al esperar al
mensajero de algún usuario y además gestionar las
ofertas que proponen las diferentes Unidades de
56
Espacio Activo; para esto debe ser capaz de
cargarle el requerimiento a los diferentes
mensajeros para que ellosviajen en busca de las
posibles ofertas. Otra función muy importante es la
de hacer el itinerario de las Unidades de Espacio
Activo a las que deben ir los mensajeros, esto lo
logra gracias a que previamente el ha registrado a
todas las unidades con su nombre, ubicación y tipos
de producto que esta ofrece.
En conclusión, este actor, es la vía de comunicación
entre el requerimiento (usuario) y los productos
(locales comerciales)

5.1.2.3 Unidad Espacio Activo Control

Este actor es de gran importancia, dado que el o
ellos son la base fundamental para lograr ofrecer
productos a los usuarios del sistema. Su función es
usar un parser para la lectura de los productos que
ofrece y la conversión de estos en objetos Producto
asociados a la unidad, para luego registrarse en el
espacio activo y registrar cuáles serán los tipos de
productos para futuras búsquedas que hagan los
usuarios del sistema. Esto lo hace a través de la
57
lectura de una URL que apunta a un archivo XML
que contiene la información.

5.1.3 Definición de Servicios ofrecidos por los actores estáticos

En la siguiente parte se enuncian los servicios que ofrecen los
actores estáticos, los cuales son invocados por medio de
mensajes de otros actores.

5.1.3.1 Definición de los servicios que ofrecen los agentes
usuarios

Es el encargado de leer el o los requerimientos del cliente
usando un parser (que será explicado en la sección 5.2.2)
que, dada una URL, convertirá un archivo XML en un
objeto de tipo Requerimiento.

5.1.3.2 Definición de los servicios que ofrecen los espacios
activos.

Ofrece el servicio de registro en el espacio activo que
utiliza cada una de las unidades de espacio activo para
pertenecer a dicho espacio activo y de esta manera el
58
espacio activo asignará el respectivo mensajero a esa
unidad de espacio activo, si así lo requiere.

5.1.3.3 Definición de los servicios que ofrecen las unidades
de espacio activo.

Es el encargado de buscar dentro de sus productos el
requerimiento solicitado por algún mensajero, y, cuando
encuentra un producto que cumple con las características
solicitadas, le asigna dicho producto al respectivo
mensajero, para que este pueda coleccionar todos los
productos resultados.

5.1.4 Definición de actores dinámicos

A estos actores les llamamos dinámicos dado su naturaleza móvil
que les permite viajar entre los diferentes teatros. Estos son
creados por los actores estáticos y durante toda su vida útil son
controlados por ellos. Su principal función es moverse a
diferentes teatros, y, ya estando en el teatro objetivo, cargar o
descargar requerimientos y productos, y ejecutar
comportamientos que ofrecen los actores locales; de esta manera
se logra alivianar el procesamiento, dado que no va a existir el
procesamiento centralizado.

59
5.1.4.1 Agente Usuario Mensajero

Al ser creado el agente usuario mensajero en el teatro agente
usuario, le deben cargar el requerimiento solicitado por el
usuario y después hacerlo viajar hasta el teatro espacio activo
correspondiente. Estando allá, el actor Espacio Activo Control
descargará el requerimiento para que el proceso continúe, y
terminado este, el Agente Usuario Mensajero volverá al teatro
agente usuario con los productos resultados encontrados.

5.1.4.2 Espacio Activo Mensajero

El Espacio Activo Mensajero es creado en el teatro Espacio
Activo y debe, después de que le carguen el requerimiento, ir
hasta el teatro Unidad Espacio Activo donde el actor local
buscara si hay algún producto que cumpla con las
características del requerimiento y si es así le cargará los
productos resultados, para que una vez finalizado este
proceso, el Espacio Activo Mensajero vuelva a el teatro
Espacio Activo, donde se precederá a devolver la respuesta al
usuario final.

5.2 Implementaciones del portal de servicios para sistemas
móviles usando SALSA

60
A continuación presentaremos diferentes escenarios que nos
servirán para comparar tiempos en la consecución de los
objetivos y para comparar el trafico de red que genera
diferentes tipos de implementaciones. Además de esto,
veremos en detalle el alcance de este trabajo de tesis, y una
forma detallada del lector de archivos XML que fue el
estándar escogido para la lectura de productos y
requerimientos. Esta sección está pensada para mostrar de
una manera más clara la forma en que diferentes tipos de
implementaciones pueden ser llevadas a cabo para resolver
este problema y explicar por qué el modelo de actores es
especial para resolverlo.

5.2.1 Alcance de la implementación del portal de servicios para
sistemas móviles
El alcance de la implementación del portal de servicios
para sistemas móviles en el leguaje SALSA pretende cubrir
todo lo relacionado con los ofertas generadas, ya sea
reactivamente o proactivamente. Para lograr esto, se
simularon varios componentes y también se obviaron
otros; así pues, no se va a tomar en cuenta la Fuente de
Información de Posicionamiento, ni la función del Gestor
de Usuarios, ni el Manejador del Contexto Temporal.

Teniendo en cuenta lo anterior, lo que se pretendió lograr,
en la implementación del portal de servicios para sistemas
móviles, fue el tramite que tiene una oferta, desde que
61
nace como un requerimiento hasta que es entregada al
usuario móvil, pasando por la gestión que realiza el
respectivo agente usuario, el espacio activo y las
diferentes unidades de espacio activo. De esta manera,
nos despreocupamos de quién hace el requerimiento, si es
el propio usuario (reactivamente) o el Gestor de Usuarios
(proactivamente), simplemente asumimos que ya está
hecho y que además sabemos en cuál espacio activo
queremos realizar el trámite de dicho requerimiento.

5.2.2 Parsers de lectura de requerimientos y productos

Se definieron estructuras de archivos XML para los diferentes
actores estáticos del sistema, de esta manera será clara la
forma en que tanto los usuarios, como los espacios activos y
sus unidades de espacio activo implementen programas
propietarios que generen estos archivos y gracias a la
naturaleza de los archivos XML, permite el acceso a ellos
desde un programa en cualquier plataforma.

A continuación, presentaremos la estructura de archivos XML
que se desarrollaron para los agentes usuarios, espacios
activos, y unidades de espacio activo.

5.2.2.1 Agente Usuario

62
El archivo XML que define un requerimiento de un
agente usuario debe ser muy flexible, por esto se
pensó en una manera genérica de leer las
características de un requerimiento, y finalmente se
llegó a una estructura cuyo ejemplo mostramos a
continuación:

En la línea número 2, encontramos la identificación
del usuario en el sistema; en la línea numero 3, se
encuentra el nombre del producto que se quiere
buscar; en la número 4, podemos encontrar el tipo
de producto que se busca; en la línea número 5, la
acción que se espera que las unidades de espacio
activo realicen (entre estas se encuentran: vende,
alquila, compra). Luego vienen tantas características
como sea necesario, de la siguiente manera:

1. Ejemplo de Código: (XML) Agente usuario XML inicial.

Sin embargo, este XML propuesto para la solución
del problema se quedaría corto. Por eso hemos
definido un XML más completo que abarque
diferentes combinaciones de peticiones, incluyendo
restricciones, conjunciones, etcétera. Esta
estructura está pensada para que satisfaga el
siguiente DTD (Data Type Definition):

2. Ejemplo de Código: (DTD) Agente Usuario - DTD de la
versión mejorada del XML.

Aunque este DTD es suficiente, para mayor claridad
y más flexibilidad es deseable construir un esquema
que pueda restringir la forma de los archivos XML
que definen requerimientoshechos por los usuarios
a través de los agentes de usuarios que ofrece el
sistema. Así pues, el siguiente esquema fue definido
para satisfacer el requerimiento y será explicado en
detalle:

3. Ejemplo de Código: (XSD) Esquema del XML mejorado.

Este esquema es base de un requerimiento. A
continuación vamos a explicar de una manera un
poco más gráfica su significado:

El elemento base de un XML de requerimiento es
agenteUsuario, y de este se desprenden seis
elementos hijos como se muestra a continuación:

Figura 7: Estructura del XML de Agente Usuario
(Requerimiento).

67
• Id: Identificación del usuario en el sistema.
Podría ser, por ejemplo, el número de
cédula, o un consecutivo que asigne el
sistema.
• Nombre: Nombre del producto que se desea
buscar.
• Tipo: Tipo del producto que se desea buscar;
por ejemplo, calzado, ropa, carro, etc.
• Acción: Es la acción que se desea que los
locales realicen sobre el producto.
• Ofertas: Número de ofertas que se desea
que el sistema seleccione y traiga al usuario
final.
• Características: Las características que se
quiere que tengan los productos resultados
de la búsqueda. Profundizaremos un poco
mas este

Figura 8. Estructura de las características de los Productos
(Requerimiento).

68
Las características se componen de cero o varios
elementos característica, así como también de cero
o varios elementos restricción.

Figura 9. Estructura de una característica de un producto
(Requerimiento).

Cada elemento característica tiene los siguientes de
hijos:
• Nombre: Es el nombre de la característica;
por ejemplo: color, marca, precio, etc.
• Valores: Es un conjunto de cero o mas
elementos valor; por ejemplo, de la
69
característica con nombre “color” los valores
podrían ser: rojo, verde, etc.
• Rango: Cuando la naturaleza de la
característica así lo permite, se puede definir
acá un rango dado un máximo y un mínimo;
por ejemplo, en la característica de nombre
“precio” el rango puede ser: máximo
100.000 y mínimo 50.000. Para los casos en
que no se especifica el máximo, se
entenderá que se refiere a un número
infinito positivo, y, en los casos en que no
se define el mínimo, se entenderá que se
refiere a cero.
• Calificación: El objetivo de este campo es
poder clasificar las ofertas que el sistema
encuentra para el usuario, es decir, lograr
determinar cuáles ofertas del total
encontradas son las que finalmente serán
enviadas al usuario. Nosotros proponemos
un sistema de tolerancias para manejar este
tema, así, este campo contendría la
tolerancia de cada característica.
Cuando la característica depende de la validez
de otras características, se tejera un árbol de
elementos características gracias a este campo.

Figura 10. Estructura de una restricción (Requerimiento)

Como se ve en la figura, las restricciones tienen los mismos elementos
que las ya mencionadas características. Podríamos definir a las
restricciones como características negadas; así pues, se podrían
representar necesidades tales como color: NO azul, estableciendo una
restricción para color con valor azul.

4. Ejemplo de Código: (XML) Ejemplo de un XML de un
requerimiento.
73

Este XML representa un requerimiento bastante
estricto. Para poder explicarlo, es necesario exponer
la interpretación que le dimos al elemento
calificación. Antes de hacerlo, queremos hacer
énfasis en que es únicamente nuestra
interpretación, pero la naturaleza del elemento
permite que se use de la manera que se desee.

La calificación en este ejemplo está medida en
niveles de tolerancia, es decir, una tolerancia 0
implica que la característica es obligatoria, para este
ejemplo tomamos una escala de 0 a 10. Sin
embargo, nuevamente, tanto la escala como la
interpretación quedan abiertas a nuevas
implementaciones.
Al haber una tolerancia de 0 a 10 y siendo 0 algo
obligatorio, 10 es entonces nada deseable, o
inclusive una restricción. Dado que esta es sólo
nuestra interpretación y que se desea que esta
estructura sea genérica, se incluyó un elemento de
tipo restricción.

De esta manera, una característica que tenga
tolerancia 2 significa que el 80% de los productos
considerados en la búsqueda deben cumplir la
74
característica. De esta manera, el ejemplo mostrado
anteriormente tiene la siguiente interpretación.

Figura 11. Esquema del ejemplo del XML de
Requerimiento, posibles caminos.

En este ejemplo, el usuario que realiza el
requerimiento desea encontrar unos tenis. En las
líneas 9 a la 20, se encuentra una característica que
indica que el 100% de los productos buscados
deben ser de talla 39; es decir, que la tolerancia es
cero a tallas diferentes. De la misma manera, los
tenis NO pueden ser blancos, y el precio máximo
que se va a pagar por los tenis es $200.000 pesos.

75
Ahora bien, se desea que el 30% de los tenis
buscados sea Nike o Puma, es decir, el nivel de
tolerancia es 7, o, de otra manera, es tolerable que
7 de cada 10 tenis no sean de marca Nike o Puma.

De este porcentaje de tenis de estas marcas, es
deseable que por lo menos el 50% sea de color rojo
o verde; es decir, la tolerancia es de 5.

Además, si los tenis son Nike o Puma, el 60% de
los productos tenidos en cuenta deben tener un
precio entre $100.000 pesos y $150.000 pesos y el
40% restante puede estar fuera de este rango, pero
nunca mayor a $200.000 pesos.

El 50% de los productos buscados deben ser de
marca Adidas, de este 50%, el 40% deben ser de
color negro o azul, y el 70% de este último 40%
debe tener un precio máximo de $100.000 pesos.

Como el 50% debe ser Adidas y el 30% Nike o
Puma, el 20% restante no tiene restricción de
marca, para este ejemplo.

De esta manera, nos podemos dar cuenta de que
las características y las restricciones pueden tener
76
conjunciones al nivel de profundidad y detalle que
se desee.

Esto hace que los requerimientos mostrados sean
flexibles, soportando conjunciones, disyunciones y
negaciones de características de productos.

5.2.2.2 Espacio Activo

El espacio activo en nuestra implementación no
presenta un parser ni un archivo XML del cual pueda
leer su configuración, simplemente, es un actor que
escucha requerimientos de usuarios, tiene sus
propios mensajeros, y da curso por medio de ellos a
los requerimientos.

Sin embargo, en el diseño del portal de servicios
para sistemas móviles, se habla de manejos de
contexto temporal, por lo cual definimos un archivo
preliminar de cómo se debería configurar un espacio
activo, para que soporte cierto tipo de actividades.

5. Ejemplo de Código: (XML) XML de un Espacio Activo

5.2.2.3 Unidad Espacio Activo

El archivo XML que define el conjunto de productos
que ofrece cada una de las unidades de espacio
activo es vital para el funcionamiento del sistema, y
sobre todo, para que cada una de las unidades de
espacio activo logren su objetivo final que es
78
entregar ofertas a los diferentes clientes, así pues
cada producto debe estar representado fielmente
por este archivo XML.

Basándonos en esto, definimos el siguiente
esquema para la representación de los productos en
las diferentes unidades de espacio activo:

El elemento base del XML es el elemento UEA que
tiene los siguientes atributos: nombre, que se
refiere al nombre de la unidad de espacio activo e
identificación, que hace referencia al identificador
de la respectiva unidad.

Figura 12. Estructura de una UEA.

El elemento UEA se compone de un conjunto de
elementos producto. Cada elemento producto tiene
como atributo el id del producto y, además, cinco