Tesis - Mario Alberto Gomez Rodriguez

Centro de Investigación y de Estudios Avanzados
del Instituto Politécnico Nacional
Laboratorio de Tecnologı́as de Información
Middleware para almacenamiento

externo para dispositivos
inalámbricos con recursos limitados
Tesis que presenta:
Mario Alberto Gómez Rodrı́guez
Para obtener el grado de:
Maestro en Ciencias
en Computación
Director de la Tesis:
Dr. Vı́ctor Jesús Sosa Sosa
Cd. Victoria, Tamaulipas, México. Febrero, 2010

c Derechos reservados por
2010
Esta investigación fue parcialmente financiada mediante el proyecto No. 51623 del Fondo Mixto
Conacyt-Gobierno del Estado de Tamaulipas.
This research was partially funded by project number 51623 from “Fondo Mixto Conacyt-Gobierno
del Estado de Tamaulipas”.
La tesis presentada por Mario Alberto Gómez Rodrı́guez fue aprobada por:
Dr. José Guadalupe Rodrı́guez Garcı́a
Dr. Javier Rubio Loyola
Dr. Vı́ctor Jesús Sosa Sosa, Director
Cd. Victoria, Tamaulipas, México., 26 de Febrero de 2010

Con mucho cariño para mi familia, por su apoyo incondicional.
Agradecimientos
Doy gracias a dios por haberme permitido obtener cada uno de mis logros en la vida.
Agradezco mucho a mi familia por que siempre me ha apoyado en lo que hago.
Muchas gracias a todos mis compañeros de la segunda generación del CINVESTAV, por
compartir sus buenos y malos momentos conmigo durante la maestrı́a. Fue un placer trabajar
con cada uno de ustedes.
Gracias al Dr. Vı́ctor Jesús Sosa Sosa (mi asesor), por toda la paciencia que me tuvo a lo largo
del desarrollo de esta tesis; muchas gracias doctor.
Agradezco a mis revisores, Dr. Javier Rubio Loyola y Dr. José Guadalupe Rodrı́guez Garcı́a por
haberme ayudado a mejorar esta tesis con sus correcciones.
Sin el apoyo de alguno de ustedes no hubiera sido capaz de llevar a cabo este trabajo. A todos,
muchas gracias !!!.
Índice General
Índice General I
Índice de Figuras V
Índice de Tablas VII
Índice de Algoritmos IX
Publicaciones XI
Resumen XIII
Abstract XV
1. Introducción 1
1.1. Contexto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. Objetivos particulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2.1. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Marco teórico y trabajos relacionados 9

2.1. Descripción de sistemas de comunicación inalámbrica . . . . . . . . . . . . . . . . . 9
2.1.1. WPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1.1. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2. WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.3. WWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3.1. Sistema global para comunicaciones móviles (GSM) . . . . . . . . 17
2.1.3.2. Servicio general de radio paquetes (GPRS) . . . . . . . . . . . . . 20
2.2. Descripción de sistemas de mensajerı́a . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1. Servicio de mensajes cortos (SMS) . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2. Arquitectura MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2.1. Entorno MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2.2. Cliente MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2.3. Centro MMS (MMSC) . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3. Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
I
3. Arquitectura del Middleware 35
3.1. Requerimientos para el diseño de la arquitectura . . . . . . . . . . . . . . . . . . . 35
3.1.1. Requerimientos lado cliente (dispositivo móvil) . . . . . . . . . . . . . . . . 35
3.1.2. Requerimientos lado servidor (PC) . . . . . . . . . . . . . . . . . . . . . . 36
3.2. Middleware para almacenamiento externo . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1. Lado cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1.1. API Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1.2. Selección red/servicio . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1.3. Módulos Wi-Fi y GPRS . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1.4. Módulo MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.1.5. Módulo SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2. Núcleo de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2.1. Centro SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2.2. Centro MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2.3. Servidor SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2.4. Pasarela GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2.5. BD Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2.6. Servidor FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2.7. Cliente e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.3. Lado servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.3.1. API Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3.2. SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3.3. DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3.4. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3.5. MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3. Medidas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4. Diagramas UML de la Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.1. Diagrama de clases del middleware (cliente) . . . . . . . . . . . . . . . . . 48
3.4.2. Diagrama de caso de uso del middleware del lado cliente . . . . . . . . . . . 50
3.4.3. Diagramas de secuencia utilizando las clases del middleware (cliente) . . . . 51
3.4.4. Diagrama de clases del middleware (servidor) . . . . . . . . . . . . . . . . . 58
3.4.5. Diagrama de caso de uso del middleware del lado servidor . . . . . . . . . . 60
3.4.6. Diagramas de secuencia utilizando las clases del middleware (servidor) . . . . 60
3.5. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4. Evaluación experimental 65
4.1. Escenario de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1.1. Medidas en redes GPRS y WLAN (reales) . . . . . . . . . . . . . . . . . . . 66
4.1.1.1. Tamaños óptimos para transferencia de archivos en redes Wi-Fi y
GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.1.1.2. Tiempo de transferencias de un archivo de tamaño promedio . . . 68
4.1.2. Elección de polı́tica de reemplazo para aplicación de ejemplo . . . . . . . . . 69
4.1.3. Swapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
II
4.1.3.1. Pruebas de envı́o . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1.3.2. Pruebas de recepción . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.4. Proyecto VS Campamento Móvil . . . . . . . . . . . . . . . . . . . . . . . 75
4.1.4.1. Descripción general del proyecto . . . . . . . . . . . . . . . . . . 75
4.1.4.2. Aplicación prototipo . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5. Conclusiones y trabajo futuro 79

5.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A. Cómo utilizar el middleware 83

A.1. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.1.1. Proceso de desarrollo de un MIDLet utilizando el J2ME Wireless Toolkit . . 84
A.2. Ejemplo de instalación de una aplicación que hace uso del middleware . . . . . . . . 85
A.2.1. Lado servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.2.1.1. Pasos para levantar el servidor . . . . . . . . . . . . . . . . . . . 86
A.2.2. Lado cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.2.2.1. Pasos para instalar el cliente . . . . . . . . . . . . . . . . . . . . 88
B. Java 2 Micro Edition (J2ME) y el manejo de mensajes SMS y MMS 91

B.1. Arquitectura J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B.2. Caracterı́sticas J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.3. Servicio de mensajes cortos (SMS) . . . . . . . . . . . . . . . . . . . . . . . . . . 95
B.4. Servicio de mensajes multimedia (MMS) . . . . . . . . . . . . . . . . . . . . . . . 96
C. Descripción de las clases del middleware 99

C.1. Clases cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.1.1. Clase HexCodec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.1.2. Interface DataInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.1.3. Interface AllInterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
C.1.4. Interface MenuInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
C.1.5. Clase FTPClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
C.1.6. Clase Crypto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.1.7. Clase UserData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
C.1.8. Clase SelecPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
C.1.9. Clase MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
C.1.10. Clase ConnectorMiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.2. Clases servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
C.2.1. Clase MailReceiverToFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
C.2.2. Clase FTPClientPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
C.2.3. Clase Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
C.2.4. Clase BDConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
C.2.5. Clase ServerConfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
III
C.2.6. Clase HexCodec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
C.2.7. Clase Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
C.2.8. Clase ThreadFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
C.2.9. Clase FTPServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
C.2.10. Clase Crypto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Bibliografı́a 125
IV
Índice de Figuras
1.1. Eventos relevantes en el mercado de telecomunicaciones en México . . . . . . . . . 3

1.2. Usuarios desde 1990 hasta 2008 según COFETEL . . . . . . . . . . . . . . . . . . 4
2.1. Desde las redes PAN hasta las RAN. . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Pila de protocolos Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Modo Ad-hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4. Arquitecturas de red con infraestructura . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5. Arquitectura GSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6. Microchip SIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7. Arquitectura GPRS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8. Arquitectura GSM habilitada para el manejo de SMSs. . . . . . . . . . . . . . . . . 23
2.9. Arquitectura MMS [8]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.10. Menú de GSpaceMobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.11. Arquitectura de EmozeTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.12. Sincronización de MobileMe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1. Middleware para almacenamiento externo para dispositivos móviles. . . . . . . . . . 38

3.2. Algoritmo de selección de red/servicio disponible. . . . . . . . . . . . . . . . . . . . 40
3.3. Proceso de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4. Encriptación y desencriptación de archivos . . . . . . . . . . . . . . . . . . . . . . 46
3.5. Proceso de encriptación de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6. Proceso de desencriptación de archivos . . . . . . . . . . . . . . . . . . . . . . . . 47
3.7. Clases aisladas: FTPClient y ConnectorMiddleware. . . . . . . . . . . . . . . . . . . 48
3.8. Clases aisladas: MMS y HexCodec. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9. Clase aislada: Crypto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.10. Clases e interfaces relacionadas: DataInterface, AllInterfaces, MenuInterface,
SelecPath y UserData. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.11. Diagrama de caso de uso cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.12. Diagrama de secuencia para el envı́o de un arhivo utilizando el middleware (cliente). 54
3.13. Diagrama de secuencia para la recepción de un arhivo utilizando el middleware (cliente). 57
3.14. Clases aisladas: BDConnection y FTPClientPC. . . . . . . . . . . . . . . . . . . . . 58
3.15. Clase aislada: Crypto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.16. Clases aisladas: MailReceiverToFTP, Usuario y HexCodec. . . . . . . . . . . . . . . 59
3.17. Clases relacionadas: FTPServer, ThreadFTP, Register y ServerConfiguration. . . . . 59
3.18. Diagrama de caso de uso servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.19. Diagrama de secuencia para la recepción de arhivos utilizando el middleware (servidor). 63
4.1. Tamaño óptimo de bloque en una red WLAN. . . . . . . . . . . . . . . . . . . . . 67

4.2. Tamaño óptimo de bloque en una red GPRS. . . . . . . . . . . . . . . . . . . . . . 67
V
4.3. Tiempos de transmisión de archivos sin encriptar . . . . . . . . . . . . . . . . . . . 68
4.4. Tiempos de transmisión de archivos encriptados . . . . . . . . . . . . . . . . . . . 69
4.5. Tasa de hits obtenidos utilizando diferentes polı́ticas de reemplazo. . . . . . . . . . 71
4.6. Tiempos de transferencia promedio obtenidos utilizando diferentes polı́ticas de
reemplazo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.7. Consumo promedio total de ancho de banda obtenido utilizando diferentes polı́ticas
de reemplazo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.8. Tiempo promedio total obtenido utilizando diferentes polı́ticas de reemplazo. . . . . 72
4.9. Capturas de pantallas de la aplicación. . . . . . . . . . . . . . . . . . . . . . . . . 77
A.1. Aspecto de la herramienta KToolBar del J2ME Wireless Toolkit . . . . . . . . . . . 85

A.2. Jerarquı́a de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.3. Directorio principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
B.1. Bloques fundamentales de CDC y CLDC. . . . . . . . . . . . . . . . . . . . . . . . 94
VI
Índice de Tablas
1.1. Fases del mercado de telefonı́a móvil en México . . . . . . . . . . . . . . . . . . . 2
2.1. Las capas y protocolos en la pila de protocolos Bluetooth . . . . . . . . . . . . . . 12

2.2. Comparación de varios estándares WLAN . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Ventajas y desventajas de las redes inalámbricas y el MMS. . . . . . . . . . . . . . 39
4.1. Medidas comunes en celulares y PDAs. . . . . . . . . . . . . . . . . . . . . . . . . 69

4.2. Tiempos promedio de envı́o. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3. Tiempos promedio de recepción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.1. Familia del lenguaje Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
VII
Índice de Algoritmos
IX
Publicaciones
Mario A. Gomez-Rodriguez, Victor Sosa-Sosa and Ivan Lopez-Arevalo. External Storage Middleware
for Wireless Devices with Limited Resources, in ACM/IEEE Symposium on Architectures for
Networking and Communications Systems (ANCS 2009), Princeton, NJ, USA, October 2009.
Mario A. Gomez-Rodriguez, Victor Sosa-Sosa and Ivan Lopez-Arevalo. A File Transfer Service for
Mobile Devices, in Mexican International Conference on Computer Science (ENC 2009), Research in
Computing Science journal (RCS), ISSN 1870-4069, Mexico City, Mexico, September 2009.
Mario A. Gomez-Rodriguez, Victor Sosa-Sosa and Ivan Lopez-Arevalo. A Portable File Swapper For
Mobile Devices, in 16th International Multi-Conference on Advanced Computer Systems (ACS 2009),
Polish Journal of Environmental Studies, Miedzyzdroje, Poland, October 2009.
Mario Alberto Gómez Rodrı́guez, Vı́ctor Jesús Sosa Sosa e Iván López Arévalo. Servicio portable
de intercambio automático de archivos para dispositivos móviles, en el VII Congreso Internacional
Sobre Innovación y Desarrollo Tecnológico (CIINDET 2009), Cuernavaca, Morelos, México, Octubre
2009.
XI
Resumen
Middleware para almacenamiento externo para dispositivos

inalámbricos con recursos limitados
por

Maestro en Ciencias del Laboratorio de Tecnologı́as de Información
Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional, 2010
Dr. Vı́ctor Jesús Sosa Sosa, Director
En la actualidad el sistema común de respaldo en los dispositivos móviles implica el uso de

cables (e.g., USB) o redes inalámbricas de corto alcance como Bluetooth o Infrarrojo. Este tipo
de comunicación limita la movilidad de los usuarios. Además, en el mundo de los dispositivos
móviles es común encontrar dispositivos que utilizan distintos sistemas operativos (e.g., Symbian
OS, Windows Mobile, etc.); siendo un requerimiento evidente el desarrollo de herramientas que
faciliten la implementación de aplicaciones móviles que sean capaces de ejecutarse en diferentes
sistemas operativos.
En este trabajo de tesis se presenta un Middleware que es capaz de funcionar en distintos sistemas
operativos y que permite a las aplicaciones móviles enviar y recibir archivos desde un servidor de
almacenamiento externo conectado a Internet, utilizando diferentes tecnologı́as inalámbricas como
Wi-Fi, GPRS y MMS. El middleware proporciona algunas medidas de seguridad como autenticación y
confidencialidad para comprobar la identidad de los usuarios y a su vez evitar que los datos que viajan
a través de la red o servicio puedan ser interpretados (entendidos) por terceras personas. Utilizando
para esto los algoritmos SHA1 (Secure Hash Algorithm 1) y AES (Advanced Encryption Standard).
Algunas de las funciones principales del middleware como son stor( ), retr( ), criptFile( ) y
decriptFile( ) fueron probadas por medio de una aplicación móvil llamada Swapper, que ofrece un
servicio de intercambio de archivos entre el dispositivo móvil y un servidor de almacenamiento externo
en forma transparente. También se presenta una aplicación prototipo de un proyecto que se tiene
XIII
con la empresa privada; dicha aplicación será software comercial que la empresa Vision Systems de
México, SA. de CV. se encargará de ofrecer a empresas del ramo de la construcción.
XIV
Abstract
External Storage Middleware for Wireless Devices with

Limited Resources
by

Master of Science from the Information Technology Labotory
Research Center for Advanced Study from the National Polytechnic Institute, 2010
Dr. Vı́ctor Jesús Sosa Sosa, Advisor
Currently the common backup system on mobile devices involves the use of cables (e.g., USB) or
short-range wireless networks like Bluetooth or Infrared. This type of communication limits the user
mobility. Moreover, in the mobile-device world is common to find devices that use different operating
systems (e.g., Symbian OS, Windows Mobile, etc.); being an evident requirement to develop tools
that facilitate the implementation of mobile applications that are capable of running on different
operating systems.
In this thesis is presented a Middleware that is capable of running on different operating systems
and allow mobile applications to send and receive files from an external storage server connected to
Internet, using different wireless technologies like Wi-Fi, GPRS and MMS. The middleware provides
some security measures such as authentication and confidentiality to verify the identity of users and in
turn prevent that the data traveling through the network or service can be interpreted (understood) by
third parties. Using the SHA1 (Secure Hash Algorithm 1) and AES (Advanced Encryption Standard)
algorithms to it.
Some of the major functions of middleware such as stor( ), retr( ), criptFile( ) and decriptFile(
) were tested by means of a mobile application called Swapper, which offers a service of swapping
files between the mobile device and an external storage server in a transparent way. It also presents
a prototype implementation of a project that is through private enterprise; such application will be
commercial software that the company Vision Systems de México, SA. CV. is responsible to offer to
XV
companies of the construction industry.
XVI
Introducción
1
En este capı́tulo se plantea el contexto del proyecto, ası́ como sus alcances y limitaciones; se
muestra cómo han evolucionado los distintos dispositivos móviles, la evolución de la telefonı́a móvil
en México, etc., se da una descripción del problema que se aborda, además de los objetivos tanto
generales como particulares.
1.1 Contexto del proyecto
El concepto básico de los teléfonos celulares comenzó en 1947, cuando los investigadores
examinaron los teléfonos móviles (para autos) y se dieron cuenta que mediante el uso de pequeñas
celdas (rango de área de servicio) con reutilización frecuente, ellos podrı́an incrementar la capacidad
de tráfico de los teléfonos substancialmente. En 1973 Martin Cooper [7] considerado el inventor del
primer teléfono portátil moderno, realizó la primera llamada desde uno de estos teléfonos. Para 1987,
los suscriptores de telefonı́a celular excedieron un millón [7]. El número de suscriptores ha crecido
exponencialmente alrededor de todo el mundo desde entonces, para el 2005 el número de teléfonos
celulares en uso en el mundo excedieron los dos millones. Desde su invención el teléfono celular
1
2 1.1. Contexto del proyecto
portable ha experimentado una tremenda evolución, se ha vuelto más pequeño, barato, confiable y
es ofrecido por completo con todo tipo de tecnologı́a [16]. El servicio ha llegado a ser muy confiable
también, la cobertura incluye todas las ciudades, pueblos y casi todas las carreteras, todos estos
factores han contribuido a la popularidad del teléfono celular.
“A principios de los noventa, el sector de las telecomunicaciones en México dio inicio a notables
transformaciones, que comenzaron con la privatización de la entonces empresa estatal Teléfonos
de México, el monopolio operador de servicios de telefonı́a fija. Quince años atrás el teléfono era
un dispositivo fijo generalmente para comunicarse entre familia, amigos o empresas, hoy en dı́a las
telecomunicaciones permiten realizar una serie de aplicaciones, antes tal vez impensadas, como por
ejemplo revisar el periódico en Internet o realizar transacciones electrónicas [35]”.
La telefonı́a celular y móvil ha avanzado de manera considerable en México y actualmente presenta
un dinamismo y expectativas de crecimiento mucho mayores a las del mercado de telefonı́a fija. La
Tabla 1.1 ilustra las diferentes etapas de la evolución de las telecomunicaciones móviles en México
desde 1990 hasta la actualidad [35].
Fase Estructura prevista

Cero: 1990-1998 Telefonı́a fija: Privatización (1990-1995) y
competencia segmentada (larga distancia) (1995-1998)
1ra : 1999-2001 Irrupción de medios móviles competencia limitada
da
2 : 2002-2004 Primera fase de maduración: intensificación de la
competencia y maduración del consumidor
3ra : 2005-presente Segunda fase de maduración
Tabla 1.1: Fases del mercado de telefonı́a móvil en México
La Figura 1.1 ilustra los eventos relevantes de las distintas fases mencionadas anteriormente.
En la Figura 1.2 se muestra el número de usuarios de telefonı́a móvil desde 1990 hasta 2008 de
acuerdo con los datos de la COFETEL [1]. En ella se puede apreciar cómo se ha incrementado el
número de usuarios con el paso de los años.
La evolución del teléfono celular ha logrado que, por un lado, en la actualidad contemos con
teléfonos celulares “inteligentes”(conocidos como smartphones) que integran las funciones de PDA
(siglas en inglés de Personal Digital Assistant) y por otro, se hayan integrado mayores capacidades
1. Introducción 3
Figura 1.1: Eventos relevantes en el mercado de telecomunicaciones en México
de cómputo, ası́ como nuevas interfaces de comunicaciones.

Los avances de las tecnologı́as de comunicaciones han permitido integrar en computadoras
portables interfaces inalámbricas que les facilitan la comunicación en red, incluso cuando el
usuario está en movimiento. Las computadoras móviles conectadas en red son parte de una mayor
infraestructura de cómputo; El cómputo móvil o el uso de una computadora portable capaz de
conectarse a una red inalámbrica ha revolucionado la manera en que utilizamos las computadoras.
En la actualidad existen distintas aplicaciones que son desarrolladas para entornos de cómputo móvil,
utilizando las tecnologı́as adicionales (como son el Wi-Fi, GPRS, Bluetooth, etc.) que han sido
incorporadas a los distintos dispositivos móviles, para los cuales las redes inalámbricas son una parte
fundamental, ya que mejoran la utilidad de los dispositivos de cómputo portables [18].
El creciente número de aplicaciones para dispositivos móviles ha generado una explosión en
los diferentes tipos de archivos que dichos dispositivos pueden almacenar: imágenes, vı́deos, texto,
programas, audio, etc. Internet se ha convertido en un medio para interconectar todo tipo de
dispositivos, los dispositivos móviles no son la excepción. El uso de las nuevas tecnologı́as hace
que los dispositivos móviles de hoy en dı́a sean capaces de ejecutar aplicaciones que generan una
gran cantidad de archivos, por lo que cada vez más se requiere que dichos dispositivos cuenten con
una mayor capacidad de almacenamiento. Desafortunadamente, la capacidad de almacenamiento en
estos dispositivos no ha crecido al ritmo que sus aplicaciones lo requieren.
4 1.2. Descripción del problema
Figura 1.2: Usuarios desde 1990 hasta 2008 según COFETEL
1.2 Descripción del problema
Una vez que los dispositivos móviles exceden su capacidad de almacenamiento, presentan la
necesidad de descargar sus archivos (tales como textos, imágenes, música, vı́deos, etc.) a sistemas
de almacenamiento externos (por ejemplo una computadora), con el fin de respaldar su información.
Este proceso limita la movilidad de los usuarios, ya que es necesario conectarse al dispositivo externo
a través de cables (USB) o acercarse lo suficiente al mismo para acceder a través de redes de corto
alcance como infrarrojo o Bluetooth.
Este problema de almacenamiento reduce la movilidad de los usuarios ya que de vez en cuando
tienen que acercarse a su sistema de almacenamiento fijo. Especialmente cuando se trata con
aplicaciones para fotos y vı́deos. Por lo tanto, se enfatiza la necesidad de desarrollar mecanismos que
permitan de forma transparente la transferencia de archivos desde un dispositivo móvil a un servidor,
considerando su disponibilidad de comunicación y de espacio, independientemente de la ubicación
1. Introducción 5
del usuario, tomando en cuenta la disponibilidad de los distintos medios de comunicación y valorando
el costo que ésta supone.
Debido a que existen diferentes dispositivos móviles que trabajan con distintas plataformas de
cómputo, no se presenta factible desarrollar una herramienta propietaria para una plataforma en
particular, ya que ésta restricción limitarı́a su capacidad de uso. Es por eso que el diseño de una
solución a este problema debe contemplar el aspecto multiplataforma1 que le permita mayor cobertura
en diferentes dispositivos móviles.
Existen varios protocolos y aplicaciones que permiten manipular archivos a través de Internet,
tales como FTP [38], HTTP [17], GMail Drive [21] (Windows), GMail FS [22] (Linux), etc. Estos
protocolos y aplicaciones permiten crear un sistema de almacenamiento de red, el cual se puede
acceder desde cualquier computadora que tenga acceso a Internet a través de una red cableada o vı́a
Wi-Fi, independientemente de dónde esté localizado el dispositivo, sin tener que preocuparse por el
servidor.
A pesar de que este tipo de protocolos y aplicaciones hacen uso de la transferencia de archivos
a través de Internet, muy pocos han sido adaptados (como GSpaceMobile [23], emoze [15] y
MobileMe [24])2 para funcionar en dispositivos móviles como PDAs, teléfonos celulares, etc. A su
vez, aplicaciones y protocolos como estos sólo permiten el intercambio de información a través de
Internet, ya sea conectado a una red cableada o vı́a Wi-Fi, lo que hace que el trabajo orientado a
redes de baja velocidad sea muy limitado.
1.3 Objetivos
Hoy en dı́a la comunicación entre plataformas heterogéneas es muy común, además de la

