Para quizás entender mejor cual es el objetivo de este blog y en definitiva, cual es el sentido de la creación de esta capa de Interoperabilidad para Moodle, deberíamos entender que representa para nosotros la interoperabilidad dentro de Moodle. No sólo por la vertiente de innovación para la plataforma, sino también para el sinfín de puertas que podemos abrir.

La interoperabilidad para las plataforma e-Learning pone de manifiesto la necesidad de intercambiar información, actividades, documentos y en mayor medida, la posibilidad de hacerlo con cursos y usuarios.

La interoperabilidad supone en lo que respecta al software, la capacidad de los diferentes programas tengan un intercambio de datos a través de un conjunto común de formatos preestablecidos para el intercambio, leyendo y escribiendo los mismos formatos de archivo, y utilizando los mismos protocolos.

Esto supone para las aplicaciones informáticas, las aplicaciones web y los sistemas de información sea un requisito principal y esencial para que el flujo de información sea continuo. La información nutre nuestro sistema y evoluciona como producto y por tanto otorga valor añadido a nuestra plataforma e-Learning. De ahí, la necesidad que el traspaso de información sea lo más transparente posible y lo más versátil. Proveyendo a la plataforma de un nuevo nivel de negocio, donde ya no sólo la usabilidad y la facilidad de aprendizaje sean primordiales, sino que los contenidos sean adecuados y fácilmente ampliables, contrastables y portables.

Ya que las ventajas de tener un sistema de enseñanza y aprendizaje integrado y basado en estándares interoperables son muchas puesto que pueden permitir, tener repositorios de bibliotecas externos para mantener el material de la formación académica en un sólo deposito, la facilidad de uso para la construcción de herramientas pedagógicas, poder combinar los contenidos, de tal forma que sean reusables y permitan ser personalizados en un nuevo contexto, etc.

Durante el proceso programación de los conectores nos hemos encontrado con que el NuSOAP que viene dentro de Moodle no funciona correctamente con PHP5 en algunos niveles de debugación. (more…)

La arquitectura en tres capas garantiza que las funciones que conforman la API puedan ampliarse independientemente de los conectores. De hecho, pese a que en un inicio hemos empezado por la implementación de las funciones de gestión académica que requiere la comunidad de Moodle (el paquete básico), está previsto que se amplíe con los servicios de los módulos (fòrum, wiki, recursos), bloques, desarrollos a medida…

Así, con el tiempo la API se completará con un número variable de funciones que, en muchos casos, cubrirán necesidades alternativas a la gestión académica (interfaces adaptadas, acceso desde móvil, monitorización remota…). Por éste motivo, a medida que la API crece, las funciones se agrupan en servicios, para que el cliente elija cuales necesita. (more…)

Our Local Hero Jordi Piguillem has got a Google Summer of Code scollarship. Chuck Severance will mentor him, and I will do my best. The proposed task for Pigui’s  SOC  will be to implement IMS TI 2.0 in Moodle. In the UPC we did something similar for the Campus project, inspired by Chuck’s explanations about IMS TI 1.0 and the requirements for the OKI - Gateway. This project and the DFWebservices are very related.

Congratulations Pigui.  Read more in Pigui’s Blog:  Moodle Happens.

Antecedents.

Martin Dougiamas assigned to us the task of developing a API to access the services of the Moodle core (Let’s call it THE API from now on). This task is described in the Moodle tracker and in Moodle Docs. It consists on a set of PHP functions that encapsulate most of the services that an external ( and even internal ) application shall need from a Moodle server. For example a backoffice application to manage inscriptions and billing. This API consists in a number of functions already proposed by Martin and other guys at Moodle.org and this development will help to redesign some of the very Moodle core functions in the future.

This will be useful for all developers who want to develop applications for Moodle, because this development can lead to a documented and stable API to hack into Moodle that should overcome new versions of Moodle. With funding we could even backport the API… anyone interested }-)

