arquitectura moodle 2_0

5/17/2018 Arquitectura Moodle 2_0 - slidepdf.com

http://slidepdf.com/reader/full/arquitectura-moodle-20 1/12

Moodle 2.0 y las nuevas plataformas de aprendizaje orientadas aservicios

1

Miguel A. CondeDepartamento de Informática y

Automática. Instituto Universitario deCiencias de la Educación (IUCE).Grupo de investigación GRIAL.

Universidad de [email protected]

Alberto del PozoDepartamento de Informática y



Francisco J. GarcíaDepartamento de Informática y



Tabla 1. 1 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 León a través del proyecto de excelencia GR47.

Resumen

El imparable avance de las nuevas tecnologías ha puesto de manifiesto la necesidad de actualizaciónde las plataformas de aprendizaje. Esaactualización se basa en la incorporación denuevas funcionalidades para satisfacer las nuevasnecesidades de los usuarios. Una de las formas enque poder llevarlo a cabo pasa por la evolución delos entornos de aprendizaje hacia lasArquitecturas Orientadas a Servicios (SOA,Service Oriented Architecture). Estasarquitecturas, implementadas principalmente enforma de servicios web, permitirán la creacióntanto de clientes como de herramientas externasque puedan interoperar con la plataforma,ampliando sus posibilidades y proporcionando unalibertad de movimiento a los usuarios que antes notenían. Moodle 2.0 será un ejemplo de esaevolución y en el presente artículo se verán algunade las nuevas posibles aplicaciones a incorporar.

1. Motivación

El gran avance tanto científico como tecnológicoque se está produciendo en la sociedad durante losúltimos años ha provocado que se deban de buscar nuevas formas de hacer llegar la enseñanza atodos los usuarios [6, 7]. El eLearning supone un

planteamiento diferente de los procesos deaprendizaje y por tanto introduce nuevasnecesidades. Estas van a verse respaldadas por las

plataformas de aprendizaje. Mientras que hace tansolo unos años el poder acceder al aprendizaje a

través de un ordenador era considerado un granavance tecnológico, ahora el poder acceder a él através de estos dispositivos se queda corto,creando la necesidad de tener toda la informaciónque se desee cuando se desee, es decir, tener amano en todo momento el conocimiento. Sinembargo no siempre las plataformas serán capacesde satisfacer estos requisitos.

Otro problema de estas plataformas es que sondemasiado genéricas, poco adaptadas acircunstancias especializadas y son pocosescalables modularmente [5] dificultando de estamanera la posibilidad de añadirle funcionalidades

propias a la plataforma, limita el desarrollo y la

sostenibilidad de los LMS (Learning ManagementSystems, plataformas de aprendizaje). Añadido atodo esto debe considerarse que, en la mayor partede los casos, la potencia de los LMS no seaprovecha totalmente, es decir, muchas de lasfuncionalidades de las plataformas de aprendizajeson ignoradas convirtiéndose en muchos casos enmeros 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 plataformasmonolíticas y cerradas, es decir, de difícilevolución y cuya interacción con otros sistemas

sea mínima. Se busca concretamente aportar capacidad de evolución y crecimientoindependiente de la tecnología. Estaindependencia se consigue mediante laimplementación de unos servicios web que

permitan la conexión con la plataforma de unamanera externa, aunque antes de llegar a los

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

ISSN 1988-3455 SISTEDES, 2010 45



servicios web, se debe comprender como seestructuran y se fundamenta su uso, esto es, lasarquitecturas SOA

Este artículo por lo tanto esta organizado de lasiguiente forma. El punto 2 habla acerca de SOAy sus posibilidades, entrando también en larelación entre SOA y los servicios web. El punto 3analiza la inclusión de los servicios web dentro dela nueva versión de Moodle, la 2.0, que estarádisponible próximamente trayendo consigo

bastantes novedades. Además explicando demanera detallada un servicio y una herramienta de

backoffice creada para su prueba, explicandotambién algunos trabajos relacionados con losservicios web.

2. SOA

De cara a la comprensión del presente artículo es preciso definir qué es la Arquitectura Orientada aServicios. Se trata un paradigma o concepto dearquitectura de software que se basa en la creaciónde un conjunto de servicios, de diferentegranularidad, entre los procesos de negocio y lasaplicaciones [18]. Esta arquitectura tiene comoobjetivos principales:•

