This repository has been archived by the owner on Jun 3, 2022. It is now read-only.
How it works
-
A user creates a project and can store any type of files in it
-
The user can transform its xlsx files to RDF by using the skosConversion
-
The user can upload a shacl shapes file, then validate any rdf file he uploaded with it
-
The user can store a rdf within his project into the triplestore (blazegraph)
-
The user can store a rdf within his project in nosql database with json-ld format to speed queries
-
The event-dispatcher topic extracts, transforms the event and redirect it to the topic of the workers responsible to consume it (e.g elastic-sink,rdf-sink, mongodb-sink).
-
The Workers (ElasticSink,FileSkink,RdfSink, MongoDbSink) consumes the message & persist them
- The event-dispatcher topic is the source of truth.
- It can be consumed from start to restore/sync blazegraph/mongodb
- The sub-topics (worker topics) can be regularly deleted
- Micro service architecture combined with a Message Broker makes it easier to maintain and develop new functionalities
- the sinks: responsible to persist on db, running asynchronous, use kafka and event-driven
- the rests: responsible to interact with the end-user, eventually sync, also shared with the sinks (e.g to save a file)
- The rest microservices communicate each other with Zookeeper (as a service discovery) and feign (as a proxy interface to ease the rest calls).
- It is possible for the sinks to communicate with these rest services without zookeeper, through the rest-gateway service
- the rest-gateway is used as a proxy for each rest services and tools (e.g mongoexpress, blazgraph-ui,...)
- The sink microservices communicate each other with Kafka.
- The messages are dispatched with the event-dispatcher