Tesis 270

CIS0830-IS13
MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS

GENÉRICOS INDEPENDIENTES DE LA PLATAFORMA ORIENTADO A
DISPOSITIVOS MÓVILES
CÉSAR ESTÉBAN CASTAÑEDA RUÍZ
PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTÁ, D.C.
2009
Ingeniería de Sistemas Istar CIS0830-IS13
CIS0830-IS13
MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE
SERVICIOS GENÉRICOS INDEPENDIENTES DE LA
PLATAFORMA ORIENTADO A DISPOSITIVOS MÓVILES
Autor:
César Estéban Castañeda Ruíz
MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO

DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE
SISTEMAS
Director
JAVIER FRANCISCO LÓPEZ PARRA
Jurados del Trabajo de Grado
ANDRÉS BARRERA
CÉSAR DÍAZ
2
Pontificia Universidad Javeriana Memoria de Trabajo de Grado

BOGOTÁ, D.C.
DICIEMBRE, 2009

Rector Magnífico
Joaquín Emilio Sánchez García S.J.
Decano Académico Facultad de Ingeniería
Ingeniero Francisco Javier Rebolledo Muñoz
Decano del Medio Universitario Facultad de Ingeniería
Padre Sergio Bernal Restrepo S.J.
Director de la Carrera de Ingeniería de Sistemas
Ingeniero Luis Carlos Díaz Chaparro
Página 3
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

Director Departamento de Ingeniería de Sistemas
Ingeniero Germán Alberto Chavarro Flórez
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus
proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral
católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que
se vean en ellos el anhelo de buscar la verdad y la Justicia”
4
AGRADECIMIENTOS
A mi familia, por su apoyo;

A mis amigos, por su compañía;
A mis profesores, por su paciencia.
Página 5

Contenido
INTRODUCCIÓN .....................................................................................................16
I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO..............................18

1. OPORTUNIDAD Ó PROBLEMÁTICA ..................................................................18
1.1 Descripción del contexto ........................................................................................ 18
1.2 Formulación............................................................................................................ 19
2. DESCRIPCIÓN DEL PROYECTO ........................................................................21
2.1. Visión Global.......................................................................................................... 21
2.2. Justificación ............................................................................................................ 21
2.3. Objetivo general ..................................................................................................... 21
2.4. Objetivos específicos .............................................................................................. 21
II - MARCO TEÓRICO ............................................................................................23

1. LBS ..................................................................................................................23
1.1. Naturaleza de los LBS ............................................................................................ 23
1.2. Tipos de LBS .......................................................................................................... 24
1.3. Sistemas de Información Geográfica (SIG) ............................................................ 25
1.4. Tecnologías de Localización (LCS) ....................................................................... 25
III - PROCESO...........................................................................................................34
1. METODOLOGÍA PROPUESTA ...........................................................................34
2. DESARROLLO DEL PROYECTO ........................................................................35

I. Exploración previa.................................................................................................. 35
II. Análisis ................................................................................................................... 35
III. Diseño de la propuesta............................................................................................ 35
IV. Diseño de la arquitectura ........................................................................................ 37
V. Implementación ...................................................................................................... 37
3. REFLEXIÓN METODOLÓGICA ..........................................................................38
6
IV - RESULTADOS ...................................................................................................41
1. EXPLORACIÓN SOBRE LAS PLATAFORMAS PARA DISPOSITIVOS MÓVILES ....41
1.1. Plataformas más relevantes .................................................................................... 41
1.2. Resultado del estudio de las plataformas ................................................................ 45
2. PROPUESTA PARA LA IMPLEMENTACIÓN DE LBS...........................................46
2.1. Propuesta de operaciones básicas en los LBS ......................................................... 46
2.2. Implementación de los diferentes tipos de LBS por medio de Invocación de
Método Remoto y Generación de Evento Asincrónico ...................................................... 47
2.3. La información de posición como parámetro ......................................................... 50
2.4. Resultados del estudio sobre la implementación de LBS ....................................... 51
3. ESTUDIO DE LAS CARACTERÍSTICAS TÉCNICAS DE LA SOLUCIÓN .................52
3.1. Comparación entre los diferentes mecanismos de transferencia de datos .............. 52
3.2. Resultados de la comparación entre los diferentes mecanismos de transferencia de
datos para dispositivos móviles ......................................................................................... 54
3.3. Formato de datos .................................................................................................... 55
3.4. Resultados del estudio de los posibles formatos de datos ...................................... 56
4. PROPUESTA DE SOLUCIÓN ..............................................................................57
4.1. Compilación de las características de la Solución .................................................. 57
4.2. El Middleware “OMNI” ......................................................................................... 57
4.3. El Redirector y el Servidor OMNI ......................................................................... 58
4.4. Sesión OMNI .......................................................................................................... 58
4.5. Tipos de datos en OMNI ........................................................................................ 59
4.6. Excepciones OMNI ................................................................................................ 60
4.7. Servicios OMNI...................................................................................................... 60
4.8. OMNI Middleware Protocol................................................................................... 62
5. IMPLEMENTACIÓN ...........................................................................................64
5.1. Arquitectura ............................................................................................................ 64
5.2. Componentes .......................................................................................................... 64
5.3. Implementación de Servicios con OMNI................................................................ 67
5.4. Aplicaciones del Middleware OMNI ...................................................................... 68
6. PRUEBAS ..........................................................................................................70
6.1. Latencia y Glitter .................................................................................................... 70
6.2. Servicio de prueba – “chatLBS” ............................................................................. 72
6.3. Modificación en la especificación del Middleware OMNI como resultado de las
pruebas............................................................................................................................... 77
Página 7

V - CONCLUSIONES Y TRABAJOS FUTUROS ..................................................78

1. CONCLUSIONES................................................................................................78
2. TRABAJOS FUTUROS ........................................................................................79
VI - REFERENCIAS .................................................................................................80
V- ANEXOS ................................................................................................................84
8
RESUMEN
En los últimos años, se ha observado un crecimiento considerable en la disponibilidad y el
uso de las redes inalámbricas. El acceso a los servicios remotos por medio de dispositivos
móviles le otorga al desarrollador una nueva herramienta (la localización), la cual le permi-
tirá implementar gran variedad de servicios innovadores que solo hasta ahora comienzan a
explorarse.
Sin embargo, existen múltiples plataformas para dispositivos móviles muy diferentes e in-
compatibles entre sí. Esto impone al desarrollador una carga extra para lograr que sus ser-
vicios sean accesibles desde todas ellas, trabajo que a menudo es más complejo que la im-
plementación del servicio en sí.
El "Middleware para la Definición e Implementación de servicios Genéricos independientes

de la plataforma orientado a dispositivos móviles", nace de la necesidad de crear un Midd-
leware independiente de la plataforma, que permita al desarrollador definir e implementar
servicios genéricos de forma estándar, al mismo tiempo que mantiene brevedad y sencillez en
consideración con los recursos limitados de un dispositivo móvil.
ABSTRACT
In the last years, the availability and use of wireless networks has experienced a substantial
increase. Accessing remote services from mobile devices may bring developers information
about user's position. This information allows the implementation of a wide variety of new
and innovating services, most of them still unexplored.
There are several platforms for mobile devices; it is a challenge for developers to achieve
interoperability of their applications between different platforms. This effort is often more
complex than the implementation of the service itself.
The "Mobile-Device oriented Middleware for the Definition and Implementation of Platform-
independent Generic Services" is a platform-independent middleware that allows developers
to define and implement standard and generic services while preserving valuable low re-
sources present in Mobile Devices.
Página 9

RESUMEN EJECUTIVO
Cuando se desea implementar un servicio que será accedido principalmente por dispositivos
móviles, se enfrenta un gran problema: la interoperabilidad.
En la actualidad, existe una variedad de plataformas que compiten por el mercado de disposi-
tivos móviles; esto dificulta la tarea de definición e implementación de servicios porque im-
pone al desarrollador la necesidad de ocuparse de las particularidades de cada una de ellas.
Para solucionar este problema se estudiaron las tecnologías de transferencia inalámbrica de

datos disponibles (WiFi, WiMax, GSM, GPRS, EDGE, UMTS, HSDPA) y los protocolos que
han sido utilizados para implementar servicios exitosamente (SMS, MMS, WAP, TCP/IP,
UDP/IP).
Tradicionalmente en Computación Móvil se reconocen dos tipos de servicios:
 Servicios Pull: Son servicios de tipo RPC, que son invocados por el dispositivo
móvil con ciertos parámetros para obtener un resultado como valor de retorno.
 Servicios Push: En este caso, el dispositivo móvil recibe información de forma
asincrónica sin haberla solicitado activamente.
La solución propuesta debía pues proveer las herramientas necesarias para implementar ser-
vicios de tipo Pull y Push.
Después del proceso de exploración, se decidió diseñar un Middleware sobre TCP basado en
XML por las siguientes razones:
 El protocolo orientado a conexión TCP permite la comunicación Full-dúplex, envío y

recepción de información de forma asincrónica y es soportado por las principales
tecnologías de comunicación inalámbrica que se usan actualmente (WiFi, WiMax,
GSM, GPRS, EDGE, UMTS, HSDPA).
 El Lenguaje de Marcas Extensible (XML) provee un estándar independiente de la pla-
taforma para la serialización de los datos que serán transmitidos.
10
Un enfoque basado únicamente en Llamadas a Procedimientos remotos (RPC) no es suficien-

te, ya que la capacidad de enviar información desde el servidor al cliente de forma asincróni-
ca (Push) no puede implementarse eficientemente. Para suplir esto, muchas aplicaciones in-
vocan periódicamente un método remoto que verifica si determinado evento ha ocurrido o no.
Esto se traduce en un tráfico de datos innecesario (y potencialmente costoso) así como en un
desperdicio de la batería del dispositivo. En este trabajo, dicha aproximación se consideró
inaceptable.
Para eliminar este problema, además de la llamada a procedimientos remotos se decidió in-
cluir en el Middleware la capacidad de generar eventos. Los eventos difieren de los RPC en
que no se espera ningún retorno como resultado de su invocación, simplemente se utilizan
para avisar que algo de interés ha sucedido.
De esta forma, el Middleware propuesto define un servicio así:
 Una interfaz con los métodos Pull, que será implementada por el servidor. Estos
métodos retornan un valor como resultado o lanzan una excepción consistente en un
identificador numérico (int) y una cadena de caracteres.
 Una interfaz con eventos Pull, que será implementada por el servidor.
 Una interfaz con eventos Push, que será implementada por el cliente.
Tanto los métodos remotos como los eventos pueden recibir cualquier cantidad de parámetros
al ser invocados.
Se definió un protocolo para la invocación de métodos remotos y la generación de eventos

basado en XML-RPC, así como el estándar para los tipos de datos que se soportan y las ex-
cepciones que pueden ocurrir, tanto de usuario como de sistema.
Para fines de validación de dicho protocolo, se implementó el middleware para RIM BlackBe-
rry OS y Google ANDROID OS en Java ME, y un servidor funcional para Java SE.
Dada la popularidad creciente de accesorios como el GPS que permiten al dispositivo móvil
conocer su posición geográfica con más o menos precisión, los servicios pueden utilizar la
información de localización como un parámetro adicional que les permitirá contextualizar sus
Página 11

resultados a la ubicación del usuario. Estos servicios se conocen como LBS (Location Based
Services).
Durante el proceso de desarrollo se encontró que el middleware propuesto es suficiente para

permitir la implementación de LBS de tipo Pull, Push y Tracking (objetivo general de este
trabajo), y que además puede utilizarse para la creación de servicios genéricos que no necesa-
riamente hacen uso de la información de localización.
Resultados:
 La implementación del Middleware se realizó de tal forma que cumple con los obje-
tivos satisfactoriamente.
 Los tipos de datos que soporta el Middleware fueron cuidadosamente escogidos y de-
finidos para lograr la interoperabilidad entre plataformas.
 Gracias a las extensivas pruebas de rendimiento que se llevaron a cabo pudo evaluar-
se el desempeño del protocolo TCP a través de la red celular. Dicho desempeño pre-
senta ciertas particularidades que fueron tomadas en consideración.
 La definición de las operaciones básicas propuestas Invocación de Método Remoto y
Generación de Evento Asincrónico resultó ser adecuada para la implementación de
servicios LBS.
 El diseño de servicios bajo el esquema de interfaces remotas de Cliente y Servidor
cubre el objetivo principal de la propuesta inicial para este Trabajo de Grado y lo ge-
neraliza para servicios que no son necesariamente LBS.
12
EXECUTIVE RESUME
When a mobile device-oriented service needs to be implemented, the main problem faced by
developers is interoperability.
There are several platforms competing in the market of mobile devices, developers must take
care of all their particular characteristics in order to successfully define and implement mo-
bile-based services.
To overcome this problem, most important wireless data transfer technologies have been
studied (WiFi, WiMax, GSM, GPRS, EDGE, UMTS, HSDPA) and the protocols used by the
time to successfully implement mobile-oriented services (SMS, MMS, WAP, TCP/IP,
UDP/IP).
Traditionally, there are two kinds of services in mobile-computing:
 Pull-type Services: Similar to RPC services. Mobile devices perform a method invo-