constante demanda de aplicaciones cliente/servidor, por lo que surge la necesidad de desarrollar
herramientas que faciliten el desarrollo de dichas aplicaciones y que a su vez puedan ser utilizadas
1
Una aplicación multiplataforma, es aquella que tiene un único código base para múltiples sistemas operativos
[31].
2
En la sección de trabajos relacionados del capı́tulo 2 se describe cada una de las aplicaciones, mencionando las
diferencias y limitaciones con respecto a nuestro trabajo.
6 1.3. Objetivos
en las distintas plataformas. Lo anterior ha potenciado el uso de tecnologı́as conocidas como

middlewares. Un middleware es un software de conectividad que consiste en un conjunto de servicios
que permiten interactuar a múltiples procesos que se ejecutan en distintas máquinas a través de
una red. Proporciona un conjunto de APIs (siglas en inglés de Application Programming Interface)
más funcionales y pueden ser reutilizados en otras aplicaciones. La organización IETF (Internet
Engineering Task Force) en mayo de 1997 lo definió como sigue:
Un middleware puede ser visto como un conjunto reutilizable y ampliable de servicios y funciones
que son comúnmente utilizadas por muchas aplicaciones para funcionar bien dentro de un
ambiente interconectado [3]
Debido al contexto del problema que se presenta, en este proyecto es recomendable que el software
sea creado como un middleware, de tal manera que pueda ser reutilizado por distintas aplicaciones
y dispositivos, como un componente más, independientemente de la plataforma. De esta manera el
software desarrollado podrá ser reutilizado por los distintos dispositivos móviles que cumplan con los
requerimientos mı́nimos de hardware.
1.3.1 Objetivo general
El objetivo principal de este trabajo fue proponer e implementar una solución al problema de
almacenamiento en los dispositivos móviles que cuentan con recursos limitados, llevando a cabo el
desarrollo de un middleware que ofrezca portabilidad para ser utilizado por distintas aplicaciones y
dispositivos, y que dé mayor soporte a la movilidad.
1.3.2 Objetivos particulares
Como una forma de cumplir con el objetivo general, se definieron los siguientes objetivos
particulares:
Desarrollar un middleware para la transferencia de archivos, que permita el intercambio de

archivos (swap) entre el dispositivo móvil y un servidor de almacenamiento externo.
1. Introducción 7
Desarrollar una aplicación que haga uso del middleware (Swapper).
Desarrollar un módulo para validar la disponibilidad de conexión con la red Wi-Fi.
Diseminación de los resultados obtenidos durante el desarrollo de la tesis.
1.3.2.1. Metodologı́a
La metodologı́a que se ha utilizado para llevar a cabo el trabajo se puede dividir en 5 etapas
principales:
Revisión bibliográfica sobre las distintas tecnologı́as del cómputo móvil y evaluación de
arquitecturas de software que incluya los siguientes temas: redes inalámbricas (Wi-Fi, WLAN,
WWAN) y middlewares.
Análisis de requerimientos previo al desarrollo del software mediador (middleware) para la

transferencia de archivos vı́a Wi-Fi.
Desarrollo de un software mediador (middleware) que dé soporte a la transferencia de archivos

vı́a Wi-Fi, GPRS y a través de mensajes multimedia (MMS).
Desarrollo de una aplicación que utilice el middleware desarrollado anteriormente.
Evaluación de la aplicación y análisis de los resultados obtenidos.
1.4 Resumen
En este capı́tulo se da una descripción detallada sobre el contexto del proyecto; la evolución de
la telefonı́a móvil y cómo el número de usuarios se ha incrementado a un ritmo muy acelerado. Se
explica que conforme las tecnologı́as evolucionan, éstas han sido integradas en computadoras móviles,
hasta llegar a ser utilizadas en dispositivos más pequeños; los dispositivos móviles, que van desde el
primer teléfono celular desarrollado para su uso en automóviles, hasta los nuevos teléfonos y PDAs
que han incorporado las nuevas tecnologı́as.
8 1.4. Resumen
Finalmente se plantea como objetivo general el proponer e implementar una solución al problema
de almacenamiento en los dispositivos móviles que cuentan con recursos limitados, mediante la
utilización de un middleware que ofrezca portabilidad y de esta manera pueda ser utilizado por
distintas aplicaciones y dispositivos, dando mayor soporte a la movilidad.
Marco teórico y trabajos relacionados
2
En el capı́tulo anterior se presentó el objetivo general del presente trabajo de tesis; en él se propone
desarrollar un middleware que haga frente al problema del almacenamiento en los dispositivos móviles.
Para llevar a cabo el desarrollo del middleware, es necesario hacer un estudio sobre las distintas
tecnologı́as y servicios que existen actualmente para transmisión de datos en redes inalámbricas. Es
por esto que en el presente capı́tulo se hace un estudio sobre los distintos tipos de redes (IEEE 802.11,
GSM, GPRS) y servicios de mensajerı́a (SMS, MMS), además de presentar los trabajos relacionados
en el área.
2.1 Descripción de sistemas de comunicación inalámbrica
La tecnologı́a inalámbrica [52] ha ayudado a simplificar el trabajo con redes, permitiendo que
múltiples usuarios puedan compartir recursos sin tener que utilizar ningún tipo de cable adicional.
Dichos recursos pueden ser una conexión de banda ancha a Internet, una impresora en red, archivos
de datos, e incluso flujos de audio y vı́deo. Este tipo de compartición de recursos ha prevalecido
conforme los usuarios han cambiado los hábitos de utilizar una única computadora por el trabajo
9
10 2.1. Descripción de sistemas de comunicación inalámbrica
en red con múltiples computadoras, cada una potencialmente con diferentes sistemas operativos y
periféricos.
Actualmente, las comunicaciones inalámbricas [55] están rompiendo los vı́nculos que los usuarios
de Internet han tenido con las conexiones cableadas. La movilidad mientras se accede a Internet y la
incrementada flexibilidad están motivando que la tecnologı́a para redes inalámbricas tenga un gran
éxito. También, las WLANs (Wireless Local Area Networks) [43, 52] o redes inalámbricas de área
local pueden incluso (a veces) ser más económicas y eficientes que la instalación de redes cableadas
en todo un edificio. Con la promoción en el mercado de las tecnologı́as para redes inalámbricas, los
servicios y aplicaciones se están incrementando dı́a con dı́a.
Sin embargo, el crecimiento del mercado de las WLAN y los servicios también depende de las
polı́ticas y regulaciones de cada paı́s. Con pocas regulaciones se puede acelerar la expansión del
mercado de las WLAN pero también crearı́a problemas de interferencia. Por otra parte, ciertas
regulaciones estrictas podrı́an asignar bien el espectro de la señal, pero podrı́an impedir el desarrollo
del mercado.
Las tecnologı́as para redes inalámbricas fueron poco interesantes (e inmaduras) durante años,
hasta 1985, cuando la FCC (Federal Communications Commission) de los estados unidos autorizó las
bandas de frecuencia ISM (Industrial, Scientific and Medical). Estas tres bandas ISM aceleraron el
desarrollo de las WLANs debido a que los vendedores no necesitaron emplear más licencias para
sus productos. En 1989, el grupo de trabajo de la IEEE 802.11 comenzó la elaboración de las
especificaciones para el Control de acceso al medio y la capa fı́sica en redes LAN inalámbricas. El
borrador final fue ratificado el 26 de Junio de 1997.
En la Figura 2.1 se muestra el conjunto de redes que va desde las redes de área personal (PAN’s),
hasta las redes de área regional (RAN’s) [26]; en ésta se puede observar el alcance en metros o
kilómetros que tiene cada una de ellas, ası́ como su velocidad de transmisión.
Figura 2.1: Desde las redes PAN hasta las RAN.
2.1.1 WPAN
Las redes inalámbricas personales [2] (WPANs, Wireless Personal Area Networks) trabajan en un
espacio operativo personal (POS, Personal Operating Space) de 10m y son utilizadas para transmitir
información a cortas distancias entre un grupo privado de dispositivos participantes. A diferencia de
una red inalámbrica de área local (WLAN, Wireless Local Area Network), una conexión hecha a través
de una WPAN implica poca o ninguna infraestructura o conectividad directa con el mundo fuera del
enlace. Esto permite el desarrollo de soluciones pequeñas, baratas y que utilizan eficientemente la
energı́a para ser implementadas por una gran cantidad de dispositivos.
2.1.1.1. Bluetooth
El nombre de la tecnologı́a Bluetooth [47] fue oficialmente adoptado en 1998 por el Bluetooth
SIG (Special Interest Group) y en 1999 dicho grupo lanzó la primer especificación de éste. Bluetooth
pertenece al tipo de redes WPAN, cuenta con un POS de 10m y una pila de protocolos [44] como se
muestra en la Figura 2.2. El principio fundamental en el diseño de la pila de protocolos fue maximizar
la reutilización de protocolos existentes para diferentes propósitos en las capas superiores, en lugar de
reinventar la rueda una vez más. Ya que el reutilizar protocolos ayuda en la adaptación de aplicaciones
existentes para que funcionen con la tecnologı́a Bluetooth y ası́ garantizar la interoperabilidad de
dichas aplicaciones.
Bluetooth cuenta con una especificación abierta, lo que permite a los desarrolladores implementar
libremente sus propios protocolos en la cima de los protocolos especı́ficos de Bluetooth, aprovechando
al máximo las capacidades de esta tecnologı́a.
Figura 2.2: Pila de protocolos Bluetooth
La pila de protocolos Bluetooth puede ser dividida en cuatro capas de acuerdo a su propósito,
incluyendo el aspecto de si el Bluetooth SIG ha sido involucrado en el desarrollo de estos protocolos.
La Tabla 2.1 muestra la división de los protocolos por capas.
Capa del protocolo Protocolos en la pila

Protocolos núcleo de Bluetooth Banda base, LMP, L2CAP, SDP
Protocolo de sustitución de cable RFCOMM
Protocolos de control de telefonı́a TCS Binary, Comandos AT
Protocolos adoptados PPP, UDP/TCP/IP, OBEX, WAP, vCard, vCal, IrMC, WAE
Tabla 2.1: Las capas y protocolos en la pila de protocolos Bluetooth
Protocolos núcleo de Bluetooth: La banda base (Baseband) y la capa de control de enlace

(link controller ) permiten un enlace fı́sico de radiofrecuencia entre las unidades Bluetooth que
forman una piconet1 [46], dicha banda base es la responsable de formatear apropiadamente
los datos para transmisión desde y hacia la capa de radio, mientras que el link controller se
encarga de efectuar los comandos del gestor de enlace (establecer y mantener el enlace).
El protocolo gestor de enlace (LMP, Link Manager Protocol) se encarga de establecer la
conexión entre los dispositivos Bluetooth, incluyendo aspectos de seguridad como autenticación
y encriptación. También se encarga de controlar los cambios de potencia y ciclos de trabajo
del dispositivo de radio Bluetooth y los estados de conexión de una unidad Bluetooth en una
piconet. La interfaz controladora de anfitrión (HCI, Host Controller Interface) proporciona
una interfaz de comandos para el controlador de banda base, el gestor de enlace, además de
permitir el acceso a los registros de control y al estado del hardware.
L2CAP (Logical Link Control and Adaptation protocol) adapta los protocolos de las capas
superiores a la banda base, proporciona servicios de datos orientados y no orientados a conexión
a los protocolos de capas superiores y cuenta con capacidades de multiplexación de protocolo,
operaciones de segmentación y reensamblado y abstracciones de grupo, además permite a los
protocolos y aplicaciones de nivel superior transmitir y recibir paquetes de datos de hasta 64
kilobytes de longitud.
Finalmente el protocolo de descubrimiento de servicios (SDP - Service Discovery Protocol) es
fundamental dentro de la estructura Bluetooth, ya que proporciona las bases para todos los
modelos de uso. Al utilizar SDP es posible consultar la información del dispositivo, los servicios
y sus caracterı́sticas, para posteriormente establecer una conexión entre dos o más dispositivos
Bluetooth.
Protocolo de sustitución de cable: RFCOMM [45] (Radio Frequency Communication)

es un protocolo de transporte que proporciona la emulación de puertos seriales (RS-232)
sobre el protocolo L2CAP, está basado en el estándar ETSI TS 07.10 y puede soportar hasta
60 conexiones simultáneas entre dos dispositivos Bluetooth, donde el número de conexiones
depende de la implementación.
1
Dos o más dispositivos que comparten el mismo canal fı́sico.
Protocolos de control de telefonı́a: El protocolo de control de telefonı́a - binario (TCS

Binary o TCS BIN) es un protocolo orientado a bits, que define el control de señalización
de llamadas para el establecimiento de llamadas de voz y datos entre dispositivos Bluetooth,
además define procedimientos para gestión de movilidad para manejar grupos de dispositivos
Bluetooth TCS.
Por otra parte, el Bluetooth SIG ha definido un conjunto de comandos AT con los cuales
un teléfono celular y un módem pueden ser controlados en los múltiples modelos de uso. Los
comandos AT que son utilizados en Bluetooth están basados en la recomendación ITU-T V.250
y el ETS 300 916 (GSM 07.07).
Protocolos adoptados: En la tecnologı́a Bluetooth, PPP ( IETF Point-to-Point Protocol)

está diseñado para correr sobre RFCOMM y llevar a cabo conexiones punto a punto.
Los protocolos TCP [11]/UDP [37]/IP [25] son utilizados dentro de la pila de protocolos
Bluetooth debido a que son estándares de protocolos definidos por la IETF (Internet
Engineering Task Force) y son utilizados para realizar conexiones a través de Internet. Son
considerados como la familia de protocolos más ampliamente utilizada en el mundo, los
protocolos TCP/IP han aparecido en numerosos dispositivos como impresoras, computadoras
de mano (handhelds computers) y teléfonos inteligentes (smartphones). El acceso a estos
protocolos es independiente del sistema operativo.
La implementación de dichos protocolos en dispositivos Bluetooth permite la comunicación
con cualquier otro dispositivo conectado a Internet, pudiendo ser utilizado como un puente a
Internet.
El protocolo OBEX es un protocolo de sesión desarrollado por IrDA (Infrared Data Association)
para intercambiar objetos de una manera simple y espontánea. OBEX proporciona la misma
funcionalidad básica que HTTP, pero de una manera más ligera, éste utiliza un modelo cliente-
servidor y es independiente del mecanismo de transporte.
2.1.2 WLAN
En la actualidad, un gran número de dispositivos están basados en el conjunto de protocolos

802.11x. El protocolo 802.11 comenzó como una extensión inalámbrica para redes de área local en
1997, siendo actualizada constantemente desde entonces. Dado que el protocolo fue construido para
trabajar en un espectro sin licencia del sistema de radio, no existe ninguna limitante para su uso; por
lo que ha favorecido a que sea el estándar dominante para los sistemas comerciales de comunicación
inalámbrica.
La IEEE publicó el estándar original IEEE 802.11 en 1997 como una especificación para un
esquema de transmisión y un protocolo de control de acceso al medio para redes inalámbricas de
área local (WLAN). Dos años más tarde, en septiembre de 1999, el estándar IEEE 802.11 fue revisado
oficialmente. Los primeros subestándares que extendieron el protocolo 802.11 fueron el 802.11a y
802.11b, los cuales se publicaron en paralelo en 1999.
El protocolo 802.11 define un conjunto de servicios básicos (BSS, Basic Service Set). El conjunto
cuenta con dos o más nodos o estaciones fijas, portables, y/o móviles que pueden comunicarse con
cualquier otra estación a través del aire en un área geográficamente limitada.
Dicho estándar especı́fica dos configuraciones:
Ad-hoc: También es referido como modo punto a punto (peer-to-peer) o un conjunto de

servicios básicos independiente (IBSS) como se ilustra en la Figura 2.3. El modo ad-hoc permite
a las estaciones móviles interconectarse directamente con cualquier otro sin el uso de un punto
de acceso. Todas las estaciones usualmente son equivalentes e independientes en la red ad-hoc.
Las estaciones pueden transmitir e inundar de paquetes el área de cobertura inalámbrica sin
tener acceso a Internet. La configuración ad-hoc puede ser utilizada fácil e inmediatamente
cuando los usuarios involucrados no puedan o no necesiten una infraestructura de red. Por
ejemplo, los participantes de una conferencia pueden configurar sus laptops como una red
inalámbrica ad-hoc e intercambiar datos sin mucho esfuerzo.
Con infraestructura: En el modo con infraestructura hay puntos de acceso que sirven de
puente entre las estaciones móviles y la red cableada (Figura 2.4).
Figura 2.3: Modo Ad-hoc
La Tabla 2.2 muestra una comparación entre varios estándares WLAN.
Ratificación Banda RF Max. tasa Capa fı́sica Rango tı́pico

de datos
IEEE 802.11 Jun. 1997 2.4GHz 2Mbps FHSS, DSSS, IR 50-100m
IEEE 802.11b Sept. 1999 2.4GHz 11Mbps DSSS/CCK 50-100m
IEEE 802.11a Sept. 1999 5GHz 54Mbps OFDM 50-100m
IEEE 802.11g Jun. 2003 2.4GHz 54Mbps OFDM, PBCC 50-100m
ETSI HIPERLAN/1 Principios 5GHz 23.5Mbps GMSK 50m
de 1996
ETSI HIPERLAN/2 Feb. 2000 5GHz 54Mbps OFDM 50m interior
300m exterior
MMAC HISWANa Abril 1999 5GHz 27Mbps OFDM 100-150m
Tabla 2.2: Comparación de varios estándares WLAN
2.1.3 WWAN
Una red inalámbrica de área extensa (WWAN, Wireless Wide Area Network) [43] cubre un área
mucho más amplia que una red inalámbrica LAN (WLAN, Wireless Local Area Network). Su área
Figura 2.4: Arquitecturas de red con infraestructura
de cobertura generalmente es del tamaño de una nación, cuenta con una infraestructura para redes
inalámbricas proporcionada por un proveedor de servicios , el cual recibe un pago mensual, similar a
una suscripción de telefonı́a celular.
Las redes WLAN son utilizadas para permitir a los usuarios de la red moverse dentro de un área
fija de cobertura, mientras que las redes WWAN son utilizadas para brindar acceso a Internet sobre
un área de cobertura mucho más amplia; para aquellos usuarios que viajan constantemente y que
necesitan tener acceso a Internet, e-mail, aplicaciones e información corporativa incluso mientras se
esta lejos de su oficina.
Las redes WWAN utilizan las redes de telefonı́a celular para la transmisión de datos, algunas de
estas redes son GSM, GPRS, UMTS.
2.1.3.1. Sistema global para comunicaciones móviles (GSM)
Antes de la introducción de GSM, las redes móviles implementadas en los distintos paı́ses
usualmente eran incompatibles. Con el paso del tiempo GSM fue mejorado por distintos grupos
e institutos como el SMG (Special Mobile Group), ETSI (European Telecommunications Standards
Institute), 3GPP, etc., hasta llegar a las redes GSM que actualmente utilizamos.
Algunas caracterı́sticas de la red GSM es que permite comunicaciones de voz digital y da

soporte para servicios de datos de baja tasa de transferencia, todo esto sobre conexiones de circuitos
conmutados (circuit-switched).
Los elementos principales de la arquitectura GSM se muestran en la Figura 2.5.
Figura 2.5: Arquitectura GSM.
La red GSM básicamente está formada por tres subsistemas llamados: Subsistema de estación
base (BSS), Subsistema de red (NSS) y el Subsistema de operación (OSS), éste último implementa
ciertas funciones que permiten la administración de la red móvil, y por motivos de claridad los
elementos que forman el OSS no se muestran en la arquitectura de la Figura 2.5.
A continuación se describen los elementos que conforman la red:
Estación móvil (ME): Es un dispositivo que recibe y transmite señales de radio dentro del área
de servicio celular, la estación móvil puede ser un teléfono móvil básico, un PDA o un teléfono
inteligente. Las capacidades de un teléfono móvil básico incluyen comunicaciones por voz,
caracterı́sticas de mensajerı́a y manejo de agendas electrónicas. Además de estas capacidades
adicionales, usualmente tanto los teléfonos inteligentes como los PDAs están equipados con un
micronavegador para Internet y un avanzado manejador de información personal (PIM, Personal
Information Manager) para manejar contactos y calendarización/asignación de entradas.
La estación móvil está compuesta por el Equipo Móvil (ME) y el Módulo de Identidad de
Suscriptor (SIM por sus siglas en inglés). El SIM (Figura 2.6) usualmente es proporcionado
al suscriptor por el operador de la red en la forma de una tarjeta inteligente. El microchip se

desprende de la tarjeta inteligente y es insertado directamente en una ranura especı́fica del
dispositivo móvil.
Actualmente las estaciones móviles pueden ser conectadas a ciertos dispositivos externos como
puede ser una computadora personal. Este dispositivo externo es llamado Equipo terminal (TE)
en la arquitectura GSM.
Figura 2.6: Microchip SIM.
Subsistema de estación base (BSS): Está formado por varias BTS’s (Estación transceptora
base) y un Controlador de estación base (BSC).
La estación transceptora base implementa las interfaces de comunicaciones aéreas con todas
las estaciones móviles ubicadas dentro de su área de cobertura (sitio de la célula). Esto incluye
modulación/demodulación de señales, compensación de señales y codificación de errores. Varias
BTSs pueden estar conectadas a un único controlador de estación base.
El BSC proporciona un conjunto de funciones para manejar conexiones de BTSs bajo su control.
Dichas funciones permiten operaciones como el handover 2 , configuración del sitio de la celda,
manejo de recursos de radio y ajuste de los niveles de potencia de la radio frecuencia del BTS.
Subsistema de red: Está formado por un Registro de Ubicación Base (HLR, Home Location
Register ), una Central de conmutación móvil (MSC, Mobile Switching Center ) y un registro
de ubicación de visitante (VLR, Visitor Location Register ).
El registro de ubicación base es un elemento de la red que contiene los detalles de suscripción
de cada suscriptor, puede manejar la información de cientos o miles de suscriptores.
2
Cambio de una red a otra.
La central de conmutación móvil efectúa las funciones de conmutación de comunicaciones del

sistema y es responsable del establecimiento de llamada, liberación y enrutamiento. También
proporciona funciones para el servicio de facturación y para la interconexión con otras redes.
Finalmente, el registro de ubicación de visitante contiene información dinámica acerca de los

