Abr 10 2008
Arquitectura de los webservices de Moodle
Para garantizar el éxito de la capa de interoperabilidad es necesario tener en cuenta algunos requisitos:
- 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.
