Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No.

3, 2010

Moodle 2.0 y las nuevas plataformas de aprendizaje orientadas a servicios1

Miguel A. Conde
Departamento de Informtica y Automtica. Instituto Universitario de Ciencias de la Educacin (IUCE). Grupo de investigacin GRIAL. Universidad de Salamanca [email protected]

Alberto del Pozo

Departamento de Informtica y Automtica. Instituto Universitario de Ciencias de la Educacin (IUCE). Grupo de investigacin GRIAL. Universidad de Salamanca [email protected]

Francisco J. Garca
Departamento de Informtica y Automtica. Instituto Universitario de Ciencias de la Educacin (IUCE). Grupo de investigacin GRIAL. Universidad de Salamanca [email protected]

Resumen
El imparable avance de las nuevas tecnologas ha puesto de manifiesto la necesidad de actualizacin de las plataformas de aprendizaje. Esa actualizacin se basa en la incorporacin de nuevas funcionalidades para satisfacer las nuevas necesidades de los usuarios. Una de las formas en que poder llevarlo a cabo pasa por la evolucin de los entornos de aprendizaje hacia las Arquitecturas Orientadas a Servicios (SOA, Service Oriented Architecture). Estas arquitecturas, implementadas principalmente en forma de servicios web, permitirn la creacin tanto de clientes como de herramientas externas que puedan interoperar con la plataforma, ampliando sus posibilidades y proporcionando una libertad de movimiento a los usuarios que antes no tenan. Moodle 2.0 ser un ejemplo de esa evolucin y en el presente artculo se vern alguna de las nuevas posibles aplicaciones a incorporar.

1. Motivacin
El gran avance tanto cientfico como tecnolgico que se est produciendo en la sociedad durante los ltimos aos ha provocado que se deban de buscar nuevas formas de hacer llegar la enseanza a todos los usuarios [6, 7]. El eLearning supone un planteamiento diferente de los procesos de aprendizaje y por tanto introduce nuevas necesidades. Estas van a verse respaldadas por las plataformas de aprendizaje. Mientras que hace tan solo unos aos el poder acceder al aprendizaje a
Tabla 1.
1

travs de un ordenador era considerado un gran avance tecnolgico, ahora el poder acceder a l a travs de estos dispositivos se queda corto, creando la necesidad de tener toda la informacin que se desee cuando se desee, es decir, tener a mano en todo momento el conocimiento. Sin embargo no siempre las plataformas sern capaces de satisfacer estos requisitos. Otro problema de estas plataformas es que son demasiado genricas, poco adaptadas a circunstancias especializadas y son pocos escalables modularmente [5] dificultando de esta manera la posibilidad de aadirle funcionalidades propias a la plataforma, limita el desarrollo y la sostenibilidad de los LMS (Learning Management Systems, plataformas de aprendizaje). Aadido a todo esto debe considerarse que, en la mayor parte de los casos, la potencia de los LMS no se aprovecha totalmente, es decir, muchas de las funcionalidades de las plataformas de aprendizaje son ignoradas convirtindose en muchos casos en meros contenedores de recursos [4][12][20]. Por eso surgen una serie de proyectos que pretenden dotar de cierta independencia a estas plataformas de eLearning (por ejemplo Moodle) para que de esta manera dejen de ser plataformas monolticas y cerradas, es decir, de difcil evolucin y cuya interaccin con otros sistemas sea mnima. Se busca concretamente aportar capacidad de evolucin y crecimiento independiente de la tecnologa. Esta independencia se consigue mediante la implementacin de unos servicios web que permitan la conexin con la plataforma de una manera externa, aunque antes de llegar a los

Este trabajo est subvencionado por el Ministerio de Industria Turismo y Comercio (proyecto TSI-020302-2009-35 y proyecto TSI-020302-2009-35) y por la Junta de Castilla y Len a travs del proyecto de excelencia GR47.

ISSN 1988-3455

SISTEDES, 2010

45

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

servicios web, se debe comprender como se estructuran y se fundamenta su uso, esto es, las arquitecturas SOA Este artculo por lo tanto esta organizado de la siguiente forma. El punto 2 habla acerca de SOA y sus posibilidades, entrando tambin en la relacin entre SOA y los servicios web. El punto 3 analiza la inclusin de los servicios web dentro de la nueva versin de Moodle, la 2.0, que estar disponible prximamente trayendo consigo bastantes novedades. Adems explicando de manera detallada un servicio y una herramienta de backoffice creada para su prueba, explicando tambin algunos trabajos relacionados con los servicios web.