usuarios que están adjuntos a la red móvil, incluyendo la ubicación geográfica del usuario. EL
VLR usualmente esta integrado al MSC.
2.1.3.2. Servicio general de radio paquetes (GPRS)
El servicio general de radio paquetes (GPRS, General Packet Radio Service) es una extensión de
la red GSM que permite a los suscriptores enviar o recibir datos sobre una conexión de conmutación
de paquetes (packet-switched). El uso de GPRS es apropiado para aplicaciones con las siguientes
caracterı́sticas:
Transmisiones frecuentes de pequeñas cantidades de datos
Transmisiones infrecuentes de grandes cantidades de datos
Estas aplicaciones usualmente no necesitan comunicarse permanentemente. Por consecuencia, la

reservación continua de recursos para realizar una conexión de circuitos conmutados no representa
una manera eficiente de explotar los escasos recursos de radio. El concepto básico detrás de una
transmisión GPRS de paquetes conmutados está en su habilidad para permitir a las aplicaciones
seleccionadas compartir recursos de radio, asignándoles solamente dichos recursos de transmisión
cuando las aplicaciones tengan datos que transmitir. Una vez que los datos han sido transmitidos por
una aplicación, los recursos de radio son liberados para que sean utilizados por otras aplicaciones. Los
escasos recursos de radio son utilizados de manera más eficiente con este mecanismo. GPRS permite
que más recursos de radio sean asignados a una conexión basada en paquetes en comparación con
una conexión de circuitos conmutados GSM.
En la Figura 2.7 se muestran los elementos principales de la arquitectura GPRS. Una estación
móvil GPRS esta categorizada de acuerdo a sus capacidades para soportar modos simultáneos de
operación para GSM y GPRS, los cuales se muestran a continuación:
Clase A: La estación móvil soporta uso simultáneo de servicios GSM y GPRS (activación,
monitoreo, transmisión, etc.). Una estación móvil de clase A puede establecer o recibir llamadas
de los dos servicios simultáneamente. La alta complejidad para diseñar dispositivos de clase A
hace que sea prohibitivamente caro producirlo y por lo tanto, estos dispositivos generalmente
no están disponibles para el mercado mundial.
Clase B: La estación móvil se encuentra adjunta a ambos servicios GSM y GPRS. Sin embargo,
la estación móvil solamente puede operar en uno de los dos servicios a la vez.
Clase C: La estación móvil se encuentra adjunta a cualquiera de los dos servicios GSM o GPRS
pero no en ambos servicios al mismo tiempo. Previo al establecimiento o recepción de una
llamada en uno de los dos servicios, la estación móvil tiene que estar explicitamente adjunta
al servicio deseado.
Antes de que una estación móvil pueda acceder a los servicios GPRS, ésta debe ejecutar un
procedimiento de adjunción GPRS (GPRS attachment) para indicar su presencia en la red. Después
de su adjunción a la red GPRS, la estación móvil activa un contexto PDP (Packet Data Protocol) con
la red con el fin de ser capaz de transmitir o recibir datos. Este procedimiento es llamado contexto
de activación PDP.
La interfaz aérea GPRS es idéntica a la de la red GSM (misma modulación de radio, bandas de
frecuencia y estructura de la trama). GPRS esta basado en un evolucionado subsistema de estación
base GSM. Sin embargo, el núcleo de la red GPRS se basa en un subsistema de red GSM en el cual
se han integrado dos elementos de red adicionales que se describen a continuación.
Nodo de soporte de servicio GPRS (SGSN): El SGSN esta conectado a uno o más subsistemas
de estación base. Éste opera como un router de paquetes de datos para todas las estaciones
móviles en un área geográfica dada. También mantiene la pista de la ubicación de las estaciones
móviles y realiza funciones de seguridad y control de acceso.
Nodo de soporte de pasarela GPRS (GGSN): El GGSN proporciona el punto de unión entre
el dominio GPRS y otras redes de datos como Internet o redes corporativas. Un nombre de
22 2.2. Descripción de sistemas de mensajerı́a
punto de acceso (APN, Access Point Name) es utilizado por el usuario móvil para establecer
la conexión a la red destino requerida.
Figura 2.7: Arquitectura GPRS.
2.2 Descripción de sistemas de mensajerı́a

El servicio de mensajes cortos (SMS) apareció en 1992, fue desarrollado como parte de las
especificaciones técnicas de la fase 1 GSM del ETSI (European Telecommunications Standards
Institute). A partir de su introducción en redes GSM, SMS ha sido portado a otras tecnologı́as
de redes tales como GPRS, CDMA y UMTS [8]. Desde su creación, el uso del servicio SMS ha
crecido de manera muy rápida, éste permite a los usuarios intercambiar mensajes que contienen
una pequeña cantidad de texto, dichos mensajes pueden ser enviados desde dispositivos móviles que
utilicen las distintas tecnologı́as mencionadas.
MMS (Multimedia Messaging Service) es un sofisticado servicio de mensajerı́a multimedia, se
considera el mejor de los diferentes tipos de servicios de mensajerı́a, como lo son el servicio de
mensajes cortos (SMS), el servicio de mensajes mejorado (EMS), y el correo por Internet [8], funciona
utilizando el paradigma de store-and-forward.
MMS es un intento de proporcionar a los suscriptores de servicios un mejor conjunto de contenidos
en el contexto de mensajerı́a, éste no es considerado como un sistema de entrega en tiempo real [19].
Su oportunidad inicial de mercado se basó principalmente en la disponibilidad de teléfonos celulares

con pantallas a color, cámaras digitales y la introducción de comunicaciones basadas en paquetes
en las redes móviles. Las primeras implementaciones de MMS permitieron a los usuarios móviles
el intercambio de mensajes multimedia no sólo con otros usuarios móviles, si no que también con
usuarios de Internet, proporcionando modos de direccionamiento a correos electrónicos y números
telefónicos.
2.2.1 Servicio de mensajes cortos (SMS)
Para la introducción del servicio de mensajes cortos en las arquitecturas de red actuales (GSM,
GPRS o UMTS), se necesita integrar algunos elementos adicionales. La Figura 2.8 muestra la
arquitectura de una red GSM habilitada para el manejo de SMS’s.
Figura 2.8: Arquitectura GSM habilitada para el manejo de SMSs.
En la figura 2.8 se puede observar los dos elementos agregados a la arquitectura de la red, siendo
uno de ellos la central de servicios de mensajes cortos (SMSC), que es la encargada de retransmitir
los mensajes entre las entidades de mensajes cortos (SMEs3 ) y manejar el almacenamiento y
retransmisión de los mensajes si la SME receptora no está disponible.
Para lograr la interoperabilidad entre el servicio de mensajes cortos y el correo electrónico por
Internet, se hace uso del otro nuevo elemento, una pasarela de correo electrónico (Email Gateway),
3
SME (Short Message Entities), elementos que pueden enviar o recibir mensajes cortos.
la cual interconecta el SMSC con la Internet. Con esta pasarela, los mensajes pueden ser enviados
desde una SME a un host en Internet y viceversa. El papel de la pasarela de correo electrónico es
convertir los formatos de mensajes (de SMS a correo electrónico y viceversa) y transmitir mensajes
entre SMS y dominios en Internet.
2.2.2 Arquitectura MMS
La arquitectura cuenta con los elementos requeridos para manejar dispositivos MMS y el envı́o
de mensajes multimedia de acuerdo a las instrucciones del proveedor de servicios o del usuario en
un entorno de múltiples proveedores. Los elementos de la red se comunican a través de un conjunto
de nueve interfaces, los protocolos de interacción para varios de ellos han sido estandarizados para
garantizar una máxima interoperabilidad mientras que otros aún están sujetos a implementaciones
propietarias. Dicha arquitectura abarca el software de mensajerı́a en el teléfono MMS4 , el cual es
requerido para la composición, envı́o y recuperación de mensajes multimedia [8]. La Figura 2.9
muestra la arquitectura general MMS.
2.2.2.1. Entorno MMS
Entorno MMS (MMSE) se refiere al conjunto de elementos MMS que están bajo el control
de una administración única (Proveedor MMS, e.g., el operador de telefonı́a móvil), encargado de
proporcionar el servicio MMS a los suscriptores.
2.2.2.2. Cliente MMS
El Cliente MMS5 es el software suministrado con el teléfono móvil que permite la composición,
visualización, envı́o y recuperación de mensajes multimedia. En el intercambio de mensajes
multimedia, el cliente que genera y envı́a el mensaje se conoce como cliente creador MMS y el
que recibe el mensaje se conoce como cliente receptor MMS.
Algunas caracterı́sticas con las que cuenta un cliente MMS son:
4
Dispositivo móvil con capacidad para manejar mensajes multimedia.
5
También conocido como MMS User Agent en la terminologı́a 3GPP.
Gestión de mensajes, notificaciones y reportes
Composición de mensajes
Visualización de mensajes
Configuración de preferencias de usuarios y ajustes de conectividad
Figura 2.9: Arquitectura MMS [8].

2.2.2.3. Centro MMS (MMSC)
El MMSC6 es un elemento clave dentro de la arquitectura MMS, está compuesto por un MMS
relay y un servidor MMS (MMS server), los cuales se encargan tanto de almacenar y manejar los
mensajes multimedia entrantes y salientes, y de garantizar la interoperabilidad con otros sistemas de
mensajerı́a [8] por medio de distintas interfaces de comunicación (por ejemplo la interfaz MM3). El
MMS relay se encarga de encaminar los mensajes tanto dentro y fuera del MMSE, mientras que el
MMS server se encarga de almacenar los mensajes.
2.2.2.4. Interfaces
En el entorno MMS, los elementos de la red se comunican a través de un conjunto de interfaces.

Varias interfaces han sido estandarizadas con el fin de garantizar interoperabilidad entre sistemas
diseñados por distintos fabricantes. Algunas otras interfaces están aún por ser estandarizadas y están
por lo tanto sujetas a implementaciones propietarias.
Las interfaces utilizadas en la arquitectura son referenciadas de acuerdo con la convención de
nombres del 3GPP (Third Generation Partnership Project) (MM1, MM2, etc.):
Interfaz MM1: Permite la interacción entre el cliente MMS (se encuentra en el dispositivo
móvil) y el MMSC, permitiendo el envı́o y recuperación de mensajes sobre ésta interfaz.
Interfaz MM2: Se encuentra entre los dos elementos internos que componen el MMSC: MMS
server y MMS relay. También se conoce como interfaz MMSS en los estándares WAP/OMA.
Interfaz MM3: Interfaz que se encuentra entre un MMSC y los servidores externos, permite
el intercambio de mensajes entre centros MMS (MMSC’s) y servidores externos como son los
servidores de correo electrónico y los centros SMS (SMSC’s).
Interfaz MM4: Es la interfaz puente entre dos MMSC’s, la cual es necesaria para el intercambio
de mensajes multimedia entre diferentes entornos MMS (e.g., entre dos redes móviles distintas).
6
El MMSC también es conocido como el MMS Proxy/Relay (estándares WAP/OMA) o el MMS Relay/Server
(estándares 3GPP) [8].
Interfaz MM5: Permite la interacción entre el MMSC y otros elementos de la red. Por ejemplo,
pedir información al Registro de Ubicación de Hogar (HLR - Home Location Register) para
encaminar un mensaje.
Interfaz MM6: Permite la interacción entre el MMSC y las bases de datos de los usuarios. Aún
esta por estandarizar.
Interfaz MM7: Es la interfaz que se encuentra entre el MMSC y las aplicaciones de servicios de
valor añadido (VAS por sus siglas en inglés). Permite a las aplicaciones VAS hacer peticiones
al MMSC (envı́o de mensajes, etc.) y obtener mensajes desde clientes MMS remotos.
Interfaz MM8: Permite la interacción entre el MMSC y el sistema billing7 del operador.
Interfaz MM9: Proporciona la interacción entre el MMSC y el sistema de carga en lı́nea. Con
esta interfaz, el MMSC puede consultar si los clientes de prepago tienen suficientes fondos en
su cuenta para consumir los servicios requeridos.
Interfaz MM10: Se encuentra entre el MMSC y el MSCF (Messaging Service Control Function).
El MMSC solicita al MSCF ejecutar algún servicio lógico especı́fico de mensajerı́a que puede
influenciar el direccionamiento, encaminamiento y carga de mensajes multimedia.
El Standard Transcoding Interface: Permite la interacción entre el MMSC y el Transcoding

Server, el cual es responsable de adaptar los contenidos del mensaje multimedia de acuerdo a
las capacidades de los clientes MMS receptores.
2.3 Trabajos relacionados
Los trabajos que se relacionan con nuestro proyecto de tesis son aquellos que tratan de proveer
servicios de transmisión de archivos desde dispositivos móviles hacia servidores de almacenamiento
externo, con el fin de respaldar información.
7
El sistema billing produce las facturas de los suscriptores MMS.
28 2.3. Trabajos relacionados
Un sistema de archivos para entornos distribuidos a gran escala es Coda, éste proporciona
replicación del lado del servidor, permite el acceso a los datos aún en estados de desconexión y se
enfoca en desconexiones a largo plazo, las cuales ocurren más frecuentemente en entornos de cómputo
móvil. Odyssey es el sucesor de Coda, el cual ha sido mejorado introduciendo comportamientos
dependientes de la aplicación y conocimiento del contexto (context-awareness) que permiten el uso
de estos enfoques en configuraciones de cómputo móvil. El sistema Bayou [13] es una plataforma para
construir aplicaciones colaborativas, su énfasis está en soportar la detección y resolución de conflictos
en aplicaciones especı́ficas. Éste ha sido diseñado como un sistema para soporte de compartición de
datos entre usuarios móviles y está destinado a ejecutarse en entornos de cómputo móvil8 . El sistema
utiliza un esquema de replicación llamado read-any/write-any, por lo que los datos replicados son
débilmente consistentes. A diferencia de los sistemas mencionados anteriormente, Bayou explota el
conocimiento de las aplicaciones para realizar procedimientos de unión y verificación de dependencias.
Lui et al [29] proponen un sistema de archivos móvil llamado NFS/M, basado en el sistema de
archivos NFS 2.0 y la plataforma Linux. Éste soporta caché de datos del lado del cliente con el fin
de mejorar el rendimiento del sistema, reduciendo la latencia durante perı́odos de conexión débiles.
Atkin y Birman [4] proponen otro sistema de archivos móvil llamado MAFS que, al igual que NFS/M,
también soporta caché del lado del cliente. Pero además, MAFS incorpora adaptación automática al
ancho de banda disponible.
Por otra parte, XMIDDLE [30] es un middleware para cómputo móvil diseñado para ayudar en
la construcción de aplicaciones móviles que utilicen replicación y reconciliación de datos en redes
ad-hoc; permite que dispositivos móviles como PDAs, laptops, etc. puedan compartir documentos
dentro de una red WLAN ad-hoc. Habilita la compartición transparente de documentos XML (que
contienen información especı́fica de la aplicación que hace uso del middleware), todo esto a través de
hosts móviles heterogéneos, permitiendo el acceso a los datos tanto de manera on-line como off-line.
Los autores realizaron la implementación de la plataforma del middleware ası́ como una aplicación
móvil de e-shopping 9 colaborativo llamada AddressBook, la cual hace uso del middleware.
8
Los autores comentan que la arquitectura no ha sido totalmente implementada, por lo que el trabajo con
dispositivos móviles como PDAs queda como trabajo futuro.
9
Compra electrónica.
Todos los sistemas de archivos y plataformas mencionados anteriormente, trabajaron con

problemas orientados a la compartición de datos en entornos de cómputo distribuido. Todos estos
tratan de maximizar la disponibilidad de los datos utilizando replicación, cada uno de ellos difiere
en la forma en que mantiene la consistencia en las réplicas. Sin embargo, solamente el último
(XMIDDLE); el cual al igual que nuestro trabajo, también es un middleware que permite el desarrollo
de aplicaciones para dispositivos móviles, siendo sus caracterı́sticas la compartición, replicación y
reconciliación de documentos XML, trabajó en dispositivos móviles como PDAs10 y a diferencia
de nuestro middleware que trabaja con redes Wi-Fi, GPRS y servicios de mensajerı́a como MMS;
XMIDDLE solamente trabaja con redes WLAN ad-hoc, además de solamente compartir información
a través de documentos XML.
En [9], Boulkenafed e Issarny presentan un middleware basado en servicios que permite la
compartición de archivos de forma colaborativa entre grupos ad-hoc que son formados dinámicamente
de acuerdo a la conectividad alcanzada por la WLAN ad-hoc. Este middleware permite compartir
y manipular datos comunes de una manera colaborativa, sin necesitar alguna infraestructura
establecida. Ellos implementaron el middleware dentro de un sistema de archivos con el fin de
evaluarlo, el resultado fue un sistema de archivos distribuido para la compartición móvil de datos de
manera ad-hoc. Vale la pena mencionar que las medidas de rendimiento realizadas por los autores
fueron hechas sobre una plataforma de diez computadoras portátiles y que solamente utilizaron
una red WLAN IEEE 802.11b en modo ad-hoc, a diferencia de nosotros, que utilizamos tanto la
red Wi-Fi como la red GSM o GPRS gracias a las nuevas tecnologı́as incorporadas en los actuales
dispositivos móviles (PDA’s, smartphones, etc.). Por otra parte, Belimpasakis et al [5] proponen
un middleware para la compartición de contenido para dispositivos móviles utilizando diferentes
protocolos (UPnP, Atom y WebDAV), proporcionando interfaces para las aplicaciones con el fin
de permitir a los desarrolladores crear aplicaciones con capacidades para compartir contenido. El
middleware mencionado hace uso tanto de la red Wi-Fi como de la red GPRS. Sin embargo, ellos no
consideran la transmisión de archivos a través de sistemas de mensajerı́a como MMS, ni el tema de
la portabilidad. Es por esto que en el presente trabajo de tesis se decidió desarrollar un middleware,
10
Utilizaron una Compaq iPAQ PDA con el sistema operativo Linux en su implementación.
el cual una de sus caracterı́sticas principales es la portabilidad.

A su vez, también existen varias aplicaciones como GSpaceMobile [23], EmozeTM [15] y MobileMe
[24] que permiten la transferencia de archivos entre dispositivos móviles y servidores externos, sin
embargo, todas estas son aplicaciones comerciales que no pueden ser utilizadas como una API para el
desarrollo de nuevos productos. Debido a que estas aplicaciones tienen un funcionamiento similar al
que ofrece nuestro servicio de almacenamiento externo, se describen con más detalle a continuación:
GSpaceMobile es una aplicación desarrollada por Palmblogfast software, que permite a los
usuarios que cuentan con dispositivos móviles de la serie S60 3a edición de Nokia, disponer
del espacio de almacenamiento que la empresa google a través de Gmail proporciona para los
usuarios registrados en su servicio de correo electrónico. Dicha aplicación es una herramienta
para transferir archivos entre un dispositivo móvil y una cuenta en el servidor Gmail, generando
un espacio de almacenamiento virtual extra (una nueva unidad) en el dispositivo y permitiendo
el envı́o y recepción de archivos entre el dispositivo y la cuenta Gmail. Para poder utilizar la
aplicación es necesario tener al menos una cuenta de correo electrónico de Gmail.
La Figura 2.10 muestra el menú de GSpaceMobile en el dispositivo móvil:
Figura 2.10: Menú de GSpaceMobile
Si se cuenta con la versión gratuita, solamente permite utilizar una cuenta de correo de Gmail,
por lo que sólo es posible generar una sola unidad virtual en el dispositivo. Por otra parte, la
versión con licencia permite utilizar múltiples cuentas de correo, permitiendo la creación de
múltiples unidades virtuales que según en las especificaciones del producto afirman que son
ilimitadas.
Algunas desventajas de GSpaceMobile son que depende del servidor de correo electrónico
de Gmail, además de que esta aplicación solamente puede ser instalada en una plataforma
especı́fica, que en éste caso es la plataforma S60 de Nokia que cuenta con su propio
sistema operativo móvil llamado Symbian. A diferencia de nuestro middleware que puede ser
utilizado siempre que se cuente con la máquina virtual de Java y las APIs necesarias para su
funcionamiento.
EmozeTM es una aplicación comercial que permite la sincronización bidireccional de contenido

entre servidores de correo electrónico corporativos y dispositivos móviles, sin la necesidad de
duplicar la información en servidores intermedios (conocido como store and forward).
La arquitectura presentada por emoze (Figura 2.11), se basa en tres componentes principales:
• Emoze Enterprise Server
• Emoze global gateway
• Emoze mobile client
La arquitectura de emoze proporciona la transferencia de datos, los cuales son encriptados

utilizando estándares de encriptación y compresión de datos para ahorrar los recursos de la red
y el dispositivo, minimizando el costo de la transmisión de datos.
Algunos de los servidores de correo electrónico con los que Emoze funciona son Gmail, Yahoo,
Windows Live/Hotmail, además de trabajar con las cuentas de correo proporcionadas por el
ISP (Internet Service Provider ) de los clientes, trabajando con los protocolos POP3 e IMAP4.
Sus desventajas, al igual que GSpaceMobile es que depende de servidores de correo electrónico
de terceros, al menos que el cliente cuente con su propio servidor.
MobileMe es un servicio desarrollado por Apple que actualiza automáticamente el estado de

correo electrónico, contactos y eventos del calendario en ciertos productos de la empresa, como
Figura 2.11: Arquitectura de EmozeTM
son el iPhone, Mac y PC, logrando que estén sincronizados.
Para el manejo de correos electrónicos, contactos y calendarios, MobileMe guarda toda

la información de éstos utilizando tecnologı́a push11 (Figura 2.12), permitiendo que los
dispositivos del usuario permanezcan sincronizados.
Cuando un usuario se suscribe a MobileMe, obtiene una cuenta de correo electrónico en me.com
que está siempre actualizada, e.g., los nuevos mensajes son actualizados automáticamente en el
iPhone, a la vez que se notifica en el momento en que lleguen. La suscripción incluye 20 GB de
espacio de almacenamiento para guardar correos electrónicos, fotos, etc. Se puede configurar
que cantidad de los 20 GB se quiere asignar a Mail y cuánto a iDisk.
iDisk permite almacenar, tener acceso y compartir archivos en lı́nea como si fuera un disco
virtual, en el que todo lo que es almacenado en éste, podrá ser descargado usando un navegador
web en cualquier computadora, iPhone, etc.
11
La información es enviada a un servidor, que al momento de detectar un nuevo contenido se encarga de
sincronizarla con los demás dispositivos (iPhone, Mac, PC).
Figura 2.12: Sincronización de MobileMe
MobileMe tiene como desventaja el que solamente funcione con los servidores de correo de
Apple, a diferencia de Emoze que puede funcionar con distintos servidores de correo electrónico.
Finalmente, todos estos productos (GSpaceMobile, Emoze y MobileMe) tienen como desventaja
general el que son productos finales que, a diferencia de nuestro middleware, no permiten el desarrollo
de nuevas aplicaciones además de ser software comercial.
2.4 Resumen
Actualmente existe una gran variedad de tecnologı́as que dan lugar al desarrollo de nuevas
aplicaciones. Por un lado están las actuales tecnologı́as inalámbricas, tales como las redes IEEE
802.11, IEEE 802.11b, GPRS, etc., las cuales han ayudado a simplificar el trabajo con redes,
permitiendo la compartición de datos o recursos (conexión a Internet, impresora en red, etc.) de
una manera más sencilla, eliminando el uso de cables. La movilidad mientras se navega en Internet y
la incrementada flexibilidad están motivando que la tecnologı́a para redes inalámbricas tenga un gran
éxito, e.g., las redes inalámbricas de área local o WLANs, algunas veces pueden ser más económicas
34 2.4. Resumen
y eficientes que la instalación de redes cableadas. Por otra parte tenemos los servicios de mensajerı́a,
como son el SMS, MMS, éstos servicios han sido incorporados a las diferentes tecnologı́as de redes
como el GSM y GPRS. Dichos servicios, desde su creación; en especial el servicio SMS, han crecido
de manera muy rápida, permitiendo a los usuarios que cuentan con un dispositivo móvil intercambiar
mensajes que pueden contener una pequeña cantidad de texto - SMS’s - o que incluyan texto,
imágenes, vı́deos, etc. - MMS’s -.
En este capı́tulo se presentaron las diferentes tecnologı́as y servicios que son parte fundamental
en el presente trabajo de tesis, ası́ como algunos trabajos relacionados que enfrentan el problema de
la compartición de datos con un enfoque distribuido a través de distintas metodologı́as, tales como
el uso de middlewares.
Arquitectura del Middleware
3
En este capı́tulo se describe la arquitectura del middleware propuesto en nuestra metodologı́a.
El middleware hace frente al problema de almacenamiento en los dispositivos móviles a través de la
transferencia de archivos entre un dispositivo y un servidor utilizando distintas redes o servicios de
comunicación.
3.1 Requerimientos para el diseño de la arquitectura

