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.

Todos estos errores se deben a que PHP5 es bastante más restrictivo con lo tipos de datos que PHP4 (recordemos Moodle 2.0 será el primero que exigirá PHP5). De hecho, dos de los tres cambios consisten simplemente en eliminar una concatenación de String+Array en una variable de debugación interna de NuSOAP.

Todos los cambios afectan al archivo “/lib/soap/nusoap.php” dentro de la raíz de Moodle.

Primer Cambio

La primera corrección consiste en comprobar el tipo de dato antes de operar con él. Para ello se añadirá código encima de la línea 3609. El contenido original es el siguiente (la línea especificada está en cursiva):

…$call_arg = array(&$instance, $method);
}
$this->methodreturn = call_user_func_array($call_arg, array_values($this->methodparams));
}
$this->debug(’in invoke_method, methodreturn:’);…

La línea a añadir es:

if (!is_array($this->methodparams)) $this->methodparams = array($this->methodparams);

Y el código queda:

…$call_arg = array(&$instance, $method);
}
if (!is_array($this->methodparams)) $this->methodparams = array($this->methodparams);
$this->methodreturn = call_user_func_array($call_arg, array_values($this->methodparams));
}
$this->debug(’in invoke_method, methodreturn:’);…

Segundo Cambio

El segundo se encuentra en la línia 3613 del código original. El cambio simplemente es quitar una concatenación del debug de NuSOAP. El original es (la parte a eliminar está en rallada):

…$this->debug(’in invoke_method, methodreturn:’);
$this->appendDebug($this->varDump($this->methodreturn));
$this->debug(”in invoke_method, called method $this->methodname, received $this->methodreturn of type “.gettype($this->methodreturn));…

Y el código queda:

…$this->debug(’in invoke_method, methodreturn:’);
$this->appendDebug($this->varDump($this->methodreturn));
$this->debug(”in invoke_method, called method $this->methodname, received of type “.gettype($this->methodreturn));…

Tercer Cambio

El tercer cambio es idéntico al anterior pero en la línea 5414, donde el código original es (la parte a eliminar está en rallado):

