Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

Middleware: Where Client/Server Hits The Road (Network)

Let's focus on the networking aspect of middleware functionality by considering this: "Is TCP/IP an example of middleware?"

TCP/IP surely helps as infrastructure on which to pin up networked applications. TCP/IP, however, is not middleware by itself, nor is the sockets interface above it. It's too low level.

Speaking in OSI network model terms, middleware is higher layer software, above the network and transport layers exemplified by the TCP/IP protocol suite and its sockets interface. Often, middleware products will supply session, presentation and application layer components.

OK, so where's TCP/IP? It provides the basic network transport between the two nodes on the network, connecting client to server. So, using TCP/IP as our only piece of middleware, our client/server component diagram would look like this:

[Diagram: TCP/IP as Middleware?]

To use TCP/IP as their middleware, application programmers could use TCP/IP's application programming interface (API) called sockets (WinSock on Windows platforms, now that Microsoft has decided that this API is part of its WOSA collection). But, then they'd be communications programmers. Unfortunately, programming to sockets isn't what most application programmers want to do. It's too complex, too full of communications functions that require programmer work. Moreover, supporting TCP/IP in the application doesn't help get other protocols like NetWare IPX/SPX or IBM SNA LU 6.2 or even fancy new ATM services supported as alternate transports.

Application programmers want to be shielded from the complexity of the network. They just want their application to work over the network. So, new layers of functionality were layered on top of the basic transport functionality. These new layers are the middleware. Here's our diagram with the middleware included:

[Diagram: Client/Server Component Model With Middleware]

Middleware comes between the application programmer--tool vendor, RDBMS vendor, whatever--and the network below. Middleware is in the middle. You still need the networking pieces below (like TCP/IP), but applications don't have to know that they are even running over TCP/IP at all. That is left as a run-time decision. The flexibility to put off networking decisions is provided by the middleware. Application programmers can keep doing their work (creating business-related applications), while the detail of making applications work over the network is left to middleware programmers (and application deployment teams).

The multiple perspectives on middleware are represented in this diagram:

[ Diagram: Client/Server Perspectives]

This very indirection provided by middleware, however, is also problematic. The unfortunate byproduct of this "hide and forget" or "leave the driving to us" thinking is that application programmers in fact remain disjointed from the networking impact of their middleware implementations. Realizing and handling that impact is left to the unfortunate network manager when bringing up the first installation of client/server applications.

All too often, however, no one pays attention to the middleware (and how it performs over the actual network in the organization) until too late. At run time, application developers find out the performance of their application architecture is not adequate or won't scale across WAN boundaries. The network manager starts pointing the finger at the application developer. Both point at the middleware vendor. All should have been working together all along.

November 15, 1995