Modelar la lógica de negocio como servicios para poder expresar la capa de negociomediante la facilidad que ofrece laorquestación de los mismos.

• Crear una capa de servicios que ofrezca lafuncionalidad de la capa de aplicación deforma independiente de la tecnología que lasoporta.

• Minimizar las dependencias entre la capa denegocio y la de aplicación para desacoplar elnegocio de la tecnología, y de este modo

permitir los cambios en cualquiera de ellas.El objetivo sería favorecer la agilidad para elnegocio.

Para comprender claramente el concepto deArquitectura Orientada a Servicios en primer lugar debe considerarse qué significa el conceptode Arquitectura en el ámbito del software. Segúnla IEEE–STD-1471-2000 (“PrácticaRecomendada Para La Descripción ArquitectónicaDe Sistemas De Software Intensivos”) laarquitectura es “la organización fundamental deun sistema integrado en sus componentes, larelación entre ellos y el medio, y los principiosque establecen su desarrollo y evolución” [11].

También puede entenderse una arquitectura como“la estructura global del software y las formas enque esa estructura proporciona integridadconceptual a un sistema [19] o bien como “laestructura lógica y física de un sistema, forjada

por todas las decisiones de diseño estratégicas ytácticas aplicadas durante el desarrollo”[3]. Encualquiera de las definiciones aportadas seconsidera la arquitectura como la organizaciónestructural de los componentes de un sistema, estetipo de organizaciones van a evolucionar vinculadas al planteamiento del modelo de

negocio que a su vez se verá condicionado por laevolución de la tecnología. Como ejemplo de esasevoluciones puede observarse como lasestructuras de negocio cambian de un modelo de

jerarquización vertical, a uno horizontal ymultidisciplinar, para posteriormente pasar unmodelo de tipo ecosistema en el que las áreasimplicadas no se comunican solo entre las áreasmás próximas.

Una vez explicado el término Arquitectura, setiene que conocer también el de servicio. Existendiferentes planteamientos acerca de lo que son losservicios. Pueden considerarse desde un punto devista de negocio como “Una funcionalidadconstruida como un componente reusable para ser

utilizado en un proceso de negocio” [9] o desde un punto de vista técnico como “elementosautodescritos e independientes de plataforma quesoportan la composición rápida, barata ydistribuida de aplicaciones” [14].

En cualquiera de los casos los servicios serán provistos por aplicaciones o proveedores deservicios de cara a proporcionar una funcionalidadsin desvelar su implementación. Esto supone ladefinición de una interfaz para su publicación.Teniendo en cuenta todo esto, las característicasdeseables para un servicio serían:• Tecnológicamente neutral. Los Servicios no

solamente deben ser independientes de

cualquier tipo de implementación sino quedeben de poder ser invocados de una formalo más estándar posible.

• Bajo acoplamiento. No debe requerirseningún conocimiento de la estructura internao externa del servicio en ningún contexto delmismo (ni en el lado del cliente ni en el delservidor).

• Descubrimiento transparente. Lafuncionalidad expresada por los servicios


ISSN 1988-3455 SISTEDES, 2010 46



debe estar disponible en diferentesrepositorios para su localización y difusión.

• Calidad de servicios. Los servicios deben ser capaces de ofrecer la funcionalidadexpresada con un nivel cualitativo adecuadode cara a que su reutilización sea posible endiferentes contextos.

• Debe existir la posibilidad de trabajar con unservicio de forma individual o formando

parte de una composición de estos en buscade una funcionalidad más completa.

La idea principal, por tanto, de esta

arquitectura es que conviene ordenar la forma enque se comunican las distintas partes de unsistema. Para conseguir este objetivo se define unacapa de servicios con el que los sistemasinteractúan, evitando así el trabajar de maneradirecta entre ellos, favoreciendo lainteroperabilidad y la escalabilidad. De estamanera, si dos sistemas desean comunicarse, nonecesitan conocer el funcionamiento del otro, sinoque utilizarán esta capa de servicios comointermediaria, la cual sí conoce como funcionanestos sistemas. Si en algún momento se deseasustituir o realizar algún cambio en alguno de losdos sistemas, la acción sería independiente delotro, ya que se han desarrollado de manera que nodependan del otro sistema, sino que sólo dependende los datos que devuelven [1]. Esta forma derelacionar componentes aporta las siguientesventajas: i) Permite sustituir componentesindividuales sin que eso afecte a otroscomponentes ii) Todos los sistemas se conectan al