OK, e are doing this. But we are not going to stop there. Our intentions are more mean. We intend to provide an interoperability architecture to be built over this API. Some of the functions of THE API are already in the CVS and we are gaining speed writing them.

Requirements

Moodle-DFWs needs to be accessible using any transport protocol present or future. So it cannot depend on a concrete Webservices protocol, name it XML-RCP, SOAP, REST or two empty yogurt vases tied by a wire.
Moodle-DFWs will need to be implemented in the present version of Moodle (Moodle 1.9) and in the future versions as well. We take for granted that in the future more services will come up, but - come on guys - we need the semantics of the first release to remain stable. We don’t want it to be like a regular Java with lots of deprecated features…. we remember: “Java is evil and eats kids”… said the master.
Moodle-DFWs needs to be extendable, so contrib amb custom applications can have a standard way to extend Moodle out of its bounds. To ensure security and simplify administration: Moodle-DFWs has to obey the Moodle Capabilities system.

A first glimpse at Moodle-DFWs

Lets look at fig.1. In this figure we have Moodle (in an orange box, off course), just below Moodle we have blue boxes that represent Moodle extensions such activity modules, courses or blocks. The purple lines plug all these software artifacts with a green box labeled API. This is THE API that MD wants us to develop. At least the part that talks with the orange Moodle box.

We want to propose a way to extend THE API so MOD, BLOCK, and COURSE extensions can provide their own service through THE API. These extensions would be dynamically included in the API if the Moodle Admin allows it. So here’s the first thing to debate. There are scalability and security issues at stake… so we want to hear from Martin Langhoff and Petr Skodak soon (we hope he will like these more than the wiki ).

Fig. 1 A firs glimpse on the Moodle-DFWs architecture.

There’s also a CON green box, just over THE API. We took this box out of THE API because is something you will only need when using a connection from another application. If you access THE API directly from a inside Moodle PHP application, an activity module for example, you just don’t need it. The CON box contains the methods to authenticate authorize the remote application. These remote applications will talk with the blue boxes inside the big green box on the left (still on fig 1). We call these boxes Connectors, and those are who implement a way of connection, giving us independence of the webservices protocol.

We have already released to the tracker one connector for PHP and another for SOAP. To test the SOAP connector Ferran Wrote a Python client, also in the CVS.

This architecture allows that the services implemented in the connectors can be independent of the methods of THE API they use. Security enhancements and scalability considerations can be applied in the design of custom connectors. In fact a connector does not need to implement a full access to the Moodle Services, juts what the organization needs. In this case the Moodle partners could meet a new field of business making custom, secure and high performance connectors. (I just have the feeling that MNET could be re-implemented as a connector some day (comments from my friend Martin Lanhoff are required!))

The current design of the connectors requires them to implement two basic components.

• Connect: initiates the first connection with Moodle. Login and logout will be handled here, and will negotiate the services from THE API that will be accessed. To manage remote connections “connect” will be the address for the http/s session.
• InOut: is the one who offers the client application the services implemented in the connector according to the rights of the authenticated user.

A three layered architecture.

So, we get this tree layers (See Fig. 2):

• Connect Layer: Contains the connectors that implement services to local(PHP) or remote (Webservices) applications. Each component manifests the services implemented using the “info” function, and implement the Connect and InOut components.
• Integration layer: This layer consists on THE API (being implemented) that provides a one point access to the Moodle + contrib functionalities.
• Services Layer: Is where real things happen. THE API knows ho to deal with the Moodle core, and in future posts we will deal on how the activity modules, course formats and plugins can offer their services to the clients.

That’s It… comments and serrano ham are most wellcome!
DFWikiteam

