UOC Technology

Technology Infrastructure

Application Infrastructure



The most diverse technologies coexist in the environment. Although the architecture is focused on the j2ee development on Jboss AS, we also keep other architectures in the catalogue such as Php developments, Oracle Application Server 10G, Oracle Forms 4(FMX Runtime), Oracle Forms 10g. Oracle Web Server, MySql, Tomcat, Apache, and others.

The architecture is based on the multi-layer client-server paradigm. We focus our efforts on the redundancy of the applications servers, so that it is always a set of servers that respond to a specific service, providing redundancy and scalability. This load distribution between servers is done through the load balancers. For this, we use two balancing types, one via hardware and the other at the application level.

In exceptions where there are specific functions of a single server, we always have procedures in place for a speedy transfer of the specific function from one server to another to reduce the impact of these single fault points to the utmost.

The configuration of all the applications servers will have the most advanced common part possible, which will facilitate the interchange of servers and boost redundancy and scalability.

With this architecture, in which a group of n servers may be allocated to a group of n services, the bottleneck usually lies in the backends (basically centralised database servers). It is, therefore, in these servers where we set out the highest requirements in terms of availability and maintenance SLAs.

Click on the picture to zoom.

The figure shows the basic layout of the UOC's applications architecture.

The applications are monitored with requests both via balancer and directly to each frontend. As an example, the monitoring of an application may include:

  • monitoring an application by balancer.
  • monitoring the balancers by software.
  • monitoring a jboss instance on 4 physical servers.
  • monitoring 4 applications on 4 physical servers.

This way, it is easier to monitor an incident. In most cases, an incident will not have any impact on the end service due to the path redundancy that an end customer has or an application in accessing the service required.


Given the diversity of applications and services offered by the UOC, not just for its customers but also for the administration of the university, we have a significant set of databases, two of which are the main ones for them all as a whole: the one that provides service to the Virtual Campus and the one that centralises the university's administration data.

Each of these databases is connected to a storage network by fibre channels, so having speedy write and read accesses. Owing to the large number of users interacting with our applications simultaneously, these databases are usually subjected to a load level of some 150 transactions per second.

Besides this, we have a set of databases for data warehouse, responsible for supporting the consultations associated with business processes.

Evidently, given the critical nature of the services, there are copies practically in real time of these databases, which would allow us to be able to recover the production almost without losing any data in the event of a contingency. These copies are distributed in two data centers, which would allow us to recover the services in the event of a disaster.

Click on the picture to zoom.