Embed Size (px)
Citation preview
Universidad Tecnica Federico Santa Marıa
Departamento de Electronica
Intermediario Activo para la Comunicacion
M2M Multiproposito.
Memoria presentada por
Daniel Enrique Caro Penaloza
como requisito parcial para optar al tıtulo de
Ingeniero Civil Telematico
Profesor Guıa
Dr. Werner Creixell
Co-referente
Dr. Tomas Arredondo
Valparaıso, Noviembre 2011
Tıtulo de la Memoria:
Intermediario Activo para la Comunicacion M2M Multiproposito.
Autor:
Daniel Enrique Caro Penaloza
Memoria de Tıtulo, presentada como requisito parcial para optar al tıtulo de
Ingeniero Civil Telematico de la Universidad Tecnica Federico Santa Marıa.
Comision:
Dr. Werner Creixell
Dr. Tomas Arredondo
Valparaıso, Noviembre 2011
Dedicado a mis padres.
RESUMEN
La mayorıa de las ideas fundamentales de la ciencia son esencialmente sencillas y,
por regla general pueden ser expresadas en un lenguaje comprensible para todos.
Albert Einstein
CONTAR con un entorno inteligente, ha sido la fantasıa de muchos escritores
y cientıficos por anos. Esta aspiracion cada vez esta mas cerca de conver-
tirse en una realidad, ya que la proxima generacion de redes estara abocada
directamente a la comunicacion entre maquinas, y a que estas esten totalmente
integradas a nuestra vidas. Actualmente, algunos de los principales usos de la
comunicacion entre maquinas incluyen la telemetrıa, la domotica, la seguridad,
el control de flota y las redes de sensores.
Los avances tecnologicos han permitido desarrollar dispositivos de menor
tamano, economicos y con mayor capacidad de procesamiento y comunicacion,
lo que ha derivado en que el mercado de las comunicaciones entre maquinas
cada dıa se vuelva mas atractivo. El factor que embaraza todos estos procesos
esta radicado en la inversion de tiempo y recursos necesarios para resolver los
problemas de comunicacion e identificacion de dispositivos, problematica que se
sera tratada y solucionada en esta memoria, mediante un intermediario activo
para la comunicacion entre maquinas y las librerıas necesarias para poder uti-
lizar este intermediario.
i
Resumen ii
En primer lugar, se abordara un estudio detallado de las tecnologıas de co-
municacion entre maquinas, su mercado, tecnologıas y soluciones disponibles,
permitiendo determinar los principales retos de la comunicacion entre maquinas,
dando las directrices y requerimientos de la herramienta a desarrollar. Para con-
tinuar con un diseno general de la solucion que contempla el intermediario acti-
vo, los conectores y las respectivas puertas de enlace para adaptar dispositivos
heterogeneos.
En el desarrollo del documento se detallara como se ha disenado e imple-
mentado cada componente de esta solucion: primero el intermediario activo o
broker, para luego continuar con los de terminales; por un lado los dispositivos
remotos y por otro los coordinadores de cada solucion, entendiendo desde ya
que el broker es un intermediario con la capacidad de almacenar y distribuir
mensajes a esos dispositivos.
Finalmente se explicaran los pasos a seguir para crear una solucion que por
vıa ejemplificativa, demostrara que el desarrollador solo debe tener presente los
dispositivos que participaran y que logica de negocio deberan seguir al fun-
cionar, mientras que los problemas relacionados a la comunicacion, seguridad,
identificacion y distribucion quedan manejados por el broker.
Palabras Clave
• Modulos GPRS • Gateway • Telemetrıa • Sockets No Bloqueantes • Ma-
chine To Machine (M2M) • Desarrollo de software Modular • Middleware Ori-
entado a Mensaje (MOM) • Broker • J2ME • Persistencia • Cinterion TC-65i
• Java • Google Guice • Mobile Middleware in Enterprise Systems
Acronimos
ABI Allied Business Intelligence. 4
ADC Analog to Digital Converter. 7
AMR Automatic Meter Reading. 50
API Application Programming Interface. 8, 13, 14,
45
APN Access Point Network. 54
ARM Advanced RISC Machine. 9
B2B Board To Board. 45
CDC Connected Device Configuration. 44
CLDC Connected Limited Device Configuration. 44,
45, 47
CPU Central Processing Unit. 7
DPWS Devices Profile for Web Services. 8
EDGE Enhanced Datas rates for GSEM Evolution.
54
GPIO General Purpose Input Output. 16
GPRS General Packet Radio Service. 2, 6, 8, 15, 27,
35, 54
GPS Global Positioning System. 7, 50
GSM Global System for Mobile Communication. 6,
27
iii
Glossary iv
I2C Inter-Integrated Circuit. 7, 16, 29
IDE Integrated development environment. 55
IMEI International Mobile Equipment Identity. 15,
20, 29
IMSI International Mobile Subscriber Identity. 20,
54, 55
IO Input Output. 7
IP Internet Protocol. 20, 22
J2ME Java 2 Micro Edition. 14, 15, 22, 47, 57
J2SE Java 2 Standard Edition. 14, 15, 47
JDBC Java DataBase Connectivity. 7, 48
JMS Java Message Service. 12, 17, 40
JTAG Joint Test Action Group. 44
JVM Java Virtual Machine. 44, 46
M2M Machine To Machine. 1, 2, 9, 15, 38, 50, 51
MAC Media Access Control. 20
MCC Mobile Country Code. 54, 55
MES Module Exchange Service. 52
MIDP Mobile Information Device profile. 45
MINA Multipurpose Infrastructure Networked Ap-
plications. 46
MNC Mobile Network Code. 54, 55
MOM Message Oriented Middleware. 21
MQTT Message Queue Telemetry Transport. 7
MTU Maximum Transmission Unit. 21, 22
NIO New Input Output or Non blocking Input Out-
put. 15, 25, 46
OSGi Open Services Gateway Initiative. 18, 28
PIN Personal Identification Number. 29
Glossary v
RAM Random Access Memory. 7
REST Representational State Transfer. 17
ROM Read Only Memory. 7
SCADA Supervisory Control And Data Acquisition. 3
SDK Software Development Kit. 45, 52, 57
SEDA Staged Event Driven architecture. 46
SIM Subscriber Identity Module. 29
SMS Short Message Service. 6, 8, 17, 29, 40, 49
SMTK Siemens Mobility Tool Kit. 53
SOA Service Oriented Architecture. 16
SOAP Simple Object Access Protocol. 8
SPI Serial Peripheral Interface(Hardware) o Ser-
vice Provider Interface(Software). 7, 9, 16, 25,
29
TCP Transmission Control Protocol. 15, 45
TTM Time To Market. 7
UART Universal Asynchronous Receiver Transmit-
ter. 7
UDP User Datagram Protocol. 8, 17, 45
UPnP Universal Plug and Play. 8
URC Unsolicited Result Code. 29, 55
WS Web Service. 12, 17
WS4D Web Service For Device. 8
WSN Wireless Sensor Network. 5
XDR External Data Representation. 8
XML Extensible Markup Language. 8
CONTENIDO
Resumen I
Acronimos V
1. INTRODUCCION 1
2. ESTADO DEL ARTE 3
2.1. Comunicacion Maquina a Maquina (M2M) .............................. 3
2.1.1. Principales Usos ....................................................... 3
2.1.2. Estado y Pronosticos del Mercado M2M ........................ 4
2.1.3. Aplicaciones Practicas ............................................... 4
2.1.4. Potenciales Dificultades en el futuro ............................. 4
2.1.5. Computacion Ubicua ................................................. 5
2.2. La red de comunicacion M2M ............................................... 5
2.3. Modulos GPRS Programables en Java. ................................... 6
2.4. Intermediarios de Comunicacion M2M .................................... 7
2.5. Conclusion del estado del arte ............................................... 9
3. ANALISIS DE REQUERIMIENTOS 10
3.1. Requerimientos de la Solucion............................................... 11
4. DISENO GENERAL DE LA SOLUCION 12
4.1. Arquitectura ..................................................................... 13
4.2. Descripcion de Componentes ................................................ 14
4.2.1. M2M Broker Server................................................... 14
4.2.2. Terminal Remoto (Gateway J2ME) .............................. 14
vi
Glossary vii
4.2.3. Terminal Administrador de Servicios (Gateway J2SE) ...... 15
4.3. Organizacion de lo Dispositivos ............................................. 15
4.3.1. Los Roles en los Servicios ........................................... 16
4.3.2. Relacion y asociacion entre equipos. ............................. 17
4.4. Conectores y Gateways........................................................ 17
4.5. Proceso General de Comunicacion.......................................... 18
5. M2M BROKER SERVER 19
5.1. Seguridad ......................................................................... 20
5.1.1. Autenticacion .......................................................... 20
5.1.2. Autorizacion ............................................................ 20
5.2. Mensajes .......................................................................... 21
5.2.1. Caracterısticas de los Mensajes .................................... 21
5.2.2. Persistencia de los Mensajes........................................ 22
5.2.3. Identificador de Mensajes ........................................... 23
5.2.4. Niveles de Notificacion ............................................... 23
5.2.5. Tipos de Mensajes .................................................... 23
5.3. Conectores ........................................................................ 24
5.3.1. Conector Gateway J2SE............................................. 25
5.3.2. Conector Gateway J2ME............................................ 25
5.4. Arquitectura Detallada ........................................................ 26
6. TERMINAL REMOTO 27
6.1. Librerıas del Sistema (Cinterion TC-65i) ................................. 28
6.1.1. Modulos.................................................................. 29
6.2. Gateway J2ME (IMP-NG GPRS) .......................................... 30
6.3. Aplicacion (Terminal Remoto) .............................................. 30
6.4. Arquitectura Detallada ........................................................ 31
7. TERMINAL ADMINISTRADOR DE SERVICIOS 32
7.1. Aplicacion ........................................................................ 33
7.2. Gateway J2SE ................................................................... 33
8. EJEMPLO DE USO 34
8.1. Diseno e Implementacion ..................................................... 35
8.2. Resultado ......................................................................... 37
Glossary viii
9. CONCLUSIONES 38
9.1. Cumplimiento de objetivos y requerimientos ............................ 39
9.2. Trabajo futuro ................................................................... 40
A. TECNOLOGIAS EMPLEADAS 43
A.1. Programacion de Dispositivos Moviles .................................... 44
A.1.1. Java en Dispositivos Moviles ....................................... 44
A.2. Seguridad ......................................................................... 45
A.3. Comunicacion y Transferencia de Informacion .......................... 45
A.3.1. Comunicacion Bloqueante (Java IO) ............................. 45
A.3.2. Comunicacion No Bloqueante (Java NIO) ...................... 46
A.4. Persistencia y Almacenamiento ............................................. 47
A.4.1. Postgres SQL........................................................... 47
A.4.2. Drivers Base de Datos y Pool de Conexiones .................. 47
A.4.3. Framework de Persistencia.......................................... 48
B. APLICACIONES PRACTICAS DE LA TECNOLOGıA M2M 49
C. DESARROLLO PARA DISPOSITIVO TC-65 52
C.1. Instalacion del SDK ............................................................ 52
C.2. Identificacion del Proveedor de Servicio................................... 54
C.3. Configuracion de la Red de Datos en Chile .............................. 54
C.4. Comandos AT (TC-65)........................................................ 55
C.5. Entorno de desarrollo .......................................................... 55
D. SERIALIZACION EN J2ME 57
D.1. Serializacion en J2ME ......................................................... 58
Referencias 64
INDICE DE FIGURAS
2.1. Cuadro resumen de tecnologıas de comunicacion inalambricas [1].. 6
2.2. Distintas soluciones usando modulos GPRS. ............................ 6
4.1. Arquitectura de ejemplo ...................................................... 13
4.2. Arquitectura de comunicacion entre dispositivos y el broker. ....... 14
4.3. Diagrama UML de organizaciones, servicios y dispositivos........... 15
4.4. Diagrama de ejemplo de Connectores y Gateways. .................... 17
5.1. Arquitectura del M2M Broker ............................................... 19
5.2. Estructura basica de los mensajes del M2M Broker ................... 22
5.3. Arquitectura Detallada del broker .......................................... 26
6.1. Arquitectura del Endpoint Field Device .................................. 27
6.2. Proceso para crear una aplicacion en J2ME ............................. 28
6.3. Diagrama de la comunicacion en el terminal remoto................... 30
6.4. Diagrama de la comunicacion en el terminal de campo. .............. 31
7.1. Arquitectura del Endpoint (Application Manager)..................... 32
8.1. Diagrama de Ejemplo.......................................................... 34
8.2. Grafico de temperatura ....................................................... 37
A.1. Arquitectura de Apache Mina ............................................... 47
C.1. Entorno de desarrollo .......................................................... 56
D.1. Proceso de serializacion ....................................................... 57
D.2. Diagrama de clases de serializacion en J2ME............................ 58
ix
INDICE DE TABLAS
2.1. Comparacion de modulos programables en Java [2] [3]................ 7
2.2. Comparacion de soluciones M2M ........................................... 8
3.1. Objetivos del proyecto. ........................................................ 10
3.2. Requerimientos funcionales. .................................................. 11
3.3. Requerimientos no funcionales............................................... 11
5.1. Tipos de autenticacion ........................................................ 20
5.2. Niveles de Notificacion ........................................................ 23
5.3. Tipos de Mensajes .............................................................. 24
6.1. Lista de Modulos para el Cinterion TC-65i .............................. 29
A.1. Comparacion de Frameworks para Java NIO [4] ........................ 46
C.1. Lista de MNC y MCC en Chile. ............................................ 54
C.2. Lista de APN en Chile. ....................................................... 54
C.3. Tabla resumen de comandos AT utilizados en el dispositivo TC-65. 55
x
Capıtulo 1
INTRODUCCION
Si una idea no es absurda al principio, entonces no merece la pena.
Albert Einstein
DESDE el siglo pasado escritores de ciencia ficcion han imaginado un mun-
do en el que dispositivos diminutos y con inteligencia serıan integrados en
nuestro entorno cotidiano. Es el caso de Mark Weiser quien describe un concepto
totalmente contrario al de realidad virtual; en vez de sumergir a las personas en
un mundo generado por ordenadores, fuerza a los ordenadores a salir al mundo
de las personas y adaptarse a sus actividades [5].
Son innumerables los dispositivos que pueden obtener datos de su entorno
y realizar acciones, pero existen circunstancias donde estos dispositivos se en-
cuentran en movimiento o en lugares de difıcil acceso, en dichos casos lo ideal es
contar con un sistema remoto para el control y la adquisicion de datos, haciendo
uso de las redes de comunicacion movil.
El auge de la comunicacion celular junto a la disminucion de los costos y
tamanos de los dispositivos de comunicacion han incentivado el mercado de la
comunicacion movil, factores que son aprovechados para comunicar variados
dispositivos electronicos con los sistemas de informacion, permitiendo la inter-
accion M2M 1 (Maquina a Maquina).
1Machine To Machine, mas informacion en la seccion 2.1
1
2
La comunicacion entre maquinas busca automatizar la lectura de datos y
acciones remotas, ademas de almacenar datos en todo momento, obteniendo
informacion valiosa en un menor tiempo [6].
En estas soluciones resulta importante la confiabilidad, la seguridad y la
estabilidad. Adicionalmente, las soluciones M2M deben estar preparadas para
futuras necesidades y disenadas desde un principio para crecer en complejidad
y numero de dispositivos.
El desarrollo de aplicaciones con modulos de comunicacion que usan redes
celulares trae consigo una serie de dificultades relacionadas con la comunicacion
e identificacion de los dispositivos, las que se ven acentuadas por la variedad de
usos que se le pueden dar a estos canales de comunicacion (lecturas automaticas
de medidores, tracking, seguridad, etc.) [7].
Teniendo en cuenta todos los factores resulta de gran importancia contar con
una plataforma que facilite el desarrollo de aplicaciones, y que sea transparente
a los detalles tecnicos (protocolos, almacenamiento, distribucion de mensajes y
comunicacion), permitiendo que el esfuerzo se enfoque en la aplicacion y no en
la comunicacion.
En este documento se presenta un acercamiento a las principales tecnologıas
involucradas y sus caracterısticas, para luego describir la solucion propuesta, sus
ventajas y desventajas comparada con soluciones similares. Se describe ademas
una implementacion basica, la cual consiste en un intermediario activo entre los
dispositivos que cuenten con comunicacion GPRS y los sistemas informaticos,
el cual recibira, almacenara, y distribuira los mensajes y eventos al dispositivo
que corresponda [8] [9] .
Capıtulo 2
ESTADO DEL ARTE
Nunca consideres el estudio como una obligacion sino como una oportunidad para
penetrar en el bello y maravilloso mundo del saber.
Albert Einstein
2.1. Comunicacion Maquina a Maquina (M2M)
M2M (Machine to Machine) se refiere a la comunicacion e intercambio de
informacion entre dos maquinas remotas, permitiendo automatizar procesos,
haciendolos eficientes [10] [11]. En el escenario actual existen un gran numero
de dispositivos y propositos, se plantean la necesidad de que las soluciones sean
modulares, de baja cohesion y enfocados a escenarios distribuidos [12].
s
Si bien M2M se usa tambien para referirse a soluciones de telemetrıa y
SCADA (Supervisory Control and Data Acquisition ), la principal diferencial
es que estas tecnologıas usan protocolos propietarios y cerrados, mientras que
M2M utiliza protocolos abiertos y con mayor flexibilidad, lo que le brinda un
mayor potencial para el desarollo de aplicaciones [13] [14].
2.1.1. Principales Usos
Monitoreo de maquinas y procesos industriales remotamente [15].
Domotica, seguridad de propiedades, medios transporte y personas [15].
Medicion de consumo de electricidad, gas y agua. [15] [6].
Aplicaciones medicas y control de salud remota e integral [16].
3
2.1 Comunicacion Maquina a Maquina (M2M) 4
2.1.2. Estado y Pronosticos del Mercado M2M
El mercado de M2M tiene mas de una decada con un crecimiento promedio
de 20 %, de acuerdo a las investigaciones de ABI Research [17], el mercado M2M
espera aumentar en mas de 85 millones de conexiones globalmente por el 2011,
y mas de 200 millones globalmente para el 2012, con un mercado total evaluado
en aproximadamente $57.000 millones de dolares para el 2014, el cual consta
tanto de dispositivos, desarrollo de soluciones y comunicacion movil [18] [19].
Fernando Fronza, director de desarrollo de productos de Telefonica Espana dice:
Aunque las aplicaciones son casi infinitas, los sectores que tienen mas
potencial de crecimiento a corto plazo son el de automative y el de los
medidores de consumo. [20].
Grandes empresas han invertido en M2M, entre las cuales destacan Verizon Wire-
less [21] [22] , Telefonica [23] [20], T-Mobile [24], Orange [25] y AT&T [26] [27] [28].
Por lo que se puede apreciar este es un mercado bastante atractivo, con unos
ingresos fiables y estables, aunque no tan cuantiosos como los derivados de las comu-
nicaciones personales [29].
2.1.3. Aplicaciones Practicas
La lista de aplicaciones practicas es larga, van desde el control de plagas hasta la
gestion y distribucion de la fuerza de trabajo. Para conocer detalladamente estas y
otras aplicaciones practicas ver el apendice B .
2.1.4. Potenciales Dificultades en el futuro
La proliferacion de dispositivos M2M y el resultante crecimiento en la inteligencia
compartida llevara a sistemas altamente complejos. Esto debe ser controlado por pro-
tocolos apropiados, interfaces y middleware, y tambien acompanado por herramientas
para gestionar el ciclo de vida de los dispositivos, como el de identificarlos y seguirlos
dentro de los sistemas de informacion [30] [31].
Ademas, la masificacion de los dispositivos con comunicacion plantea problemas
como la seguridad, confidencialidad, estabilidad, fiabilidad y calidad de servicio. En-
tre los principales desafıos podemos encontrar [7] [30]:
2.2 La red de comunicacion M2M 5
Procesamiento de los datos: El trafico global de Internet se cuadruplicara para
el ano 2015 [32], junto a nuevas restricciones, especialmente en procesamiento de tiem-
po real.
La administracion de Soluciones: Las soluciones deberan demostrar ser de
facil integracion con los sistemas heredados del cliente y de otros proveedores, con
miras a soportar el cambios de sus operaciones y logica en el futuro.
Mejores tecnologıas en los dispositivos: El objetivo es lograr mayores fre-
cuencias de comunicaciones inalambricas y a la vez reducir el consumo de energıa, lo
que permitira una mayor autonomıa de estos dispositivos.
Comunicacion entre Dispositivos: La asimetrıa de los flujos dentro de una
red de sensores inteligentes (WSN) sigue planteando problemas que todavıa no se han
logrado resolver, sumado a la ausencia de normas ha sido y sera uno de los mayores
impedimentos para que este tipo de tecnologıas se consoliden [30].
2.1.5. Computacion Ubicua
La computacion ubicua1 es la integracion de la informatica en el entorno de las
personas, logrando que los dispositivos se perciban como objetos cotidianos [33]. Se
ha fijado como objetivo colocar dispositivos inteligentes tanto en el entorno como en
aparatos de uso diario para que las personas puedan interactuar con ellos de una
manera natural y desinhibida. La finalidad es clara, poder dar inteligencia a nuestro
entorno.
2.2. La red de comunicacion M2M
La tecnologıas M2M han aprovechado los avances de la comunicacion inalambrica,
la cual ha mejorado en cobertura y caracterısticas, ademas se cuenta con variadas
opciones de acuerdo a los requerimientos de capacidad de transferencia y movilidad
(Ver Figura 2.1) [1].
1Otros terminos para ubicuidad son: pervasive computing, calm technology, things that
think, inteligencia ambiental y everyware. Mark Weiser es considerado el autor del concepto.
2.3 Modulos GPRS Programables en Java. 6
HSPA
0.1 1 10 100Tasa de
Transferencia
GS
M
GP
RS
DECT
Bluetooth
Mobilidad
Evolución 3G aLargo Plazo
WiMAX
WiFi
UMTS
EDGE
Alta Velocidad
Vehicular(Rural)
Vehicular(Urbano)
Peatonal
Nómada
Fijo Urbano
Interiores
Área Personal
Figura 2.1. Cuadro resumen de tecnologıas de comunicacion inalambricas [1].
Las comunicaciones inalambricas puede ser incluso globales, de ahı viene el sig-
nificado de GSM (Global System for Mobile Communication) que permite la comuni-
cacion de voz, datos y SMS alrededor del mundo. Ademas los proveedores entregan
acceso a internet a traves de la red celular [34], permitiendo que estos dispositivos
puedan comunicarse con servidores en todo el mundo.
2.3. Modulos GPRS Programables en Java.
Todo equipo que requiera interactuar con otros, debe contar con un dispositivo que
le permita acceder a una determinada red de comunicacion, para las redes celulares
se pueden usar los modems GPRS. La desventaja de ese tipo de solucion es que la
unidad central de procesamiento debe implementar todas las instrucciones necesarias
para utilizar el modem y el tamano y costo del producto final se eleva. Con el tiempo
esto se volvio un requerimiento bastante usual, y ahora los nuevos modulos unen un
modem celular y una unidad de procesamiento programable en un unico dispositivo,
disminuyendo el costo, el tamano y el tiempo de desarrollo (ver figura 2.2). Los
modulos GPRS programables mas usados son:
ROM RAMROMRAM
Aplicación Aplicación
Módulo GSM con Java
Módulo GSM
Unidad de Procesamiento
Solución Común Nueva Solución
Figura 2.2. Distintas soluciones usando modulos GPRS.
2.4 Intermediarios de Comunicacion M2M 7
Cinterion TC-65i: Fue uno de los primeros dispositivos con la capacidad de
integrar un modem GPRS y un procesador programable en Java [35]. Este ha sido
disenado para ser de bajo costo y con un entorno de desarrollo simple [36]. Las ven-
tajas son la difusion y la documentacion.
Motorola G24 Java: Desarrollado por Motorola. Incluye mensajerıa, conex-
iones seguras a internet y soporte a MQTT [37] M2M protocol [2] (Ver tabla 2.1). Las
ventajas son la capacidad de almacenamiento de 10[MB] y la posibilidad de conec-
tarlo a un modulo GPS desarrollado por Motorola. Las debilidades son el precio (84
USD [38]) y la falta de documentacion. La lınea Motoroloa M2M fue adquirida por
Telit en marzo del 2011 [39], no se conoce con claridad si seguira dando soporte al
G24-j.
Modulo CPU ROM RAM IO ADC I2C SPI UART
TC-65i Arm9 1.7[MB] 400[KB] 10 2 X X XG24-J Arm7 10[MB] 1.8[MB] 15 1 X - X
Tabla 2.1. Comparacion de modulos programables en Java [2] [3].
2.4. Intermediarios de Comunicacion M2M
Los intermediarios de comunicacion para dispositivos M2M, tienen como principal
objetivo disminuir el TTM(Time To Market) o tiempo que toma en lanzar nuevos
productos y servicios al mercado.
Estas soluciones se encargan de comunicar los dispositivos moviles con los sis-
temas de informacion de las empresas, ya que los dispositivos moviles no cuentan con
un sistema robusto para soportar una gran cantidad de conexiones entrantes; suman-
do razones de seguridad y estabilidad, estos deben establecer el enlace a un servidor.
Entre las principales soluciones encontramos la siguientes (ver tabla 2.2):
Enfora Service Gateway 2.0 - eWiDE: Enfora es una empresa que desar-
rolla un modem, con soporte a nivel mundial, que cuenta con el servicio eWide, para
comunicarse con los dispositivos Enfora. Esta permite una implementacion rapida, ya
que la comunicacion con los sistemas de informacion esta basada en JDBC y por el
lado de los modulos, solo es necesario configurarlos. [40].
2.4 Intermediarios de Comunicacion M2M 8
BiTX: m2m data eXchange: Bajo el principio de evitar hacer todo desde cero,
BiTX ha desarrollado una solucion de puerta de enlace junto a un protocolo abierto
de mensajes XML denominado BiTXml para facilitar el desarrollo de aplicaciones
multiproposito [41]. Esta solucion se orienta a los dispositivos y sensores que pueda
tener el modulo y como poder controlarlos remotamente.
OpenGate 4: OpenGate ha sido disenada sobre una arquitectura distribuida
punto a punto que ayuda a simplificar el desarrollo de soluciones inalambricas basadas
en GPRS, la cual cuenta con 3 componentes: Cliente, el cual corresponde al disposi-
tivo movil, la Plataforma Opengate, la que se encarga de encaminar los mensajes de
forma segura y fiable, y la Aplicacion, donde la informacion es integrada a los sistema
de la empresa [42]. Es la solucion mas completa, contando con soporte para Java,
C++ y .NET.(ver tabla 2.2) [43].
WS4D Web Services for Devices - PipesBox: Proyecto actualmente en
desarrollo por el grupo WS4D de Universidad de Rostock, esta herramienta busca
combinar dispositivos y servicios de forma facil, permitiendole a usuarios no tecni-
cos crear soluciones. Puede integrarse con DPWS, UPnP, Bluetooth, Zigbee entre
otras. [44]
En la tabla 2.2 se puede apreciar un resumen comparativo de las distintas solu-
ciones intermediarias de comunicacion M2M.
Caracterıstica OpenGate eWiDE PipesBox BiTX
Soporte Europa Mundial Alemania Europa
Mensajes XML - - SOAP BiTXml
Mensajes Binarios XDR UDP Packet - -
SMS X - - XAPI Java, y C++ UDP API Java y C++ Java y C++
Panel Web X X X X
Tabla 2.2. Comparacion de soluciones M2M
2.5 Conclusion del estado del arte 9
2.5. Conclusion del estado del arte
Se puede apreciar que la comunicacion M2M, tiene grandes ambiciones y requer-
imientos que cumplir, pero la motivacion de un mercado en crecimiento y con buenas
ganancias resulta ser una apuesta con importantes beneficios si se cuenta con una
solucion confiable, estable, flexible y con una buena adaptacion a los sistemas de in-
formacion de los clientes.
El futuro es promisorio si a lo anterior se le suma la disminucion en los costos de
los dispositivos, y la mayor cobertura de las redes de celulares, ademas la mayorıa
de las aplicaciones M2M pueden correr perfectamente en 2G, aunque sean una gran
cantidad de conexiones, el uso de ancho de banda y costos es mınimo comparado al
de llamadas telefonicas [45]. Las funcionalidades de los dispositivos son variadas, por
lo cual es necesario dar flexibilidad a las aplicaciones finales dependiendo el uso que
se les dara.
Se trabajara con el modulo Cinterion TC-65i ya que se cuenta con los dispositivos
y el hardware necesario [46]; ademas cabe mencionar que Cinterion es una de las em-
presas mas destacadas en el desarrollo de modulos de comunicacion celular [47]. Otros
factores importantes son la capacidad de procesamiento (ARM9) y la capacidad de
comunicacion SPI, sin embargo el modulo G-24 Java de Motorola cuenta con 10[MB]
de almacenamiento, resultando idoneo para escenarios de captura de datos cuando se
pierde la comunicacion.
Respecto a los distintos intermediarios de comunicacion M2M, el principal argu-
mento a realizar una solucion propia, es el hecho que solo Enfora cuenta con soporte
en America Latina, pero es la plataforma con menos flexibilidad y esta restringida
a una marca de modems. Un aspecto importante es que todas esas empresas estan
enfocadas a grandes clientes o estan en desarrollo.
Finalmente la solucion sera programada en Java basandose en los aspectos basicos
que tiene las distintas soluciones, pero tambien con capacidad de incluir otras carac-
terısticas segun se vayan requiriendo a futuro.
Capıtulo 3
ANALISIS DE
REQUERIMIENTOS
Cualquier persona, en mar o en tierra, con un aparato sencillo y barato que cabe en
un bolsillo, podrıa recibir noticias de cualquier parte del mundo o mensajes
particulares destinados solo al portador, la Tierra se asemejarıa, pues, a un
inconmensurable cerebro, capaz de emitir una respuesta desde cualquier punto.
Nikola Tesla
Al desarrollar un producto nuevo es necesario determinar los requerimientos y
caracterısticas que debera tener, basandose en las experiencias anteriores, productos
similares y sugerencias realizadas por clientes y desarrolladores. La tabla 3.1 muestra
los principales objetivos.
ID Historia
O1 Aumentar la capacidad de dispositivos conectados
O2 Persistencia de datos en el intermediario
O3 Posibilidad de que sea usada por empresas sin IP estatica
O4 Evitar uso de una unidad de procesamiento complementaria
O5 Relacionar el software y hardware de forma modular
Tabla 3.1. Objetivos del proyecto.
10
3.1 Requerimientos de la Solucion 11
3.1. Requerimientos de la Solucion
Los requerimientos pueden ser tanto una condicion o necesidad de un usuario para
resolver un problema o alcanzar un objetivo, como una condicion o capacidad que
debe estar presente en un sistema o componentes de sistema. Los requerimientos se
dividen en requerimientos funcionales y no funcionales.
Requerimientos Funcionales
Definen las funciones que el sistema sera capaz de realizar, para cumplir con
su objetivo, en este caso un intermediario activo de mensajes, entre dispositivos de
comunicacion movil y sistemas de informacion.
ID Requerimiento
F1 Comunicacion con los dispositivos moviles
F2 Comunicacion con los sistemas de informacion
F3 Almacenar y distribuir mensajes entre dispositivos
F5 Control del estado de los dispositivos conectados
Tabla 3.2. Requerimientos funcionales.
Requerimientos No Funcionales
Los requerimientos no funcionales tienen que ver con el rendimiento, usabilidad y
seguridad entre otras. Los atributos del sistema son cualidades no funcionales que a
menudo se confunden con las funciones, por ejemplo: facilidad de uso y tolerancia a
fallas [48].
ID Requerimiento
NF1 Estable y robusto
NF2 Tolerancia a fallas de comunicacion
NF3 Diseno escalable y portable
Tabla 3.3. Requerimientos no funcionales.
Capıtulo 4
DISENO GENERAL DE LA
SOLUCION
Por supuesto todos tenemos nuestros lımites, pero
¿como puede usted descubrir posiblemente sus lımites a no ser que
explore tan lejos y tan ampliamente como posiblemente pueda?
A. E. Hotchner
Desde sus inicios, la computacion distribuida requirio una forma distinta de desar-
rollar el software, lo que llevo a la creacion de distintos patrones de diseno, entre los
que destacan Spoke-Broker [49], Peer-To-Peer, Publisher-Subscriber [50] y Proxy [51],
y en muchas casos se volvio una necesidad contar con un intermediario activo y un
respectivo middleware [31] para la comunicacion. Los estandares Java Message Ser-
vice(JMS) y WebService(WS) son muy populares, ya que estos facilitan el desarrollo
y la interoperabilidad, pero agregan una carga importante a los recursos tanto de
hardware como de la comunicacion.
El patron Spoke-Broker resulta ser el mas apropiado para cumplir con los requer-
imientos, ya que permite desacoplar el emisor del receptor usando un mediador
activo, al cual se le puede denominar hub o broker [52], responsable de coordinar la
comunicacion, retransmitiendo solicitudes, resultados y excepciones. El hecho de que
todo los mensajes viajen a traves de un componente central es ideal para la seguridad,
y el control de dispositivos y mensajes. [53] [54].
Una desventaja es que el hub se puede convertir en el cuello de botella y el talon de
Aquiles en cuanto a seguridad, para mitigar ese riesgo se puede realizar distribucion
de carga y usar tecnicas de encriptacion . En ese caso de usar multiples instancias el
hub es centralizado al momento de disenar pero distribuido al momento de ejecutar.
12
4.1 Arquitectura 13
4.1. Arquitectura
La solucion propuesta consiste en un broker y respectivos gateways [53] que per-
miten resolver los problemas de escalabilidad y diversidad de aplicaciones, sin en-
frentarse a las dificultades de la comunicacion entre dispositivos [9].
Los gateways consisten en middlewares que abstraen la complejidad de la comuni-
cacion con el broker mediante una API(Application Programming Interface) [55], con
el cual se tiene acceso a funciones para intercambiar mensajes con los otros dispositi-
vos. El broker se encarga de autentificar, determinar privilegios, almacenar y distribuir
los mensajes a los dispositivos que corresponda. Determinando que dispositivo va a
consumir los mensajes, solo es necesario conocer los datos del intermediario [56].
Esta arquitectura permite que el Broker sea utilizado por dispositivios con acceso
a internet y que pueda ser programado, como los nuevos televisores, computadores,
celulares, tablets y en sistemas embebidos. La funcion de cada dispositivo depen-
dera de su rol dentro de cada servicio, y no de sus caracterıstica.
En la figura 4.1 se puede apreciar una arquitectura de ejemplo, donde los dispositi-
vos moviles, de ahora en adelante los Terminal Remotos, y los sistema informatico de
la empresa, de ahora en adelante los Terminal Administradores de Servicios utilizan
los Gateway J2ME y J2SE respectivamente para comunicarse a traves del Servidor
M2M Broker.
Servidor M2M Broker
Servicio Central Broker
ConectorJ2ME
ConectorJ2SE
GPRSGateway J2ME
Aplicación de Seguimiento
VIDAware
Gateway J2ME
Aplicación de Telemedida
Gateway J2ME
Aplicación deSalud Remota
GPRS
GPRS
Aplicación de Seguimiento
Gateway J2SE
Gateway J2SE
Aplicación deSalud Remota
Gateway J2SE
Terminales Remotos
Terminales Administradores de Servicios
105.1khw
Aplicación de Telemedida
Figura 4.1. Arquitectura de ejemplo
4.2 Descripcion de Componentes 14
En la figura 4.1 se muestra la arquitectura y una serie de ejemplos de uso, y en
la figura 4.2 se puede apreciar la arquitectura generica, que es aplicable a cualquier
tipo de uso, esta arquitectura contempla tres componentes, que se explicaran en la
siguiente seccion.
Gateway J2MEAplicación
Terminal AdministradorServidor M2M BrokerAplicaciónGateway J2SE
Servicio M2M Broker
Terminal Remoto
ConectorJ2ME
ConectorJ2SE
Figura 4.2. Arquitectura de comunicacion entre dispositivos y el broker.
4.2. Descripcion de Componentes
4.2.1. M2M Broker Server
Es el servicio que debera sostener los canales de comunicacion entre los clientes y
los usuarios, monitorear el estado de los dispositivos moviles, ademas de almacenar
los mensajes y acceder a la lista de dispositivos que forman parte de cada aplicacion.
Entre las funciones detacan:
• Permitir comunicacion entre las terminales o endpoints.
• Identificar y mantener un registro de estado de los equipos.
• Notificar eventos de comunicacion.
• Conector para las terminales(J2ME y J2SE) .
• Cola de mensajes persistente.
4.2.2. Terminal Remoto (Gateway J2ME)
El terminal remoto consta de un pequeno dispositivo o modulo de comunicacion
el cual viene integrado con un microprocesador. Si bien estos dispositivos pueden ser
programados en C++, C], Java, J2ME o Python, solo se trabajara desarrollando la
API o Gateway para J2ME , especıficamente para el modulo Cinterion TC-65i.
4.3 Organizacion de lo Dispositivos 15
La funcionalidad de este dispositivo es la de comunicarse con la puerta de enlace
y mantener una comunicacion confiable y segura. Al ser un dispositivo con recursos
limitados requiere de un protocolo simple. Y sus principales funciones son:
• Programado usando J2ME.
• Comunicacion TCP al M2M Broker usando GPRS.
• Identificacion usando IMEI y una firma digital de la aplicacion.
• Notificar eventos de comunicacion.
4.2.3. Terminal Administrador de Servicios (Gateway J2SE)
Este terminal Administrador ejecutara el servicio que se integrara al sistema in-
formatico de la organizacion, el cual se comunicara con el broker usando el Gateway
J2SE. El listado de funciones a continuacion:
• Comunicacion TCP usando NIO con la puerta de enlace.
• Encolar mensajes en una base de datos local en caso de estar desconectado.
• Poder revisar el registro de mensajes intercambiados.
• Reconexion automatica al desconectarse.
4.3. Organizacion de lo Dispositivos
Para organizar los dispositivos y sus entornos de trabajo, se ha determinado un
modelo que agrupa equipos dentro de organizaciones, servicios e instancias. En la
figura4.3 se encuentra representa la relacion.
1:N Organización
Servicio Instancia
Dispositivo
1:N
1:N
Suscripción
1:N
1:N
Figura 4.3. Diagrama UML de organizaciones, servicios y dispositivos.
4.3 Organizacion de lo Dispositivos 16
Organizaciones
Las organizaciones son las entidades que representan las empresas, se debera crear
una nueva para cada empresa. La idea es que todo dispositivo este restringido a
comunicarse solo con los dispositivos de esa organizacion.
Servicios
Cada servicio tiene un identificador unico dentro del broker, el que es utilizado al
desarrollar el software de los dispositivos. De esa forma cada dispositivo sabe como
interactuar con sus servicios, la idea principal es que un servicio X funcionando en la
organizacion I funcione de la misma forma que en la organizacion II.
Instancias
Cada vez que un servicio es configurado para funcionar dentro de una organizacion
se crea una nueva instancia en el Broker.
4.3.1. Los Roles en los Servicios
Un aspecto importante es que los dispositivos no tiene un unico rol asignado, sino
que por cada servicio al que esta suscrito tiene un rol. Esto permite una Arquitectura
Orientada a Servicios (SOA), brindado gran flexibilidad a la momento de desarrollar
soluciones innovadoras . De todas formas para seguir con la misma taxonomıa, se
explicaran los roles mas usados y sus funciones, suponiendo que cada dispositivo
tiene el mismo rol para todos sus servicios asignados.
Terminal Administrador (Manager)
Dispositivos responsables de solicitar datos y acciones a los dispositivos que estan
en terreno . Generalmente correspondera a servidores con buena capacidad de proce-
samiento, almacenamiento y comunicacion.
Terminal Remoto (Remote)
Rol de todos los dispositivos con capacidades reducidas, generalmente seran ac-
tuadores o sensores, con capacidades mınimas de almacenamiento y procesamiento.
Ademas pueden ser integrados a maquinas que tengan la capacidad de comunicarse
usando puerto serial, SPI, I2C y GPIOs, estas maquinas pueden ser medidores de
consumo o signos vitales, vehıculos o equipos industriales en general.
4.4 Conectores y Gateways 17
4.3.2. Relacion y asociacion entre equipos.
Cada organizacion funciona aislada de las otras, y un equipo solo puede pertenecer
a una y comunicarse solo con los de esa organizacion. Cada aplicacion solo esta re-
stringida a los servicios y roles asignados, lo que facilita que una solucion sea desar-
rollada y usada sin mayores cambios de software en varias organizaciones.
Por ejemplo los dispositivos con TC-65i seran programados para usar un servicio
de monitoreo Y , por otro lado la organizacion I tiene los servicios de tracking(X) y
la organizacion II los servicios de telemetrıa(W ), sin embargo ambas pueden utilizar
el servicio de monitoreo Y de sus respectivas organizaciones.
4.4. Conectores y Gateways
La dupla conector-gateway, son la solucion propuesta para la comunicacion en-
tre dispositivos heterogeneos sin desaprovechar las caracterısticas de cada uno. Es
ası como cada conector busca aprovechar las mejores prestaciones que tienen cada
tipo de dispositivos. Por ejemplo los computadores cuentan con buenos recursos tan-
tos de procesamiento como de transmision, en cambio los dispositivos moviles tienes
importantes restricciones de memoria y de transmision.
Ademas permite crear otros conectores a futuro, por ejemplo conectores para SMS,
WS, REST, JMS y UDP entre otros. El unico requerimiento es que los conectores
respeten las especificaciones para hacer uso del servicio central del broker. En la figura
4.4 se aprecia la interaccion entre conector, gateway y broker.
Gateway AAplicación Conector AServicioCentral
delBroker
Gateway BAplicación Conector B
Terminal X
Terminal Y M2M BrokerInternet
Figura 4.4. Diagrama de ejemplo de Connectores y Gateways.
4.5 Proceso General de Comunicacion 18
Al ejecutarse el broker, iniciara automaticamente todos los modulos activos que
implementen la interfaz de conector. A futuro lo ideal serıa contar con un broker en
OSGi para poder agregar o eliminar conectores sobre la marcha, sin necesidad de
reiniciar el broker.
4.5. Proceso General de Comunicacion
El proceso mediante el cual el dispositivo se conecta al broker para interactuar con
otros dispositivos, resulta bastante complejo si se explica cada detalle, a continuacion
se explica la interaccion de forma general.
1. El terminal se conecta a un conector de broker usando el gateway respec-
tivo.
2. El terminal inicia la comunicacion con los datos de identificacion.
3. Si la identificacion es correcta, el broker le envıa su identificador unico y la
organizacion a la cual pertenece. De lo contrario se generara una excepcion y
es desconectado.
4. El terminal envıa la lista de servicios que requiere para su funcionamiento.
5. El broker le informa al terminal la lista de servicios asociados.
6. Para cada servicio autorizado, el dispositivo inicia el respectivo controlador.
7. Al iniciarse el servicio, este le informa al broker que ya puede recibir mensajes
provenientes de este.
8. El broker actualiza el estado de la terminal dentro del broker y le envıa el
numero de mensajes pendientes de cada servicio, dicha senal le llegara a los
controladores de cada servicio y esta sera responsable de determinar la accion.
9. Cada servicio puede solicitar transferencia de mensajes pendientes.
Capıtulo 5
M2M BROKER SERVER
Si supiese que es lo que estoy haciendo, no lo llamarıa investigacion.
Albert Einstein
Al implementar el broker, se han tomado una serie de decisiones en el diseno y
arquitectura, buscando tener un servicio modular, flexible, de bajo consumo de re-
cursos y que pueda soportar sobre mil equipos concurrentes.
En este capıtulo se detallara cada componente y como ha sido implementado a
grandes rasgos, de esta forma el lector conocera la informacion tecnica, pero sin entrar
en los detalles de implementacion.
Servicio Central M2M Broker Persistencia Conectores
Conector J2ME
Conector J2SE
Encriptación
Seguridad Dispositivos
Mensajes Sesiones
Figura 5.1. Arquitectura del M2M Broker
En la figura 5.1 se puede apreciar los principales modulos que forman parte del
broker, entre las que destacan persistencia, encriptacion, conectores, seguridad y ad-
ministrador de mensajes, dispositivos y sesiones. La arquitectura con los detalles de
cada modulo se encuentra representada la figura 5.3.
19
5.1 Seguridad 20
5.1. Seguridad
En toda plataforma informatica la seguridad de los datos es una parte importante
y crıtica para obtener la confianza de los usuarios. Aunque este sistema puede ser usa-
do para transmitir datos confidenciales, la razon prioritaria para contar con seguridad
es que se pueden realizar acciones sobre dispositivos con diversas funcionalidades, por
ejemplo una valvula o interruptores.
La seguridad tiene varias aristas como son la autenticacion, la autorizacion y la
encriptacion. Cada una abarca distintas partes de la seguridad desde la proteccion de
los datos hasta el acceso a informacion restringida.
5.1.1. Autenticacion
La autenticacion o autentificacion, es el proceso en el que se determina que el
usuario o dispositivo es quien dice ser, generalmente se usa un identificador y una
llave, de esa forma el usuario le hace saber al sistema que tiene las credenciales nece-
sarias para hacer uso de su identidad dentro del sistema. Al ser autorizado se le
notifica su identificador unico dentro del broker.
Se ha decidido normalizar este proceso a traves de la combinacion unica de tipo,
id y key, de esa forma a futuro se pueden agregar distintos tipos de identificacion
(ver tabla 5.1).
tipo id key
imei IMEI del Dispositivo IMSI de la SIM
ip Direccion IP Hash(MAC)
login Usuario Password
Tabla 5.1. Tipos de autenticacion
5.1.2. Autorizacion
La autorizacion consiste en determinar que privilegios tiene cada usuario, en-
tiendase privilegios como los permisos para acceder a informaciones o realizar ac-
ciones determinadas. Para la seguridad del sistema se utilizo el framework Apache
Shiro, que facilita los procesos de autenticacion y autorizacion (ver Apendice A.2).
5.2 Mensajes 21
Apache Shiro permite determinar por ejemplo: El usuario X puede realizar accion
Y. Esto se ha simplificado teniendo la dualidad de poder asegurar la autorizacion ba-
sada en Roles y Permisos. Los permisos son generalmente asociados a una accion
determinada, en cambio a un rol se le asigna un conjunto de permisos.
Por ejemplo el permiso y rol para enviar mensajes a todos los dispositivos de la
aplicacion se pueden llamar send broadcast app y app manager respectivamente,
permitiendo que los dispositivos con el rol app manager puedan enviar mensajes ma-
sivos a todos los dispositivos dentro de una aplicacion. Si fuera necesario agregar o
eliminar un permiso a todos dispositivos con el rol app manager, solo debera cam-
biarse la configuracion de permisos asociados a dicho rol.
Los permisos son los que estan directamente vinculados a la aplicacion, al software
y a los roles son un conjuntos de permisos que pueden ir cambiando en el tiempo,
incluso se pueden crear nuevos roles, sin necesidad de modificar el programa.
5.2. Mensajes
Una caracterıstica importante a determinar en un Middleware Orientado a Men-
sajes (MOM) es la composicion y complejidad de los mensajes, fundamentalmente
por que estas determinaran las restricciones del protocolo de comunicacion.
Al disenar un protocolo de comunicacion se busca la simplicidad, ya que el proceso
para encontrar errores y fallas se vuelve mas complicado en los sistemas distribuidos.
Aumentar la complejidad de los mensajes se verıa reflejado en un protocolo mucho
mas difıcil de implementar, evaluar y mantener.
5.2.1. Caracterısticas de los Mensajes
Largo de los Mensajes
Al determinar el largo de los mensajes resulta importante la Unidad Maxima de
Transferencia (MTU) que determina el conjunto de bytes que puede enviarse a traves
de internet, eso no impide que se puedan enviar datos mayores sino que ek nebsahe
serpa fragmentado en datagramas del tamano del MTU.
5.2 Mensajes 22
En general los MTU mas utilizados rodean los 1500 bytes, dado que la mayorıa
de maquinas estan conectadas a redes Ethernet o derivados, aunque por defecto el
tamano de datagrama IP es de 576 bytes. Dando prioridad a la compatibilidad, se ha
determinado que el tamano maximo del contenido o payload sera de 500 Bytes.
Estructura de los Mensajes
A grandes rasgos un mensaje tıpico esta formado por una cabecera o header y un
payload o contenido, como se aprecia en la Figura 5.2, aunque algunos contenidos de
la cabecera pueden variar de acuerdo al tipo de mensaje.
Cabecera
Identificador
Mensaje del M2M Broker
Contenido
Datos SerializadosArreglo de Bytes
Destino
Origen Tipo de Persistencia Tipo de Mensaje
Tipo de DestinoMarca de Tiempo Tamaño de Contenido
Figura 5.2. Estructura basica de los mensajes del M2M Broker
La cabecera contiene datos referente al tipo de mensaje, tipo de persistencia, nivel
de notificacion, identificador de mensaje, destino, origen, etc.
La carga o contenido esta formado por un arreglo de byte, que puede ser un objeto
serializable o un arreglo de unidades de datos basicos dependiendo de la aplicacion
(el broker no necesita saber cual es el contenido).
Serializacion de mensajes en J2ME
A diferencia de J2SE, J2ME no soporta serializacion y ademas tiene restricciones
en el tipo de datos que soporta, teniendo en cuenta eso, se usaran los tipos de datos
basicos que esa plataforma pueda soportar. El apendice D explica el proceso [57].
5.2.2. Persistencia de los Mensajes
Mensaje Persistente
Se mantiene hasta que sea recibido por el destino. El mensaje se mantiene en el
broker hasta que haya sido procesado correctamente por los destinatarios, luego es
eliminado.
5.2 Mensajes 23
Mensaje Transitorio
Se pierde en caso del que el destino este desconectado. El broker intentara en-
viarle el mensaje una cantidad de veces y esperara un tiempo determinado, de no ser
entregado este se dara por descartado.
5.2.3. Identificador de Mensajes
Algunos mensajes requieren de un identificador de mensaje, para confirmar recep-
cion, este puede ser generado por gateway o el broker. El gateway se preocupara de
decidir y llevar a cabo dicha identificacion. Cuando el dispositivo de destino esta
desconectado, el broker generara un identificador al persistir el mensaje en la base
de datos, de esa forma la aplicacion podra consultar por estado de dicho mensaje
posteriormente.
5.2.4. Niveles de Notificacion
El nivel de notificacion es un parametro del mensaje para solicitar que se avise si
el mensaje ha llegado correctamente hasta un determinado punto, de esta forma el
dispositivo que esta enviando un mensaje sera notificado si el mensaje arribo correc-
tamente al destino.
Nivel Notifica
none Nunca.
broker-in Arribo al broker.
broker-out Despacha al destino.
destination-in Arribo al destino.
Tabla 5.2. Niveles de Notificacion
5.2.5. Tipos de Mensajes
Son un conjunto de mensajes con el proposito de que al ser recepcionados en
el broker estos puedan ser descifrados por el decodificador de protocolo (Protocol
Decoder) respectivo, de esa forma a la logica de negocio le llegara un objeto con el
mensaje listo para procesar.
5.3 Conectores 24
Mensaje Descripcion
COMMAND Mensajes de interaccion y senalizacion entre el broker y los
gateways, usados para ingresar, enviar senales y desconec-
tarse del broker.
EXCEPTION Todo dispositivo puede responder con alguna excepcion
ante algun mensaje incorrecto, o en situaciones donde la
accion a realizar no se lleva a cabo con exito.
HEARTBEAT Senal para determinar si el dispositivo se encuentra conec-
tado, determina si la conexion establecida funciona correc-
tamente.
REQUEST y
REPLY
Para intercambio secuencial de mensajes, request para so-
licitar y reply para responder. Esta paridad es util en las
aplicaciones donde el orden de los mensajes es importante.
EVENT Son mensajes para notificar un evento que no requiere una
respuesta inmediata, por ejemplo notificar que se abrio una
puerta o que se esta llegando al umbral maximo de alguna
variable.
REGISTRY Mensaje para entregar informacion agrupada a un destino.
Por lo tanto son mensajes periodicos, donde se privilegia la
integridad de la informacion al tiempo de transmision.
Tabla 5.3. Tipos de Mensajes
5.3. Conectores
Los conectores son esenciales para trabajar con dispositivos heterogeneos y obten-
er lo mejor de cada medio de transmision; en la implementacion de estos es donde el
desarrollo modular resulta fundamental.
Los conectores son modulos que implementan la interfaz Connector.java para co-
municarse de la misma forma con el servicio central de broker, pero cada uno puede
realizar sus operaciones de distinta forma. Para la aplicacion que es ejecutada en los
dispositivos, la comunicacion es independiente al tipo de conector.
5.3 Conectores 25
Esto se logra usando las capacidades del Service Provider Interface (SPI) de
Google Guice1 y reflexion de java; el administrador de conectores buscara todas las
clases que instancien la interfaz de conector, y ejecutara los metodos para iniciar ca-
da uno de estos conectores ademas de iniciar los respectivos controladores o listeners
para que dichos conectores puedan enviar senales al administrador. Por lo tanto los
conectores activos dependeran de la configuracion de modulos del Google Guice.
5.3.1. Conector Gateway J2SE
Este conector esta disenado para ser usado en los servidores de la empresa, com-
putadores con buena capacidad de procesamiento y comunicacion, se le denomina
J2SE, ya que Java NIO requiere de esa version de java.
El gateway y el conector usaran un protocolo de objetos serializados, eso implica
que los objetos seran serializados y enviados en formato de bytes a traves de internet,
para luego ser deserializados en el destino. Esto permite un desarrollo rapido del
protocolo, ya que no requiere una especificacion detallada de los mensajes, y permite
un trabajo bastante limpio utilizando una interfaz conocida por ambas partes. La
unica desventaja, es el incremento en el tamano de los mensajes.
5.3.2. Conector Gateway J2ME
En los dispositivos de menor capacidad de procesamiento y comunicacion, como
celulares o sistemas embebidos. Una restriccion es el monto de transferencia mensual
que disponen este tipo de equipos, por lo que es necesario utilizar la menor cantidad
de bytes en senalizacion y cabecera.
En el conector y gateway para J2ME se utilizara una lista de datos encolados; de
acuerdo al tipo de mensajes se colocaran los datos en un determinado orden, y en el
lado de recepcion dicho mensaje debera ser leıdo en ese mismo orden para armar el
mensaje correctamente.
Ademas de seguir un orden, es necesario determinar el tipo de dato y sus carac-
terısticas, por ejemplo asignar un codigo para cada tipo de datos, de esta forma al ir
leyendo el arreglo de bytes, y de acuerdo al tipo de datos, se van definiendo los valores
de todos los datos que forman dicho objeto [57]. Mas informacion en el apendice D.
1http://code.google.com/p/google-guice/wiki/InspectingModules
5.4 Arquitectura Detallada 26
5.4. Arquitectura Detallada
Para finalizar este capıtulo, la figura 5.3 representa todos los modulos, pudiendose
apreciar detalles de la implementacion, distribucion de los datos relacionados con la
sesion y el uso de cache de los distintos modulos.
PersistenciaBroker DAOs
MyBattis DB Mappers
Pool de Conexiones a Base de Datos ( Apache DBCP )
Cache Manager
ehCache.xml
RDBMS Postgres SQL 9.0
Device Dao Message Dao Service Dao
Conectores
Servicio Central del M2M Broker
TCP J2SE Connector
TCP J2SE IoHandler
Security
AuthenticatorAuthentication
Strategy
Device Manager
Message Manager
Registry Manager
Authorizer
Auth Tokens IMEI
SessionManager
Session DAOLogin IP Custom
cache
MessageRouter
Message ManagerMessage
Persistence
cache
cache
subject
broker
ObjectSerializationCodecFactory
subject
subject
TCP J2ME Connector
TPC J2SE IoHandler subject
J2MESerializationCodecFactory
Custom Connector
Custom IoHandler subject
CustomCodec
Figura 5.3. Arquitectura Detallada del broker
Capıtulo 6
TERMINAL REMOTO
La diferencia entre lo que hacemos y somos capaces de hacer,
resolverıa la mayorıa de los problemas del mundo .
Mahatmas Gandhi
Los terminales remotos, generalmente son dispositivo heterogeneos que cuenta
con recursos de procesamiento y comunicacion limitados, pero cuenta con el hard-
ware necesario para realizar acciones y obtener senales desde sensores.
Este tipo de terminal esta compuesto por los modulos de la figura 6.1. Las librerıas
del Sistema, que en este caso tiene las especificaciones para trabajar con todo el
hardware del dispositivo. El Gateway J2ME (IMP-NG GPRS) que permite establecer
la comunicacion al broker utilizando GPRS y los comandos GSM, este modulo ha sido
desarrollado para J2ME pero adaptada para soportar las especificaciones de cada
dispositivo. Y finalmente la Aplicacion que tendra la logica de funcionamiento del
dispositivo.
Aplicación
Librerías del SistemaCinterion TC-65
Gateway J2ME
Terminal Remota
IMP-NG GPRS
Figura 6.1. Arquitectura del Endpoint Field Device
27
6.1 Librerıas del Sistema (Cinterion TC-65i) 28
6.1. Librerıas del Sistema (Cinterion TC-65i)
La librerıas del sistema son un conjunto de modulos e interfaces para facilitar la
programacion y el uso de las distintas caracterısticas dispositivo. Para mantener un
orden en la forma que se desarrollo cada modulo, se ha implementado un modelo
similar a OSGi en el dispositivo. Ese alcance fue implementado por el Information
and Communication System Research Group del Swiss Federal Institute of Technol-
ogy (ETH) Zurich, con el fin de tener un sistema orientado a servicios en J2ME,
facilitando el desarrollo de aplicaciones modulares.
El problema principal es que J2ME no cuenta con las mismas capacidades que
J2SE, por ejemplo no puede cargar modulos dinamicamente, pero puede realizar un
proceso similar al de los modulos del Kernel de linux: al generar el ejecutable en
J2ME, se descomprimen todas las librerıas utilizadas, para luego compilarlas y agru-
parlas en la aplicacion que se ejecutara en el dispositivo [58] (ver figura 6.2).
unjar
hardware-io-tc65i.jar
gateway-j2me-tc65.jar
aplicacion-example.jar
endpoint-os-tc-65.jar
network-io-tc65i.jar
unjar
unjar
unjar
unjar
copiar Archivos.class .java
jar
aplicacion-example.jar
compilarBytecode
Figura 6.2. Proceso para crear una aplicacion en J2ME
Al contar con servicios que puedan ser administrados sin necesidad de reiniciar el
dispositivo, permite que los servicios sean inicializados a medida que son requeridos
por las distintas aplicaciones, y ası poder reducir el consumo de recursos. Por otro
lado, el programador siempre tendra claro que modulos son cargados y en que estado
se encuentran.
6.1 Librerıas del Sistema (Cinterion TC-65i) 29
6.1.1. Modulos
Los modulos dependeran de cada dispositivo, y entre ellos pueden reutilizarse
dado que han sido disenados para ser poco acoplados entre ellos. En la tabla 6.1 se
encuentra la lista de modulos implementados para el TC-65i.
Modulo Funcion y responsabilidades
AT Manager Ejecutar comandos AT sobre el dispositivo.
Logging Determina que tipos de registros seran representados.
GSM Manager Establece y monitorea la comunicacion GSM.
GPRS Manager Administra la conexion a la red de datos.
Socket Manager Provee socket de comunicacion.
NIO J2ME Controla la comunicacion establecida por un socket.
Serial Port Comunicacion serial completa usando ASC0.
Shell Me Ejecuta comandos de administracion y control.
Serial Console Acceso a la Shell y logging usando ASC1.
IO Manager Controlar las entradas y salidas digitales.
Temp Manager Informa y alerta sobre la temperatura, usando URC.
Power System Informa sobre la baterıa y energıa.
Persistence Persistencia de datos en la memoria del dispositivo.
Time Manager Controla la hora actual y alarmas de tiempo.
Watchdog Reinicia el sistema en caso de que no responda.
SPI y I2C Administra la comunicacion SPI y I2C.
ADC Convertidor de senales analogas a digitales.
SMS Gateway Enviar y recibir SMS.
Tabla 6.1. Lista de Modulos para el Cinterion TC-65i
Cada modulo fue disenado para cumplir una labor especifica de acuerdo a su
funcion, por ejemplo el modulo GSM Manager puede ingresar el PIN de la SIM si
esta la solicita, y ademas entregar datos relacionado a la red y el dispositivo como el
IMEI del modulo o la calidad de la senal.
6.2 Gateway J2ME (IMP-NG GPRS) 30
6.2. Gateway J2ME (IMP-NG GPRS)
Los frameworks de comunicacion mas usados tienen un consumo elevado de re-
cursos, el cual es escaso en los dispositivos moviles [59]. El Gateway J2ME tiene como
objetivo permitir la comunicacion con consumo moderado de recursos y que pueda
funcionar dentro de la heterogeneidad de dispositivos disponibles [31].
La principal caracterıstica de este gateway, es que utiliza un sistema de serial-
izacion desarrollado especialmente para dispositivos con J2ME, ya que este no la
soporta. El Apendice D detalla la serializacion en J2ME y como fue implementada en
gateways y conectores. En la comunicacion se utilizaron sockets TCP persistentes.
M2M Broker
NIO J2ME
Socket ManagerI/O Session
GPRS Manager GSM Manager
J2ME JVMCinterion IMP-NG
Gateway J2MEM2M Session
Aplicación Listeners
Cinterion TC-65i
Realiza la transmisión de datos
Comunicación de datos
Conexión al broker
Lógica de la aplicación
Figura 6.3. Diagrama de la comunicacion en el terminal remoto.
La arquitectura de comunicacion (ver figura 6.3), ha sido implementada en capas
para dividir la logica de la aplicacion, la interaccion con el broker, la comunicacion
de datos a traves del socket y la transmision de los datos al medio. Esto permite
reutilizar codigo en otros tipos de modulos programable en Java.
6.3. Aplicacion (Terminal Remoto)
Este modulo, corresponde a la implementacion que se utilizara para coordinar las
servicios a los cuales se encuentra suscrito. Se debe implementar un M2MServiceListener
y entregar sus credenciales de autorizacion por cada uno, ya que solo recibira mensajes
si esta autorizado.
6.4 Arquitectura Detallada 31
6.4. Arquitectura Detallada
Los detalles del diseno e implementacion del modulo remoto se pueden apreciar
en la figura 6.4.
Aplicación
Librerías del SistemaNIO J2ME
Socket Manager
GatewayJ2ME
(GPRS)
Servicios del Sistema Temp
ManagerSerialPort
IOManager
Listeners de Sistema Operativo Listeners del Gateway Service ListenersGateway
ServiceManager
Service XListener
Service YListener
M2MSession
Power ManagerListener
GPRS ManagerListener
Serial Port
Listener
TimeAlarm
Listener
JVM ( Cinterion IMP-NG)
GPRSManager
GSMManager
ConsoleWatchDog Shell
TimeManager
PowerManager
Logging
Figura 6.4. Diagrama de la comunicacion en el terminal de campo.
Capıtulo 7
TERMINAL ADMINISTRADOR
DE SERVICIOS
Con frecuencia se ensena a los hombres a no hacer, a no comprometerse, a no
aventurarse. Es precisamente al reves de la vida.
Alberto Hurtado
Este tipo de terminal esta disenado para dispositivos que son homogeneos y con
una mayor capacidad de comunicacion y procesamiento. Estos dispositivos correspon-
den generalmente a servidores y/o computadores por lo que se puede utilizar Java 2
Standard Edition ademas de un conjunto importante de librerıas. En la figura 7.1 se
encuentra representada la arquitectura de este terminal.
Aplicación
Gateway J2SE
Applications Listeners
Service X Listener
JVM (J2SE)
Service Y Listener
M2M Session
Figura 7.1. Arquitectura del Endpoint (Application Manager)
32
7.1 Aplicacion 33
7.1. Aplicacion
La aplicacion en terminal debe implementar los listeners necesarios para poder
escuchar los mensajes proveniente de los dispositivos remotos. Ademas debe manejar
los eventos del gateway, el cual le notificara todo sobre la comunicacion con el broker.
Al igual que todos los dispositivos, este puede utilizar distintos servicios y con roles
distintos si es necesario, de esa forma puede coordinar las aplicaciones orquestando
los procesos. De alguna forma permite facilitar el desarrollo de mashup1 o compilados
de aplicaciones.
7.2. Gateway J2SE
Para la comunicacion a traves de la red, el Gateway J2SE usara Apache Mina, y
sera implementado de forma similar al conector para J2SE implementado en el Broker.
Por lo tanto se utilizara el decodificador para transmitir objetos serializados, con el
que cuenta Apache Mina. Este gateway de controlar y establece la comunicacion con
el broker, ademas de coordinar los mensajes. Al utilizar J2SE, se pueden establecer
varias comunicaciones en paralelo para mejorar el rendimiento de la comunicacion.
1Aplicacion que combina distintas fuentes de informacion, dato o servicio, para crear un
nuevo servicio.
Capıtulo 8
EJEMPLO DE USO
No creo que haya alguna emocion mas intensa para un inventor
que ver alguna de sus creaciones funcionando.
Esa emocion hace que uno se olvide de comer, de dormir, de todo.
Nikola Tesla
Para demostrar las caracterısticas del M2M Broker, en este capıtulo se explicara la
implementacion de un ejemplo simple, haciendo un uso practico de este servicio y sus
respectivas librerıas de desarrollo.
Aprovechando las capacidades del modulo Cinterion TC-65i, se hara una apli-
cacion que recolecte la temperatura del modulo. De esa forma la aplicacion estara so-
licitando los registros a dicho servicio, y se comunicara con una aplicacion central que
almacenara registros de varios dispositivos (ver figura 8.1).
Gateway J2ME
ServidorServidor M2M BrokerGateway J2SE
Servicio M2M Broker
Terminal Tc65i
ConectorJ2ME
ConectorJ2SE
Servicios de Temperatura Servicios de TemperaturaInformación (Temperatura)
Mensaje con Información(Temperatura)
Figura 8.1. Diagrama de Ejemplo
34
8.1 Diseno e Implementacion 35
8.1. Diseno e Implementacion
La organizacion se llamara org.demo, el modulo GPRS se llamara endpoint.-
remote.demo y el servidor endpoint.manager.demo. Mientras que el servicio
sera monitor.temperatura. Todas soluciones que vayan a utilizar este middleware
y servicio, debe contemplar las siguiente etapas en su implementacion:
Configuracion en el M2M Broker
Lo primero a realizar es la configuracion del intermediario de la comunicacion, o
sea el broker. De esa forma los dispositivos podran interactuar correctamente entre
ellos. A continuacion, los pasos que deben ser seguidos:
1. Crear la Organizacion org.demo.
2. Ingresar los dispositivos y su forma de identificacion. El endpoint.remote.-
demo usara el imei y endpoint.manager.demo usara el login.
3. Relacionar los dispositivos con la organizacion org.demo.
4. Crear el servicio monitor.temperatura.
5. Instanciar el servicio en la organizacion org.demo.
Terminal Remoto
La implementacion de la aplicacion en este dispositivo resulta ser la mas compli-
cada, ya que se trabaja en un entorno restringido y especifico al dispositivo a utilizar,
en este caso Cinterion TC-65i. Los pasos son los siguientes:
1. Determinar las configuraciones del sistema operativo y los servicios que se uti-
lizaran.
2. Establecer las configuraciones del Gateway J2ME y los datos de identificacion
en este caso utilizando el IMEI y una clave.
3. Implementar los listeners para el sistema operativo, y el servicio monitor.temperatura.
4. Implementar la logica del dispositivo.
5. Iniciar los servicios y la comunicacion con el broker.
8.1 Diseno e Implementacion 36
El proceso de comunicacion que realizara el gateway con el broker, se detalla en
la seccion 4.5. La logica del dispositivo, pasara a coordinar los servicios y decidir
que acciones realizar ante los diferentes mensajes y eventos. Por otro lado estan los
servicios que son utilizados en varias organizaciones, en esos casos, la idea es utilizar
el mismo controlador en todos los dispositivos.
Terminal Administrador de Servicios
La implementacion para estos dispositivos es mas simple, ya que solo se enfoca a
recepcionar y coordinar la informacion que es generada por otros dispositivos, aunque
no quita la posibilidad de que estos servidores puedan compartir el estados de sus
recursos.
Una caracterıstica importante es que a diferencias de los Terminales Remotos que
se comunican con un numero pequeno de terminales, los Terminales Administradores
de Servicio se pueden conectar con miles de dispositivos simultaneamente.
La aplicacion en este dispositivo debe seguir el siguiente orden.
1. Establecer las configuraciones del Gateway J2SE y los datos de identificacion
en este caso usando usuario y clave.
2. Implementar los listeners para cada servicio.
3. Implementar la logica que procesa la informacion proveniente de los dispositivos
remotos.
4. Iniciar la comunicacion con el broker.
8.2 Resultado 37
8.2. Resultado
Finalmente en la aplicacion administradora de servicio puede generar un grafico
que se ira actualizando a medida que llega la temperatura desde los terminales, como
se puede apreciar en la figura 8.2. La aplicacion desarrollada no tiene ningun grado
de complejidad en cuanto a comunicacion, por lo tanto se cumplio con el objetivo de
simplificar el desarrollo de este tipo de soluciones.
Figura 8.2. Grafico de temperatura
Capıtulo 9
CONCLUSIONES
El cientıfico no tiene por objeto un resultado inmediato.
El no espera que sus ideas avanzadas sean facilmente aceptadas.
Su deber es sentar las bases para aquellos que estan por venir, y senalar el camino.
Nikola Tesla
En este proyecto de tıtulo se ha enfrentado el reto no menor de crear una her-
ramienta para facilitar la comunicacion entre maquinas. En este capıtulo se se detal-
laran las principales dificultades, las decisiones que fueron acertadas y que aspectos
son destacables de este proyecto.
Disenar y crear una herramienta requiere mas dedicacion, a diferencia de una apli-
cacion que es creada para un solo fin, y sin tener en cuenta su integracion a otras. Una
herramienta busca dar una solucion generica a las principales dificultades de un area,
sirviendo de base para soluciones futuras. Por ende se hizo una investigacion amplia a
los usos, y las principales dificultades publicadas por otros autores, y de esta forma se
llego a conocer bien los desafıos de generar una solucion para la comunicacion M2M
multiproposito.
La comunicacion de sistemas distribuidos y especialmente entre dispositivos moviles
e inalambricos, es un entorno hostil para la transmision de datos, y siempre traera con-
sigo un conjunto de dificultades y limitantes. Esto se soluciono con senalizacion, co-
las, y persistencia de mensajes, ademas de un control detallado de los estado de los
equipos.
38
9.1 Cumplimiento de objetivos y requerimientos 39
Para lograr el objetivo fue necesario hacer uso de frameworks y librerıas amplia-
mente utilizadas, para evitar rehacer la rueda y principalmente seguir los estandares.
Y es que un aspecto importante, fue aprender imitando las buenas practicas en el
diseno e implementacion. A esto se puede sumar que la mayorıa son proyectos codigo
abierto. Destaca el uso de Apache Shiro para manejar el sistema de sesiones, ya que
permitio concentrar las sesiones de todos los tipos de dispositivos en un solo admin-
istrador de sesiones, sin importar la sesion utilizada por cada conector.
El resultado de este proyecto facilita y disminuye el tiempo de desarrollo de la
mayorıa de las aplicaciones enfocadas a la comunicacion entre maquinas, evitando
que el desarrollador tenga que preocuparse de los problemas de comunicacion e iden-
tificacion, lo que disminuye el tiempo en que se pueden sacar nuevos productos al
mercado, y por ende disminuir los costos. Ademas el diseno para manejar las organi-
zaciones, dispositivos y roles, permite contar con un software como servicio y poder
ofrecerlo bajo demanda.
9.1. Cumplimiento de objetivos y requerimientos
Este documento tenıa como fin explicar el proceso y todo lo necesario para realizar
el diseno e implementacion de un intermediario activo de mensajes, entre dispositi-
vos de comunicacion movil y sistemas de informacion. A continuacion se explicara el
resultado de haber cumplido con los requerimientos descritos en el capıtulo 3 .
Para cumplir gran parte de los requerimientos, fue necesario contar con un broker
o hub, dispositivo que concentrara toda la comunicacion. Esta fue la eleccion mas ac-
ertada, ya que permite que el broker tenga un control total en la calidad, seguridad,
persistencia y distribucion de mensajes y dispositivos. Aunque es importante recordar
la necesidad de contar con distribucion de carga y tolerancia a falla.
La heterogeneidad de los dispositivos, uno de los desafıos mas importantes, se re-
solvio utilizando conectores en el lado del broker y gateway en los terminales remotos,
permite aprovechar las capacidades de cada terminal.
El broker y los gateways fueron disenado siguiendo patrones empresariales de in-
tegracion, lo que significo una inversion importante de tiempo en el diseno, pero sus
ventajas a largo plazo son valiosas, ya que disminuye el tiempo de mejoras y la ar-
quitectura es simple y modular.
9.2 Trabajo futuro 40
Un factor necesario para el exito, era que pequenas empresas que no cuentan con
servidores y una direccion fija en internet pudieran acceder a estos servicios. Este
objetivo se logro con creces, ya que ademas de no requerir una IP fija, no es nece-
sario contar con un servidor activo durante todo el dıa, ya que el broker almacena
los mensajes que seran entregados cuando se vuelva a activar el servicio en el com-
putador correspondiente. Esto disminuye los costos e incluso permite el desarrollo de
aplicaciones innovadoras.
Se logro hacer uso completo de las capacidades del Cinterion TC-65i, evitando el
uso de una unidad complementaria de procesamiento, ademas de relacionar de forma
modular el software y el hardware disponible, lo que ayuda a la creacion de software
reutilizable y mas facil de mantener, y lo mas importante: un producto de menor costo.
Aunque no era un objetivo, el sistema permite generar mashups o compilacion
de servicios, funcionalidad con mucho potencial. La reutilizacion y orquestacion de
servicios distribuidos, permite la integracion de todo nuestro entorno en un sistema sin
fisuras, donde la informacion es transmitida y compartida entre distintos dispositivos
transversalmente a su funcion, permitiendo la creacion de verdaderos ecosistemas.
9.2. Trabajo futuro
Este proyecto de tıtulo, se enfoco a dar una solucion a un problema amplio, por
lo que aspectos interesantes no se abordaron en detalle. A continuacion una serie de
sugerencia para otros proyectos, y mejoras al proyecto actual.
En cuanto a la sugerencia de proyectos relacionados estan: el descubrimiento y
descripcion de servicios dinamicos, la persistencia y distribucion de datos en sistemas
distribuidos, comunicacion peer to peer , tolerancia a falla de los sistemas distribui-
dos, la identificacion universal de dispositivos y el desarrollo modular de aplicaciones.
Respecto a las mejoras y caracterısticas adicionales que se le pueden incluir a este
proyecto a futuro estan: el panel de administracion web, incrementar la seguridad y
estabilidad, mejorar la entrega de mensajes encolados, la implementacion de otros
conectores (JMS y SMS), distribucion de carga, actualizacion masiva, consola de ad-
ministracion, que los dispositivos remotos puedan ser puertas de enlace para redes de
sensores, estandarizar la identificacion y descripcion de servicios.
9.2 Trabajo futuro 41
La comunicacion entre maquinas, es la base para tener la proxima generacion
de redes, posibilitando tener un entorno inteligente. Las principales dificultades y
desafıos esta en trabajar con dispositivos que son heterogeneos y con pocas capaci-
dades de procesamiento y comunicacion. Pero el escenario anterior esta cambiando,
las nuevas tecnologıa estan permitiendo contar con dispositivos mas pequenos y con
una mayor capacidad, lo que va a permitir que estos sean colocados practicamente en
cualquier parte y ademas soportar estandares de comunicacion mas robustos, facili-
tando su integracion. Aunque siempre existiran dispositivos con limitaciones donde
este proyecto seguira sirviendo para abordar este tipo de desafıos.
APENDICES
42
Apendice A
TECNOLOGIAS EMPLEADAS
Si supiera que el mundo se acaba manana, yo, hoy todavıa, plantarıa un arbol.
Martin Luther King
Al desarrollar un software, es importante determinar los frameworks que son uti-
lizados en soluciones similares, la razon principal es evitar rehacer algo que ya ha
sido implementado por programadores con una mayor experiencia, y ademas uti-
lizar herramientas que son ampliamente aceptadas y usadas en aplicaciones de alto
rendimiento.
En el presente capıtulo se explicaran las principales herramientas y las justifica-
ciones del por que se ha elegido cada una de estas, de tal forma que el lector pueda
tener una vision amplia de las ventajas y desventajas de usarlas, y ademas le servira de
acercamiento a las tecnologıas mas utilizadas.
El siguiente desarrollo se plantea en torno a un conjunto de librerıas Open Source,
las que toman la responsabilidad de capas concretas de la aplicacion, siguiendo los
patrones modulares y de arquitectura orientadas a servicios. Se busca un acoplamien-
to ligero entre capas, que permita su reemplazo por tecnologıas alternativas [60].
Entre las capas importantes tenemos la encargada de la comunicacion, otra de la
persistencia de datos y finalmente una de la modularidad de la aplicacion.
43
A.1 Programacion de Dispositivos Moviles 44
A.1. Programacion de Dispositivos Moviles
La programacion de los dispositivos embebidos resulta un reto debido a sus lim-
itaciones, ademas existen los modulos que se programan utilizando JTAG (C y C++)
y los que se les pueden cargar aplicaciones que correran en maquinas virtuales que
soportan Python, Java, .NET o algun otro lenguaje.
La programacion utilizando JTAG, consiste en compilar la aplicacion que sera car-
gada y ejecutada como un firmware en dicho dispositivo. Entre las ventajas esta el
alto rendimiento, flexibilidad para controlar el hardware y el control minucioso de
los recursos. Sin embargo entre las desventajas esta la necesidad de contar con ex-
periencia avanzada, dificultades para encontrar errores, la mayorıa de los errores se
encontraran en tiempos de ejecucion y finalmente la aplicacion desarrollada esta to-
talmente acoplada al hardware.
La utilizacion de aplicaciones que son cargadas sobre dispositivos que cuentan
con una maquina virtual trae como ventaja la utilizacion de lenguajes mas amiga-
bles, cuentan con API para utilizar librerıas que controlan el hardware y en algunas
ocasiones permite actualizar la aplicacion remotamente. Entre las desventajas esta la
poca flexibilidad para utilizar los recursos, y un rendimiento bastante menor.
Teniendo en cuenta que uno de los objetivos es agilizar los tiempos de desarrollo
y el tiempo con el cual se sacan nuevas soluciones al mercado, se ha decido utilizar
dispositivos que cuentan con una maquina virtual, en este caso la maquina virtual de
Java (JVM).
A.1.1. Java en Dispositivos Moviles
Desde los principios de Java, se ha planteado un objetivo, (WORA)write once, run
anywhere (escribir una vez, ejecutar en cualquier parte), que busca alcanzar la porta-
bilidad de las aplicaciones a cualquier sistema, esto se logra mediante una maquina
virtual. Otras razones para utilizar Java es que ha sido un lenguaje desarrollado desde
el comienzo para ser facil de escribir y mantener [61] [62].
El Cinterion TC-65i se programa utilizando Java para dispositivos moviles, pero
con librerıas modificadas para utilizar el hardware que dispone, de esta forma las ver-
siones CLDC y CDC de Java para dispositivos moviles incluyen un conjunto pequeno
de librerıas del Java Standard Edition, esta caracterıstica limita la portabilidad de
A.2 Seguridad 45
aplicaciones entre modulos GPRS programables en Java (Cinterion TC-65i y Motorola
G-24J) y en ese sentido nos impide utilizar la misma aplicacion en ambos dispositivo,
cabe destacar que aunque el tipo de conector B2B es el mismo el Pinout difiere en
varias senales.
La plataforma Java utilizada en el TC-65i es denominada Cinterion IMP-NG
TC65i Wireless Toolkit, y la documentacion de esta puede ser encontrada en el SDK
de dicho dispositivo, esta plataforma es la que contiene las principales librerıas y API
para utilizar el hardware que trae el dispositivo, que tiene la configuracion CLDC 1.1
y el perfil de IMP-NG que es muy similar al MIDP 2.0 .
A.2. Seguridad
Para la seguridad de aplicaciones programadas en Java, existe 2 frameworks con-
solidados, uno es Spring Security y el otro Apache Shiro, se usara el ultimo ya que
el primero requiere de muchas librerıas, las que aumentan el consumo de recursos,
eso es a causa de que Spring Security esta enfocado a la seguridad de sitios webs. De
todas formas ambos sistemas incluyen las mismas funcionalidades de Identificacion,
Autorizacion y Criptografıa.
Las principales caracterısticas de Apache Shiro que han determinado su eleccion
son el control de sesiones y la flexibilidad de ser usado en el desarrollo de frameworks
que requieran de seguridad.
Otro beneficio importante es que la informacion de la sesion puede ser compartida
entre clientes con diferentes tecnologıas, como lo pueden ser aplicaciones para moviles,
para escritorio, e incluso sitios webs, permitiendo que un cliente pueda usar distintos
medios y ser considerado de igual forma, de esa forma se adapta perfectamente a los
requerimientos del Broker.
A.3. Comunicacion y Transferencia de Informacion
A.3.1. Comunicacion Bloqueante (Java IO)
Esta es la comunicacion en red mas usada en java y consiste en Sockets(TCP) y
Datagramas(UDP), dada su simplicidad esta disponible para ser usada en los dispo-
sitivos con capacidades restringidas [63]. Ya que todos dispositivos moviles program-
ables en Java lo soportan, se usara esta API en el Gateway J2ME.
A.3 Comunicacion y Transferencia de Informacion 46
A.3.2. Comunicacion No Bloqueante (Java NIO)
En dispositivos con una mayor concurrencia de procesos y servicios se hace im-
portante el uso de Java(NIO) ya que cuenta con las las siguientes ventajas:
• Entrada salida no bloqueante.
• Posibilidad de utilizar bloques de memoria para la escritura y lectura.
• Aprovecha las capacidades del SO en el que se ejecuta la JVM.
• Ofrece mejores prestaciones y una mayor eficacia en los procesos de entrada/salida.
Java NIO es mas complejo que trabajar con Java IO, por lo cual se hace necesario
trabajar con un Framework, entre los cuales destacan Mina, Netty y Grizzly, en la
tabla A.1 se puede apreciar una comparacion subjetiva, ya que no se cuentan con
evaluaciones serias:
Framework Documentacion Rendimiento Caracterısticas
Apache MINA FFFFF FFFF FFFFJBossrNetty FFF FFFF FFFFSunrGrizzly FF FFFFF FF
Tabla A.1. Comparacion de Frameworks para Java NIO [4]
Apache MINA
Apache MINA esta basada en SEDA 1 [65] ,con el fin de soportar concurrencia
masiva (del orden de 10.000 clientes simultaneos) y evitar los principales problemas
de sistemas tradicionales basados en hebras y eventos. Se decide usar por la bue-
na documentacion, rendimiento, usabilidad y recomendaciones de varios usuarios en
proyectos similares [66] [67].
La informacion que llega como arreglo de Byte es procesado por el FilterChain
(Cadena de Filtros) de Apache Mina, el cual transforma esa informacion en estado
bruto (Raw Data) en instancias de objetos, permitiendo separar la logica del protocolo
con la logica de negocio (IoHandler) [68].
1SEDA is an acronym for staged event-driven architecture, and decomposes a complex,
event-driven application into a set of stages connected by queues [64].
A.4 Persistencia y Almacenamiento 47
Maneja la conexión
I/O HandlerI/O Session
I/O FilterChainI/O Filter #1
I/O Filter #2
I/O Service
Punto Remoto
Realiza la Entrada/Salida
Filtra y modifica el mensajes
Lógica del protocolo
Figura A.1. Arquitectura de Apache Mina
Apache Mina ademas cuenta con un Codec para transmitir y recibir objetos Seri-
alizados, facilitando el desarrollo para el Gateway J2SE, dicha caracterıstica no puede
ser aplicada en dispositivos moviles ya que el perfil CLDC para J2ME no cuenta con
las capacidad de serializar objetos.
A.4. Persistencia y Almacenamiento
A.4.1. Postgres SQL
Se ha decidido usar este motor de base de datos, ya que ademas de ser gratu-
ito tiene una comprobada reputacion en el uso de aplicaciones de alto desempeno.
Teniendo en cuenta que los factores crıticos seran el tiempo de respuesta y la ca-
pacidad de comunicar la mayor cantidad de dispositivos, se aplicaran el uso de Pool
de Conexiones y Cache para evitar consultas redundantes, practicas para lograr un
mejor desempeno al momento de almacenar y acceder a los datos [69].
A.4.2. Drivers Base de Datos y Pool de Conexiones
Resulta importante contar con un Pool de Conexiones, por una razon bastante
simple: abrir y cerrar una conexion a la base de datos consume recursos y tiempo
valioso, ademas que mantener un conjunto de conexiones permite realizar multiples
consultas en paralelo, todas esas caracterısticas son muy valiosas a la hora de contar
con un sistema concurrente y con una carga importante de solicitudes.
A.4 Persistencia y Almacenamiento 48
Postgres recomienda usar Apache Common DBCP para manejar el Pool de conex-
iones en una aplicacion standalone [70], si la aplicacion se va a desplegar en un servidor
de aplicaciones es preferible utilizar el pool de conexiones que este entrega.
A.4.3. Framework de Persistencia
La idea principal de usar un Framework de persistencia, es evitar el uso directo
de JDBC, y disminuir la cohesion con el motor de base datos, ya que el acceso se
realiza usando funciones de una API y no a traves de sentencias SQL.
Se ha decidido utilizar MyBatis que tiene como principal ventaja que permite
obtener un mejor despempeno gracias al uso de sentencias SQL optimizadas y el uso
de Cache. Otro beneficio importante es que puede ser integrado facilmente a un Pool
de Conexiones y a distintos frameworks de Injeccion de Dependencias.
Apendice B
APLICACIONES PRACTICAS DE
LA TECNOLOGIA M2M
La teorıa es cuando se sabe todo y nada funciona. La practica es cuando todo
funciona y nadie sabe por que. En este caso hemos combinado la teorıa y la
practica: nada funciona... y nadie sabe por que.
Albert Einstein
Control Medico Remoto
Las empresas que realizan examenes clınicos cuentan con dispositivos que evaluan
la salud del individuo constantemente [71], de esta forma se puede contar con un
perfil de su estado, enviar alarma en caso de algun problema, brindandoles una mayor
libertad a las personas que deben ser examinadas constantemente, ya que el doctor
podra sugerirle remotamente que tome alguna medida para cuidar su salud o asista
un determinado lugar de atencion si la situacion lo amerita [72] [16].
Control de Plagas
En la industria alimenticia, un aspecto importante es el control de plagas [72]. La
que tiene como principal objetivo evitar que se gasten horas valiosas revisando cada
trampa, en lugar de eso se envıa un SMS al servidor de control, mostrando en que
sector y cuando se ha producido. Ademas pudiendo senalar cuando las trampas aun
contienen el roedor.
49
50
Seguro a Medida y Perfil de Comportamiento
Teniendo en cuenta que ya existe un gran volumen de automoviles con un dis-
positivo de localizacion GPS, una directiva europea obligara a partir de 2012 a que
todos los coches que se fabriquen lleven una tarjeta SIM que avise automaticamente
al numero internacional de urgencias 112 en caso de accidente [20], aprovechando
esto, las companıas de seguros ya pueden controlar a su asegurado y decidir si es
un conductor agresivo o tranquilo, y ajustar el precio de su poliza. Este tipo de se-
guros ya funcionan, aunque necesitan un permiso previo de cesion de datos por el
asegurado. En las empresa de transporte Interurbano es usado para tener un perfil de
conduccion de sus trabajadores, de esta forma por ejemplo pueden entregar los buses
nuevos o de mayor importancia a los conductores con un perfil de conduccion mas
responsable [72].
Lectura Automaticas de Consumo
Uno de los principales usos de las comunicaciones M2M es la telemetrıa, en este ca-
so la lectura automatica de consumo o AMR del ingles Automatic Meter Reading [73].
Basicamente consiste en una tecnologıa que obtiene automaticamente el consumo, di-
agnostico y estado de los medidores de agua, electricidad o gas para luego transferir
esta informacion a un servidor central que realizara las operaciones de cobranza,
resolucion de problemas y analisis. Logrando principalmente un ahorro en tiempo y
dinero, y ademas entregando informacion de consumo en tiempo real, lo que permite
que tanto el cliente como el proveedor administren mejor su consumo [74].
Control de Variables Ambientales
El transporte o almacenamiento de alimentos perecederos a las temperaturas y
humedad correcta es esencial. Las soluciones M2M pueden ayudar a mantener un
control detallado del contenido que es transportado o almacenado. De esta forma
se puede emitir informes del estado de la mercaderıa transportada, aumentando la
rentabilidad para el cliente. Una solucion relacionada, pero enfocada al control de
aguas servidas gano un premio al mejor plan de negocios orientado a la limpieza, la
cual ayudara a los municipios en la prevencion de derrames de aguas residuales a
traves de un control continuo [75].
51
Seguridad
Cada vez hay una mayor incidencia en el comportamiento criminal y antisocial,
es importante demostrar compromiso en el cuidado de la fuerza de trabajo y el pat-
rimonio, ya que en terreno son mas vulnerables. En vehıculos permiten controlar la
ubicacion y la seguridad de su personal. Permitiendo que la atencion medica y policial
este disponibles en el momento y lugar indicado [76] [77].
Terminales de puntos de Venta
Las soluciones M2M en este sector permiten utilizar dispositivos inalambricos para
la transferencia electronica de fondos y de esta forma, facilitar el pago de bienes y
servicios. Estos dispositivos moviles presentan la ventaja de su movilidad y en algunos
casos la seguridad de tener el control completo de su uso por parte del propietario
de la tarjeta [25], a nivel nacional es el pago de cuentas con los distribuidores de gas
licuado por ejemplo Gasco y Servipag [78].
Distribucion de la Fuerza de Trabajo
Los sistemas de distribucion automatica proporcionar un mejor servicio al cliente
y reduccion de costos. Por ejemplo, cuando una empresa de taxis recibe una llamada
de alguien para reservar un taxi; esta solicitud se envıa a traves de un ordenador
al conductor mas cercano para aceptar el trabajo; ademas la central puede estar al
tanto de la ubicacion y estado de cada taxi. En casos mas avanzados un sistema de
navegacion le podrıa indicar la ruta mas rapida. Lo cual da como resultado un ahorro
de tiempo, dinero y una mejora en la experiencia de los clientes. Actualmente un
sistema con esas caracterısticas esta funcionando en el aeropuerto de Paris Charles
de Gaulle, con excelentes resultados, por lo cual los aeropuertos de Paris y Steria
estan planeando implementarlo a corto plazo [72].
Apendice C
DESARROLLO PARA
DISPOSITIVO TC-65
Si exagerasemos nuestras alegrıas, como hacemos con nuestras penas,
nuestros problemas perderıan importancia.
Anatole France
A continuacion se entregaran la informacion necesaria para desarrollar aplica-
ciones utilizando modulos que utilizan las redes celulares.
C.1. Instalacion del SDK
Entorno Windows
La instalacion del SDK, incluye el MES (Module Exchange Service), la cual per-
mite acceder al dispositivo de almacenamiento que tiene el TC-65i, ademas permite es-
tablecer una conexion para debugear usando el emulador. Es importante tener conec-
tado el dispositivo y con los drivers necesarios al instalar el SDK, ya que sera necesario
para configurara el entorno de desarrollo.
Entorno Linux
El SDK no es compatible con linux, pero un grupo que tuvo acceso al protocolo
ha desarrollado un conjunto de herramientas que permiten cargar aplicaciones, sin
embargo aun no es posible debugear en entorno linux.
52
C.1 Instalacion del SDK 53
Entre las cosas importantes esta trabajar con puertos seriales el linux, en caso de
usar conectores a serial estos se pueden detectar ejecutando:
$dmesg | grep tty
Para el USB del modulo TC-65i se optiene /dev/ttyACM0 y para los otros usb
se optiene /dev/ttyUSB0 y /dev/ttyUSB1. Para poder comunicarse con los modulos
se requiere de JObexFTP1 o Tc65SSH2, se utilizo TC65ssh por la flexibilidad.
Ambos clientes ObexFTP usan la librerıa RXTX3 que permite crear programas
que utilicen el puerto serial en Linux, Windows , Mac-OS y Solaris. Por lo tanto es
necesario copiar las librerıas o archivos *.so a /usr/lib y el RXTXcomm.jar al class-
path del Tc65SSH.
Para cargar archivos los archivos app.jar y app.jad y luego iniciar la aplicacion se
debe ejecutar el siguiente comando:
java -cp tc65sh.jar:RXTXcomm.jar:. org.tc65sh.Main
-p /dev/ttyACM0
-c "put /home/me/app.jar /home/me/app.jad;AT^SJRA=a:/app.jar"
En caso de utilizar Netbeans o Eclipse es necesario usar solo las librerıas del
Siemens Mobility Toolkit (SMTK) ya que los ejecutables estan solo para windows,
pero se pueden usar los ejectuables del Sun Java(TM) Wireless Toolkit 2.5.2 sin
ningun problema, copiandolos a la carpeta ./bin del SMTK.
Finalmente para trabajar con puerto serial existen 2 programas para linux Cute-
Com que cuenta con interfaz grafica y minicom que se usa por consola, el comando
mas simple es el siguiente:
minicom -o -D /dev/ttyUSB0
1https://github.com/3esmit/JObexFTP2http://www.vilsmeier-consulting.de/tc65sh.html3http://rxtx.qbang.org/
C.2 Identificacion del Proveedor de Servicio 54
C.2. Identificacion del Proveedor de Servicio
Cada operador celular tiene un identificador unico denominado Mobile Network
Code (MNC), ademas cada pais tambien tiene su identificador unico conocido como
Mobile Country Code (MCC), dichos codigos forman parte del International
Mobile Subscriber Identity (IMSI) [79] (Ver tabla C.1).
MCC MNC Operador
730 1 Entel PCS Telecomunicaciones S.A.
730 2 Telefonica Moviles Chile S.A. (movistar)
730 3 America Movil Chile (Claro)
730 10 Entel Telefonıa Movil S.A.
Tabla C.1. Lista de MNC y MCC en Chile.
C.3. Configuracion de la Red de Datos en Chile
Para tener acceso a la red de datos (GPRS, EDGE, o ) se requieren de los datos
para ser configurada, entre los datos importantes estan el APN, usuario y clave. Una
lista con las configuraciones en Chile se puede apreciar en la tablaC.24.
Proveedor APN Usuario Password
Entel imovil.entelpcs.cl entelpcs entelpcs
Entel WAP bam.entelpcs.cl entelpcs entelpcs
Movistar web.tmovil.cl web web
Claro bam.clarochile.cl clarochile clarochile
Claro bap.clarochile.cl clarochile clarochile
Tabla C.2. Lista de APN en Chile.
4El Tc-65 no es compatible con proxy.
C.4 Comandos AT (TC-65) 55
C.4. Comandos AT (TC-65)
Comando AT Funcion
AT SJRA=A:/app.jar Ejecuta app.jar
AT SISR=1,1500 Leer datos encolados en el socket
AT SISW=1,N,0,0 Escribir N caracteres en el socket
AT SISC=1 Desconectar
AT SCFG? Ver configuracion
ATˆMONI Ver estado de la comunicacion con la antena
AT SMSO Apagar
AT+CFUN=1,1 Reiniciar
AT+IPR=115200 Setear tasa transferencia
ATI Ver version del Firmware Instalado
AT+CGREG? Revisar el estado del registro en la red GPRS
AT+CGREG=1 Activar URC para cambios de estado en la Red.
AT+CGATT=1 Unirse a la red GPRS.
AT+CSQ Calidad de la Senal.
AT+CGATT=0 Desconectarse de la red GPRS
AT SJNET Configuracion de la red GPRS
AT+CREG? Revisar estado de la conexion celular
AT SICI Informacion de la conexıon a Internet
AT+CIMI Obtiene el codigo IMSI , MCC y MNC
ATˆMONP Estado de las antenas vecinas.
Tabla C.3. Tabla resumen de comandos AT utilizados en el dispositivo TC-65.
C.5. Entorno de desarrollo
Todos los modulos han sido programados para ser ejecutados y compilados por
Maven, por lo tanto estos codigos pueden ser utilizados facilmente desde Linux o
Windows, usando comandos o cualquier IDE. El IDE que se utilizo fue el Netbeans
7.0 y en la figura C.1 se puede apreciar todos los proyectos Maven desarrollados, tanto
librerıas como el broker.
C.5 Entorno de desarrollo 56
Figura C.1. Entorno de desarrollo
El apendice A detalla porque se han elegido determinados frameworks, ademas
en el apendice C se explica como instalar lo necesario para trabajar con el Cinterion
TC-65i en Windows y Linux.
Apendice D
SERIALIZACION EN J2ME
La mayorıa de los hombres persiguen el placer
con tal apresuramiento, que en su prisa, lo pasan de largo.
S. Kierkegaard
El proceso de Serializacion consiste en poder transformar un objeto instanciado
en datos binarios, con el fin de ser almacenados o transmitidos, para luego realizar
el proceso contrario y recupera el objeto instanciado (ver figura D.1). Resulta ser la
mejor forma de transmitir datos entre sockets [57].
Almacenar Transmitir
Arreglo de Bytes
Origen Destino
Objeto 4
InstanciaObjecto
Compuesto
Objeto 3
Objeto 2
Objeto 1
Objeto 4
InstanciaObjecto
Compuesto
Objeto 3
Objeto 2
Objeto 1 Serializar Deserializar
Base de Datos Entradas / Salidas
Figura D.1. Proceso de serializacion
El SDK de J2ME no soporta Reflexion, por lo tanto no permite la exploracion del
objeto y sus metodos, impidiendo desarrollar un sistema automatico de serializacion
de los objetos. En cambio J2SE soporta serializacion y mucho de sus objetos basicos
cuentan con metodos de serializacion, por lo cual algo que es totalmente automatico
en J2SE, se debe hacer de una manualmente en J2ME.
57
D.1 Serializacion en J2ME 58
D.1. Serializacion en J2ME
Para desarrollar un sistema de serializacion en J2ME, este cuenta con DataInput-
Stream y DataOutputStream que permiten transformar datos primitivos en arreglos
de bytes y viceversa. La idea es extender esas clases para trabajar con otro tipo de
datos basicos, y desarrollar un sistema de serializacion utilizando dichas clases.
Existen variadas formas de generar un sistema de serializacion. Lo mejor es crear
2 clases que extenderan las clases DataInputStream y DataOutputStream, DataInput-
StreamMe y DataOutputStreamMe respectivamente, para implementar metodos que
que permitan trabajar con mas tipos de datos.
Al no contar con un sistema de Serializacion en J2ME, cada objeto que sea nece-
sario serializar debe extender SerializableMe, interfaz que tiene 2 funciones: serialize
y deserialize. Ambas funciones deben ser implementadas por cada objeto con el fin
de transformar los datos importantes de dicho objeto en arreglos de byte y viceversa,
es importante que esas funciones sigan el mismo orden a la hora de poner y obtener
los datos del arreglo de bytes.
Finalmente se genera una clase SerializatorMe, el cual se encarga de manipular
los objetos que extienda SerializableMe, invocando sus metodos serialize y deserialize
respectivamente, si es que extienden la interfaz SerializableMe. En la figura D.2 estan
las clases y su relacion con las clases con las que cuenta J2ME.
DataOutputStream
DataInputStream
DataOutputStreamMe
DataInputStreamMe
SerializableMe
SerializatorMe
<<interface>>
Figura D.2. Diagrama de clases de serializacion en J2ME
REFERENCIAS
[1] H. D. V. T. H. Harry Bouwman, Mobile Services Innovation and Business Mod-
els. Springer, 2008.
[2] Motorola. (2009) G24 java module, delivering seamless mo-
bility to the m2m world. [Online]. Disponible: http:
//www.motorola.com/staticfiles/Business/Products/M2MWirelessModules/
G24JAVA/ Documents/staticfiles/G24-JavaProductBrochure new.pdf
[3] Cinterion. (2010) Evolution platform, connector modules. [Online].
Disponible: http://www.cinterion.com/tl files/cinterion/downloads/cinterion
datasheet evolution connector web.pdf
[4] Z. Development. (2009) Scalable NIO servers - part 1 - perfor-
mance. [Online]. Disponible: http://www.znetdevelopment.com/blogs/2009/
04/07/scalable-nio-servers-part-1-performance/
[5] Mark Weiser. (1991) The Computer for the 21st Century. [Online]. Disponible:
http://nano.xerox.com/hypertext/weiser/SciAmDraft3.html
[6] Metrilog. (2005) New age telemetry. [Online]. Disponible: www.metrilog.at/
download/M2M WhitePaper.pdf
[7] E. Consulting. (2009) Key factors for a successfull deployment strategy
(part 2). [Online]. Disponible: http://emblazeworld.com/Attachments-Articles/
2009-MayCellularM2MWhitepaper-Part2.pdf
[8] Sunil Hattangady. (2010) Wireless m2m, key factors for a successful
deployment strategy(part 2). [Online]. Disponible: http://emblazeworld.com/
Attachments-Articles/2009-MayCellularM2MWhitepaper-Part2.pdf
[9] David Melendi Palacio y Abel Rionda Rodrıguez. (2008) Arquitecturas de
mensajes. [Online]. Disponible: www.it.uniovi.es/docencia/Telematica/appTel/
material/Tema5.pdf
59
Referencias 60
[10] Fundacion EROSKI. (2010) Comunicaciones m2m. [Online]. Disponible:
http://www.consumer.es/web/es/tecnologia/internet/2010/02/08/190762.php
[11] M. Architect. (2010) What is m2m? [Online]. Disponible: http://www.
m2marchitect.com/what-is-m2m.html
[12] C. Floerkemeier, M. Langheinrich, E. Fleisch, F. Mattern, and S. E. Sarma,
Eds., The Internet of Things, First International Conference, IOT 2008, Zurich,
Switzerland, March 26-28, 2008. Proceedings, ser. Lecture Notes in Computer
Science, vol. 4952. Springer, 2008.
[13] K.-D. Walter. (2009) Implementing m2m applications via gprs, edge and umts.
[Online]. Disponible: http://m2m.com/docs/DOC-1003
[14] D. Wallace. (2005) Protocol problems. [Online]. Disponible: http:
//industrialm2m.blogspot.com/2005/03/protocol-problems.html
[15] Cinterion. (2010) Vertical markets, how m2m can improve your life. [Online].
Disponible: http://www.cinterion.com/verticals.html
[16] ——. (2010) ehealth: Mobile health care, intelligent cellular connectivity for
health and wellness applications. [Online]. Disponible: http://www.cinterion.
com/tl files/cinterion/downloads/cinterion eHealth broschure web.pdf
[17] Allied Business Intelligence Research. (2010) M2m market forecasts.
[Online]. Disponible: http://www.abiresearch.com/research/1003362-M2M
Market Forecasts
[18] Strategy Analytics. (2010) Global mobile m2m market to reach $57 billion
by 2014. [Online]. Disponible: http://www.strategyanalytics.com/default.aspx?
mod=PressReleaseViewer&a0=4072
[19] BITX. (2007) Powering the m2m revolution. [Online]. Disponible: http:
//www.slideshare.net/scardin/bitx-powering-the-m2m-revolution
[20] Ediciones El Paıs. (2010) Telefonica apuesta por el mercado sin personas.
[Online]. Disponible: http://www.elpais.com/articulo/tecnologia/Telefonica/
apuesta/mercado/personas/elpeputec/20091215elpeputec 5/Tes
[21] Machine to Machine The Internet of Things. (2009) Verizon wireless
on the m2m bandwagon. [Online]. Disponible: http://m2m.orangeom.com/
vzw-on-the-m2m-bandwagon/
[22] ——. (2009) Verizon wireless: M2m push. [Online]. Disponible: http:
//m2m.orangeom.com/verizon-wireless-m2m-push/
Referencias 61
[23] Domingo Legua. (2009) Telefonica crea una division centra-
da en el mercado m2m. [Online]. Disponible: http://www.
networkworld.es/Telefonica-crea-una-division-centrada-en-el-mercado--M2M-/
seccion-actualidad/noticia-88244
[24] Machine to Machine The Internet of Things. (2010) T-mobile sets
up new m2m center. [Online]. Disponible: http://m2m.orangeom.com/
t-mobile-sets-up-new-m2m-center/
[25] Empresas Orange. (2009) Soluciones de movilidad - m2m. [Online]. Disponible:
http://empresas.orange.es/aplicaciones moviles profesionales/m2m/
[26] Machine to Machine The Internet of Things. (2009) At&t gets
on board with m2m. [Online]. Disponible: http://m2m.orangeom.com/
att-gets-on-board-with-m2m-the-internet-of-things/
[27] Zacks Investment Research. (2009) Mobile M2M market flourishing. [On-
line]. Disponible: http://www.zacks.com/stock/news/25413/Mobile+M2M+
Market+Flourishing
[28] Gelmato. (2010) Gemalto acquires cinterion, the global leader in machine-to-
machine.
[29] El blog de la Comision del Mercado de las Telecomunicaciones. (2010)
A toda maquina. [Online]. Disponible: http://blogcmt.com/2010/01/15/
a-toda-maquina/
[30] Empresas Orange. (2009) Whitepaper m2m. [Online]. Disponible: http:
//www.steria.com/documents/File/WP Machine-to-Machine M2M.pdf
[31] O. Riva and J. Kangasharju, “Challenges and lessons in developing middleware
on smart phones,” Computer, vol. 41, pp. 23–31, oct. 2008.
[32] Cisco. (2011) Cisco visual networking index (vni) forecast (2010-2015). [Online].
Disponible: http://www.cisco.com/en/US/netsol/ns827/networking solutions
sub solution.html#∼forecast
[33] Wikipedia. (2010) Computacion ubicua. [Online]. Disponible: http://es.
wikipedia.org/wiki/Computacion ubicua
[34] K.-D. Walter. (2009) Implementing m2m applications via gprs, edge and
umts. [Online]. Disponible: http://m2m.com/servlet/JiveServlet/previewBody/
1003-102-1-1006/Whitepaper 01.pdf
[35] S. W. Module. (2005) Tc65 the m2m application platform. [On-
line]. Disponible: http://www.siemens.com.br/templates/get download2.aspx?
id=2199&type=FILES
Referencias 62
[36] M. Nordic. (2005) Tc65 plug into the wireless m2m market. [Online].
Disponible: http://www.m2m.dk/00730/00737/00747/
[37] IBM. (2010) Mq telemetry transport. [Online]. Disponible: http://mqtt.org/faq
[38] A. Modules. (2009) G24 java module. [Online].
Disponible: http://www.adaptivemodules.co.uk/index.cfm/fa/shopdetails/
Product ID/334/Category ID/26/Sub Category ID/74
[39] Telit. (2011) Telit acquires motorola m2m.
[40] Enfora. (2009) Enfora service gateway. [Online]. Disponible: http://www.
enfora.com/index.cgi?CONTENT ID=2565
[41] BITX. (2010) The bitx m2m ecosystem. [Online]. Disponible: http://www.bitx.
com/sites/bitx.mediagrouptv.com/files/BITX SYS DETAIL ENG 1.0 2.pdf
[42] Wikipedia. (2010) Opengate. [Online]. Disponible: http://en.wikipedia.org/
wiki/OpenGate
[43] O. Systems. (2010) Opengate connector. [Online]. Disponible: http://www.
opengate.es/esp/caracteristicas/connector.htm
[44] PipesBox. (2010) WS4d. [Online]. Disponible: http://ws4d.e-technik.
uni-rostock.de/?page id=76
[45] Carl Weinschenk. (2010) M2M, the quiet giant. [On-
line]. Disponible: http://www.itbusinessedge.com/cm/blogs/weinschenk/
m2m-the-quiet-giant/?cs=38202
[46] M. Architect. (2010) What is m2m, siemens tc65, ac75 ... [Online]. Disponible:
http://www.m2marchitect.com/what-is-m2m--3.html
[47] European Business Press. (2008) Cinterion hailed as m2m wireless
modules leader. [Online]. Disponible: http://www.electronics-eetimes.com/
en/cinterion-hailed-as-m2m-wireless-modules-leader?cmp id=7&news id=
208401418
[48] L. Soto. (2010) Requerimientos funcionales y no fun-
cionales. [Online]. Disponible: http://www.mitecnologico.com/Main/
RequerimientosFuncionalesYNoFuncionales
[49] R. M. H. R. P. S. Frank Buschmann and M. Stal. (1996) Broker pattern. [Online].
Disponible: http://www.vico.org/pages/PatronsDisseny/PatternBroker/
[50] ——. (1996) Publisher subscriber pattern. [Online]. Disponible: http:
//www.vico.org/pages/PatronsDisseny/PatternPublisherSubscriber/
Referencias 63
[51] R. H. R. J. Erich Gamma and J. Vlissides. (1995) Proxy pattern. [Online].
Disponible: http://www.vico.org/pages/PatronsDisseny/PatternProxy/
[52] G. Ramblings. (2003) Hub and spoke [or] zen and the art of message broker
maintenance. [Online]. Disponible: http://www.enterpriseintegrationpatterns.
com/ramblings/03 hubandspoke.html
[53] G. Hohpe and B. Woolf, Enterprise Integration Patterns. Addison-Wesley,
2008.
[54] G. Ramblings. (2003) Messagebroker. [Online]. Disponible: http://www.
eaipatterns.com/MessageBroker.html
[55] Wikipedia. (2011) Middleware. [Online]. Disponible: http://es.wikipedia.org/
wiki/Middleware
[56] M. M. Angel). (2011) Middleware. [Online]. Disponible: http://www.magmax.
org/drupal/es/node/49
[57] R. M. G. R. Celeste Campo V´zquez and G. D.-A. Sancho. (2003)
Desarrollo de un mecanismo de serializacion en j2me. [Online]. Disponible:
www.it.uc3m.es/celeste/papers/Serializacion.pdf
[58] ETHZ-IKS. (2004) Cldc/midp applications. [Online]. Disponible: http:
//jadabs.berlios.de/jadabs-cldc/intro/midpapps.html
[59] C. Becker, G. Schiele, H. Gubbels, and K. Rothermel, “Base a micro-broker-
based middleware for pervasive computing,” in PERCOM ’03: Proceedings of
the First IEEE International Conference on Pervasive Computing and Commu-
nications. Washington, DC, USA: IEEE Computer Society, 2003, p. 443.
[60] G. de Cantabria. (2010) Amapbase, consideraciones generales. [Online].
Disponible: http://amap.cantabria.es/confluence/display/BASE/Base
[61] M. Barr. (2010) Kvm: A small java virtual machine for j2me.
[Online]. Disponible: http://www.netrino.com/Embedded-Systems/How-To/
KVM-J2ME-Java-Virtual-Machine
[62] M. Barr and B. Frank. (2010) Java in embedded systems. [Online]. Disponible:
http://www.netrino.com/Embedded-Systems/How-To/Embedded-Java
[63] Q. H. Mahmoud. (2003) J2me low-level network programming. [Online].
Disponible: http://developers.sun.com/mobility/midp/articles/midp2network/
[64] M. Welsh. (2006) Seda: An architecture for highly concurrent server applications.
[Online]. Disponible: http://www.eecs.harvard.edu/∼mdw/proj/seda/
Referencias 64
[65] Wikipedia. (2010) Staged event driven architecture. [Online]. Disponible:
http://en.wikipedia.org/wiki/Staged event-driven architecture
[66] Apache MINA. (2010) Testimonials. [Online]. Disponible: http://mina.apache.
org/testimonials.html
[67] Z. Development. (2009) Scalable NIO servers - part 3 - features.
[Online]. Disponible: http://www.znetdevelopment.com/blogs/2009/04/13/
scalable-nio-servers-part-3-features/
[68] Apache MINA. (2010) Why use a protocolcodecfilter? [Online]. Disponible:
http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html
[69] Java Performance Tuning. (2010) Jdbc performance tips. [Online]. Disponible:
http://www.javaperformancetuning.com/tips/jdbc.shtml
[70] PostgreSQL. (2010) Postgres JDBC : Applications, datasource. [Online].
Disponible: http://jdbc.postgresql.org/documentation/84/ds-ds.html
[71] Wikipedia. (2010) Electronic health record. [Online]. Disponible: http:
//en.wikipedia.org/wiki/Electronic health record
[72] Empresas Orange. (2009) Brochure m2m. [Online]. Disponible: http:
//www1.orange.co.uk/m2mvillage/download-pdf.php
[73] Wikipedia. (2010) Automatic meter reading. [Online]. Disponible: http:
//en.wikipedia.org/wiki/Automatic meter reading
[74] Enfora. (2010) Arm energia. [Online]. Disponible: http://www.enfora.com/
index.cgi?CONTENT ID=1727
[75] City of Anaheim. (2009) Ac-net awards $25,000 to hadronex llc in clean
tech business plan competition. [Online]. Disponible: http://www.anaheim.net/
administration/PIO/news.asp?id=1142
[76] Machine to Machine The Internet of Things. (2009) M2m and se-
curity from tellular. [Online]. Disponible: http://m2m.orangeom.com/
m2m-and-security-from-tellular/
[77] Enfora. (2010) Seguridad. [Online]. Disponible: http://www.enfora.com/index.
cgi?CONTENT ID=1910
[78] Gasco. (2010) Multiservicios gasco. [Online]. Disponible: http://www.gasco.cl/
multiservicio/multiservicios.html?opcion=F1
[79] Wikipedia. (2010) Mobile country code y mobile network code. [Online].
Disponible: http://es.wikipedia.org/wiki/Mobile country code
