Middleware is one of those terms everyone pretends to understand but one that no-one really does. Part of the problem, though, is that you never see middleware.
So… what is it then?
A good way to think of it is as a cord connecting two separate things together. Let’s take Mrs Lee and Mrs Selah. They live across the road from each other, but by picking up their telephones they can communicate with one another. While we see the two talking, we don’t notice the telephone wire connecting them: that’s the middleware.
Okay, so now instead of Mrs Lee we have a database system, and instead of Mrs Selah, let’s take a web server.
The middleware connects the two together and allows them to interact: users can request data from the database system via a web browser (eg. typing in a search on Google) and the middleware enables the database system to talk to the web server, which then returns web pages that match the user’s criteria.
It makes things standardised
Mrs Lee could probably try and make her own telephone line, and it might work and connect her to Mrs Burton. But it’s easier for her to use the one outside her house that already exists, because it’s built on established, open standards.
These standards let the two people, or systems, talk to each other: did we mention that Mrs Selah is Indian, and doesn’t speak English? Or that Mrs Lee doesn’t understand Punjabi? The telephone line connecting the two friends translates what Mrs Lee is saying so Mrs Selah understands, and vice versa.
It all acts as one big network
There’s another thing, of course: Mrs Lee doesn’t just want to speak with Mrs Selah. She wants to talk to a whole host of people, and the different telephone wires connect her to all these different friends, and it conveys all the information she wants to tell them, enabling them to act on it. This is just like the way in which middleware passes on information from one application to another, and does so with lots and lots of them.
Just like when a new house is built the whole telephone network doesn’t need an overhaul, you just add a new line connecting the house, when you add a new application to your business you don’t need to overhaul your existing middleware.
That’s because it doesn’t matter if the applications don’t speak the same language: a popular method of integrating new applicationsis called a service-oriented architecture (SOA) approach. To integrate applications all doing different things, all added at different times, and all of which speak different languages, you don’t need a one-size-fits-all system.
Instead you just plug these applications into your enterprise system bus (ESB), which is something that acts as a server, messaging and API service. The ESB carries out the task of translating messages between all the different languages, and routing those messages to where they’re meant to go: making sure everyone is talking to the right person.