bus de la misma forma, con lo que se gana enhomogeneidad iii) Facilidad en la operación ymantenimiento iv) Arquitectura sencilla, robusta yescalable.

2.1. SOA y los servicios Web

Es importante conocer que SOA no es unsinónimo de servicios web. Mientras que SOA esun paradigma de desarrollo (y estrategia de TI),los servicios web son una de las posiblestecnologías que se pueden utilizar paraimplementar SOA, aunque hay que destacar que laimplantación de SOA está siendo mucho másrápida gracias a los servicios web y que éstos seestán convirtiendo en el estándar de facto para laimplementación de estas arquitecturas.

Una vez vista la diferencia entre SOA y losservicios web, se va a tratar de describir esteúltimo. Cabe destacar que existen varias posiblesdefiniciones acerca de lo que son los serviciosweb, lo que muestra su complejidad a la hora dedar una explicación adecuada de todo lo que son eimplican. Una posible sería hablar de ellos comoun conjunto de aplicaciones o de tecnologíasintercambian datos entre sí con el objetivo deofrecer unos servicios. Los proveedores ofrecensus servicios como procedimientos remotos y losusuarios solicitan un servicio llamando a esos

procedimientos a través de la web [21]. Estosservicios proporcionan mecanismos decomunicación estándares entre diferentesaplicaciones, que interactúan entre sí para

presentar información dinámica al usuario. El usode los servicios web proporciona una serie deventajas (muchas de las cuales derivan de lasventajas de implementar una ArquitecturaOrientada a Servicios) como son:• Promueven la interoperabilidad ya que la

interacción entre un proveedor y unsolicitante de servicio está diseñada para quesea completamente independiente de la

plataforma y del lenguaje.• Fomentan los estándares y protocolos

basados en texto, que hacen más fácilacceder a su contenido y entender sufuncionamiento.

• Al apoyarse en HTTP, los servicios web pueden aprovecharse de los sistemas deseguridad firewall sin necesidad de cambiar las reglas de filtrado.

• Reducen la complejidad por medio delencapsulamiento, ya que los solicitantes y los

proveedores del servicio se preocupan por lasinterfaces necesarias para interactuar. Comoresultado, un solicitantes de servicio no sabecómo fue implementando el servicio por

parte del proveedor, y éste, a su vez, no sabe

cómo utiliza el cliente el servicio.• Permiten la interoperabilidad entre

plataformas de distintos fabricantes por medio de protocolos estándar y abiertos yaque las especificaciones son gestionadas por una organización abierta, la W3C.


ISSN 1988-3455 SISTEDES, 2010 47



2.2. Arquitectura SOA en eLearning

De cara a incorporar interoperabilidad en las plataformas de aprendizaje y hacer a estasflexibles y escalables es necesaria la definición deuna nueva generación de plataformas deaprendizaje. Este tipo de plataformas se van aasentar en las Arquitecturas Orientadas aServicios. Este tipo de solución proporcionará unaseparación entre la interfaz de un servicio y suimplementación subyacente. No será relevanteque una aplicación que se quiera conectar a una

plataforma esté implementada en una tecnologíadiferente del core del LMS. SOA aportaindependencia en la evolución del software

permitiendo la incorporación de nuevasfuncionalidades independientemente de la versióndel LMS subyacente.

Dentro de las posibles aplicaciones de lasarquitecturas SOA deberían considerarsediferentes enfoques:• Uso de las arquitecturas SOA para

proporcionar información a contextosexternos. Como podría ser el uso dearquitecturas orientadas a servicios para

búsquedas semánticas de información sobrela plataforma de aprendizaje, como el

proyecto LUISA [10].• Adaptación ligera de plataformas de

aprendizaje a otras aplicaciones, como puedeser con servicios de autenticación oherramientas de comunicación administrativay backoffice [15]. Generalmente sonadaptaciones parciales y no necesariamentetienen que integrarse transparentemente.

• Vinculaciones completas entre las plataformas y las aplicaciones en las que laintegración es totalmente transparente paralos usuarios, permitiendo una comunicación