Lets remember that Moodle, build on philosophical principles on pedagogy (Social Constructionism), typically comes into the educational spaes by the hand of the teachers with the will to innovate. When the nw LMS is proposed from ABOVE, usually goes towards things like Sakai, if we are lucky and go FLOSS, or things in the propietary market that we will not name, period. Right now the Moodle policy is to build on stability, reliability and integration with the needs of the institution. And this is a good thing, cause is the way that the ideas bred in the Moodle communty can spread to as many educational environments as possible.

But still there are plenty of Moodle adopters who have crazy ideas that we’d love to see out there. Moodle’s M stands for Modular ( Martin recognizes that on a first stage it meant Martin’s ) so Moodle can be extended through activity modules, blocks, course formats, hacks, plug-ins, etc. The Moodle contrib is full of that (more than 330 actually). But we do now from on experience that is hard to develop a Moodle extension, open source it, give support to the users, maintain it and, specially, to keep up with the evolution of Moodle ( that in last 3 years has been crazy: look at the Moodle core in Moodle 1.4 and what’s rigth now in Moodle 1.9… ) Still one of the keys of the success of Moodle is the possibility that gives of being extended, cause every big organization wants its information system to adapt (not to adapt the organization itself, like when one implements things like SAP). But organizations need to keep upgrading their customizations to the Moodle version… and lots of these developments never are published, and lots of members of the community are reinventing the same wheel over and over again.

And every day appear new connected devices (mobile devices, micro-laptops such as the OLPC, consoles like the Wii, cook gadgets like th iPhone and even virtual artefacts like Virtual worlds like Second Life (to give a not so good example)). All of these artifacts can be possible points of access to the Moodle courses, and even can become scenarios to new learning experiences… more exciting and innovative than the very Moodle itself.

And we want all of these to talk with Moodle and with the Moodle activities…

Moodle needs a stable core API that alows the developers to write activities and extensions that survive the Moodle evolution, so they can be ported from one Moodle version to the next… giving the organizations a garantee of their investment in time, brainpower and off course money. And needs easy ways so external appilcations and devices can talk with it in an easy to develop and secure way…

Our challenge is to create a kick ass webservices echosystem that Martin Dougiamas will love to put into Moodle core rigth away. That’s (one of ) our errand.

DFWikiteam out

• La capa debe ser accesible desde cualquier sistema de conexión, tanto actual como futuro.
• La estructura de la api debe ser versátil para que se adapte a futuras versiones de Moodle.
• Las funciones que conforman la api deben ser ampliables para que las contribuciones o incluso aplicaciones a medida puedan definir más.
• El webservice debe adaptarse al sistema de privilegios de Moodle (capabilities) para garantizar la seguridad.
• Pese a que el punto de acceso a la api será único y otorgará acceso a todas las partes sistema donde se tengan privilegios, debe existir un medio para especificar qué partes de la api son esenciales para las aplicaciones clientes. Así, será posible optimizar las conexiones incluyendo sólo aquellas funcionalidades que se necesiten.

Los anteriores requerimientos nos han llevado a definir la siguiente arquitectura.

Donde la única parte estática es la referente a la integración de las apis con el medio de conexión. De éste modo es posible ampliar la api o los conectores sin necesidad de replicar código. A diferencia de las grandes librerías de Moodle, las api se basará en librerías específicas que serán incluidas dinámicamente y que podrán ser conectadas o desconectadas a nivel del sitio (site) y requeridas a nivel de aplicación cliente o consumidora.

Además, existen varios conectores para acceder a la api. Cada connector representa un medio de acceso. Para una primera versión hemos trabajado en un conector SOAP y otro de PHP, esté último pensado para aplicaciones que se encuentren en el mismo servidor (o en la misma instancia de Moodle).

La arquitectura esta pensada para que los conectores se usen independientemente de las funciones de la api que sean requeridas. Ésta es la razón por la que cada conector dispone de dos componente básicos:

• Connect: establece la primera conexión con Moodle y proporciona herramientas para autenticarse en el sistema (login), salir (logout) y especificar que servicios de la api se necesitan. En el caso de conexiones remotas como SOAP, la dirección de “connect” será la entrada pública al sistema que nos proporcionará una sesión para usar la api (un tíquet).
• InOut: es el encargado de ofrecer al cliente la api unificada con los servicios requeridos y filtrar según los privilegios del usuario autenticado. El acceso a este componente requiere que el usuario esté autenticado y, por tanto, en el caso de las conexiones remotas será necesario usar el componente “connect” antes.

Como es de suponer, el hecho de pasar por “connect” para conseguir una sesión temporal válida no se aplica en el caso del connector director PHP, donde la propia sesión de Moodle remanente en el navegador web ya nos sirve. El trazado de la conexión será tratado en próximos artículos.

Las librerías que contienen los servicios de la api deben definirse de forma que a los conectores les sea posible ofrecerlas a los clientes. Por éste motivo es necesario que cada librería disponga de una función especial, llamada de forma genérica función “info”, que sirva de índice para general una definición de operaciones y estructuras (el WSDL en el caso de SOAP y una estructura de datos en el de PHP). La existencia de ésta función conlleva una ventaja clara, cada servició dispondrá de lugar completamente definido donde podrán consultarse de forma fácil las funciones públicas (cosa que en lenguajes como PHP4, donde no existen funciones privadas, es bastante útil). El formato de dicha función se especificará en próximos artículos, así como las limitaciones que implica.

Dado que el montaje de la api se realiza dinámicamente de forma centralizada, es posible separar el webservice en tres capas muy diferenciadas:

• Capa de servicios (Service Layer): son todas las librerías que pueden conformar la api. Todas ellas disponen de su propia función “info”. La librerías pueden estar agrupadas en paquetes de servicios que pueden ampliarse. Por ejemplo, un paquete podría corresponder a los servicios ofrecidos por los distintos módulos de actividad (fórum, wiki, lección…), mientras que otro podría garantizar el acceso a funciones de gestión académica hechas a medida.
• Capa de integración (Integration Layer): representa la inclusión única de la api. Se divide sólo en dos partes: una para las funciones de login, logout y petición de servicio, y otra que unifica los servicios requeridos para que los conectores puedan ofrecerlos. También es el responsable de unir todos los índices de funciones y estructuras que les devuelven los servicios (con las funciones “info”) y combinarlos en una macroestructura
• Capa de conexión (Connect Layer): representa el total de conectores que hay activos en el sistema. Cada conector es capaz de interpretar la macroestructura que le devuelve la capa de integración y ofrecerla al cliente.

Por otro lado, cada día aparecen nuevos dispositivos con acceso a la Red, como los móviles, que ya se cuentan entre los clientes potenciales para cualquier aplicación en línea. Muchos de estos dispositivos tienen navegadores compatibles, sin embargo, sus monitores y teclados limitados suelen dificultar bastante la navegación por páginas complejas como las de Moodle. En este sentido, sería conveniente que Moodle facilitase la creación de interfaces alternativas o permitiese la conexión desde programas externos que ofrezcan vistas no basadas en HTML.

Dentro de la comunidad ya hace tiempo que se tanteo la posibilidad de crear una capa lógica para Moodle que permita extender las funcionalidades del sistema sin necesidad de modificar el código original, una API. El problema es que en las últimas versiones de Moodle se han añadido muchas novedades y modificado una gran parte del núcleo del programa (sobre todo en la versión 1.7 debido a creación de los roles). En consecuencia, la dirección de l proyecto ha priorizado la estabilidad de las modificaciones a implementar y documentar de una API para facilitar las aplicaciones de terceros.

Como añadido, la creación de la capa de interconexión nos obliga a replantearnos una gran parte de las funciones internas de Moodle y simplificar el código para que sea más usable y comprensible. En este sentido, DFwikiLabs trabajarà junto al equipo de Moodle.org para ayudar a mejorar la calidad del código final.