Creación de un gateway entre SMS y JMS para Kannel

Transcripción

1 UNIVERSIDAD DE LAS AMÉRICAS PUEBLA Escuela de Ingeniería Departamento de Ingeniería en Sistemas Computacionales Creación de un gateway entre SMS y JMS para Kannel Tesis profesional presentada por Oscar Medina Duarte como requisito parcial para obtener el título de Licenciado en Ingeniería en Sistemas Computacionales Sta. Catarina Mártir, Puebla. Primavera de 2005

2 UNIVERSIDAD DE LAS AMÉRICAS PUEBLA Escuela de Ingeniería Departamento de Ingeniería en Sistemas Computacionales Creación de un gateway entre SMS y JMS para Kannel Tesis profesional presentada por Oscar Medina Duarte como requisito parcial para obtener el título de Licenciado en Ingeniería en Sistemas Computacionales Jurado Jose Luis Zechinelli Presidente Oleg Starostenko Vocal y Director Yuhsi Takahashi Secretario Sta. Catarina Mártir, Puebla. Mayo de 2005

3 UNIVERSIDAD DE LAS AMÉRICAS PUEBLA ESCUELA DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA EN SISTEMAS COMPUTACIONALES HOJA DE FIRMAS Tesis presentada por Oscar Medina Duarte como requisito parcial para obtener el título de Licenciado en Ingeniería en Sistemas Computacionales. Aceptada por el Departamento de Ingeniería en Sistemas Computacionales Dr. Oleg Starostenko Vocal y Director Dr. Jose Luis Zechinelli Presidente M.C. Yuhsi Takahashi Secretario Dr. David Sol Martínez Jefe del Departamento Sta. Catarina Mártir, Cholula, Puebla a 17 de Mayo de 2005

4 A mis padres que con tanto esfuerzo y cariño me dieron la oportunidad de estudiar, a mis hermanos que siempre me alentaron a seguir, a mi novia Pao que siempre tuvo una caricia a pesar de mi ansiedad y un beso alentador para darme, a EC por su amistad y por esas 4 líneas de código y a todas las personas que tuvieron que ver con la realización de este trabajo. OM MANI PEME HUM

5 Índice general 1. Introducción Definición del problema Persistencia y fallas Componentes Objetivos Objetivos generales Objetivos específicos Alcances y limitaciones Alcances Limitaciones Recursos a utilizar Estado actual del problema Sistemas existentes Aportación Técnicas y tecnologías a usar Análisis de tecnologías Tecnologías existentes en el mercado Productos y tecnologías i

6 ÍNDICE GENERAL ii 2.2. Protocolo de intercambio de información y control en Kannel Método de desciframiento Descripción General del protocolo Análisis del protocolo Arquitectura Implementación kjprotocol API kjgateway Ejemplo simple Pruebas Funcionamiento del protocolo Funcionamiento del gateway Transacciones y persistencia Comentarios Evaluación del sistema Conclusiones Trabajo a futuro A. Kannel box protocol description 56 A.1. Current C structures A.2. Protocol Definition A.3. BNF of protocol packets A.3.1. Protocol Glossary B. Propiedades de configuración 65

7 ÍNDICE GENERAL iii C. Código fuente 67 C.1. mx.udlap.kjprotocol.adminkmessage C.2. mx.udlap.kjgateway.simplejmstransport C.3. mx.udlap.kjgateway.simplemessage C.4. mx.udlap.kjgateway.simpleservice D. Configuración de Kannel 81 E. Sniffing de sesiones 83 E.1. kjgateway sniffing E.2. smsbox sniffing Bibliografía 91

