We have decided to re-implement Ontohub from scratch, because
- even if there is some decoupling into services, the core service (written in Ruby on Rails 3) is still too monolithic and therefore unmanageably complex. It shall be therefore decoupled into a backend (in Ruby on Rails 5) and a frontend (in ember.js).
- this further decoupling of services follows the OOR architecture
- we would need to migrate from Ruby on Rails 3 (which will be no longer maintained) to Ruby on Rails 5 in several steps, which could be even more costly than a re-implementation.
- we could not get along with many problems in using sidekiq as a background service. We hope that RabbitMQ, a true service broker, will be better here. Moreover, servers providing Hets as a service can be registered more easily
- new programmers could be attracted, because we start from scratch
- the ember.js frontend, written in Javascript, could attract more programmers than the former Ruby on Rails core, because ember.js is easier to learn.
- even a re-implementation can re-use parts of the existing code basis
- last but not least, the user interface could be re-designed in order to better meet usability
#Cornerstones of the new architecture
- Separation of backend and frontend:
- We have a full featured JSON API backend, implemented with the current version of Rails.
- There is a separate application written with EmberJS that servers as the frontend and communicates with the backend.
- More distributed communication with Hets:
- Analysis is done by distributed instances of Hets.
- OMS-Parsing workers are distributed as well.
- These two are listening on queues that are managed by RabbitMQ: The backend pushes jobs to the queues and as soon as a worker (analysis or parsing) is free, this worker starts the job. The results of the analysis (JSON output of Hets) are pushed back to RabbitMQ such that the parsing can be started. Parsing results are written directly to the database and indexed in Elasticsearch and the backend is notified about it via RabbitMQ such that the result can be pushed to the frontend via websockets.
- There are several, controversially discussed ways of integrating git, gitlab, github with Ontohub.
##Onothub components and their git repositories
- ontohub-models: Data model for Ontohub, to be used by backend and by hets-ontohub-adapter
- ontohub-frontend: The Ontohub web UI for the end user
- ontohub-backend: The main Ontohub service that servers the data for the frontend and other client via the JSON API
- hets-rabbitmq-wrapper: RabbitMQ wrapper for Hets
- hets-ontohub-adapter: Adapter converting Hets data structures into Ontohub models
- ontohub-git-shell: git shell for interaction with git clients
Looks like great work here. I thought folks here might be interested to hear (possibly Fabian) that starting from a few different design constraints, last year I mostly completed a multi cast infrastructure to spread data to interested receivers, then aggregate results. The infrastructure demonstrates type-safe information flow control in monadic regions. Of interest here is that this year I hope to integrate my prior work on the constructive proof of the satisfaction condition of an institution and a Kan extension encoding of concepts, objects and representations. Folks can see some of the work on satisfaction here http://rickmurphy.org/Sat.hs and concepts here http://rickmurphy.org/kan-concepts.html