-
-
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 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 on one interface: The user interface.
This is all logical, but what if another application needs some customer related data as well?
A webshop has another function with other business needs. That's why its data model is completely different than that of the CRM system. Now both 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 two data models. Another aspect is that the data needs to be transported from one application to another. In this case the CRM could have a daily export to directory (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 needs to be created, so what the problem?
Now 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 arrise. In the first example we have only one flow, but in second example we already have 11 flows.
More systems, more message types mean more possible flows. 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. There also can be numerous way to connect to the middleware platform. If for example a broker used, it can be a MQTT broker, a JMS Broker, a Pub-Sub Broker, an AMQP broker and so on. The way to connect also depends on the specific implementation of that technology.
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 Sprint Integration and Apache Camel. They solve data integration problems one a data and on a infrastructural level.
Even when using integration frameworks to bridge the gap between systems, the number of connections can get quickly out of control. Often you still need to code a lot. And even when you have central middleware platform there are many ways to get the data from and to the platform. For example:
- A service on the middleware platform (ESB service)
- A web service 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 programm (for example based on Apache Camel)
- An adapter
Maybe some components support multiple ways of connecting, but mostly not all. The end result are multiple ways to connect, spread over the entire application landscape. Each component is configured and managed separately.
When there many way to connect to applications and middleware there are a lot pains. Hereunder are some of them list, together with the gain when using Assimbly gateway.
| Pain | Gain |
|---|---|
| Every time a new project or new technology appears, | Every connection is created the same way. |
| things are done differently. The available connector | |
| only works with a limited set of technologies. | |
| Result are multiple ways of connecting | |
| applications with each other or middleware | |
| platform. |
| Pain | Pain |
|---|---|
| So there is integration module, but one that only | Multiple instances in one gateway |
| works with one running flow. If there are multiple | |
| instances needed, everytime a new one needs to | |
| be created/started. |
| Pain | Gain |
|---|---|
| So the basic stuff works, but what about | Scalability, fault tolerance, security |
| scalability, fault tolerance, security. | are build-in |
| Pain | Gain |
|---|---|
| The custom module works with some technologies | Technology adapts to business needs |
| but now the project want something else. This | |
| isn't supported and the project should adjust | |
| to the connection available technology |
| Pain | Gain |
|---|---|
| There can be a lot of pain, because of | Assimbly depends on Camel, but this is |
| dependencies. | like Assimbly self, open source. A big |
| One of the worst is a dependency on people. For example only | community and knowledge and support |
| one guy can adjust the intgration moduele or has enough expertise. | is available. |
| What if this person leaves the company or hit by a bus? | So if you need the be dependable, it |
| Another is dependencies on certain | better is something rock-solid |
| technologies, like OS, application or | |
| middleware. This make it hard to migrate | |
| Third is dependencies on license restrications | |
| This can hold back to add a connection or | |
| hardware licenses |
| Pain | Gain |
|---|---|
| The integration module is somewhere on a | Remotely accessible from any browser |
| server. | including audits. |
| You need to have access on this machine to | |
| perform command line functions | |
| When something happesn, it takes time to | |
| log in (if you have access). And it's hard | |
| to find out who did what |
| Pain | Gain |
|---|---|
| All connections are spread over the landscape | Central management and statistics |
| There is no oversight of what is running. | |
| Maybe there is middleware, but the connections | |
| stay spaghetti | |
| Als there is no clear view on load or errors. |
| Pain | Gain |
|---|---|
| Manual configuration are time consuming and | Intuitive GUI |
| error prone. There is no input validation | |
| or if worse code and deploy |
....
No matter how you're integration is setup, Assimbly acts as one way to connect application to the preferred integration in a reliable and easy way. You're not dependent on that way. For example when changing the broker you can change gateway to connect to that broker.