El intercambio de datos entre distintas aplicaciones informáticas puede parecer algo relativamente sencillo que se consigue sin más, pero esto en general, no es cierto. En primer lugar los programas usan identificativos que normalmente no son compatibles. Por ejemplo, usando el DNI como clave para identificar a personas, podríamos establecer una correspondencia entre sus datos en las distintas aplicaciones. Pero si las claves no son las mismas, por ejemplo, si cada aplicación genera sus propios códigos como ocurre con frecuencia, la correspondencia se hace imposible sin un arduo y prolijo trabajo manual. Otro motivo evidente es que las relaciones entre los datos y sus estructuras internas también son propias de cada aplicación.
Para integrar los datos entre distintas aplicaciones se hace necesaria la existencia de interfaces bien diseñadas y documentadas, a través de las cuales se puedan exponer los datos y comunicarse los programas. No hay otro modo. Pero esta condición, si bien es necesaria, no es suficiente. Además de una interfaz, debe ser posible establecer una correspondencia entre los códigos que se usen en una y otra aplicación para identificar sus elementos de información.
Si ponemos por caso una aplicación que realiza una petición de servicio a otra, la primera debe facilitar sus claves para que luego pueda interpretar el resultado una vez resuelto. Es decir, si una aplicación pide que se le resuelva una tarea, a través de la interfaz común debe aportar, además de la información propia de la petición, las claves necesarias para entender el resultado que reciba. Concretándolo más con un ejemplo, supongamos una aplicación que solicita a otra un servicio para resolver un horario académico. En este caso el horario resuelto debería expresarse usando claves para que la aplicación que lo pide lo reconozca. De este modo podrá identificar en la solución a los profesores, materias, etc. El acuerdo de formatos y de claves entre las dos aplicaciones debe ser preciso para que funcione y ambas partes deben de colaborar necesariamente en ello.
Existen algunas aplicaciones que exponen sus propias interfaces de intercambio sin que sean del todo operativas, con deficiencias de diseño que impiden que la carga del resultado pueda recibirse correctamente. Se hace por lo tanto necesaria la implementación de interfaces abiertas bien definidas y documentadas para la comunicación entre aplicaciones. De hecho existen organismos de estandarización que las establecen. En su defecto se podrían adoptar como estándares las interfaces abiertas asociadas a productos consolidados que se publiquen con este fin.
Peñalara Software ha hecho público el formato interno de almacenamiento de GHC para usarlo como interface de intercambio. El formato XML-GHC es completo. Todo aquello que se configura con el planificador, así como los resultados que genera GHC, puede expresarse con este modelo.
Además, junto al desarrollo de un nuevo motor de horarios que esperamos ofrecer próximamente como servicio remoto, disponemos de interfaces abiertas JSON que podrán consultarse a través del repositorio público GitHub y que están asociadas a librerías de desarrollo también disponibles, en este caso, en Apache Maven. Con este proyecto intentamos ofrecer servicios para la generación los horarios al ecosistema de aplicaciones de gestión académica, y así facilitar en última instancia el trabajo a los usuarios.