Sistema de mensajería WAP. WAP messaging system. Deivis Ricardo Álvarez Mendoza 1, Joan Martínez Herrera 2

Transcripción

1 Serie Científica de la Universidad de las Ciencias Informáticas No. 9, Vol. 4, Año: 2011 ISSN: RNPS: Tipo de artículo: Artículo original Temática: Telecomunicaciones Recibido: 25/05/2011 Aceptado: 28/09/2011 Publicado: 29/09/2011 Sistema de mensajería WAP WAP messaging system Deivis Ricardo Álvarez Mendoza 1, Joan Martínez Herrera 2 1 Departamento de Ingeniería de Software. Facultad 2. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, CP Departamento de Telecomunicaciones. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, CP {dalvarezm, jherrera}@uci.cu Resumen Los sistemas digitales de radiocomunicaciones móviles proveen soluciones de radiotelefonía privada y ofrecen servicios a un grupo cerrado de usuarios. Generalmente son usados como apoyo a la gestión de procesos críticos dentro de un país o área determinada. Un ejemplo de ello son los servicios a organismos como policías, bomberos, forestales entre otros. TETRA es el estándar abierto digital de radiocomunicaciones móviles elaborado por el ETSI. En el presente artículo se realiza una breve descripción sobre el Protocolo de Aplicaciones Inalámbricas, describiendo las principales características del mismo y aspectos sobre la investigación realizada para la inclusión de mensajes WAP (tanto mensajes WAP Push como mensajes WAP Continuous Provisioning). Estos serán utilizados con el objetivo de enviar datos a los agentes de campo a través de la infraestructura de red TETRA. Además se explica la creación de un sistema web para el envío de los mencionados mensajes. Palabras clave: WAP push, WAP continuous provisioning, WBXML, spring, web services, java RMI. Abstract The digital systems of mobile telecommunications provide solutions of private radiotelephony and offer services to a closed group of users. These systems are mostly used as support to the management of critical processes within a country or determined area. Examples are services to organisms like police, firefighters and foresters among others. TETRA is the digital open standard of mobile radio-communications made by

2 the ETSI. In the present paper a brief description is made about the Wireless Application Protocol, describing its main features and aspects about an investigation realized to the inclutionos WAP Messages (WAP Push and WAP Continuous Provisioning). These messages would be used to send data to filed agents through the TETRA network infrastructure. Besides it is explained the creation of a web system to send the mentioned messages. Keywords: WAP push, WAP continuous provisioning, WBXML, spring, web services, java RMI. Introducción Durante la última década las radiocomunicaciones se han visto influenciadas grandemente por los servicios de datos que se brindan en las redes celulares. El uso de la navegación web ha revolucionado la forma en que se valoran los servicios de un proveedor. Es por ello que empresas de gran prestigio a nivel internacional desean integrar soluciones que puedan brindar acceso a datos que puedan dar respuesta a determinadas necesidades de sus clientes, como son policías, bomberos, guardias forestales, agentes de orden público, etc. La Universidad de las Ciencias Informáticas (UCI) en coordinación con la empresa Teltronic S.A. ha desarrollado un servidor de aplicaciones WAP (del inglés, Wireless Application Protocol) para brindar servicios de datos mediante el uso de este protocolo. Con el mismo se brinda una solución que permite la gestión de la información vía WAP como parte de la infraestructura de red que proveen denominada TETRA (del inglés, Terrestial Trunked Radio) NEBULA. Para ello fue necesario el desarrollo de varios componentes entre ellos la implementación de un API (del inglés, Application Program Interface) que pudiera ser utilizada por los programadores para el envío de mensajes WAP Push, tecnología que se utiliza para el envío de avisos a los terminales. Por otra parte La web o WWW (del inglés, World Wide Web) se puede calificar sin duda alguna como el componente fundamental de las TIC (Tecnologías de la Informática y las Telecomunicaciones) que ha revolucionado y popularizado el uso de Internet, gracias a ser un medio de difusión y comunicación abierto, flexible y de tecnología muy simple, lo cual ha dado origen a un amplio espectro de aplicaciones, dentro de las que se destacan las aplicaciones o portales web. Este tipo de software es muy popular debido a lo práctico del navegador web como cliente ligero, así como a la facilidad para actualizar y mantener la información almacenada en bases de datos sin distribuir e instalar software a miles de usuarios potenciales. Es por ello que el API desarrollada se ha vinculado con un sistema web, encargado de proporcionar los datos necesarios para enviar los mensajes para los cuales ha sido diseñado el API. Desarrollo Mensajes Wap Push 2