2. SOA
De cara a la comprensin del presente artculo es preciso definir qu es la Arquitectura Orientada a Servicios. Se trata un paradigma o concepto de arquitectura de software que se basa en la creacin de un conjunto de servicios, de diferente granularidad, entre los procesos de negocio y las aplicaciones [18]. Esta arquitectura tiene como objetivos principales: Modelar la lgica de negocio como servicios para poder expresar la capa de negocio mediante la facilidad que ofrece la orquestacin de los mismos. Crear una capa de servicios que ofrezca la funcionalidad de la capa de aplicacin de forma independiente de la tecnologa que la soporta. Minimizar las dependencias entre la capa de negocio y la de aplicacin para desacoplar el negocio de la tecnologa, y de este modo permitir los cambios en cualquiera de ellas. El objetivo sera favorecer la agilidad para el negocio. Para comprender claramente el concepto de Arquitectura Orientada a Servicios en primer lugar debe considerarse qu significa el concepto de Arquitectura en el mbito del software. Segn la IEEESTD-1471-2000 (Prctica Recomendada Para La Descripcin Arquitectnica De Sistemas De Software Intensivos) la arquitectura es la organizacin fundamental de un sistema integrado en sus componentes, la relacin entre ellos y el medio, y los principios que establecen su desarrollo y evolucin [11].

Tambin puede entenderse una arquitectura como la estructura global del software y las formas en que esa estructura proporciona integridad conceptual a un sistema [19] o bien como la estructura lgica y fsica de un sistema, forjada por todas las decisiones de diseo estratgicas y tcticas aplicadas durante el desarrollo[3]. En cualquiera de las definiciones aportadas se considera la arquitectura como la organizacin estructural de los componentes de un sistema, este tipo de organizaciones van a evolucionar vinculadas al planteamiento del modelo de negocio que a su vez se ver condicionado por la evolucin de la tecnologa. Como ejemplo de esas evoluciones puede observarse como las estructuras de negocio cambian de un modelo de jerarquizacin vertical, a uno horizontal y multidisciplinar, para posteriormente pasar un modelo de tipo ecosistema en el que las reas implicadas no se comunican solo entre las reas ms prximas. Una vez explicado el trmino Arquitectura, se tiene que conocer tambin el de servicio. Existen diferentes planteamientos acerca de lo que son los servicios. Pueden considerarse desde un punto de vista de negocio como Una funcionalidad construida como un componente reusable para ser utilizado en un proceso de negocio [9] o desde un punto de vista tcnico como elementos autodescritos e independientes de plataforma que soportan la composicin rpida, barata y distribuida de aplicaciones [14]. En cualquiera de los casos los servicios sern provistos por aplicaciones o proveedores de servicios de cara a proporcionar una funcionalidad sin desvelar su implementacin. Esto supone la definicin de una interfaz para su publicacin. Teniendo en cuenta todo esto, las caractersticas deseables para un servicio seran: Tecnolgicamente neutral. Los Servicios no solamente deben ser independientes de cualquier tipo de implementacin sino que deben de poder ser invocados de una forma lo ms estndar posible. Bajo acoplamiento. No debe requerirse ningn conocimiento de la estructura interna o externa del servicio en ningn contexto del mismo (ni en el lado del cliente ni en el del servidor). Descubrimiento transparente. La funcionalidad expresada por los servicios

ISSN 1988-3455

SISTEDES, 2010

46

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