8 Capítulo 1 Introducción En los últimos años, se ha presentado una enorme demanda por servicios portátiles, a los que se les ha llamado tecnologías móviles, este repentino crecimiento de tecnologías ha traído consigo nuevas formas de hacer negocios y nuevos paradigmas para ofrecer servicios de información. Tal es el caso de los servicios de texto o SMS [1] [4] por sus siglas en inglés Short Message Service que permiten el intercambio de mensajes cortos (entre 140 y 160 caracteres como límite) entre teléfonos celulares o entre teléfonos celulares y una central de SMS (llamada SMSC [1] [4] por sus siglas en inglés Short Message Service Center) que a su vez, puede redirigir los mensajes a una entidad externa de mensajes cortos (llamada ESME [4] por sus siglas en inglés External Short Message Entity) donde pueden ser procesados para brindar servicios más complejos. Para que un ESME sea capaz de hospedar servicios, éste debe comunicarse con el SMSC mediante un protocolo de propósito específico, generalmente SMPP [4] que permite el intercambio de mensajes a través de una conexión punto a punto, que puede realizarse usando protocolos de más bajo nivel como TCP [3], PPP [8] u otros. Este enlace debe ser establecido por un gateway (SMS gateway) que implemente dicho protocolo e integre el enlace a los servicios de información que se van a ofrecer. Los servicios son atendidos por un software que recibe el mensaje del cliente, lo procesa y envía una 1

9 CAPÍTULO 1. INTRODUCCIÓN 2 ESME Servicio 1 Servicio 2 SMS Gateway SMPP SMSC Red Celular Servicio 3 SMPP Teléfono móvil Figura 1.1: Trayectoria de los mensajes transmitidos entre un servicio y un teléfono móvil respuesta de regreso en caso de ser requerido. A este software vamos a llamarlo servicio de ahora en adelante. Uno de los SMS gateways más populares actualmente, es el proyecto Kannel [2] [9], que es un WAP [7] y SMS gateway que sigue la filosofía OpenSource [10]. Kannel posee, entre otras características, la capacidad para crear servicios muy sencillos mediante el uso de archivos de configuración, pero para una aplicación en el mundo real, esta capacidad es bastante reducida, por lo que posee características que le permiten comunicarse con otros procesos usando HTTP [6], de este modo, servicios más complejos pueden ser desarrollados como aplicaciones web Definición del problema El protocolo que usa Kannel para comunicarse con otras aplicaciones (HTTP) funciona correctamente, pero tiene la desventaja de no haber sido diseñado específicamente

10 CAPÍTULO 1. INTRODUCCIÓN 3 para este propósito, lo cual trae con sigo algunos aspectos a considerar Persistencia y fallas HTTP no incorpora características para mantenimiento de persistencia, por lo que en caso de falla del sistema, pueden llegar a perderse mensajes, ya que no existe un método para recuperarlos. Tampoco existe el concepto de transacciones por lo que no se tiene un control de las acciones que son iniciadas y terminadas con éxito Componentes Kannel puede ser configurado para funcionar de manera distribuida, pero sus componentes realizan demasiadas tareas que en la mayoría de los casos no son utilizadas. El funcionamiento de unos componentes depende del de otros de manera directa, por lo que podemos decir que los módulos de Kannel no son del todo autónomos Objetivos Objetivos generales Crear un módulo para Kannel (box) que sirva como gateway entre el protocolo nativo/intenrno de Kannel y Java mediante el uso de JMS que permita persistencia de los mensajes y uso de transacciones Objetivos específicos 1. Habilitar la persistencia de mensajes transferidos entre Kannel y un servicio SMS mediante la integración con JMS que permite administrar esta característica.

11 CAPÍTULO 1. INTRODUCCIÓN 4 2. Habilitar las características de JMS para uso de transacciones en las colas de mensajes compartidas por el gateway y una aplicación de servicio SMS. 3. Reducir el tamaño de los componentes de un Gateway basado en Kannel. 4. Aumentar la autonomía de la administración de los componentes. 5. Determinar si es necesario modificar el bearerbox para una conexión más estable Alcances y limitaciones Alcances 1. Desarrollar un módulo (box) capaz de mantener una conexión con el bearerbox de Kannel. 2. El software resultante tendrá las características necesarias para la etapa de pruebas. 3. Crear una arquitectura que permita mayor autonomía de los componentes del sistema. 4. Realizar pruebas con el nuevo módulo: a) Que demuestren la funcionalidad básica de la implementación del protocolo. b) Con simulaciones de casos de tráfico extremo. c) Con un servicio de ejemplo.