bidireccional y aportando un modo de presentación totalmente adaptado al LMS.

Para esto se proponen varias especificacionesentre las que destacan IMS LTI ( Learning

Tools for Interoperability), para integracióntransparente

de aplicaciones en las plataformas o losOSIDs (Open Service Interface Definitons)del proyecto OKI (Open Knowledge Initiative)[13], que describen medios de comunicaciónentre la plataforma y otras herramientas.

• Adaptaciones mixtas, en las que lasaplicaciones requieren de comunicación conel LMS para extraer información e incorporar información al mismo, pero sin que tenganque estar incorporados en ellos, como

podrían ser clientes móviles para las plataformas de aprendizaje. En este sentidocabe destacar Moodbile [2], como ejemplo deintegración.

• En cualquiera de los casos lo que se pretendees proporcionar nuevas funcionalidades a las

plataformas de aprendizaje haciéndolas

evolucionar de un modelo monolíticodestinado a la extinción a un modeloevolutivo, escalable y flexible.

3. Servicios Web en Moodle 2.0

A lo largo del 2010 está previsto el lanzamientode la nueva versión de Moodle. Esta nuevaversión, la 2.0, que sustituirá a la actual 1.9, se havisto como una oportunidad de realizar las cosasde manera distinta, de darle un cambio radical a la

plataforma y adaptarla a las a las tecnologías queestán inundando el mercado de lastelecomunicaciones. Muchos de estos cambios son

el soporte para repositorios externos (Picasa,Youtube, Flickr, Wikimedia, etc.), nuevosmódulos y bloques, cambios en el código del corede Moodle (aunque se podrá actualizar sin

problemas de la versión 1.9 a la 2.0), etc., pero elcambio más importante que aquí interesa es el desoporte para servicios web. Estos servicios web(en cuyo proyecto participa uno de los autores deeste artículo) permitirán ampliar enormemente las

posibilidades de Moodle, pasando de ser una plataforma monolítica a una aplicación escalable ycon la cual se puede interoperar. De esta manerase podrían solucionar algunos problemas uobstáculos que habían ido apareciendo con eltiempo, como son:• La aparición de nuevos dispositivos móviles

con conexión a Internet, con diferentesinterfaces y compatibilidades distintas.Muchos de estos navegadores permitennavegar por la aplicación, pero debido a suslimitaciones físicas ésta puede llegar a ser realmente compleja. Por lo tanto, sabiendoque el número de estos dispositivos estácreciendo, es conveniente que Moodle


ISSN 1988-3455 SISTEDES, 2010 48



facilite la creación de interfaces alternativasadaptadas a estas plataformas.

• El gran número de organizaciones queconfían en Moodle como su plataforma deeLearning ha aumentado en los últimos años,lo que provoca cambios en losrequerimientos del sistema (escalabilidad) ydiversificación de los mismos, ya quecontinuamente surgen nuevas necesidades asatisfacer, como son nuevas funcionalidades(siempre y cuando no se corrompan los

principios pedagógicos de Moodle). Aún así,

hay que adaptar Moodle a los sistemas deinformación de las organizaciones donde seimplementa.

• Integración con Backoffice. Se ofrece la posibilidad de, por ejemplo, crear unaaplicación que pueda interactuar con variossistemas a la vez, ejecutando una mismaacción en varios lugares, haciendo que todofuncione de forma conjunta, evitando tener que realizar las operaciones varias veces,como se ve en la Figura 1.

Figura 1. Gestión de Moodle y una base de datos deuna organización antes de la utilización de los servicios

web.

Utilizando los servicios web se pasaría a

realizarlas tan sólo una vez, dentro de unaherramienta de backoffice, la cual se encargará derealizar las operaciones pertinentes tanto en la

base de datos de la organización, como en Moodlemediante los servicios web, sin necesidad demodificar o acceder al código, como se ve en laFigura 2.

Figura 2. Gestión de Moodle y una base de datos deuna organización después de la implementación de los

servicios web, utilizando una herramienta de backoffice.

3.1. Planteamiento Arquitectónico

El primer paso dentro del desarrollo de losservicios web fue el de definir una arquitecturaque permitiera garantizar la interoperabilidad quese les presupone. Por ello, dichos servicios web