debe estar disponible en diferentes repositorios para su localizacin y difusin. Calidad de servicios. Los servicios deben ser capaces de ofrecer la funcionalidad expresada con un nivel cualitativo adecuado de cara a que su reutilizacin sea posible en diferentes contextos. Debe existir la posibilidad de trabajar con un servicio de forma individual o formando parte de una composicin de estos en busca de una funcionalidad ms completa. La idea principal, por tanto, de esta arquitectura es que conviene ordenar la forma en que se comunican las distintas partes de un sistema. Para conseguir este objetivo se define una capa de servicios con el que los sistemas interactan, evitando as el trabajar de manera directa entre ellos, favoreciendo la interoperabilidad y la escalabilidad. De esta manera, si dos sistemas desean comunicarse, no necesitan conocer el funcionamiento del otro, sino que utilizarn esta capa de servicios como intermediaria, la cual s conoce como funcionan estos sistemas. Si en algn momento se desea sustituir o realizar algn cambio en alguno de los dos sistemas, la accin sera independiente del otro, ya que se han desarrollado de manera que no dependan del otro sistema, sino que slo dependen de los datos que devuelven [1]. Esta forma de relacionar componentes aporta las siguientes ventajas: i) Permite sustituir componentes individuales sin que eso afecte a otros componentes ii) Todos los sistemas se conectan al bus de la misma forma, con lo que se gana en homogeneidad iii) Facilidad en la operacin y mantenimiento iv) Arquitectura sencilla, robusta y escalable. 2.1. SOA y los servicios Web Es importante conocer que SOA no es un sinnimo de servicios web. Mientras que SOA es un paradigma de desarrollo (y estrategia de TI), los servicios web son una de las posibles tecnologas que se pueden utilizar para implementar SOA, aunque hay que destacar que la implantacin de SOA est siendo mucho ms rpida gracias a los servicios web y que stos se estn convirtiendo en el estndar de facto para la implementacin de estas arquitecturas.

Una vez vista la diferencia entre SOA y los servicios web, se va a tratar de describir este ltimo. Cabe destacar que existen varias posibles definiciones acerca de lo que son los servicios web, lo que muestra su complejidad a la hora de dar una explicacin adecuada de todo lo que son e implican. Una posible sera hablar de ellos como un conjunto de aplicaciones o de tecnologas intercambian datos entre s con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a esos procedimientos a travs de la web [21]. Estos servicios proporcionan mecanismos de comunicacin estndares entre diferentes aplicaciones, que interactan entre s para presentar informacin dinmica al usuario. El uso de los servicios web proporciona una serie de ventajas (muchas de las cuales derivan de las ventajas de implementar una Arquitectura Orientada a Servicios) como son: Promueven la interoperabilidad ya que la interaccin entre un proveedor y un solicitante de servicio est diseada para que sea completamente independiente de la plataforma y del lenguaje. Fomentan los estndares y protocolos basados en texto, que hacen ms fcil acceder a su contenido y entender su funcionamiento. Al apoyarse en HTTP, los servicios web pueden aprovecharse de los sistemas de seguridad firewall sin necesidad de cambiar las reglas de filtrado. Reducen la complejidad por medio del encapsulamiento, ya que los solicitantes y los proveedores del servicio se preocupan por las interfaces necesarias para interactuar. Como resultado, un solicitantes de servicio no sabe cmo fue implementando el servicio por parte del proveedor, y ste, a su vez, no sabe cmo utiliza el cliente el servicio. Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estndar y abiertos ya que las especificaciones son gestionadas por una organizacin abierta, la W3C.

ISSN 1988-3455

SISTEDES, 2010

47

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

2.2. Arquitectura SOA en eLearning De cara a incorporar interoperabilidad en las plataformas de aprendizaje y hacer a estas flexibles y escalables es necesaria la definicin de una nueva generacin de plataformas de aprendizaje. Este tipo de plataformas se van a asentar en las Arquitecturas Orientadas a Servicios. Este tipo de solucin proporcionar una separacin entre la interfaz de un servicio y su implementacin subyacente. No ser relevante que una aplicacin que se quiera conectar a una plataforma est implementada en una tecnologa diferente del core del LMS. SOA aporta independencia en la evolucin del software permitiendo la incorporacin de nuevas funcionalidades independientemente de la versin del LMS subyacente. Dentro de las posibles aplicaciones de las arquitecturas SOA deberan considerarse diferentes enfoques: Uso de las arquitecturas SOA para proporcionar informacin a contextos externos. Como podra ser el uso de arquitecturas orientadas a servicios para bsquedas semnticas de informacin sobre la plataforma de aprendizaje, como el proyecto LUISA [10]. Adaptacin ligera de plataformas de aprendizaje a otras aplicaciones, como puede ser con servicios de autenticacin o herramientas de comunicacin administrativa y backoffice [15]. Generalmente son adaptaciones parciales y no necesariamente tienen que integrarse transparentemente. Vinculaciones completas entre las plataformas y las aplicaciones en las que la integracin es totalmente transparente para los usuarios, permitiendo una comunicacin bidireccional y aportando un modo de presentacin totalmente adaptado al LMS. Para esto se proponen varias especificaciones entre las que destacan IMS LTI (Learning Tools for Interoperability), para integracin transparente de aplicaciones en las plataformas o los OSIDs (Open Service Interface Definitons) del proyecto OKI (Open Knowledge Initiative) [13], que describen medios de comunicacin entre la plataforma y otras herramientas.