3 El modelo de envío de mensajes de tipo Push a través del protocolo WAP está basado en el modelo Cliente/Servidor, pero en el cual no existe una solicitud específica para la misma por parte del cliente antes del proceso de envío de información desde el servidor. Estos mensajes pueden ser codificados de manera que pueda ser más eficiente el envío de los mismos a través de la infraestructura correspondiente (WAP-250-PushArchOverview, 1999). Para el desarrollo de la presente API la codificación se convirtió, no tanto en una posible opción, sino en una necesidad debido al poco ancho de banda presente en la infraestructura de red TETRA. Tipos De Wap Push Existen 3 clasificaciones para estos mensajes que pueden ser Service Indication (SI), Service Loading (SL) y Cache Operation (CO). Service Indication Los mensajes de tipo Service Indication (SI) proveen un mecanismo asíncrono para el envío de notificaciones al terminal. Estos mensajes contienen un pequeño texto para el usuario del terminal, así como una URI mediante la cual se puede acceder a un servicio y es responsabilidad del usuario decidir si visitar el servicio que se ha enviado en el momento que llega el mensaje o en otro instante (WAP-167-ServiceInd, 1999). En el siguiente ejemplo se muestra un mensaje de tipo SI. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN" " <si> <indication href=" created=" t11:04:00z" siexpires=" t11:04:00z" action="signal-low">soluciones TETRA</indication> </si> Ejemplo 1. XML correspondiente a mensaje SI. Service Loading En contraste con los mensajes de tipo SI los Service Loading (SL) no requieren acciones por parte de los usuarios. Estos mensajes contienen una URI mediante la cual se puede acceder al servicio que puede ser cargado sin la confirmación del usuario final. El contenido puede ser ejecutado o cargado en la memoria caché del navegador utilizado en el dispositivo móvil. Si el contenido debe ser ejecutado entonces puede controlarse el grado de intrusión que tendrá el mismo (WAP-168-ServiceLoad, 1999). En el siguiente ejemplo se muestra un mensaje de tipo SL. 3

4 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN" " <sl href=" action="execute-low"></sl> Ejemplo 2. XML correspondiente a mensaje SL. Cache Operation(CO) Mediante un mensaje del tipo Cache Operation (CO) se provee de un medio para invalidar objetos específicos o todos los objetos que comparten el mismo prefijo de una URI dada, de la memoria caché del navegador del cliente. Esta característica es útil cuando el tiempo de expiración del contenido guardado en la caché no puede ser determinado con antelación (por ejemplo las vistas de un correo electrónico) y los contenidos cambian con más rapidez que lo que el cliente los accede. (WAP-175-CacheOp, 1999) En el siguiente ejemplo se muestra un mensaje de tipo CO. <?xml version="1.0"?> <!DOCTYPE co PUBLIC "-//WAPFORUM//DTD CO 1.0//EN" " <co> <invalidate-object uri="portalwap.jsp"></invalidate-object> <invalidate-service uri=" </co> Ejemplo 3. XML correspondiente a mensaje CO. Wap Continuous Provisioning Consisten en un mecanismo que utiliza la pila de protocolos WAP, mediante el cual los proveedores ofrecen información, servicios y configuración a los dispositivos. Este mecanismo tiene como característica fundamental que ha sido diseñado para ser extensible, y permite modificar características y agregar funcionalidades a los terminales móviles (Grosso, 2001). Dentro de las características del WAP Continuous Provisioning cabe destacar que el mismo se puede ejecutar sin importar el software del dispositivo. Además se debe señalar que este mecanismo puede ser habilitado por operaciones de cautela del proveedor, acontecimientos inteligentes de la red o petición mediante voz o datos del usuario. Un requisito para poder establecer el mecanismo es que el dispositivo debe estar encendido, de lo contrario el mismo no 4

