WSO2 Enterprise Integrator 6 vs 7
What’s the difference? When to use, which version?
Everybody loves freedom and the opportunity to make choices. But sometimes, “making the right choice” itself becomes the most stressful thing. As the number of options on your table keeps growing, it exponentially keeps increasing the difficulty of making the right choice. A methodical way such as listing pros and cons on a spreadsheet is one way of doing this. However, it is questionable if we could—or remember to—list down everything that we care about and if there is a reasonable mechanism to put a score in front of them.
In a regular routine, I meet many professionals who have been tasked to make such choices. What I describe here is mostly applicable to product-evaluation and migration phases of IT projects. Some of them are certain of what they want to achieve and expect the product vendor to provide and support exactly what they have chosen to use. Meanwhile, the others design software platforms to serve the current set of requirements while fitting in the path of emerging trends that could become prominent in the future. At the same time, their choices are also influenced by other factors such as existing relationships with certain product/platform vendors and budgetary restrictions.
When considering this sort of differences in people and technical communities, a certain product vendor must invest a significant effort in research and development to be in line with technological trends while investing equally on complimenting the existing concepts and methodologies. In simple words, a certain product vendor has to provide their (existing and potential) customers with multiple options for their choice!
From my personal point-of-view, I see WSO2 Enterprise Integrator version 7.x (EI-7x) as an option for choice rather than being the direct successor of WSO2 Enterprise Integrator version 6.x (EI-6x). In fact, WSO2 provides Long-Term-Support of 10 years for EI-6x also with continuous regular updates via WSO2 Update Manager (WUM)channel due to this very reason.
But, as I mentioned earlier, this can result in some confusion as in most cases the product vendors encourage customers to upgrade the software platforms with the latest version.
Everybody loves freedom and the opportunity to make choices. But sometimes, “making the right choice” itself becomes the most stressful thing. As the number of options on your table keeps growing, it exponentially keeps increasing the difficulty of making the right choice.
Therefore, let’s discuss why and when you should choose a particular version of WSO2 EI-6x series or EI-7x series.
Differences in Functional Profiles
EI-6x comes as a single binary distribution combining below-given profiles.
- Integration Server (Services, protocols & data integration)
- Message Broker
- Workflow Engine (BPEL, BPMN)
Based on the profile you choose during the server start-up, each EI-6x runtime instance will behave accordingly.
Under the EI-7x label, you get two different well-optimised binary distributions that help to create two types of functional runtimes.
- Micro Integrator (A minified binary pack of the Integration Server)
- Streaming Integrator (To process and act on events in real-time)
If you look for a Message broker, Workflow engine or Stream integrator (processor), at this point, it is clear which version your choice has to be. Therefore, let’s narrow the scope down to “Integration” as it helps understanding how other factors could influence your choice when selecting between EI-6x or EI-7x.
Composition of Integration Artefacts
The mediation engine and the libraries used in both EI-6x and EI-7x are the same. Therefore, integration developers use the same set of tools, techniques and the same (declarative) language to compose mediation flows. This allows you to deploy the same Integration Artefacts on either runtime (i.e. EI-6x or EI-7x) without having to make any modifications. Especially, this helps when you are about to perform a migration.
The architecture of Runtime
While both EI-6x and EI-7x being JVM based runtimes, the way you would use them will be different.
EI-6x is an application server-like runtime which would host many different integration artefacts similar to how an application server hosts many different web applications. While the EI-6x server runtime keeps running, the users can deploy/remove integration artefacts.
EI-7x introduces an immutable runtime approach instead of behaving similar to an application server. That means the runtime is built by encapsulating the integration artefacts, rather than deploying them on an already up-and-running runtime environment. Also, this is a minified, lightweight runtime that only consists of the essentials. Therefore, its start-up delay is significantly lower than EI-6x, which is ideal for container-based deployments.
Scaling and resources utilisation
The above diagram depicts how four different integration artefacts (composite archives) would scale in both EI-6x and EI-7x. Since that famous topic on ‘the monolith vs micro-services’ has been there in discussions for a while, I believe that you will see the level of isolation of hardware resources and independence of different deployments that you can achieve with EI-7x.
X was designed for Y—but works perfectly with Z
EI-6x can be considered as a product that was designed for conventional virtual-machines based deployments. It also works on containers without issues. However, it will be impractical to use the real advantages of containers with this. For example, server-like runtimes take more time to start up and make itself available for service compared to the start-up delay of containers.
EI-7x is a minified, lightweight runtime that only consists of the essentials. Its start-up delay is significantly lower than EI-6x, which is ideal for container-based deployments. Therefore, EI-7x can be considered as a product that was designed to fit—and take advantage of—modern infrastructure platforms that use containers (e.g Docker) and container orchestration systems (e.g. Kubernetes). However, there is nothing that prevents you from deploying in on virtual-machines if you choose to do so.
Therefore, EI-7x can be considered as a product that was designed to fit — and take advantage of — modern infrastructure platforms that use containers (e.g Docker) and container orchestration systems (e.g. Kubernetes).
Wrapping up
WSO2 is an engineering-driven technology company that invests a significant effort in designing and producing integration products to fit in and compliment those emerging industrial requirements and promising technological trends. As a result, there can be multiple products that overlap the same functional domains such as the Enterprise Integrator 6x series and 7x series, which is the subject of this article. So, what is the EI series that fits your exact set of use cases or simply your choice has to be?
If you already read through the five sections above to understand the similarities, differences and the development effort that you have to put when migrating from one version to another, now you know your own answer to that question.
[ The official WSO2 documentation https://ei.docs.wso2.com/en/7.1.0/micro-integrator/references/comparisong-mi7-ei6xx/ ]