Adaptaciones mixtas, en las que las aplicaciones requieren de comunicacin con el LMS para extraer informacin e incorporar informacin al mismo, pero sin que tengan que estar incorporados en ellos, como podran ser clientes mviles para las plataformas de aprendizaje. En este sentido cabe destacar Moodbile [2], como ejemplo de integracin. En cualquiera de los casos lo que se pretende es proporcionar nuevas funcionalidades a las plataformas de aprendizaje hacindolas evolucionar de un modelo monoltico destinado a la extincin a un modelo evolutivo, escalable y flexible.

3. Servicios Web en Moodle 2.0

A lo largo del 2010 est previsto el lanzamiento de la nueva versin de Moodle. Esta nueva versin, la 2.0, que sustituir a la actual 1.9, se ha visto como una oportunidad de realizar las cosas de manera distinta, de darle un cambio radical a la plataforma y adaptarla a las a las tecnologas que estn inundando el mercado de las telecomunicaciones. Muchos de estos cambios son el soporte para repositorios externos (Picasa, Youtube, Flickr, Wikimedia, etc.), nuevos mdulos y bloques, cambios en el cdigo del core de Moodle (aunque se podr actualizar sin problemas de la versin 1.9 a la 2.0), etc., pero el cambio ms importante que aqu interesa es el de soporte para servicios web. Estos servicios web (en cuyo proyecto participa uno de los autores de este artculo) permitirn ampliar enormemente las posibilidades de Moodle, pasando de ser una plataforma monoltica a una aplicacin escalable y con la cual se puede interoperar. De esta manera se podran solucionar algunos problemas u obstculos que haban ido apareciendo con el tiempo, como son: La aparicin de nuevos dispositivos mviles con conexin a Internet, con diferentes interfaces y compatibilidades distintas. Muchos de estos navegadores permiten navegar por la aplicacin, pero debido a sus limitaciones fsicas sta puede llegar a ser realmente compleja. Por lo tanto, sabiendo que el nmero de estos dispositivos est creciendo, es conveniente que Moodle

ISSN 1988-3455

SISTEDES, 2010

48

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

facilite la creacin de interfaces alternativas adaptadas a estas plataformas. El gran nmero de organizaciones que confan en Moodle como su plataforma de eLearning ha aumentado en los ltimos aos, lo que provoca cambios en los requerimientos del sistema (escalabilidad) y diversificacin de los mismos, ya que continuamente surgen nuevas necesidades a satisfacer, como son nuevas funcionalidades (siempre y cuando no se corrompan los principios pedaggicos de Moodle). An as, hay que adaptar Moodle a los sistemas de informacin de las organizaciones donde se implementa. Integracin con Backoffice. Se ofrece la posibilidad de, por ejemplo, crear una aplicacin que pueda interactuar con varios sistemas a la vez, ejecutando una misma accin en varios lugares, haciendo que todo funcione de forma conjunta, evitando tener que realizar las operaciones varias veces, como se ve en la Figura 1.

Figura 2. Gestin de Moodle y una base de datos de una organizacin despus de la implementacin de los servicios web, utilizando una herramienta de backoffice.

3.1. Planteamiento Arquitectnico El primer paso dentro del desarrollo de los servicios web fue el de definir una arquitectura que permitiera garantizar la interoperabilidad que se les presupone. Por ello, dichos servicios web deban de cumplir una serie de requisitos establecidos por el equipo de desarrollo de Moodle [17]: Los servicios web deben ser accesibles desde cualquier sistema de conexin, tanto actual como futura, y deben de poder ser invocados independientemente del lenguaje utilizado para ello (interoperabilidad). La estructura de los servicios web debe de desarrollarse de tal manera que aunque se realicen cambios dentro del core de Moodle, sea necesario realizar pocas o ninguna modificacin en la API. Las funciones que conforman la API deben ser ampliables para favorecer las contribuciones. El servicio web debe adaptarse al sistema de privilegios de Moodle (capabilities) para garantizar la seguridad. Atendiendo a esta serie de requisitos, los servicios web de Moodle 2.0 estn divididos en tres capas fundamentales [16] que pueden observarse en la Figura 3 y se describen posteriormente.