5 funcionará. La información que podría actualizarse puede ser una o varias combinaciones de las siguientes (Grosso, 2001): Información de conectividad. Selección del proveedor de servicios. Configuración del proxy y el DNS (del inglés, Domain Name Server). Información para acceder a distintas aplicaciones. Configuraciones en el navegador. En el ejemplo 4 se muestra un mensaje WAP Continuous Provisioning mediante el cual se modifica la página de inicio de un navegador (Grosso, 2001). <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN" " <wap-provisioningdoc encoding = 1.0 > <characteristic type="pxlogical"> <parm name="startpage" value=" </characteristic> </wap-provisioningdoc> Ejemplo 4. Mensaje WAP Continuous Provisioning en formato XML. Codificación de los mensajes WAP Los mensajes WAP Push pueden ser codificados para optimizar su envío a través de la infraestructura utilizada y para lograr una mayor rapidez y eficiencia a la hora de ser enviados y recibidos pues con los mensajes de una gran cantidad de caracteres pueden reducirse inclusive hasta la mitad de su tamaño, evitando con esto el engorroso proceso de segmentación, que puede incurrir inclusive en la pérdida de un mensaje y por consiguiente la pérdida del mensaje en su totalidad al no poder ser reensamblado en el terminal (WAP-167-ServiceInd, 1999; WAP-168- ServiceLoad, 1999; WAP-175-CacheOp, 1999). En el caso de las redes TETRA debido a las restricciones presentes en la infraestructura, la codificación se convirtió más en una obligación que en una opción. Por esta razón el API cuenta con un mecanismo de codificación para luego de conformado el XML (del inglés, extensive Markup Language) codificarlo a su forma en WBXML (del inglés, Wireless Binary XML). 5

6 Encabezados de los mensajes WAP Push Los mensajes WAP Push pueden ser codificados para optimizar su envío a través de la infraestructura utilizada y para lograr una mayor rapidez y eficiencia a la hora de ser enviados y recibidos pues con los mensajes de una gran cantidad de caracteres pueden reducirse inclusive hasta la mitad de su tamaño, evitando con esto el engorroso proceso de segmentación, que puede incurrir inclusive en la pérdida de un mensaje y por consiguiente la pérdida del mensaje en su totalidad al no poder ser reensamblado en el terminal. (WAP-167-ServiceInd, 1999, (WAP-168- ServiceLoad, 1999; WAP-175-CacheOp, 1999). En el caso de las redes TETRA debido a las restricciones presentes en la infraestructura, la codificación se convirtió más en una obligación que en una opción. Por esta razón el API cuenta con un mecanismo de codificación para luego de conformado el XML (del inglés, extensive Markup Language) codificarlo a su forma en WBXML (del inglés, Wireless Binary XML). Encabezado Wireless Datagram Protocol (WDP) El protocolo WDP opera en la capa superior de los servicios portadores de datos brindados por los diferentes tipos de redes inalámbricas existentes. WDP ofrece un servicio consistente a las capas superiores del protocolo WAP y funciona independientemente del tipo de portador disponible en la red. En la siguiente imagen se muestra donde se ubica WDP dentro de una infraestructura genérica (WAP-259-WDP a, 1999). Figura 1. WDP arquitectura general. Encabezado Wireless Session Protocol (WSP) Wireless Session Protocol (WSP, por sus siglas en inglés) es un protocolo optimizado para llevar peticiones y res- 6

7 puestas Hyper Text Transfer Protocol (HTTP, por sus siglas en inglés). Como sucede con el WBXML la principal función de WSP es la compresión de estas peticiones y respuestas HTTP y los encabezados HTTP. Esta característica es importante para este desarrollo puesto que los mensajes WAP Push incluyen los encabezados HTTP Content-Type y Content-Size. Adicionalmente pueden enviarse encabezados específicos de WAP, de los cuales se utilizan en este caso el destinado para WAP Push. Según la siguiente imagen el encabezado WSP para WAP Push toma la siguiente forma para la parte de los encabezados (headers) sin contar el identificativo de la transacción (Push ID): (WAP-203- WSP a, 1999). Figura 2. Campos para Push y Confirmed Push. Servicios web Los servicios web tienen una gran complejidad y pueden ser definidos como un conjunto de aplicaciones o de tecnologías con capacidad para inter-operar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer una serie de servicios. No cuentan con una interfaz gráfica con la que las personas puedan interactuar, sino que son software accesible en Internet por otras aplicaciones. De esta forma se pueden desarrollar aplicaciones que hagan uso de otras aplicaciones que estén disponibles en Internet interactuando con ellas (Guía Breve de Servicios Web, 2005). Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar (Guía Breve de Servicios Web, 2005). El siguiente gráfico muestra cómo interactúa un conjunto de servicios web: 7

8 Figura 3. Funcionamiento de un servicio web. En todo este proceso intervienen una serie de tecnologías que hacen posible esta circulación de información. Por un lado, estaría SOAP (Protocolo Simple de Acceso a Objetos). Se trata de un protocolo basado en XML, que permite la interacción entre varios dispositivos y que tiene la capacidad de transmitir información compleja. Los datos pueden ser transmitidos a través de HTTP, SMTP, etc. SOAP especifica el formato de los mensajes. El mensaje SOAP está compuesto por un envelope (sobre), cuya estructura está formada por los siguientes elementos: header (cabecera) y body (cuerpo) (Guía Breve de Servicios Web, 2005). Los principales elementos a tener en cuenta para la implementación de los servicios web son: (Guía Breve de Servicios Web, 2005). SOAP (Simple Object Access Protocol). UDDI (Universal Description, Discovery and Integration). WSDL (Simple Object Access Protocol). SOAP es un protocolo de mensajería XML extensible que forma la base de los Servicios Web proporcionando un mecanismo simple y consistente que permite a una aplicación enviar mensajes XML a otra aplicación. Un mensaje SOAP es una transmisión de una vía desde un emisor SOAP a un receptor SOAP, y cualquier aplicación puede participar en este intercambio como emisor o receptor, además de ser completamente independiente del protocolo de transporte subyacente (Guía Breve de Servicios Web, 2005). WSDL es un fichero XML usado para describir la interfaz de un Servicio Web como un conjunto de puntos finales de comunicación (métodos) capaces de intercambiar mensajes (es decir recibir llamadas con sus parámetros correspondientes y generar respuesta con el resultado que le corresponda). Proporciona toda la información necesaria para 8

9 acceder y utilizar un Servicio Web. Un documento WSDL describe qué hace el Servicio web, cómo se comunica, y dónde reside (Guía Breve de Servicios Web, 2005). UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros (Guía Breve de Servicios Web, 2005). Los servicios web presentan una amplia gama de ventajas que los convierten en herramientas muy usadas a nivel global. Son independientes del lenguaje de programación que se utilice y de la plataforma sobre la que se desarrollen. Permiten la reusabilidad de servicios, interoperabilidad entre aplicaciones (Guía Breve de Servicios Web, 2005). Invocación de métodos remotos (RMI) Es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y provee de un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java (Grosso, 2001). RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia, recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (Grosso, 2001). Por medio de RMI, un programa Java puede exportar un objeto, lo que significa que éste queda accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de este momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto. La invocación se compone de los siguientes pasos: (Grosso, 2001). Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java). Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta. Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente. El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local. Marco de trabajo (framework) spring Es spring es un framework de código abierto de desarrollo de aplicaciones para la plataforma Java. A pesar de que spring framework no obliga a usar un modelo de programación en particular, se ha popularizado considerándosele una alternativa al modelo de Enterprise JavaBeans. Por su diseño el framework ofrece mucha libertad a los desarrolladores en Java y soluciones muy bien documentadas y fáciles de usar para las prácticas comunes en la industria. Las características de éste pueden emplearse en cualquier aplicación hecha en Java. Spring es el más popular y de los más ambiciosos de los frameworks de peso ligero. Interviene en todas las capas arquitectónicas de una 9