cation with associated parameters to obtain results as return values.
 Push-type Services: Mobile device receives data asynchronically, without explicit

request from Client.
The proposed Solution should provide the necessary tools to implement both Pull and Push
services.
After an exploration process, a XML-based Middleware running over TCP has been designed
for some reasons:
 TCP allows Full-Duplex transmissions, sending and receiving asynchronous data and
is supported by main wireless data transfer technologies (WiFi, WiMax, GSM, GPRS,
EDGE, UMTS, HSDPA).
Página 13

 Extensible Markup Language (XML) provides a platform independent standard for

serialization of transmitted data.
RPC-based systems are not enough to efficiently implement Push-type services. To deal with
this, some applications invoke RPC procedures on a periodic basis to ask servers if certain
events have occurred. This creates an unnecessary and potentially expensive data flow. In this
work, that approach has been rejected.
The proposed Middleware includes generation events functionality. Differently from RPC,
when events are invoked there are not results awaited from such invocation; they are used
only for notification purposes (Push).
In the Middleware, a service is defined as:
 A Pull-interface implemented by Server. These procedures return a result or throw an

exception.
 A Pull-interface of events implemented by Server.
 A Push-interface of events implemented by Clients.
RPC procedures and Events can receive any number of parameters when being invoked.
A protocol for Invocation of RPC Procedures and Remote Event generation has been defined,
as well as the standard for supported data types and possible system and user exceptions.
To successfully validate the proposed protocol, it has been implemented in Java ME and Java
SE and tested over RIM BlackBerry OS and Google ANDROID OS platforms.
Given the increased use of different LCS´s that allow devices to know their current position,
services use location data as an additional parameter to contextualize their results to user
position. These types of services are known as LBS (Location Based Services).
14
During developing process it has become evident that the proposed Middleware is capable of
implementing LBS of Pull, Push and Tracking types (principal goal of this work) and can also
be used to implement generic services not necessarily involved with position data.
Results:
 The Middleware was implemented in a way that successfully accomplishes all objec-
tives of this work.
 Data types supported by the Middleware were carefully chosen and defined to
achieve interoperability between platforms.
 Thanks to extensive performance tests, TCP over cellular networks has demonstrated
to have some particular behavior that has been considered when designing the Mid-
dleware.
 Definition of proposed basic operations RPC and Remote Event Generation where
enough to implement all types of LBS.
 Service design under remote Client and Server interfaces layout successfully accom-
plishes main objectives of this work and generalizes it to implement generic services,
including LBS.
Página 15

INTRODUCCIÓN
Este documento describe el proceso de desarrollo del Trabajo de grado titulado “Middleware
para la definición e implementación de servicios genéricos independientes de la plataforma
orientado a dispositivos móviles”.
En el transcurso de este Trabajo se propone, implementa y prueba una solución al problema

de interoperabilidad entre plataformas para dispositivos móviles que surge al desarrollar ser-
vicios accedidos por medio de esta clase de dispositivos.
El proceso siempre estuvo dirigido al uso eficiente de los recursos limitados de los equipos y
a la preferencia por las tecnologías más recientes que muy seguramente estarán disponibles
para una gran cantidad de usuarios en el futuro cercano.
En la sección I – Descripción general del Trabajo de Grado, el lector encontrará una visión
global del Trabajo que incluye la formulación del problema, la justificación y los objetivos
que se plantearon en la propuesta inicial.
En la sección II – Marco teórico, se introducen los conceptos y definiciones necesarios para

la compresión adecuada de este Trabajo.
En la sección III – Proceso, se expone la metodología propuesta originalmente y qué se rea-

lizó en cada una de sus fases. Seguidamente, se consignan las diferencias entre lo propuesto y
lo realizado y se justifican las modificaciones metodológicas que debieron ser realizadas du-
rante el transcurso del proceso.
La sección IV – Resultados, se divide en subsecciones, cada una de las cuales trata de un

factor diferente en la constitución de la solución. Al final de cada subsección se encuentran
las conclusiones relevantes que finalmente son compiladas y empleadas para generar una
propuesta. A continuación, dicha propuesta y su implementación asociada son explicadas y
sus pruebas y resultados correspondientes presentados.
16
En la sección V – Conclusiones y trabajos futuros, se encuentran las conclusiones que se

alcanzaron tras la realización del presente Trabajo de Grado y algunos de los caminos que
éste abre a futuros desarrollos.
La presente memoria no pretende ahondar en los detalles técnicos de la solución propuesta ni

del software implementado. Dichos detalles se profundizan en los documentos que se entre-
gan como anexos.
Página 17

I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO
1. Oportunidad ó Problemática
1.1 Descripción del contexto
En los últimos años, la creciente tecnología de interconexión entre diferentes dispositivos

electrónicos y entre las redes mismas ha abierto una vasta gama de posibilidades para el
desarrollo de servicios y aplicaciones. Por esto, es muy importante la exploración de las
opciones que surgen al combinar las tecnologías existentes y las que muestran tendencia
a popularizarse en el futuro cercano, pues se trata de una fuente de posibles aplicaciones
innovadoras con gran potencial de éxito.
Los teléfonos móviles han estado presentes en Colombia desde hace ya más de una déca-
da, y se han difundido ampliamente. Pero en los últimos años, con el advenimiento de la
“revolución móvil” dejaron de ser sólo teléfonos y alcanzaron el nivel de pequeñas com-
putadoras de bolsillo. La miniaturización de los dispositivos, los avances en la interfaz
hombre-máquina y la reorientación de los servicios que prestan los operadores celulares
hacia una filosofía integradora, similar a la de Internet, permitirán que en pocos años una
gran cantidad de personas en Colombia [CRTC2008] y en el mundo [SASA2007], lleven
en su bolsillo un dispositivo capaz de mantener un flujo de datos constante, veloz y en
tiempo real con Internet.
Además, una red de dispositivos móviles como los descritos agrega una nueva variable:
la posición geográfica del dispositivo en un determinado momento. Dicha información
puede obtenerse por medio de Servicios de Localización (LoCation Services - LCS). El
servicio GPS (Global Position System) resulta particularmente interesante; según
[ABIR2008], es de esperarse que en los próximos 5 años se generalice la inclusión de es-
ta característica en los dispositivos móviles de todas las gamas. Sin embargo, la calidad
del receptor GPS influye en su precisión y los dispositivos móviles de gama baja con
GPS pueden no resultar lo suficientemente precisos para los servicios más exigentes. Pe-
18
ro, según [SADO2007], En el futuro, la creciente demanda de dichos servicios incenti-

vará a los fabricantes a diseñar dispositivos más baratos y precisos.
Cuando las tecnologías de conectividad inalámbrica y posicionamiento geográfico con-

vergen en un dispositivo móvil, nace la capacidad de relacionar los datos de posición
con la información disponible en un sistema de información geográfica para contextuali-
zar la prestación de un servicio. Estos servicios se conocen como Sistemas Basados en la
localización (Location Based Services - LBS).
Recientemente, los LBS y los servicios para dispositivos móviles en general han desper-
tado la atención del mercado, ya que tienen un gran potencial que solo hasta ahora co-
mienza a apreciarse. A pesar de esto, las implementaciones a gran escala no han surgido
rápidamente, ya que la mayoría de los servicios existentes son aplicaciones específicas
para ámbitos empresariales cerrados, o son proyectos de exploración e investigación
técnica para futuros desarrollos [MCMA2006].
Si bien los diferentes estándares de acceso a las redes de Internet y telefonía móvil son
aceptados universalmente, La interoperabilidad entre la gran variedad de plataformas dis-
ponibles para dispositivos móviles no se había logrado [COST2002]. Era pues necesaria
la búsqueda de un mecanismo que permitiera implementar Servicios genéricos para dis-
positivos móviles sin que los usuarios tuvieran que preocuparse por la marca o platafor-
ma de su dispositivo al acceder a ellos.
1.2 Formulación
Las redes inalámbricas y los dispositivos móviles ofrecen al usuario la posibilidad de es-
tar conectado permanentemente y en casi cualquier lugar donde se encuentre. Esto abre la
puerta a toda una nueva gama de aplicaciones, servicios, juegos, redes sociales, etc. que
solo hasta ahora está comenzando a ser explorada.
El principal obstáculo para el desarrollador es la poca interoperabilidad existente entre la

variedad de plataformas disponibles para dispositivos móviles. El desarrollador se ve
Página 19

obligado a particularizar su servicio para una sola plataforma, con la consiguiente pérdida
de mercado y oportunidades; o a abarcar varias de ellas con el esfuerzo y recursos que es-
to supone.
En el caso de los dispositivos móviles la solución a los problemas de conexión y transfe-

rencia de datos frecuentemente es mucho más compleja que el servicio mismo que se está
implementando. Dado que las operaciones de carga, ejecución, prueba y depuración de
programas en dispositivos móviles resultan muy laboriosas aún disponiendo de emulado-
res; una aplicación sencilla puede demandar mucho tiempo para su implementación.
Muchos servicios han resuelto el problema de la interoperabilidad haciendo uso de tecno-

logías que son comunes a todos los teléfonos (SMS) a costa de ser sumamente primitivos
y de no aprovechar funcionalidades potencialmente presentes en el dispositivo. Dicha
aproximación satisface efectivamente el esquema Pull-Push, ya que un mensaje de texto
SMS puede enviarse como una solicitud de servicio (Pull), y un SMS recibido es en sí un
evento asincrónico (Push). Sin embargo, la latencia de envío y recepción de un SMS difi-
cultan la implementación de servicios más complejos o que requieran algo cercano al
tiempo real.
Teniendo en cuenta la creciente disponibilidad de nuevos medios inalámbricos de alta ve-

locidad para la transferencia de datos (WiFi, EDGE, 3G) en los dispositivos móviles; se
formuló la siguiente pregunta, que motivó el desarrollo del presente Trabajo de Grado:
¿Cómo lograr la implementación de servicios genéricos para dispositivos móviles de

tal forma que se utilicen eficientemente los recursos y sean independientes de la pla-
taforma de cada dispositivo?
20
2. Descripción del Proyecto

2.1. Visión Global
Durante el desarrollo de este proyecto, se realizó una exploración de las plataformas y

tecnologías disponibles para la transferencia de datos en dispositivos móviles.
Con los resultados de dicha exploración, se procedió a proponer una solución viable y a
su implementación y prueba.
Finalmente, haciendo uso del middleware obtenido como producto final, se implementó
una aplicación que demuestra satisfactoriamente las funcionalidades necesarias para
cumplir con el objetivo de este Trabajo de Grado.
2.2. Justificación
El proyecto se realizó con el fin de brindar a los desarrolladores una herramienta que les
facilite la tarea de diseñar e implementar servicios orientados a dispositivos móviles sin
que deban preocuparse por asuntos de compatibilidad entre las diferentes plataformas.
Se busca que el desarrollador pueda concentrar sus esfuerzos en el diseño de su servicio,

mientras que los asuntos técnicos, de interoperabilidad y transferencia de datos son mane-
jados por el middleware desarrollado en este trabajo.
2.3. Objetivo general
Proponer una solución para la implementación de LBS de tipo Pull, Push y Tracking de
tal forma que sean independientes de la plataforma de cada dispositivo.
2.4. Objetivos específicos
I. Realizar una investigación exploratoria acerca de las diferentes plataformas exis-

tentes actualmente para dispositivos móviles.
Página 21

II. Analizar los datos obtenidos y con base en los resultados, proponer una solución
al problema.
III. Desarrollar la propuesta y diseñar la arquitectura asociada.
IV. Desarrollar una aplicación práctica que demuestre las funcionalidades básicas de
la propuesta en LBS de tipo Pull, Push y Tracking.
22
II - MARCO TEÓRICO
1. LBS
1.1. Naturaleza de los LBS
Según [GSMA2003] los LBS ofrecen a los usuarios un conjunto de servicios basándose
en la posición geográfica del cliente que los solicita. Dichos servicios brindan la capaci-
dad a humanos o máquinas de localizar geográficamente a otras personas, dispositivos,
vehículos o recursos, así como de poner a disposición su propia ubicación para otros
usuarios interesados. Los LBS implican dos acciones principales:
 Obtener la localización geográfica del usuario.
 Utilizar la información de localización para proveer un servicio.
Un LBS puede activarse automáticamente cuando el cliente se encuentra en una localiza-

ción específica. Alternativamente, el usuario mismo puede invocar el servicio para solici-
tar información que dependerá del sitio en que se encuentre actualmente (puntos de in-
terés, información de tráfico, vehículos, recursos o servicios de emergencia y rescate).
En [STEI2006], un LBS es presentado como la intersección de tres tecnologías diferen-

tes: Conectividad Inalámbrica y LCS, Sistemas de información geográfica e Internet
(fig. 1).
Página 23

1.2. Tipos de LBS
De acuerdo con [ADUS2004] existen básicamente tres tipos de LBS: Pull, Push y Trac-
king.
1.2.1. Pull
En un servicio de tipo Pull, el Cliente solicita activamente al Servidor el envío de in-

formación. Se reconocen dos tipos [GSMA2003]:
a) Cuando el servicio Pull requiere la posición del solicitante: En este caso,

el servicio solicitado requiere como parámetro la posición del dispositivo
móvil que lo solicita. Este tipo de servicio puede responder a preguntas co-
mo: “¿Cuál es la estación de servicio más cercana a mi posición?”.
b) Cuando el servicio Pull requiere la posición de otro dispositivo: El servi-

cio solicitado debe localizar a otro dispositivo móvil para poder ser ejecuta-
do. Un servicio de este tipo puede responder a preguntas como: “¿En dónde
se encuentra mi hijo en este momento?”.
En el primer caso, el servicio puede resolverse entre el Cliente que realizó la so-
licitud y el Servidor. En el segundo caso, el Servidor debe averiguar la posición
de un tercer actor para poder ejecutar satisfactoriamente el servicio.
1.2.2. Push
En un servicio de tipo Push, El Servidor envía al Cliente información de forma

asincrónica cuando ocurre un evento de interés. Este tipo de servicio responde a ne-
cesidades como: “Infórmeme todas las mañanas del clima local” o “Avíseme cuando
mi hijo llegue al aeropuerto”.
24
1.2.3. Tracking
Este tipo de servicio provee reportes constantes de la posición de un objetivo. De esta

forma se puede trazar su posición con respecto al tiempo. Un ejemplo sería: “monito-
reo de rutas de transporte público” o “localización de vehículo robado”.
Un LBS puede pertenecer a una o más de estas categorías. Por ejemplo, en un servicio
para redes sociales, un usuario podría ser notificado de la cercanía con sus amigos (push,
tracking), o podría solicitar información de cuantos de sus amigos han visitado el restau-
rante en que se encuentra en cierto momento (pull).
1.3. Sistemas de Información Geográfica (SIG)
Un Sistema de Información Geográfica (SIG) es un caso especial de un Sistema de In-

formación que tiene la capacidad de integrar datos espaciales y descriptivos
[MURP1995].
Un SIG puede entenderse también como un modelo computarizado que representa una
zona geográfica (real o imaginaria) con determinado grado de precisión por medio de un
sistema de coordenadas que permiten identificar cualquier punto de forma unívoca. Adi-
cionalmente, para cada punto puede almacenarse la información relacionada que se con-
sidere de interés dependiendo del uso que se dará al SIG.
Su potencial deviene de la posibilidad de relacionar la información en un contexto espa-

cial para después sacar conclusiones acerca de dicha relación.
1.4. Tecnologías de Localización (LCS)
Son las tecnologías que permiten obtener la información de localización geográfica del
dispositivo móvil.
En su forma más simple, el usuario mismo determina e introduce la información de posi-

ción en el dispositivo. Por ejemplo, se envía por medio de SMS un mensaje con el nom-
bre de cierto centro comercial. Unos segundos después, el usuario recibe un nuevo men-
Página 25

saje SMS con información sobre las promociones o eventos que se encuentran disponi-
bles en dicho centro comercial.
1.4.1. Triangulación de antenas
Según [ADUS2004], la más utilizada es la Observación de Diferencia de Tiempo Me-

jorada (Enhaced Observed Time Difference – EOTD) que hace parte del estándar
GSM. En este sistema, el dispositivo móvil envía una señal a la torre y espera una
respuesta. Como se conoce la velocidad a la cual se propagan las señales electro-
magnéticas, puede estimarse la distancia entre el dispositivo móvil y dicha antena. Si
se realiza el mismo procedimiento con tres antenas cuya posición geográfica se cono-
ce, se puede estimar la localización del dispositivo utilizando triangulación.
En muchos países, este servicio debe estar disponible obligatoriamente en cualquier

red de teléfonos celulares, ya que permite a las autoridades rastrear los aparatos en
caso de emergencia o secuestro. Sin embargo, no siempre están al servicio del públi-
co en general y son sumamente imprecisos.
1.4.2. Sistemas de localización satelitales
Actualmente solo existen tres de estos sistemas: ГЛОНАСС (sistema construido por
la extinta CCCP, parcialmente operativo en la actualidad), GALILEO (iniciativa eu-
ropea en desarrollo), y el Sistema de
Posicionamiento Global (Global Po-
sition System – GPS). Todos estos
sistemas operan bajo el mismo prin-
cipio:
Una constelación de satélites gira en

órbita alrededor de la Tierra, de for-
ma tal que siempre son “visibles” por
lo menos 6 de ellos desde cualquier
punto en su superficie.
26
El dispositivo móvil está equipado con un receptor que tiene la capacidad de captar la
señal que emiten constantemente los satélites.
Se realiza un proceso similar al de la

triangulación, pero en este caso en tres
dimensiones. En lugar de buscar el punto
de intersección entre tres circunferencias,
se busca la intersección entre tres esferas.
En realidad, existen dos puntos de inter-
sección, uno sobre la superficie de la
Tierra, y el otro en el espacio, muy por
encima de la órbita de los satélites. El
sistema GPS proporciona una precisión
de hasta 3 metros, y su señal está dispo-
nible para la población civil de forma gratuita.
Página 27

2. Transferencia inalámbrica de datos
La capacidad de transferir datos de forma inalámbrica es la base para la creación de redes

de dispositivos móviles. A continuación se expondrán las tecnologías más utilizadas en la
actualidad.
2.1. Redes telefónicas celulares
Las redes telefónicas celulares fueron inicialmente concebidas para prestar el servicio de
telefonía móvil pero han ido evolucionando hasta convertirse en redes de transferencia de
datos genéricos. Una red celular está conformada por cierto número de células que sub-
dividen y cubren un espacio geográfico determinado. Cada una de estas células está equi-
pada con transmisor-receptor fijo, conocido como estación base. Los dispositivos que de-
seen acceder a dicha red deben conectarse con la estación base correspondiente a la célula
en donde se encuentran en ese momento. Si un dispositivo se desplaza y cambia de célu-
la, también cambia de estación base de forma transparente para la aplicación que está uti-
lizando la conexión [TANE2003].
2.1.1. Evolución de las redes telefónicas celulares
Según la tecnología utilizada, las redes telefónicas se clasifican en generaciones:
 1G (Primera generación)
Sistemas de transferencia de voz analógicos.
 2G (Segunda generación)
Sistemas de transferencia de voz digitales. Soportan la transferencia de

paquetes de datos de forma limitada.
 3G (Tercera generación)
Sistemas de transferencia de voz y datos digitales. Permiten una co-

nexión de banda ancha para el envío y recepción de paquetes de datos.
28
 4G (Cuarta generación)
Estos sistemas se encuentran en su etapa de desarrollo, actualmente no

existe ninguna definición 4G. No diferenciarán entre la transmisión de
voz o de datos y estarán completamente basadas en IP.
2.1.2. Tecnologías de telefonía celular
Se indica al inicio de la descripción de cada tecnología la generación a la cual perte-

nece. En algunos casos, una tecnología se considera como una transición de una ge-
neración a otra. En este caso se utilizan indicaciones como (2.5G).
2.1.2.1. GSM (Global System for Mobile communications)
(2G) Este sistema es utilizado aproximadamente en el 80% de las redes celulares

a nivel mundial [GSMW2009]. Se trata del estándar utilizado en Colombia. En
GSM se utiliza la multiplexión por división de frecuencia, en el que cada disposi-
tivo móvil transmite en una frecuencia y recibe en una frecuencia mayor. Se uti-
liza multiplexión por división de tiempo para dividir un solo par de frecuencia en
ranuras de tiempo compartidas por múltiples teléfonos móviles.
2.1.2.2. CDMA (Code Division Multiple Access)
(2G) Se utiliza en Estados unidos y es completamente diferente a GSM, ya que

no divide el rango de frecuencia permitida en varios rangos estrechos, sino que
permite que cada estación transmita todo el tiempo a través de todo el espectro de
frecuencia. Los receptores utilizan filtros para aislar únicamente la información
que les interesa, mientras descartan todo lo demás como ruido aleatorio.
2.1.2.3. GPRS (General Packet Radio Service)
(2.5G) Se trata de una red de paquetes construida sobre GSM. Permite que las es-
taciones móviles envíen y reciban paquetes IP en una celda que se ejecuta en un
Página 29

sistema de voz. Cuando GPRS se encuentra en operación, algunas ranuras de

tiempo en algunas frecuencias se reservan para el tráfico de paquetes.
2.1.2.4. EDGE (Enhaced Data rates for GSM Evolution)
(2.5G - 3G) Es una red para el intercambio de paquetes construida sobre GSM. A
diferencia de GPRS, agrega bits extra por baudio que son utilizados para la
transmisión y recepción de los paquetes IP. Dependiendo de su implementación,
permite mayor o menor velocidad en la transmisión de datos. Por esta razón no
puede ubicarse específicamente en 2.5G o en 3G.
2.1.2.5. UMTS (Universal Mobile Telecommunications System)
(3G) También conocido como W-CDMA, no es una evolución de GSM pero

puede interactuar con ésta. Una celda CDMA puede entregar una llamada a una
celda GSM de ser necesario. En teoría, permite velocidades de hasta 2Mbps.
2.1.2.6. HSDPA
(3.5G) Existen varios sistemas de transición entre 3G y 4G. HSDPA se expone

aquí porque es el que ha sido escogido por Colombia. Se trata de la optimización
de UMTS/CDMA y su ancho de banda permite videoconferencias. La latencia en
este sistema es de alrededor de 100ms, lo cual permite aplicaciones requieran
tiempo real.
2.2. Redes inalámbricas no celulares
Estos sistemas fueron concebidos para proporcionar acceso inalámbrico a Internet.
2.2.1. WiFi (Wireless Fidelity)
Es un sistema de transferencia de paquetes de datos que utiliza ondas electromagnéti-

cas en lugar de cables. Está definida por el estándar IEEE 802.11 con el fin de emular
el comportamiento de las redes Ethernet (LAN) 802.3 pero inalámbricamente; por lo
30
tanto es completamente compatible con todos los servicios de éstas. Su cobertura

práctica es de aproximadamente 100mts.
2.2.2. WiMAX (Worldwide interoperability for Microwave Access)
Fue diseñada para brindar acceso a internet en zonas en las que la instalación de fi-
bra óptica no resulta rentable. Utiliza antenas transmisoras de microondas que en te-
oría pueden transmitir a velocidades de hasta 70Mbps. Está descrita en el estándar
IEEE 802.16.
Página 31

3. Protocolos de transferencia de datos
Se examinarán los principales mecanismos disponibles para la transferencia de datos desde y

hacia los dispositivos móviles.
3.1. SMS (Short Message Service)
Este sencillo sistema fue diseñado para la transferencia de alrededor de 160 caracteres de
7 bits desde un Servidor a un dispositivo o viceversa. Inicialmente hizo parte de la especi-
ficación de GSM, pero dada su gran popularidad las redes 3G actuales lo soportan.
Es muy fiable y hace uso eficiente de las transmisiones por radio, ya que está relacionado
estrechamente con el hardware del teléfono y la infraestructura de la red celular misma.
Como parte de las funcionalidades de bajo nivel de las diferentes plataformas, el progra-
mador tiene acceso a un API que le permite implementar aplicaciones que envíen y reci-
ban SMS para suplir sus necesidades de transferencia de datos. En el caso de Java ME,
este API está descrito en el documento jsr-120.
En el pasado, este mecanismo ha sido utilizado con éxito para la implementación de LBS
[GANG2004].
3.2. MMS (Multimedia Messaging System)
Gracias al aumento en la complejidad de la información manejada por los teléfonos celu-

lares (música, imágenes, videos) SMS resulta muy limitado en la actualidad. Por esta
razón se creó el estándar MMS con los mismos objetivos y estructura de SMS pero con
una carga útil de aproximadamente 300kb (según las capacidades del dispositivo y los
límites establecidos por el operador).
Al igual que en SMS, existen funcionalidades de bajo nivel que permiten a las aplicacio-
nes utilizar este sistema para el envío y recepción de datos.
32
3.3. WAP (Wireless Application Protocol)
Proporciona las especificaciones para un entorno de aplicaciones y una pila de protocolos

que pretenden estandarizar la forma como los dispositivos móviles acceden a contenido
de Internet, como correo electrónico y grupos de noticias. Su definición no especifica un
protocolo para la capa de transporte pero se implementa casi siempre sobre SMS o
GPRS.
Un navegador WAP provee todos los servicios básicos que proporciona un navegador
WEB pero simplificados para operar con recursos limitados. WAP Push permite hacer uso
de mensajes SMS o de paquetes enviados por GPRS para enviar un link a otro servicio
WAP y descargar datos adicionales.
3.4. BlackBerry Push
Se trata de un servicio que permite al Servidor enviar datos al Cliente de forma asincróni-
ca (Push) sin hacer uso de ninguna conexión específica. Es muy eficiente porque utiliza
una infraestructura basada en un hardware especial presente en los teléfonos y que los
operadores deben estar preparados para soportar. Los servicios BlackBerry mail y Black-
Berry Messenger que han dado fama a estos dispositivos están construidos utilizando esta
tecnología. Infortunadamente, este servicio solo funciona en teléfonos BlackBerry; el
operador debe realizar cambios en su infraestructura para soportarlo y el usuario tiene
que pagar por él.
3.5. IP (Internet Protocol)
A partir de GPRS existe la posibilidad de enviar datagramas IP tanto en UDP como en

TCP. Sin embargo, el envío y recepción de paquetes UDP por parte de teléfonos celulares
se encuentra frecuentemente restringido por los operadores de telefonía celular para evi-
tar el tráfico no autorizado de VOIP (Voz por IP). Las aplicaciones tienen acceso a la ca-
pa de transporte por medio de las funcionalidades de bajo nivel proporcionadas en el API
de cada plataforma. En el caso de Java ME, este API está descrito en el documento jsr-
197.
Página 33

III - PROCESO
1. Metodología Propuesta
En la propuesta original del presente Trabajo de Grado se planteó la siguiente metodología:
I. Exploración Previa
Durante esta etapa, se recopilará y clasificará información acerca de las diferentes

plataformas existentes para dispositivos móviles.
II. Análisis
Con los datos recopilados, se analizarán las plataformas disponibles más utilizadas;
sus fortalezas y debilidades en cuanto a la implementación de LBS.
III. Diseño de la Propuesta
Se hallará un subconjunto de funcionalidades de bajo nivel comunes en las platafor-

mas analizadas (manejo de puertos, interfaz con el hardware, etc.). Dichas funciona-
lidades se utilizarán para realizar una propuesta que permita implementar LBS de ti-
po pull, push y tracking.
IV. Diseño de la Arquitectura
Se diseñará una arquitectura acorde con la propuesta, de tal forma que proporcione
todas las funcionalidades extraídas en la fase anterior. Asimismo, se diseñará un LBS
básico que requiera para su implementación la utilización de las funcionalidades pull,
push y tracking, con el fin de probar la arquitectura a medida que es implementada.
V. Implementación
Se realizará la codificación del software asociado a la arquitectura, paralelamente se

desarrollará el LBS básico anteriormente descrito para validar las funcionalidades de
forma incremental.
34
2. Desarrollo del Proyecto
Durante el desarrollo del proyecto, la metodología propuesta resultó ser adecuada en las tres
primeras fases. Las fases IV y V se llevaron a cabo de forma ligeramente diferente.
A continuación se expondrá el trabajo realizado en cada una de las fases metodológicas.
I. Exploración previa
Durante esta fase de desarrollo fueron exploradas las plataformas para dispositivos
móviles y su relevancia actual en el mercado. Las plataformas consideradas fueron
Apple iPhone OS, Google Android, RIM Blackberry OS, Microsoft Windows Mobile,
y Symbian OS.
El marco teórico se complementó con los estándares de comunicación móvil que tra-
bajan con las plataformas anteriormente mencionadas: GSM, CDMA, GPRS, EDGE,
UMTS y HSDPA.
II. Análisis
Esta fase se centró en analizar cada plataforma para averiguar las facilidades que
proporciona al desarrollador para acceder a las funcionalidades de bajo nivel que son
necesarias para la implementación de servicios LBS de tipo pull, push y tracking.
Se consideró importante también la capacidad para ejecutar aplicaciones concurren-

temente así como varios hilos en cada aplicación.
En todas menos una de las plataformas consideradas (Apple iPhone OS) dichas fun-
cionalidades son fácilmente utilizables por el desarrollador.
III. Diseño de la propuesta
Tras analizar las funcionalidades de red de bajo nivel que otorga cada plataforma al
momento de implementar aplicaciones, se observó que todas permiten establecer co-
nexiones TCP por medio de sockets.
Página 35

Un socket TCP otorga:
 Comunicación full-dúplex.
 Envío y recepción de datos de forma asincrónica.
Las plataformas analizadas permiten la ejecución de varios hilos. Gracias a esto, pue-
de implementarse un mecanismo de espera para eventos asincrónicos.
La capacidad para enviar datos asincrónicamente permite la implementación de ope-

raciones de tipo pull. La posibilidad de recibir eventos asincrónicos es la base para
realizar operaciones de tipo push. Las operaciones de tracking pueden implementarse
al combinar operaciones pull y push, como se examinará detenidamente más adelan-
te.
En este punto de la metodología se concluyó que al considerar la información de po-

sición proveniente de un GPS o de cualquier otro LCS como un parámetro, entonces
un sistema que permita operaciones pull y push también permite la implementación
de LBS de tipo pull, push y tracking. Esta conclusión será analizada con más detalle
en la sección de resultados
De esta forma, se plantea una respuesta a la pregunta que motivó el presente Trabajo
de Grado:
¿Cómo lograr la implementación de servicios genéricos para dispositivos móviles

de tal forma que se utilicen eficientemente los recursos y sean independientes de la
plataforma de cada dispositivo?
R. “Por medio de un Middleware que permita la definición e implementación de ser-

vicios genéricos de tipo pull push y tracking independientes de la plataforma orien-
tado a dispositivos móviles”.
Con esta respuesta se procedió a diseñar el middleware y su protocolo asociado, des-

critos en el anexo 1.
36
IV. Diseño de la arquitectura
Dentro de los objetivos de este Trabajo de Grado se encuentra la implementación de

una aplicación de prueba para verificar la validez de la solución propuesta.
Como resultado del paso metodológico III: Diseño de la propuesta, se obtuvo el do-
cumento que especifica un middleware (Anexo 1).
Durante esta fase, se tomó dicho documento y se utilizó para diseñar una arquitectura
para ser implementada en el paso metodológico V.
Es importante aclarar que la arquitectura que se diseñó no está especificada en el do-

cumento de definición del middleware. Cualquier desarrollador que desee implemen-
tarlo es libre para diseñar su propia arquitectura, siempre y cuando su comportamien-
to se ajuste a lo especificado en el documento.
La arquitectura diseñada está descrita en el anexo 2.
V. Implementación
El middleware fue implementado con base en la arquitectura diseñada en el paso IV

en Java ME y Java SE haciendo uso de la metodología de desarrollo de software co-
nocida como Prototipo Incremental.
Dicha implementación se ejecutó satisfactoriamente en un computador de escritorio y

en los dispositivos móviles RIM Blackberry 8100 y HTC Google Android G1.
El middleware fue probado utilizando las tecnologías EDGE, WiFi y Ethernet (con-
currentemente), con resultados igualmente positivos.
Una vez probado el middleware, éste se utilizó para diseñar un servicio que requiere
la utilización de las funcionalidades Pull, Push y Tracking necesarias para cumplir
con los objetivos de este Trabajo de Grado.
Página 37

3. Reflexión metodológica
Como se mencionó anteriormente, la metodología propuesta fue apropiada para el desarrollo

del proyecto durante las fases I, II y III. En las fases IV y V se introdujeron cambios para
ajustarlas a las necesidades según el contexto, los cuales se exponen a continuación:
IV. Diseño de la arquitectura
a) Propuesta metodológica original
Se diseñará una arquitectura acorde con la propuesta, de tal forma que proporcio-
ne todas las funcionalidades extraídas en la fase anterior. Asimismo, se diseñará
un LBS básico que requiera para su implementación la utilización de las funcio-
nalidades Pull, Push y Tracking con el fin de probar la arquitectura a medida que
es implementada.
b) Ejecución ajustada
Se diseñó una arquitectura con la propuesta, de tal forma que proporcionaba to-
das las funcionalidades extraídas en la fase anterior. Se aplazó el diseño del ser-
vicio LBS de prueba para la fase de implementación.
c) Justificación
Se consideró que el servicio de prueba era completamente independiente de la

arquitectura; su única función era validarla cuando ya se encontrara implementa-
da. Por esta razón su especificación correspondía a la fase de pruebas.
38
V. Implementación
d) Propuesta metodológica original
Se realizará la codificación del software asociado a la arquitectura, paralelamente

se desarrollará el LBS básico anteriormente descrito para validar las funcionali-
dades de forma incremental.
e) Ejecución ajustada
Se realizó la codificación del software asociado a la arquitectura. Las funciona-

lidades genéricas Pull y Push fueron implementadas sucesivamente. Una vez
operativo el middleware, se utilizó para desarrollar servicios específicos para
pruebas de rendimiento y un servicio de demostración.
f) Justificación
Diseñar previamente un servicio para ser desarrollado de forma paralela con el

middleware añade las complejidades características de dicho servicio a la ya
compleja implementación de la arquitectura. Se decidió entonces reducir el servi-
cio a su mínima expresión: Las funcionalidades básicas Pull y Push. Una vez
probadas, se puede diseñar e implementar cualquier servicio para validar y de-
mostrar el middleware.
El desempeño de los sockets TCP sobre la red de telefonía celular se desconocía.

Por esta razón, el middleware desarrollado se empleó para implementar servicios
de prueba que permitieron medir los valores de latencia y glitter de dicha tecno-
logía.
Página 39

Reflexión sobre la metodología Prototipo Incremental
La metodología de desarrollo de software Prototipo Incremental resultó adecuada pa-

ra el desarrollo del middleware, ya que permitió obtener prototipos funcionales desde
el principio del proceso. Gracias a esto, varios problemas inherentes a la programa-
ción de dispositivos móviles emergieron en una etapa temprana y fueron soluciona-
dos primero. De esta forma se consiguió la separación entre los problemas técnicos y
los bugs del middleware, lo cual facilitó enormemente el proceso de depuración.
La principal desventaja consistió en la necesidad de refactorizar el código en sucesi-

vas iteraciones, ya que para obtener prototipos funcionales de forma rápida fue nece-
saria la escritura de código provisional que más tarde tuvo que ser mejorado o rees-
crito, como es típico en Prototipo Incremental. Sin embargo, a partir de la experien-
cia con este trabajo, el desarrollador considera que el esfuerzo y tiempo invertidos en
refactorizar el código no son comparables con el gran trabajo que habría supuesto la
depuración de una gran cantidad de módulos complejos desarrollados por separado y
probados en conjunto al final de la etapa de implementación.
40
IV - RESULTADOS
En esta sección se consignan los resultados que fueron obtenidos durante el desarrollo de este
Trabajo de Grado. El orden de aparición corresponde con el orden de ejecución.
1. Exploración sobre las plataformas para Dispositivos móviles
1.1. Plataformas más relevantes
Las plataformas para dispositivos móviles que presentan mayor relevancia en la actuali-
dad [MCCR2009], [YUNC2007] son: Google Android OS, RIM BlackBerry OS, Micro-
soft Windows Mobile, Symbian OS e iPhone OS. A continuación un resumen de cada una
desde el punto de vista del desarrollador de aplicaciones.
1.1.1. Google Android OS
Se trata de un sistema operativo de código abierto

desarrollado por Google que busca ser fácilmente
adaptable a las necesidades de cada fabricante de
dispositivos. El usuario puede interactuar con el
sistema por medio de una pantalla sensible al tacto o
un trackball.
La base de este sistema es un kernel de Linux, que

ejecuta a su vez varias máquinas virtuales Java para
las aplicaciones del teléfono. Cada aplicación corre
sobre su propia instancia de máquina virtual, y cada
máquina virtual es un proceso en el sistema operativo.
Sorprendentemente, esta plataforma no utiliza el estándar Java ME. Implementa la

mayoría del estándar Java SE complementado con un API desarrollado especialmente
para Android que permite al desarrollador un control muy profundo del sistema.
Página 41

Android proporciona un emulador, un SDK, y un plugin de Eclipse para facilitar la

implementación de aplicaciones. Las operaciones de depuración pueden realizarse en
los dispositivos reales si así se desea e incluso existe un dispositivo especialmente di-
señado para ello (Android Developer Phone).
1.1.2. RIM BlackBerry OS
Es el sistema operativo utilizado

por todos los dispositivos BlackBe-
rry fabricados por la compañía ca-
nadiense Research in Motion
(RIM). Su interfaz ha cambiado
muy poco en los últimos diez años,
ya que siempre ha sido muy funcio-
nal, lógica y consistente. En la ma-
yoría de los modelos, todas las ope-
raciones se realizan gracias a un trackball, a un botón menu y un botón back.
Las aplicaciones en esta plataforma se desarrollan utilizando Java ME. El programa-

dor tiene acceso a las funcionalidades de red de bajo nivel proporcionadas por dicho
estándar además de un API para el manejo de la interfaz y las características particu-
lares de estos dispositivos.
RIM pone a disposición de los programadores un IDE propio, un plugin para Eclipse
y un emulador para cada uno de sus dispositivos. El IDE puede enlazarse con un dis-
positivo real por medio del puerto USB para realizar la depuración paso a paso.
42
1.1.3. Microsoft Windows Mobile
Windows Mobile es la versión móvil del sistema

operativo Windows. Intenta emular su interfaz al
incluir un botón de inicio y una barra de tareas.
Esto resulta poco práctico, ya que las pantallas
reducidas pueden dificultar la visualización de
íconos tan pequeños.
El código de este sistema operativo es completa-