Figura 1. Gestin de Moodle y una base de datos de una organizacin antes de la utilizacin de los servicios web.

Utilizando los servicios web se pasara a realizarlas tan slo una vez, dentro de una herramienta de backoffice, la cual se encargar de realizar las operaciones pertinentes tanto en la base de datos de la organizacin, como en Moodle mediante los servicios web, sin necesidad de modificar o acceder al cdigo, como se ve en la Figura 2.

ISSN 1988-3455

SISTEDES, 2010

49

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

Figura 3. Capas de los servicios web de Moodle 2.0

1. Conectores. Hasta el momento se puede conectar con la plataforma a travs de 4 protocolos, estos son: REST, SOAP, XML-RPC y AMF (Flash). Adems, se est trabajando en un quinto conector, JSON, el cul es bastante ms rpido que los cuatro ya nombrados en lo que al intercambio de datos se refiere. Cada uno

de estos protocolos posee su propio conector, los cuales se encargarn de recibir la peticin desde el exterior, comprobar si la funcin a la que se desea acceder existe, comprobar los permisos del usuario que la invoca (y en caso de que sea necesario, generar o devolverle el token que le va a identificar durante la sesin, aunque

ISSN 1988-3455

SISTEDES, 2010

50

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

tambin se puede conectar con la plataforma enviando el nombre de usuario y la contrasea en cada invocacin). Una vez hecho esto, los conectores parsean los datos y llamarn a la funcin correspondiente, pasando de esta manera a la capa externa. Los conectores admiten plugins as que se podrn aadir fcilmente nuevos conectores para que los sistemas externos puedan conectar con Moodle utilizando protocolos distintos a los que la plataforma trae de serie. 2. Externallib. Esta capa est formada por un conjunto de ficheros denominados externallib.php los cuales se encuentran expandidos por todo el rbol de directorios de Moodle. Dichos ficheros son llamados desde los conectores y en ellos se encuentran todas las funciones que se ofrecen en la API de los servicios web. Es decir, resumen todas las funcionalidades de Moodle para ofrecerlas al exterior, intentando utilizar para ellos el mayor cdigo posible existente dentro de la plataforma para no crear cdigo innecesario o duplicado. De esta manera, el externallib.php de users se encuentra dentro de la carpeta user de Moodle, y contiene una serie de funciones que permiten gestionar los aspectos relacionados con los usuarios de la plataforma (como ya se explicar ms adelante). Como es lgico, antes de comenzar a realizar cualquiera de las acciones, se chequen los permisos del usuario con relacin a la accin a realizar, y se comprueban adems los parmetros recibidos y que se van a devolver. Esto ltimo se consigue gracias a que en estos ficheros se encuentran adems una serie de funciones que indican los parmetros que acepta y que debe devolver cada funcin de la API. Por ltimo, indicar un problema con el que se han encontrado los desarrolladores: el tratamiento de errores. La solucin actual consiste en el lanzamiento de excepciones cada vez que haya un error, cambiando de esa manera la idea inicial de devolver cadenas de texto. Este tratamiento de errores ha sido posible finalmente gracias a los requisitos mnimos de Moodle 2.0, que necesita de PHP 5 para funcionar (las excepcin entraron en PHP en esta versin), por lo que si se desean utilizar los servicios web en versiones anteriores (hay un proyecto que est trabajando en el backporting de los servicios web) ser necesario