10 aplicación Java, Enterprise Edition (JEE, por sus siglas en inglés). Además está diseñado para facilitar una flexibilidad arquitectónica. Presenta varias características, algunas de las cuales son: Contenedor de Inversión de Control: Permite una sofisticada administración de configuración para POJOs (del inglés, Plain Old Java Object) y trabaja con otros componentes de spring para proveer servicios como la administración de configuración. Una abstracción de acceso a datos: Spring anima a un consistente acercamiento arquitectónico para acceso a datos, y posee una abstracción única y poderosa para implementarlo. Presenta una rica jerarquía de excepciones de acceso a datos, independientemente de cualquier framework de persistencia en particular. Simplificación de JDBC: Presenta una capa de abstracción sobre Java Database Connectivity (JDBC, por sus siglas en inglés) que es significativamente mucho más simple y menos propensa a errores para usar que JDBC puro cuando se necesita usar acceso a través de SQL a base de datos relacionales. Es un framework contenedor liviano basado en la técnica Inversión de Control (IoC) y una implementación de desarrollo según el paradigma de Orientación a Aspectos (AOP). Propuesta del sistema El sistema fue implementado siguiendo el patrón de diseño modelo-vista-controladora. Aunque el sistema de codificación de mensajes WAP fue desarrollado siguiendo una arquitectura de tipo monolítica. Esta arquitectura la cual plantea el diseño del software mediante la creación de una estructura única, la cual no tiene interfaz y corresponde a una parte de un sistema, generalmente en la implementación de un proceso de negocio. Por las características de la propuesta de solución es que se utiliza esta arquitectura como base (Figura 4) y es fácilmente acoplable al sistema web al ser incluido dentro del sistema de acceso a datos. En la Figura 5 se puede realizar una mejor comprensión de la arquitectura del software. 10

