-
-
Notifications
You must be signed in to change notification settings - Fork 9
Rationale & Advantages
Logic get you from A to B, imagination get you everywhere
Einstein
When you want to integrate two systems, you soon find out that integration was an afterthought. This is because applications are designed with one main function in mind.
For example an application created for customer relation management (CRM) is designed around managing customers. The designer creates a datamodel that matches exactly the needed business functionality. All technological components like the database and code are derived from this main function. Mostly the focus is hereby on one interface: The user interface.
This is all logical, but what if another application needs some customer related data as well? A webshop for example.
A webshop has another function with other business needs. That's why its data model is completely different from the CRM system.
Now both systems have no well-defined data interface, so how do we exchange data? What mostly is done that in one of the applications some custom module is created. This module acts as a bridge between the two data models.
Another aspect is that the data needs to be transported from one application to another. In this case the CRM system could have a daily export to a fileshare on the webshop server. The custom module of the webshop can now import the exported data into its database.
So one custom module and a fileshare needed to be created, so what the problem?
In our example we have two systems and one type of message. What when there is another system that manage data like articles and prices. This data should also go to the webshop. But there is also a warehouse management system that needs this data. And the webshop orders should go to warehouse management system and update customer data should go back to the CRM system. All of these data should be sent to an analytics platform.
With every messagetype, every system, more possibilities arise. In the first example we have only one flow, but in second example we already have 11 possible flows.
More systems, more message types mean more data interfaces. It's impossible (and just too much work) to create custom modules every time. Besides using file shares aren't safe and don't scale.
To have one way of exchanging data we let all flows pass through a middleware platform. This platform can route the data and transform the data to the datamodel of the consuming application. Now we don't need:
- Custom code in the application
and
- We only need to connect to one middleware platform.
In practice a lot of applications have no or only one way to connect to the outside world. This can be SFTP, a database table, a webservice, a broker and so on. With numerous applications, there are also numerous ways to connect to the middleware platform.
It's almost impossible to support all kind of protocols and technologies (that may not even exist). There are fortunately several projects which focus on connecting these technologies. In the Java world, most common are Spring Integration and Apache Camel. They solve data integration problems on a data and on an infrastructural level.
Assimbly uses the Camel Framework to create flexible and reliable integrations.
Even when using integration frameworks to bridge the gap between systems, the number of connections can get quickly out of control. There are many many ways to get the data from and to applications or to the middleware platform.
For example:
- A service on the middleware platform (ESB service)
- A web service/API gateway on the middleware platform (SOAP/REST)
- A web service/API gateway standalone (SOAP/REST)
- A module directly build into the application which handles integration
- A script on the application server
- A program (for example based on Apache Camel)
- An adapter
The end result: multiple ways to connect, spread over the entire application landscape.
When there are so many ways to connect applications and middleware with each other there are also a lot of pains. Hereunder are some of them listed, together with the gains when using Assimbly gateway.
| Pain | Gain |
|---|---|
| Every time when a new project or new technology appears, things are done differently. The available connectors only works with a limited set of technologies. Result is multiple ways of connecting applications with each other or middleware platform. | Every connection is created the same way. |
| Pain | Gain |
|---|---|
| The custom module works with some technologies, but now the project want something else. This isn't supported and the project should adjust the available connectors | Technology adapts to business needs. |
| Pain | Gain |
|---|---|
| So the basic stuff works, but what about scalability, fault tolerance and security? | Scalability, fault tolerance, security are build-in. |
| Pain | Gain |
|---|---|
| So there is an integration module available, but one that only works with one running flow. If there are multiple instances, every time a new instance needs to be created/started. | Multiple instances (flows) run in one gateway. |
| Pain | Gain |
|---|---|
| There can be a lot of pain, because of dependencies: | Assimbly depends on Camel, but is like Assimbly self, open source. A big community and knowledge and support is available. So if you need the be dependable, it better is something rock-solid like Apache Camel. |
| One of the worst is a dependency on people. For example only one guy can adjust the integration module. What if this person leaves the company or is hit by a bus? | |
| Another is dependency on certain technologies, like OS, application or middleware. This make it hard to migrate | |
| Third are dependencies on license restrictions. This can hold back to add a connection or hardware licenses. Because you pay per connection or core |
| Pain | Gain |
|---|---|
| The integration module is somewhere on a server. You need to have access on this machine to perform command line functions. When something happens, it takes time to log in (if you're lucky to have access). And it's hard to find out who did what | Remotely accessible from any browser, including audits. |
| Pain | Gain |
|---|---|
| All connections are spread over the landscape. There is no oversight of what is running. Maybe there is middleware, but the connections stay spaghetti. | Central management and statistics |
| Also there is no clear view on load or errors. |
| Pain | Gain |
|---|---|
| Manual configuration are time-consuming and error prone. There is no input validation or even worse you need to code and deploy every time :) | Intuitive GUI. |
No matter how your integration is set up, Assimbly acts as one way to connect applications in a reliable and easy way. Without dependencies, you're more flexible for change. For example when changing the broker you can configure the gateway to connect to the new broker. Besides Assimbly is extensible with new components. In short, it makes your integration agile.