actualizar la versin de PHP si se tiene versiones anteriores a la 5. 3. Ncleo de Moodle. La capa de ncleo de Moodle est formada por todos las libreras que contienen funciones que puedan interesar dentro de la capa de los externallib, es decir, funciones relaciones con los usuarios, los cursos, los grupos, etc. Esta capa ha sido mejorada en Moodle 2.0 porque muchas de estas funciones impriman mensajes de error en pantalla cuando haba algn problema, por lo que se han reescrito parte de estas funciones del ncleo para que en caso de error devuelvan excepciones (hasta ahora Moodle no posea una API y gracias a estos cambios se est generando una). 3.2. Ejemplo de descripcin y uso de un servicio web Dentro de este apartado se va a explicar la estructura interna de un servicio perteneciente a los servicios web de Moodle, ms concretamente la parte correspondiente a la capa externa del servicio logging, encargado de la gestin de la actividad (logs) dentro de la plataforma. Los diagramas utilizados para la explicacin del servicio son diagramas creados mediante SoaML, un proyecto de especificacin open source que describe un perfil y metamodelado UML para el diseo y modelado de las arquitecturas orientadas a servicios. 3.2.1. Arquitectura y funciones del servicio En primer lugar se representa la arquitectura del servicio, que indica la relacin entre el consumidor del servicio y su proveedor, en este caso el paquete logging con su correspondiente externallib.php, estando de mediador el contrato del servicio. El diagrama utilizado para la representacin de esta informacin es el llamado diagrama de arquitectura del servicio (Service Architecture Diagram) y se tiene un ejemplo en la Figura 4. Mientras que ese diagrama no ofrece una informacin demasiado valiosa dentro de la documentacin de los servicios web, el diagrama de servicio (service diagram, Figura 5) representa de una manera clara las funciones que la API de de logging va a ofrecer como servicio web

ISSN 1988-3455

SISTEDES, 2010

51

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

Figura 4. Diagrama de arquitectura de servicio (logging).

Figura 5. Diagrama del servicio (logging).

ISSN 1988-3455

SISTEDES, 2010

52

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

En el diagrama de la Figura 5 cabe destacar la representacin de las 3 funciones que la API de los servicios web va a ofrecer en relacin a la parte de logging, estas son: i) create_logs, que permitir crear logs dentro de la base de datos de la plataforma, y por lo tanto ofrecer la posibilidad de registrar acciones importantes que se realicen desde fuera de la plataforma (realmente lo que hara es ofrecer una informacin ms concreta del trabajo realizado, ya que los servicio web ya registran ellos mismos si han sido utilizados) ii) get_logs, funcin que permitir recuperar una serie de logs de la plataforma. Esta funcin permite recuperar la actividad de Moodle en funcin del tiempo, del usuario, del curso o del id dentro de la base de datos. En algunas plataformas demasiado grandes, el nmero de logs es demasiado elevado, por lo que se est trabajando en una funcin que cuente los logs existentes para que en caso de que sea un nmero muy elevado stos se puedan devolver por bloques, evitando as problemas de memoria iii) delete_logs, sta es una funcin que no debera ser muy utilizada ya que sirve para borrar cierta actividad dentro de la plataforma. 3.2.2 Parmetros de las funciones El tercer diagrama que documenta un servicio web consiste en uno llamado diagrama de mensajes (message diagram) que complementa la informacin ofrecida en el diagrama anterior, indicando los parmetros que cada una de las funciones del servicio acepta y devuelve en cada ejecucin. Un ejemplo de este diagrama se puede ver en la Figura 6. En ella que se observan los mensajes que los consumidores van a intercambiar con el servicio. En la mayor parte de los casos, las funciones deben recibir un array de arrays, donde cada uno de estos segundos arrays contiene la informacin necesaria para una ejecucin de la funcin. De esta manera, se hace posible realizar varias acciones, como dar de alta cien usuarios por ejemplo, utilizando slo una invocacin a la funcin create_users, pero envindole un array con cien arrays. Dicho esto, en el diagrama se puede observar que la funcin get_logs debe recibir un array de arrays con los parmetros criteria (curso, usuario, id, fecha), data1 y data2, mientras que devolver toda la informacin existente acerca de los logs dentro de la base de datos. Cabe destacar que para conocer el uso de