debían de cumplir una serie de requisitosestablecidos por el equipo de desarrollo deMoodle [17]:• Los servicios web deben ser accesibles desde

cualquier sistema de conexión, tanto actualcomo futura, y deben de poder ser invocadosindependientemente del lenguaje utilizado

para ello (interoperabilidad).• La estructura de los servicios web debe de

desarrollarse de tal manera que aunque serealicen cambios dentro del core de Moodle,sea necesario realizar pocas o ningunamodificación en la API.

• Las funciones que conforman la API debenser ampliables para favorecer lascontribuciones.

• El servicio web debe adaptarse al sistema de privilegios de Moodle (capabilities) paragarantizar la seguridad.

• Atendiendo a esta serie de requisitos, losservicios web de Moodle 2.0 están divididosen tres capas fundamentales [16] que puedenobservarse en la Figura 3 y se describen

posteriormente.


ISSN 1988-3455 SISTEDES, 2010 49



Figura 3. Capas de los servicios web de Moodle 2.0

1. Conectores. Hasta el momento se puedeconectar con la plataforma a través de 4

protocolos, estos son: REST, SOAP, XML-RPCy AMF (Flash). Además, se está trabajando enun quinto conector, JSON, el cuál es bastantemás rápido que los cuatro ya nombrados en loque al intercambio de datos se refiere. Cada uno

de estos protocolos posee su propio conector,los cuales se encargarán de recibir la peticióndesde el exterior, comprobar si la función a laque se desea acceder existe, comprobar los

permisos del usuario que la invoca (y en caso deque sea necesario, generar o devolverle el tokenque le va a identificar durante la sesión, aunque


ISSN 1988-3455 SISTEDES, 2010 50



también se puede conectar con la plataformaenviando el nombre de usuario y la contraseñaen cada invocación). Una vez hecho esto, losconectores parsean los datos y llamarán a lafunción correspondiente, pasando de estamanera a la capa externa. Los conectoresadmiten plugins así que se podrán añadir fácilmente nuevos conectores para que lossistemas externos puedan conectar con Moodleutilizando protocolos distintos a los que la

plataforma trae de serie.2. Externallib. Esta capa está formada por

un conjunto de ficheros denominadosexternallib.php los cuales se encuentranexpandidos por todo el árbol de directorios deMoodle. Dichos ficheros son llamados desde losconectores y en ellos se encuentran todas lasfunciones que se ofrecen en la API de losservicios web. Es decir, resumen todas lasfuncionalidades de Moodle para ofrecerlas alexterior, intentando utilizar para ellos el mayor código posible existente dentro de la plataforma

para no crear código innecesario o duplicado.De esta manera, el externallib.php de users seencuentra dentro de la carpeta user de Moodle,y contiene una serie de funciones que permitengestionar los aspectos relacionados con losusuarios de la plataforma (como ya se explicarámás adelante). Como es lógico, antes decomenzar a realizar cualquiera de las acciones,se chequen los permisos del usuario conrelación a la acción a realizar, y se compruebanademás los parámetros recibidos y que se van adevolver. Esto último se consigue gracias a queen estos ficheros se encuentran además unaserie de funciones que indican los parámetrosque acepta y que debe devolver cada función dela API. Por último, indicar un problema con elque se han encontrado los desarrolladores: eltratamiento de errores. La solución actualconsiste en el lanzamiento de excepciones cada

vez que haya un error, cambiando de esamanera la idea inicial de devolver cadenas detexto. Este tratamiento de errores ha sido

posible finalmente gracias a los requisitosmínimos de Moodle 2.0, que necesita de PHP 5

para funcionar (las excepción entraron en PHPen esta versión), por lo que si se desean utilizar los servicios web en versiones anteriores (hayun proyecto que está trabajando en el

backporting de los servicios web) será necesario

actualizar la versión de PHP si se tieneversiones anteriores a la 5.3. Núcleo de Moodle. La capa de núcleode Moodle está formada por todos las libreríasque contienen funciones que puedan interesar dentro de la capa de los externallib, es decir,funciones relaciones con los usuarios, loscursos, los grupos, etc. Esta capa ha sidomejorada en Moodle 2.0 porque muchas deestas funciones imprimían mensajes de error en

pantalla cuando había algún problema, por loque se han reescrito parte de estas funciones del