mente cerrado. Sin embargo, los desarrolladores
pueden utilizar el API .net Mobile y el entorno de
desarrollo Visual Studio que es muy completo y
permite el acceso a las funcionalidades de red de
bajo nivel del dispositivo, aunque su licencia no es totalmente abierta.
Esta plataforma ha perdido la gran popularidad que disfrutaba hace algunos años de-
bido a las malas políticas de mercadeo de Microsoft [SEGA2009].
1.1.4. Symbian
Este sistema operativo es utilizado en dispositi-

vos fabricados por Motorola, Nokia, Samsung,
Siemens, y Sony Ericsson. Data de una época en
la que toda la interfaz de usuario se reducía a un
teclado alfanumérico y unos pocos botones adi-
cionales. Las nuevas características como panta-
llas sensibles al tacto no están muy bien sopor-
tadas.
Diseñado especialmente para procesadores

ARM, su estructura está basada en un microkernel que contiene las unidades básicas
del sistema operativo: planificador, administrador de memoria y drivers de dispositi-
Página 43

vo. Las aplicaciones pueden compilarse y ejecutarse en código de máquina, o correr

en una máquina virtual de Java.
El programador puede desarrollar aplicaciones para Symbian haciendo uso del com-
pilador de C++ que está disponible de forma gratuita, o de un SDK para Java ME.
Dependiendo del fabricante, existen diferentes emuladores para dispositivos que uti-
lizan Symbian. Una aplicación implementada haciendo uso de cualquiera de estas
herramientas tiene acceso a las funcionalidades de red de bajo nivel del dispositivo.
1.1.5. Apple iPhone OS
En la actualidad, solo los dispositivos iPhone e iPod

Touch utilizan este sistema operativo. Es una versión
reducida de Mac OS con gran énfasis en gráficas 3D de
alta velocidad, lo cual le permite soportar la pesada y
compleja interfaz de usuario que utiliza casi exclusi-
vamente una pantalla sensible al tacto y varios ace-
lerómetros que pueden detectar cambios en la posición
e inclinación del dispositivo.
Uno de los principales objetivos de Apple al desarrollar

este sistema es la velocidad de respuesta de las aplica-
ciones. Por esta razón todas deben ser compiladas a código de máquina y está expre-
samente prohibida la instalación de una máquina virtual (como la necesaria para eje-
cutar Java) o un compilador en tiempo de ejecución (como el utilizado por .net).
Aunque el SDK se puede descargar gratis, el desarrollador debe pagar para obtener
las firmas digitales que necesita para instalar su aplicación en un dispositivo real.
(Existen modificaciones no autorizadas de hardware que permiten instalar aplicacio-
nes no firmadas). Solo Apple puede desarrollar aplicaciones que se ejecuten concu-
rrentemente, y el acceso a las funcionalidades de red de bajo nivel está muy limitado.
44
1.2. Resultado del estudio de las plataformas
Después de estudiar cada plataforma, se obtuvieron los siguientes resultados considera-

dos relevantes para este Trabajo de Grado:
a) A excepción de Apple iPhone OS, todas las plataformas proporcionan las herra-
mientas y documentación necesarias para el desarrollo de aplicaciones de forma
gratuita y abierta.
b) RIM BlackBerry OS, Symbian OS soportan la tecnología Java ME, mientras que
Google Android OS se basa en Java SE.
c) A excepción de Apple iPhone OS, todas las plataformas permiten que las aplica-
ciones desarrolladas tengan acceso a las funcionalidades de red de bajo nivel de
los dispositivos.
d) A excepción de Apple iPhone OS, todas las plataformas permiten la ejecución
concurrente de varias aplicaciones, al mismo tiempo que el uso de diferentes
threads por cada aplicación.
Teniendo en cuenta estos resultados, se concluye lo siguiente:
a) El sistema operativo Apple iPhone OS no se tendrá en cuenta a la hora de diseñar

la solución, dado que las políticas de Apple no permiten el desarrollo de ninguna
aplicación compleja por parte de terceros.
b) La arquitectura diseñada se implementará en este Trabajo de Grado utilizando
Java ME y Java SE, ya que de esta forma quedarán cubiertas las plataformas
BlackBerry OS, Google Android OS y Symbian OS.
c) La solución propuesta debe estar diseñada de tal forma que en trabajos futuros
pueda ser implementada en plataformas diferentes a Java ME y Java SE.
Página 45

2. Propuesta para la implementación de LBS
En esta sección se exponen las funcionalidades básicas propuestas para la implementación de

LBS en cada una de sus modalidades.
2.1. Propuesta de operaciones básicas en los LBS
La solución a proponer debe tener la capacidad de implementar LBS en todas sus modali-
dades (Marco Teórico, secc. 2.1) o en cualquier combinación de las mismas. Para este
propósito se halló un conjunto de operaciones básicas que ejecutadas en un determinado
orden exhiben el comportamiento descrito. Este Trabajo de Grado propone dos operacio-
nes básicas genéricas: Invocación de Método Remoto y Generación de Evento Asincró-
nico.
2.1.1. Invocación de Método Remoto (Pull)
La ejecución de un método remoto se desencadena cuando es solicitada por el Clien-

te. De esta forma, una aplicación decide cuando los servicios son invocados. La Invo-
cación de Método Remoto se subdivide en:
 El Cliente envía una solicitud compuesta por un nombre de método y una se-
rie de parámetros.
 El Servidor ejecuta un método con los parámetros proporcionados y genera
un resultado.
 El Servidor envía el resultado al Cliente.
Si se produce un error al invocar un método, o si por alguna razón dicho método no

se puede ejecutar, el resultado recibido por el cliente es una notificación de fallo (Ex-
cepción).
2.1.2. Generación de Evento Asincrónico (Push)
Un evento asincrónico es generado por el Servidor en el Cliente cuando ocurre un

suceso que el Cliente está interesado en conocer. Se subdivide en:
46
 El Servidor determina que ha ocurrido un suceso y un determinado Cliente

debe ser informado.
 El Servidor envía una notificación al Cliente compuesta por un nombre de
evento y una serie de parámetros.
Un evento es asincrónico porque el Cliente no puede determinar con exactitud cuán-

do ocurrirá.
2.2. Implementación de los diferentes tipos de LBS por medio de Invocación

de Método Remoto y Generación de Evento Asincrónico
Una vez definidas las operaciones básicas Invocación de Método Remoto y Generación
de Evento Asincrónico, se expone cómo estas pueden combinarse para implementar cada
tipo de servicio LBS.
2.2.1. Implementación de LBS tipo Pull
Según (Marco Teórico, secc. 2.1), existen dos subtipos de LBS de tipo Pull:
a) Cuando el servicio Pull requiere la posición del solicitante:
En este caso, el Cliente realiza una Invocación de Método Remoto y envía como
parámetro su propia posición. Si dicha posición no se puede determinar o
Página 47

aproximar, el método no puede ser invocado. Si el método se ejecuta satisfacto-

riamente, el Servidor retorna al Cliente un resultado, si no, se retorna un error.
b) El servicio Pull requiere la posición de otro dispositivo:
El Cliente realiza una Invocación de Método Remoto. El Servidor necesita la po-

sición de otro dispositivo para ejecutar el método. La posición de este tercer ac-
tor puede determinarse de dos formas:
i. El Servidor interroga al cliente: El Servidor genera un Evento

Asincrónico en un Cliente para notificarle que su posición es reque-
rida. Seguidamente, el Cliente responde por medio de una Invoca-
ción de Método Remoto con su posición como parámetro.
48
ii. El Cliente anuncia periódicamente su posición: Si resulta más efi-

ciente debido a la naturaleza del servicio que se está implementando,
un Cliente podría realizar una Invocación de Método Remoto en for-
ma regular para indicar al Servidor su posición actual o un cambio en
la misma. Así, cuando el Servidor requiere una posición determinada
consulta el registro de posiciones más actualizado en vez de interro-
gar a los dispositivos.
Si no puede hallarse la posición, el método no puede ejecutarse y el Servidor re-

torna un error.
2.2.2. Implementación de LBS tipo Push
El Servidor utiliza una Generación de Evento Asincrónico en el Cliente con una serie
de parámetros para notificar que cierto suceso ha ocurrido.
2.2.3. Implementación de LBS tipo Tracking
En un LBS de tipo Tracking, se utiliza un reporte periódico de la posición de un dis-

positivo móvil en particular para trazar una ruta en el tiempo. Esto puede lograrse uti-
Página 49

lizando una combinación de Invocación de Método Remoto y Generación de Evento

Asincrónico, así:
a) Los dispositivos que están siendo monitoreados realizan una Invocación de

Método Remoto para indicar su posición periódicamente o lo hacen para in-
dicar un cambio en la misma.
b) Los Clientes interesados en conocer la posición de otro u otros dispositivos
en tiempo real reciben Eventos Asincrónicos desde el Servidor cada vez que
está disponible nueva información de posición de los dispositivos monitorea-
dos.
El tiempo real se encuentra limitado por las propiedades de latencia y glitter de la red
que se utilice para la transmisión de los datos.
2.3. La información de posición como parámetro
En los LBS, se conoce como información de posición al conjunto de datos que permite
ubicar un punto sobre el planeta de forma unívoca. Dependiendo del LCS que se esté uti-
lizando, esta información puede estar complementada con datos como orientación, velo-
cidad y altura sobre la superficie. En todo caso, la información de posición consistirá en
una tupla de datos de algún tipo, muy probablemente numérico. Esta tupla puede consi-
derarse como un parámetro (o una serie de parámetros) que puede ser enviado al realizar
una Invocación de Método Remoto o una Generación de Evento Asincrónico.
Es importante recalcar que: una Invocación a Método Remoto o una Generación de

Evento Asincrónico no necesariamente requiere de la información de posición para
llevarse a cabo.
Como ejemplo, el Cliente puede interrogar al Servidor acerca del valor de una acción en
determinado momento. O el Servidor puede notificar asincrónicamente a un Cliente que
una acción a alcanzado un valor crítico y debe vender. Ninguno de estas operaciones re-
quiere la información de posición.
50
2.4. Resultados del estudio sobre la implementación de LBS
Después de estudiar los diferentes tipos de LBS y su implementación, se obtuvieron los

siguientes resultados considerados relevantes para este Trabajo de Grado:
a) Las operaciones básicas Invocación de Método Remoto y Generación de Even-

to Asincrónico son suficientes para la implementación de un LBS en cual-
quiera de sus modalidades.
b) La información de posición puede considerarse como un parámetro más al mo-
mento de ejecutar cualquiera de las operaciones básicas.
a) Si la solución incluye un mecanismo para la implementación de las operaciones

básicas Invocación de Método Remoto y Generación de Evento Asincrónico, en-
tonces tendrá la capacidad para implementar cualquier LBS y cumplir así con el
principal objetivo del presente Trabajo de Grado.
b) Si la solución puede utilizarse para implementar cualquier LBS, entonces también
podrá emplearse para implementar servicios que no sean LBS, es decir, que no
requieran de la información de posición para su funcionamiento.
Página 51

3. Estudio de las características técnicas de la Solución
Con los resultados obtenidos anteriormente, se procedió a hallar las características técnicas
más adecuadas para una solución que permita la implementación de las operaciones básicas
Invocación a Método Remoto y Generación de Evento Asincrónico.
3.1. Comparación entre los diferentes mecanismos de transferencia de datos
En (fig. 9) se comparan los diferentes mecanismos para la transferencia de datos entre

dispositivos móviles (Marco Teórico secc. 3) por medio de la siguiente lista de criterios:
 Disponibilidad: El mecanismo está disponible en una gran variedad de dispositi-

vos móviles.
 Interoperabilidad: Las diferentes plataformas lo implementan, por esto pueden
utilizarlo para interactuar entre ellas.
 Capacidad de Pull: Tiene el potencial para implementar la operación básica In-
vocación de Método Remoto anteriormente definida.
 Capacidad de Push: Tiene el potencial para implementar la operación básica
Generación de Método Asincrónico anteriormente definida.
 Latencia: El tiempo que le toma al Cliente enviar un mensaje al Servidor y vice-
versa.
 Ancho de banda: El tamaño de los parámetros que pueden enviarse del Cliente
al Servidor y viceversa.
52
1) Solo está disponible en las redes de telefonía celular; para interactuar con Internet
se requieren adaptadores.
2) WAP puede visualizar contenido de Internet, pero necesita un adaptador interme-
dio que interprete y transforme los datos.
3) La definición de Invocación de Método Remoto requiere la capacidad de generar
un retorno como parte de la misma transacción. En este caso es necesario generar
un Evento Asincrónico aparte para enviar al Cliente el resultado de la invocación.
4) La latencia depende mucho de la configuración del operador y la congestión ac-
tual de la red. Puede ser de algunos segundos, y en ocasiones, minutos.
5) Entre 800ms y 2000ms.
6) [ARZU2008] 500ms-2000ms, GPRS; 500ms-1000ms, EDGE; ~200ms, UMTS;
~100ms, HSDPA.
7) GPRS es práctico hasta ~500kb, dependiendo de la configuración del operador y
la cobertura. EDGE, UMTS son útiles hasta decenas de Mb (Sin embargo, un
dispositivo móvil en general no descarga o envía archivos de ese tamaño).
HSDPA puede manejar voz y video en tiempo real.
Página 53

3.2. Resultados de la comparación entre los diferentes mecanismos de trans-

