Repositorio Institucional de Documentos

UNIVERSIDAD DE ZARAGOZA Centro Politécnico Superior PROYECTO FIN DE CARRERA Ingeniería Informática Curso 2008/2009 Near Field Communication Application Provisioning Framework Alumno: Andrea Martínez Mazo Director: Jakob Saros – Ericsson AB, Luleå (Sweden) Tutor: Kåre Synnes – Luleå Tekniska Universitet, Luleå (Sweden) Ponente: Francisco Javier Fabra Caro – Universidad de Zaragoza Zaragoza, Septiembre de 2009 NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 1 NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 2 NEAR FIELD COMMUNICATION APPLICATION FRAMEWORK RESUMEN Near Field Communication es una tecnología de comunicación que está ganando adeptos día a día. NFC posee características comunes a la tecnología Bluetooth: ambas son tecnologías de comunicación de corto alcance que funcionan sobre una conexión inalámbrica; aún con todo, NFC posee propiedades con las que aventaja a Bluetooth. Una de las más importantes radica en el tiempo de establecimiento de la conexión, el cual es significativamente menor en la tecnología NFC. Por todo ello, esta Comunicación de Corto Alcance se ha convertido en un medio fácil y seguro de transmisión de información. Su aplicación en el campo de la telefonía móvil abre nuevos caminos a servicios y transacciones de la vida cotidiana, que buscan facilitar y agilizar los procedimientos seguidos en la actualidad. El proyecto con título NFC Application Provisioning Framework busca fomentar el uso de la tecnología descrita. La manera en que se desea conseguir este fin es facilitando un servicio al usuario, el cual le permitirá interaccionar con cualquier etiqueta NFC, incluso cuando éstas, en un principio, no pudieran ser leídas por su teléfono móvil. De esta forma, una única aplicación será la encargada de proveer todo tipo de servicios o aplicaciones requeridas para que un dispositivo móvil pueda comunicarse con dispositivos NFC y llevar a cabo transferencias de información entre ellos. NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 3 NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 4 TABLA DE CONTENIDOS Resumen ........................................................................................................................2 Tabla de contenidos .......................................................................................................4 Tabla de figuras..............................................................................................................6 1. Introducción................................................................................................................8 2. Análisis .....................................................................................................................14 2.1. Estudio previo...............................................................................................14 2.2. Metodología..................................................................................................14 2.3. Requisitos del sistema..................................................................................16 2.4. Escenarios....................................................................................................17 2.5. Diagrama de Casos de Uso..........................................................................17 2.6. Diagramas de actividades.............................................................................19 2.7. Diagrama de Secuencia................................................................................20 2.8. Diagrama de clases......................................................................................21 3. Diseño del sistema ...................................................................................................22 3.1. Arquitectura física.........................................................................................22 3.2. Arquitectura lógica........................................................................................23 3.3. Diseño de la Base de Datos .........................................................................26 3.4. Interfaces de Usuario....................................................................................27 4. Implementación ........................................................................................................28 4.1. fases .............................................................................................................28 4.2. Tecnologías y otros métodos........................................................................29 4.3. Estructura de la implementación...................................................................30 4.4. Tests de usabilidad.......................................................................................33 5. Conclusiones............................................................................................................34 Referencias bibliográficas.............................................................................................36 NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 5 NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 6 TABLA DE FIGURAS Figura 1 – Diagrama Gantt, 1ª parte.............................................................................15 Figura 2 – Diagrama Gantt, 2ª parte.............................................................................15 Figura 3 – Diagrama de Casos de Uso ........................................................................18 Figura 4 – Diagrama de actividades para el CU “GET GCRTD”..................................19 Figura 5 – Diagrama de actividades para el CU “SEARCH SERVICE”........................19 Figura 6 – Activity diagram: Download service.............................................................19 Figura 7 – Diagrama de Secuencia..............................................................................20 Figura 8 – Diagrama de Clases....................................................................................21 Figura 9 – Arquitectura Física del sistema ...................................................................23 Figura 10 – Record Handling Architecture....................................................................25 Figura 11 – Diagrama del modelo de datos..................................................................26 NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 7 NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 8 ABBREVIATIONS AMS Application Management System API Application Programming Interface CDC Connected Device Configuration CLDC Connected Limited Device Configuration CSS Cascade Style Sheets DB DataBase EJB Enterprise JavaBeans GC Generic Control GCF Generic Connection Framework GCRTD Generic Control Record Type Definition GUI Graphic User Interface HTML HyperText Markup Language HTTP HyperText Transfer Protocol IEC International Electrotechnical Commission ISO International Organization for Standardization J2EE Java 2 Platform, Enterprise Edition J2ME Java 2 Platform, Micro Edition JAD Java Application Descriptor JAR Java ARchive File Java EE Java Platform, Enterprise Edition Java ME Java Platform, Micro Edition Java SE Java Platform, Standard Edition JSR Java Specification Requests JVM Java Vistual Machine KB Kilobytes Kbps Kilobits per second KVM Kernel-based Virtual Machine MB Megabytes Mbps Megabits per second MDIP Mobile Information Device Profile MHz Megahertz MIME Multipurpose Internet Mail Extensions NDEF NFC Data Exchange Format NFC Near Field Communication NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 15 Especificaciones completas • Desarrollo e implementación del primer prototipo –implementación • Evaluación del prototipo (usuario final) –pruebas y realimentación • Implementación del producto (expansión gradual) Una vez definidas las etapas que va a seguir el proyecto, se procede a establecer recursos temporales para cada una de ellas. De esta fase se ha obtenido el Diagrama Gantt que muestra las restricciones de tiempo establecidas para llevar a cabo el desarrollo del presente proyecto: Figura 1 – Diagrama Gantt, 1ª parte Figura 2 – Diagrama Gantt, 2ª parte Como se puede ver en el diagrama anterior, el proyecto se inicia a finales de Enero de 2009 y finalizará a principios de Septiembre del mismo año, quedando algunas semanas libres de dedicación al mismo, por diferentes motivos. NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 16 2.3. REQUISITOS DEL SISTEMA Se han estudiado las características que el sistema deberá tener para atender las necesidades establecidas. Así, se han obtenido los siguientes requisitos: FUNCIONALIDAD Se quiere obtener un proceso automatizado y transparente al usuario, en el que se minimice la interacción con el mismo, con el objetivo de facilitar así su uso y navegabilidad. Así, el proceso será iniciado como respuesta a un evento del usuario, en el que éste aproxime el dispositivo móvil a una etiqueta NFC. Una vez iniciado el proceso, esto es, cuando suceda que un usuario inicia la interacción con una etiqueta NFC y su teléfono móvil no está preparado para dicha transacción de información, el usuario deberá permitir ciertas operaciones (como puede ser el acceso a Internet) y, tras ello, el servicio requerido para que el dispositivo móvil y la etiqueta puedan interaccionar, quedará instalado y listo para su ejecución. INTERFACES DE USUARIO Sencillas, comprensibles y que proporcionen una idea intuitiva de navegabilidad. DISPOSITIVOS Otro de los requisitos impuestos es el uso de los dispositivos con los que se realizarán las pruebas. Éstas se llevarán a cabo con etiquetas RFID (UPM Rafsec) y con un teléfono móvil con soporte para NFC (Nokia 6131 NFC). REQUISITOS NO IMPUESTOS POR EL SISTEMA Conforme se ha ido analizando el sistema y sus requerimientos, se ha encontrado cierta funcionalidad que no es imprescindible para que el sistema funcione, pero sí aconsejable y deseable para que así, todos los aspectos que interfieren en el proceso queden cubiertos. Es por ello que se van a añadir las nuevas características estudiadas al sistema, y con ello se amplían ligeramente los requisitos del mismo. A continuación están descritan las funcionalidades y propiedades que implementarán estos requisitos no impuestos por el propio sistema: • Aplicación que permita escribir en etiquetas NFC: Se desea obtener un modo de escribir la información deseada en etiquetas NFC vacías. De esta forma, se podrá programar el sistema, para que los dispositivos móviles puedan detectar la etiqueta de la forma esperada. • Aplicación web de subida de servicios: Es conveniente tener un sistema web (para que pueda ser accedido de forma global), el cual permita subir servicios al servidor del sistema, de forma que, tras esto, queden listos para ser descargados por los usuarios. NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 17 2.4. ESCENARIOS Tras el estudio de tecnologías y captura de requisitos, se han pensado una serie de escenarios en los que se puede ver cómo se podría aplicar el sistema que se va a desarrollar, en contextos de la vida real, y cómo afectaría éste en la interacción entre usuarios y dispositivos NFC. Esta fase ayuda a visualizar la funcionalidad que ofrecerá el sistema y algunos aspectos de interacción que pueden aclarar aspectos hasta ahora no tenidos en cuenta. A continuación se enumeran los escenarios que se han definido. Todos ellos están pensados para que se sitúen etiquetas NFC en distintas localizaciones, con distintos objetivos. • Pósters inteligentes (Smart Posters) en el cine: Etiquetas NFC integradas en carteles anunciadores de películas, que aportarán información de la película que publicitada (horario, público apto, sinopsis…). • Noticias / titulares / información meteorológica: Etiquetas NFC situadas en áreas céntricas de la ciudad. Al tocarlas, se podrán consultar las noticias destacadas del día (en forma, por ejemplo, de titulares) u otra información como la predicción meteorológica. • Información turística: Las etiquetas NFC se situarán en oficinas de turismo. El usuario podrá obtener información turística relevante. • Adquisición de billetes last-minute: Etiquetas NFC situadas en estaciones trenes y autobuses, cerca de paneles informativos. El usuario podrá adquirir billetes último-minuto de forma rápida y sin esperar colas, con tan sólo acercar su teléfono al trayecto deseado. * Los escenarios arriba expuestos están explicados con mayor detalle en la sección “B.1. Scenarios” del “anexo B. Analysis” de este documento. 2.5. DIAGRAMA DE CASOS DE USO Una vez identificados los requisitos del proyecto, se ha elaborado el Diagrama de Casos de Uso. En él se pueden identificar dos casos de uso principales: • RECOGER INFORMACIÓN (GET DATA): Incluye las operaciones necesarias para obtener los parámetros de configuración del dispositivo móvil y de la etiqueta NFC. • PROCESAR SERVICIO (PROCESS SERVICE): Comprende las operaciones necesarias para la búsqueda del servicio apropiado y su posterior descarga e instalación en el dispositivo. NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 18 En el sistema se han identificado seis actores. Cinco de ellos son dispositivos físicos encargados de procesar diversas operaciones. El sexto actor es el usuario final. • ETIQUETA NFC (NFC TAG): Dispositivo que contiene la información a ser leída por el dispositivo NFC del usuario final. • DISPOSITIVO MÓVIL (MOBILE DEVICE): Dispositivo que gestionará el proceso. En él quedará instalado el servicio que se descargue, de forma que pueda, una vez hecho esto, interaccionar de la forma esperada con la etiqueta. • SERVIDOR DE LOOKUP (LOOKUP SERVICE): Máquina encargada de buscar el servicio adecuado que cumpla con los requisitos de la etiqueta NFC. Esta máquina consultará los servicios disponibles en el Registro de Aplicaciones, y los comparará con los parámetros obtenidos de la etiqueta y el dispositivo móvil. • SERVIDOR DE APLICACIONES (APPLICATION SERVER): Máquina donde se tiene almacenados los servicios, listos para ser descargados e instalados en los dispositivos móviles de los usuarios. • REGISTRO DE APLICACIONES (APPLICATION REGISTRY): Máquina en la que se tiene almacenada la información referente a los distintos servicios almacenados en el Servidor de Aplicaciones. • USUARIO FINAL (END USER): Es la persona que inicia el proceso, llevando a cabo el evento de tocar con su dispositivo móvil la etiqueta NFC. A continuación se muestra el diagrama de Casos de Uso, formado por los componentes arriba descritos: Figura 3 – Diagrama de Casos de Uso NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 19 2.6. DIAGRAMAS DE ACTIVIDADES Un Diagrama de Actividades especifica un Caso de uso. Es por ello que se han seleccionado los casos de uso que tienen mayor complejidad y se han detallado mediante diagramas de actividades, los cuales se pueden ver a continuación: • Especificación del CU “GET GCRTD”: El Caso de Uso especifica las operaciones necesarias para leer la información (Generis Control Record Type Definition) de la etiqueta NFC. Figura 4 – Diagrama de actividades para el CU “GET GCRTD” • Especificación del CU “SEARCH SERVICE”: Este diagrama muestra las operaciones que se llevan a cabo para buscar el servicio más apropiado que se adapte a la etiqueta NFC consultada. La búsqueda se realiza a partir de parámetros del teléfono y parámetros obtenidos de la etiqueta. Figura 5 – Diagrama de actividades para el CU “SEARCH SERVICE” Especificación del CU “DOWNLOAD SERVICE”: El diagrama muestra las operaciones requeridas para descargar el servicio requerido por la etiqueta NFC. Figura 6 – Activity diagram: Download service NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 20 2.7. DIAGRAMA DE SECUENCIA Un Diagrama de Secuencia muestra cómo se suceden las distintas operaciones a lo largo del proceso, qué métodos se llaman en cada etapa y qué información se transmite en ellos, cuánto dura la vida de cada uno de los objetos y cómo se comunican entre ellos. El Diagrama de Secuencia de nuestro sistema está compuesto por seis objetos principales. El objeto denominado GUI es el objeto que desencadena el proceso. En él se producen las primeras acciones, y es él el que recibe la información final. Éste objeto es el que representa la interacción con el usuario, el encargado de recoger la información necesaria para iniciar el proceso de búsqueda del servicio y el encargado de notificarle antes los posibles eventos que se sucedan. El Diagrama de Secuencia que modela el sistema principal que estamos desarrollando se puede ver a continuación: Figura 7 – Diagrama de Secuencia NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 21 2.8. DIAGRAMA DE CLASES Por último, se ha creado el Diagrama de Clases, una estructura estática que describe el sistema mostrando sus clases, las relaciones entre ellas y, en este caso, las operaciones que cada una de ellas implementa. Podemos ver el diagrama a continuación: Figura 8 – Diagrama de Clases NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 22 3. DISEÑO DEL SISTEMA 3.1. ARQUITECTURA FÍSICA La arquitectura física de un sistema está compuesta por los elementos físicos que la componen. Dentro de nuestro sistema se han identificado seis elementos que conforman esta arquitectura: • Etiqueta NFC: Etiqueta RFID que contiene la información que debe ser mostrada en el dispositivo móvil del usuario final. Al ser detectada por el dispositivo, se activa e inicia la transferencia de información, enviando al teléfono móvil un NDEFMessage con el contenido deseado. • Dispositivo móvil con soporte NFC: Es el dispositivo que inicia el proceso al aproximarse a una etiqueta NFC a menos de 10 centímetros de distancia. Una vez que la etiqueta ha sido reconocida y su información se ha leído, el teléfono comprueba si tiene el servicio requerido para procesar dicha información. Si no lo tiene disponible, se lanza la ApplicationDiscoverer, y con ello, se envía una petición al servidor junto con los parámetros leídos del móvil e información de la etiqueta. Este dispositivo debe estar provisto de acceso inalámbrico a Internet. • Servidor de Lookup: Servidor Web que recibe las peticiones HTTP que los dispositivos móviles lanzan. En él están alojados los Java servlets que se ejecutan al detectar una petición HTTP. Para que el proceso pueda desarrollarse de la forma deseada, este servidor debe tener acceso al Registro de Aplicaciones. • Registro de Aplicaciones: Base de datos que almacena información acerca de los servicios disponibles para ser descargados. Recibe peticiones SQL desde el Servidor de Lookup, enviando por su parte la respuesta a dichas peticiones. • Servidor de Aplicaciones: Servidor donde se alojan los servicios para ser descargados. Cuando el dispositivo móvil obtiene la URI del servicio requerido, se establece una conexión entre dicho dispositivo y el servidor de Aplicaciones, para que se pueda descargar así el servicio. NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 23 • Ordenador Personal: U otro dispositivo con acceso a Internet, es el dispositivo desde el que se visualizará la página Web en la que se introducirá información sobre el servicio a subir, y se cargará el propio servicio. Este dispositivo establecerá una conexión con el Servidor de Lookup, que será el encargado de almacenar los servicios y su información el destino correspondiente. El esquema de la arquitectura física del sistema se puede ver a continuación: Figura 9 – Arquitectura Física del sistema 3.2. ARQUITECTURA LÓGICA El sistema a desarrollar en este proyecto se ha dividido en tres sub-sistemas. El primero de ellos se corresponde con la aplicación más importante que se ha denominado ApplicationDiscoverer. Ésta será la encargada de auto-lanzarse cuando una etiqueta NFC, no reconocida por el dispositivo móvil, se detecte. A partir de ahí, se realizará el proceso de búsqueda de la aplicación, en el Servidor de Registros, a través de Servidor de Lookup, se obtendrán las localizaciones de los servicios aconsejados por NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 24 el sistema, el usuario deberá entonces seleccionar una opción, y este servicio escogido se descargará e instalara en el dispositivo móvil del usuario final. Un segundo sub-sistema es el definido para poder escribir el NDEFMessage deseado en una etiqueta NFC vacía. El último de los sub-sistemas definidos es el compuesto por la página Web y los servidores de bases de datos (Servidor de Registro y Servidor de Aplicaciones). Este sistema permite introducir servicios y su información correspondiente mediante una interfaz Web. Por otro lado, la arquitectura lógica del sistema está estructurada en tres capas. Así, cada una de ellas (capa de presentación, capa de lógica de negocio y la capa de datos) puede mantenerse de forma individual, y alojarse en un módulo independiente al resto de capas. Esta arquitectura proporciona escalabilidad y aumenta el rendimiento del sistema. A continuación se va a explicar el papel de cada uno de los sub-sistemas, y las estructuras de capas que los conforman. • Application Discoverer: La aplicación se despliega en una arquitectura de tres capas: o Datos: está distribuida en dos fragmentos: el Servidor de Aplicaciones y el Registro de Aplicaciones. Éste último está implementado en una base de datos MySQL, en la que se almacena toda la información correspondiente a los servicios disponibles en el Servidor de Aplicaciones. Por su parte, el Servidor de Aplicaciones está desplegado en un directorio del servidor, en el que se encuentran los servicios, dispuestos a ser descargados por los usuarios. Éste está implementado en un servidor Apache Tomcat. o Lógica de negocio: Está distribuida entre en Servidor de Lookup y el dispositivo móvil. Los Java servlets y las operaciones de acceso a la base de datos se encuentran en el servidor. Por su parte, estructuras de manejo e intercambio de datos, quedan situadas en el lado del cliente. La parte correspondiente al lado del servidor (Servidor de Looup) está alojada en un servidor Apache Tomcat. En el presente proyecto, la capa de datos y la capa de lógica están desplegadas en la misma máquina, por motivos de disponibilidad de recursos, pero éstas podrían migrarse a diferentes máquinas, teniendo que cambiar, únicamente, las referencias físicas a dichas máquinas, como son las URIs y direcciones IP de las cadenas de conexión.. o Capa de presentación: Se aloja en el dispositivo móvil. Está formada por clases de creación de interfaces gráficas y un MIDlet. Esta capa contiene las operaciones referentes al aspecto visual de la aplicación y a su interacción con el usuario. También contiene las operaciones requeridas de detección de etiquetas NFC y la gestión de la transmisión de información, puesto que éstas son clases propias de la clase MIDlet. • WriteNDEFMessage: La aplicación se distribuye en dos capas, puesto que no requiere almacenamiento de datos: o Lógica: Está formada por las clases que forman las estructuras de datos necesarias para llevar a cabo el proceso de escritura. Éstas son las NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 31 La clase ENDEFRecord extiende de NDEFRecord. Un objeto de la clase NDEFRecord está formado por un tres campos: NDEFRecordType –tipo de registro (en nuestro caso: EXTERNAL_RTD) y cadena de conexión (urn:nfc:ext:ericsson.com: demo)-, un segundo campo de tipo byte[] que representa el identificador del registro, y un tercer campo de tipo byte[] que representa el payload o información útil que contiene el registro. La estructura creada en la calse ENDEFRecord amplía esta disposición de información, creando, a su vez, una nueva estructura para el campo payload, que queda establecido como la unión de un campo target, un campo action, y un campo data. De esta manera, podemos escribir y leer información de las etiquetas (mensajes NDEF, formados por registros ENDEF), conociendo su estructura interna y siendo capaces de extraer la información que queremos gestionar. Puesto que la transmisión de información debe hacerse mediante estructuras de bytes, también se han creado métodos específicos para convertir una secuencia de objetos en bytes, y viceversa. La implementación de esta funcionalidad puede consultarse en mayor profundidad en el “anexo D. Implementation”, al final de este documento. Cabe puntualizar el porqué se ha creado esta versión extendida de un NDEFRecord. La respuesta reside en la necesidad de transmitir un mensaje NDEF formado por un registro, el cual cumpla con las especificaciones establecidas para esta tecnología. Así, el campo payload de un registro genérico está comprendido por los tres campos vistos en el párrafo anterior: target, action, data. APPLICATIONDISCOVERER El segundo de los sub-sistemas implementados es el que ha requerido un mayor esfuerzo y el que mayor número de componentes requiere para su correcto funcionamiento. Todo ello se describe en los siguientes párrafos. ApplicationDiscoverer es un sistema cliente-servidor. En el lado del cliente, se cuenta con un MIDlet encargado de dirigir el proceso, implementado, al igual que el MIdlet anteriormente descrito, sobre la plataforma Java ME. Éste está desplegado en un dispositivo móvil. Una de las primeras acciones que deben llevarse a cabo es el registro del mismo en el dispositivo. Dada la configuración establecida en el MIDlet, esto se consigue durante el proceso de instalación de la aplicación, sin necesidad de configuraciones externas, por parte del usuario final. El registro del MIDlet se lleva a cabo mediante el método PushRegistry, el cual requiere como parámetros una cadena de conexión, el nombre del MIdlet y el grupo de usuarios a los que se les permite el uso de la aplicación. Lo que se consigue con este registro es dejar al MIDlet preparado para que, en el momento en que se lea una etiqueta que contiene la cadena establecida en el momento del registro, la aplicación sea lanzada de forma automática. Tras el registro, la siguiente función a implementar es la detección de etiquetas. Para ello, la clase ApplicacionDiscoverer debe implementar la interfaz NDEFRecordListener. La interfaz cuenta con el método recordDetected(NDEFMessage ndefMessage), que se ejecuta al detectarse un registro (esto es, una etiqueta que contiene un NDEFMessage formado por registros). Esto es posible puesto que en el método constructor del MIDlet se ha añadido un NDEFRecordListener que permite la detección del registro. Así, hasta este punto tenemos implementada la detección de la etiqueta (gracias al método PushRegistry, que queda establecido al instalarse la aplicación) y la detección de la información en ella contenida (gracias al Listener y al método recordDetected). NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 32 A continuación, y tomando como base el mensaje NDEF obtenido de la etiqueta (nos lo proporciona el método recordDetected(NDEFMessage ndefMessage) ), podemos extraer la información que necesitamos para la gestión del proceso. Esto se consigue desmontando la estructura de bytes creada por la aplicación WriteNDEFMessage. Lo que nos interesa en este momento es la información almacenada en el campo target. Junto a este dato, se añaden ciertos parámetros que recogemos del dispositivo móvil, como son el lenguaje y el país en el que se encuentra registrado el teléfono, y una vez obtenida esta información, enviamos una petición al Servidor de Lookup, en forma de link y mediante el protocolo HTTP (usando los métodos que implementa la arquitectura RESTful Web Services). La información se envía usando la conexión por defecto del teléfono móvil, que como es natural, debe ser una conexión WiFi. El Servidor de Lookup tiene implementado un servlet, llamado LookupService. Éste está desarrollado sobre la plataforma Java EE. El servlet obtiene la petición enviada por el dispositivo móvil y comienza su proceso de búsqueda del servicio requerido. Para ello, establece una conexión con el Registro de Aplicaciones, el cual almacena la información referente a los servicios disponibles, y lleva a cabo una serie de operaciones contra la base de datos. El Servidor de Lookup obtiene los resultados, pudiendo éstos ser cero, uno o más servicios. Para poder gestionar este número variable de servicios, se ha optado por crear una estructura XML, la cual se envía en forma de cadena desde el Servidor de Lookup al dispositivo móvil del usuario final. Los resultados obtenidos se obtienen así en el dispositivo que inició el proceso, y tras ello, se procede a la interpretación y visualización de los mismos. Esto se consigue utilizando las funcionalidades que ofrece el paquete kXML, el cual se ha incluido en este sistema. El usuario tiene entonces la posibilidad de seleccionar uno de los servicios mostrados, pudiendo obtener información detallada de cada uno de ellos. Una vez elegida una de las opciones mostradas, se procede a la descarga del servicio. Un nuevo componente entra en juego, el Servidor de Aplicaciones, el cual tiene almacenados los servicios disponibles para ser descargados. Así, se establece una nueva conexión entre el dispositivo móvil y el servidor, y mediante el método paltformRequest(String url), perteneciente al paquete javax.microedition.midlet.MIDlet, el servicio se descarga al teléfono del usuario. Tras esto, el servicio podrá ser instalado (de forma automática, previa confirmación del usuario) y ejecutado, obteniendo así el objetivo deseado: la interacción con la etiqueta NFC leída al inicio del proceso. Al hablar de la ApplicationDiscover, es imprescindible destacar la rapidez con la que el servicio es llevado a cabo, la cual, si no tenemos en cuenta el tiempo destinado por el usuario a la selección del servicio (puesto que éste es un tiempo variable y no controlable por el sistema), se ejecuta de forma total en un tiempo inferior a 1 minuto. Este hecho permite que el usuario no sienta la necesidad de abortar el proceso y la operación se pueda culminar de forma satisfactoria. PÁGINA WEB El último sub-sistema implementado tiene una arquitectura cliente-servidor. El cliente puede ser cualquier dispositivo con acceso a Internet mediante un navegador Web. En él se mostrará la página implementada, la cual ha sido creada con código HTML y validaciones Javascript. Éstas aportan la funcionalidad requerida para asegurarnos que el usuario introduce la información adecuada en cada caso. Tras introducir dicha información y seleccionar la localización del fichero o los ficheros que contienen el servicio deseado, se procede a almacenar este contenido en NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 33 los servidores del sistema. Así, la petición es recogida por el Servidor de Lookup – implementado sobre la plataforma Java EE-, el cual responde mediante un servlet creado para este fin, llamado Upload. El servlet procesará la información introducida y la almacenará en el Registro de Aplicaciones. De la misma forma, recogerá los archivos cargados y los almacenará en el Servidor de Aplicaciones. 4.4. TESTS DE USABILIDAD En un sistema como el que se está desarrollando en este proyecto, es aconsejable que los usuarios finales formen parte del proceso de desarrollo, pudiendo aportar sus ideas y mejoras, puesto que, una vez implementado el sistema, serán ellos los que van a hacer uso del mismo. Es por ello que se ha creado una serie de pruebas de usabilidad, para las que se ha seleccionado a un grupo de usuarios que cumplen el perfil de usuarios finales. Estas pruebas se han llevado a cabo en dos fases del proyecto: cuando se tuvo un primer prototipo del sistema, y cuando el sistema estuvo finalizado. La primera de ellas proporcionó feedback al sistema, pudiendo así modificar, mejorar y adaptar las debilidades encontradas. La segunda fase de evaluación indicó si los objetivos de cara al usuario final y a la interacción del mismo con la aplicación se cumplieron, y si el usuario ha quedó satisfecho con el sistema desarrollado. Las conclusiones obtenidas tras realizar los tests de usabilidad establecidos, se pueden leer a continuación. TESTS DE USABILIDAD REALIZADOS TRAS OBTENER UN PRIMER PROTOTIPO Una vez obtenido un primer prototipo (previamente estudiado y evaluado por la parte desarrolladora), se llevó a cabo una primera fase de evaluación y, a pesar de que en ella se intentó crear un escenario real, en el que el usuario se pudiera situar y ambientar, esto no se llegó a conseguir, puesto que una gran parte de los evaluadores no consiguieron situarse en el contexto del problema. Al margen de esta desventaja y lo que ello pudo afectar en relación con otros aspectos, el resto de cuestiones planteadas en el test de usabilidad dieron resultados positivos al prototipo obtenido. TESTS DE USABILIDAD REALIZADOS TRAS OBTENER EL PRODUCTO FINAL Una segunda fase de evaluación llevada a cabo al final de la etapa de implementación, aportó conclusiones positivas, dejando patente un claro interés por parte de los evaluadores hacia el servicio testado. * En la sección “B.7. Evaluation tests” del “anexo B. Analysis” del presente documento se puede ver el test de usabilidad realizado a los usuarios finales. NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 34 5. CONCLUSIONES Finalizado el desarrollo del presente proyecto se puede concluir que la valoración final es muy positiva. Los objetivos funcionales propuestos al inicio del proyecto se han cumplido de la forma deseada. La funcionalidad buscada, el hecho de facilitar al usuario final un marco que le permita la interacción con todo tipo de dispositivos NFC, ha sido implementada, testada y evaluada como positiva. Cabe destacar este hecho puesto que, personas implicadas directamente en el proyecto, mencionaron al inicio del mismo que sería “normal” no encontrar una solución al problema planteado, dentro del tiempo establecido hasta la conclusión del proyecto. Por otra parte, los tiempos dedicados a cada una de las fases, y las horas finales invertidas, son las adecuadas para un proyecto software. Éstas se podían haber mejorado en etapas iniciales, puesto que costó entender el funcionamiento de ciertos aspectos de la tecnología NFC, pero aún con ello, el resultado es positivo. Hay que tener en cuenta que el alumno se enfrentaba por primera vez al uso de NFC, a su estudio y comprensión, y puede que este hecho alargara ligeramente la fase inicial de estudio previo y conocimiento de las tecnologías a utilizar. Con todo ello, se ha conseguido solventar el vacío encontrado en la tecnología NFC en lo que se refiere a la interacción con etiquetas NFC que requieren un servicio específico para su lectura, por parte de un dispositivo móvil con soporte para NFC. Éstas, salvando las limitaciones detalladas al inicio del documento, podrán ser leídas bajo todos los conceptos. Con la instalación de una única aplicación, como es ApplicationDiscoverer, el usuario podrá acceder a múltiples servicios requeridos por ciertas etiquetas, para que éstas puedan interaccionar con el dispositivo móvil. Este hecho aporta grandes ventajas de cara al usuario final, abriendo un gran abanico de posibilidades en el mundo de las interacciones entre dispositivos NFC. Como opinión personal, debo destacar que he quedado muy satisfecha con el trabajo realizado, con el proceso llevado a cabo para obtenerlo y los resultados finales obtenidos. He conocido a fondo las capacidades y características de una nueva tecnología, lo cual valoro como favorable y muy interesante. Otro punto destacable, en lo personal, es el haber desarrollado el proyecto, de forma favorable, en un país extranjero, de habla sueca e inglesa. Por último, concluir con el grado de satisfacción que supuso conocer la noticia de que el presente proyecto va a ser incluido en una plataforma de mayor alcance, y será utilizado por la empresa en la que ha sido desarrollado. Ello ha supuesto un perfecto punto final para la conclusión del proyecto. NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 35 NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 36 REFERENCIAS BIBLIOGRÁFICAS [1] Introducción a J2ME. http://www.todosymbian.com/secartprint36.html [2] Paquete javax.microedition.contactless. http://mobilezoo.biz/jsr/257/javax/microedition/contactless/package-summary.html [3] Sun Microsystems. FAQs. How can a MIDlet be launched automatically? http://developers.sun.com/mobility/midp/questions/pushregistry/ [4] Sun Microsystems. The MIDP 2.0 Push Registry. http://developers.sun.com/mobility/midp/articles/pushreg/ [5] Library of congress. Codes for the representation of names of languages. http://www.loc.gov/standards/iso639-2/php/code_list.php [6] Sun Microsystems The Java servlet API. http://java.sun.com/developer/onlineTraining/Servlets/Fundamentals/servlets.html [7] Sun Microsystems. FAQs. What are the defined J2ME system property names? http://developers.sun.com/mobility/midp/questions/properties/index.html [8] Sun Microsystems. Parking XML in J2ME. http://developers.sun.com/mobility/midp/articles/parsingxml/ [9] Esidea Grupo Tecnológico. Alto nivel – bajo nivel. http://www.esidea.com/index.asp?pagina_e=noticias&mas=15 [10] Nokia Forum. Design and User Experience Library [11] NFC Forum http://www.nfc-forum.org/home [12] John W. Muchow, “Core J2ME. Technology and MIDP”, 2002. [13] Diferentes consultas: http://www.wikipedia.org [14] Consultas sobre J2ME y dispositivos móviles. http://www.forum.nokia.com [15] Java Community Process. http://jcp.org/aboutJava/communityprocess/edr/jsr257/index.html [16] NFC Forum. Technical specifications. http://www.nfc-forum.org/specs/ [17] The Apache Software Foundation http://tomcat.apache.org/ [18] Sun Microsystems. MySQL. http://www.mysql.com/ NFC Application Provisioning Framework Andrea Martínez Mazo, September 2009 37 [19] kXML 2. http://kxml.sourceforge.net/kxml2/ [20] Nokia. Developer Discussion Boards. http://kxml.sourceforge.net/kxml2/ [21] J2ME PushRegistry. Activación automática de MIDlets. http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=pushRegistry [22] Collin Mulliner, “Attacking NFC Mobile Phones”, May 2008. mulliner.org/nfc/feed/collin_mulliner_eusecwest08_attacking_nfc_phones.pdf [23] ABI Research. NFC. www.abiresearch.com/research/1003525-Near+Field+Communication+(NFC) [24] Java Community Process. The Java API for RESTful Web Services http://jcp.org/aboutJava/communityprocess/final/jsr311/index.html [25] Universidad de Deusto. Near Field Communication. http://www.morelab.deusto.es/images/talks/NFC.ppt [26] Innovision, creators of RFID systems. NFC Forum Standards and Tags, Abril 2007. http://www.enamax.net/wima/pics/File/confs/Heikki%20Huomo.pdf [27] Nokia. Touch a Phone, Touch a Friend: Using RFID and Visual Tags with JSR 257 http://docs.huihoo.com/javaone/2006/JAVA%20ME/ts-3789.pdf