Tecnología de la UOC

Arquitectura

La capa de servicios

La capa de servicios (Service Layer)

capa_tecno

La arquitectura tecnológica de la UOC es una arquitectura orientada a servicios (en inglés Service Oriented Architecture, SOA). Diseñar según el paradigma SOA significa pensar en un sistema como un conjunto de módulos con una funcionalidad y responsabilidad públicas (los servicios) y un conjunto de mecanismos que permiten la interacción entre ellos (tanto de forma local como remota). Así pues, SOA permite la creación de sistemas muy escalables y define una forma estándar de exposición e invocación de estos servicios. De hecho los beneficios que aporta SOA a una organización según la Wikipedia son:

  • Mejora en los tiempos de realización de cambios tecnológicos.
  • Facilidad para adaptarse a diferentes modelos de negocios, en especial a aquellos basados en la colaboración con otras instituciones.
  • Facilidad para mejorar o reemplazar elementos sin disrupción en el proceso de negocio.
  • Facilidad para la integración de diferentes tecnologías.

En el marco de la arquitectura de la UOC, SOA permite combinar las diferentes tecnologías que coexisten en el sistema, como C++, Java o PHP; facilita la interacción entre diferentes aplicaciones propias de la universidad y de terceros como SAP, Moodle o Google Apps; y ofrece un marco abierto y adecuado para integrar nuevas herramientas en la UOC o para que las herramientas de la UOC se puedan integrar en otros sistemas.

En una arquitectura SOA, pues, los elementos más destacados son los servicios. Un servicio (service en inglés) es, técnicamente, una colección de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Así, las prescripciones de las aplicaciones que pueden ser usadas por otros componentes del sistema se exponen en forma de servicios y están accesibles mediante estos mecanismos.

El acceso a los servicios puede ser público o restringido. En el caso de la UOC hay cinco servicios públicos que permiten que las aplicaciones externas interaccionen y se integren con el Campus Virtual. El resto de los servicios, la gran mayoría, son restringidos y conforman el catálogo de servicios empresariales de la universidad que permite que un determinado componente del sistema pueda tener acceso a la información de la institución de forma ordenada y controlada.

Servicios públicos de acceso a la UOC (Campus Services interfaces)

En la arquitectura de la UOC hay cinco servicios principales públicos que permiten a aplicaciones externas interaccionar con el Campus Virtual de la UOC. En el argot informático, este conjunto de servicios reciben el nombre de API (Application Programming Interface), interfaz de programación de aplicaciones, dado que en definitiva es la parte pública del Campus de la cual las aplicaciones externas pueden hacer uso. Hay que destacar que «público» no quiere decir, en absoluto, inseguro, hacen falta determinados privilegios para poder acceder a cierta información de Campus Virtual, y cuando se quiere hacer uso de estos servicios hay que notificarlo previamente. Los cinco servicios disponibles son:

  • Autentificación: el servicio de autentificación permite validar las credenciales de un usuario y darle paso o no al sistema. También verificar si un usuario ha sido autentificado o no.
  • Autorización: el servicio de autorización permite conocer si un usuario está autorizado para acceder a una funcionalidad o a un recurso determinado.
  • Seguimiento: el servicio de seguimiento permite registrar el sistema de datos de seguimiento. Los datos de seguimiento hacen posible, por ejemplo, que un profesor conozca qué uso han hecho sus estudiantes de los recursos que hay en el aula.
  • Internacionalización: el servicio de internacionalización o localización hace que una aplicación pueda declarar los literales de su interfaz. Permite también introducir las traducciones de estos literales en otros idiomas, de forma que la aplicación puede mostrarse en cualquiera de los idiomas que se han ido introduciendo.
  • Configuración: el servicio de configuración permite la definición, asignación y paso de parámetros entre la aplicación y el sistema.
     

Con la publicación de estos servicios Campus, la UOC abre las puertas a la colaboración y la integración de su entorno de aprendizaje con otras instituciones, a la vez que permite integrar herramientas y componentes de otras instituciones en la UOC. Este nuevo modelo de interoperabilidad responde a lo que hoy está pasando en internet, donde la mayoría de las herramientas web 2.0 ofrecen una API con el fin de que otras aplicaciones puedan integrar sus funcionalidades. De hecho, la interoperabilidad en cuanto al e-learning es uno de los focos de interés y uno de los retos por resolver para la mayoría de las instituciones que se dedican al aprendizaje virtual. En esta línea, la UOC ha creado su API basándose en iniciativas internacionales y con el ánimo de definir un conjunto de servicios estándares no sólo útiles para el Campus de la UOC, sino también para otros LMS como Moodle o Sakai. Así, cualquier herramienta que utilice la API de la UOC puede funcionar también con Moodle, Sakai e incluso otros LMS. La especificación de los servicios Campus y el software necesario para poder utilizarla con los diferentes LMS está disponible bajo licencia de software libre en la web del proyecto Campus Project: http://www.campusproject.org.

Para integrar una herramienta externa en el Campus de la UOC hace falta, pues, únicamente, acceder a esta web, descargar la documentación y el software y programar un adaptador o plug-in que, utilizando los cinco servicios descritos, interacciona con el Campus. Dado que estos servicios también funcionan con otros LMS, durante la fase de desarrollo no hay que utilizar el Campus de la UOC; se puede hacer el desarrollo con Moodle, por ejemplo, y después ejecutarlo contra el Campus de la UOC. Además, este desarrollo no es válido sólo para la UOC, sino que funcionaría para cualquier institución que utilice alguno de los LMS compatible, por ejemplo, Moodle.

Los servicios web (Web Services)

Los servicios web son, hoy en día, el modelo de computación distribuida que resuelve mejor el problema de la interoperatibilidad entre aplicaciones muy diversas, entre diferentes plataformas, lenguajes de programación diferentes y distintas ubicaciones geográficas en la red. Los servicios web fomentan el uso de los estándares y protocolos basados en texto como XML, lo que hace más fácil acceder a su contenido y entender su funcionamiento. Por contra, su rendimiento es bajo si se compara con otros modelos de computación distribuida, como son RMI, CORVA o DCOM. Esta es la principal desventaja derivada de adoptar un formato basado en texto, pero, aun así, las ventajas y la simplicidad de este modelo con respecto a los otros lo hacen bastante aconsejable.

En la UOC, los servicios web son el mecanismo más utilizado para la interacción entre las diferentes aplicaciones. Buena parte del trabajo de transición de la UOC al modelo SOA ha consistido en eso: definir y estandarizar los servicios web necesarios con el fin de que las aplicaciones se puedan comunicar entre ellas sólo mediante este mecanismo. Actualmente la UOC tiene disponible un catálogo de aproximadamente unos setenta servicios web diferentes. Este catálogo va creciendo a medida que se van introduciendo nuevas aplicaciones y funcionalidades.

El Enterprise Service Bus (ESB)

Como ya se ha mencionado en otros apartados, la UOC acumula diferentes tecnologías y aplicaciones, fruto tanto de los quince años de historia como de la tendencia actual a la diversidad tecnológica. Disponer de una arquitectura que permita y fomente esta diversidad es básico para poder aunar dos tendencias que, a menudo, no son compatibles: (1) Hace falta poder mantener sistemas antiguos, por lo cual responden bien a su función; (2) hace falta poder incorporar las últimas tendencias, nuevas herramientas y nuevas tecnologías. En resumidas cuentas, el objetivo es poder hacer la elección de herramientas y aplicaciones en función de las necesidades de los usuarios y no en función de restricciones tecnológicas que imponga el sistema.

Una de las piezas más importantes para conseguir este propósito es el ESB (Enterprise Service Bus). Un ESB es un elemento que permite la comunicación y el paso de mensajes entre servicios. Los servicios se comunican con el Bus sin conocer aspectos concretos de la tipología de la red o del servicio con el que se comunican. El Bus aísla el sistema de toda esta complejidad y ofrece mecanismos con el fin de que sea posible el intercambio de mensajes con independencia de la tecnología y de la arquitectura física implicada en toda la secuencia del paso de mensaje. En resumidas cuentas, una arquitectura ESB proporciona una capa de abstracción que permite la comunicación de aplicaciones a través de múltiples protocolos de comunicación y la agregación, la recombinación y la transformación de servicios.

En el caso de la UOC, el ESB (de Oracle) permite que coexistan e interactúen entre sí aplicaciones con tecnologías muy diferentes (Java, PHP, C++, PL/SQL y .NET), y, asimismo, permite también catalogar todos los servicios disponibles, monitorizarlos y hacer cambios sin que afecte al funcionamiento de las aplicaciones. Poder cambiar los servicios, ampliarlos e ir adaptándolos a las nuevas necesidades sin interferir en el funcionamiento del sistema es esencial para que un sistema aspire a la evolución constante y mantenga un alto nivel de servicio.