12 CAPÍTULO 1. INTRODUCCIÓN Limitaciones 1. La manera de configurar el software resultante será principalmente mediante archivos de configuración. 2. El manual resultante tendrá sólo las características necesarias para que otras personas de la comunidad puedan experimentar con él. 3. La documentación del software deberá estar escrita en inglés con el objeto de facilitar la participación de la comunidad en el proyecto. 4. Las pruebas se limitarán al hardware, software y conexiones disponibles al momento de la experimentación Recursos a utilizar Hardware Los requerimientos de hardware dependerán de los requerimientos de las herramientas de software a utilizar. Software Las pruebas se realizarán usando la versión CVS de Kannel más reciente disponible y compatible al momento de realizar las pruebas. Se utilizará cualquier sistema operativo que soporte el uso de las herramientas requeridas: 1. Java como plataforma y lenguaje de programación principal 2. jedit como interfaz de desarrollo 3. gcc Kannel está escrito en C asi que es probable llegar a utilizar algunas librerías o desarrollar partes en C.

13 CAPÍTULO 1. INTRODUCCIÓN 6 4. ethereal/tcpdump software de monitoreo de bajo nivel para analizar la información transferida. 5. Kannel es preferente trabajar con la última versión cvs de Kannel. 6. JBoss para usar su implementación de JMS y otras características Estado actual del problema Sistemas existentes No hay sistemas disponibles en la red que resuelvan estos problemas en Kannel, lo más cercano a éste, son sistemas que reciben los mensajes de Kannel por HTTP y a continuación los traducen a una especificación de JMS para distribuirlos a sus servicios. Esto es, usando el smsbox incluido en Kannel que presenta las desventajas mostradas en la sección 1.1. Componentes de Kannel Los componentes en Kannel son llamados box es en el lenguaje del proyecto, y existen tres tipos principales: bearerbox smsbox wapbox El bearerbox o bearer es el encargado de realizar las conexiones con los SMSC s y realizar el ruteo entre las conexiones y los servicios, el smsbox se conecta al bearer mediante un protocolo interno y es el encargado de atender los servicios SMS, y el wapbox

14 CAPÍTULO 1. INTRODUCCIÓN 7 se encarga del mismo modo de atender servicios WAP. De los problemas que se han expuesto en la sección 1.1, el único que ha intentado resolverse ha sido el de la persistencia, pero su solución hasta el momento no ha mostrado buenos resultados, actualmente (Octubre 2004) es la parte más discutida y modificada diariamente por los desarrolladores interesados. Para intentar resolver este problema, el bearerbox implementa una cola de mensajes interna que almacena los mensajes de tres modos posibles: Memoria RAM - Veloz pero no es persistente. Archivo - Persistente pero muy lento. Base de Datos - Promedio de los anteriores. Estos métodos, en condiciones de alto tráfico o tráfico con ciertas características, suele fallar, resultando en la pérdida de algunos mensajes Aportación La idea aquí es la implementación de un smsbox que en lugar de proveer sus servicios a través de HTTP, lo haga a través de JMS. Podríamos decir que se va a implementar un jsmsbox que tomará en cuenta los aspectos negativos del smsbox (Secc. 1.1 ) para corregirlos Técnicas y tecnologías a usar Reverse Engineering, para descifrar el protocolo nativo de Kannel Packet Sniffing, para descifrar el protocolo nativo de Kannel principalmente. J2EE, se usará como ambiente en algunos casos y pruebas para demostrar integración.

15 CAPÍTULO 1. INTRODUCCIÓN 8 JMS, especificación de MQ de Java. Los lenguajes que serán más probablemente utilizados son: Java, C, Bourne Shell.

16 Capítulo 2 Análisis de tecnologías 2.1. Tecnologías existentes en el mercado Dado el acelerado crecimiento comercial en la prestación de servicicios móviles basados en texto, existe en el mercado una oferta considerable de soluciones con distintos enfoques y características, mismas que a continuación, serán exploradas de manera general Productos y tecnologías Hay una buena gama de opciones y diferencias entre los distintos productos SMS. La razón por la que se ha escogido Kannel para este proyecto, es que de todos, es uno de los más aceptados a nivel general por las empresas, ya que implementa una gran cantidad de protocolos smsc de manera correcta, por ser suficientemente estable en condiciones de producción, y por ser Open Source, lo que implica que es un proyecto constantemente actualizado y con un buen control de calidad, ya que la cantidad de desarrolladores y usuarios es alta, y todos están en constante comunicación.(tabla 2.1) 9