Para el correcto funcionamiento de la arquitectura se contemplaron algunos requerimientos
mı́nimos para su desarrollo. En las siguientes subsecciones se explican de una manera más detallada.
3.1.1 Requerimientos lado cliente (dispositivo móvil)
Del lado cliente se debe contar principalmente con la máquina virtual de Java ME, además de lo
siguiente:
CLDC 1.1 (Connected Limited Device Configuration 1.1 ): La configuración CLDC es una parte
fundamental de la arquitectura J2ME; ésta es la base para los perfiles.
35
36 3.1. Requerimientos para el diseño de la arquitectura
Una configuración de la plataforma J2ME especifica un subconjunto del lenguaje de

programación Java, el subconjunto de funcionalidad de la configuración de la máquina virtual
de Java, las caracterı́sticas de seguridad y redes, ası́ como el núcleo de librerı́as de la plataforma,
todo lo necesario para soportar una gran cantidad de productos [48].
MIDP 2.0 (Mobile Information Device Profile 2.0 ): Un perfil J2ME define conjuntos de APIs
especı́ficos para cierto dispositivo [51].
APIs J2ME requeridas:
• Wireless Messanging API 1.1 (JSR 120)
• Wireless Messanging API 2.0 (JSR 205)
• SATSA-CRYPTO (JSR 177)
• PDA Profile for J2ME (JSR 75)
3.1.2 Requerimientos lado servidor (PC)
Por otra parte, del lado servidor se requiere otras aplicaciones como:
MySQL [50]: Se necesita el gestor de bases de datos MySQL1 para manejar la base de datos
de usuarios utilizada por el middleware.
Java JRE [49]: Es necesario tener instalada la maquina virtual de Java2 .
Apache Tomcat [20]: También es necesario tener instalado el servidor de aplicaciones Java,
Apache Tomcat3 .
1
Versión utilizada: 5.0
2
3
3.2 Middleware para almacenamiento externo
Los dispositivos móviles actuales (e.g., teléfonos celulares), tienden a incluir diferentes accesorios y
aplicaciones como: editores de texto, hojas de cálculo, cámaras fotográficas y de vı́deo que usualmente
generan un gran número de archivos que pueden exceder la capacidad de almacenamiento de los
mismos. Esta limitante puede ser subsanada mediante el uso de un sistema de almacenamiento
externo (e.g., una PC), realizando copias de los archivos y de esta manera permitir que los dispositivos
móviles cuenten con nuevo espacio de almacenamiento disponible. El sistema común de respaldo en
los dispositivos móviles implica el uso de cables (USB) o redes inalámbricas de corto alcance como
Bluetooth o Infrarrojo. Este tipo de comunicación limita la movilidad de los usuarios. Esta situación
representa un reto para las aplicaciones móviles, ya que tienen que considerar diferentes aspectos
relacionados con los sistemas operativos y las diferentes tecnologı́as inalámbricas existentes. Ante esta
situación, un requerimiento evidente es el desarrollo de herramientas que faciliten la implementación
de aplicaciones móviles portables que sean capaces de ejecutarse en diferentes sistemas operativos
móviles y que tomen ventaja de las distintas tecnologı́as inalámbricas.
En esta sección se describe la arquitectura del middleware propuesto, el cual puede ser utilizado en
el desarrollo de futuras aplicaciones para dispositivos móviles. La arquitectura básicamente ofrece un
servicio de transferencia de archivos que hace transparente la red inalámbrica que se está utilizando.
La Figura 3.1 muestra la arquitectura; está compuesta de tres partes principales que se describen en
las siguientes subsecciones.
3.2.1 Lado cliente
El lado cliente cuenta con módulos que permiten al dispositivo interactuar con el servidor,
proporcionando las herramientas necesarias para el intercambio de archivos a través de distintas
redes de comunicación o utilizando servicios de mensajerı́a. A continuación se describe cada uno de
los módulos que se encuentran en el lado cliente del middleware.
38 3.2. Middleware para almacenamiento externo
Figura 3.1: Middleware para almacenamiento externo para dispositivos móviles.
3.2.1.1. API Cliente
El módulo API Cliente es utilizado directamente por las aplicaciones móviles para enviar y recibir
archivos de manera independiente a los servicios de comunicación disponibles. Este módulo ofrece
un conjunto de métodos que facilitarán a las aplicaciones móviles la recepción y transmisión de
archivos a través de redes inalámbricas como Wi-Fi y GPRS. El API también incluye servicios de
mensajerı́a como son el SMS y MMS; de esta manera el middleware permitirá que los desarrolladores
de aplicaciones puedan configurar el tipo de red a utilizar, considerando el servicio más económico
en términos del costo de servicio o el consumo de ancho de banda. Algunos de los métodos de
transmisión de datos que pueden ser utilizados por la aplicación son:
selecPath( ): Permite seleccionar directorios o archivos que se encuentran en el dispositivo con

el fin de ser utilizarlos por el middleware.
stor( ): Función que permite el envı́o de archivos al servidor utilizando las redes inalámbricas
disponibles (Wi-Fi o GPRS) o el servicio MMS.
retr( ): Función que permite obtener los archivos que han sido enviados al servidor, haciendo
uso de las mismas redes y servicios que stor( ).
3.2.1.2. Selección red/servicio
La capa de Selección red/servicio es un módulo que permite definir qué tipo de red o servicio
utilizar, o detectar de manera automática cuál de éstos se encuentra disponible, proporcionando
el método autoDetectConnection( ) para su detección. La red/servicio que se encuentre disponible
será utilizada para la transmisión de los datos. La Figura 3.2 muestra el diagrama de flujo del
algoritmo de selección de red/servicio. Las prioridades de selección fueron asignadas tomando en
consideración la velocidad de operación y el costo del servicio.
Por otra parte, la Tabla 3.1 muestra una comparativa de velocidad, ventajas y desventajas de las
redes inalámbricas y el servicio de mensajes multimedia.
Velocidad Ventajas Desventajas

WLAN Hasta 54Mbps Más económica Cobertura limitada (Metros)
GPRS Hasta 150Kbps Mayor cobertura (Kilómetros) Mayor costo, se factura por Kb
MMS × Mayor cobertura (Kilómetros) Incertidumbre en el tiempo de llegada
Tabla 3.1: Ventajas y desventajas de las redes inalámbricas y el MMS.

Figura 3.2: Algoritmo de selección de red/servicio disponible.
3.2.1.3. Módulos Wi-Fi y GPRS
Los módulos Wi-Fi/GPRS permiten el envı́o de los archivos utilizando el protocolo FTP. Debido
a que en ambas redes los paquetes enviados llegan a Internet, por un lado la red GPRS cuenta con un
nodo de pasarela GPRS (GGSN) que se encarga de convertir los paquetes al formato apropiado del
protocolo de paquetes de datos (PDP) y lo envı́a a las correspondientes redes de datos; por el otro
lado una red WLAN se conecta a Internet a través de un proveedor de servicios de Internet (ISP)
local [28], pasando por un ISP regional/nacional, para finalmente llegar a la red de redes a través de
los grandes Backbones de Internet. Entre las principales diferencias entre ambas redes destacan la
velocidad de transmisión y la cobertura.
3.2.1.4. Módulo MMS
Módulo alternativo para el envı́o de archivos utilizando el servicio de mensajes multimedia, éste
será utilizado cuando las redes Wi-Fi y GPRS no estén disponibles.
3.2.1.5. Módulo SMS
El propósito de este módulo es el de proporcionar al usuario un medio de registro para

posteriormente poder acceder a nuestro servidor de archivos.
3.2.2 Núcleo de la arquitectura
Esta parte de la arquitectura representa los servicios de comunicación necesarios para nuestro
middleware. Incluye módulos para lidiar con las tecnologı́as inalámbricas y servicios más populares
utilizados para el registro de usuarios y la transferencia de archivos.
3.2.2.1. Centro SMS
El centro SMS (SMSC) es el encargado de retransmitir los mensajes entre las entidades de
mensajes cortos (SMEs, elementos que pueden enviar o recibir mensajes cortos) y el almacenamiento
y retransmisión de los mensajes si la SME receptora no está disponible.
3.2.2.2. Centro MMS
El centro MMS (MMSC)4 es un elemento clave dentro de la arquitectura MMS, está compuesto
por un MMS relay y un MMS server, los cuales se encargan tanto de almacenar y manejar los
mensajes multimedia entrantes y salientes, y de garantizar la interoperabilidad con otros sistemas de
mensajerı́a [8] por medio de distintas interfaces de comunicación (por ejemplo la interfaz MM3).
4
El MMSC también es conocido como el MMS Proxy/Relay (estándares WAP/OMA) o el MMS Relay/Server
(estándares 3GPP) [8].
3.2.2.3. Servidor SMTP
Recibe los archivos que han sido enviados a través de mensajes multimedia (MMS) a una cuenta de
correo electrónico. Los datos viajan a través de la red móvil disponible (2.5G o 3G) y son encaminados
por el MMSC a Internet, para posteriormente llegar a nuestro SMTP [27] Server.
3.2.2.4. Pasarela GSM
La pasarela GSM recibe los mensajes de texto (SMSs) que son enviados por el cliente para la
creación de una cuenta.
3.2.2.5. BD Usuarios
Es la base de datos que contiene la información de los usuarios registrados en nuestro servicio.
3.2.2.6. Servidor FTP
Se encarga de recibir y almacenar los archivos de usuarios registrados. Estos archivos pueden
provenir tanto de clientes conectados por socket como del cliente de email (e-mail Client). Este
servidor es una de las partes fundamentales de la arquitectura, ya que en él se almacenan los archivos
de los usuarios registrados.
3.2.2.7. Cliente e-mail
Ayuda a las aplicaciones móviles a obtener archivos del servidor de almacenamiento externo
utilizando el Protocolo de Oficina de Correo (POP3) [33].
3.2.3 Lado servidor
Consiste de un módulo ubicado en el servidor de almacenamiento externo que es utilizado por el

sistema de almacenamiento para la gestión de cuentas de usuario, el envı́o y recepción de archivos a
través de diferentes servicios de comunicación como Wi-Fi, GPRS, UMTS y el servicio de mensajes
multimedia (MMS).
3.2.3.1. API Servidor
Este es un módulo que ofrece un conjunto de métodos que serán utilizados por las aplicaciones
del lado del servidor. Contiene funciones para la gestión de cuentas de usuario y conexiones, ası́ como
funciones para la recepción y transmisión de datos a través de diferentes redes inalámbricas. Incluye
envoltorios similares como los ubicados en el lado cliente del middleware, sin embargo, incluye el
módulo FTP que empaqueta todos los métodos de transferencia y recepción de archivos de forma
transparente para la aplicación del lado del servidor. Algunos de los métodos de transmisión de datos
que pueden ser utilizados por la aplicación son:
runFTPServer( ): Permite la recepción de los archivos que fueron enviados por el cliente,
utilizando el protocolo FTP (Filte Transfer Protocol)..
newUser( ): Facilita la creación de las cuentas de los usuarios que tendrán acceso al servidor.
runMailReceiverToFTP( ): Permite la recepción de los archivos que fueron enviados por el

cliente utilizando el servicio de mensajerı́a MMS.
3.2.3.2. SMS
Se encarga de gestionar los mensajes de texto recibidos por la Pasarela GSM y realiza el registro de
usuarios de la aplicación, con el fin de tener acceso al servidor FTP y poder almacenar su información.
Al momento de recibir un SMS, se conecta al servidor BD Usuarios y crea una cuenta con los
datos del usuario que vienen dentro del mensaje.
3.2.3.3. DB
El módulo DB efectúa el manejo de cualquier conexión a la base de datos de los usuarios.
3.2.3.4. FTP
Maneja el envı́o y recepción de archivos que se encuentran almacenados en el Servidor FTP.

44 3.3. Medidas de seguridad
3.2.3.5. MMS
Este módulo crea un cliente de correo electrónico que obtiene los mensajes que se encuentran
almacenados en el servidor SMTP, retransmitiendolos al Servidor FTP.
3.3 Medidas de seguridad
En la actualidad existen muchos aspectos de seguridad que pueden ser aplicados en un sistema. En
nuestro caso nos enfocaremos en el aspecto de la autenticación y la confidencialidad [42, 41, 40, 39]
en los dispositivos móviles [10].
Los datos que son transmitidos utilizando el middleware viajan a través de la infraestructura
proporcionada por un proveedor de servicios, para el caso del servicio MMS por Internet (vı́a Wi-Fi)
o por la red GPRS que al final también es conectado a Internet a través de una pasarela. Como se
sabe, todos estos tipos de redes son redes no seguras, es por esto que es necesario aplicar medidas
de seguridad dentro de las transmisiones de datos para evitar que dichos datos puedan ser leı́dos o
modificados cuando viajan por la red.
Algunas de las medidas de seguridad deseadas en una comunicación segura y que fueron aplicadas
en nuestro caso son:
Autenticación: Tanto como el emisor y receptor deben ser capades de confirmar la identidad
de la otra parte involucrada en la comunicación para asegurarse de que la otra parte es en
efecto quién o lo que parece. Es verificar la identidad del usuario (máquina o persona) que se
encuentra en el otro punto de la red o comprobar que es quien dice ser.
Confidencialidad: Es asegurarse que únicamente el emisor y el receptor deseado deberán ser

capaces de entender el contenido del mensaje transmitido. Como los espı́as pueden interceptar
el mensaje, se requiere necesariamente que el mensaje sea encriptado de algún modo (ocultar
los datos) para que el mensaje interceptado no pueda ser desencriptado (entendido) por éstos.
Es asegurarse que otras personas no puedan ver la información que ha sido enviada por la red.
Para aplicar los puntos mencionados anteriormente se utilizaron las siguientes herramientas
criptográficas:
Resumen de mensaje (Message Digest): Genera un resumen de 160 bits de un archivo, mensaje,
etc., para nuestro caso utilizamos el SHA1 (Secure Hash Algorithm 1) [14].
Cifradores (Ciphers): Se utilizan para encriptar o desencriptar datos utilizando llaves. Pueden
ser simétricos (nuestro caso, la misma llave para encriptar y desencriptar) o asimétricos (dos
llaves, una para encriptar y otra para desencriptar). Nosotros utilizamos el algoritmo AES
(Advanced Encryption Standard) [12], el cual es un algoritmo de llave simétrica, con una llave
y tamaño (puede variar) de bloque de 128 bits o 16 bytes
En la Figura 3.3 se muestra el procedimiento de cómo el cliente se identifica con el servidor.

En el dispositivo móvil se crea un resumen de mensaje (conocido como digest) utilizando el nombre
de usuario y contraseña. Este digest será enviado al servidor acompañado del nombre del usuario.
Del lado del servidor se crea un nuevo digest con el nombre de usuario recibido y la contraseña que
se encuentra en la base de datos del servidor, posteriormente se compara el digest recibido con el
digest generado del lado del servidor, si éstos son iguales significa que el usuario se ha identificado
correctamente. Todo esto es para dotar de autenticación al middleware.
Figura 3.3: Proceso de autenticación
Además, por el lado de la confidencialidad, los archivos son encriptados/desencriptados (Figura

3.4) siempre que viajan por la red (Internet, GPRS) y también cuando son enviados utilizando el
servicio de mensajerı́a multimedia.
46 3.3. Medidas de seguridad
Figura 3.4: Encriptación y desencriptación de archivos
Los procesos que se llevan a cabo para la encriptación y desencriptación de los archivos se
muestran en las Figuras 3.5 y 3.6 respectivamente.
Figura 3.5: Proceso de encriptación de archivos

Figura 3.6: Proceso de desencriptación de archivos
3.4 Diagramas UML de la Arquitectura
En esta sección se proporcinan los distintos diagramas del middleware realizados utilizando el
Lenguaje Unificado de Modelado (UML, Unified Modeling Language) [6], como son:
Diagrama de clases: Describe la estructura del middleware, mostrando las clases, sus atributos
y las relaciones entre las clases.
Diagrama de caso de uso: Muestra la funcionalidad proporcionada el middleware en términos

de actores, sus objetivos representados como casos de uso y las dependencias entre dichos
casos.
Diagrama de secuencia: Muestra la forma en que los objetos se comunican con cualquier otro
en términos de una secuencia de mensajes, además de indicar el tiempo de vida de los objetos
en relación a los mensajes.
48 3.4. Diagramas UML de la Arquitectura
3.4.1 Diagrama de clases del middleware (cliente)
El diagrama de clases del middleware (cliente) se muestra a continuación. Debido a que ciertas
clases de la arquitectura se encuentran aisladas y además de que el mostrar el diagrama de forma
completa evitarı́a una buena apreciación, se decidió mostrar varias clases en distintas imágenes,
describiendo brebemente cada una de ellas.
La Figura 3.7 muestra las clases FTPClient y ConnectorMiddleware, siendo la primera de éstas
para la transferencia de archivos utilizando un cliente FTP y la otra para el manejo de las conexiones
con el servidor.
Figura 3.7: Clases aisladas: FTPClient y ConnectorMiddleware.
Las clases mostradas en le Figura 3.8 son utilizadas para el envı́o de archivos vı́a MMS y el
manejo de cadenas de bytes y de caracteres.
Figura 3.8: Clases aisladas: MMS y HexCodec.
En la Figura 3.9 se da el diagrama de la clase Crypto, que es utilizada para la

encriptación/desencriptación de archivos y la creación de resúmenes de mensajes.
Figura 3.9: Clase aislada: Crypto.
Todas las clases mostradas en las figuras anteriores, son clases que se encuentran aisladas en
nuestro middleware debido a que se optó por dejar la resposabilidad de utilizarlas al desarrollador,
ya en el nivel de aplicación. A continuación se muestran las clases e interfaces que si se encuentran
relacionadas dentro del middleware (cliente).
La Figura 3.10 muestra las clases e interfaces que son utilizadas para la exploración de archivos
(SelecPath), datos del usuario (UserData) y la comunicación entre clases (DataInterface, AllInterfaces
y MenuInterface).
Figura 3.10: Clases e interfaces relacionadas: DataInterface, AllInterfaces, MenuInterface, SelecPath

y UserData.
Una descripción más técnica de cada una de las clases e interfaces aquı́ mostradas puede ser
encontrada en el Anexo C.
3.4.2 Diagrama de caso de uso del middleware del lado cliente
La Figura 3.11 muestra el diagrama de caso de uso del lado cliente. En este diagrama se
puede observar como es que una aplicación hace uso de nuestro middleware en la parte del cliente,
proporcionando de manera gráfica la funcionalidad del middleware.
Como un ejemplo podemos tomar cuando el usuario necesita transmitir un archivo, éste llamarı́a al
caso de uso Transmitir archivos el cual para leer los archivos a enviar, hace uso del caso Leer archivos
que finalmente utiliza nuestro middleware. También llamarı́a a Obtener conexión para obtener una
conexión o servicio que se encuentre disponible, este caso posteriormente utilizarı́a a Conexiones para
transmisión que a su vez extiende al caso MMS y Conexiones para recepción que también extiende
los casos GPRS y Wi-Fi. Los casos MMS, GPRS y Wi-Fi son generalizaciones del caso Método de
transmisión que utiliza nuestro middleware que se comunica con la aplicación servidor. Finalmente
por cada archivo leı́do, y una vez obtenida la red o servicio a utilizar, se envı́a cada uno de los
archivos.
Figura 3.11: Diagrama de caso de uso cliente.

3.4.3 Diagramas de secuencia utilizando las clases del middleware

