Syndesis backend architecture
This document want to illustrates at high level some of the components that makes up Syndesis and how they are communicating together to finally serves the creation of an integration. We are using Apache Camel as a runtime target, though it would be possible to extend the project and makes it suitable to any other integration platform.
Disclaimer: the content illustrated here is related to version 1.8, it can change in future versions.
Before deep dive in the diagram illustration, let’s recap the list of main components involved in Syndesis:
- UI: component dedicated to serve the user interface
- Server: mainly used for storing information persistently and retrieving its content from UI
- JSonDB: a database where we store json formatted documents
- Meta: used to report specific information of each connector
- Connector: acts as a proxy between Syndesis and integration platform
- Integration: generate an integration project based on the integration platform template
- S2I: used to create a runtime where the integration will run
Here is a bottom up view (from integration platform to UI) of Syndesis. As the aim of the document is to highlight the backend components we feel it more natural to start the dissertation from the target integration runtime.
Figure 1. Backend architecture
When you want to create an integration, you generally starts with the definition of how this integration will interact with the integration platform runtime. In Syndesis this is mediated by the ComponentProxy whose goal is to decouple the Syndesis specific model from the integration platform. Through the development of a Connector you will therefore be able to bring your integration platform functionality in Syndesis: in the case depicted you will be able to port any Camel component into Syndesis by developing a Connector. The whole list of connectors will be finally your list of available sources/destination that you will be able to use in your Syndesis installation.
A ProjectGenerator is using the list of connectors and is built by the S2I whose result is a Dockerized IntegrationRuntime. The runtime contains all the dependencies that any integration running upon it will be needing. For this reason the idea is to bundle together at this stage a docker image that will be used as extension point by the real integration that you will define later on: in our case the integration generated is a Spring Boot application that will be kicked off in a container: everything completely transparent to the final user!
The user will finally interact to the system through a UI that will use a RESTful API (Server) to expose properly the feature. All is read/stored to a document based database (JsonDB) and any possible special feature needed by some connector is bridged by the Meta component that is queried by the Server, again, through a RESTful API.
The discussion provided in this document is leaving other details (such as deployment, logging, authorization, …) on purpose as it wants to be a first and quick approach to the architecture behind Syndesis.