ferencia de datos para dispositivos móviles
Después de estudiar y comparar los diferentes mecanismos de transferencia de datos dis-

ponibles para dispositivos móviles, se llegó a los siguientes resultados, considerados re-
levantes para el presente Trabajo de Grado:
a) Los sistemas SMS, MMS y WAP han sido utilizados satisfactoriamente en el pa-
sado para la construcción de LBS, y tienen el potencial para la implementación de
las operaciones básicas Invocación de Método Remoto y Generación de Evento
Asincrónico.
b) Los sistemas SMS, MMS, y WAP son prácticamente universales, todas las plata-
formas para dispositivos móviles soportan los protocolos estandarizados.
c) Los sistemas SMS, MMS, y WAP están estrechamente ligados con las redes de te-
lefonía celular, y no hacen parte de la pila de protocolos de IP.
d) La latencia de los sistemas SMS, MMS y WAP tiende a ser muy alta e impredeci-
ble.
e) El sistema BlackBerry Push es muy eficiente, pero solo está disponible para dis-
positivos BlackBerry y es necesario pagar por su utilización.
f) Los protocolos TCP/IP y UDP/IP están soportados por las tecnologías GPRS,
EDGE, UMTS, HSDPA.
g) El protocolo UDP es de uso restringido en muchas redes de telefonía celular.
a) A pesar de su universalidad, los sistemas de transferencia de datos SMS, MMS y

WAP no se utilizarán para diseñar la solución, ya que su interoperabilidad con
Internet necesita desarrollos adicionales y su latencia es muy alta.
b) El protocolo UDP/IP es muy eficiente pero será descartado, ya que los operado-
res de redes celulares restringen su uso.
c) El protocolo TCP/IP será el utilizado para el diseño de la solución en este
Trabajo de Grado.
54
3.3. Formato de datos
Es necesario establecer el formato que se utilizará a la hora de transmitir los datos utili-
zando el protocolo seleccionado (TCP/IP). Para esto existen dos posibilidades: transfe-
rencia binaria y transferencia de texto.
3.3.1. Transferencia binaria
La carga útil consiste en un arreglo de bytes. Es muy eficiente, ya que un solo byte
proporciona 255 estados u 8 banderas, lo cual permite enviar toda la información del
sistema (tipo de comando, errores, etc.) utilizando unos pocos bytes.
La eficiencia también se manifiesta durante la transferencia de los parámetros. Por

ejemplo, un entero desde -2147483647 hasta +2147483647 puede representarse en
forma binaria con solo 4 bytes.
Sin embargo, la trama resultante resulta ilegible para un humano y su implementa-

ción muy estricta; basada en las posiciones de los bytes de tal forma que es difícil in-
troducir cambios posteriores. Algunas combinaciones de bits corresponden a caracte-
res especiales que pueden ser interpretados de diferentes formas por diferentes siste-
mas generando errores en la transmisión y dificultades de interoperabilidad.
3.3.2. Transferencia de texto
Los datos se transfieren de forma alfanumérica. Por ejemplo, el entero 2057303431

se transmite como “2057303431” (10 bytes). En forma binaria se transmitiría como
01111010 10011111 11110101 10000111 = “zƒ§ç” (4 bytes). Los comandos e indi-
cadores del sistema también deben ser representados por varios caracteres, lo cual
aumenta el tamaño de la trama.
Al transmitir de esta forma puede hacerse uso del formato XML que evita la presencia
de caracteres especiales y por lo tanto los potenciales problemas de interoperabilidad,
al mismo tiempo que las tramas se hacen legibles para los humanos facilitando así el
trabajo de depuración.
Página 55

3.4. Resultados del estudio de los posibles formatos de datos
Después de estudiar los formatos de transferencia binario y de texto, se concluye lo si-

guiente:
a) El formato de transferencia binaria no se utilizará dados los posibles problemas

de interoperabilidad y su inflexibilidad a la hora de introducir cambios posterio-
res.
b) La solución utilizará el formato de transferencia de texto y el Lenguaje de
Marcas Extensible (XML) porque de esta forma se alcanza el objetivo de In-
teroperabilidad en el presente Trabajo de Grado.
56
4. Propuesta de Solución
Una vez halladas las características generales que debe implementar la Solución, se procede a
diseñar una propuesta para la misma.
4.1. Compilación de las características de la Solución
En las secciones anteriores se hallaron las características que debe tener la Solución pro-
puesta para satisfacer todos los objetivos del presente Trabajo de Grado. Estas caracterís-
ticas son:
a) La solución debe ser implementable en todas las plataformas estudiadas a excep-

ción de Apple iPhone OS.
b) La solución debe tener la capacidad de realizar las operaciones básicas Invoca-
ción de Método Remoto y Generación de Evento asincrónico tal como fueron
definidas en la sección (Resultados, secc. 2.2.) de este documento.
c) La solución debe utilizar el protocolo TCP/IP para el transporte de datos.
d) Los datos serán transmitidos en formato texto por medio del Lenguaje de Marcas
Extensible XML.
4.2. El Middleware “OMNI”
Para satisfacer las características anteriormente mencionadas se inició un proyecto de de-

sarrollo de software cuyo objetivo es la especificación y desarrollo de un Middleware pa-
ra la implementación de servicios genéricos orientado a dispositivos móviles. A tal pro-
yecto y a su Middleware asociado se les dio el nombre de “OMNI”.
El documento de especificación tiene como fin dar a los desarrolladores toda la informa-
ción necesaria para implementar el Middleware en una plataforma determinada de tal
forma que pueda interactuar con otras implementaciones del mismo. Por esta razón, la
especificación del Middleware es completamente independiente de la plataforma. Este
documento puede encontrarse en el anexo 1.
Página 57

Se expondrá a continuación de manera global la estructura y funcionamiento del Middle-

ware OMNI.
4.3. El Redirector y el Servidor OMNI
La estructura de un servicio OMNI contempla dos servidores: el Redirector OMNI, que

actúa como un registro y el Servidor OMNI, en donde se encuentra el servicio propia-
mente dicho. Los Clientes conocen la IP o el host del Redirector; se conectarán a él para
averiguar el host del Servidor OMNI que aloja el servicio deseado. (fig. 10).
4.4. Sesión OMNI
Cuando un Cliente ha obtenido la dirección IP o el host del Servidor OMNI, establece

una conexión y negocia una sesión. Esta sesión se desarrolla sobre una conexión TCP
full-dúplex que se mantiene abierta mientras dure la sesión y se multiplexa para enviar las
solicitudes de Ejecución de Método Remoto y recibir las notificaciones de Evento
Asincrónico al mismo tiempo. El Middleware envía además otras tramas para control in-
terno, pero de forma transparente para la aplicación.
58
Al momento de iniciar sesión, el Cliente debe declarar qué tipo de dispositivo intenta co-
nectarse. Esto podría utilizarse en un futuro con fines estadísticos o para dar trato prefe-
rencial a ciertos dispositivos según su tipo:
 Desktop: Computador de escritorio o portátil.

 SmartPhone: Teléfono celular con capacidades superiores.
 HandHeld: Computador de bolsillo.
 LimitedPhone: Teléfono celular con capacidades muy inferiores.
 EmbeddedDevice: Dispositivo embebido. (máquinas, sistemas de rastreo, siste-
mas basados en microcontroladores en general).
 CriticalDevice: Dispositivo utilizado para el monitoreo de pacientes a distancia,
sistemas de de seguridad, aplicaciones para la bolsa de valores.
 ExperimentalDevice: Dispositivo experimental o en desarrollo.
Seguidamente, el Cliente recibe una cadena de caracteres de hasta 128 bytes correspon-
diente al valor de la variable de sistema connectionID. Esta variable identifica unívoca-
mente la sesión.
4.5. Tipos de datos en OMNI
La versión del Middleware que será entregada soporta los siguientes tipos básicos de da-
to:
 Entero con signo de 32 bits, (int).

 Real con signo, (double).
 Booleano, (boolean).
 Cadena de caracteres (string).
 Arreglos de los tipos de datos anteriores.(int[], double[], etc.).
Internamente se utilizan los tipos Estructura de datos y Arreglo recursivo.
Página 59

4.6. Excepciones OMNI
El Middleware define dos clases de excepciones: Excepciones de Sistema y Excepciones

de Servicio. Una Excepción de Sistema se lanza cuando el error que ha ocurrido ha sido
generado por la conexión o por el Middleware. Una Excepción de Servicio ocurre cuando
un Método Remoto invocado genera una excepción. Existe una lista de las posibles Ex-
cepciones de Sistema (presente en la defininición del Middleware), mientras que el pro-
gramador de un Servicio es libre de diseñar sus propias Excepciones de Servicio defi-
niéndolas así:
a) Un número entero (int) que identifica la excepción.

b) Una cadena de caracteres (String) que describe la excepción.
El desarrollador puede definir cualquier número (32 bytes) de Excepciones de Servicio.
4.7. Servicios OMNI
Un servicio en OMNI se define como:
 Una interfaz implementada por el Cliente con una serie de Eventos Asincrónicos.
 Una interfaz implementada por el Servidor con una serie de Métodos Remotos
que retornan un valor o lanzan una Excepción de Servicio.
 Una interfaz implementada por el Servidor con una serie de Eventos Asincróni-
cos.
 Un nombre de servicio.
60
En (fig. 11) puede verse un ejemplo de la Interfaz de Eventos Asincrónicos del lado del
Cliente en un hipotético servicio de Chat, tal como se vería al utilizar el Middleware en
Java ME que se entrega como parte de este Trabajo de Grado:
Figura 11. (Ejemplo de interfaz OMNI para el Servidor)
import co.edu.javeriana.lbs.omni.io.ConnectionException;
import co.edu.javeriana.lbs.omni.service.PushListener;
public interface chatPushListener extends PushListener

{
public void mensajeRecibido(String remitente, String mensaje)
throws ConnectionException;
public void UsuarioCerca(int id, double longitud, double latitud)
public void usuarioConectado(String nombreUsuario, int id)
}
En (fig. 12) puede verse un ejemplo de la interfaz de Métodos Remotos y Eventos

Asincrónicos que implementaría el Servidor en un hipotético servicio de Chat.
Figura 12. (Ejemplo de interfaz OMNI para el Cliente)
import co.edu.javeriana.lbs.omni.service.PullServices;
public interface chatPullServices extends PullServices

{
//Eventos asincronicos:
public void actualizarPosicion(int id, double longitud, double latitud)
public void enviarMensaje(int idRemitente, int idDestino, String mensaje)
//Metodos remotos:
public String[] getListaContactos()
public double[] getPosicionUsuario(int idUsuarioUbicar)
}
Página 61

4.8. OMNI Middleware Protocol
El protocolo utilizado por el Middleware OMNI está basado en el estándar XML-RPC

[WINE2003] y añade al mismo la capacidad de enviar eventos asincrónicos del Servidor
al Cliente. Su especificación puede encontrarse en el anexo 1. Se proporcionan a conti-
nuación ejemplos de las tramas utilizadas durante su operación.
En (fig. 13) se muestra un

Figura 13, Generación de evento Asincrónico.
ejemplo de la trama en-
<?xml version="1.0"?>
<generateEvent>
viada por el Servidor para
<eventName>chat.push.event.usuarioCerca</eventName>
<params> generar Eventos Asincró-
<param>
<value> nicos en el Cliente para
<array>
<data> un servicio hipotético de
<value><int>65432</int></value>
<value><double>35.89685</double></value> Chat.
<value><string>6.45871</string></value>
</data>
</array>
</value>
</param>
</params>
</generateEvent>
62
(fig. 14) presenta un ejemplo de la trama enviada por el Cliente al Servidor para solicitar
la ejecución de un Método Remoto y las posibles respuestas del Servidor (Valor de Re-
torno o Excepción) en un servicio hipotético de Chat.
Figura 14 Invocación de Método Remoto.

-Invocación del Cliente:
<methodCall>
<methodName>chat.pull.method.getPosicionUsuario</methodName>
<params>
<param>
<value>
<array><data>
</data></array>
</value>
</param>
</params>
</methodCall>
-Respuesta del Servidor (Éxito):
<methodResponse>
<params>
<param>
<value>
<array><data>
<value><double>54.4578</double></value>
<value><double>34.5761</double></value>
</data></array>
</param>
</params>
</methodResponse>
-Respuesta del Servidor (Fallo):
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
</member>
<member>
<name>faultString</name>
<value><string>The service has generated an exception.</string></value>
</member>
<member>
<name>serviceErrorCode</name>
</member>
<member>
<name>serviceErrorDescription</name>
<value><string>EL USUARIO NO EXISTE!</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
Página 63

5. Implementación
Tras definir una solución, el siguiente paso consiste en validar su funcionalidad. Con este fin
se diseñó una arquitectura adecuada para la implementación del Middleware OMNI en Java
ME y Java SE tal como se especifica en (Resultados secc. 1.2). La arquitectura puede consul-
tarse en el anexo 2; la documentación en el anexo 3.
5.1. Arquitectura
OMNI es un Middleware basado en una arquitectura Cliente-Servidor. Se trata de