…$contents = ”;
foreach($value as $k => $v) {
$this->debug(”serializing array element: $k, $v of type: $typeDef[arrayType]“);
//if (strpos($typeDef['arrayType'], ‘:’) ) {
if (!in_array(…

Donde el resultante es:

…$contents = ”;
foreach($value as $k => $v) {
$this->debug(”serializing array element: $k”);
//if (strpos($typeDef['arrayType'], ‘:’) ) {
if (!in_array(…

Con estos tres cambios nos ha sido posible conectar los servicios de prueba que ya están implementados con un programa en pyhton 2.5. Sin embargo, es muy posible que los errores en el String de debug se repitan en otras partes del código.

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.

Por ejemplo, las funciones de control de usuarios formarían parte del servicio “user”, mientras que el de acceso a los mensajes de los foros podría ser el servicio “forum” .

Sin embargo, esta estructura sólo nos garantiza un único nivel de servicios, identificados por nombre. En caso que una organización quiera añadir más, deberán añadirse en el mismo sitio. Y si un cliente necesita, por ejemplo, todos los servicios de los módulos tendrá que pedirlos uno a uno, dado que el webservice no puede diferenciar qué servicios son de los módulos y cuáles no.

Por éste motivo los servicios de agrupan en paquetes (Fig 1). El sistema de paquetización es muy común en los lenguajes de programación estructurados como Python. En el caso de la API, todos los servicios pertenecen a un único paquete o al paquete básico (que se incluye siempre por defecto y contiene las funciones básicas de navegación, login…).

En los ejemplos anteriores, la gestión de usuarios estaría dentro del paquete básico, por lo que se llamaría “user” sin más, y el servicio de los foros estaría dentro del paquete “mod”, por lo que sería “mod.forum”.

Fig.1 Diagrama de la paquetización

Gracias al sistema de paquetización es possible:

• Programar varios servicios a medida y agruparlos en un único paquete de modo que sea menos intrusivo en el sistema.
• Mantener ordenadas las librerías de servicio que conforman un paquete.
• Cada cliente podrá requerir un servicio concreto (por ejemplo el servicio “mod.forum”) o todos los servicios de un paquete (por ejemplo, “mod.*” incluye todos los servicios del paquete “mod”).
• A nivel de Moodle, será posible conectar y desconectar los servicio que se ofrecen a los clientes, tanto a nivel individual como de paquete.

A modo de resumen, la API del webservice es el conjunto de servicios que están disponibles dentro de los paquetes.

• Las funciones deben ser suficientemente simples para que pueda ser usada por lenguajes de programación simplificados (J2ME, C# Mobile, Javascipt…) y dispositivos limitados (móviles, reproductores de MP3…).
• Las funciones deben ser genéricas para que sirvan de soporte a aplicaciones de alto nivel (gestiones académicas, interfaces de usuario alternativas…) y den acceso a todas las funcionalidades del sistema.
• Los datos se tienen que poder usar en cualquier lenguaje de programación estructurado. Pero, a su vez, tienen que ser útiles y servir para minimizar el número de llamadas a la funciones.
• El resultado de las funciones debe ser útil, completo y mínimo. Los resultados complejos deben contener aquello que se necesita, sin devolver datos superfluos o poco usados pero sin obligar a que el cliente realice llamadas extras para conseguir más información básica.
• Las estructuras de datos serán reusables y su número finito. Se debe evitar que existan más de dos estructuras para representar un mismo concepto.
• Se debe garantizar el acceso a la API mediante varios tipos de conexión externa (SOAP, JSON…) y también mediante la inclusión directa en PHP desde el propio sistema.
• Las funciones de la API tienen que basarse en las propuestas por Moodle.

Todas éstas limitaciones nos obligan a replantearnos muchas de las funciones de Moodle. Sin embargo, ésto es un aspecto positivo del proyecto, que nos brinda la posibilidad de ver Moodle desde un nuevo punto de vista y dar coherencia a todas partes del código.

Definición de los casos

Para cumplir los requerimientos y, al mismo tiempo, cubrir las necesidades de Moodle, hemos decidido diferenciar dos casos:

• La conexión directa desde PHP (en el mismo servidor)
• Cualquier método de conexión remota (SOAP, XML, Json…)

Pese a que ambos casos usarán las mismas funciones, cuando la llamada se realice desde conexión directa se permitirá más libertad en el paso de parámetros. El motivo es muy simple, PHP es un lenguaje interpretado que deja manga ancha a los programadores: parámetros optativos, tipos de datos no declarados explícitamente… en cambio, los protocolos de interconexión como SOAP están pensados para lenguajes más restrictivos como Java y, en consecuencia, no permiten muchos de los informalismos de PHP.

Limitaciones en la conexiones remotas

En principio las conexiones remotas deben permitir el acceso a la API mediante cualquier protocolo. Sin embargo, existe un par de condiciones que de deben cumplir en pos de conseguir una API eficiente:

• Orientación a objetos, o que pueda trabajar con datos estructurados como estructuras y matrices (”Structs” y “Arrays”).
• Que permita que el resultado de las funciones sean estructuras complejas; vectores, estructuras o vectores de estructuras.

Una vez cribados los protocolos, toca fijarnos en las limitaciones que se impondrán en las llamadas remotas. Para ello debemos fijarnos en aquellos protocolos y lenguajes estructurados que menos flexibilidad dejan al programador. Podemos decir que se va a mínimos, pero siempre teniendo en cuenta que las siguientes limitaciones sólo se aplican a las conexiones remotas, no a la directa en PHP.

Punto remoto 0: declaración de las funciones

En PHP las variables y funciones no se declaran. De echo, cuando se incluye un archivo de código, se puede suponer que se tiene acceso a todas la funciones y que los parámetros pueden pasarse sin necesidad de especificar el tipo.

Por desgracia, no ocurre los mismo con la mayoría de los lenguajes, donde es necesario declarar las funciones (los “.h” de c, por ejemplo) y los parámetros van asociados a un tipo (en Java, “int”, “boolean”…). De hecho, todos los protocolos de llamada remota requieren que las funciones invocables estén declaradas y los tipos especificados.

Por éste motivo, cada servicio dispondrá de una función especial llamada “mdl_nombreservicio_info” (a partir de ahora la llamaremos función “info”) donde las funciones públicas estarán declaradas mediante una estructura de datos. Ésta primera limitación es tan importante que se detallará en próximos artículos.

Punto remoto 1: un único tipo por parámetro

Cada parámetro de las funciones sólo podrá ser de un tipo de dato. Pese a que en algunos lenguajes de alto nivel es común que no sea así (por ejemplo que un parámetro pueda ser un entero para tratar un único identificador o un vector para tratar un conjunto) sería erróneo generalizar y, por tanto, es obligatorio especificar un único tipo en la función “info”.

Punto remoto 2: todos los parámetros son obligatorios

Los parámetros optativos son bastante habituales en los lenguajes interpretados (Python, Perl, PHP…) y otros usan polimorfismo para simularlos (Java, C#…), sin embargo el resto no disponen de ésta posibilidad, así que todos los parámetros que se especifiquen la función “info” deben ser obligatorios.

Punto remoto 3: limitaciones en los tipos de datos complejos

pese a que en la función “info” se puedan declaras tipos de datos complejos, sólo se permiten:

• vectores (”arrays”) de elementos simples (enteros, booleanos, cadenas…)
• estructuras (”structs”) de elementos simples
• vectores de estructuras

Por ejemplo, serían válidos:

• un vector de enteros
• una estructura llamada persona formada por una cadena de caracteres nombre (”String”) y un entero zapato con el número de zapato.
• un vector donde cada elemento es de tipo persona.

Y NO serían válidos (los errores están rallados):

• una estructura familia formada por la cadena dirección y un vector donde los elementos son de tipos persona y que se llama miembros. (No se permite que una estructura contenga un vector)
• un vector donde cada elemento contiene un entero y un booleano (La solución seria declarar una estructura M con un entero y un booleano y que los elementos del vector fuesen de tipo M).
• una estructura llamada principal que contenga un entero llamado simpatía y una estructura de tipo persona llamada sujeto (No se permite que una estructura contenga otra estructura).

El motivo de ésta limitación es garantizar que la mayoría de los protocolos se podrán conectar a la API sin problemas. Si se permitieran estructuras dentro de estructuras la penalización de la serialización y deserialización recursiva de las variables podría llegar a ser excesiva.
Punto remoto 4: evitar los parámetros complejos

Podemos suponer que todos los clientes potenciales de los webservices podrán usar parámetros complejos en las llamadas pero, como norma general, a costa de complicar el código. En consecuencia, se intentarán evitar en la medida de los posible.

En caso que no sea posible, es recomendable que los parámetros complejos sólo sean vectores de tipos simples (enteros, booleanos…). Por parte del cliente, montar un vector simple no supone un gran coste, sin embargo, montar una estructura con una especificación remota (por ejemplo si están definidas en el WSDL de SOAP, y no en el cliente) puede ser complicado y puede generar más acoplamiento del necesario.

Ésta recomendación sólo se aplicará a los parámetros, pero no a los resultados (o retornos). Si se intenta que todos los resultados sean simples, lo más probable es que se acaben codificando funciones incompletas que requieran de más llamadas por parte del cliente. Así que no hay ningún problema en devolver resultados complejos siempre que cumplan el punto remoto 3 y que se declaren en la función “info”.

Punto remoto 5: un único resultado y siempre del mismo tipo

Son muy pocos los lenguajes donde el tipo de dato del retorno puede variar arbitrariamente (por ejemplo devolver un objeto complejo o un identificador entero según se necesite) y muchos menos los que permiten que las funciones devuelvan más de un resultado.

Sin duda, sería un error que la API fuese permisiva en éste aspecto, así que todas las funciones tendrán un máximo de un retorno y su tipo siempre será el mismo (que será especificado en la función “info”). Además, pese a que no es obligatorio que las funciones devuelvan algo, seria recomendable que así fuese.

Limitaciones en la conexión directa PHP

Técnicamente, no existe ninguna limitación para que las funciones de la API no sean parecidas a las internas de Moodle. Sin embargo, todas las funciones deben ser invocables también desde las conexiones remotas, así que es conveniente tomar ciertas precauciones:

Punto directo 1: se permiten los parámetros optativos

Pese a que en las conexiones remotas no se permiten los parámetros optativos por limitaciones técnicas (punto remoto 2), prohibirlo en la conexión directa PHP sería limitar mucho el trabajo de los programadores y, en consecuencia, está permitido usar valores por defecto en los parámetros de las funciones.

En cualquier caso se debe asegurar que, como mínimo, aquellos parámetros que no tengan un valor por defecto estarán especificados en la función “info”. Es decir, en caso que en conexión directa se permita llamar a la función con más parámetros (algunos de ellos optativos), los obligatorios deben aparecer en la función “info”. Igualmente, cuando en conexión directa se permitan menos parámetros (por ejemplo porqué algunos valores se recogen de la sesión en caso que no se especifiquen), los optativos restantes también aparecerán “info”.

Punto directo 2: el retorno será siempre del mismo tipo

Como se ha explicado en las conexiones remotas, los retornos de una función serán siempre del mismo tipo (punto remoto 5) y tendrán limitaciones (punto remoto 3). Ésto también afecta la conexión PHP, donde será obligatorio.

Pese a que pueda parecer un planteamiento extremo, es importante que se cumpla ésta limitación. Si se permitiera devolver resultados distintos cuando se ejecuta en conexión directa o remota, estaríamos creando acomplamiento entre los conectores y la API porqué algunas partes de código serían específicas dependiendo de la conexión. Con ésta limitación se evita.

A primera vista se podría pensar que el parágrafo anterior se contradice con el punto directo 1. Sin embargo, si analizamos más a fondo, podemos ver que el punto directo 1 sólo explota los parámetros optativos de PHP y no crea acoplamiento alguno, dado que no funciona distinto según el tipo de conexión. De éste modo, si en un futuro se implementa un nuevo tipo de conector que permita parámetros optativos, el código no se modificaría en absoluto.

Punto directo 3: comprobaciones de tipo de dato en los parámetros

Para mantener las especificaciones impuestas por Moodle, es necesario permitir que los tipos de dato de los parámetros puedan ser distintos según interese (por ejemplo, pasar un entero para tratar un único elemento o vector para realizar un tratamiento masivo). Éste uso de las variables es común en PHP, sin embargo la mayoría de los lenguajes no lo soportan.

Sin duda, permitir ésto provoca un cierto grado de acoplamiento entre la API i los conectores. Por éste motivo es IMPRESCINDIBLE que la comprobación de tipos no provoque replicación de código, dado que ésto sólo limitaría la escalabilidad de la arquitectura.

Por ejemplo, supongamos que tenemos la función “mdl_user_get_users($userids)” donde el parámetro puede ser un simple entero para conseguir un usuario, o un vector de enteros para conseguir varios:

En éste caso el código se puede plantear de dos formas: suponiendo inicialmente que $userids es un vector o, por el contrario, un único entero. Pese a que las dos funciones serían parecidas y ambas cumplirían las especificaciones, la segunda opción requiere replicación y, por tanto, NO sería válida para la API.

Opción A: suponiendo que es un vector, correcta para la API:

function mdl_user_gest_users ($userids) {

 if (!is_array($userid)) $userids = array($userids);

 $res = array();

 foreach ($userids as $userid) {

   (... conseguir el usuario y ponerlo en res ...)

 }

 return $res;

}

Opción B: suponiendo que es un entero, inválida para la API (la parte replicada está rallada):

function mdl_user_gest_users ($userids) {

 $res = array();

 if (!is_numeric($userid)) {

   (... buscar el usuario y ponerlo en res ...)

 } else {

   foreach ($userids as $userid) {

     (... conseguir el usuario y ponerlo en res ...) 

   }

 }

 return $res;

}

Se permitimos que se replique código en las funciones, a la larga sería imposible mantener los dos códigos actualizados y la posibilidad de cometer errores de copia y pegar (”cut and paste”) aumentaría dramáticamente. Por éste motivo es prioritario que se cumpla esté punto y, en caso que no sea posible, se debe evitar el uso de parámetros con tipos variables.

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.