17 CAPÍTULO 2. ANÁLISIS DE TECNOLOGÍAS 10 Plataforma El primer punto a explorar es la integración con Java, es decir que un producto esté preparado naturalmente para interactuar con Java o no; en este caso, Kannel no lo está. De ahi nace la necesidad de crear un gateway entre el protocolo nativo de Kannel y Java, para dicho efecto, es necesaria la implementación de un API que pueda descifrar y codificar dicho protocolo. J2SE es la versión estándard de java, que cuenta únicamente con las herramientas para que un programa use la máquina virtual (JVM). Comunicación entre aplicaciones/componentes Éste es un punto clave en el diseño de un producto SMS, ya que de ello depende en gran medida la flexibilidad que pueda llegar a tener una aplicación soportada por éste. Actualmente, el modelo más popular por su facilidad de implementación es HTTP, que padece de los problemas descritos en el capítulo 1. Un método que aún no ha sido explotado por completo, y que resuelve muchos de los problemas presentados por HTTP son las colas de mensajes (MQ). Cabe señalar, que para este trabajo, la atención será en particular para el servicio de mensajes de Java (JMS). Open Source El tipo de licencia de un producto es importante por que de éste depende el alcance del proyecto y el costo. En nuestro caso, Kannel usa una licencia tipo BSD que no restringe ni el tipo de uso del software ni del código fuente del mismo, siempre y cuando se conserve dicha licencia, a diferencia de otros productos que son caros y de accesso restringido al código fuente para desarrollo experimental.

18 CAPÍTULO 2. ANÁLISIS DE TECNOLOGÍAS 11 J2SE J2EE JMS HTTP WebService OpenSource Dist. Sist.Oper. Kannel X Tipo BSD X Multi Provato NCL X X X X X No X Multi Now SMS X No Windows Donald X No X Windows EMS X X X X X No X Multi Tabla 2.1: Relación entre algunos productos similares a Kannel, tecnologías y otras características relevantes 2.2. Protocolo de intercambio de información y control en Kannel Para lograr comunicar cada módulo, Kannel implementa un sencillo protocolo de propósito especifico basado en estructuras (struct) de C (Ver A.1). Para realizar un análisis de este protocolo, primero fue necesario descifrarlo, para generar una especificación del mismo (Apéndice A) Método de desciframiento El problema para usar el mismo protocolo que Kannel usa, radica en que no existe documentacion del mismo, nadie más que él que lo desarrolló sabe exactamente cómo es que éste de hecho funciona. Entonces, el siguiente paso fue preguntar en la lista de desarrolladores, pero al hacerlo nadie pudo responder con un docuemnto detallado al respecto y sugirieron investigarlo en el código fuente de Kannel. Ingeniería inversa con código fuente Para descifrar el protocolo usando el código fuente, hubo que ir rastreando y corriendo el código a mano hasta hallar los archivos y líneas que manejan en primer lugar la representación de los datos, lo cual fue encontrado en los archivos msg.c, msg.h y