una capa que sirve de intermediario entre la aplicación y la capa de transporte, de
forma que el flujo de datos codificados en XML a través de la red es completa-
mente transparente para las implementaciones del Cliente y del Servidor.
5.2. Componentes
La arquitectura comprende seis componentes principales: Redirector OMNI, Servidor

OMNI, Cliente OMNI, Generador de Stubs, Parser XML y Módulo de Compatibilidad.
64
5.2.1. Redirector OMNI
Se trata de un servidor que espera continuamente la conexión de Clientes OMNI para

redireccionarlos al servidor que presta el servicio solicitado. El puerto por el cual se
realiza la conexión no se especifica; el administrador puede escoger la configuración
que más le convenga.
Es la puerta de entrada a los Servicios OMNI. Cuando una aplicación desea acceder a
un servicio, se conecta con el Redirector para obtener su dirección IP o host. El redi-
rector puede utilizarse para realizar balanceo de carga u operaciones de mantenimien-
to en los servidores que prestan el Servicio OMNI.
5.2.2. Servidor OMNI
Este servidor tiene la capacidad de manejar concurrentemente la sesión OMNI de un

cierto número de Clientes OMNI (dependiendo de la configuración y las capacidades
de la máquina). El puerto por el cual se realiza la conexión no está especificado.
Una vez obtenido el host, el Cliente se conecta con el Servidor OMNI e inicia una se-
sión. A partir de ese momento, puede invocar los Métodos Remotos o recibir los
Eventos asincrónicos que hacen parte del Servicio. El Servidor puede a su vez servir
como puente para otros sistemas, como invocación SOAP o webServices.
5.2.3. Cliente OMNI
El Cliente OMNI es la parte del Middleware presente en el Cliente, entre la

aplicación y la capa de transporte. Se encarga de la transmisión y recepción
de datos de tal forma que resulte transparente para la aplicación.
De forma transparente para la aplicación, realiza operaciones orientadas a la

conservación y restablecimiento de la conexión con el Servidor OMNI:
 PING: El Cliente envía un paquete al Servidor cuando ha transcurrido

cierto tiempo (determinado por la configuración) sin que se le haya no-
Página 65

tificado un Evento Asincrónico o haya recibido un Retorno de Método.

De esta forma, puede verificarse si la conexión continúa abierta.
 Restablecimiento de conexión: Si por alguna razón la conexión se
pierde, el Cliente intentará restablecerla y continuar con la sesión. Si
tras cierto número de intentos (determinado por la configuración) esto
no es posible, la Aplicación cliente será notificada.
5.2.4. Generador de Stubs
Por tratarse de un Middleware orientado a dispositivos móviles, los Stubs en

OMNI se generan en tiempo de compilación. De esta forma, se elimina la car-
ga computacional derivada de los Stubs generados en tiempo de ejecución.
Para facilitar el proceso de desarrollo en Java ME y Java SE, se incluyó un

módulo generador de código que toma los archivos .java correspondientes a
las interfaces del Cliente y del Servidor y genera automáticamente el código
en Java compilable correspondiente al Stub de Cliente y el Stub de Servidor
(Skeleton).
5.2.5. Parser XML
El Parser de XML fue implementado cuidadosamente; trabaja sobre una única

copia de la cadena XML en memoria. Fue diseñado para ser ejecutado en dis-
positivos con memoria y recursos computacionales limitados. Tiene la capaci-
dad de hallar errores en la sintaxis y en la estructura de la cadena XML que
analiza.
66
5.2.6. Módulo de Compatibilidad
El Módulo de Compatibilidad es la única diferencia entre las implementacio-

nes en Java ME y Java SE. Está diseñado para encapsular las diferencias en
el establecimiento y manejo de conexiones TCP que existen entre estas dos
versiones de Java y proporcionar una interfaz común.
Por condiciones de hardware, algunos dispositivos móviles presentan particu-

laridades en el manejo de conexiones TCP aún cuando afirmen apegarse al
estándar Java ME. Para portar el Middleware a estos dispositivos basta con
reescribir el Módulo de Compatibilidad y respetar su interfaz, ya que el resto
está desarrollado en Java estándar.
5.3. Implementación de Servicios con OMNI
Para desarrollar Servicios haciendo uso del Middleware OMNI se deben seguir los si-
guientes pasos generales:
i. Definición de la Interfaz de Eventos Asincrónicos que el cliente implementará.

ii. Definición de la Interfaz de Métodos Remotos y Eventos Asincrónicos que el Ser-
vidor implementará.
iii. Creación de Stubs para el Cliente y el Servidor por medio del Generador Auto-
mático de Stubs.
iv. Implementación o adaptación de la lógica del Servicio según las interfaces que se
han definido.
v. Desarrollo de la aplicación en el Cliente. Debe implementar la Interfaz de Even-
tos Asincrónicos a través de la cual el Stub de Cliente le notificará de tales even-
tos. Asimismo, la aplicación invocará los Métodos Remotos a través de la Interfaz
de Métodos Remotos que implementa dicho Stub.
Página 67

5.4. Aplicaciones del Middleware OMNI
Dadas sus características, el Middleware OMNI puede utilizarse para implementar gran
cantidad de servicios que involucran dispositivos móviles. Ejemplos de aplicaciones po-
sibles en OMNI son:
 LBS: de tipo Pull, Push y Tracking.

 Telemetría: Gracias a su capacidad para recibir eventos asincrónicos, el Cliente
recibe información de telemetría en tiempo real con una latencia conocida.
 Telecontrol: El sistema invoca métodos remotos para controlar dispositivos o
máquinas distantes.
 Monitoreo de pacientes a distancia: El sistema recibe un reporte periódico o en

tiempo real de ciertos signos vitales medidos en un paciente.
68
 Domótica: El usuario está al tanto de los eventos de su casa inteligente, al mismo

tiempo que la controla a distancia.
 Sistemas de alarma: El usuario puede ser notificado cuando una alarma se ha ac-
tivado.
 Sistemas de monitoreo económico: El Cliente conoce los valores de las acciones
en tiempo real o simplemente es alertado cuando una acción sobrepasa cierto
umbral.
 Redes sociales: El usuario es alertado cuando sus amigos se encuentran física-
mente cerca de él. Pueden organizarse rápidamente concentraciones en un punto
determinado por el sistema como el de más fácil acceso para todos los usuarios
interesados en la reunión.
 Juegos: El Usuario tiene la capacidad de jugar con otros usuarios distantes.
 Monitoreo de unidades: Una empresa puede conocer donde se encuentran todas
sus unidades para determinar cuál está más cerca de un determinado punto y
puede prestar un servicio más rápidamente.
 Recuperación de vehículos robados: Un Cliente puede seguir en un mapa la tra-
yectoria de su vehículo robado.
 Recolección de datos sobre rutas: Una serie de dispositivos instalados en vehí-
culos pueden transmitir la información de las rutas que recorren para comple-
mentar el mapa de una ciudad, así como la velocidad promedio, el tiempo de es-
pera en semáforos, etc.
 Correo electrónico: Los correos electrónicos se redirigen instantáneamente al
dispositivo móvil; pueden ser leídos y contestados.
 Comercio electrónico: El usuario puede comprar y vender, es notificado cuando
las subastas comienzan o terminan; cuando se publica cierto artículo con cierto
precio, cuando algo se vende o se compra, etc.
 Acceso simplificado a sistemas más complejos: Las aplicaciones pueden ac-
ceder a los servicios disponibles en SOAP, CORBA, etc. de forma simpli-
ficada a través de OMNI. El Cliente envía los parámetros y el Servidor se
encarga de invocar los servicios y reenviar sus resultados de vuelta al
Cliente.
Página 69

6. Pruebas
Una vez finalizado el proceso de implementación y depuración del Middleware OMNI se

realizaron pruebas para evaluar su rendimiento.
6.1. Latencia y Glitter
En esta prueba, la Latencia se define como el tiempo que toma un mensaje en ir del
Cliente al Servidor y regresar. En pocas palabras, realizar un PING. El Glitter es la des-
viación estándar de la Latencia.
Para hallar estos valores, se diseñó e implementó un sencillo Servicio OMNI con la si-
guiente Interfaz de Métodos y Eventos Remotos en el Servidor:
Figura 15. (Interfaz OMNI para el servidor PING)
public interface pingPullServices extends PullServices

{
public String pingFromClient(String load)
public void saveData(String fileName, String info, int[] delays)
}
Durante la prueba, el Cliente invoca el método String pingFromClient(String load) pa-

ra enviar al Servidor una cadena arbitraria de cierta longitud. Seguidamente, el Servidor
retorna al Cliente un String correspondiente a la cadena que se recibió. El Cliente mide el
tiempo que transcurre entre la invocación y el retorno. Tras repetir este proceso 100 ve-
ces, el Cliente genera el Evento Remoto void saveData(String fileName, String info,
int[] delays) para enviar al Servidor los tiempos resultado de cada una de las 100 prue-
bas y guardarlos en un archivo.
Se asumió que el tiempo que tarda el Servidor en generar el retorno es constante y cerca-
no a cero.
70
La prueba se realizó con 11 longitudes diferentes de la cadena (carga útil). Los resultados
pueden verse en (fig. 16) y (fig. 17). Los datos registrados en cada prueba pueden consul-
tarse en el anexo 7.
~ , "
--ii;- •
•
•
•
~
•
•
•
•
~
•
•
•
F'gu ra H e arga u •• enCl a pmm '0
Mi1ioo9 ·
,- /
,= /
/
.-
, ~
/
,- /'
,-
,-
,-
'" ,- "'00 ' 00) " .)0 ,~
'"' . " .,00 ,- "'..
Página 71

Como puede apreciarse, hasta los 3500 bytes de carga útil la latencia y el glitter se man-
tienen dentro de los valores esperados para la tecnología que se está utilizando (3G).
Después de ese valor, el glitter aumenta de tal forma que se hace muy difícil establecer
un valor predecible para la latencia.
Durante las pruebas se enviaron decenas de miles de paquetes a través de la conexión sin
registrar nunca la pérdida de uno de ellos. Esto indica que el sistema es confiable.
6.2. Servicio de prueba – “chatLBS”
Finalmente, se utilizó el Middleware para la implementación de un servicio que explota

las funcionalidades Pull, Push y Tracking de OMNI.
El servicio chatLBS permite a los usuarios del sistema comunicarse entre sí por medio de
mensajes, al mismo tiempo que visualiza la posición de cada uno de ellos en tiempo real
(Limitado a la latencia del sistema). (fig. 18).
El chatLBS puede representarse como un grafo completo, ya que cada usuario conoce la
posición de todos los demás.
72
Este servicio es suficiente para validar las funcionalidades del Middleware porque:
a) Cuando un usuario solicita el envío de un mensaje, se realiza una operación Pull.

b) Cuando un usuario recibe un mensaje o una notificación de cambio de posición
por parte de otro usuario, se realiza una operación Push.
c) Cada usuario notifica sus cambios de posición al Servidor, el cual se encarga de
registrarlos y repetirlos inmediatamente a todos los demás usuarios. Esto consti-
tuye un servicio de tipo Tracking.
Para lograr las funcionalidades propuestas, se diseñaron las interfaces de Servidor y

Cliente requeridas por el Middleware OMNI. (fig. 19) y (fig. 20).
Figura 19. (Interfaz OMNI para el Servidor chatLBS)
public interface chatLBSPullServices extends PullServices

{
public boolean iniciarSesion(String ID, String nombreUsuario)
public boolean cerrarSesion(String ID)
public boolean enviarMensaje(String IDremitente, String nombreDestino,
String mensaje)
public void enviarMensajeBroadcast(String IDremitente,
String mensaje)
public void actualizarLocalizacion(String ID, double[] coordenadas)
public String[] getListaUsuarios(String ID)
}
iniciarSesion(String ID, String nombreUsuario), cerrarSesion(String ID) y

getListaUsuarios(String ID) son los métodos que se emplean para entrar, salir y obte-
ner la información inicial del sistema.
Página 73

enviarMensaje(String IDremitente, String nombreDestino, String mensaje) y

enviarMensajeBroadcast(String IDremitente, String mensaje) son servicios Pull para
enviar mensajes de texto.
actualizarLocalizacion(String ID, double[] coordenadas) se invoca para informar al

Servidor cuando la posición del dispositivo ha cambiado.
Figura 20. (Interfaz OMNI para el Cliente chatLBS)
import co.edu.javeriana.lbs.omni.service.PushListener;
public interface chatLBSPushListener extends PushListener

{
public void usuarioConectado(String nombreUsuario)
public void usuarioDesconectado(String nombreUsuario)
public void posicionActualizada(String nombreUsuario,
double[] coordenadas)
public void mensajePrivadoRecibido(String nombreRemitente,
String mensaje)
public void mensajeBroadcastRecibido(String nombreRemitente,
String mensaje)
}
usuarioConectado(String nombreUsuario) y usuarioDesconectado(String nombreUsua-

rio) son Eventos Asincrónicos (Push) que notifican al Cliente si un determinado usuario
se ha conectado o desconectado.
posicionActualizada(String nombreUsuario, double[] coordenadas) es un Evento

