Moodle WebServices

Designing a Webservices Architecture for Moodle: Moodle-DFWs.

The purpose of this entry is to analyze the interoperability needs of Moode, and to make a proposal of architecture (that is already partially implemented). We call this Moodle-DFWs, because it needs a name. All this work is being done in the Universitat Politecnica de Catalunya by the group known as DFWikiteam.

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

Tags: Architecture, Moodle, Webservices

Trackback URI | Comments RSS