19 CAPÍTULO 2. ANÁLISIS DE TECNOLOGÍAS 12 msg-decl.h. Una vez hallados estos archivos hubo que ejecutar el preprocesador de C para llegar a una definición de estructuras de C entendible por el programador promedio (Ver A.1). Ingeniería inversa con sniffer Para observar en realidad como es que se comportan los paquetes del protocolo en el medio usando un sniffer (Figura 2.1), lo primero que debe hacerse es identificar un paquete correspondiente al protocolo, en este caso se observa el primer paquete enviado por un smsbox al iniciar una sesión con el bearerbox : 0 x a c397 7 f E.. Dy.@.@... 0 x f a4 1 a0b 1 c28 15 c3 1 c80 99 e0...(... 0 x fff 9 bb a cda... l. 0 x cda c l... 0 x0040 ffff ffff... Los primeros 20 bytes corresponden al encabezado IP: a c397 7 f f Los siguientes 32 bytes, corresponden al encabezado TCP: 80 a4 1 a0b 1 c28 15 c3 1 c80 99 e fff 9 bb a cda cda Y finalmente los ultimos 16 bytes, corresponden al paquete de identificación de Kannel : c ffff ffff

20 CAPÍTULO 2. ANÁLISIS DE TECNOLOGÍAS 13 Figura 2.1: Paquete de identificación de un smsbox a un bearerbox desplegados en una ventana de ethereal Donde, los primeros 4 bytes, corresponden al tamaño del paquete: c = 13 Los siguientes 4 bytes, corresponden al tipo de paquete: = 1 = admin Los siguientes 4 bytes, corresponden al comando solicitado: = 3 = Identification Y los 4 bytes restantes al identificador interno del smsbox Descripción General del protocolo Este protocolo mantiene conectados dos módulos de kannel entre sí, permitiendo la transferencia de datos y paquetes entre ellos.

21 CAPÍTULO 2. ANÁLISIS DE TECNOLOGÍAS 14 Una sesión es iniciada cuando un módulo cliente solicita conectarse al bearerbox enviando un comando administrativo que solicita ser identificado. La misma es terminada cuando el bearerbox solicita al cliente ser apagado o reiniciado. Durante la sesión, ambas partes pueden enviar latidos (heartbeats) entre sí para indicar a la otra parte que el enlace está activo y la aplicación esta viva. En una sesión con uns smsbox cuando un smsbox ha establecido una sesión, puede enviar y recibir packetes tipo SMS. En una sesión con un wapbox cuando un smsbox ha establecido una sesión, puede enviar y recibir datagramas WDP (Wireless Datagram Protocol). Nota: Para mayores detalles sobre el protocolo ver el apéndice A Análisis del protocolo La intención original, fue hacer una especificación del protocolo que usa Kannel, pero después de descifrarlo y estudiarlo, he creído que no es apropiado nombrarle especificación, sino nombrarle descripción (Apéndice A), ya que la única instancia del protocolo se encuentra implícita dentro del código fuente, sin una estructura clara del mismo que pudiera fácilmente ser descrita usando pseudocódigo. Seguridad El protcolo no soporta actualmente mecanismos formales de autenticación más que por medio de la dirección IP, pero este tipo de autenticación no forma parte del protocolo, sino de la implementación. Otra forma en la que puede autenticarse una conexión por medio de este protocolo es mediante el uso de tecnologías como SSL (Secure Socket Layer s), pero éste sigue estando fuera de los verdaderos alcances del protocolo y es también un factor de implementación.

22 CAPÍTULO 2. ANÁLISIS DE TECNOLOGÍAS 15 Desempeño El planteamiento estructural del protocolo es apropiado, pero está implementado usando tipos de datos nativos de C, lo cual hace que la cantidad de información transmitida sea tan excesiva, que algunos paquetes llegan a ser casi 3 veces más grandes de lo que realmente necesitan ser. Tomemos por ejemplo, el paquete de la sección 2.2.1: c ffff ffff Si lo agrupamos por campos, c ffffffff ^------^ ^------^ ^------^ ^------^ Longitud Tipo Comando ID podemos ver que dado el tipo de aplicación: La longitud, nunca llegará a ser mayor a unos cuantos cientos de bytes, para los casos más extremos, siendo el promedio de unos cuantos cientos de bytes, por lo que el uso de un entero con signo de 4 bytes es excesivo, el uso de un entero con signo de 2 bytes, estaría muy holgado en este campo. Los tipos de paquetes actualmente definidos son 5, por lo que 3 bits, serían suficientes, el problema en dicho caso, sería la necesidad del uso de bits de relleno para transmitirlo con facilidad; por esto, sería conveniente la asignación de 4 bits (medio byte) para dicho campo, lo cual nos daría una buena holgura para siguientes diseños basados en este protocolo. Comando, la situación es la misma que la anterior. Si para este caso asignáramos otra vez 4 bits, podríamos fusionar el campo anterior con este para tener un byte completo para ambos campos.

23 CAPÍTULO 2. ANÁLISIS DE TECNOLOGÍAS 16 ID, se refiere al identificador del cliente que se conecta al bearerbox. Para éste tenemos que el número real de clientes que tendría el bearerbox raramente sería mayor a una docena, pero si suponemos que todos los servicios SMS del mundo fueran a concentrarse a través de un bearerbox, y que cada país necesitara 10 clientes bearerbox para satisfacer la demanda (ambos casos excesivos), tomando en cuenta el conteo actual (2004) de países miembors de la ONU (para tener un número más o menos estable), tendríamos la necesidad de asignar = 1910 identificadores lo cual puede hacerse en con 11 bits; si esta cantidad la redondeamos a 16 bits, para tener un identificador de 2 bytes, tendríamos espacio para asignar identidicadores, mucho más que lo que hace un momento creíamos suficiente. Tomando en cuenta estos cálculos, podríamos mejorar esto: c ffff ffff en esto : 000 c 13 ffff una formación optimizada del paquete, de 5 bytes contra 16 bytes. Después de analizar este protocolo, es fácil notar que es mejorable en muchos aspectos, pero a pesar de todo puede ser usado para nuestros propósitos, con mínimas o ninguna adaptación tanto del bearerbox como del protocolo.

24 Capítulo 3 Arquitectura Este sistema de manera global presenta cuatro módulos: bearerbox de Kannel, kj- Gateway, Java Message Service y aplicación de servicio (Ver figura 3.1). bearerbox Este es el módulo de kannel que se conecta a una central de sms (SMSC), es la parte básica de un ESME (External Short Message Entity). Es el nivel más bajo de conexión que concede un proveedor de servicios de texto en telefonía celular para agregadores de servicio. El protocolo más popular para este efecto es SMPP mismo que ha sido elegido para realizar las pruebas. kjgateway Este es el módulo principal. Es un intermediario entre kannel y JMS. Al integrarse con JMS, características como persistencia y transacciones pueden ser fácilmente configuradas. Éste se comunica con el bearerbox usando el protocolo interno de Kannel, mismo que fue decodificado e implementado en Java para la realización de este proyecto. En la figura 3.2 podemos ver de modo un poco más detallado los módulos internos de kjgateway. 17

25 CAPÍTULO 3. ARQUITECTURA 18 Teléfono Móvil Red de Telefonía Celular bearerbox kjgateway Java Message Service Servicio 1 Servicio n Figura 3.1: Modo en que cada componente se conecta en un sistema sms gateway basado en JMS

26 CAPÍTULO 3. ARQUITECTURA 19 Flujo de entrada bearerbox Flujo de salida Flujo de salida kjgateway Flujo de entrada KjWriting Thread ack Thread KjReading Thread JMS Transfer Flujo de salida Flujo de entrada Flujo de entrada Java Message Service Flujo de salida Figura 3.2: Arquitectura de kjgateway

27 CAPÍTULO 3. ARQUITECTURA 20 Para detallar el diseño de este módulo, podemos observar en el diagrama de la figura 3.3 cómo es que las clases y objetos que modelan este componente se relacionan. La clase principal desde el punto de vista del gateway es la clase KannelJMSGateway, que instancía a las clases KjWritingThread, KjReadingThread, AckCycleThread, KannelBinding y una implementación de la clase JMSTransport que es cargada de manera dinámica como se le indique desde un Objeto Properties. kjreadingthread Esta clase es un subproceso o hilo encargado de leer mensajes entrantes del bearerbox usando la conexión especificada por KannelBinding. Este thread hace una lectura que se bloquea hasta que recibe un mensaje completo; al desbloquearse, si el mensaje es válido, lo procesa de acuerdo a su tipo: 1. SMS - Llama a un método de la interfase JMSTransport para indicarle que un nuevo mensaje ha llegado. 2. ACK - Llama a un método de la clase AckCycleThread para indicarle que se ha recibido la confirmación de un mensaje enviado anteriomente. 3. Otros - Son ignorados ya que el prototipo no los requiere para la etapa de pruebas. JMSTransport Esta interfase está diseñada para intercambiar mensajes entre JMS y Kannel (Figura 3.4). Contiene los prototipos de los métodos: gotmomessage, gotmtmessage, addkjwritingthread y start. gotmomessage - este método es llamado por kjreadingthread para notificar que ha recibido un mensaje originado en la red de telefonía, típicamente un teléfono celular.

28 CAPÍTULO 3. ARQUITECTURA 21 Figura 3.3: Diagrama de clases de kjgateway

29 CAPÍTULO 3. ARQUITECTURA 22 jmstransport K a n n e l Flujo de entrada Flujo de salida Kannel to JMS Converter JMS to Kannel Converter JMS Publisher JMS Subscriber J M S P r o v i d e r Figura 3.4: Funcionamiento de jmstransport gotmtmessage (uso futuro) - La semántica de este método se refiere a las acciones a llevar a cabo cuando un mensaje con destino a la red de telefonía ha llegado al sistema. addkjwritingthread - Agrega un objeto de la clase KjWritingThread al objeto actual, para permitirle enviar mensajes a la red de telefonía celular. start inicializa un objeto de esta clase tomando las propiedades que recibe como parámetro. Típicamente, este método implementará los mecanismos necesarios para permitir que las funciones básicas del mismo estén vigentes. kjwritingthread Este subproceso se encarga de escribir mensajes para el bearerbox, ya sea de contenido o de control. Cuando envía un mensaje de contenido, manda una copia del mismo mensaje al AckCycleThread en espera de una confirmación de entrega. El principal

30 CAPÍTULO 3. ARQUITECTURA 23 Figura 3.5: Diagrama de clase de kjwritingthread método que implementa esta clase es send. Esta clase (Figura 3.5) puede funcionar en forma de hilo y en forma de objeto normal, la diferencia es que cuando funciona como thread, se usa el método sendonthread para enviar mensajes. Al llamar a este método, los mensajes se agregan a una lista ligada (LinkedList) que funciona como un buffer y se intentan enviar los mensajes de la cola en un ciclo que se repite en un lapso de tiempo determinado. En el caso contrario, los mensajes son enviados tan pronto como sea posible, bloqueando el método hasta que se logre enviar el mensaje; esto significa que si existe previamente un buffer para escribir, el método podría bloquearse indefinidamente. AckCycleThread Esta clase es un subproceso que administra el reenvío de mensajes, y su tiempo de vida dentro de la aplicación, es decir, cuanto tiempo hay que esperar antes de reenviar un mensaje o si se ha recibido una confirmación de su entrega. Cada vez que un mensaje es enviado, esta clase es notificada en espera de un acuse de recibo (acknowledge) de la parte receptora, en caso de no recibir tal mensaje en un periodo determinado de tiempo, intentará reenviar dicho mensaje nuevamente hasta

31 CAPÍTULO 3. ARQUITECTURA 24 Figura 3.6: Diagrama de clase de AckCycleThread expirar su tiempo de vida o hasta recibir dicha respuesta. Figura 3.6. Sus principales métodos son waitack y confirmack. waitack recibe un mensaje de texto para el que hay que esperar un acknowledge. confirmack recibe un acknowledge que en caso de coincidir con un mensaje, confirmará su recepción. El funcionamiento de esta clase está basado en un Hashtable que contiene los mensajes indexados usando su correspondiente UUID, cuya confirmación es esperada. La llamada de waitack agrega una entrada en dicho Hashtable y la llamada de confirmack lo elimina. Cada determinado lapso de tiempo (frecuency) se intentan reenviar los mensajes aún contenidos en el Hashtable. kjprotocol API Las conexiones con Kannel usan una implementación de un protocolo de bajo nivel

32 CAPÍTULO 3. ARQUITECTURA 25 creado por los primeros desarrolladores de Kannel, a ésta se le ha llamado kjprotocol. Contiene las clases esenciales (Figura 3.7) para leer y escribir mensajes del mismo modo que lo hacen los módulos de Kannel, permitiendo así el desarrollo de componentes compatibles con Kannel bajo Java. BasicPacket Esta clase 3.8 hereda los atributos length y type para los demás tipos de paquetes, de modo que los métodos que requieran saber el tipo o longitud de un mensaje, puedan hacerlo sin tener que escribir un método sobrecargado para cada tipo de paquete existente. BasicKannelProtocolMessage Esta interfase especifica los métodos getmessage y setmessage que son usados por métodos que leen o escriben paquetes de un flujo de datos conectado con un módulo de kannel, en este caso con un bearer box. Aplicación de servicio Son módulos que se conectan usando JMS como protocolo de conexión para intercambiar mensajes SMS entre la aplicación o servicio y los clientes de la red de telefonía. Algunos ejemplos de servicios que pueden ser ofrecidos son los micro pagos por servicios materiales o la venta de contenido de personalización para celulares. En el capítulo 4.3 se presenta de manera más detallada el diseño e implementación de una aplicación de servicio de ejemplo. Conclusión En este capítulo, hemos mostrado de modo general como es que los principales módulos están relacionados con las clases que fueron implementadas