núcleo para que en caso de error devuelvanexcepciones (hasta ahora Moodle no poseía unaAPI y gracias a estos cambios se está generandouna).

3.2. Ejemplo de descripción y uso de un

servicio web

Dentro de este apartado se va a explicar laestructura interna de un servicio perteneciente alos servicios web de Moodle, más concretamentela parte correspondiente a la capa externa delservicio logging , encargado de la gestión de laactividad (logs) dentro de la plataforma. Los

diagramas utilizados para la explicación delservicio son diagramas creados mediante SoaML,un proyecto de especificación open source quedescribe un perfil y metamodelado UML para eldiseño y modelado de las arquitecturas orientadasa servicios.

3.2.1. Arquitectura y funciones del servicio

En primer lugar se representa la arquitectura delservicio, que indica la relación entre elconsumidor del servicio y su proveedor, en estecaso el paquete logging con su correspondienteexternallib.php, estando de mediador el contratodel servicio. El diagrama utilizado para larepresentación de esta información es el llamadodiagrama de arquitectura del servicio (Service

Architecture Diagram) y se tiene un ejemplo en laFigura 4. Mientras que ese diagrama no ofrece unainformación demasiado valiosa dentro de ladocumentación de los servicios web, el diagramade servicio ( service diagram, Figura 5) representade una manera clara las funciones que la API dede logging va a ofrecer como servicio web


ISSN 1988-3455 SISTEDES, 2010 51



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

Figura 5. Diagrama del servicio (logging).


ISSN 1988-3455 SISTEDES, 2010 52



En el diagrama de la Figura 5 cabe destacar larepresentación de las 3 funciones que la API delos servicios web va a ofrecer en relación a la

parte de logging, estas son: i) create_logs, que permitirá crear logs dentro de la base de datos dela plataforma, y por lo tanto ofrecer la posibilidadde registrar acciones importantes que se realicendesde fuera de la plataforma (realmente lo queharía es ofrecer una información más concreta deltrabajo realizado, ya que los servicio web yaregistran ellos mismos si han sido utilizados) ii)get_logs, función que permitirá recuperar una

serie de logs de la plataforma. Esta función permite recuperar la actividad de Moodle enfunción del tiempo, del usuario, del curso o del iddentro de la base de datos. En algunas plataformasdemasiado grandes, el número de logs esdemasiado elevado, por lo que se está trabajandoen una función que cuente los logs existentes paraque en caso de que sea un número muy elevadoéstos se puedan devolver por bloques, evitando así

problemas de memoria iii) delete_logs, ésta es unafunción que no debería ser muy utilizada ya quesirve para borrar cierta actividad dentro de la

plataforma.

3.2.2 Parámetros de las funciones

El tercer diagrama que documenta un servicio webconsiste en uno llamado diagrama de mensajes(message diagram) que complementa lainformación ofrecida en el diagrama anterior,indicando los parámetros que cada una de lasfunciones del servicio acepta y devuelve en cadaejecución. Un ejemplo de este diagrama se puedever en la Figura 6. En ella que se observan losmensajes que los consumidores van a intercambiar con el servicio. En la mayor parte de los casos, lasfunciones deben recibir un array de arrays, dondecada uno de estos segundos arrays contiene lainformación necesaria para una ejecución de lafunción. De esta manera, se hace posible realizar

varias acciones, como dar de alta cien usuarios por ejemplo, utilizando sólo una invocación a lafunción create_users, pero enviándole un arraycon cien arrays. Dicho esto, en el diagrama se

puede observar que la función get_logs deberecibir un array de arrays con los parámetroscriteria (curso, usuario, id, fecha), data1 y data2,mientras que devolverá toda la informaciónexistente acerca de los logs dentro de la base dedatos. Cabe destacar que para conocer el uso de

los parámetros será necesario leer ladocumentación de Moodle donde aparece una

pequeña descripción de cada uno de ellos con sus posibles valores.

3.3. Aplicación de los servicios web de Moodle,

la herramienta de Backoffice

Durante el desarrollo de la capa externa de losservicios web, se decidió realizar una herramientade prueba que permitiera probar el correctofuncionamiento de las funciones de la API que se

iban creando. A la vez, esta herramienta podría permitir observar (desde el punto de vista de losfuturos desarrolladores de clientes para Moodle)las posibles necesidades que éstos pudieran tener,

