Hacia un sistema centralizado
Anteriormente se afirmó que la versión 3 del software Celsius es, a diferencia de sus antecesores, un sistema centralizado y único. Para entender qué significa esto es necesario comprender cómo ha evolucionado este sistema y qué restricciones imponía el modelo anterior. Cuando en 2001 se creó el software Celsius, era utilizado principalmente en la UNLP para obtener estadísticas del servicio de intercambio, y paulatinamente fue incorporando funciones que permitían realizar la gestión de los pedidos de usuarios. Poco a poco, el software fue creciendo hasta convertirse en una herramienta integral, que cubría buena parte del flujo de trabajo diario de este servicio, y además generaba estadísticas en vivo muy útiles. Esta versión inicial fue cedida a unas pocas instituciones de LibLink, quienes comenzaron a usarlo para obtener métricas y gestionar los pedidos de sus propios usuarios. Esta cesión requería que las instituciones que instaron Celsius dispongan de un equipo capaz de ejecutar un servidor web y un servidor de bases de datos. También requería personal idóneo, capaz de instalar y mantener estos servidores, y de instalar, mantener y brindar los servicios básicos requeridos por cualquier sistema web: monitoreo, seguridad, backups desatendidos, etc.
Al multiplicarse la cantidad de usuarios, comenzaron a surgir nuevos requerimientos para el software: mas y mejores estadísticas, automatización de tareas de administración, nuevos servicios para los usuarios, adaptaciones estéticas para navegadores web modernos, personalización de la interfaz gráfica para cada institución, entre otras. Es así como surgieron las distintas versiones de Celsius 1.x. Mientras tanto, más instituciones seguían instalando el software, aunque ahora cada una instalaba la última versión disponible, y muy pocas realizaban la actualización desde la versión original que habían instalado en sus servidores inicialmente.
Esto generó una gran dispersión de versiones instaladas. Sumado a esto, las herramientas sobre las que corría Celsius (como por ejemplo servidor web, intérprete PHP y servidor MySQL) continuaban evolucionando, y las últimas versiones de Celsius sumaban compatibilidad con estas versiones.
Cuando la base de instancias o instalaciones de Celsius instaladas creció a varias decenas, fue necesario implementar un mecanismo para compartir información entre todas ellas: catálogos de instituciones, información de países, instituciones, dependencias y unidades, revistas científicas, etc. También surgió la necesidad de integrar los flujos de trabajo entre instancias remotas, de modo de permitir que un administrador de una instancia A pueda enviar una solicitud de su propia instancia hacia una instancia B, sin tener que ingresar a esta y cargarla manualmente (repitiendo toda la información cargada en su instancia).
Estos nuevos requerimientos derivaron en el desarrollo de Celsius Network o Celsius NT, durante los años 2005 y 2006, y aquí comenzó nuevamente una sucesión de versiones en evolución: Celsius NT 2.0, 2.0.1, 2.0.2, y así sucesivamente hasta Celsius NT 2.0.9 en el año 2015.
Si bien la evolución resultó muy positiva para los usuarios y las instituciones, la dispersión de versiones comenzó a ser insostenible: muchas instituciones continuaban con versiones 1.x, y otras con alguna versión 2.0.x, pero muy pocas se mantenían realmente actualizadas hacía la última versión. Sumado a esto, las nuevas incorporaciones a Celsius sumaban nuevas herramientas y funciones que
hacían complejo el proceso de instalación y actualización: interconexión con webservices, importación remota de datos desde una base de datos centralizada (directorio Celsius), comunicación intra e inter instancia, por nombrar algunas. Muy pocas instituciones contaban con personal técnico capacitado y/o con infraestructura (servidores, redes, etc.) para realizar la instalación, mantenimiento, actualización, monitoreo y dar soporte a sus propios usuarios, y como resultado, las instalaciones de nuevas instancias tomaban meses y requerían un gran esfuerzo de soporte por parte de los desarrolladores: muchas instituciones perdían datos por falta de backups automáticos, no se aplicaban las actualizaciones de nuevas versiones, etc.
Con una base instalada de más de 80 instancias de Celsius distribuídas en América y España, el modelo distribuído ya no parecía ser el mejor. Todo esto afectaba principalmente a las instituciones con menos recursos económicos y técnicos. Es así como, en el año 2012, comenzó a desarrollarse una nueva versión de Celsius, basada en un modelo centralizado y disponible para los usuarios como software como servicio (software as a service, SaaS). Este desarrollo implicó reescribir todo el código fuente de Celsius, utilizando nuevas tecnologías y brindando servicios acordes a los tiempos actuales: aplicaciones interactivas, adaptación a dispositivos móviles, caché de archivos, encriptación, entre otros. En este modelo centralizado, las instituciones se desentienden de la gestión del servidor, del mantenimiento del software, del monitoreo y de los backups: todo esto se realiza desde un servidor centralizado, y se crean nuevas instancias de Celsius por medio de una herramienta de gestión de la red de instancias, que a su vez permite homologar y compartir datos de interés para todas las instancias: catálogos, contactos, instituciones, etc.
A mediados de 2015 se liberó la primera versión de Celsius 3 v1.0, disponible en principio para la UNLP, a fin de detectar y corregir errores tanto en el código como en la migración de datos. A fines de 2015 se realizó la actualización hacia Celsius 3 v1.1, ya mucho más estable y con capacidad para contener múltiples instancias independientes dentro del software, con lo cual comenzaron a incorporarse instancias de instituciones que se suman a LibLink. Al momento de redactar este manual, Celsius 3 v1.2 ya está próximo a finalizarse, y se está desarrollando en paralelo Celsius 3 v2.0, Celsius 3 v2.5 y Celsius 3 v3.0 .