los parmetros ser necesario leer la documentacin de Moodle donde aparece una pequea descripcin de cada uno de ellos con sus posibles valores. 3.3. Aplicacin de los servicios web de Moodle, la herramienta de Backoffice Durante el desarrollo de la capa externa de los servicios web, se decidi realizar una herramienta de prueba que permitiera probar el correcto funcionamiento de las funciones de la API que se iban creando. A la vez, esta herramienta podra permitir observar (desde el punto de vista de los futuros desarrolladores de clientes para Moodle) las posibles necesidades que stos pudieran tener, para de esta manera poder realizar una API lo ms sencilla y usable posible. Teniendo en cuenta que se quera abarcar el mayor nmero de funciones de la API posibles, se decidi crear una herramienta de backoffice (a pequea escala) que permitiera a un administrador realizar las gestiones bsicas de una plataforma Moodle. Dichas gestiones bsicas seran: Administracin. La opcin ms interesante dentro de la administracin de la herramienta es la de poder cambiar el protocolo mediante el cual se quiere conectar con la plataforma Moodle, ya que el cliente creado permite la conexin con tres de los cuatro protocolos que soporta Moodle, estos son: REST, SOAP y XML-RPC. Adems, se est trabajando para adaptarla al protocolo JSON, que como se ha dicho anteriormente se encuentra actualmente en desarrollo. El resto de opciones son el envo masivo de mensajes a los usuarios inactivos (se le indica el nmero de das mnimo que un usuario debe llevar inactivo y automtica se manda un mensaje a todos esos usuarios) y la opcin de probar directamente las funciones de la API de los servicios web, tan solo indicndole la funcin que se desea probar y los parmetros que se le van a enviar. Usuarios. Permite el acceso a todos los usuarios de la plataforma, adems de permitir gestiones tales como la creacin de nuevos usuarios y la actualizacin y eliminacin de los ya existentes. Cursos. De la misma forma que con los usuarios, permite la gestin de la

ISSN 1988-3455

SISTEDES, 2010

53

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

configuracin de los cursos, as como de alguna de sus actividades. Es decir se pueden crear, eliminar, modificar y acceder a cursos, as como a las categoras de cursos. Ya dentro de ellos, se puede acceder a sus foros, calificar a los alumnos y gestionar los grupos. Roles. Una parte importante dentro de Moodle es el sistema de roles, por lo que la herramienta permite la gestin de los roles en los dos contextos ms utilizados: sistema y cursos. Logs. La parte ms interesante llega con la gestin de los logs. Adems de poder acceder a los logs de la plataforma ya sea mediante usuario, curso o fecha, con motivo de probar la interoperabilidad de los servicios

web, la herramienta incorpora un applet de un herramienta de visualizacin de logs creada por Diego Alonso Gmez [8] que crea visualizaciones de la actividad de la plataforma accediendo a los logs de la misma. Con anterioridad a los servicios web esta herramienta necesitaba el acceso directo a la base de datos para recoger la informacin, por lo que se necesitaba un contacto con la plataforma adems de tener que acceder al cdigo de la misma. De esta manera, gracias a los servicios web, la herramienta es independiente de la plataforma con la que trabaje, otorgndole una independencia que antes no tena.

Figura 6. Diagrama de mensajes del servicio (logging).

ISSN 1988-3455

SISTEDES, 2010

54

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

4. Conclusiones
Los procesos de aprendizaje estn cambiando, ya no solo debido a la evolucin de las nuevas tecnologas, sino tambin a cambios sociolgicos como pueden ser la irrupcin de las tendencias sociales favorecidas por las herramientas 2.0; las nuevas necesidades formativas cada vez ms orientadas hacia el alumno; los nuevos contextos y situaciones en los que los alumnos aprenden; el hecho de que los receptores de la informacin han nacido en la era digital y por tanto utilizan la tecnologa a un nivel antes no contemplado; los nuevos paradigmas formativos derivados de propuestas como la normativa de Bolonia que aboga por el reconocimiento de aprendizaje tanto formal como no formal; etc. Ante esta situacin las plataformas de aprendizaje, que han sido las herramientas ms extendidas y utilizadas de los ltimos aos estn en peligro de extincin. Cuando estas herramientas han alcanzado un mayor grado de madurez, y an a pesar de que su potencial no se aproveche, surgen nuevas necesidades y stas suponen la evolucin. Esa evolucin conduce a nuevos contextos, paradigmas y orientaciones en lo que se refiere al aprendizaje, y para ello son necesarias las arquitecturas SOA. Las Arquitecturas Orientadas a Servicios sern una puerta que permite incrementar la funcionalidad de las plataformas de aprendizaje, proporcionando por tanto un medio para evitar su estancamiento, permitiendo abrirse camino hacia las nuevas tendencias como pueden ser los entornos de aprendizaje personalizados (PLEs). Moodle 2.0 y las herramientas que se han definido para su testeo son un claro ejemplo de cmo una plataforma puede ir ms all y puede realmente ser escalable y flexible gracias a la base que aportan los servicios web. Utilizando las Arquitecturas Orientadas a Servicios sobre este conocido LMS se ha conseguido proporcionar un medio para enriquecer las funcionalidades, existan ya trabajos en este sentido pero en cualquiera de los casos supona tener que acceder directamente al cdigo de Moodle y se generaran dependencias tecnolgicas y de versin. De este modo, como demuestran los ejemplos descritos, se abre un nuevo mundo para este LMS. Lo que se consigue con este tipo de aplicaciones ser por tanto la evolucin de la especie, que no es otra que los medios que el alumno utiliza para