para de esta manera poder realizar una API lo mássencilla y usable posible. Teniendo en cuenta quese quería abarcar el mayor número de funcionesde la API posibles, se decidió crear unaherramienta de backoffice (a pequeña escala) que

permitiera a un administrador realizar lasgestiones básicas de una plataforma Moodle.Dichas gestiones básicas serían:• Administración. La opción más interesante

dentro de la administración de la herramientaes la de poder cambiar el protocolo medianteel cual se quiere conectar con la plataformaMoodle, ya que el cliente creado permite laconexión con tres de los cuatro protocolosque soporta Moodle, estos son: REST, SOAPy XML-RPC. Además, se está trabajando

para adaptarla al protocolo JSON, que comose ha dicho anteriormente se encuentraactualmente en desarrollo. El resto deopciones son el envío masivo de mensajes alos usuarios inactivos (se le indica el númerode días mínimo que un usuario debe llevar inactivo y automática se manda un mensaje atodos esos usuarios) y la opción de probar directamente las funciones de la API de los

servicios web, tan solo indicándole la funciónque se desea probar y los parámetros que sele van a enviar.

• Usuarios. Permite el acceso a todos losusuarios de la plataforma, además de permitir gestiones tales como la creación de nuevosusuarios y la actualización y eliminación delos ya existentes.

• Cursos. De la misma forma que con losusuarios, permite la gestión de la


ISSN 1988-3455 SISTEDES, 2010 53



configuración de los cursos, así como dealguna de sus actividades. Es decir se puedencrear, eliminar, modificar y acceder a cursos,así como a las categorías de cursos. Yadentro de ellos, se puede acceder a sus foros,calificar a los alumnos y gestionar losgrupos.

• Roles. Una parte importante dentro deMoodle es el sistema de roles, por lo que laherramienta permite la gestión de los roles enlos dos contextos más utilizados: sistema ycursos.

• Logs. La parte más interesante llega con lagestión de los logs. Además de poder acceder a los logs de la plataforma ya seamediante usuario, curso o fecha, con motivode probar la interoperabilidad de los servicios

web, la herramienta incorpora un applet deun herramienta de visualización de logscreada por Diego Alonso Gómez [8] que creavisualizaciones de la actividad de la

plataforma accediendo a los logs de lamisma. Con anterioridad a los servicios webesta herramienta necesitaba el acceso directoa la base de datos para recoger lainformación, por lo que se necesitaba uncontacto con la plataforma además de tener que acceder al código de la misma. De estamanera, gracias a los servicios web, la

herramienta es independiente de la plataforma con la que trabaje, otorgándoleuna independencia que antes no tenía.

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


ISSN 1988-3455 SISTEDES, 2010 54



4. Conclusiones

Los procesos de aprendizaje están cambiando, yano solo debido a la evolución de las nuevastecnologías, sino también a cambios sociológicoscomo pueden ser la irrupción de las tendenciassociales favorecidas por las herramientas 2.0; lasnuevas necesidades formativas cada vez másorientadas hacia el alumno; los nuevos contextos ysituaciones en los que los alumnos aprenden; elhecho de que los receptores de la información hannacido en la era digital y por tanto utilizan latecnología a un nivel antes no contemplado; los

nuevos paradigmas formativos derivados de propuestas como la normativa de Bolonia queaboga por el reconocimiento de aprendizaje tantoformal como no formal; etc.

Ante esta situación las plataformas deaprendizaje, que han sido las herramientas másextendidas y utilizadas de los últimos años estánen peligro de extinción. Cuando estasherramientas han alcanzado un mayor grado demadurez, y aún a pesar de que su potencial no seaproveche, surgen nuevas necesidades y éstassuponen la evolución. Esa evolución conduce anuevos contextos, paradigmas y orientaciones enlo que se refiere al aprendizaje, y para ello son

necesarias las arquitecturas SOA.Las Arquitecturas Orientadas a Serviciosserán una puerta que permite incrementar lafuncionalidad de las plataformas de aprendizaje,

proporcionando por tanto un medio para evitar suestancamiento, permitiendo abrirse camino hacialas nuevas tendencias como pueden ser losentornos de aprendizaje personalizados (PLEs).

