One of our active projects is to backport Moodle 2.0 webservices to Moodle 1.9.
Because of all the differences between Moodle 2.0 and Moodle 1.9 we will have to put into practice some tricks. The following image is a diagram of the designed achitecture:
We have added to Moodle 2.0 webservices architecture a couple of components to solve some problems.
Core Layer
Core Layer has nearly the same elements that Moodle 2.0 core layer, but these elements had not been evolved. There are methods that print success messages to the screen, database libraries print error messages too, etc. This is a big problem! We don’t want to re-program all these functions, it would be a waste of time.
External Layer
We will copy external layer from Moodle 2.0 to Moodle 1.9. We want to make easier the upgrade from Moodle 1.9 to Moodle 2.0, we have to publish the same functions with the same parameters. We will have to tune their implementation a little, some published functions only exist on Moodle 2.0 or have changed a little from the previous version.
Local External REST Server is a new component that will provide a REST webservice throught localhost. It will call external functions, serialize results and return them.
Connectors Layer
We will copy all connectors from Moodle 2.0 to Moodle 1.9 and develop a proxy to the local REST server. The External Proxy will define the same functions that Moodle 2.0 Connectors are calling to the External layer. The main idea is to change all requires/includes in connectors to invoke proxy’s methods. The proxy will call external functions via local webservice and return the result.
Why are we doing this odd and tricky things?
If Moodle 1.9 core prints something to the screen, it will break all webservices response. Using this architecture, the only message that will be broken will be the response of local webservice call. If the Proxy detects an error in the local call (it can unserialize the response), it would know how to proceed in every situation.
April 28th, 2009 at 4:42 pm
Sobre esto que comentas:
If Moodle 1.9 core prints something to the screen, it will break all webservices response. Using this architecture, the only message that will be broken will be the response of local webservice call. If the Proxy detects an error in the local call (it can unserialize the response), it would know how to proceed in every situation.
Puedes utilizar una técnica en php que es redirigir la salida estándar de esas funciones a una variable usando los buffers de php. De esta forma te aseguras que no te va a sacar nada por pantalla que “te rompa”
Aquí tienes un ejemplo, es usar simplemente un par de funciones:
http://bura-bura.com/blog/archives/2004/12/01/php-tip-redirecting-echo-output/
Espero que te sirva
April 29th, 2009 at 12:02 pm
Esto si que me parece una buena solución, la paranoia esta del servidor REST local es idea de mi jefe y no me acaba de gustar.
Sea como sea, habra que añadir algun elemento en alguna de las capas para evitar el printado por pantalla.
April 29th, 2009 at 3:14 pm
Ah, y gracias por la pista
April 29th, 2009 at 5:26 pm
De nada, es una idea más, no sé si os encajará bien en vuestro planning.
Desde el punto de vista conceptual, la vuestra es más elegante, desde el práctico os llevaría menos tiempo usando buffers.
¿Tenéis estimado para cuando tendréis el backport hecho?
A nosotros (CV&A Consulting) nos interesaría para un proyecto disponer de esta funcionalidad por lo que podríamos hablar de alguna colaboración para centrar esfuerzos.
Si te parece, puedes contactarme en jleyva ARR-OBA cvaconsulting.com
May 8th, 2009 at 8:38 am
Creo que vamos a aprovechar la idea de los buffer para hacer un desarrollo rapido y tenerlo listo pronto.
Después ya añadiremos lo otro encima, así mejoramos a la escalavilidad y la seguridad.
Nos vemos.