Middleware is anything that is not part of an operating system, and neither is it part of one software application, but rather lies between them.
It acts as a bridge between your request and application.
There are two types of protocols in middlewares:
UDP is message-oriented.
TCP is stream-oriented.
UDP and TCP are package-oriented in OSI level 5 (Transport).
TCP is stream-oriented, but are partitioned into packages.
MOM Middleware is a communication message queue.
MOM is a software or hardware infrastructure supporting sending and receiving messages between distributed systems.
Message-oriented protocols send data in distinct chunks or groups.
Streaming protocols are communicated as a sequence of bytes with no explicit message boundaries.
Streaming protocols are always built on above protocols using discrete messages such as frames (Ethernet), datagrams (UDP), packets (IP), and cells (ATM).
This middleware layer allows software components (applications, servlets, and other components) that have been developed independently and that run on different networked platforms to interact with one another.
Applications distributed on different network nodes use the application interface to communicate.
MOM provides software elements that reside in all communicating components of a client/server architecture and typically support asynchronous calls between the client and server applications.
MOM reduces the involvement of application developers with the complexity of the master-slave nature of the client/server mechanism.
Remote procedure call (RPC-based) middlewares.
Object request broker (ORB-based) middlewares.
Message-oriented middleware (MOM-based) middlewares.
All these models make it possible for one software component to affect the behavior of another component over a network.
They are different in that RPC- and ORB-based middleware create systems of tightly coupled components, whereas MOM-based systems allow for a loose coupling of components.
In an RPC- or ORB-based system, when one procedure calls another, it must wait for the called procedure to return before it can do anything else.
In these mostly synchronous messaging models, the middleware functions partly as a super-linker, locating the called procedure on a network and using network services to pass function or method parameters to the procedure and then to return results.