Moodle 2.0 y las herramientas que se handefinido para su testeo son un claro ejemplo decómo una plataforma puede ir más allá y puederealmente ser escalable y flexible gracias a la baseque aportan los servicios web. Utilizando lasArquitecturas Orientadas a Servicios sobre esteconocido LMS se ha conseguido proporcionar unmedio para enriquecer las funcionalidades,existían ya trabajos en este sentido pero encualquiera de los casos suponía tener que acceder directamente al código de Moodle y se generaríandependencias tecnológicas y de versión. De estemodo, como demuestran los ejemplos descritos, seabre un nuevo mundo para este LMS. Lo que seconsigue con este tipo de aplicaciones será por tanto la evolución de la “especie”, que no es otraque los medios que el alumno utiliza para

aprender cómo son las plataformas de aprendizajey los contextos a qué estas pueden aplicarse.

Referencias

[1] Alba, J. ¿Qué es SOA - Arquitectura Orientadaal Servicio. bit, 167, 2008.[2] Alier, M. and Casany, M. J. Moodbile:Extending Moodle to the Mobile on/offlineScenario. In Proceedings of the IADISInternational Conference Mobile Learning.Algarve, 2008.[3] Booch, G. Object Oriented Analysis andDesign with Applications. The

Benjamin/Cummings Publishing Company, 1994.[4] Cuban, L. Oversold and underused: Computersin the classroom. Harvard University Press,Cambridge, MA, 2001.[5] Fontenla, J., Caeiro, M. and Llamas, M. UnaArquitectura SOA para sistemas de e-Learning através de la integración de Web Services. VCongreso Iberoamericano de Telemática. CITA2009. Gijón/Xixón. Mayo, 2009.[6] García Peñalvo, F. J. Estado Actual de losSistemas E-Learning. Teoría de la Educación.Educación y Cultura en la Sociedad de laInformación, 6, 2. Octubre, 2005.[7] García Peñalvo, F. J. Preface of Advances in

E-Learning: Experiences and Methodologies.Information Science Reference, Hershey, PA,USA, 2008.[8] Gómez, D. A., Sánchez, R. T. and García, F. J.Semantic Spiral Timeline como apoyo al e-learning. Journal of Universal Computer Sience (j-

jucs), 2008.[9] Keen M. et al. Implementing Technology toSupport SOA Governance and Management. IBMRedBooks. 2007.[10] LUISA Learning Content ManagementSystem Using Innovative Semantic Web ServicesArchitecture. 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 PersonalLearning Environment? CETIS, 2006.http://zope.cetis.ac.uk/members/ple/resources/colinmilligan.pdf, Última vez consultado 12/07/2010[13] OKI. OKI Project.http://www.okiproject.org/. Última vez consultado12/07/2010.


ISSN 1988-3455 SISTEDES, 2010 55



[14] Papazoglou, M. P. Service -OrientedComputing: Concepts, Characteristics andDirections. In Proceedings of the Proceedings of the Fourth International Conference on WebInformation Systems Engineering. IEEEComputer Society. 2003.[15] Pätzold, S., Rathmayer, S. and Graf, S.Proposal for the Design and Implementation of aModern System Architecture and integrationinfrastructure in context of e-learning andexchange of relevant data, 2008.[16] Piguillem, J. Moodle 2.0 Web Servicesarchitecture, 2009.

http://blogs.dfwikilabs.org/pigui/2009/04/27/moodle-20-web-services-architecture/. Última vezvisitado 12/07/2010.

[17] Recio, F. Arquitectura de los webservices deMoodle, 2008.http://blogs.dfwikilabs.org/moodle_ws/2008/04/10/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%20SOA.pdf. Última vez visitado 12/07/2010.[19] Shaw, M. and Garlan, D. Softwarearchitecture: perspectives on an emergingdiscipline. Prentice-Hall, Inc., 1996.[20] Universidad de Carolina del Norte. SakaiPilot Evaluation Final Report. 2009

http://www.unc.edu/sakaipilot/evaluation/FinalRe pt-Oct15-09-sm.pdf. Última vez consultado12/07/2010.[21] W3C Guía Breve de Servicios Web, 2010.http://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb. Última vez consultado 12/07/2010


ISSN 1988-3455 SISTEDES, 2010 56

arquitectura moodle 2_0

Documents