Break up Assimbly
Part 3: Architectural principles of the Assimbly project
The Assimbly project is creating an open integration stack with modules that are:
- Open source
- Vendor Independent
- Multi/Hybrid-Cloud
- Service-Orientated
- Function-Orientated
- Modular
- API-Based
- Low-Code
These are all the trends we identified in the previous part. As we saw in the first part, the architecture of Assimbly is built in much like a temple. Within the temple, we can find many of these trends.
Now let’s discuss them in detail and break Assimbly apart in several pieces:
The foundation: languages and frameworks
The foundations are technologies can change, but not so often. The basic foundation layer is Java. All other frameworks and tools are also open source. The most important integration framework used in Assimbly is Apache Camel. Camel by itself is already modular and service-orientated. The most import web frameworks are Spring Boot (backend) and Angular (Frontend).
Note that there are Java API’s and REST API’s build on the top of these frameworks, thus it remains possible to change some frameworks with another when necessary.
All frameworks used are proven open source technologies. Assimbly stands so to say “on the shoulders of giants”. Building on such software allows you to make faster steps and benefit from broader developments, which in turn make new columns possible.
The columns: An Assimbly module
A column in Assimbly represents a so-called integration function. A function means that a module is responsible for a specific role in the integration layer. For example transport or interfacing.
Examples of such functions are:
- Connector: Adapter between software components. Often acts as protocol bridge. Interoperability function.
- Broker: A middleware layer with queues and topics. Act as a transport component. Transport function.
- API: A collection of endpoints around a business function.
- Service Bus: Contains the integration logic like transformation and filtering.
Within the Assimbly project, we focussed on the “Connector” and “Broker” columns so far. Leaving other functions to other software.
Layers
Besides these vertical columns, every column has horizontal layers. These layers are not functional, but technical. Layers are for example a Java API, REST API or a User Interface. The design principles behind these layers are abstraction and reuse. Every module (a column) thus always has the same layers.
The base layer
The bottom building block of this column is the Base Module. This contains various utilities classes used in Assimbly. Think of utilities for working with configuration, certificates and encryption. This module is used in every Assimbly module.
The implementation layer
Above the Base Module, there is a block that contains the logic for a specific integration function. The so-called implementation. For example for the connector (interoperability) or broker (transport) module.
The interface layers
There are three types of interface layers:
- Java interface
- REST interface
- User interface
These interfaces, sometimes called API’s, are key to Assimbly. Each interface is a separate building block. Consider for example the broker module. On top of the base it has a Java API which has two implementations:
The Java interface offers design-time modularity. It can be called within any Java application.
The User Interface and the REST API, can be called in runtime, offering runtime modularity. The REST interface is there so that Assimbly can be called language-agnostic through HTTP calls. The UI makes it possible to manage a module from a browser without knowledge of Java or REST.
Design time
The upper building blocks rest on the lower building blocks. That is, a connector or broker module needs a base module. The Rest API again rests on the Java API modules and so on. The reverse is not true. A Base Module can be used as an independent building block. The applies whenever your building block goes up.
The dependencies of the building blocks are downwards, never upwards. Here is an example of the connector module:
If you took away the bottom building blocks, the column would fall over.
Runtime
Where does Assimbly run? Basically everywhere. Assimbly is a Java application, so it’s running in a Java Virtual Machine (JVM) and may run natively in the future. The virtual machine can run anywhere from a local laptop, a server, a Docker container or within a cluster like Kubernetes.
But what’s exactly that it is running? From the start of the Assimbly project, it was the idea to make it possible to run Assimbly from just one file: gateway.jar (or assimbly.jar)
When running the jar, you can open your browser and login into the user interface:
Assimbly.jar, one could say, is a complete integration platform. This is great for local development, but in production often every module will run separately on a server or within a container. We come back to this topic in the last part.
Runtime dependencies
In addition to build time dependencies, within some building blocks you can also add dependencies at runtime. Runtime dependencies are often a bit more difficult to implement, but are more dynamic for end-users.
Some examples are:
Database: It is possible to specify the database at startup. If nothing is specified then an embedded database is used (h2), otherwise any database is supported by Hibernate (Think of MySQL, PostgreSQL, SQLServer and Oracle).
Broker: Users can change between ActiveMQ Classic and ActiveMQ Artemis on the fly. This is because the UI calls the same REST/JAVA API that is translated to a specific implementation.
Frontend: The default frontend is an Angular application, but other frontends can be developed in for example React, Vue or a REST tool like Insomnia, Postman or Curl can be used to manage the Assimbly module.
Camel components: Camel has hundreds of components. Think of a FILE, KAFKA or HTTPS component. Not all components are supported by Assimbly from build time (as Maven dependencies).
If a connector flow is started with an unsupported dependency, then Assimbly Gateway tries to resolve it in runtime by taking the following actions:
- Find the Maven dependency in the Camel catalog.
- Resolve the dependency through Jeka (a Java alternative for Maven).
- Load the resolved dependencies at runtime.
Independent
In the software temple, the rooftop is the place of the integrations. Integrations are the components that really do the work. That move the data from A to B.
All these integrations run on the top of a platform. The platform consists of various integration modules, the columns. Not every column needs to be an Assimbly module! To create a complete platform. It is wrapped up in such a way that it can work with several other (integration) software.
Or start at the beginning:
