What is the middleware (if any) in web-service consumed by a website?

Question

I am trying to identify the parts of an architecture.

The server (Python) acts as a web-service, delivering files and data. The client (JS) requests the data which it needs by sending xmlhttprequests to the server.

I read that there can be a "middleware" layer that connects the application with its node of the distributed system. The point of the middleware is to abstract away the underlying network communication

SOAP is given as an example for being a middleware protocol. I do not use SOAP (or REST) Does that mean I do not have a middleware? I'm using plain old HTTP for the communication. Is that enough of an abstraction to be called a middleware? On the other hand, HTTP is part of the TCP/IP stack, which makes me think it is a part of the network communication and not an abstraction thereof. That would suggest that I do not use/have a middleware.

What exactly is a middleware in this scenario?

---

further confusion

One part of the problem is that it's not very clear what the middleware actually is and that there are different definitions of it.

What I found so far and what I asked this question upon is that there exists one layer of middleware, per node in the distributed system. The middleware layers are not directly connected. It is the network underneath the middleware that ensures the connection. The middleware is there to provide an abstraction layer between the application and the network.

See this image:

Each middleware block is separate. that makes sense. Chances are that the middleware for Mac OS is an entirely different thing than the middleware for Windows. On each application builds upon its specific middleware.

Another way to think about it is that the middleware actually is pretty much the only thing that connects the nodes of the distributed system as can be seen in the image from wikipedia:

This looks like a contradiction. In one scenario, each part of the application talks to its individual middleware, which in turn talks to the node of the network. The middleware is the common base line that separates the distributed application from the distributed system underneath. In the other, the middleware is some big blob that spans across all nodes which means that there is no such thing as individual middlewares for each node.

I have the growing suspicion that everybody makes up their own interpretation of this not strictly defined terminology.

the answer

is that there is no (clear) answer. The accepted answer provides reasonable thoughts about the whole matter. The terminology falls apart if applied in a rigorous concrete way.

Answer 1

Wikipedia has a suitable definition for Middleware. It says:

Middleware is the software that connects software components or enterprise applications. [It] is the software layer that lies between the operating system and the applications on each side of a distributed computer network. Typically, it supports complex, distributed business software applications.

In other words, it's the software in the middle, in between systems. It is the way that distinct software systems communicate with each other.

If you're working with heterogenous systems, the way you communicate with them, and the way you fulfill each system's expectations in terms of interface and workflow, can vary drastically from system to system. Some systems are fairly straightforward to work with; they have standard web services and a sensible REST interface. Others may not have such niceties, and may actually require you to scrape their websites to get any useful information from them, or even import a text or binary file in some proprietary format. The use of SOAP or REST does not necessarily define middleware, in that regard.

Some middleware attempts to map systems to each other through configurable interfaces, business rules and workflows. Biztalk is one such attempt. As different systems begin to converge on standardized ways of communicating with each other (i.e. REST models), such mapping should become less common; the programmer will put more focus on the business processes required to connect different systems together, rather than communication protocols.