(cliente)
Para proporcionar un ejemplo donde se muestre claramente cómo es que una aplicación utiliza
las diferentes clases proporcionadas por el middleware, a continuación se muestran los diagramas
de secuencia de una aplicación que utiliza el middleware (cliente) para el envı́o y recepción de un
archivo.
En la Figura 3.12 se muestra el diagrama de secuencia para el envı́o de un archivo ya sea tanto
por Wi-Fi como por MMS, en este diagrama se puede apreciar cómo es que la aplicación utiliza los
métodos de las clases proporcionadas por el middleware.
Se puede ver que el middleware ofrece varias opciones de conexión de las cuales se tomara una.
Si se le pide al middleware que seleccione de manera automática la red/servicio disponible, entonces
se utiliza el método autoDetectConnection( ) para que regrese el tipo de conexión (red/servicio)
disponible.
Una vez obtenido el tipo de conexión a utilizar, se crea la conexión utilizando el método
getConnection( ); dentro de los parámetros de este método, se le pasa un código hexadecimal
que es creado utilizando el método bytesToHexString( ), dicho código se crea a partir de un resumen
de mensaje creado utilizando el método getDigest( ), éste toma como parámetros el nombre del
usuario y su contraseña para generar el resumen (digest).
El valor de retorno del método getConnection( ) es almacenado en un objeto tipo Object para
posteriormente hacerlo comportar de acuerdo con el tipo de conexión obtenida.
Si el tipo de conexión es Wi-Fi, al objeto obtenido previamente se le realiza un cast al tipo
FTPClient para que se comporte como un cliente FTP. Posteriormente se encripta el archivo
utilizando el método criptFile( ).
Para comenzar la transmisión se abre un flujo de entrara al archivo encriptado para poder leerlo.
Se llama al método openInputStream( ) del objeto myFc, posteriormente se invoca al método stor(
) del objeto obj que se esta comportando como un cliente FTP, pasándole como parámetros el
flujo obtenido previamente, ası́ como el nombre que se le asignará al archivo en el servidor. Una vez
enviado el archivo se invoca al método delete( ) del objeto myFc para borrar el archivo encriptado
que fue creado, después se invoca al método close( ) para cerrar la conexión establecida por dicho
objeto. Finalmente se llama al método disconnect( ) de obj para finalizar la conexión con el servidor
FTP.
Por otra parte, si el tipo de conexión es MMS, al objeto obtenido previamente se le realiza
un cast al tipo MMS para que la transmisión se lleve a cabo por medio de mensajes multimedia.
Posteriormente se encripta el archivo utilizando el método criptFile( ).
Se abre un flujo de entrara al archivo encriptado para poder leerlo e iniciar la trasmisión. Se
llama al método openInputStream( ) del objeto myFc, también se invoca al método fileSize( ) del
mismo objeto para obtener el tamaño del archivo a enviar; posteriormente se invoca al método stor(
) del objeto obj que se esta comportando como un objeto MMS, pasándole como parámetros el flujo
obtenido previamente, el nombre que se le asignará al archivo en el servidor, ası́ como el tamaño
del archivo. Una vez enviado el archivo se invoca al método delete( ) del objeto myFc para borrar
el archivo encriptado que fue creado, después se invoca al método close( ) para cerrar la conexión
establecida por dicho objeto.
Las clases, métodos y variables del middleware, utilizadas dentro de la aplicación y por
consecuencia en el diagrama fueron:
Clase ConnectorMiddleware
• autoDetectConnection( );
• getConnection( );
• ConnectorMiddleware.AUTO CONNECTION
• ConnectorMiddleware.WIFI CONNECTION
• ConnectorMiddleware.MMS CONNECTION
Clase HexCodec
• bytesToHexString( );
Clase Crypto
• getDigest( );
• criptFile( );
Clase FTPClient
• stor( );
• disconnect( );
Clase MMS
• stor( ):
Figura 3.12: Diagrama de secuencia para el envı́o de un arhivo utilizando el middleware (cliente).
Para la recepción de archivos en el cliente vı́a Wi-Fi, se crea directamente un cliente FTP
utilizando el método getConnection( ); dentro de los parámetros de este método, se le pasa un código
hexadecimal que es creado utilizando el método bytesToHexString( ), dicho código se crea a partir
de un resumen de mensaje creado utilizando el método getDigest( ), éste toma como parámetros el
nombre del usuario y su contraseña para generar el resumen (digest). El valor de retorno del método
getConnection( ) es almacenado en el objeto ftp del tipo FTPClient.
Para comenzar la recepción se llama al método create( ) del objeto myFc para crear el archivo
(encriptado) en el cual se escribirán los bytes leı́dos desde el servidor, posteriormente se abre un flujo
de salida a dicho archivo invocando al método openOutputStream( ) del mismo objeto, después se
invoca al método retr( ) del objeto ftp, pasándole como parámetros el flujo obtenido previamente,
ası́ como el nombre del archivo que será traı́do desde el servidor. Una vez obtenido el archivo se
invoca al método close( ) del objeto myFc para cerrar la conexión establecida por dicho objeto.
Posteriormente se desencripta el archivo utilizando el método decriptFile( ), creando uno nuevo
archivo. Después se abre una nueva conexión con el archivo encriptado, instanciando nuevamente el
objeto myFc; se invoca al método delete( ) del objeto myFc para borrar el archivo encriptado que
fue creado, después se invoca al método close( ) para cerrar la conexión establecida por dicho objeto.
Finalmente se llama al método disconnect( ) de ftp para finalizar la conexión con el servidor FTP.
La Figura 3.13 nos muestra el diagrama de secuencia de una aplicación que recibe un archivo
utilizando el middleware (cliente), pudiendose apreciar como es que son utilizadas las distintas clases
del middleware.
Las clases, métodos y variables del middleware, utilizadas dentro de la aplicación fueron:
Clase ConnectorMiddleware
• getConnection( );
• ConnectorMiddleware.WIFI CONNECTION
Clase HexCodec
• bytesToHexString( );
Clase Crypto
• getDigest( );
• decriptFile( );
Clase FTPClient
• retr( );
• disconnect( );
Figura 3.13: Diagrama de secuencia para la recepción de un arhivo utilizando el middleware (cliente).
3.4.4 Diagrama de clases del middleware (servidor)
A continuación se muestra el diagrama de clases del middleware (servidor). Como ya se

mencionó en la sección Diagrama de clases del middleware (cliente) los motivos por los cuales las
clases son mostradas de cierta forma, en esta sección también se mostrarán varias clases en distintas
imágenes, describiendo brebemente cada una de ellas.
En la Figura 3.14 se muestran las clases BDConnection y FTPClientPC, éstas clases son utilizadas
para la manipulación de bases de datos y el envı́o de archivos utilizando un cliente FTP.
Figura 3.14: Clases aisladas: BDConnection y FTPClientPC.
La clase Crypto que se muestra en la Figura 3.15, al igual que en el cliente, se utiliza para la
encriptación/desencriptación de archivos y la creación de resúmenes de mensajes.
Figura 3.15: Clase aislada: Crypto.
En la Figura 3.16 se muestran las clases utilizadas para la recepción de mensajes multimedia, el
manejo de información del usuario y la manipulación de cadenas de bytes y de caracteres.
Figura 3.16: Clases aisladas: MailReceiverToFTP, Usuario y HexCodec.
Las clases mostradas en las figuras anteriores, son clases que se encuentran aisladas dentro del
middleware debido a que se optó por dejar la resposabilidad de utilizarlas al desarrollador, ya en el
nivel de aplicación. A continuación se muestran las clases que si se encuentran relacionadas dentro
del middleware (servidor).
En la Figura 3.17 se muestran las clases que están relacionadas, éstas proporcionan los métodos
para el registro de usuarios, la configuración y el manejo de un servidor FTP.
Figura 3.17: Clases relacionadas: FTPServer, ThreadFTP, Register y ServerConfiguration.
Al igual que con el cliente, la descripción técnica de cada una de las clases e interfaces
aquı́ mostradas puede ser encontrada en el Anexo C.
3.4.5 Diagrama de caso de uso del middleware del lado servidor
En la Figura 3.18 también se muestra el diagrama de caso de uso del lado servidor. Al igual
que en el diagrama de caso de uso del cliente, en éste se observa como una aplicación hace uso del
middleware en la parte del servidor.
Se puede tomar como ejemplo cuando la aplicación necesita recibir los archivos que viajan a
través del servicio de mensajerı́a multimedia hacia una cuenta de correo electrónico y reenviarlos al
servidor FTP. Para hacer esto, se utilizarı́a el caso de uso Recibir emails y enviarlos al servidor FTP,
dicho caso utiliza los casos Cliente de correo electrónico (para obtener los correos electrónicos) y
Cliente FTP (para reenviar los correos al servidor FTP). Cliente FTP usa el caso Enviar archivos
que finalmente utiliza el middleware. El Cliente de correo electrónico hace uso del caso Descargar
archivos que también utiliza el middleware. Por cada correo electrónico descargado por el caso Cliente
de correo electrónico, el caso Recibir emails y enviarlos al servidor FTP utiliza el caso Cliente FTP
para reenviar los archivos que vienen en los correos al servidor FTP.
3.4.6 Diagramas de secuencia utilizando las clases del middleware

(servidor)
A continuación se muestran los diagramas de secuencia de una aplicación que utiliza el middleware
(servidor) para poner a funcionar el servidor y otras aplicaciones que recibiran los archivos enviados
por los clientes, proporcionando un ejemplo de como es que una aplicación utiliza el middleware.
En la Figura 3.19 se muestra el diagrama de secuencia para levantar los servidores; tanto el
servidor FTP como un cliente de correo electrónico que reenvı́a los archivos que han sido enviados
vı́a MMS hacia el servidor FTP. En éste diagrama se puede apreciar cómo es que la aplicación utiliza
los métodos de las clases proporcionadas por el middleware.
Inicialmente se crea un objeto ftp del tipo FTPServer, el cual recibe como parámetro un objeto
del tipo ServerConfiguration, este objeto a su vez recibe como parámetros la ruta en donde va a
trabajar el servidor FTP (donde se crearán las cuentas de los usuarios), el puerto donde correrá dicho
Figura 3.18: Diagrama de caso de uso servidor.
servidor, la URL a la base de datos de los usuarios, ası́ como el usuario y la contraseña para acceder
a la misma. Después se crea un Thread para ejecutar más adelante el servidor ftp en background.
Posteriormente se crea un objeto mr del tipo MailReceiverToFTP, que recibe como parámetros el
nombre del servidor POP3, el puerto en el cual trabaja dicho servidor, la cuenta de correo electrónico
de la cual serán obtenidos los archivos que se enviarán al servidor FTP, la contraseña de la cuenta,
la IP del servidor FTP, el número del puerto al que se conectará con el servidor FTP, ası́ como el
número de minutos que esperará para volver a verificar si han llegado nuevos correos electrónicos a
la cuenta especificada previamente. Después se crea un Thread para ejecutar más adelante el cliente
de correo electrónico en background.
Finalmente se lanzan los dos Threads creados previamente para dejar funcionando tanto la
recepción de archivos directamente desde el servidor FTP, ası́ como la recepción de archivos que
fueron enviados vı́a MMS a una cuenta de correo electrónico.
Las clases y métodos del middleware, utilizadas dentro de la aplicación fueron:
Clase FTPServer
• runFTPServer( );
Clase ServerConfiguration
Clase MailReceiverToFTP
• runMailReceiverToFTP( );
Figura 3.19: Diagrama de secuencia para la recepción de arhivos utilizando el middleware (servidor).
3.5 Resumen
En este capı́tulo se mostró la arquitectura utilizada en el desarrollo del middleware propuesto. Se
explicó cada uno de los módulos que lo conforman, el algoritmo para seleccionar una red o servicio
disponible, las medidas aplicadas (autenticación y confidencialidad) para brindarle seguridad al
middleware, ası́ como la jerarquı́a de clases realizadas en la implementación en J2ME. La arquitectura
descrita en este capı́tulo permite el envı́o y recepción de archivos entre un dispositivo móvil y un
servidor, además de que una de las principales caracterı́sticas de un middleware es la portabilidad
que, en nuestro caso, al estar implementado en Java permite ser utilizados en otros dispositivos que
cumplan con los requerimientos necesarios para la ejecución de aplicaciones J2ME. En el Anexo A
se da un ejemplo sobre como utilizar el middleware para el diseño de nuevas aplicaciones móviles y
en el Anexo C se encuentra una descripción breve de cada una de las clases.
Evaluación experimental
4
En esta sección se desarrollaron una serie de experimentos con el fin de crear un escenario de
prueba para nuestro middleware. Se describe una aplicación móvil que a partir de aquı́ llamaremos
Swapper, ésta ofrece un servicio de intercambio de archivos entre el sistema de almacenamiento
local del dispositivo móvil y el sistema de almacenamiento externo que se encuentra en un servidor
conectado a través de Internet.
4.1 Escenario de pruebas
Las pruebas realizadas se dividieron en dos secciones para distinguir las pruebas reales de las
simuladas, en las siguientes subsecciones se describen cada una de ellas con más detalle.
De manera inicial, se calcularon algunos valores utilizados como medidas en nuestras pruebas.
Estos valores son tomados de experimentos de envı́o y recepción de datos que se hicieron con distintos
dispositivos celulares. La sección 4.1.1 resume las medidas obtenidas. Estas medidas fueron de utilidad
para simular diversas politicas de reemplazo con el fin de seleccionar una que fuera implementada en
nuestra aplicación de ejemplo.
65
66 4.1. Escenario de pruebas
4.1.1 Medidas en redes GPRS y WLAN (reales)
En esta sección se describe cada una de las pruebas que fueron hechas con el fin de medir el
tiempo promedio de transmisión en redes GPRS y Wi-Fi, ası́ como verificar los tamaños de bloques
que proporcionen un mejor1 rendimiento en las distintas redes. Con estas pruebas se pudo obtener
información que finalmente fue aplicada en las simulaciones realizadas; las cuales serán explicadas
más adelante.
4.1.1.1. Tamaños óptimos para transferencia de archivos en redes Wi-Fi y GPRS
En [16], Vargas realizó un conjunto de pruebas con el fin de determinar cuál serı́a el tamaño
de bloque para ser usado en las transmisiones de datos que proporcionarı́a el menor tiempo de
transferencia entre el teléfono celular y el servidor utilizando la red WLAN. En ese estudio se obtuvo
como resultado que para una red WLAN el tamaño de bloque óptimo es de 4KB, tal como se puede
observar en la Figura 4.1. Por otra parte, para las redes GPRS se encontró que el tamaño óptimo
de bloque era de 96 bytes. Debido a que la tasa de transferencia de la red GPRS varı́a, ocasiona
que conforme la red se satura aumente el número de errores de transmisión con dicho tamaño de
bloque. Es por eso que el autor decidió utilizar un tamaño de bloque de 64 bytes, el cual fue el
que le proporcionó una mejor velocidad de transmisión a diferentes horas del dı́a. En la Figura 4.2
se muestra la gráfica de los tiempos promedio de transferencia para distintos tamaños de bloque
utilizados.
1
En [16] plantean que en la red GPRS la transmisión de bloques muy grandes tiende a aumentar el número de
errores.
Figura 4.1: Tamaño óptimo de bloque en una red WLAN.
Figura 4.2: Tamaño óptimo de bloque en una red GPRS.

4.1.1.2. Tiempo de transferencias de un archivo de tamaño promedio
El tamaño de archivo promedio obtenido de los diferentes teléfonos móviles fue 1.3MB; éste
tamaño se obtuvo recolectando archivos (más de 700) de diferentes dispositivos móviles, donde
además cabe mencionar que la mayorı́a de éstos archivos fueron imágenes y música.
El tiempo promedio obtenido al transmitir más de 120 archivos planos2 de 1.3MB (tamaño
promedio utilizando distintos dispositivos) a un servidor de almacenamiento externo, conectado a
Internet utilizando una red Wi-Fi fue de 8.3s, la gráfica de la Figura 4.3 nos muestra los tiempos de
cada uno de los archivos enviados, pudiéndose observar que la mayorı́a de éstos tardaron poco más
de 8s en transmitirse.
Figura 4.3: Tiempos de transmisión de archivos sin encriptar
Por otra parte, también se midieron los tiempos de transferencia de 31 archivos de tamaño
promedio (1.3MB) encriptados, obteniéndose un tiempo promedio de 135.3s. En la Figura 4.4 se
muestran los tiempos obtenidos en cada una de las 31 ejecuciones, en las que también puede
observarse que el tiempo promedio osciló por encima de los 130 segundos.
El medir los tiempos de transferencia de los archivos tanto planos como encriptados nos ayudará a
calcular tiempos de transmisión en las pruebas que se explicarán más adelante.
2
Archivos que no están encriptados.
Figura 4.4: Tiempos de transmisión de archivos encriptados
4.1.2 Elección de polı́tica de reemplazo para aplicación de ejemplo
El intercambio de archivos permite a los dispositivos móviles liberar espacio de almacenamiento

para ası́ dotarlos de nuevo espacio disponible. En esta sección se muestran algunos experimentos
que se realizaron en busca de una polı́tica de reemplazo [54, 34] eficiente, tomando en cuenta los
siguientes aspectos: el espacio de almacenamiento promedio en los dispositivos móviles actuales, el
tamaño promedio de archivo, tasa de transferencia promedio en redes comunes inalámbricas LAN y
WAN, como Wi-Fi y GPRS respectivamente.
La Tabla 4.1 muestra las medidas tomadas de diferentes teléfonos celulares y PDAs como: Nokia
N95 y HP iPAQ HW6945.
Medida Tamaño
MAX TAM MEM 2GB
MAX TAM ARCH 15MB
MIN TAM ARCH 469KB
AVG TAM ARCH 1.3MB
Tabla 4.1: Medidas comunes en celulares y PDAs.

