If you work in IT, you must know about middleware. In fact, this simple concept is at the foundation of our fast-paced world. Even if it isn’t the most appealing thing ever, it is a pillar for almost any application. Why is that, and how? In this post, we will see what is middleware software and how to use it in your application.
Middleware Software
What is a middleware software?
In short, middleware is the fusion of two words: middle and software. And, guess what, middleware is a software that stays in the middle. To be more specific, it is a software that stays in between two other software components, like a hamburger in a sandwich.
It is part of a pipeline of information. In fact, the main goal of any software is to elaborate information, and to do that information must move around. Thus, information has to move from one software to another, and middleware facilitates that. If you are confused a little don’t worry, we will address everything now.
Why can’t a single software do all the processing?
It can, but modern tasks are no joke. In fact, modern application requires the interaction of multiple parties and components. For example, think about buying something on Amazon.com. As soon as you submit the order, several parties come to play:
- Amazon’s website handles your order
- Your bank must provide authorization for the payment
- The card company (e.g. VISA, MasterCard) relay the request to your bank
- Amazon’s logistics software takes charge of your shipment
- The shipping company gets your order
And probably much more. In this case, you clearly see that no single entity manages the entire process. Instead, many entities play different roles. Thus, you need interaction to connect with software from other companies. But that’s what APIs are for, you don’t necessarily need a middleware.
Sometimes, your application is huge. So huge you may want to split it into different applications, each doing only a part of the job. However, data needs to flow between those application fragments. That’s another reason you need multiple software: modern challenges are too big for a single one.
The shape of middleware
Middlewares come in many forms. They can be software running on a server, containers or even standalone appliances. Sometimes, you create your own middleware software. Instead, other times you purchase a preconfigured middleware application (e.g. Mulesoft).
How to use middleware
If we answer how to use middleware, we will also see why you should use it. We already know more or less the way to use it: put it between two other software. But what does this mean?
You have one software that needs to engage another, for example, the webserver wanting to send an order to the logistics application. You can engage directly that application, but you have some compatibility problems. For example, the logistics application may want to receive a file in FTP, but the webserver cannot support FTP, it only supports REST.
With middleware, you make an additional software that receives a file with REST and then sends it to the logistics software with FTP. In other words, you translate technologies. This is the main goal of middleware, and also the difference from an API.
In fact, an API simply is a way for another software to engage your software. Instead, middleware is an additional software that translates between different technologies.
Typical use case
In the ideal world, you don’t need middleware at all. That’s just utopia because the real world is hungry for middleware. Normally, middleware comes to play when you have legacy applications. Or, even better, when you want to integrate applications from different eras or with different technology designs.
Complex use cases of middleware
Imagine you have a legacy application that reads data from a disk to process orders (e.g. shipments). However, your company grew and you added more sites. While the database is one in the HQ, each distribution center has its own application that wants to write in the disk when an order is shipped.
At first, you map on all servers the disk in HQ as a network disk and this works for your national branches. But you expand overseas, say from the US to Australia. You try the same approach, but your application starts to timeout because of latency.
You need a better approach. The option here is to have an active middleware, that moves data between applications on its own, not waiting for either of the two to do an action. So, you set up a middleware to fetch with FTP data from the server in HQ, and copy it to the server in Australia every hour, and then copy the differences back. This is something you may do with Mulesoft, in fact.
In conclusion
In conclusion, middleware software is something that stays in the back but that makes the complex interactions possible. These complex interactions, in turn, make the modern world possible. Middleware is all about integration and enablement.
Do you ever use middleware software? Let me know in the comments.