11 Figura 4. Arquitectura Monolítica. Figura 5. Vista Arquitectónica del Sistema. La capa Presentación o Vista es la encargada de mostrar la interfaz de usuario y en ella los elementos necesarios para la interacción con el software, por lo general está constituida por elementos HTML. La capa Controladora se responsabiliza de responder a los eventos originados por el usuario, por ejemplo si se realizó una acción sobre un botón, sobre un enlace o algún otro elemento de la vista que genere una petición al servidor. La capa de Acceso a Datos o Modelo es la responsable de gestionar la información almacenada en la base de datos, en la misma se encuentran tres clases que la conforman, la clase JDBC que se encarga de acceder utilizando un objeto JDBCConection, la clase RMI se encarga de realiza la invocación de un método de forma remota a otro servidor donde este publicado este servicio y la clase Servicios Web (Web Service) que se encarga de consumir un servicio web publicado en un servidor remoto. El sistema al ser desplegado la persona encargada de esta acción a través de un fichero de configuración especificará la forma de acceder a la información. De forma vertical se encuentran las clases de Dominio, Seguridad y Excepciones. Las clases dominio son las entidades que maneja el sistema, la clases de seguridad brinda este servicio a cada una de las capas, de igual forma las clases de excepción manejan los errores detectados y los almacena en ficheros para posterior análisis. 11

12 Puesto que el Portal va a estar de cara a internet se hizo necesario la implementación de una capa de seguridad para la protección y el acceso de personas autorizadas al sistema, para llevar a cabo dicho trabajo de utilizó el módulo Spring-Security o Acegi-Security como era conocido anteriormente. La seguridad se estableció a nivel de roles con funcionalidades asociada a estos. Cada petición al servidor es interceptada y verificada su nivel de acceso y en dependencia del resultado tiene acceso o no. Resultados y Discusión La introducción de un sistema de envío de mensajes dentro de una red TETRA presupone una mejora considerable a los servicios que se proveen dentro de ella. Algunos de estos resultados son: Fue desarrollado un sistema capaz de enviar los 3 tipos de mensajes WAP mencionados anteriormente. El sistema es capaz además de codificar los mensajes a su formato binario (entiéndase WBXML). El sistema fue desarrollado completamente sobre tecnologías libres por lo puede ser utilizado en cualquier otro sistema que necesite de estos mensajes con el único requisito de que el mismo cuente con una instancia de la máquina virtual de Java. Los mensajes codificados y enviados al terminal son visualizados correctamente. Al ser presionado el texto que se muestra cuando se envía un mensaje tipo Service Indication se accede a la URL contenida en el mismo. Al ser enviado un mensaje de tipo Service Loading, se carga correctamente el navegador accediendo a la URL contenida en el mismo. Al ser enviado un mensaje de tipo Cache Operation se modifican los objetos contenidos en la memoria caché del navegador. Al enviar un mensaje WAP Continuous Provisioning se aprecian modificaciones en la página de inicio del navegador WAP. Conclusiones Mediante el uso de este sistema se podrá hacer llegar a los clientes informaciones ubicadas en la web de manera automática para puedan acceder directamente a la misma, es decir sin tener que teclear la URL, eli- 12

13 minando toda la dificultad que esto puede conllevar pues los teclados de los terminales son muy limitados. Además en el caso de que en el sistema exista una información muy urgente pues puede enviarse, mediante el uso de un mensaje de tipo Service Loading, para que ni tan siquiera tenga que revisar su bandeja de entrada y vaya directamente a la URL que se desea que visite. No obstante, la principal importancia del presente API radica en que la tecnología WAP Push es prácticamente nueva en las redes de tipo TETRA, por lo que con su uso se incluirá un nuevo servicio dentro de estas redes. Referencias WAP-250-PushArchOverview a: WAP Push Architectural Overview, WAP Forum, Disponible en: [ WAP-167-ServiceInd a: Wireless Application Protocol: Service Indication, WAP Forum, Disponible en: [ WAP-168-ServiceLoad a: Wireless Application Protocol: Service Indication, WAP Forum, Disponible en: [ WAP-175-CacheOp a: Wireless Application Protocol: Cache Operation, WAP Forum, Disponible en: [ WAP-259-WDP a: Wireless Application Protocol: Wireless Datagram Protocol, WAP Forum, Disponible en: [ WAP-203-WSP a: Wireless Application Protocol: Wireless Session Protocol Specification, WAP Forum, Disponible en: [ Guía Breve de Servicios Web. World Wide Web Consortium, Disponible en: [ W. GROSSO, Java RMI, O'Reilly, First Edition October 2001, ISBN: