UOC Technology

Architecture

The Service Layer

The Service Layer

capa_tecno

The UOC's technology architecture is a service-oriented architecture (SOA). A SOA design approach entails understanding a system as a set of modules with a public responsibility and functionality (the services) and a set of mechanisms that support the interaction between them (both locally and remotely). Thus, a SOA facilitates creating very scalable systems and defines a standard way of providing and invoking these services. According to Wikipedia, a SOA provides the following benefits to an organization:

  • Reduction in time taken to implement technology changes.
  • Ease of adaptation to different business models, especially those based on collaboration with other institutions.
  • Ease of improving or replacing elements without disrupting the business process.
  • Ease of integrating different technologies.

In the context of the UOC's architecture, a SOA permits combining the different technologies that coexist in the system, such as C++, Java and PHP; facilitates the interaction between different University and third-party applications, such as SAP, Moodle and Google Apps; and offers an open framework capable of integrating new tools into the UOC and allowing UOC tools to be integrated into other systems.

Therefore, in a SOA, the services are the most important elements. A service is, at a technical level, a collection of protocols and standards for exchanging data between applications. So, the functions of the applications that can be used by other components of the system are provided as services and are accessible via these mechanisms.

Service access can be public or restricted. In the case of the UOC, there are five public services that allow external applications to interact and integrate with the Virtual Campus. The rest of the services, the great majority, are restricted and make up the catalogue of the University's business services that let a given component of the system access the data of the Institution in an orderly and controlled manner.

Access to the UOC's Public Services (Campus Services Interfaces)

In the UOC's architecture, there are five main public services that let external applications interact with the UOC's Virtual Campus. In IT jargon, this set of services is an API, an Application Programming Interface, as it the public part of the Campus of which the external applications can make use. It is important to note that public does not mean insecure. Specific privileges are required to access different information in the Virtual Campus and using these services requires prior notification. The five services available are:

  • Authentication: The authentication service supports validating the credentials of users and granting them with access or not to the system. It also supports verifying if a user has been authenticated.
  • Authorization: The authorization service supports determining if a user is authorized to access a given function or resource.
  • Monitoring: The monitoring service supports recording monitoring data in the system. Monitoring data allows, for example, a lecturer to see what use students make of classroom resources.
  • Internationalization: The internationalization or localization service supports applications declaring their interface literals. It also supports including the translations of these literals in other languages so that the application can be displayed in any of the languages that have been included.
  • Configuration: The configuration service supports defining, assigning and transferring parameters between applications and the system.

With the publication of these Campus services, the UOC opens its doors to the collaboration and integration of its learning environment with other institutions at the same time as allowing the integration of tools and components of other institutions into the UOC. This new model of interoperability is owing to the move to the Internet where the majority of Web 2.0 tools provide an API so other applications can integrate their functionality. In the field of e-learning, interoperability is, in fact, one of the interest focuses and one of the challenges the majority of the institutions that offer e-learning have to meet. In this vein, the UOC created its API based on international initiatives and with the desire to define a set of standard services useful not only for the UOC's Campus but also for other LMSs, such as Moodle and Sakai. So, any tool used by the UOC's API can work with Moodle, Sakai and other LMSs. The specification of the Campus Services and the software required to use it with different LMSs are available under free software licence from the Campus Project's page: http://www.campusproject.org.

Integrating an external tool in the UOC's Campus requires only accessing this Web page, downloading the documentation and the software, and programming an adaptor or plug-in that interacts with the Campus using the five services described. As these services also work with other LMSs, it is not necessary to use the UOC's Campus during the development phase; the development can be done using, for example, Moodle, and it can be later executed on the UOC's Campus. In addition, as well as being valid for the UOC, this development would work with any other institution that uses any of the compatible LMSs, such as Moodle.

The Web Services

Web services are today the distributed computing model that best resolves the problem of interoperability between very diverse applications and different platforms, programming languages and geographical locations on the different networks. Web services foster the use of text-based standards and protocols, such as XML, which makes it easier to access their content and understand their operation. On the other hand, their performance is low compared to other distributed computing models, such as RMI, CORBA and DCOM. This is the main disadvantage with adopting a text-based format, although the advantages and simplicity of this model compared to others make it a good choice.

At the UOC, the Web services are the mechanisms most used for the interaction between the different applications. A large part of the UOC's work in moving to the SOA model involved this-defining and standardising the Web services required so that the applications could communicate with each other using this mechanism. The UOC currently has a catalogue of approximately 70 different Web services. This catalogue continues to grow with the new applications and functionality that are being added.

The Enterprise Service Bus (ESB)

As mentioned above, the UOC has accumulated different technologies and applications owing to its fifteen years of history and the current trend towards technological diversity. Having an architecture that allows and promotes this diversity is fundamental for being able to combine two tendencies that appear incompatible: (1) to be able to maintain old systems because they serve their purpose well; (2) to be able to incorporate the latest tendencies, new tools and new technologies. Basically, the aim is to be able to select tools and applications according to user needs and not technology restrictions imposed by the system.

One of the most important elements for achieving this is the ESB (Enterprise Service Bus). An ESB supports communication and sending messages between services. The services communicate with the bus without knowing specific aspects on the type of network or the service with which they are communicating. The bus isolates the system from all this complexity and provides mechanisms that enable the exchange of messages regardless of the physical architecture and technology involved in the message transfer sequence. Basically, an ESB architecture provides an abstraction layer that allows applications to communicate via multiple communication protocols and the addition, recombining and transforming of services.

In the case of the UOC, the ESB (from Oracle) allows applications with very different technologies (Java, PHP, C++, PL/SQL and .NET) to interact. It also permits cataloguing all the available services, monitoring them and making changes to them without affecting the operation of the applications. Being able to change the services, extend them and adapt them to new requirements without interfering with the operation of the system is vital for a system that aspires to constantly evolve while maintaining a high level of service.