Asincrónico que notifica al Cliente del cambio en la posición de un usuario.
mensajePrivadoRecibido(String nombreRemitente, String mensaje) y mensajeBroad-

castRecibido(String nombreRemitente, String mensaje) son Eventos Asincrónicos que
informan al Cliente de la recepción de un mensaje.
74
Tras su implementación, el servicio fue desplegado como puede verse en (fig. 21).
Figura 21.
Despliegue de Prueba (chatLBS)
Cliente
Emulador
BlackBerry OS
Window s
Servidor
chatLBS
Redlrector OMNI
Página 75

Unas capturas de pantalla en Windows y en BlackBerry OS pueden verse en (fig. 22).
Figura 22.
[fj OMNI , ha! LBS 1.0
1 Conectar 11 Desconectar
Nombre Usuario: lusu.,i02 longttud: ~
I Iniciar Sesión 11
.. cerrarSesion Establecer 1
"eroiceHo st: 1 86 .80 .3.1 90 ac_ry:o.o:o.o

"eroicePo rt: 200 suario1:U.0:0.0
one c1.do 'I D:. 8 h 1L8S
nici.ndo s eSl on de,. ... .. 81
esión inIC ,.d. ' . . do de sde 1ermln. 1fij"
>b lackberry: Mensaje erM'
~
I ~ I Broadcast
76
6.3. Modificación en la especificación del Middleware OMNI como resultado

de las pruebas
Tras probar el servicio y observar su funcionamiento, se realizó una modificación en la
especificación original del Middleware OMNI para mejorar su rendimiento:
 Problema potencial: Cuando un Cliente invoca un Método Remoto que requiere

la solicitud de información de múltiples Clientes, el método bloqueará el hilo en
la aplicación invocadora hasta cuando todos los demás Clientes hayan sido inter-
rogados; lo cual tomará un tiempo superior a la peor latencia existente dentro del
sistema.
 Solución: Se agregó la funcionalidad de Generación de Evento Asincrónico del
Cliente al Servidor. De esta forma, el Cliente puede solicitar un servicio sin espe-
rar un retorno inmediato. Cuando el Servidor haya finalizado la ejecución y tenga
los resultados disponibles, los enviará al Cliente por medio de un Evento
Asincrónico del Servidor al Cliente.
Adicionalmente, algunos métodos pueden no requerir retorno alguno por parte del Servi-
dor (void) ni lanzar ninguna excepción. En este caso, la nueva funcionalidad de Evento
Asincrónico del Cliente al Servidor sirve para implementarlos más eficientemente, ya que
el hilo invocador en la aplicación Cliente transmite los datos y se desbloquea tras recibir
la notificación ACK de TCP.
Página 77

V - CONCLUSIONES Y TRABAJOS FUTUROS
1. Conclusiones
 La exploración llevada a cabo sobre las diferentes plataformas disponibles para dis-
positivos móviles muestra que el estándar Java ME está ampliamente soportado y es
una buena elección a la hora de desarrollar aplicaciones fácilmente adaptables a va-
rias plataformas.
 Los protocolos de transferencia de datos SMS, MMS y WAP han sido utilizados exi-
tosamente en el pasado para la implementación de servicios en dispositivos móviles.
Sin embargo, dada la tendencia y las características de las redes actuales y futuras
(3G - 4G) es muy probable que estos sean reemplazados por o implementados sobre
la pila de protocolos de IP.
 La utilización de XML logra el objetivo de interoperabilidad pero sacrifica la eficien-

cia en la transmisión de los datos que se obtendría al enviar las serializaciones de da-
tos binarias propias de cada plataforma.
 Un LBS de tipo Pull, Push o Tracking puede definirse como un servicio en el cual se
utiliza la información de posición como parámetro.
 Las operaciones básicas propuestas y definidas en este Trabajo de Grado como Invo-
cación de Método Remoto y Generación de Evento Asincrónico son suficientes para
la implementación de servicios genéricos para dispositivos móviles.
 El Middleware especificado y la implementación asociada en Java ME - Java SE

proporcionan al desarrollador las operaciones básicas de Invocación de Método Re-
moto y Generación de Evento Asincrónico. Por lo tanto se alcanzaron todos los obje-
tivos de este Trabajo de Grado.
78
2. Trabajos futuros
El Middleware desarrollado cumple con los objetivos para los cuales fue diseñado. Sin em-
bargo, existen diversas opciones que pueden tomarse para retomar este proyecto y comple-
mentarlo.
 Implementación del Cliente para Microsoft .net: Al implementar el Cliente OMNI

para Microsoft .net el Cliente en Java ME interactuaría de forma transparente con
Windows Mobile. La arquitectura existente en Java puede fácilmente portarse a C#
dado su gran parecido.
 Implementación de un servidor más eficiente y robusto: El servidor en Java puede

ser reemplazado por uno mucho más eficiente implementado en C++.
 Implementación de mecanismos de seguridad: Extender la definición del Middlewa-

re para permitirle efectuar transferencias de datos seguras.
 Desarrollo de una metodología para la creación de servicios con el esquema Pull-

Push: Se ha afirmado que cualquier servicio puede implementarse utilizando el es-
quema Pull-Push, pero no se ha especificado detalladamente cómo. Sería interesante
la creación de una metodología que permitiera encontrar las interfaces Pull y Push de
un servicio determinado.
 Desarrollo de adaptadores de software: El Middleware puede utilizarse para brindar

a los dispositivos móviles acceso simplificado a sistemas más complejos, como Web-
Services, SOAP, CORBA, etc. Para esto es necesaria la implementación de adaptado-
res.
 Desarrollo de adaptadores de hardware: El Middleware puede utilizarse para opera-

ciones de telemetría y telecontrol. Los adaptadores para el manejo de sensores y ac-
tuadores serían necesarios.
Página 79

VI - REFERENCIAS
Article
[GANG2004]
Gang, L.; Shang, F.; Jun, S.; Ye, J. & Meiping, F.
PTGRP: an LBS application based on SMS platform
Proc. Joint Conference of the 10th Asia-Pacific Conference on Communications and
the 5th International Symposium on Multi-Dimensional Mobile Communications,
2004, 1, 234-238 vol.1
Standard
[WINE2003]
Winer, D.
XML-RPC Specification
http://www.xmlrpc.com
UserLand Software,
2003
Book
[TANE2003]
Tanenbaum, A. S.
Mendoza, G. T. (ed.)
Redes de computadoras
Prentice Hall,
2003
Booklet
[STEI2006]
Stefan Steiniger, Moritz Neun, A. E.
Foundations of Location Based Services
2006
Article
[SEGA2009]
Segan, S.
If Microsoft Can't Move Faster in Phones, It's Dead
http://www.pcmag.com/article2/0,2817,2341157,00.asp
PC Magazine,
2009, 28
80
Article
[SASA2007]
Sasaki, A.; Yamauchi, K.; Chan, W.; Cohen, M.; Wei, D. & Cheng, Z.
Innovative Mobile Phone Services Based on Next Generation Infrastructure in Japan
A Survey
Proc. 7th IEEE International Conference on Computer and Information Technology
CIT 2007,
2007
Article
[SADO2007]
Sadoun, B. & Al-Bayari, O.
LBS and GIS Technology Combination and Applications
Proc. IEEE/ACS International Conference on Computer Systems and Applications
AICCSA '07,
2007
Article
[ABIR2008]
ABI Research®,
More than 550 Million GPS – Enabled Handsets Will Ship by 2012
http://www.abiresearch.com/press/1125-More+Than+550+Million+GPS-
Enabled+Handsets+Will+Ship+by+2012
ABI Research®,
2008
Article
[CRTC2008]
Comisión Nacional de telecomunicaciones (Colombia)
Continúa dinámica de crecimiento en el sector de telecomunicaciones
Informe Sectorial de Telecomunicaciones,
2008
Article
[MURP1995]
Murphy, L. D.
Geographic Information Systems: Are They Decision Support Systems?
1995
Página 81

Article
[MCMA2006]
McMahon, M.; Steketee, C.
Investigation of Proposed Applications for LBS Enabled Mobile Handsets
Proc. International Conference on Mobile Business ICMB '06,
2006
Article
[MCCR2009]
McCracken, H.
Smart Phone OS Smackdown
PC World,
2009
Article
[COST2002]
Costa-Requena, J.; Tang, H. & Espigares, I.
Consistent LBS solution in next generations of mobile internet
Proc. Ninth International Conference on Parallel and Distributed Systems,
2002
Article
[YUNC2007]
Cho, Y. C. ; Jeon, J. W.
Current software platforms on mobile phone
Proc. International Conference on Control, Automation and Systems ICCAS '07,
2007
Manual
[GSMA2003]
GSM Association.
Location Based Services
GSM Association,
2003
Techreport
[GSMW2009]
GSM Association.
Market Data Summary
GSM Association, 2009
82
Article
[ARZU2008]
Aitor Arzuaga Munsuri, Jose Miguel Arzuaga Canals, M. Z. A.
Implementación de aplicaciones de telecontrol sobre redes GPRS
2008
Article
[ADUS2004]
Adusei, I. K.; Kyamakya, K. & Erbas, F.
Location-based services: advances and challenges
Proc. Canadian Conference on Electrical and Computer Engineering,
2004
Página 83

V- ANEXOS
Anexo 1: Omni Middleware Protocol RFC.
Anexo 2: Diagrama de Clases de la implementación en Java de OMNI Middleware.
Anexo 3: Documentación de la implementación en Java de OMNI Middleware.
Anexo 4: Código fuente de la implementación en Java de OMNI Middleware.

Anexo 5: Instrucciones para la implementación de un servicio OMNI.
Anexo 6: Código fuente del servicio de ejemplo “ChatLBS”.

Anexo 7: Datos registrados durante las pruebas de Latencia y Glitter.
84
Página 85

Tesis 270

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tesis 270

Загружено:

Авторское право:

Доступные форматы

CIS0830-IS13

MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS

CÉSAR ESTÉBAN CASTAÑEDA RUÍZ

PONTIFICIA UNIVERSIDAD JAVERIANA

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO

PONTIFICIA UNIVERSIDAD JAVERIANA

PONTIFICIA UNIVERSIDAD JAVERIANA

Joaquín Emilio Sánchez García S.J.

Decano Académico Facultad de Ingeniería

Ingeniero Francisco Javier Rebolledo Muñoz

Decano del Medio Universitario Facultad de Ingeniería

Padre Sergio Bernal Restrepo S.J.

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Luis Carlos Díaz Chaparro

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

Director Departamento de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Artículo 23 de la Resolución No. 1 de Junio de 1946

A mi familia, por su apoyo;

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO..............................18

II - MARCO TEÓRICO ............................................................................................23

2. DESARROLLO DEL PROYECTO ........................................................................35

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

V - CONCLUSIONES Y TRABAJOS FUTUROS ..................................................78

2. TRABAJOS FUTUROS ........................................................................................79

El "Middleware para la Definición e Implementación de servicios Genéricos independientes

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

Para solucionar este problema se estudiaron las tecnologías de transferencia inalámbrica de

Tradicionalmente en Computación Móvil se reconocen dos tipos de servicios:

 El protocolo orientado a conexión TCP permite la comunicación Full-dúplex, envío y

Un enfoque basado únicamente en Llamadas a Procedimientos remotos (RPC) no es suficien-

De esta forma, el Middleware propuesto define un servicio así:

Se definió un protocolo para la invocación de métodos remotos y la generación de eventos

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

Durante el proceso de desarrollo se encontró que el middleware propuesto es suficiente para

Traditionally, there are two kinds of services in mobile-computing:

 Push-type Services: Mobile device receives data asynchronically, without explicit

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

 Extensible Markup Language (XML) provides a platform independent standard for

In the Middleware, a service is defined as:

 A Pull-interface implemented by Server. These procedures return a result or throw an

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

En el transcurso de este Trabajo se propone, implementa y prueba una solución al problema

En la sección II – Marco teórico, se introducen los conceptos y definiciones necesarios para

En la sección III – Proceso, se expone la metodología propuesta originalmente y qué se rea-

La sección IV – Resultados, se divide en subsecciones, cada una de las cuales trata de un

En la sección V – Conclusiones y trabajos futuros, se encuentran las conclusiones que se

La presente memoria no pretende ahondar en los detalles técnicos de la solución propuesta ni

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO

En los últimos años, la creciente tecnología de interconexión entre diferentes dispositivos

ro, según [SADO2007], En el futuro, la creciente demanda de dichos servicios incenti-

Cuando las tecnologías de conectividad inalámbrica y posicionamiento geográfico con-

El principal obstáculo para el desarrollador es la poca interoperabilidad existente entre la

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

En el caso de los dispositivos móviles la solución a los problemas de conexión y transfe-

Muchos servicios han resuelto el problema de la interoperabilidad haciendo uso de tecno-

Teniendo en cuenta la creciente disponibilidad de nuevos medios inalámbricos de alta ve-

¿Cómo lograr la implementación de servicios genéricos para dispositivos móviles de

2. Descripción del Proyecto

Durante el desarrollo de este proyecto, se realizó una exploración de las plataformas y

Se busca que el desarrollador pueda concentrar sus esfuerzos en el diseño de su servicio,