Con el fin de elegir una polı́tica de reemplazo eficiente que pudiera ser utilizada en una aplicación
que haga uso de nuestro middleware, se simularon cuatro diferentes polı́ticas; las cuales se basan en
las medidas promedio tomadas de dispositivos móviles y redes inalámbricas reales.
Las polı́ticas de reemplazo utilizadas en las pruebas fueron:
LRU (menos recientemente utilizado)
LFU (menos frecuentemente utilizado)
LFS (Tamaño de archivo más grande)
SFS (Tamaño de archivo más pequeño
Las polı́ticas LRU y LFU [54, 34] fueron tomadas de la literatura mientras que LFS y SFS fueron
variaciones que utilizaban el tamaño de archivo como polı́tica de reemplazo.
Para las polı́ticas de reemplazo se tiene la siguiente definición:
Cuando un archivo es requerido por la aplicación, y éste se encuentra en el dispositivo móvil,

se dice que ha ocurrido un Hit, de lo contrario quiere decir que ha ocurrido un Miss y que
dicho archivo no se encuentra en el dispositivo lo que implica descargarlo del servidor.
Las Figuras 4.5 y 4.6 muestran las gráficas obtenidas utilizando los datos de la Tabla 4.1 en
la simulación de un celular. Se simularon 31 veces cada una de las cuatro polı́ticas mencionadas
y por cada una de las simulaciones se gráfico el número de hits para la primer figura y el tiempo
promedio de transmisión para la segunda (el tiempo que tarda en traerse un archivo desde el servidor
cuando ocurre un Miss). Ambos tiempos se obtuvieron para cada polı́tica de reemplazo. Como se
puede ver, la polı́tica que obtuvo un mayor número de hits fue el LFS. Si la aplicación remplaza los
archivos basada en el tamaño de archivo más grande (LFS) se obtiene una mejor tasa de hits, sin
embargo, también se obtiene un mayor tiempo de transferencia promedio. Cabe mencionar que para
la simulación se utilizó el tiempo de transferencia promedio de un archivo sin encriptar, el cual era
de 8.3s.
Figura 4.5: Tasa de hits obtenidos utilizando diferentes polı́ticas de reemplazo.
Figura 4.6: Tiempos de transferencia promedio obtenidos utilizando diferentes polı́ticas de reemplazo.
Estos resultados podrı́an ser un buen punto de negociación, dependiendo si el costo se basa en
el tiempo de uso del enlace o en la cantidad de datos transferidos. Basados en la información que
se muestra en la Figura 4.6, los usuarios pueden definir en el middleware, una polı́tica de costo que
mejor se adapte a sus necesidades.
En la mayorı́a de los casos, el servicio de comunicación inalámbrica es calculado en base al
consumo de ancho de banda. Las Figuras 4.7 y 4.8 muestran el consumo promedio total de ancho
de banda y el tiempo promedio total después de ejecutar todas las polı́ticas. Estas simulaciones nos
dieron ideas al momento de decidir qué polı́tica implementar, ya que es importante considerar todos
los costos en términos de tiempo y consumo de ancho de banda.
Figura 4.7: Consumo promedio total de ancho de banda obtenido utilizando diferentes polı́ticas de
reemplazo.
Figura 4.8: Tiempo promedio total obtenido utilizando diferentes polı́ticas de reemplazo.
Los resultados obtenidos de las simulaciones son de utilidad a la hora de decidir qué polı́tica de
reemplazo utilizar en una aplicación de intercambio móvil que haga uso de nuestro middleware.
4.1.3 Swapper
Para mostrar la funcionalidad de nuestro middleware se desarrolló una aplicación llamada

Swapper, con ésta se realizaron pruebas para medir tiempos de envı́o y recepción de archivos reales
desde un dispositivo móvil hacia un servidor.
En las pruebas que se presentarán en las siguientes subsecciones se optó por utilizar un archivo
con un tamaño de 90KB para que éste pudiera ser utilizado en los distintos tipos de conexiones
(Wi-Fi, GPRS y MMS), debido a que aunque el estándar MMS no está restringido a un lı́mite en
el tamaño del mensaje, el proveedor de servicio utilizado lo limita a 100KB. Además, otro punto a
considerar es el costo en las pruebas utilizando GPRS, el cual se factura por kilobyte transmitido.
Las funciones principales del middleware utilizadas en las pruebas fueron:
stor( ): utilizada para almacenar un archivo
retr( ): utilizada para descargar un archivo
criptFile( ): utilizada para encriptar un archivo
decriptFile( ): utilizada para desencriptar un archivo
4.1.3.1. Pruebas de envı́o
Se probaron las funciones de envı́o de archivos utilizando los tres tipos de conexiones Wi-Fi,
GPRS y MMS. Los tiempos obtenidos se muestran en la Tabla 4.2.
Wi-Fi GPRS MMS

Tiempo prom. de
transferencia c/enc. 15.27s 26.8s 86.12s
Tiempo prom. de
transferencia s/enc. 5.14s 16.89s 32.56s
Tabla 4.2: Tiempos promedio de envı́o.

Los tiempos mostrados en la tabla anterior miden el tiempo desde que se comienza a encriptar el
archivo (en su respectivo caso) hasta que es enviado en su totalidad hacia el servidor. Para el caso
del MMS, el tiempo que se muestra es relativo, debido a que en realidad depende mucho de cuanto
se demore en llegar a la cuenta de correo electrónico configurada, para finalmente ser descargado
por nuestro cliente y ser enviado al servidor. Los resultados obtenidos en esta prueba muestran como
el proceso de encriptación conlleva un tiempo que puede, en algunos casos, triplicar el tiempo de
envı́o.
4.1.3.2. Pruebas de recepción
También se midieron los tiempos utilizando las funciones de recepción y los tres tipos de
conexiones antes mencionadas. Los resultados se pueden observar en la Tabla 4.3.
Wi-Fi GPRS MMS

Tiempo prom. de
transferencia c/enc. 15.35s 25.63s x
Tiempo prom. de
transferencia s/enc. 9.17s 22.68s x
Tabla 4.3: Tiempos promedio de recepción.
Para este tipo de pruebas no se tomó en cuenta el servicio MMS debido a que no se vio factible
que el servidor pagara por cada mensaje que sea enviado al cliente.
En la Tabla 4.3 se puede ver como el tiempo de recepción con encriptación no varió mucho con
respecto al de transmisión con encriptación. En cambio, para el caso de la recepción sin encriptación
se puede ver como éste aumentó en ambos tipos de conexiones (Wi-Fi y GPRS) con respecto al de
transmisión sin encriptación.
4.1.4 Proyecto VS Campamento Móvil
Como parte de este trabajo de tesis, se incursionó en un proyecto con la empresa Vision Systems
de México, SA. de CV. llamado VS Campamento Móvil.
El objetivo del proyecto fue crear una aplicación móvil que aproveche las capacidades de nuestro
middleware propuesto. La aplicación está orientada al manejo de insumos, consumos, etc. dentro de
una empresa orientada a la construcción. Dicha aplicación será software comercial que la empresa
Vision ofrecerá a sus clientes.
4.1.4.1. Descripción general del proyecto
Los consumos de la maquinaria juegan un papel muy importante en el control de costos de una
obra, debido a que su descontrol implica altos costos que pueden afectar el rendimiento esperado.
Existen 2 consumos principales que toda empresa desea tener controlados: combustibles y aceites.
En el desarrollo de una obra, la maquinaria se traslada al lugar de los trabajos y es necesario
según se requiera, se le suministren aquellos insumos que por su naturaleza se consumirán conforme
se utilice el equipo (e.g., combustible). Para esto, regularmente por la distancia de las obras, resulta
costoso y no funcional que todos los equipos se trasladen a un punto X donde se les suministren
los insumos que requieran; por tanto, se utilizan equipos de transporte que recorren cada una de las
obras y equipos, para suministrarles los insumos directamente en campo.
Toda empresa requiere controlar el correcto suministro de insumos y llevar una estadı́stica de
cargas y suministro para analizar el comportamiento de consumo de cada equipo y evaluar sus
rendimientos con la intención de observar cuando un equipo esté fuera de sus rendimientos esperados,
lo cual significarı́a un problema en el equipo o bien, una desviación por parte del personal encargado
del equipo o del reparto.
4.1.4.2. Aplicación prototipo
Se implementó una aplicación que está en fase de desarrollo, la cual proporciona los menús para
dar de alta registros tanto de reparto de combustible como de vales de la empresa. La aplicación
permite el envı́o de los registros al servidor.

El menú de alta de registros de reparto de combustible cuenta con los siguientes campos:
Kilometraje
Folio vale
Cantidad Lts.
Fecha
Hora
Clave combustible
Id. equipo
Los campos del menú de alta de registros de vales son:
Folio
Total lts.
Consumido
Fecha
Clave combustible
En la Figura 4.9 se muestran algunas capturas de distintos menús de la aplicación.

La aplicación VS campamento móvil recolecta diferentes datos que son empaquetados y
preparados para su envı́o a un sistema central de control de la empresa Vision Systems. La aplicación
utiliza nuestro middleware para enviar la información desde el dispositivo móvil en momentos cuando
el usuario lo requiera o, en caso de que se haya configurado de manera automática, en momentos
cuando el middleware detecta una conexión estable y económica según las prioridades de conexión
que hayan sido definidas. Esta aplicación se encuentra empotrada encima de nuestro middleware (del
Figura 4.9: Capturas de pantallas de la aplicación.
lado del cliente). Del lado del servidor, el sistema central de control de la empresa Vision Systems,
se conecta con nuestro middleware del lado del servidor para recibir la información que los usuarios
móviles le envı́an (Figura 3.1). En esta aplicación, todo el proceso de transmisión y recepción de datos
de manera segura e independientemente del medio de transferencia disponible queda encapsulado por
nuestro middleware, lo que facilita el desarrollo de aplicaciones móviles que requieren estos servicios.
4.2 Resumen
En este capı́tulo se presentó un escenario de pruebas que muestra los tamaños óptimos de bloque
para la transferencia en redes Wi-Fi y GPRS.
Se midieron los tiempos de transferencia de un archivo de tamaño promedio (1.3MB) en redes
Wi-Fi, dichos tiempos se midieron para transferencias con y sin encriptación.
También se simularon cuatro polı́ticas de reemplazo con el fin de dar una estudio sobre qué polı́tica
podrı́a ser implementada en aplicaciones que utilicen el middleware. Se midieron los tiempos de
transmisión y recepción con y sin encriptar, utilizando una aplicación llamada Swapper; ésto para dar
78 4.2. Resumen
un ejemplo funcional de nuestro middleware. Finalmente se presentó un proyecto con una empresa
privada, mostrando un ejemplo real de utilización del middleware.
Conclusiones y trabajo futuro
5
En la actualidad el uso de los dispositivos móviles se ha incrementado de manera muy rápida.
Las capacidades de procesamiento en estos dispositivos también han tenido un avance considerable.
El teléfono celular ha evolucionado constantemente hasta crear la aparición de nuevos dispositivos
que integran distintas caracterı́sticas de algunos otros como los PDA’s, además de contar con nuevas
interfaces de comunicación como son el USB, infrarrojo, Bluetooth, GPRS y Wi-Fi, etc. Lo anterior ha
dado paso a los nuevos teléfonos inteligentes (smartphones). Además, la telefonı́a celular y móvil ha
avanzado de manera considerable y actualmente presenta un crecimiento mucho mayor con respecto
al mercado de telefonı́a fija.
Todos estos desarrollos tecnológicos hacen que los dispositivos móviles de hoy en dı́a sean capaces
de ejecutar aplicaciones que generan una gran cantidad de archivos y, como consecuencia, requieren
una mayor capacidad de almacenamiento. Desafortunadamente, la capacidad de almacenamiento de
estos dispositivos no ha crecido al ritmo que las aplicaciones lo consumen.
Cuando los dispositivos móviles exceden su capacidad de almacenamiento, es necesario descargar

sus archivos a sistemas de almacenamiento externos con el fin de respaldar su información, limitando
la movilidad de los usuarios debido a que es necesario conectarse a dicho dispositivo externo a través
79
80
de cables o redes de corto alcance. Este tipo de situaciones motivan el desarrollo de mecanismos
que permitan el intercambio de archivos entre dispositivos móviles y sistemas de almacenamiento
externo, de un modo transparente, teniendo en cuenta situaciones tales como la conectividad a redes
inalámbricas LAN o WAN, el costo del servicio y el almacenamiento disponible.
En la actualidad existen una gran variedad de sistemas operativos para dispositivos móviles,
algunos de ellos son:
Symbian OS
Linux Mobile
Windows Mobile
Android
Mac OS (iPhone)
Debido a todas éstas diferentes plataformas, no es conveniente desarrollar aplicaciones especı́ficas

para cada una de las plataformas en particular, ya que limitarı́a su capacidad de uso. Es por esto que
se optó por utilizar un middleware permita mayor cobertura en diferentes dispositivos móviles.
En la presente tesis se desarrolló un middleware que puede ser integrado como una API para el
desarrollo de nuevas aplicaciones móviles, como es el caso de la aplicación Swapper y del proyecto
VS Campamento Móvil que está siendo desarrollando para la empresa Vision Systems de México,
SA. de CV..
La arquitectura del middleware contempla el envı́o de archivos utilizando distintas tecnologı́as de
redes inalámbricas como son el Wi-Fi y el GPRS. También está preparado para transmitir archivos
mediante el servicio de mensajerı́a multimedia (MMS), como una opción adicional a ser considerada
por los usuarios al tomar una decisión teniendo en cuenta el costo de los servicios inalámbricos o la
disponibilidad.
Para brindarle seguridad a la arquitectura middleware propuesta se agregaron las medidas de
autenticación y confidencialidad, para que los datos transmitidos utilizando el middleware y que
5. Conclusiones y trabajo futuro 81
viajan por la red no puedan ser leı́dos o modificados por otras personas. Para ésto se utilizaron
resúmenes de mensaje (Message Digest) utilizando el SHA-1 (Secure Hash Algorithm 1) y cifradores
(Ciphers) utilizando el AES (Advanced Encryption Standard).
En el capı́tulo de pruebas se simularon varias polı́ticas de reemplazo con el fin de elegir una
polı́tica eficiente que pudiera ser empleada en aplicaciones de intercambio de archivos que hagan
uso de nuestro middleware. Dichas polı́ticas se implementaron utilizando información recabada de
distintos dispositivos móviles y redes inalámbricas reales.
Se realizaron pruebas de transferencia de archivos desde un dispositivo móvil a un servidor externo,
tanto con archivos planos como con archivos encriptados, obteniéndose que para el primer caso el
tiempo promedio era de 8.3s mientras que para el segundo se obtuvo un tiempo de 135.3s. Asimismo,
se mostraron gráficas en las que se puede observar la cantidad de Hits y el tiempo promedio para
cada una de las polı́ticas implementadas.
Swapper intercambia archivos entre un dispositivo móvil y un sistema de almacenamiento externo,
incrementando el espacio de almacenamiento en el primero. Está basado en una arquitectura de
middleware que ofrece soporte para la transmisión y recepción de archivos tomando ventaja de
las redes inalámbricas disponibles y considerando las cuestiones relacionadas con los costos de los
diferentes servicios inalámbricos y el tiempo de transmisión.
También se introdujo un proyecto que se tiene con la empresa privada con el fin de desarrollar una
aplicación que ayude en el manejo de insumo, reportes de actividades, etc. dentro de una empresa
del ramo de la construcción.
Durante el desarrollo de la arquitectura del middleware mostrada en el presente trabajo de
tesis, una de las principales dificultades técnicas que se tuvieron fue del lado de los dispositivos
móviles que, conforme han evolucionado también han ido aumentando las restricciones para con los
desarrolladores. En nuestro caso, la mayorı́a de los teléfonos celulares, PDAs y smartphones requieren
que el desarrollador cuente con un certificado de alguna entidad certificadora (e.g. VeriSign [53])
para poder desarrollar aplicaciones en el dispositivo. Debido a esto se tuvo que realizar un proceso
de desbloqueo en todos los dispositivos utilizados en las pruebas, siendo cada uno estos procesos
especı́fico para cada dispositivo; todo esto debido a que no fue posible adquirir algún certificado,
82 5.1. Trabajo futuro
además de que se corrı́a el riesgo de que dicho certificado no funcionara en todos los dispositivos
con los que se contaba, debido a que no todos operan con la misma entidad certificadora. Otra
de las dificultades técnicas fue que los dispositivos deben cumplir con los requerimientos mı́nimos
mencionados en el capı́tulo 3.
Finalmente podemos concluir que el middleware desarrollado funciona de manera adecuada a la
hora de ser integrado al desarrollo de nuevas aplicaciones, quedando demostrado con el desarrollo
de nuestra aplicación Swapper y el prototipo del proyecto, VS Campamento Móvil, los cuales hacen
uso de nuestro middleware.
5.1 Trabajo futuro

Como trabajo futuro se plantea integrar algún mecanismo de compresión de datos en el
middleware, con el fin de reducir el tiempo de transmisión y consumo de ancho de banda, aspectos
que tienen un alto impacto en el costo por el uso de redes como GPRS.
Un segundo trabajo futuro podrı́a ser la utilización de múltiples servidores de almacenamiento,
permitiendo un almacenamiento distribuido de los datos y de esta manera incrementar la
disponibilidad de los datos almacenados en caso de que alguno de los servidores involucrados no
se encuentre disponible.
Finalmente otro trabajo futuro podrı́a ser la integración de un módulo de handover o handoff
vertical dentro de la arquitectura, para que el cambio entre redes se realice de manera automática y
sin reinicializar la conexión, debido a que en el presente trabajo de tesis se asume que al momento
de realizar el cambio entre redes, el usuario ya está dado de alta o tiene acceso a la red (para el caso
de una red Wi-Fi), además de iniciar por completo una nueva conexión con el servidor.
Cómo utilizar el middleware
A
A.1 Herramientas de desarrollo
Actualmente existen varias herramientas de desarrollo para la creación de aplicaciones J2ME, en
esta sección se explicará el uso del Sun Java Wireless Toolkit, que es una herramienta para el desarrollo
de aplicaciones móviles basadas en Java ME CLDC [32] (Connected Limited Device Configuration)
y MIDP (Mobile Information Device Profile); éste puede ser utilizado como un entorno de desarrollo
independiente o con un entorno de desarrollo integrado IDE (Integrated Development Environment)
como el NetBeans IDE.
Es necesario instalar las siguientes aplicaciones para poder efectuar la compilación de los
programas escritos en J2ME.
J2SE: Compilador estándarde Java.
Sun Java Wireless Toolkit: IDE para el desarrollo de apicaciones J2ME con soporte para MIDP
2.0/2.1 y CLDC 1.0/1.1.
(Opcionalmente) NetBeans con el Sun Java Wireless Toolkit for CLDC integrado.
83
84 A.1. Herramientas de desarrollo
A.1.1 Proceso de desarrollo de un MIDLet utilizando el J2ME Wireless

Toolkit
J2ME Wireless Toolkit cuenta con la herramienta KToolBar (Figura A.1), con la cual es posible
crear proyectos para posteriormente ejecutarlos en el emulador que ésta proporciona.
A continuación se describe en breve el proceso para crear un nuevo proyecto para J2ME:
Crear un nuevo proyecto al que le asignaremos un nombre concreto realcionado con la

aplicación. Posteriormente se pueden editar los atributos del archivo JAD.
Una vez creado el proyecto se crea un sistema de directorios dentro de la carpeta apps, en
ésta se creará una carpeta con el nombre del proyecto y dentro de ella se crearán varios
subdirectorios tal como se muestra en la Figura A.2.
En el subdirectorio src es donde se deben de guardar los archivos con estensión .java que
forman las clases del proyecto.
El subdirectorio res se utiliza para guardar los recursos que sean utilizados por la aplicación en
desarrollo, como pueden ser imágenes u otros archivos que sean requeridos por la aplicación.
Si se utiliza alguna librerı́a; como es en el caso de utilizar nuestro middleware. Ésta debe ser
guardada en el subdirectorio lib para que la aplicación pueda utilizarla.
Finalmente, una vez colocados los archivos en cada subdirectorio correspondiente, solamente
hay que compilar el proyecto. Si la compilación se lleva a cabo correctamente, la herramienta
nos proporciona la opción de empaquetar la aplicación a través del menú Project → Package
→ Create Package. Es posible ejecutar la aplicación en el mismo KToolBar utilizando el
menú Project → Run, el cual utiliza el emulador que viene integrado con dicha herramienta.
Figura A.1: Aspecto de la herramienta KToolBar del J2ME Wireless Toolkit
Figura A.2: Jerarquı́a de directorios
A.2 Ejemplo de instalación de una aplicación que hace uso

del middleware
En esta parte se da una explicación sobre como llevar a cabo la instalación de una aplicación que
ha sido desarrollada utilizando como herramienta de desarrollo nuestro middleware tanto del lado
cliente como del lado servidor.
86 A.2. Ejemplo de instalación de una aplicación que hace uso del middleware
A.2.1 Lado servidor
Del lado servidor se cuenta con los siguientes directorios y archivos:
Buzon: Directorio donde se crearán las cuentas de cada usuario registrado en la Base de Datos.
lib: Librerias utilizadas.
• ServerMiddleware.jar : Middleware que será utilizado para el desarrollo de aplicaciones del

lado del servidor.
• mysql-connector-java-3.1.14-bin.jar : Conector de bases de datos MySQL para Java.
• mail.jar : Paquete para conectarse a servidores de correo utilizando el protocolo de oficina

de correo (POP3) en Java.
BD.sql: Base de Datos para los usuarios de la aplicación.
FTPConfigurator.jar : Aplicación para configurar el servidor incluı́do en el middleware.
MMSConfigurator.jar : Aplicación para configurar el cliente de correo electrónico incluı́do en el

middleware.
Register.war : Servicio para el registro de los usuarios vı́a web.
A.2.1.1. Pasos para levantar el servidor
1. Es necesario contar con el manejador de bases de datos Mysql1 , Java JRE2 y el servidor de
aplicaciones Java llamado Apache Tomcat3 , ya sea en cualquiera de las plataformas Linux o
Windows.
2. Insertar la base de datos BD.sql

1
Versión 5.0
2
Versión 1.6
3
Versión 6.0
3. Crear un usuario que representará a la aplicación al momento de acceder a la base de datos

en MySQL.
4. Posicionarse en la carpeta donde se encuentran los archivos mencionados anteriormente, tal

como se muestra en la Figura A.3
5. Levantar las aplicaciones FTPServer.jar y MMS.jar utilizando los siguientes comandos en java:
java -jar FTPConfigurator.jar /home/usuario/servidor/Buzon/ 6000

localhost/bdmiddleware userBD passBD
java -jar MMSConfigurator.jar pop3.live.com 995 prueba one@hotmail.com

pruebaone 148.247.199.1 6000
6. Extraer la aplicación Register.war en el servidor tomcat y modificar los parametros que se

encuentran en el archivo web.xml que está dentro del directorio WEB-INF; modificar los
parámetros a su conveniencia.
<init-param>
<description>Direccion del Buzon</description>
<param-name>ftpPath</param-name>
<param-value>/home/usuario/Escritorio/servidor/Buzon</param-value>
</init-param>
<init-param>
<description>URL de la Base de Datos</description>
<param-name>urlDB</param-name>
<param-value>localhost/bdmiddleware</param-value>
</init-param>
<init-param>
<description>Usuario del usuario de la BD</description>
<param-name>usrDB</param-name>
<param-value>userDB</param-value>
88 A.2. Ejemplo de instalación de una aplicación que hace uso del middleware
</init-param>
<init-param>
<description>Contrase~
na de la Base de Datos</description>
<param-name>pswDB</param-name>
<param-value>passDB</param-value>
</init-param>
Figura A.3: Directorio principal
A.2.2 Lado cliente
Del lado cliente se cuenta con el archivo SistemaDeReparto.jar, que es la aplicación móvil que
hace uso del middleware.
A.2.2.1. Pasos para instalar el cliente
Los pasos para instalar la aplicación J2ME puede variar dependiendo de el dispositivo móvil. A
continuación se presentan los pasos que fueron probados en un dispositivo Nokia N95 RM-160, Serie
60, Versión 3 y que cuenta con el sistema operativo Symbian OS.
Transferir el archivo SistemaDeReparto.jar al dispositivo móvil, ésto se puede hacer utilizando

una red de corto alcance como Bluetooth o conectando el dispositivo a la computadora vı́a
USB y copiar dicho archivo a la memoria del dispositivo.
Abrir el archivo SistemaDeReparto.jar que ha sido transferido al dispositivo; al hacerlo se

iniciará la instalación de la aplicación.
Durante la instalación se debe seleccionar en que parte se desea instalar la aplicación, puede
ser en la memoria interna del dispositivo o en la memoria MicroSD (si es que el dispositivo
cuenta con una).
Al finalizar la instalación, la aplicación debe estar situada en:

Menu/Aplicaciones/SistemaDeReparto
Java 2 Micro Edition (J2ME) y el manejo de
B
mensajes SMS y MMS
Java es un lenguaje de programación orientado a objetos creado por Sun Microsystems. El objetivo
principal fue crear un entorno de desarrollo de aplicaciones independiente de la plataforma, siguiendo
el eslogan “escribir una vez, ejecuta en cualquier parte”. Actualmente Java es uno de los entornos
de desarrollo de software más populares, éste ofrece la capacidad de desarrollar aplicaciones para
servidores, computadoras de escritorio y hasta en los dispositivos móviles. En la Tabla B.1 se muestran
las distintas familias del lenguaje Java, las cuales han sido creadas para cubrir las distintas necesidades
que el mercado requiere.
J2ME cuenta con dos máquinas virtuales:
J2EE Desarrollo de aplicaciones empresariales distribuidas

J2SE Desarrollo de aplicaciones convencionales para computadoras de escritorio
J2ME Desarrollo de aplicaciones para dispositivos empotrados (móviles)
Java Card Desarrollo de aplicaciones para tarjetas inteligentes
Tabla B.1: Familia del lenguaje Java.
91
92 B.1. Arquitectura J2ME
CVM (Compact Virtual Machine): Utilizada como máquina virtual para la configuración
CDC. Soporta las mismas caracterı́sticas que la máquina virtual de J2SE y esta osientada
a dispositivos de gama alta con procesadores de 32 bits con 2MB o más de memoria RAM.
KVM (Kilobyte Virtual Machine): Es la máquina virtual más pequeña desarrollada por
Sun orientada a dispositivos con bajas capacidades computacionales, es utilizada con la
configuración CLDC.
Java es un lenguaje de programación desarrollado originalmente por Sun Microsystems y liberado

en 1995 como un componente principal de la plataforma Java de dicha empresa. Actualmente se
la define como una plataforma tecnológica más que un lenguaje, si bien fuertemente basado en la
sintaxis y semántica de dicho lenguaje, las implementaciones actuales son complejas, de librerı́as
extensas y con extensa funcionalidad. El lenguaje propiamente dicho tiene mucho de la sintaxis
derivada de C y C++, pero un modelo de objetos más simple y menos facilidades de bajo nivel.
B.1 Arquitectura J2ME
Inicialmente pensadas para correr en dispositivos electrodomésticos como sistemas embebidos,

el paradigma de Java fue ganando terreno en áreas más tradicionales de la computación y sistemas
de información. Las aplicaciones Java se crean a través de un proceso de compilación en tiempo
de diseño, cuyo código objeto no es código máquina de alguna plataforma establecida, sino el
correspondiente a una máquina “virtual”, entendiendo por maquina virtual (VM por sus iniciales en
inglés) como la implementación por software de una máquina (computadora) que ejecuta programas
como si fuese una máquina real. La definición más precisa, sin embargo, es la propuesta por Popek
& Goldberg, 1974 [36], donde se establece que una VM es un “duplicado aislado y eficiente de una
maquina real”.
Un programa escrito en Java recibirı́a servicios del entorno en tiempo de ejecución Java (Java
Runtime Environment, JRE) a través de la emisión de comandos de los cuales el resultado esperado
es devuelto por el JRE. Al proveer dichos servicios al programa, el JRE está actuando como una
“máquina virtual”, tomando el lugar del sistema operativo o hardware para el cual el programa
normalmente deberı́a haber sido escrito.
Esencialmente, este código intermedio – conocido como bytecode- se ejecutará en una máquina
virtual de procesos, que puede ser conceptualizada como un conjunto de servicios. El código máquina
es al microprocesador lo que el código intermedio es a la máquina virtual. En la práctica, el bytecode
se traduce en bloques a código máquina, mediante un proceso de interpretación, y últimamente
se ha conseguido una significativa ganancia en rendimiento a través de técnicas de compilación
en tiempo de ejecución sobre demanda (Just-In-Time compilers). Como esta compilación se realiza
incrementalmente, a petición, subiendo y procesando los bloques necesarios en la aplicación, podemos
decir que la compilación final se realiza en memoria, para obtener el código máquina que realmente
se ejecuta.
B.2 Caracterı́sticas J2ME
Esta plataforma fue creada originalmente para enfrentar los problemas derivados de su uso en
dispositivos pequeños. La definición de Java SE se concentra en encajar en dicho entorno limitado, y
hacer posible la creación de aplicaciones Java para dispositivos con poca memoria, pantalla pequeña
y limitada capacidad de energı́a / autonomı́a.
Esta tecnologı́a está basada en tres elementos:
Configuración: provee un conjunto básico de bibliotecas y capacidades de la máquina virtual

para una gran cantidad de dispositivos. Define una mı́nima plataforma para una categorı́a
horizontal de dispositivos, cada uno con requerimientos similares en cantidades de memoria
total y poder de procesamiento. Una configuración establece y define el lenguaje Java y las
caracterı́sticas de la máquina virtual y bibliotecas de clases mı́nimas que un fabricante de
dispositivos o un proveedor de contenido espera encontrar en todos los dispositivos de una
misma categorı́a.
Perfil: un conjunto de APIs para soportar un conjunto más reducido de dispositivos. Conforma
94 B.2. Caracterı́sticas J2ME
una capa por encima de la configuración, y por lo tanto la extiende, al mismo tiempo que
atiende la demanda especifica de un determinado mercado “vertical”o familia de dispositivos.
El objetivo principal de un perfil es garantizar interoperabilidad con una determinada familia de
dispositivos o dominio, definiendo un estándar Java para dicho mercado. Los perfiles incluyen
bibliotecas de clases que son más especı́ficas de dominio que las clases provistas en una
configuración.
Paquetes opcionales: conjunto de APIs de tecnologı́a especı́fica.
La plataforma Java ME ha sido a su vez dividida en dos configuraciones de base: una para
pequeños dispositivos móviles y otra diseñada para dispositivos móviles con más capacidad, como
decodificadores de televisión digital, sistemas de navegación en automóviles, etc.
La primera configuración, para pequeños dispositivos, se conoce como Configuración para

Dispositivos con Conectividad Limitada o CLDC por sus iniciales en inglés. La segunda, con más
capacidad, se denomina Perfil de Dispositivo Conectado, CDC. En la Figura B.1 se indican los
bloques fundamentales de cada variante.
Figura B.1: Bloques fundamentales de CDC y CLDC.

B.3 Servicio de mensajes cortos (SMS)
SMS es un servicio disponible actualmente para el envı́o de pequeños mensajes de texto entre
celulares, teléfonos fijos y computadoras, pero sus comienzos fueron en Europa junto con la red GSM
debido a su capacidad de transporte de datos digitales y se extendió luego a las redes TDMA y CDMA.
Si bien empezó como un servicio anexo, hoy en dı́a juega un rol fundamental en las comunicaciones.
Los mensajes son enviados a través de las bandas de frecuencias más altas y ocupan muy poco ancho
de banda, siendo del tipo punto a punto. Se diferencian dos tipos según su procedencia: los SM-MT
y los SM-MO, los primeros se envı́an hacı́a los teléfonos móviles y los segundos se envı́an desde los
teléfonos móviles.
Sus usuarios principales son los jóvenes intercambiando mensajes sucintos, además de esto, se
puede extender a juegos, servicios de notificación, recepción de correos electrónicos, servicios de
información, y servicios basados en la ubicación.
Ejemplo de un programa escrito en J2ME para el envı́o de un mensaje SMS:
import javax.microedition.midlet.*;
import javax.microedition.io.*;
import javax.microedition.lcdui.*;
import javax.wireless.messaging.*;
public class SMS extends MIDlet {

protected void startApp() {
new Thread( new Runnable( ) {
public void run( ) {
try {
MessageConnection con = (MessageConnection)Connector.open( "sms://
+5550000:50000" );
TextMessage mensaje = (TextMessage)con.newMessage( MessageConnecti
96 B.4. Servicio de mensajes multimedia (MMS)
on.TEXT_MESSAGE );
mensaje.setPayloadText( "Mensaje SMS" );
con.send( mensaje );
con.close();
}
catch( Throwable e ) {
e.printStackTrace();
}
}
}).start( );
}
protected void pauseApp() {}
protected void destroyApp( boolean flag ) {}
}
B.4 Servicio de mensajes multimedia (MMS)

A continuación se muestra un ejemplo para el envı́o de mensajes multimedia MMS en J2ME:
import javax.microedition.midlet.*;
import javax.microedition.io.*;
import javax.wireless.messaging.*;
import java.io.*;
import javax.microedition.io.file.*;
public class MMS extends MIDlet {

protected void startApp() {
new Thread( new Runnable( ) {
public void run( ) {
try {
MessageConnection con = (MessageConnection)Connector.open( "mms:/
/+5550000" );
MultipartMessage mensaje = (MultipartMessage)con.newMessage(
MessageConnection.MULTIPART_MESSAGE);
FileConnection myFc = (FileConnection) Connector.open( "arch_imag
en.jpeg" );
InputStream in = myFc.openInputStream( );
byte[] bImage = new byte[(int)myFc.fileSize()];
in.read( bImage );
in.close();
mensaje.addMessagePart( new MessagePart(bImage, 0, bImage.length,
"image/jpeg", "iden", "arch_imagen", null));
mensaje.setHeader("X-Mms-Priority", "high");
mensaje.setSubject( "Mensaje MMS de prueba");
mensaje.setAddress( "mms://+5550000" );
con.send( mensaje );
con.close();
} catch( Throwable e ) {
e.printStackTrace();
}
}
}).start( );
}
protected void pauseApp() {}
protected void destroyApp( boolean flag ) {}
}
Descripción de las clases del middleware
C
C.1 Clases cliente
C.1.1 Clase HexCodec
public class HexCodec extends java.lang.Object
Clase que proporciona un conjunto de métodos para la conversión de ’Strings’ en arreglos de

’bytes’ y viceversa.
Métodos:
public HexCodec(): Constructor de la clase HexCodec
public static java.lang.String bytesToHexString(byte[] bytes): Método estático para la

conversión de una arreglo de ’bytes’ a un ’String’ de dı́gitos hexadecimales.
Parametros:
bytes - Arreglo de ’bytes’ que será convertido a un ’String’ de dı́gitos hexadecimales
Retorno:
99
100 C.1. Clases cliente
Regresa un ’String’ de dı́gitos hexadecimales
public static byte[] hexStringToBytes(java.lang.String hex): Método estático para la conversión

de un ’String’ de dı́gitos hexadecimales a un arreglo de ’bytes’.
Parametros:
hex - ’String’ de dı́gitos hexadecimales
Retorno:
Regresa un arreglo de ’bytes’ obtenido del ’String’ de dı́gitos hexadecimales
public static boolean isHexString(java.lang.String str): Método estático para validar que un
’String’ sólo contenga dı́gitos hexadecimales.
Parametros:
str - ’String’ a ser verificado
Retorno:
Reresa ’true’ si el ’String’ sólo contiene dı́gitos hexadecimales, de lo contrario regresa ’false’
C.1.2 Interface DataInterface
public interface DataInterface
Interface que proporciona los métodos para establecer los datos necesarios para la configuración
de algún servidor.
Métodos:
void setUser(java.lang.String u): Método para establecer la cadena con el nombre del usuario.
Parametros:
u - ’String’ con el nombre del usuario
void setPassword(java.lang.String p): Método para establecer la cadena con la contraseña del
usuario.
Parametros:
p - ’String’ con la contraseña del usuario
void setIPPort(java.lang.String ipp): Método para establecer la cadena con la IP y el puerto

de configuración. El formato debe ser ’IP:Puerto’
Parametros:
ipp - ’String’ con el IP/Puerto del usuario
void setMMSData(java.lang.String em): Método para establecer el correo electrónico necesario

para la configuración del cliente.
Parametros:
em - ’String’ con el correo electrónico configurado por el usuario
void setConnection(int connection): Método para establecer el tipo de conexión que se

utilizará a la hora de transmitir datos (Wi-Fi/GPRS/MMS).
Parametros:
connection - Entero con el tipo de conexión a establecer
C.1.3 Interface AllInterfaces
public interface AllInterfaces extends MenuInterface, DataInterface
Interface que extiende las interfaces ’MenuInterface’ y ’DataInterface’ para proporcionar una
nueva interface que cuente con todos los métodos de ambas.
C.1.4 Interface MenuInterface
public interface MenuInterface
Interface que proporciona los métodos para que una clase pueda establecer un menú o ruta a
algún archivo o directorio.
Métodos:
void setMenu(): Método para establecer el menú de un MIDLet.

void setRuta(java.lang.String r): Método para establecer la ruta a algún archivo o directorio.
Parametros:
r - Ruta a ser establecida
C.1.5 Clase FTPClient
public class FTPClient extends java.lang.Object
Clase que proporciona un cliente FTP y los métodos para el manejo de transferencia de archivos
desde el dispositivo móvil.
Métodos:
public FTPClient(): Constructor de la clase FTPClient.
public void connect(java.lang.String url, java.lang.String user, java.lang.String pass) throws

java.io.IOException: Método para conectarse a un servidor FTP con una URL, usuario y
contraseña especı́ficos.
Parametros:
url - URL para conectarse al servidor FTP. El formato debe ser ’socket://[IP]:[Puerto]’
user - Cuenta del usuario que se conectara al servidor FTP
pass - Contraseña del usuario que se conectara al servidor FTP
Throws:
java.io.IOException
public void disconnect() throws java.io.IOException: Método para desconectarse del servidor
FTP.
Throws:
java.io.IOException
public boolean stor(javax.microedition.io.file.FileConnection file) throws java.io.IOException:

Método para enviar un archivo al servidor FTP.
Parametros:
file - Clase ’FileConnection’ que contiene la información del archivo a ser enviado
Retorno:
Regresa ’true’ si el archivo se alamaceno correctamente, de lo contrario regresa ’false’
Throws:
java.io.IOException
public boolean stor(java.io.InputStream input, java.lang.String filename) throws

java.io.IOException: Método para enviar un archivo al servidor FTP.
Parametros:
input - Flujo de entrada al archivo a ser enviado
filename - Nombre del archivo a ser enviado
Retorno:
Throws:
java.io.IOException
public boolean retr(javax.microedition.io.file.FileConnection file) throws java.io.IOException:

Método para obtener un archivo desde el servidor FTP.
Parametros:
file - Clase ’FileConnection’ que contiene la información del archivo a ser obtenido
Retorno:
Regresa ’true’ si el archivo se obtuvo correctamente, de lo contrario regresa ’false’
Throws:
java.io.IOException
public boolean retr(java.io.OutputStream output, java.lang.String filename)

throws java.io.IOException: Método para obtener un archivo desde el servidor FTP.
Parametros:
output - Flujo de salida para escribir el archivo obtenido
filename - Nombre del archivo a ser obtenido

Retorno:
Regresa ’true’ si el archivo se obtuvo correctamente, de lo contrario regresa ’false’
Throws:
java.io.IOException
public boolean bin() throws java.io.IOException: Método para entrar en modo binario para el
envı́o de archivos.
Retorno:
Regresa ’true’ si entro en modo binario, de lo contrario regresa ’false’
Throws:
java.io.IOException
public boolean ascii() throws java.io.IOException: Método para entrar en modo ASCII para el
envı́o de archivos de texto. Usualmente es el modo por default.
Retorno:
Regresa ’true’ si entro en modo ASCII, de lo contrario regresa ’false’
Throws:
java.io.IOException
C.1.6 Clase Crypto
public class Crypto extends java.lang.Object
Clase que proporciona varios métodos para la encriptación/desencriptación de archivos y la

creación de resúmenes de mensajes (digests).
Métodos:
public Crypto(): Constructor de la clase Crypto.
public static void criptFile(java.lang.String inFile, java.lang.String outFile)

throws java.io.IOException, java.security.NoSuchAlgorithmException,
javax.crypto.NoSuchPaddingException, java.lang.Illegal-
StateException,
javax.crypto.ShortBufferException, javax.crypto.IllegalBlockSizeException,
javax.crypto.BadPaddingException, java.security.InvalidKeyException: Método para la
encriptación de un archivo.
Parametros:
inFile - Ruta al archivo de entrada que se desea encriptar
outFile - Ruta al archivo de salida, éste será el archivo encriptado
Throws:
java.io.IOException
java.security.NoSuchAlgorithmException
javax.crypto.NoSuchPaddingException
java.lang.IllegalStateException
javax.crypto.ShortBufferException
javax.crypto.IllegalBlockSizeException
javax.crypto.BadPaddingException
java.security.InvalidKeyException
public static void decriptFile(java.lang.String inFile, java.lang.String outFile)

javax.crypto.NoSuchPaddingException, java.lang.IllegalStateException,
desencriptación de un archivo.
Parametros:
inFile - Ruta al archivo de entrada que se desea desencriptar
outFile - Ruta al archivo de salida, éste será el archivo desencriptado
Throws:
java.io.IOException
public static byte[] getDigest(java.lang.String usr, java.lang.String pass)

throws java.security.NoSuchAlgorithmException, java.security.DigestException: Método para la
creación de un resúmen de mensaje de 20 bytes, el cual se genera utilizando los dos parámetros
de entrada.
Parametros:
usr - Cadena con el nombre del usuario que será utilizada para generar el reumen
pass - Cadena con la contraseña del usuario que será utilizada para generar el reumen
Retorno:
Regresa un arreglo de 20 bytes que contiene el resumen de las dos cadenas recibidas como
parámetros
Throws:
java.security.DigestException
C.1.7 Clase UserData
public class UserData extends javax.microedition.lcdui.Form implements MenuInterface,

javax.microedition.lcdui.CommandListener, javax.microedition.lcdui.ItemStateListener
Clase que proporciona un formulario para poder llenar los datos del usuario.
Métodos:
public UserData(AllInterfaces mid, javax.microedition.lcdui.Display d, java.lang.String ru,

java.lang.String usr, java.lang.String pass, java.lang.String ipp, java.lang.String em, int con):
Constructor de la clase UserData.
Parametros:
mid - MIDLet con el que se va a comunicar la clase, éste debe extender la interface
’AllInterfaces’ para comunicarse a través de los métodos que proporciona dicha interface.
d - Display para poder desplegar objetos en la pantalla mientras se está bajo el control de la
clase ’UserData’.
ru - ’String’ que contiene la ruta por default de la aplicación
usr - ’String’ que contiene el usuario por default de la aplicación
pass - ’String’ que contiene la contraseña por default de la aplicación
ipp - ’String’ que contiene el ’[IP]:[Puerto]’ por default de la aplicación
em - ’String’ que contiene el correo electrónico por default de la aplicación
con - Entero que contiene el tipo de conexión por default de la aplicación
public void itemStateChanged(javax.microedition.lcdui.Item item): Método para el manejo de

eventos sobre los ’Item’ del formulario.
Parametros:
item - ’Item’ activado por el evento
public void commandAction(javax.microedition.lcdui.Command c,

javax.microedition.lcdui.Displayable d): Método para indicar las acciones que se deben realizar
cuando se produzca un evento en el comando ’c’que se encuentra en el objeto ’d’.
Parametros:
c - Clase ’Command’ que contiene el comando que fue activado por el evento
d - Clase ’Displayable’ que contiene el objeto actual desplegado en pantalla
public void setMenu(): Método para establecer el menú de un MIDLet.

public void setRuta(java.lang.String r): Método para establecer la ruta a algún archivo o
directorio.
Parametros:
r - Ruta a ser establecida
C.1.8 Clase SelecPath
public class SelecPath extends javax.microedition.lcdui.List implements

javax.microedition.lcdui.CommandListener
Clase para el manejo de la selección de rutas a archivos o directorios en el dispositivo móvil.

Métodos:
public SelecPath(MenuInterface cp, javax.microedition.lcdui.Display d, boolean opc):

Constructor de la clase ’SelecPath’.
Parametros:
cp - Clase padre con la que se va a comunicar, ésta debe implementar a la interface
’MenuInterface’ para poder comunicarse a traves de los métodos que dicha interface
proporciona
d - Clase ’Display’ para poder desplegar objetos en la pantalla mientras se esta seleccionando
la ruta
opc - Parámettro booleano para indicarle a la clase si se va a seleccionar un arhivo o directorio.
Si ’opc’ es ’true’ se desplegarán en la pantalla tanto archivos como directorios; de lo contrario,
si ’opc’ es ’false’ solamente se desplegarán los directorios
public void selectPath(): Método para seleccionar la ruta de manera recursiva. Si el objeto
seleccionado es un directorio, a continuación se desplegarán los subdirectorios y archivos que
se encuentren dentro de éste, dependiendo del valor de ’opc’.
public void commandAction(javax.microedition.lcdui.Command

cm, javax.microedition.lcdui.Displayable d): Método para indicar las acciones que se deben
realizar cuando se produzca un evento en el comando ’c’que se encuentra en el objeto ’d’.
Parametros:
cm - Clase ’Command’ que contiene el comando que fue activado por el evento
d - Clase ’Displayable’ que contiene el objeto actual desplegado en pantalla
C.1.9 Clase MMS
public class MMS extends java.lang.Object
Clase para el manejo del envı́o de archivos a través del servicio de mensajerı́a multimedia MMS.
Métodos:
public MMS(java.lang.String psw, java.lang.String e): Constructor de la clase MMS.

Parametros:
psw - Contraseña de la cuenta de correo electrónico a la que serán enviados los archivos vı́a
MMS
e - Correo electrónico al que serán enviados los archivos vı́a MMS
public void stor(javax.microedition.io.file.FileConnection file)throws java.io.IOException:

Método para enviar un archivo al servidor vı́a MMS.
Parametros:
file - Clase ’FileConnection’ que contiene la información del archivo a ser enviado
Throws:
java.io.IOException
public void stor(java.io.InputStream input, java.lang.String filename, long filesize) throws

java.io.IOException: Método para enviar un archivo al servidor vı́a MMS.
Parametros:
input - Flujo de entrada al archivo a ser enviado

filesize - Tamaño del archivo a ser enviado
Throws:
java.io.IOException
C.1.10 Clase ConnectorMiddleware
public class ConnectorMiddleware extends java.lang.Object
Clase que proporciona varios métodos para el manejo de las conexiones con el servidor.
Métodos:
public ConnectorMiddleware(): Constructor de la clase ConnectorMiddleware.
public static java.lang.Object getConnection(java.lang.String url, java.lang.String usr,

java.lang.String pass, java.lang.String email, int con) throws java.io.IOException: Método
estático para obtener la conexión que se utilizará para la transferencia de datos.
Parametros:
url - URL del servidor FTP. El formato debe ser ’socket://[IP]:[Puerto]’
usr - Usuario con el que se identificara con el servidor FTP
pass - Contraseña del usuario FTP
email - Correo electrónico al qu serán enviados los archivos vı́a mensajes MMS
con - Tipo de conexión que se desea obtener
Retorno:
Regresa una clase tipo ’Object’ a la cual se le debe hacer un ’cast’ según el tipo de conexión
requerida en el parámetro ’con’
Throws:
java.io.IOException
public static int autoDetectConnection(): Método que detecta de manera automática el tipo
de conexión disponible.
Retorno:
Regresa un entero que reprecenta el tipo de conexión disponible. Los valores de retorno pueden
ser las constantes ’WIFI CONNECTION’ o ’MMS CONNECTION’
C.2 Clases servidor
C.2.1 Clase MailReceiverToFTP
public class MailReceiverToFTP extends java.lang.Object
Clase que proporciona un conjunto métodos para la conversión de ’Strings’ en arreglos de ’bytes’
y viceversa.
Métodos:
public MailReceiverToFTP(java.lang.String pop, java.lang.String prt, java.lang.String e,

java.lang.String pass, java.lang.String dirFTP, int FTPp, long m): Constructor de la clase
MailReceiverToFTP.
Parametros:
pop - Servidor POP3 al que se va conectar el cliente
prt - Puerto del servidor POP3
e - Cuenta de correo electrónico
pass - Contraseña de la centa de correo electrónico
dirFTP - ’URL o IP’ del servidor FTP al que serán enviados los archivos descargados desde la
cuenta de correo electrónico
FTPp - Puerto del servidor FTP al que se va a conectar
m - Tiempo en minutos en el que se verificará la recepción de nuevo correo electrónico
public void runMailReceiverToFTP(): Método para ejecutar el clientre de correo electrónico

112 C.2. Clases servidor
C.2.2 Clase FTPClientPC
public class FTPClientPC extends java.lang.Object
Clase que proporciona un cliente FTP y los métodos para el manejo de transferencia de archivos
desde una PC.
Métodos:
public FTPClientPC(): Constructor de la clase FTPClientPC.
public void connect(java.lang.String host) throws java.io.IOException: Método para conectarse

con un servidor FTP al puerto por default (21). El cliente se conectara como un usuario
anonimo.
Parametros:
host - Host o servidor al que se va a conectar el cliente FTP. El formato debe ser ’URL o IP’
Throws:
java.io.IOException
public void connect(java.lang.String host, int port) throws java.io.IOException: Método para
conectarse con un servidor FTP a un puerto especı́fico. El cliente se conectara como un usuario
anonimo.
Parametros:
port - Puerto al que se va a conectar el cliente FTP
Throws:
java.io.IOException
public void connect(java.lang.String host, int port, java.lang.String user, java.lang.String pass)
throws java.io.IOException: Método para conectarse a un servidor FTP con un puerto, usuario
y contraseña especı́ficos.
Parametros:
port - Puerto al que se va a conectar el cliente FTP
user - Cuenta del usuario que se conectara al servidor FTP
pass - Contraseña del usuario que se conectara al servidor FTP
Throws:
java.io.IOException
public void disconnect() throws java.io.IOException: Método para desconectarse del servidor
FTP.
Throws:
java.io.IOException
public boolean stor(java.io.File file) throws java.io.IOException: Método para enviar un archivo
al servidor FTP.
Parametros:
file - Clase ’File’ que contiene la información del archivo a ser enviado
Retorno:
Throws:
java.io.IOException
public boolean stor(java.io.InputStream inputStream, java.lang.String filename) throws

java.io.IOException: Método para enviar un archivo al servidor FTP.
Parametros:
inputStream - Flujo de entrada al archivo a ser enviado
Retorno:
Throws:
java.io.IOException
public boolean bin() throws java.io.IOException: Método para entrar en modo binario para el
envı́o de archivos.
Retorno:
Regresa ’true’ si entro en modo binario, de lo contrario regresa ’false’
Throws:
java.io.IOException
public boolean ascii() throws java.io.IOException: Método para entrar en modo ASCII para el
envı́o de archivos de texto. Usualmente es el modo por default.
Retorno:
Regresa ’true’ si entro en modo ASCII, de lo contrario regresa ’false’
Throws:
java.io.IOException
C.2.3 Clase Register
public class Register extends java.lang.Object
Clase que proporciona un conjunto métodos para la inserción de usuarios en una Base de Datos.
Métodos:
public Register(ServerConfiguration c): Constructor de la clase Register.

Parametros:
c - Clase ’ServerConfiguration’ que contiene los datos datos necesarios para el registro de
usuarios
public boolean newUser(Usuario usr): Método para la inserción de usuarios en la Base de

Datos. Posterior a la inserción del usuario, se crea un subdirectorio en el directorio de trabajo
especificado en la clase ’ServerConfiguration’.
Parametros:
usr - Clase ’Usuario’ que contiene los datos del usuario a ser agregado a la Base de Datos
Retorno:
Regresa ’true’ si el nuevo usuario se agrego correctamente, de lo contrario regresa ’false’
public boolean newUser(java.lang.String nombre, java.lang.String apellidos, java.lang.String

direccion, java.lang.String celular, java.lang.String email, java.lang.String password): Método
para la inserción de usuarios en la Base de Datos. Posterior a la inserción del usuario, se crea
un subdirectorio en el directorio de trabajo especificado en la clase ’ServerConfiguration’.
Parametros:
nombre - Nombre del usuario
apellidos - Apellidos del usuario
direccion - Dirección del usuario
celular - Número de celular del usuario
email - Correo electrónico del usuario
password - Contraseña del correo electrónico del usuario
Retorno:
Regresa ’true’ si el nuevo usuario se agrego correctamente, de lo contrario regresa ’false’
C.2.4 Clase BDConnection
public class BDConnection extends java.lang.Object
Clase que proporciona varios métodos para la manipulación de la Base de Datos.

Métodos:
public BDConnection(java.lang.String path, java.lang.String user, java.lang.String pass):

Constructor de la clase BDConnection.
Parametros:
path - URL de la Base de Datos
user - Usuario para acceder a la Base de Datos
pass - Contraseña del usuario para acceder a la Base de Datos
public boolean connect(): Realiza la conexión a la Base de Datos cargando el driver

’com.mysql.jdbc.Driver’.
Retorno:
Regresa ’true’ si la conexión se llevo a cabo en éxito, de lo contrario regresa ’false’
public boolean addUser(Usuario usr): Agrega un usuario a la Base de Datos.

Parametros:
usr - Usuario a ser dado de alta en la Base de Datos
Retorno:
Regresa ’true’ si la inserción de llevo a cabo con éxito, de lo contrario regresa ’false’
public boolean addUser(java.lang.String nombre, java.lang.String apellidos, java.lang.String

direccion, java.lang.String celular, java.lang.String email, java.lang.String password): Agrega
un usuario a la Base de Datos.
Parametros:
nombre - Nombre del usuario
apellidos - Apellidos del usuario
direccion - Dirección del usuario
celular - Num. de celular del usuario
email - Correo electrónico del usuario
password - Contraseña del usuario
Retorno:
Regresa ’true’ si la inserción de llevo a cabo con éxito, de lo contrario regresa ’false’
public boolean existUser(java.lang.String cell): Verifica si un usuario existe en la Base de Datos.

Parametros:
cell - Número de celular del usuario a ser verificado
Retorno:
Regresa ’true’ si el número de celular del usuario ya existe en la Base de Datos, de lo contrario
regresa ’false’
public Usuario getCampos(java.lang.String cell, java.lang.String pass): Obtiene los datos del
usuario ’cell’ y contraseña ’pass’ que existe en la Base de Datos.
Parametros:
cell - Número de celular del usuario a obtener
pass - Contraseña del usuario a obtener
Retorno:
Regresa una clase ’Usuario’ que contiene todos los datos del usuario
public Usuario getCampos(java.lang.String cell): Obtiene los datos del usuario ’cell’ que existe
en la Base de Datos.
Parametros:
cell - Número de celular del usuario a obtener
Retorno:
Regresa una clase ’Usuario’ que contiene todos los datos del usuario
protected boolean dissconnect(): Realiza la desconexión de la Base de Datos.

Retorno:
Regresa ’true’ si la desconexión se llevo a cabo en éxito, de lo contrario regresa ’false’
C.2.5 Clase ServerConfiguration
public class ServerConfiguration extends java.lang.Object
Clase que contiene la configuración de un servidor; proporciona los métodos ’get’ para obtener
cada uno de los parámetros de configuración.
Métodos:
public ServerConfiguration(java.lang.String dir, int p, java.lang.String dbp, java.lang.String

dbu, java.lang.String dbpw): Constructor de la clase ServerConfiguration.
Parametros:
dir - Directorio de trabajo
p - Puerto de donde se ejecutará la aplicación que utilice esta clase (ServerConfiguration)

dbp - URL de la Base de Datos
dbu - Usuario con acceso a la Base de Datos
dbpw - Contraseña del usuario de la Base de Datos
public java.lang.String getDirPath(): Método para obtener el directorio de trabajo.

Retorno:
Regresa un ’String’ que contiene el directorio de trabajo
public java.lang.String getDBPath(): Método para obtener la URL de la Base de Datos.

Retorno:
Regresa un ’String’ que contiene la URL de la Base de Datos
public java.lang.String getDBUsr(): Método para obtener el usuario de la Base de Datos.

Retorno:
Regresa un ’String’ que contiene el usuario de la Base de Datos
public java.lang.String getDBPass(): Método para obtener la contraseña del usuario de la Base
de Datos.
Retorno:
Regresa un ’String’ que contiene la contraseña del usuario de la Base de Datos
public int getPort(): Método para obtener el puerto de ejecución.

Retorno:
Regresa un ’String’ que contiene el puerto de ejecución
C.2.6 Clase HexCodec
public class HexCodec extends java.lang.Object
Clase que proporciona un conjunto métodos para la conversión de ’Strings’ en arreglos de ’bytes’
y viceversa.
Métodos:
public HexCodec(): Constructor de la clase HexCodec.
public static java.lang.String bytesToHexString(byte[] bytes): Método estático para la

conversión de una arreglo de ’bytes’ a un ’String’ de dı́gitos hexadecimales.
Parametros:
bytes - Arreglo de ’bytes’ que será convertido a un ’String’ de dı́gitos hexadecimales
Retorno:
Regresa un ’String’ de dı́gitos hexadecimales
public static byte[] hexStringToBytes(java.lang.String hex): Método estático para la conversión

de un ’String’ de dı́gitos hexadecimales a un arreglo de ’bytes’.
Parametros:
hex - ’String’ de dı́gitos hexadecimales
Retorno:
Regresa un arreglo de ’bytes’ obtenido del ’String’ de dı́gitos hexadecimales
public static boolean isHexString(java.lang.String str): Método estático para validar que un
’String’ sólo contenga dı́gitos hexadecimales.
Parametros:
str - ’String’ a ser verificado
Retorno:
Reresa ’true’ si el ’String’ sólo contiene dı́gitos hexadecimales, de lo contrario regresa ’false’
C.2.7 Clase Usuario
public class Usuario extends java.lang.Object
Clase que contiene la información del usuario. Proporciona los métodos para establecer (’set’) y
obteger (’get’) cada uno de los datos del usuario.
Métodos:
public Usuario(): Constructor de la clase Usuario.
public void setNombre(java.lang.String nom): Establece el nombre del usuario.

Parametros:
nom - Nombre del usuario
public java.lang.String getNombre(): Obtiene el nombre del usuario.
public void setApellidos(java.lang.String ape): Establece los apellidos del usuario.

Parametros:
ape - Apellidos del usuario
public java.lang.String getApellidos(): Obtiene los apellidos del usuario.
public void setDireccion(java.lang.String dir): Establece la dirección del usuario.

Parametros:
dir - Dirección del usuario
public java.lang.String getDireccion(): Obtiene la dirección del usuario.
public void setCelular(java.lang.String cel): Establece el número de celular del usuario.

Parametros:
cel - Número de celular del usuario
public java.lang.String getCelular(): Obtiene el número de celular del usuario.
public void setEmail(java.lang.String em): Establece el correo electrónico del usuario.

Parametros:
em - Correo electrónico del usuario
public java.lang.String getEmail(): Obtiene el correo electrónico del usuario.
public void setPassword(java.lang.String pass): Establece la contraseña del correo electrónico

del usuario.
Parametros:
em - Contraseña del correo electrónico del usuario
public java.lang.String getPassword(): Obtiene la contraseña del correo electrónico del usuario.
C.2.8 Clase ThreadFTP
public class ThreadFTP extends java.lang.Thread
Clase que da la funcionalidad al servidor FTP, proporcionando los métodos para el manejo de la
transferencia de archivos, además de extender a la clase ’Thread’ para el manejo de concurrencia en
el servidor.
Métodos:
public ThreadFTP(java.net.Socket income, int c): Constructor de la clase ThreadFTP.

Parametros:
income - ’Socket’ que atiende la petición actual
c - Identificador del número de cliente, este número será utilizado para la asignación del puerto
que será utilizado para la transferencia de archivos
public static void setSC(ServerConfiguration c): Método para establecer la configuración del
servidor a través de la clase ’ServerConfiguration’.
Parametros:
c - Configuración del servidor
public void run(): Método para ejecutar el hilo del servidor FTP que atenderá al cliente actual.
Este método es llamado a través del método ’start( )’ de la clase ’Thread’.
C.2.9 Clase FTPServer
public class FTPServer extends java.lang.Object
Clase que proporciona un servidor FTP, ejecutando un hilo por cada cliente que éste atiende.
Métodos:
public FTPServer(ServerConfiguration c): Constructor de la clase FTPServer’.

Parametros:
c - Clase ’ServerConfiguration’ que contiene los datos necesarios para ejecutar el servidor FTP
public void runFTPServer(): Método para ejecutar el servidor FTP.
C.2.10 Clase Crypto
public class Crypto extends java.lang.Object
Clase que proporciona varios métodos para la encriptación/desencriptación de archivos y la

creación de resúmenes de mensajes (digests).
Métodos:
public Crypto(): Constructor de la clase Crypto.
public void criptFile(java.lang.String inFile, java.lang.String outFile)

encriptación de un archivo.
Parametros:
inFile - Ruta al archivo de entrada que se desea encriptar
outFile - Ruta al archivo de salida, éste será el archivo encriptado
Throws:
java.io.IOException
public void decriptFile(java.lang.String inFile, java.lang.String outFile)

desencriptación de un archivo.
Parametros:
inFile - Ruta al archivo de entrada que se desea desencriptar
outFile - Ruta al archivo de salida, éste será el archivo desencriptado
Throws:
java.io.IOException
public static byte[] getDigest(java.lang.String usr, java.lang.String pass)

throws java.security.NoSuchAlgorithmException, java.security.DigestException: Método para la
creación de un resúmen de mensaje de 20 bytes, el cual se genera utilizando los dos parámetros
de entrada.
Parametros:
usr - Cadena con el nombre del usuario que será utilizada para generar el reumen
pass - Cadena con la contraseña del usuario que será utilizada para generar el reumen
Retorno:
Regresa un arreglo de 20 bytes que contiene el resumen de las dos cadenas recibidas como
parámetros
Throws:
java.security.DigestException
Bibliografı́a
[1] Cofetel, Mar. 2009. Disponible en lı́nea en: http://www.cofetel.gob.mx/index.jsp.
[2] IEEE 802.15.1. Wireless medium access control (MAC) physical layer (PHY) specifications
for wireless personal area networks (WPANs), June 2005. Disponible en lı́nea en:
http://standards.ieee.org/getieee802/download/802.15.1-2005 part1.pdf.
[3] B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mambretti, R. Moore, and

B. Teitelbaum. Network policy and services: A report of a workshop on middleware. Technical
report, Copyright (C) The Internet Society (2000). All Rights Reserved., disponible en lı́nea en:
http://www.ietf.org/rfc/rfc2768.txt, Feb. 2000.
[4] Benjamin Atkin and Kenneth P. Birman. Network-aware adaptation techniques for mobile file
systems. In NCA ’06: Proceedings of the Fifth IEEE International Symposium on Network
Computing and Applications, pages 181–188, Washington, DC, USA, 2006. IEEE Computer
Society.
[5] Petros Belimpasakis, Juha-Pekka Luoma, and Mihaly Börzsei. Content sharing middleware
for mobile devices. In MOBILWARE ’08: Proceedings of the 1st international conference
on MOBILe Wireless MiddleWARE, Operating Systems, and Applications, pages 1–8, ICST,
Brussels, Belgium, Belgium, 2007. ICST (Institute for Computer Sciences, Social-Informatics
and Telecommunications Engineering).
[6] Alex E. Bell. Death by UML Fever. Association for Computing Machinery (ACM), Apr. 2004.
Disponible en lı́nea en: http://portal.acm.org/ft gateway.cfm?id=984495&type=pdf.
[7] Mary Bellis. History of cellular phones, Sep. 2009. Disponible en lı́nea en:
http://inventors.about.com/library/weekly/aa070899.htm.
125
126 BIBLIOGRAFÍA
[8] Gwenaël Le Bodic. MOBILE MESSAGING TECHNOLOGIES AND SERVICES SMS, EMS and
MMS. Second edition, 2005.
[9] Malika Boulkenafed and Valérie Issarny. A middleware service for mobile ad hoc data sharing,
enhancing data availability. In Middleware ’03: Proceedings of the ACM/IFIP/USENIX 2003
International Conference on Middleware, pages 493–511, New York, NY, USA, 2003. Springer-
Verlag New York, Inc.
[10] T. G. Brutch and P. C. Brutch. Mutual Authentication, Confidentiality, and Key Management
(MACKMAN) System for Mobile Computing and Wireless Communication. In ACSAC ’98:
Proceedings of the 14th Annual Computer Security Applications Conference, page 308,
Washington, DC, USA, 1998. IEEE Computer Society.
[11] Vinton Cerf, Yogen Dalal, and Carl Sunshine. SPECIFICATION OF INTERNET
TRANSMISSION CONTROL PROGRAM. Network Working Group, Dec. 1974. Disponible
en lı́nea en: http://tools.ietf.org/html/rfc675.
[12] Joan Daemen and Vincent Rijmen. The Design of Rijndael AES - The Advanced Encryption
Standard. Springer, 2002.
[13] Alan Demers, Karin Petersen, Mike Spreitzer, Douglas Terry, Marvin Theimer, and Brent Welch.
The bayou architecture: Support for data sharing among mobile users, 1994.
[14] D. Eastlake and P. Jones. US Secure Hash Algorithm 1 (SHA1) . The Internet Society, Sep.
2001. Disponible en lı́nea en: http://www.ietf.org/rfc/rfc3174.txt.
[15] EmozeTM , Aug. 2009. Disponible en lı́nea en: http://www.emoze.com/.
[16] Juan Antonio Vargas Enrı́quez. A vertical handover platform for applications on
mobile devices. Master’s thesis, CINVESTAV, 2009. Disponible en lı́nea en:
http://www.tamps.cinvestav.mx/sites/default/files/tesis 1.zip.
BIBLIOGRAFÍA 127
[17] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee.

Hypertext Transfer Protocol – HTTP/1.1. The Internet Society, June 1999. Disponible en
lı́nea en: http://www.ietf.org/rfc/rfc2616.txt.
[18] George H. Forman and John Zahorjan. The challenges of mobile computing. Computer,
27(4):38–47, 1994.
TM
[19] Wireless Application Protocol Forum. W AP MMS Architecture Overview. Techni-
cal report, Wireless Application Protocol Forum, Ltd., Apr. 2001. Disponible en lı́nea en:
http://www.openmobilealliance.org/tech/affiliates/wap/wap-205-mmsarchovervi
ew-20010425-a.pdf.
[20] The Apache Software Foundation. Apache tomcat, Jan. 2010. Disponible en lı́nea en:
http://tomcat.apache.org/download-60.cgi.
[21] GMail-Drive, Mar. 2009. Disponible en lı́nea en: http://www.viksoe.dk/code/gmail.htm.
[22] GmailFS, Mar. 2009. Disponible en lı́nea en: http://richard.jones.name/google-hacks

/gmail-filesystem/gmail-filesystem.html.
[23] GSpaceMobile, Mar. 2009. Disponible en lı́nea en: https://www.ibomobi.com/home/.
[24] Apple Inc., Nov. 2009. Disponible en lı́nea en: http://www.apple.com/mobileme/.
[25] University of Southern California Information Sciences Institute. INTERNET PROTOCOL.

The Internet Engineering Task Force (IETF), Sep. 1981. Disponible en lı́nea en:
http://tools.ietf.org/html/rfc791.
[26] Gerald Q. Maguire Jr. IK2555 Mobile and Wireless Network Architectures, Nov. 2009. Disponible
en lı́nea en: http://www.it.kth.se/courses/IK2555/MWA-20090125.pdf.
[27] J. Klensin. Simple Mail Transfer Protocol. The Internet Society, Oct. 2008. Disponible en lı́nea
en: http://tools.ietf.org/html/rfc5321.
128 BIBLIOGRAFÍA
[28] James F. Kurose and Keith W. Ross. Computer Networking: A Top-Down Approach Featuring
the Internet. 3rd edition, 2000.
[29] John C. S. Lui, Oldfield K. Y. So, and T. S. Tam. NFS/M: An Open Platform Mobile File
System. In ICDCS ’98: Proceedings of the The 18th International Conference on Distributed
Computing Systems, page 488, Washington, DC, USA, 1998. IEEE Computer Society.
[30] C. Mascolo, L. Capra, S. Zachariadis, and W. Emmerich. Xmiddle: A data-sharing middleware

for mobile computing. Int. Journal on Personal and Wireless Communications, 21(1):77–103,
April 2002.
[31] Sun Microsystems. JavaTM Look and Feel Design Guidelines, second edition , Feb. 2001.
Disponible en lı́nea en: http://java.sun.com/products/jlf/ed2/book/index.html.
[32] Sun Microsystems. Sun Java Wireless Toolkit for CLDC, Nov. 2009. Disponible en lı́nea en:
http://java.sun.com/products/sjwtoolkit/overview.html.
[33] J. Myers and M. Rose. Post Office Protocol - Version 3. The Internet Society, May 1996.
Disponible en lı́nea en: http://tools.ietf.org/html/rfc1939.
[34] S. V. Nagaraj. Cache Replacement Algorithms, volume 772 of The Springer International Series
in Engineering and Computer Science, chapter 7, pages 61–72. Springer Netherlands, apr 2006.
[35] Ernesto Piedras, Carla Bonina, Gonzalo Rojón, Viviana Vallejo León, Martha Lagunas Arellano,
and Caroline Verut. Contribuciones sociales y económicas de la telefonı́a móvil en méxico.
Technical report, TELECOM CIDE, 2006.
[36] Gerald J. Popek and Robert P. Goldberg. Formal requirements for virtualizable third generation
architectures. Commun. ACM, 17(7):412–421, 1974.
[37] J. Postel. User Datagram Protocol . The Internet Engineering Task Force (IETF), Aug. 1980.
Disponible en lı́nea en: http://www.ietf.org/rfc/rfc0768.txt.
BIBLIOGRAFÍA 129
[38] J. Postel and J. Reynolds. FILE TRANSFER PROTOCOL (FTP). Network Working Group,
Oct. 1985. Disponible en lı́nea en: http://tools.ietf.org/html/rfc959.
[39] Ronald L. Rivest. Cryptography. pages 617–755, 1990.
[40] Ronald L. Rivest. All-or-nothing encryption and the package transform. In FSE ’97: Proceedings
of the 4th International Workshop on Fast Software Encryption, pages 210–218, London, UK,
1997. Springer-Verlag.
[41] MIT Lab for Computer Science Ronald L. Rivest. Chaffing and Winnowing: Confidentiality
without Encryption. Association for Computing Machinery (ACM), Mar. 1998. Disponible en
lı́nea en: http://people.csail.mit.edu/rivest/Chaffing.txt.
[42] Robert Schlaff. Confidentiality

Using Authentication. Association for Computing Machinery (ACM), Jan. 2001. Disponible
en lı́nea en: http://www.acm.org/crossroads/xrds5-2/confide.html.
[43] Inc. Sierra Wireless, Nov. 2002. Disponible en lı́nea en:

http://www.sierrawireless.com/documents/corporate/2130273 WWAN v WLAN.pdf.
[44] Bluetooth Special Group (SIG). Bluetooth Protocol Architecture, Aug. 1999. Disponible en lı́nea
en: http://bluetooth.com/NR/rdonlyres/7F6DEA50-05CC-4A8D-B87B-F5AA02AD78EF/0
/Protocol Architecture.pdf.
[45] Bluetooth Special Group (SIG). RFCOMM with TS 07.10, June 2003. Disponible en lı́nea en:
http://www.bluetooth.com/NR/rdonlyres/1483FFFD-7A5C-49A8-9AFE-1156DA1D96C3/
916/rfcomm1.pdf.
[46] Bluetooth Special Group (SIG). Bluetooth Baseband, Sep. 2009. Disponible en lı́nea en:
http://bluetooth.com/Bluetooth/Technology/Works/Architecture Baseband.htm.
[47] Bluetooth Special Group (SIG). History of Bluetooth Technology, Sep. 2009. Disponible en
lı́nea en: http://www.bluetooth.com/Bluetooth/SIG/History of the SIG.htm.
130 BIBLIOGRAFÍA
[48] Inc. Sun Microsystems. Connected Limited Device Configuration. Specification Version 1.1.
Technical report, Sun
Microsystems, Santa Clara, California 95054. U.S.A. 650-960-1300, Mar. 2003. Disponible en
lı́nea en: http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html.
[49] Inc. Sun Microsystems. Java se runtime environment (jre), Jan. 2010. Disponible en lı́nea en:
http://java.sun.com/javase/downloads/index.jsp.
[50] Inc. Sun Microsystems. Mysql community server, Jan. 2010. Disponible en lı́nea en:
http://dev.mysql.com/downloads/mysql/.
[51] Inc. Sun Microsystems and Inc. Motorola. Mobile Information Device Profile. Specification
Version 2.0. Technical report, Sun Microsystems, Nov. 2002. Disponible en lı́nea en:
http://jcp.org/aboutJava/communityprocess/final/jsr118/index.html.
[52] USRobotics
R
. Wireless LAN Networking, Oct. 2009. Disponible en lı́nea en:
http://www.usr.com/download/whitepapers/wireless-wp.pdf.
[53] VeriSign. Company information, Jan. 2010. Disponible en lı́nea en:

http://www.verisign.com/corporate/information/index.html.
[54] D.L. Willick, D.L. Eager, and R.B. Bunt. Disk cache replacement policies for network fileservers.
In Distributed Computing Systems, 1993., Proceedings the 13th International Conference on,
pages 2–11, May 1993.
[55] Jui-Hung Yeh, Jyh-Cheng Chen, and Chi-Chen Lee. WLAN standards. Potentials, IEEE,
22(4):16–22, Oct.-Nov. 2003.

Tesis - Mario Alberto Gomez Rodriguez

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesis - Mario Alberto Gomez Rodriguez

Uploaded by

Copyright:

Available Formats

Centro de Investigación y de Estudios Avanzados

del Instituto Politécnico Nacional

Laboratorio de Tecnologı́as de Información

Middleware para almacenamiento

Tesis que presenta:

Mario Alberto Gómez Rodrı́guez

Para obtener el grado de:

Cd. Victoria, Tamaulipas, México. Febrero, 2010

Dr. José Guadalupe Rodrı́guez Garcı́a

Dr. Javier Rubio Loyola

Dr. Vı́ctor Jesús Sosa Sosa, Director

Cd. Victoria, Tamaulipas, México., 26 de Febrero de 2010

Agradezco mucho a mi familia por que siempre me ha apoyado en lo que hago.

Índice de Tablas VII

2. Marco teórico y trabajos relacionados 9

5. Conclusiones y trabajo futuro 79

A. Cómo utilizar el middleware 83

B. Java 2 Micro Edition (J2ME) y el manejo de mensajes SMS y MMS 91

C. Descripción de las clases del middleware 99

1.1. Eventos relevantes en el mercado de telecomunicaciones en México . . . . . . . . . 3

2.1. Desde las redes PAN hasta las RAN. . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1. Middleware para almacenamiento externo para dispositivos móviles. . . . . . . . . . 38

4.1. Tamaño óptimo de bloque en una red WLAN. . . . . . . . . . . . . . . . . . . . . 67

A.1. Aspecto de la herramienta KToolBar del J2ME Wireless Toolkit . . . . . . . . . . . 85

B.1. Bloques fundamentales de CDC y CLDC. . . . . . . . . . . . . . . . . . . . . . . . 94

1.1. Fases del mercado de telefonı́a móvil en México . . . . . . . . . . . . . . . . . . . 2

2.1. Las capas y protocolos en la pila de protocolos Bluetooth . . . . . . . . . . . . . . 12

3.1. Ventajas y desventajas de las redes inalámbricas y el MMS. . . . . . . . . . . . . . 39

4.1. Medidas comunes en celulares y PDAs. . . . . . . . . . . . . . . . . . . . . . . . . 69

B.1. Familia del lenguaje Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Middleware para almacenamiento externo para dispositivos

Mario Alberto Gómez Rodrı́guez

En la actualidad el sistema común de respaldo en los dispositivos móviles implica el uso de

External Storage Middleware for Wireless Devices with

Mario Alberto Gómez Rodrı́guez

1.1 Contexto del proyecto

Fase Estructura prevista

Tabla 1.1: Fases del mercado de telefonı́a móvil en México

Figura 1.1: Eventos relevantes en el mercado de telecomunicaciones en México

de cómputo, ası́ como nuevas interfaces de comunicaciones.

Figura 1.2: Usuarios desde 1990 hasta 2008 según COFETEL

1.2 Descripción del problema

Hoy en dı́a la comunicación entre plataformas heterogéneas es muy común, además de la

en las distintas plataformas. Lo anterior ha potenciado el uso de tecnologı́as conocidas como

1.3.1 Objetivo general

1.3.2 Objetivos particulares

Desarrollar un middleware para la transferencia de archivos, que permita el intercambio de

Desarrollar una aplicación que haga uso del middleware (Swapper).

Desarrollar un módulo para validar la disponibilidad de conexión con la red Wi-Fi.

Diseminación de los resultados obtenidos durante el desarrollo de la tesis.

Análisis de requerimientos previo al desarrollo del software mediador (middleware) para la

Desarrollo de un software mediador (middleware) que dé soporte a la transferencia de archivos

Desarrollo de una aplicación que utilice el middleware desarrollado anteriormente.

Evaluación de la aplicación y análisis de los resultados obtenidos.

2.1 Descripción de sistemas de comunicación inalámbrica

Figura 2.1: Desde las redes PAN hasta las RAN.

Figura 2.2: Pila de protocolos Bluetooth

Capa del protocolo Protocolos en la pila

Tabla 2.1: Las capas y protocolos en la pila de protocolos Bluetooth

Protocolos núcleo de Bluetooth: La banda base (Baseband) y la capa de control de enlace

Protocolo de sustitución de cable: RFCOMM [45] (Radio Frequency Communication)

Protocolos de control de telefonı́a: El protocolo de control de telefonı́a - binario (TCS

Protocolos adoptados: En la tecnologı́a Bluetooth, PPP ( IETF Point-to-Point Protocol)