aprender cmo son las plataformas de aprendizaje y los contextos a qu estas pueden aplicarse.

Referencias
[1] Alba, J. Qu es SOA - Arquitectura Orientada al Servicio. bit, 167, 2008. [2] Alier, M. and Casany, M. J. Moodbile: Extending Moodle to the Mobile on/offline Scenario. In Proceedings of the IADIS International Conference Mobile Learning. Algarve, 2008. [3] Booch, G. Object Oriented Analysis and Design with Applications. The Benjamin/Cummings Publishing Company, 1994. [4] Cuban, L. Oversold and underused: Computers in the classroom. Harvard University Press, Cambridge, MA, 2001. [5] Fontenla, J., Caeiro, M. and Llamas, M. Una Arquitectura SOA para sistemas de e-Learning a travs de la integracin de Web Services. V Congreso Iberoamericano de Telemtica. CITA 2009. Gijn/Xixn. Mayo, 2009. [6] Garca Pealvo, F. J. Estado Actual de los Sistemas E-Learning. Teora de la Educacin. Educacin y Cultura en la Sociedad de la Informacin, 6, 2. Octubre, 2005. [7] Garca Pealvo, F. J. Preface of Advances in E-Learning: Experiences and Methodologies. Information Science Reference, Hershey, PA, USA, 2008. [8] Gmez, D. A., Snchez, R. T. and Garca, F. J. Semantic Spiral Timeline como apoyo al elearning. Journal of Universal Computer Sience (jjucs), 2008. [9] Keen M. et al. Implementing Technology to Support SOA Governance and Management. IBM RedBooks. 2007. [10] LUISA Learning Content Management System Using Innovative Semantic Web Services Architecture. 2009. http://luisa.atosorigin.es. ltima vez consultado 12/07/2010 [11] Maier, M. W., Emery, D. and Hilliard, R. IEEE 1471 and systems engineering. Syst. Eng., 7, 3 2004), 257-270. [12] Milligan, C. The Road to the Personal Learning Environment? CETIS, 2006. http://zope.cetis.ac.uk/members/ple/resources/coli nmilligan.pdf, ltima vez consultado 12/07/2010 [13] OKI. OKI Project. http://www.okiproject.org/. ltima vez consultado 12/07/2010.

ISSN 1988-3455

SISTEDES, 2010

55

Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, Vol. 4, No. 3, 2010

[14] Papazoglou, M. P. Service -Oriented Computing: Concepts, Characteristics and Directions. In Proceedings of the Proceedings of the Fourth International Conference on Web Information Systems Engineering. IEEE Computer Society. 2003. [15] Ptzold, S., Rathmayer, S. and Graf, S. Proposal for the Design and Implementation of a Modern System Architecture and integration infrastructure in context of e-learning and exchange of relevant data, 2008. [16] Piguillem, J. Moodle 2.0 Web Services architecture, 2009. http://blogs.dfwikilabs.org/pigui/2009/04/27/moo dle-20-web-services-architecture/. ltima vez visitado 12/07/2010.

[17] Recio, F. Arquitectura de los webservices de Moodle, 2008. http://blogs.dfwikilabs.org/moodle_ws/2008/04/1 0/arquitectura-de-los-webservices-de-moodle/. ltima vez visitado 12/07/2010 [18] Serverlabs Pero, qu es realmente SOA? , http://www.theserverlabs.com/folletos/Folleto%20 SOA.pdf. ltima vez visitado 12/07/2010. [19] Shaw, M. and Garlan, D. Software architecture: perspectives on an emerging discipline. Prentice-Hall, Inc., 1996. [20] Universidad de Carolina del Norte. Sakai Pilot Evaluation Final Report. 2009 http://www.unc.edu/sakaipilot/evaluation/FinalRe pt-Oct15-09-sm.pdf. ltima vez consultado 12/07/2010. [21] W3C Gua Breve de Servicios Web, 2010. http://www.w3c.es/divulgacion/guiasbreves/Servi ciosWeb. ltima vez consultado 12/07/2010

ISSN 1988-3455

SISTEDES, 2010

56