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
@baclawski, @knowlengr: actually, the current decision is to use git (not github!) as a repository backend. The reason is that
1 git provides good version control (I am not sure about whether a CMS can really match this)
2. Ontohub has about 250 users that have already created lots of git repositories,
3. the COLORE repository, one of the largest non-OWL ontology repositories I know, uses git,
4. users can work off-line on their git repositories and then push their commits, which is not possible using a CMS.
Indeed, this last point gives me the feeling that git is much more decentralised than a CMS could be. But maybe I do not know the right CMS?