middleware para el desarrollo de aplicaciones …jesús vicario jover eloy javier mata sotés y...
TRANSCRIPT
Jesús Vicario Jover
Eloy Javier Mata Sotés y José Manuel Sota Eguizábal
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2014-2015
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
Middleware para el desarrollo de aplicaciones móvilespara el Campus Virtual de la Universidad de La Rioja
(Blackboard Learn)
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015
publicaciones.unirioja.esE-mail: [email protected]
Middleware para el desarrollo de aplicaciones móviles para el Campus Virtual de la Universidad de La Rioja (Blackboard Learn), trabajo fin de grado
de Jesús Vicario Jover, dirigido por Eloy Javier Mata Sotés y José Manuel Sota Eguizábal(publicado por la Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
Facultad de Ciencias, Estudios Agroalimentarios e Informática
TRABAJO FIN DE GRADO
Grado en Ingeniería Informática
Middleware para el desarrollo de aplicaciones móviles para el Campus Virtual de la Universidad de La Rioja
(Blackboard Learn)
Alumno:
Jesús Vicario Jover
Tutores:
Eloy J. Mata Sotés
José Manuel Sota Eguizabal
Logroño, junio 2015
2
Resumen El proyecto consiste en el análisis e implementación de un middleware que facilite el desarrollo de aplicaciones móviles que interactúen con Blackboard Learn. Blackboard Learn es la plataforma que utiliza la Universidad de La Rioja para la gestión de contenido de cursos, estudiantes y profesores. Mediante este middleware terceras partes podrán acceder al sistema para desarrollar aplicaciones móviles con contenido especifico que complementen las funcionalidades que ofrece la versión web de la plataforma. Finalmente se ha desarrollado un prototipo de aplicación para iOS para demostrar algunas de las posibilidades de este middleware.
Abstract The project consists of the analysis and implementation of a middleware which will make the development of mobile phone applications which interact with Blackboard Learn easier. Blackboard Learn is the platform which the University of La Rioja uses to manage the content of courses, students and teachers. By this middleware, third parties will be able to access the system in order to develop mobile phone applications with specific content which complements the features offered by the web version of the platform. Finally an iOS application prototype has been develop to show some posibilities of this middleware.
3
Tabla de contenido
1. INTRODUCCIÓN .............................................................................................................................. 4 1.1 ANTECEDENTES ............................................................................................................................................... 4 1.2 OBJETIVO .......................................................................................................................................................... 4 1.3 PLANIFICACIÓN ............................................................................................................................................... 5
2. CREACIÓN DEL MIDDLEWARE ................................................................................................... 8 2.1 ANÁLISIS ........................................................................................................................................................... 8 2.1.1 Interacción con la plataforma Blackboard ................................................................................. 8 Conclusión .......................................................................................................................................................... 10 2.1.2 Requisitos funcionales y no funcionales .................................................................................... 10 2.1.3 Casos de uso ........................................................................................................................................... 12
2.2 DISEÑO ........................................................................................................................................................... 14 2.2.1 Arquitectura del middleware ......................................................................................................... 14 2.2.3 Diseño de las clases ............................................................................................................................. 14 2.2.4 Diseño plan de pruebas ..................................................................................................................... 16
2.3. IMPLEMENTACIÓN ...................................................................................................................................... 17 2.3.1 Recursos externos ................................................................................................................................ 17 2.3.2 Configuración del sistema Blackboard Learn ......................................................................... 17 2.3.3 Tecnologías usadas ............................................................................................................................. 19 2.3.4 Configuración y uso de los servicios web Blackboard ......................................................... 20 2.3.5 Comunicación ........................................................................................................................................ 23 2.3.6 Clases y cómo generarlas ................................................................................................................. 23 2.3.7 Implementación SOAP ....................................................................................................................... 29 2.3.8 Implementación REST ....................................................................................................................... 34
2.4 PRUEBAS ........................................................................................................................................................ 38 3. CREACIÓN DE APP ....................................................................................................................... 40 3.1 ANÁLISIS ........................................................................................................................................................ 40 3.1.1 Requisitos funcionales y no funcionales ................................................................................... 40
3.2 DISEÑO ........................................................................................................................................................... 41 3.2.1 Diseño interfaz aplicación iOS ....................................................................................................... 41 3.2.2 Diagrama de navegación ................................................................................................................. 44
3.3. IMPLEMENTACIÓN ...................................................................................................................................... 45 3.3.1 Generar clases para Objective C .................................................................................................... 45 3.3.2 Uso de librería RestKit ....................................................................................................................... 46 3.3.3 Interfaz gráfica ..................................................................................................................................... 48 3.3.4 Implementación funcionalidad ..................................................................................................... 48
4. SEGUIMIENTO DEL PROYECTO ................................................................................................ 53 Sprint 1: Configuración entorno de desarrollo y plataforma BBLearn. 60 horas .............. 53 Sprint 2. Desarrollo cliente Servicios Web. 62 horas ...................................................................... 54 Sprint 3. Implementación servicios REST y despliegue. 40 horas ............................................. 56 Sprint 4 . Desarrollo pequeña APP. 50 horas ...................................................................................... 57 Sprint 5. Pruebas generales. 20 horas ................................................................................................... 58
5. CONCLUSIONES ............................................................................................................................. 59 5.1 OBJETIVOS ..................................................................................................................................................... 59 5.2 FUTURAS MEJORAS ...................................................................................................................................... 60
6. BIBLIOGRAFÍA ............................................................................................................................... 60
4
1. Introducción En esta memoria se desarrollan los aspectos más importantes del trabajo realizado para el Proyecto Fin de Grado en Ingeniería Informática.
1.1 Antecedentes En la actualidad muchas universidades de todo el mundo usan Sistemas de Gestión de Aprendizaje (Learning Management System -‐ LMS) con el fin de ofrecer acceso al contenido de la institución, vía web, a los profesores y alumnos. De esta forma evoluciona la interacción entre la universidad, los profesores y alumnos llevando la comunicación más allá de las propias aulas de la universidad. Un LMS es un sistema que se encarga de gestionar, de forma virtual, todos los aspectos del proceso de aprendizaje. Ofrece la gestión de los cursos y contenidos de una institución académica así como la evaluación del aprendizaje individual. Algunos LMS son Moodle, eCollege, WebCT, o Blackboard Learn. En la Universidad de La Rioja se dispone de Blackboard Learn, sistema LMS desarrollado por Blackboard Inc. Este cuenta con más de doce mil usuarios y más de tres mil cursos activos. Además, el sistema tiene una media de 1.700 visitas diarias. Tradicionalmente el acceso al Campus Virtual se ha hecho mediante la aplicación web. Sin embargo la evolución en la forma de conectarnos, los dispositivos inteligentes y la facilidad de acceso a internet obliga a nuevas formas de acceso a los sistemas de la Universidad. Cualquier persona con un Smatphone o tablet con acceso a internet puede acceder a todo el contenido y servicios en cualquier lugar del mundo. Este proyecto nace con la idea de facilitar que los alumnos puedan acceder al contenido de sus asignaturas desde una aplicación móvil. La aplicación necesita comunicarse con la plataforma de Blackboard para conseguir los datos deseados y poder mostrarlos. Sin embargo, para conseguir esta comunicación se han de seguir una serie de mecanismos que dificultan en exceso el desarrollo. Por esto, se ha propuesto desarrollar un middleware que haga de comunicador entre las aplicaciones móviles y el sistema de Blackboard.
1.2 Objetivo El objetivo principal del proyecto es el desarrollo de un middleware que haga la comunicación entre la plataforma Blackboard Learn y los dispositivos móviles. Mediante esta comunicación se consigue que los dispositivos tengan acceso a los datos (del sistema de aprendizaje) para su posterior tratamiento.
5
Los datos se obtendrán en un formato esquemático. El dispositivo móvil final deberá entender y procesar el esquema de los datos para mostrárselos al usuario de forma dinámica e interactiva. También se desarrollará una app para terminales iOS con el fin de mostrar el uso y la funcionalidad del middleware. De esta manera se pretende establecer las bases para que en un futuro se pueda desarrollar una aplicación completa del campus virtual de la Universidad de La Rioja. Otros objetivos concernientes al proyecto son:
-‐ Instalación de una instancia virtualizada de la plataforma Backboard Learn para la simulación de las pruebas correspondientes.
-‐ Consecución de comunicación a la plataforma desde aplicaciones externas a través de servicios web SOAP.
-‐ Implementación de cliente traductor de REST a SOAP. En cuanto a los objetivos personales:
-‐ Perfeccionar la redacción de proyectos. -‐ Aprendizaje de implementación de servicios RESTful. -‐ Adquirir conocimientos para el desarrollo de aplicaciones iOS y su
entorno de desarrollo Xcode.
1.3 Planificación Para la realización de este proyecto se empleará la metodología Scrum para la gestión y desarrollo del software. Es una metodología de desarrollo ágil, que se caracteriza por adoptar una estrategia de desarrollo iterativa e incremental y por el solapamiento de las diferentes fases del desarrollo. En esta metodología se realizan entregas parciales y regulares del producto final con el fin de que el cliente vea los progresos. Su uso está centrado en proyectos complejos, donde los requisitos son cambiantes o poco definidos. Como hemos comentado, el proyecto se va a basar en la metodología Scrum. No se usará al completo puesto que es una metodología pensada para trabajar en equipo y en este caso se trata de un proyecto individual. Por otro lado, es una metodología que se acopla a nuestras necesidades por ser un proyecto con requisitos poco definidos. Por lo tanto, se hará un uso más particular de esta metodología para así obtener un beneficio alto en el desarrollo del proyecto. El proyecto estará comprendido entre el 12 de enero y el 29 de mayo, casi cuatro meses. Cada semana se empleará 20 horas para el desarrollo del mismo con disponibilidad de los sábados para posibles imprevistos.
6
Para la correcta realización del proyecto se ha realizado la siguiente descomposición de tareas:
• Configuración de la Plataforma Virtual Blackboard Learn • Estudio panel de administración BBLearn (cursos, usuarios…) • Desarrollo servicios web en Java mediante el protocolo SOAP • Pruebas servicios web • Desarrollo servicio Rest • Pruebas servicio Rest • Implementación middleware con servicios web SOAP y REST entre BBLearn
y la APP • Conexiones entre los distintos medios • Diseño de la interfaz gráfica para la aplicación móvil en dispositivos iOS. • Desarrollo funcionalidad de la APP • Gestión de errores • Pruebas generales • Documentación
Para llevar a cabo las mismas, el proyecto se dividirá en Sprint´s (periodos de tiempo en los que se deben ir entregando los avances del proyecto) de entre tres y cuatro semanas. A continuación se enumeran los sprint’s que se van a seguir a lo largo del proyecto con la correspondiente estimación de horas.
• Sprint 1: Configuración entorno de desarrollo y plataforma BBLearn. 60 horas
• Sprint 2. Desarrollo cliente Servicios Web. 62 horas • Sprint 3. Implementación servicios REST y despliegue. 40 horas • Sprint 4 . Desarrollo pequeña APP. 50 horas • Sprint 5. Pruebas generales. 20 horas
A estas horas se les debe sumar las siguientes horas:
• Planificación: 20 horas. Definición de las tareas del proyecto
• Memoria: 45 horas. Escribir la memoria del proyecto
• Reuniones: 10 h Reuniones con el tutor del proyecto. Dedicas a la elaboración y seguimiento del proyecto.
7
Por lo tanto, la estimación total de horas dedicadas al proyecto quedaría reflejada en la siguiente tabla. Sprints 232 Planificación 20 Memoria 45 Reuniones 10 Total 307
8
2. Creación del Middleware
2.1 Análisis En este apartado se expone toda la documentación recogida del análisis elaborado para la realización del proyecto. A continuación se van a exponer todas las opciones estudiadas para conseguir la comunicación con la plataforma. También, y con el fin de una mejor comprensión de la memoria, se desarrollarán una serie de definiciones.
2.1.1 Interacción con la plataforma Blackboard Blackboar Learn ofrece distintas alternativas a los desarrolladores para desarrollar funcionalidad extra para la plataforma; LTI (Learning Tools Interoperability), Servicios Web y Building Blocks. A continuación, se expondrá con detalle cada una de ellas y se tomará una decisión sobre cual se usará para la ejecución del proyecto.
LTI (Herramientas de interoperabilidad) El concepto principal de LTI es establecer una forma estándar de integrar herramientas de terceros en plataformas de aprendizaje como Blackboard, Moodle, ect. En este estándar las herramientas de terceros se llaman tools (tools providers) y por otro lado, a las plataformas de aprendizaje se les llama tools consumers. De esta forma y como el nombre indica se crea interoperabilidad entre los sistemas. Es la forma con la que las plataformas de aprendizaje puedan obtener funcionalidad de terceros, sin necesitad de un desarrollo y mantenimiento personalizado. Además tiene la ventaja de que no compromete el rendimiento de la aplicación, ya que se ejecutan en servidores independientes. Por lo tanto, es una forma de permitir, sin problemas, la conexión de aplicaciones web externas (cómo un chat) alojadas externamente dentro de las plataformas educativas.
Funcionamiento El modo de trabajo básico de LTI consiste en una URL, clave y secreto para la herramienta.
9
El administrador añade la herramienta o actividad virtual estableciendo la URL, clave y secreto. Una vez configurado, los profesores ven la herramienta o actividad para ser colocada como un enlace. Los estudiantes usan la herramienta como si estuviese incluida dentro de la plataforma. La herramienta externa recibirá una solicitud de lanzamiento junto a la identidad del usuario, información de cursos, información de roles, la clave y firma. Esta información se envía mediante un formulario HTTP generado en el navegador del usuario con elementos de datos LTI en campos ocultos del formulario. Estos se presentan en la herramienta externa mediante JavaScript. Los datos del formulario se firman con el estándar de seguridad OAuth por lo que la herramienta externa se asegura que los datos de lanzamiento no han sido modificados. Recibida la petición, la herramienta puede elegir entre redirigir al usuario a otra URL o presentarlo directamente en la interfaz de usuario.
Servicios Web Es una tecnología que utiliza un conjunto de estándares y protocolos que sirven para intercambiar datos entre aplicaciones, en distintos lenguajes. Ofrecen la posibilidad de intercambiar información entre aplicaciones de software independientemente del lenguaje de programación y la plataforma sobre la que se ejecuta. De esta forma proporcionan interoperabilidad a la plataforma. Blackboard ofrece sus servicios web para extender su funcionalidad de software en aplicaciones de terceros sin la necesidad de crear Building Blocks (explicados en el siguiente apartado) o usar java. Estos servicios web están basados en SOAP y usan tokens WS-‐SECURITY para asegurar la transmisión de datos entre las dos entidades. Blackboard ofrece de esta forma parte de la funcionalidad de la aplicación a aplicaciones externas. Para hacer uso de ellos se deben activar desde la propia plataforma.
Building blocks Son extensiones de Blackboard que permiten incluir funcionalidades adicionales en la herramienta educativa. Con estos se puede personalizar, ampliar la experiencia y funcionalidades de los usuarios, flujos de trabajo y los métodos de almacenamiento de datos.
10
También se puede asistir la administración del sistema y automatizar tareas y procedimientos repetitivos. Su desarrollo es muy similar a un árbol de proyectos web en Java. Blackobard dispone de una API Java para desarrollar Building Blocks. Son aplicaciones web que se ejecutan en el sistema de Blackboard, que hace de contenedor de las mismas. Estas aplicaciones deben instalarse por el administrador de la plataforma requiriendo de permisos específicos para poder hacerse correctamente. Un ejemplo es Blackboard Stats que proporciona estadísticas sobre la actividad de los usuarios en la plataforma.
Conclusión Como hemos mencionado anteriormente, nuestro proyecto consiste en obtener datos de la plataforma para procesarlos y mostrarlos en aplicaciones móviles. En este caso, y después de valorar el estudio hecho en el apartado anterior se llega a la conclusión de que tanto LTI como Building Block no son las formas idóneas para desarrollar el proyecto. La primera no encaja con nuestro proyecto porque no se desea integrar aplicaciones externas dentro de la plataforma de aprendizaje. En el caso de Building blocks, tampoco se amolda a la necesidad del proyecto porque no se pretende personalizar ni añadir funcionalidades al sistema. Por esto, se decide usar los servicios web basados en SOAP ya que ofrecen un canal de comunicación entre el sistema y el middleware. De esta manera, el middleware se encargara de procesar los datos y remitirlos a las aplicaciones móviles. A la hora de comenzar el proyecto, se contacta con desarrolladores de Blackboard exponiendo la idea de desarrollar una aplicación iOS para el campus virtual de la Universidad de La Rioja a través de los servicios web. Estos ante la complejidad que supone consumir los servicios web de Blackboard con WSSecurity de BBLearn con la plataforma de Cocoa, proponen el desarrollo de un middleware en java que traduzca las peticiones REST de Cocoa a las llamadas SOAP para BBlearn.
2.1.2 Requisitos funcionales y no funcionales En este bloque se describen los requisitos funcionales y no funcionales que cumplirá el proyecto.
11
2.1.2.1 Requisitos funcionales En el middleware se identifican los siguientes requisitos funcionales:
o Será un sistema que servirá de comunicación entre la plataforma Blackboard y aplicaciones para dispositivos móviles.
o Este sistema constará de una serie de peticiones con las que el usuario interactuará desde la aplicación móvil.
o A través de estas peticiones, se podrá tener acceso a diversos contenidos del aula de Blackboard del usuario.
2.1.2.2 Requisitos no funcionales
Requisitos de usuario. Para acceder a la funcionalidad del middleware el usuario deberá estar registrado en la Universidad de La Rioja con su correspondiente usuario y contraseña.
Requisitos de seguridad El middleware debe realizar la comunicación con la plataforma bajo peticiones HTTPS con el fin de cumplir con la seguridad establecida.
Requisitos tecnológicos.
o El middleware podrá funcionar bajo los sistemas operativos Windows, Linux y Mac OX.
o Es imprescindible tener conexión a internet para el funcionamiento de la app y el middleware.
o El rendimiento del middleware dependerá del servidor en el que este alojado y del ancho de banda que disponga.
12
2.1.3 Casos de uso A continuación se expone el diagrama de casos de uso que el middleware ofrece a la aplicación. La funcionalidad está orientada a servir datos a la app.
Figura 1. Diagramas casos de uso
Caso de uso Ver calificaciones
Descripción
Realiza petición al sistema para obtener las calificaciones del usuario
Autores Usuario
Precondiciones
13
Dispositivo debe tener conexión a internet El middleware debe estar activo El usuario debe haber iniciado sesión
Postcondiciones Dispositivo recibe la petición y devuelve las datos
Secuencia normal
1. Usuario realiza la petición REST 2. Rest hace la correspondiente petición SOAP a la
plataforma 3. La plataforma devuelve los datos pedidos 4. El servicio Rest devuelve los datos en JSON al
dispositivo.
Excepciones
Si el usuario no posee calificaciones el sistema se lo informará
14
2.2 Diseño En este apartado se definen todas las decisiones tomadas a lo largo del desarrollo del proyecto en cuanto al diseño de la arquitectura del sistema.
2.2.1 Arquitectura del middleware Como hemos mencionado anteriormente se va a desarrollar un middleware que haga de comunicador entre aplicaciones móviles y la instancia de Blackboard. La arquitectura del sistema estará comprendida por un equipo con la plataforma de Blackboard Learn y un servidor con el middleware desarrollado. En lo que se refiere al middleware, estará formado por la siguiente arquitectura. Por una parte, se tiene la parte de la implementación SOAP que tendrá el modelo de datos y la lógica de negocio. Por otra, se tiene la implementación de la API Rest que se encargará de presentar los datos a los dispositivos móviles.
2.2.3 Diseño de las clases En el proyecto se van a usar clases generadas a partir de ficheros WSDL que la plataforma pone a nuestra disposición para el uso de los servicios web. De esta forma nos ahorramos el coste de desarrollar el modelo de datos y la lógica de negocio , centrándonos en la parte de presentación de los datos. El código generado se estructura de la siguiente manera. Por cada servicio que ofrece la plataforma se generan dos paquetes con la siguiente estructura “blackboard.ws. <servicio>” y “blackboard.ws.<servicio>.xsd”. De tal forma que en los paquetes del primer estilo se genera la lógica de negocio del servicio, mientras que en los que terminan en “xsd” se genera el modelo de datos.
15
Cada uno de los servicios tiene asociado su correspondiente wrapper contenidos en el paquete “com.blackboard.test.clients.wrappers”
16
Por otra parte, se crea un paquete con el nombre middleware que contendrá la funcionalidad que se quiere dar al servicio así como la definición de la API Rest. Este paquete contiene dos clases. La clase LanzadoRest que se encarga de definir los recursos de la API Rest y de lanzar el servicio. Y la clase Cliente que implementa la API a partir de los wrappers y clases de modelo de datos anteriormente mencionados.
2.2.4 Diseño plan de pruebas
En este apartado se describe le metodología a seguir para las pruebas a realizar en la fase de test.
Se van a realizar dos tipos de pruebas.
-‐ Pruebas unitarias: se realizan para comprobar el correcto funcionamiento de un módulo de código, asegurando que cada modulo de código funcione correctamente por separado.
-‐ Pruebas de integración: a realizar una vez aprobadas las pruebas unitarias. Son aquellas en las que se compruebas todas las pruebas unitarias en conjunto, de una sola vez.
Las pruebas se documentaran de la siguiente forma: Prueba Grupo Descripción Resultado Comentarios
17
2.3. Implementación En el apartado de implementación se detalla el proceso elaborado para la ejecución del proyecto a partir de las decisiones tomadas en los apartados anteriores. Se desarrollan minuciosamente los pasos seguidos debido la complejidad de la comunicación con la plataforma de Blackboard y el uso de herramientas y tecnologías nuevas no vistas a lo largo de la carrera.
2.3.1 Recursos externos El desarrollo del proyecto, tanto del middleware como de la APP, requiere el uso de librerías externas para facilitar el desarrollo y ahorrar tiempo de programación. En este apartado describimos las librerías externas usadas para el desarrollo del middleware:
-‐ Axis2: Es una Liberia desarrollada por Apache para facilitar el trabajo con servicios web SOAP
-‐ Jersey: esta librería extiende de JAX-‐RS. Es una librearía con
características y utilidades adicionales para simplificar el desarrollo de clientes RESTful.
-‐ Rampart: librería que permite incrustar cabeceras de seguridad en los mensajes SOAP.
2.3.2 Configuración del sistema Blackboard Learn Para poder hacer el desarrollo del proyecto y ver los resultados que se van obteniendo es necesario tener acceso a una instancia de Blackboard. Esta instancia deberá tener diversidad de contenidos como por ejemplo usuarios, cursos, contenido del curso, etc. Para ello se configura una maquina virtual de pruebas con la plataforma Blackboard Learn, para ello se debe tener instalado:
• “Virtual Box” (software de virtualización de sistemas operativos) y • “Vagrant” (herramienta para la creación y configuración de entornos de
desarrollo virtualizados). Después, se descarga la máquina virtual de Vagrant y el Vagrantfile de help.blackboard.com. Nota: Se debe tener cuenta de desarrollador de blackboard
18
Descargados e instalados los componentes necesarios se procede a configurar el entorno de desarrollo. Para ello se debe levantar la máquina virtual. Esto consiste en ejecutar, en el directorio donde se encuentren los ficheros mencionados anteriormente, los siguientes comandos:
-‐ vagrant up
-‐ vagrant ssh
Con estos comandos se consigue levantar los servicios y loguearnos en la máquina. Una vez logeados en la máquina virtual, se ejecuta el siguiente comando para levantar el Learn. -‐sudo /usr/local/blackboard/tools/admin/ServiceController.sh services.start
19
Una vez configurado el sistema por el administrador de la plataforma los usuarios pueden acceder a sus cursos y contenidos a través del navegador.
Figura 2. Primera pantalla BBLearn web
2.3.3 Tecnologías usadas Blackboard proporciona servicios web SOAP para java, así que, con el fin de hacer más simple la comunicación entre la aplicación y la plataforma de BBLearn, se ha propuesto hacer un middleware que traduzca las peticiones REST de COCOA a las llamadas SOAP para la plataforma. Para la implementación de la parte del cliente SOAP del middleware es necesario generar las clases correspondientes a partir de los ficheros WSDL, así como usar los “wrappers” que proporciona el módulo de administración de la plataforma. Se implementará la funcionalidad específica que quiere nuestra aplicación para su posterior llamada desde la implementación REST (Representational State Transfer). Para la implementación del servicio RESTful se va a usar la API Java JAX-‐RS, que proporciona soporte para el estilo arquitectónico REST. Existen varias implementaciones para esta API, entre ellas destacan “Restlet” y “Jersey”. Restlet es uno de los pioneros en servicios REST, comenzó en el año 2005, desarrollado por Jerome Louvel. Jersey, por su parte, sacó su primera versión en 2007 y es la implementación de referencia para Java Sun. Sobresale sobre todo por su facilidad de uso.
20
Por ser la referencia para Java Sun, como por ser la implementación recomendada por desarrolladores de Blackboard, Jersey va a ser la implementación escogida para este proyecto. Jersey ofrece su propia API que extiende JAX-‐RS con características y utilidades adicionales para simplificar el desarrollo del servicio RESTfull. Cuenta con las siguientes características, a parte de las propias de JAX-‐RS:
-‐ WADL (Web Application Description Languaje) -‐ API de cliente (fácil uso para hacer peticiones HTTP) -‐ Integración con SPRING -‐ Soporte Modelo Vista Controlador -‐ Soporte JSON -‐ Amplia documentación -‐ …
2.3.4 Configuración y uso de los servicios web Blackboard En esta sección se va a exponer cómo hacer la configuración de la plataforma para el uso de los servicios web. Para ello se deben seguir una serie de pasos que se detallan a continuación, diferenciando entre la parte del administrador y la del desarrollador. Más adelante se mostrará el uso especifico que nuestro cliente hará de los mismos.
Activación servicios web Antes de comenzar con el desarrollo del servicio SOAP el administrador debe activar los servicios en la plataforma en el panel de administración del sistema. El administrador puede ver que servicios web están instalados y cuales pueden o no estar disponibles para su uso. Para acceder a la activación de los servicios el administrador debe loguearse en la instancia de la plataforma y navegar a la página de administración del sistema. En el módulo de Building block aparece un enlace para la administración de los servicios web. Al hacer click en este enlace aparecerá un listado con los servicios web que ofrece la plataforma. Para la activación de los mismos se debe marcar los checkbox de los servicios que se quieres activar.
21
Figura 3. Administración servicios web
Configurar inicio de sesión de los servicios web (Proxy Tool) Para usar los servicios web se debe tener una aplicación cliente de inicio de sesión. Hay dos métodos principales de acceso. Con el primero se inicia sesión mediante usuario y contraseña de un usuario con privilegios suficientes para usar las clases y métodos de los servicios web. Con el segundo se inicia sesión usando una herramienta proxy (proxy tool) autorizada y registrada previamente. Una herramienta de proxy es un programa cliente identificado por un nombre específico que tiene un secreto compartido que debe ser pasado al iniciar sesión. El administrador debe registrar esta herramienta y acto seguido autorizar el programa cliente para que pueda ser utilizado al iniciar sesión y hacer llamadas a los servicios web de Blackboard.
22
Para registrar la herramienta de proxy, el administrador debe navegar al panel de Administracion del sistema. En el módulo de building blocks aparece un enlace con el nombre building blocks, se accede a el y por último click en Porxy Tool. Se mostrará una nueva ventana con datos a rellenar para registrar la herramienta.
Figura 4. Administración proxy tool
Por parte del desarrollador, la herramienta proxy también puede ser registrada a partir de líneas de código usando los propios servicios web, de cualquier manera, como hemos mencionado anteriormente, el administrador debe autorizarla. Hacerlo de forma programada tiene la ventaja de que se puede especificar la funcionalidades a las que puede acceder ese proxy tool. De tal manera que se puede crear un proxy tool específico para ver datos, otro para editar, y otro para eliminar.
23
2.3.5 Comunicación La comunicación entre la aplicación y la plataforma quedaría resumida de la siguiente forma. La APP hace una llamada desde COCOA a los servicios REST que se encargan de traducir esa llamada a una petición a los servicios web (SOAP) de la plataforma BBLearn. Ésta sirve los datos solicitados por los servicios SOAP devolviéndoselos al middleware, y por último, se devuelve la respuesta en formato JSON a COCOA. La aplicación móvil se encargará del posterior tratamiento de los datos.
Figura 5. Diagrama proyecto
2.3.6 Clases y cómo generarlas Blackboard proporciona gran cantidad de servicios web diferentes, las clases tienen un gran número de métodos para obtener, actualizar y añadir datos en el sistema. Estas clases deben ser generadas por el desarrollador. En esta sección se explica cómo generarlas y para que sirve cada una.
24
Explicación de las clases Para usar de modo correcto las clases se debe saber lo que cada una puede hacer y como la aplicación cliente puede usar una clase del servicio web en particular. En la siguiente tabla se muestra resumidamente las servicios que se van a usar y lo que puede hacer cada una de ellos: Nombre Servicio Web Uso
Context
Crea sesión en el sistema Blackboard Iniciar sesión con usuario y contraseña autorizada o con proxy tool previamente autorizado. Registrar un proxy tool para poder ser autorizado por el administrador de la plataforma. Debe ser usado para inicializar la sesión.
Course
Se usa para obtener información sobre los cursos, así como para actualizar y crear cursos.
User
Se usa para obtener, actualizar, añadir información sobre usuarios.
Content
Se usa para obtener, actualizar y añadir información sobre el contenido de un curso
Gradebook
Se usa para obtener, actualizar y añadir calificaciones en un curso dado.
Calendar
Se usa para obtener, actualizar y añadir elementos al calendario, pudiendo ser calendario personal, de un curso, o de la
25
institución
Announcement
Se usa para obtener, actualizar y añadir anuncios en la plataforma
A continuación, se muestra una lista de las principales clases que se van a usar en el cliente y lo que cada una puede hacer. Por desgracia, desde junio de 2011, Blackboard no ha publicado una guía de usuario de los servicios web detallando para lo que cada uno puede ser utilizado y cómo usarlo. Nombre de la Clase Uso
ContextWS
Interface que contiene los principales métodos para crear la sesión en la plataforma. Requeridos para poder usar cualquier otro servicio web. Entre ellos destacan logginTool y loggin.
LoginTool
Clase usada por el servicio Context para loguear el cliente con la Herramienta proxy correspondiente.
UserWS
Interface que contiene los principales métodos para acceder y actualizar todo tipo de usuarios. Uno de los mas importantes es getUser que devuelve un array de UserVO.
UserVO
Representa los datos de un usuario de la plataforma
UserFilter, CourseFilter, ContentFilter, ScoreFilter, ColumnFilter
Se usan como criterio de búsqueda de usuarios/ cursos/ contenidos/ Calificaciones/ Columnas/ Calendarios
CoursesWS Interface que contiene los principales métodos para acceder y actualizar los
26
cursos. Métodos como createCourse, deleteCourse o getCourse.
CourseVO Representa los datos de un curso
ContentWS
Interface que contiene los principales métodos para acceder y actualizar el contenido de un curso. Métodos como removeContent, createContent, getContent
ContentVO
Representa los datos del contenido de un curso
GradebookWS
Interface que contiene los métodos para acceder a las calificaciones.
ScoresVO
Representa una celda de un libro de calificaciones. Es decir, la calificación de un usuario determinado en una columna dada y un curso determinado.
ColumnVO Representa la comuna de una calificación
CalendarWS
Interface que contiene los métodos para acceder y actualizar los elementos del calendario
CalendarVO Representa los datos de un elemento del calendario
Acceso a los servicios web El acceso a los servicios web Blackboard son Simple Acces Protocol (SOAP) por lo que cualquier aplicación que vaya a consumirlos debe crear un envoltorio SOAP con los nodos apropiados para hacer una petición al servicio web. La aplicación, por su parte, deberá interpretar el envoltorio SOAP de respuesta.
27
Se usarán las clases generadas para crear los envoltorio SOAP correspondientes y así poder centrarnos en el desarrollo, creación y procesamiento de los objetos y no centrarnos en los detalles técnicos referidos a crear el envoltorio SOAP. Primero, se generan las clases JAVA del cliente a partir de los WSDL suministrados por los servicios web de Blackboard, para luego poder interactuar con ellos.
Generar Clases En este apartado se explican los pasos a seguir para la generación de las clases a partir de los ficheros WSDL que proporciona la plataforma. Para ello se usará el framework Axis2 y Rampart Module incluyendo la característica WS-‐Security. (protocolo de comunicación que suministra un medio para aplicar seguridad en los servicios web). Como se ha mencionado antes, para poder generar las clases deben estar activados y detectables los servicios web de la plataforma. Pudiendo ser accesibles los ficheros WSDL para su transformación a clases Java. Descargamos Axis2 de sus página web http://axis.apache.org/axis2/java/core/ y se descomprime el zip en un directorio especifico del equipo ya que se necesitará más adelante. Instalado el framework Axis2 se declaran las siguientes variables de entorno, las cuales son necesarias para ejecutar el script de generación de código. AXIS2_HOME=c:\<path_to_axis2> JAVA_HOME=c:\jdk1.6.0_12
Por último, se ejecuta el script bash que proporciona el panel de administración de blackboard “sampleGenClient.sh” pasándole como parámetro la URL de acceso a nuestra plataforma web. >> ./sampleGenCliente.sh https://localhost:9877 Este script se encarga de generar las clases a partir de los ficheros WSDL que contiene la instancia de Blackboard. Como se puede apreciar en la URL, la petición de los servicios web debe ser bajo https. La máquina virtual que distribuye Blackboard para entornos de desarrollo usa el puerto 9877 para esta conexión.
NOTA. Desde hace más de un año, Balckboard Learn, con el fin de cumplir con las mejores prácticas de la industria para la protección de las comunicaciones por internet, sólo ejecuta la plataforma sobre SSL.
28
El script creará una carpeta llamada “generated” en la que quedarán almacenadas las clases java que ha generado el script.
Rampart Module (Cabeceras seguridad) Cualquier llamada a los servicios web de Blackboard requiere un envoltorio SOAP con cabeceras de seguridad. Rampart es un módulo que ayuda a añadir estas cabeceras al envoltorio SOAP. Para configurar el modulo, se descarga de http://axis.apache.org/axis2/java/rampart/ y se siguen los siguientes pasos. Añadir los siguientes archivos “.jar” en la carpeta “bin” de nuestro directorio de Axis2.
• opensaml-‐1.1.jar • rampart-‐core-‐1.4.jar • rampart-‐policy-‐1.4.jar • rampart-‐trust-‐1.4.jar • wss4j-‐1.5.4.jar • xmlsec-‐1.4.1.jar
Se copia el archivo “rampart-‐1-‐4.mar” de la carpeta “modules” de Rampart a la carpeta “repository/modules” del directorio Axis2, y por último, se edita el archivo “modules.list” de Axis2 y se añade la línea “rampart-‐1.4-‐mar”
Usando eclipse Se importan las clases generadas en el proyecto de Eclipse, así como los wrappers que Blackboard nos facilita para hacer más simple el proceso. Incluidas las clases generadas se editan las propiedades del proyecto para establecer como parámetro la variable de entorno AXIS2_HOME, ya que dependen de muchas librerías de Axis2 y Rampart. También podemos importar las librerías directamente desde el menú de propiedades del proyecto. En nuestro caso, lo haremos de este modo debido a que se tendrá conflicto con otra librería para el servicio Rest.
29
Figura 6. Librerías eclipse
Una vez realizados estos pasos, comienza el desarrollo del cliente.
2.3.7 Implementación SOAP El primer objetivo para desarrollar nuestro cliente SOAP es comprender como se debe hacer un primer acceso a los mismos. El primer paso para usar cualquier servicio web de Blackboard en el cliente es inicializar una sesión con ContextWS.initialize(). Por lo tanto, antes de hacer cualquier consulta para obtener datos de la plataforma se debe hacer uso de esta clase para configurar la parte de seguridad del envoltorio SOAP, inicializar sesión y recoger el valor ID de sesión de la instancia de Blackboard y más tarde hacer el login correspondiente. Debe hacerse uso de la clase OutflowConfiguration para añadir las cabeceras de seguridad debido a que por defecto el mensaje SOAP no las incluye. Para realizar esta llamada se debe poner usuario “session” y contraseña “nosession” en el usernametoken. Esta llamada devolverá el id de sesión que se
30
deberá incrustar en la contraseña de usernametoken con el callback para las posteriores peticiones a los servicios web. op.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_10); op.setProperty(WSHandlerConstants.PW_CALLBACK_REF,
new ClientWrapper.PasswordCallbackClass(this)); OutflowConfiguration ofc = new OutflowConfiguration(); ofc.setActionItems("UsernameToken Timestamp"); if (useAutomaticLogin()) ofc.setUser(LTI_RAW_USERNAME_PREFIX + guid); else ofc.setUser("session"); ofc.setPasswordType("PasswordText");
op.setProperty(WSSHandlerConstants.OUTFLOW_SECURITY, ofc.getProperty());
Realizados estos pasos, la aplicación puede consumir los servicios según los privilegios que se le hayan otorgado.
Funcionalidad cliente Como hemos comentado a lo largo de la memoria, se va a desarrollar un middleware servir de datos de la plataforma Blackboard a una aplicación móvil, por lo tanto, se destaca que la funcionalidad que se desarrolle en éste será la funcionalidad que obtenga la APP. El cliente está pensado para hacer servir de datos a una aplicación móvil que muestre al usuario información acerca de su perfil y asignaturas en el campus virtual, por lo que tendrá las siguientes funcionalidades: inicio de sesión para el usuario, recoger los cursos en los que está inscrito el usuario, los usuarios que componen un curso, el contenido de un curso, calificaciones de un usuario y calendario del usuario. El cliente se registrará como administrador, más adelante, en base al contexto u otro tipo de autentificación nativa, se gestionará internamente, en la aplicación externa, lo que el usuario pueda realizar.
31
“Inicio de sesión del usuario” Método que realiza la comprobación de que existe el usuario con contraseña. Se usa el método login de la clase Context. pasándole un usuario y una contraseña. Devuelve verdadero o falso según si el inicio de sesión es correcto o no. “Cursos por usuario” Método que devuelve los cursos en los que está matriculado el alumno. A este método se le pasa el usuario específico que va a realizar la consulta y devuelve un array de cursos. Para el desarrollo de este método se usan las clases Context, CourseIdVO, CourseFilter, Course. Comienza llamando al método “getMemberShips” de la clase Context, este método devuelve un vector de objetos “CourseIdVO”. Cada objeto almacena un identificador único del curso, que es un identificador externo para un curso de Blackboard. Una vez obtenidos los identificadores de los cursos del usuario se crea un objeto del tipo CourseFilter. Este objeto se usa para especificar como va a filtrar Blackboard los cursos cuando se llame al método correspondiente para la obtención de los mismos. En este caso, el filtro es “Cursos por ID”, por lo que se establece el tipo de filtro a 3, (courseFilter.setFilter(3)). Para saber los valores de cada filtro hay que mirar el JAVADOC de Blackboard. Una vez aplicado el filtro, se llama en última instancia al método getCourse (pasándole como parámetro el filtro) del servicio web Course, devolviendo un vector de objetos tipo CourseVO. Estos objetos almacenan la información correspondiente a cada curso en los que está inscrito el usuario. “Usuarios por curso” Método que devuelve los usuarios inscritos en un determinado curso. Para hacer la consulta al método se le pasa el Id de un curso especifico devolviendo un vector de usuarios. Para el desarrollo de este método se usan las clases CourseVO, CourseFilter, Course, UserFilter, UserVO. User. La cabecera del método tiene como parámetro de entrada un String identificativo del curso. Este identificador se usará como filtro de búsqueda del sistema. Se crea un objeto de tipo UserFilter y se le asigna el como tipo de filtro un entero que representa al criterio “Usuarios por curso”. A continuación se le asigna el identificativo del curso mediante el método setCourseId.
32
Por último llamamos al método getUser de la clase User, pasándole como parámetro el filtro creado anteriormente. Este método devuelve un vector de objetos del tipo UserVO , cada uno de estos objetos almacena la información correspondiente a los Usuarios inscritos en el curso seleccionado. “Contenido principal de un curso” Método que devuelve el contenido principal de un curso. En este caso, al método se le pasa tanto el Id del usuario como el Id del curso. Devuelve un vector de objetos tipo Content que contienen los datos de las carpetas principales de la asignatura. Para el desarrollo de este método se usan las clases ContentFilter y Content. Se crea un objeto del tipo ContentFilter, se le asigna el criterio de filtro “Contenido por Usuario”, ya que un usuario puede tener distinto contenido en el mismo curso, y se le asgina el ID del usuario mediante el método setUserID. Por último, se llama al método getFilteredContent pasándole el filtro y el ID del curso. Este método devuelve un vector de objetos tipo Content que almacenan la información del contenido principal de un curso. “Contenido de una carpeta” Método que devuelve el contenido de una carpeta dentro de un curso. Este método se extiende del método anterior. Este método tiene como parámetros el ID del usuario, ID del curso y el ID de la carpeta. Devuelve un vector de objetos tipo Content que contiene los datos del contenido disponible dentro de la carpeta. Para el desarrollo de este método se usan las clases ContentFilter y Content. Se crea un objeto del tipo ContentFilter, se le asigna el criterio de filtro “Contenido por usuario y contenido”, se le asgina el ID y el ID del contenido principal. Por último, se llama al método getFilteredContent pasándole el filtro y el ID del curso. Este método devuelve un vector de objetos tipo Content que almacenan la información del contenido principal de un curso. Corresponde a la aplicación que procese la información solicitada el diferenciar que tipo de contenido es, para ello el objeto Content dispone de la propiedad ContentHandler que proporciona información sobre el tipo de contenido que es. En el caso de ser una carpeta ContentHandler mostraría lo siguiente:
33
“Calificaciones del usuario por curso” Método que devuelve las calificaciones de un alumno en un curso concreto. Este método tiene como parámetros el ID del usuario y el ID del curso. Devuelve un vector de objetos tipo Score que contiene los datos de las calificaciones. Para este método se usan las clases ScoreFilter, ScoreVO y Gradebook. Se crea un objeto del tipo ScoreFilter, se le asigna al filtro el cirterio “Scores por Usuario”. Una vez creado el filtro se llama al método getGrades de la clase Gradebook, pasándole como parámetros el filtro y el identificador del curso, este método devuelve un vector de objetos del tipo ScoreVO. Cada objeto obtiene información sobre la nota de un determinado elemento del curso. “Información del elemento de una calificación (Score)” Este método viene seguido del método anterior. El método anterior devuelve un vector de Scores el cual contiene el identificador del elemento al que se le asigna la nota, pero no información sobre dicho elemento. Por lo tanto, este método devuelve información sobre dicho elemento. Tiene como parámetros el ID del curso y un ID de columna. El ID de columna viene dado en el objeto Score (calificación), representa el identificador del elemento calificado. Por lo tanto, se crea un filtro (ColumnFilter) con el criterio de “Elemento por ID” pasándole el ID de columna. Una vez creado el filtro y asignado el identificador de la columna se llama al método getGradebookColumns, pasandole como parámetros el filtro y el ID del curso, devolviendo un objeto de tipo ColumnVO. Este objeto almacena la información correspondiente al elemento calificado, como por ejemplo su nombre. “Eventos calendario alumno” Método que devuelve eventos del calendario personal de un alumno. Este método tiene como parámetros el ID del usuario. Develve un vector de objetos tipo CalendarItemVO que almacena información sobre los eventos marcados en el calendario. Para este método se usan las clases CalendarItemFilter y CalendarItemVO. Se crea un objeto del tipo CalendarItemFilter, se le asigna el criterio de filtro “Elementos por Usuario”, y el ID del usuario mediante el método setUserId.
34
Por último, se llama al método getCalendarItem pasándole el filtro. Este método devuelve un vector de objetos tipo CalendarItemVO.
2.3.8 Implementación REST En este apartado se incluye toda la documentación referida al consumo de los servicios SOAP mediante llamadas de tipo REST (Transferencia de estado representacional). En el estilo arquitectónico REST una de las principales características es que no tiene estado (stateless) lo que quiere decir que cada petición que se realiza a ellos es independiente. Todas las llamadas al mismo servicio serán idénticas.
URL´s y recursos A diferencia de SOAP, la idea de servicio desaparece. En este caso lo que se tiene son recursos. Por lo tanto, un recurso es la información a la que se quiere acceder, modificar o eliminar. La forma de acceder a un recurso es mediante URL´s, que además de permitir identificar el recurso de forma única permite localizarlo para acceder a el. El primer paso es identificar que recursos se va a usar. En este caso están definidos a partir de la funcionalidad que se ha desarrollado en los servicios SOAP. El segundo paso será asignar URL´s a los recursos que se han identificado. Existen varias reglas para estructurar la URL de un recurso:
-‐ Mantener una jerarquía lógica -‐ Ser únicas -‐ No verbosos
Anotaciones Jersey usa anotaciones para simplificar el desarrollo y despliegue del servicio web. Estas anotaciones se usan para ayudar a mapear la clase de recursos como un recurso web. Estas anotaciones son:
• @Path especifica la ruta de acceso relativa para una clase recurso o método.
35
• @GET, @PUT, @POST, @DELETE y @HEAD especifican el tipo de petición HTTP de un recurso.
• @Produces especifica los tipos de medios MIME de respuesta. • @Consumes especifica los tipos de medios de petición aceptados.
También proporciona anotaciones adicionales para extraer información de una solicitud.
• @PathParam enlaza el parámetro a un segmento de ruta. • @QueryParam enlaza el parámetro al valor de un parámetro de consulta
HTTP. • @MatrixParam enlaza el parámetro al valor de un parámetro de matriz de
HTTP. • @HeaderParam enlaza el parámetro a un valor de cabecera HTTP. • @CookieParam enlaza el parámetro a un valor de cookie. • @FormParam enlaza el parámetro a un valor de formulario. • @DefaultValue especifica un valor por defecto para los enlaces anteriores
cuando la clave no es encontrada. • @Context devuelve todo el contexto del objeto. (Por ejemplo: @Context
HttpServletRequest request)
Configuración de Jersey en el proyecto de Eclipse Descargar Jersey de https://jersey.java.net. Descargar el fichero zip que contiene los jar de la implementación y sus dependencias centrales. No proporciona dependencias de terceros más allá de las de apoyo a JSON y JavaDoc. Para empezar a hacer uso de Jersey se debe importar los ficheros “.jar” en el proyecto de Eclipse.
36
Implementación del servicio REST En este apartado vamos a describir como se define una clase con las anotaciones vistas anteriormente para implementar el servicio REST que se quiere publicar.. No se pretende explicar todas las anotaciones, únicamente las utilizadas en este proyecto. En primera instancia se debe usar la anotación @Path para definir el recurso de primer nivel de acceso a los servicios. Las URL’s son jerárquicas por lo que este será el recurso raíz. Especiicando la ruta relativa que designa a los recursos de la clase a la que anota
Cualquier servicio al que llamemos tendrá la siguiente estructura http://servidor:puerto/rest/{recurso} El siguiente nivel se encuentra en cada método que define cada recurso. Se usará la anotación @Path. Cada recurso debe tener, además del nivel de acceso, una anotación que especifique el tipo de petición HTTP que realiza el recurso pudiendo ser Get, Post, Pust, Delete o Head.
Con @PathParam anotamos parámetros del método cuyo valor es extraído de la URL de la petición. Los nombres de los parámetros corresponden con los nombres de los patrones especificados en la anotación @Path.
Servicio JSON Nuestra implementación, por le momento, sólo va a procesar peticiones de lectura para ello servirá los datos a través de estructuras JSON.
37
La construcción de un servicio que sirva una estructura JSON consiste en indicar que es una petición GET y usar la anotación @Produces para indicarle el tipo de respuesta que queremos en cada método. En nuestro caso, se le indicará MediaType.APPLICATION_JSON. Por defecto, en el caso de que no especifiquemos el tipo de respuesta, se produce texto plano MediaType.TEXT_PLAIN.
Cómo se puede observar en el trozo de código también se le puede indicar la codificación en la que queremos que nos sirva la estructura JSON.
Servicio con parámetros En muchas ocasiones se necesita pasar parámetros a peticiones de tipo GET para ello se construye la URL de la siguiente manera http://servidor:puerto/rest/recurso?nombre=pepe. Donde asignamos al parámetro nombre el valor pepe. Para interpretar esta Query disponemos de la anotación @QueryParam que identificara el parámetro que se pasa desde el cliente.
Recursos del middleware. Un apartado importante en el desarrollo de un servicio REST, es tener claros que recursos se va a tener. A continuación se detallan los que se publicaran en nuestra API REST.
38
/rest/Login/:user?:pass Envía una petición con el usuario y contraseña del usuario. Si es valido devuelve un esquema JSON con los datos del usuario de forma extendida.
/rest/User/:uer Envía una petición con el nombre un usuario. Devuelve la información de dicho usuario.
/rest/Courses/:user Envía una petición con el nombre de un usuario. Devuelve un esquema JSON con los cursos en los que está inscrito ese usuario.
/rest/Users/:course Envía una petición con el identificativo de un curso. Devuelve un esquema JSON con los usuarios que están inscritos en ese curso.
/rest/Content/:course?:user Envía una petición con el identificativo de un curso y el identificativo de un usuario concreto. Devuelve un esquema JSON con el contenido principal del curso para ese usuario.
/rest/ContentFolder/:folder?:course&:user Envía una petición con el identificativo de una carpeta del curso, el identificativo del curso y el usuario. Devuelve el contenido de la carpeta del curso para el usuario concreto.
2.4 Pruebas Tan y como se ha desarrollado en el apartado de diseño de pruebas se han realizado pruebas unitarias y de integración. A continuación se muestran algunas de las pruebas realizadas en el transcurso del proyecto.
39
Pruebas unitarias: Prueba Login Grupo Middleware Descripción Identificar al usuario. Devuelve todos los datos del usuario Resultado Correcto Comentarios Obtiene un funcionamiento correcto. El usuario consigue validar
su identidad correctamente Prueba Listado asignaturas Grupo Middleware Descripción Realiza una petición de las asignaturas de un usuario concreto
Crea un filtro para devolver las asignaturas en las que esta matriculado el alumno. Hace la correspondiente llamada a los servicios SOAP para obtener los resultados
Resultado Correcto Comentarios Obtiene un funcionamiento correcto. Si el usuario no existe no
devuelve nada. Se parte de la premisa de que el usuario siempre va a existir. Se usa siempre después de identificar al usuario.
Prueba Contenido de una asignatura Grupo Middleware Descripción Realiza una petición del contenido de una asignatura y usuario
concretos. Crea un filtro con el usuario y la asignatura
Resultado Correcto Comentarios Obtiene un funcionamiento correcto. Si el usuario no existe no
devuelve nada. Se parte de la premisa de que el usuario y la asignatura siempre van a existir. Se usa siempre después de identificar al usuario y sus asignaturas.
Pruebas de integración: Prueba Uso de varias funcionalidades Grupo Middleware Descripción Identifica al usuario
Muestra asignaturas del usuario Contenido de las asignaturas Notas del usuario por asignatura Calendario del usuario
Resultado Correcto Comentarios Obtiene un funcionamiento correcto
40
3. Creación de APP Una vez desarrollado el middleware tenemos acceso a los servicios web de blackboard desde cocoa. Para la implementación de la APP se va a usar el entorno de desarrollo XCode propio de los sistemas de Apple.
3.1 Análisis En este apartado se encuentran los aspectos más importantes del análisis realizado para el desarrollo de la app móvil para terminales iOS.
3.1.1 Requisitos funcionales y no funcionales
Requisitos funcionales En la app se identifican los siguientes requisitos funcionales.
o La app será un sistema con el que el usuario interactúe con los datos asociados a el en la instancia de Blackboard..
o El usuario deberá loguearse para poder hacer uso del resto de las funcionalidades.
o Una vez logueado el usuario podrá acceder a tres secciones principales: Asignaturas, calificaciones y calendario.
Requisitos no funcionales
Requisitos de los usuarios Para poder acceder a todas las funcionalidades de la app el usuario deber autentificarse mediante usuario y contraseña.
Requisitos tecnológicos.
o Es imprescindible tener conexión a internet para el funcionamiento de la app y el middleware.
o La aplicación está dirigida a terminales móviles iOS.
41
o La aplicación debe adaptase a las diferentes resoluciones que componen la gama de terminales iOS.
Requisitos de interfaces
o La aplicación debe tener una interfaz de uso intuitiva y sencilla, además de marcar un estilo minimalista siguiendo la dinámica que Apple quiere para sus aplicaciones.
o La aplicación debe tener un aspecto similar al estilo de diseño de la versión web de La Universidad de La Rioja.
3.2 Diseño En este apartado se definen todas las decisiones tomadas a lo largo del desarrollo del proyecto en cuanto al diseño de la arquitectura del sistema y la interfaz de la aplicación iOS.
3.2.1 Diseño interfaz aplicación iOS En esta sección se exponen los prototipos realizados para la aplicación. En una primera instancia se optó por realizar modelos de bajo nivel con el fin de tener una primera idea fundamental del funcionamiento de la aplicación. Para ello se realizaron los siguientes bocetos a papel y lápiz. La ventana principal de la aplicación será una ventana de autenticación del usuario. En esta pantalla el usuario deberá autentificarse mediante usuario y contraseña. Para eso debe estar dado de alta por el servicio técnico/administrador de la plataforma. Una vez autenticados pasamos a la segunda pantalla.
42
En esta segunda pantalla se mostrará una lista con los cursos en los que están matriculados los usuarios, así como un menú inferior con las distintas secciones a las que se puede acceder. Pulsando cualquier curso de la lista se accederá al contenido principal de mismo abriéndose otra pantalla.
Esta pantalla vuelve a ser un listado, en este caso se muestran los contenidos principales del curso. Al pulsar sobre cualquier contenido principal se accederá de nuevo a otra pantalla que mostrará el sub-‐contenido de la misma.
43
Como se ve en la imagen, en esta pantalla aparecerán los distintos contenidos que puede tener el curso, distinguiendo el tipo de contenido a través de imágenes identificativas. En el menú inferior que se ha mencionado anteriormente tendremos las siguientes opciones:
-‐ Cursos -‐ Calificaciones -‐ Calendario -‐ Perfil de usuario
Cuando se pulsa sobre el menú de calificaciones aparecerá una pantalla mostrando los distintos cursos en los que el usuario esta inscrito. Al pulsar un curso en concreto aparecerá un tabla con las calificaciones del usuario para ese curso.
44
En el apartado de Calendario aparecerá un listado con las tareas registradas en el calendario de la plataforma. En el apartado Perfil de Usuario aparecerán todo los datos del usuario.
Figura 7. Prototipo pantalla calificaciones y calendario
3.2.2 Diagrama de navegación La aplicación se ha planteado para que sea fácil e intuitiva. Una vez iniciada la sesión, en la correspondiente ventana, se podrá acceder al menú principal. Desde este menú se tendrá acceso a todas las opciones. El diagrama de navegación de la aplicación quedaría de la siguiente manera.
45
Figura 8. Diagrama navegación
3.3. Implementación
3.3.1 Generar clases para Objective C El middleware nos devuelve los datos en JSON siguiendo la estructura de las clases JAVA generadas anteriormente. Con el fin de perder menos tiempo y agilizar el proceso de implementación de la aplicación se decide generar las clases a partir de los WSDL y no crear manualmente las clases a partir de lo que nos devuelven los JSON. Para ello usamos WSDL2JObjC. Para generar código con esta herramienta sólo debemos seguir los siguientes pasos.
o Lanzar la aplicación o Buscar el fichero WSDL o copiar la URL donde este alojado.
46
o Seleccionar el directorio donde queremos que genere nuestro código o Hacer click en “Parse WSDL”
Generado el código tenemos que importarlo en nuestro proyecto y podremos trabajar con el.
3.3.2 Uso de librería RestKit Para realizar las correspondientes llamadas a los servicios REST se ha decidido usar la librería RestKit. Es un framework moderno de Objective C para implementar clientes de servicios web RESTful tanto en iOS como en Mac OS X. Está diseñada para hacer un desarrollo más sencillo proporcionando un sistema para manejar el modelo de datos de la aplicación con las estructuras JSON y XML devueltos por el servicio web. Reskit es una librería que se compone de varios elementos individuales. A continuación se detallan los componentes más importantes..
Object Mapping Es uno de los piezas más importantes. Nos ofrece un sistema de mapeo de objetos haciendo una transformación de estos entre las representaciones clave-‐valor de la estructura JSON
AFNetworking Es una librería de redes. Extiende potentes abstracciones de las redes de alto nivel integradas en COCOA.
Networking. Proporciona la integración entre Object Mapping y las redes HTTP proporcionadas por AFNEtworking
3.3.2.1 Instalación RestKit vía CocoaPods
¿CocoaPods? En la actualidad existen multitud de repositorios con librerías de código abierto para incluir en nuestro proyecto. CocoaPods nos gestiona fácilmente estas librerías, actualizando por nosotros cada una de las librerías. ( como Apache Maven en J2EE).
47
Instalación Para instalar CocoaPods deberemos escribir el siguiente comando en nuestro terminal $ [sudo] gem install cocoapods
$ pod setup Una vez instalado CocoaPods creamos un fichero llamado Podfile $ vi Podfile Escribimos lo siguiente en nuetro Podfile para que incluya la librería RestKit que es la que se quiere. platform :ios, 6.0
pod 'RestKit', '~> 0.20.0rc'
# Include optional Testing and Search components pod 'RestKit/Testing', '~> 0.20.0rc' pod 'RestKit/Search', '~> 0.20.0rc'
Por último invocamos CocoaPods desde nuestro terminal para instalar las dependencias. $ pod install Una vez generadas las clases e incluidas las librerías correspondiente para consumir servicios REST comenzamos el desarrollo de la aplicación.
48
3.3.3 Interfaz gráfica Xcode introdujo lo que Apple llama StoryBoard desde el lanzamiento de iOS 5. Es una herramienta que permite hacer las interfaces de manera más sendilla e intuitiva. Una característica a destacar es que permite observar la navegabilidad entre distintas pantallas sin tener que estudiar el código. Para el desarrollo de la interfaz gráfica se ha intentado seguir la línea de Apple haciendo una aplicación minimalista y con listados. También se ha querido seguir el estilo de patrones de colores de la Universidad de La Rioja.
3.3.4 Implementación funcionalidad Este bloque expone los aspectos más importantes implementados en la funcionalidad de la aplicación móvil. Una vez tenemos el modelo de datos y el diseño comenzamos la implementación de la funcionalidad. La aplicación desarrollada se encarga de recibir datos a partir de peticiones web concretas. El usuario realiza estas peticiones a través de la interfaz sin darse cuenta. Por ejemplo, si el usuario pulsa el enlace de acceso a los cursos la aplicación realizará una petición al middleware para obtener los cursos del usuario.
49
Inicio aplicación Se realizarán peticiones web a partir de la Api Rest desarrollada en el middleware. Para implementar estas peticiones se ha usado la librería ResKit y la clase appDelegate.m AppDelegate es un fichero que se crea al generar un nuevo proyecto de desarrollo para iOS en Xcode. Se encarga de manejar eventos globales o tareas a realizar según los estados de la aplicación. Por ejemplo al arrancar la aplicación. En nuestro caso, al iniciar la aplicación se inicia un cliente HTTP con la URL del middleware. Todas las peticiones se añadirán a esa URL. Este cliente se pasa al crear el objeto RKObjectManager que es la interfaz principal para trabajar con los servicios REST.
50
Mapeo de los objetos Las peticiones web reciben como respuesta esquemas JSON que coinciden con las clases generadas para ObjectiveC. RestKit ofrece una clase para hacer de manera sencilla el mapeo de JSON a objetos locales. Esta clase se llama RKObjectMapping. Hay dos formas de indicarle como debe mapear los objetos. En nuestro caso se va a usar la menos automática pero la más eficaz y rápida en procesamiento. Se le indica a la case RKObjectMapping la correlación entre los atributos del JSON y los atributos de nuestro modelo de datos.
Peticiones Para declarar cada una de las peticiones se usa la clase RKResponseDescriptor que nos proporciona RestKit. Se le asigna principalmente el recurso de la petición y la descripción del mapeo del objeto Por ultimo, se agregará el objeto al administrador de objetos (RKObjectManager) para así poder usar la petición en cualquier momento del desarrollo.
Interfaz gráfica y controladores Como se ha mencionado anteriormente, se ha usado la tecnología de StoryBoard de xCode para crear la interfaz gráfica de la aplicación.
51
De este modo a cada vista o pantalla se le asigna un controlador. Como se puede observar, Apple nos “obliga” a usar el patrón MVC (Modelo-‐Vista-‐Controlador).
El controlador será en encargado de plasmar los datos obtenidos en sus respectiva vista. Por lo tanto, en cada controlador se hará la correspondiente petición al recurso o petición solicitada para esa pantalla.
52
53
4. Seguimiento del proyecto La primera etapa del proyecto se dedica a la planificación del mismo. Siguiendo la metodología Scrum se define una pila de producto y se asocian las tareas para cada Sprint . Además, según indicaciones del tutor del proyecto se redacta el análisis para el desarrollo del proyecto. A continuación se detallan los sprint’s que se han seguido a lo largo del proyecto:
Sprint 1: Configuración entorno de desarrollo y plataforma BBLearn. 60 horas
Objetivo En este primer sprint se intentará levantar y configurar una plataforma de Blackboard propia para el desarrollo personalizado del proyecto. También se configurará los servicios web para la comunicación con la plataforma.
Tareas
Análisis y estudio de las distintas alternativas para realización del proyecto. Se estudiarán LTI, Bulding Blocks y servicios web con el fin de decantarse sobre una de ellas para la realización del proyecto.
Levantamiento y configuración BBLearn. Puesta en marcha y configuración de un aula virtual propia para las pruebas del desarrollo
Estudio panel de administración BBLearn. Una vez puesta en marcha nuestra plataforma, comprender el uso del panel de administración de la misma.
Creación de usuarios, cursos y otros elementos en la plataforma. Inserción de distintos elementos en el aula virtual para su posterior uso en las pruebas de desarrollo.
Configuración Servicios Web en BBLearn y entorno de desarrollo de los mismos. Configuración del acceso a los servicios web de Blackboard para su posterior uso en el entorno de desarrollo.
54
Configuración Proxy Tool. Creación y configuración del Proxy Tool (herramienta proxy) para inicializar sesión a partir de los servicios web.
Pila del producto Tarea Tiempo Análisis y estudio de alternativas
20
Levantamiento y configuración BBLearn
28
Estudio panel admin BBLearn
3
Creación de usuarios, curso y otros elementos
2
Configuración S. W y entorno desarrollo
5
Configuración Proxy Tool
2
Total 60 horas
Sprint 2. Desarrollo cliente Servicios Web. 62 horas
Objetivo Instalada la plataforma de BBLearn y el entorno de desarrollo, queda por configurar el Proxy Tool y comenzar con el despliegue y desarrollo de la funcionalidad deseada a partir de los servicios web que nos ofrece Blackboard.
55
Tareas
Configuración proxy tool (pendiente sprint anterior)
Generación y estudio de las clases Generación de las clases usadas por los servicios web a partir de de los ficheros WSDL con la herramienta WSDL y estudio de las mismas
Comprensión de los wrappers de Blackboard Comprensión y aprendizaje de uso de los wrappers que la plataforma deja a disposición de los desarrolladores.
Estudio API Blackboard Comprensión y estudio de la API http://library.blackboard.com/ref/8c09eac0-‐db9b-‐4c1f-‐839a-‐69ce42234bdf/index.htm
Implementación de la funcionalidad deseada para los Servicios Web.
-‐ Cabeceras seguridad mensaje SOAP -‐ Login usuario. -‐ Asignaturas por usuario. -‐ Contenido asignatura. -‐ Usuarios por asignatura. -‐ …
Prueba inicial de despliegue servicios SOAP axis Pruebas generales para la implementación especifica de los servicios.
Pila de producto Tarea Tiempo Configuración Proxy Tool
2
Generación clases servicios web
4
Comprensión wrappers
3
Estudio API Blackboard
5
45
56
Implementación servicios web Pruebas
3
Total 62
Sprint 3. Implementación servicios REST y despliegue. 40 horas
Objetivo Terminar la implementación especifica para los servicios web y pruebas de los mismos. Estudiar los distintos framework para la implementación REST y comenzar el desarrollo.
Continuación implementación servicios web Continuación de desarrollo de la funcionalidad deseada para los servicios web del middleware
Continuación pruebas servicios web Pruebas de los nuevos servicios implementados en este sprint
Estudio framework’s REST. Estudio y elección del framework a usar en para los servicios REST
Implementación servicios Rest usando cliente BBLearn Desarrollo servicios REST que hagan de cliente traductor para las llamadas a los servicios web correspondientes
Pruebas Pruebas generales y búsqueda de posibles errores
Corrección de errores Corrección de los errores encontrados en las pruebas generales.
Pila de producto Tareas Tiempo Implementación servicios web
5
Pruebas 5
57
Estudio framework’s REST
15
Implementación servicios REST
15
Pruebas
3
Corrección de errores
3
Total 46
Sprint 4 . Desarrollo pequeña APP. 50 horas
Objetivo Hacer una pequeña APP para iOS usando el middleware desarrollado en los sprint’s anteriores, haciendo las correspondientes llamadas a los servicios para obtener los datos de la plataforma BBLearn.
Tareas
Desarrollo Layauts Generar las pantallas principales de la aplicación siguiendo el estilo minimalista de iOS.
Navegabilidad entre layauts Definir las transiciones entre los distintos layauts de la aplicación
Estudio librería Reskit Aprendizaje del framework Reskit para la implementación de cliente REST en cocoa.
Instalar RestKit Instalación de RestKit a traveces de CocoaPods
Llamadas a los servicios REST Implementación del cliente REST de la APP usando el framework RestKit y obteniendo respuestas JSON
Transformación respuesta de las llamadas REST Mapear las respuestas JSON a objetos de Objective C.
58
Tareas Tiempo Desarrollo de layauts
10 horas
Navegabilidad entre layauts
5 horas
Estudio librería RestKit
5 horas
Implementación llamadas Rest
12 horas
Login
3 horas
Pantalla de cursos
3 horas
Pantalla contenido curso
3 horas
Pantalla calificaciones
3 horas
Pantalla calendario
3 horas
Total 47 horas
Sprint 5. Pruebas generales. 20 horas
Objetivo Realizar pruebas generales del funcionamiento del middleware junto con la aplicación. Hacer correcciones de los posibles fallos.
Tareas
Prueba de la APP Pruebas generales del funcionamiento de la aplicación: respuestas JSON, navegabilidad entre pantallas.
59
Corrección de errores Corrección de pequeños errores en el desarrollo tanto del middleware como de la aplicación.
Documentación Escribir documentación sobre el desarrollo del proyecto. Tareas Tiempo Prueba APP
12 horas
Corrección errores
3 horas
Documentación
5 horas
Total 20 horas
5. Conclusiones En este apartado se recogen las conclusiones recabadas a lo largo del proyecto, así como las lecciones aprendidas y futuras mejoras.
5.1 Objetivos Al comenzar el proyecto se hizo un estudio de las diferentes formas de hacer un desarrollo especifico para Blackboad. También se contactó con desarrolladores de la plataforma para escoger la forma idónea de llevar a cabo el proyecto. El resultado de este estudio fue escoger los servicios SOAP para hacer el desarrollo del mismo. A lo largo de la implementación nos hemos encontrado con varios problemas – inconvenientes para realizar la funcionalidad deseada. Los servicios web que ofrece la plataforma están orientados al uso del administrador, por lo que a la hora de interactuar con ellos a modo de usuario se ha tenido que buscar distintas soluciones para hacer la conveniente simulación. Aún con los inconvenientes se ha conseguido cumplir el objetivo principal del proyecto, ya que se ha creado un middleware y una app que permite al usuario acceder a los distintos contenidos de su aula virtual. El objetivo principal era conseguir comunicación con el aula y recoger datos para mostrarlos en la app.
60
En cuanto a objetivos extras, se ha conseguido cumplir a medias. Según se iba realizando la aplicación para iOS surgió la idea de mostrar los diferentes archivos de los contenidos de las asignaturas. Los servicios web no permiten obtener los enlaces de estos contenidos, lo máximo que nos permite es obtener el titulo y extensión de los ficheros.
5.2 Futuras mejoras Como posibilidad de mejoras del proyecto se propone las siguientes funcionalidades:
-‐ Realizar entregas de trabajos y tareas. -‐ Ver archivos adjuntos.
6. Bibliografía
-‐ Manuales y tutoriales para el uso de los servicios web de Blackboard o www.oscelot.org o www.edugarage.com o http://www.brucephillips.name
-‐ Documentación blackboard o https://help.blackboard.com
-‐ Libros para comenzar a desarrollar en iOS
o Aprende iOS – Juan M. Cigarran o Beginning iOS 7 Development Exploring the iOS SDK
-‐ Otros o http://stackoverflow.com o http://es.wikipedia.org/wiki/Wikipedia:Portada