Middleware sits "in the middle" between application software that may be working on different operating systems. It is similar to the middle layer of three-tier single system architecture, except that it is stretched across multiple systems or applications. Examples include EAI software, telecommunications software, transaction monitors, and messaging-and-queuing software.

The distinction between operating system and middleware functionality is, to some extent, arbitrary. While core kernel functionality can only be provided by the operating system itself, some functionality previously provided by separately sold middleware is now integrated in operating systems. A typical example is the TCP/IP stack for telecommunications, nowadays included in virtually every operating system.

In simulation technology, middleware is generally used in the context of the high level architecture (HLA) that applies to many distributed simulations. It is a layer of software that lies between the application code and the run-time infrastructure. Middleware generally consists of a library of functions, and enables a number of applications – simulations or federates in HLA terminology – to page these functions from the common library rather than re-create them for each application.

In the computer industry, middleware is a general term for any programming that serves to "glue together" or mediate between two separate and often already existing programs. A common application of middleware is to allow programs written for access to a particular database to access other databases.

Typically, middleware programs provide messaging services so that different applications can communicate. The systematic tying together of disparate applications, often through the use of middleware, is known as enterprise application integration (EAI).

Okay, I think that the previous section define the term middleware from academic view, maybe we can be a bit more specific about what middleware is by describing what it does. First, though, we need a basic model to show where middleware fits among the other pieces of the client/server puzzle.

We'll divide our discussion into three areas:

• Basic client/server component model
  
• Basic middleware services
  
• Types of middleware
  

Basic Client/Server Component Model

We've created a simple network application model to help explain the concept of middleware, and we'll use it throughout this guide. Instead of the OSI network model, we have basic chunks on servers and clients, including operating system, application program, and the connectivity pieces like network protocols and middleware software.



Here's our model which is defined in the context of database networking middleware:



The middleware is right there in the middle (called database connectivity middleware in our diagram). Notice that middleware components are instantiated on both client and server platforms. Since some definitions of middleware include code that isolates operating systems from hardware platform differences (like the hardware abstraction layer or HAL in Windows NT), let's keep our discussion focused on middleware for distributed systems. In some cases, there will be more middleware services provided by an intermediate device like a database gateway. The next diagram provides a more specific example using Oracle and PowerBuilder on common platforms:



What does the middleware do? Simply put, it provides a set of services to applications like a client/server database as depicted in our diagram. What are those services? Read on.

Basic Middleware Services

The basic set of middleware services are offered by most products today. We'll refer to Microsoft's SQL Server RDBMS (Relational Data Base Management System or Relational) and its DB-Library data access middleware as an example. Services offered include:

Client/Server Connectivity -Middleware provides the mechanism by which network applications communicate across the network. This includes in the case of database networking for example the service of putting packages of query results data into network transport packets. Microsoft SQL Server, for example, uses Sybase's Tabular Data Stream (TDS) protocol to handle formatting of data for transport across the network. This session layer interaction may also have its own timers and even error control to handle automatic retransmission of lost packets. One feature common is the ability for the client to interrupt the current operation on the server to cancel a large query response download. (We'll discuss the various mechanisms provided in depth when we discuss the typology of Middleware later.)

Platform Transparency -Client and server don't have to have intimate knowledge of each other in order for work to get done. Differences between platform specific encodings like big-endian and little-endian or EBCDIC and ASCII are typically hidden by middleware. Middleware often runs on a variety of platforms, letting the organization utilize all its existing desktop and server hardware as applications require. Still, some middleware products find it hard to look beyond Windows clients and UNIX or Windows NT servers. Make sure the middleware you're buying handles all the platforms you really have deployed. Microsoft SQL Server DB-Library middleware provides access only to Windows NT servers (since that's the only supported SQL Server host platform), but does so from DOS, Windows (3.1, 95, NT), Mac and UNIX clients (though not all this client software ships with SQL Server itself).



Network Transparency and Isolation -Middleware often makes networking choices transparent to application programmers. Actually, though, every middleware product we've ever heard of runs on TCP/IP, with all the other protocols coming in a distant second. If you want to be more prepared to run tomorrow's middleware, get on the TCP/IP bandwagon. Then again, don't let application programmers become too divorced from networking decisions; it can lead to poorly designed applications.



SQL Server supports multiple protocols between clients and servers, though some are specific to a given platform. From Macs, the choices are TCP/IP and AppleTalk. From PCs, there are more choices: TCP/IP, NetWare IPX/SPX, and NetBIOS/NetBEUI (Named Pipes). In some cases, the client and server don't even have to run the same network protocol between them. An intermediate device which might best be called a database relay can get the two end nodes talking to each other. But, they'll need the same middleware product everywhere to make this happen.



Application and Tool Support (APIs) -Before middleware can be used, it must present its own API to client applications that might use it. For shrink-wrapped tools like a database query tool, the API support can be critical. While ODBC has provided some level of transparency across multiple proprietary database APIs, many RDBMS vendors still encourage using their own proprietary APIs. Be sure you know what APIs your middleware offers as well as what APIs your tools can use. Hopefully there's a match! SQL Server offers both ODBC standard and DB-Library proprietary APIs on the client. For more generic middleware, the API on the server must be available as well; for RDBMS middleware, the server side is typically hard-coded to support an RDBMS.



Language Support -Middleware often provides transparency across different SQL database dialects. Even when coding in embedded SQL in a 3GL, the middleware mig ht allow the use of a single SQL dialect across a variety of RDBMS back ends. Outside of the database specific middleware products, generic middleware products often allow different programming languages to be used to create the distinct pieces of an application (pieces that reside on different machines). Since SQL Server's DB-Library only supports SQL Server RDBMSs, the SQL dialect supported is Transact SQL, a superset of ANSI 89 SQL created by Sybase and Microsoft.



RDBMS Support -When we focus on database networking middleware (also called data access middleware), middleware may also provide a level of transparency across different data storage formats. It will make different RDBMSs look like the same RDBMS. ODBC is one way of hiding RDBMS differences, but middleware products often provide multiple RDBMS support from both proprietary and standard APIs. SQL Server's DB-Library middleware does support ODBC interfaces, but still natively gets users to SQL Server RDBMS only.



Much database networking middleware is closely tied to the RDBMS of that same vendor. To get to even more data sources, database gateway products are needed. Third party products like TechGnosis SequeLink or IBI EDA/SQL offer more variety in RDBMSs. Even Microsoft has recently allied with IBI to have their multi-RDBMS connectivity solution connected to the DB-Library network so that DB-Library clients can get to RDBMSs other than SQL Server.



For non-data access products, RDBMS functionality can still be provided using extensions to make accessing that kind of data directly easy over the middleware solution deployed. NetWeave is one messaging vendor that also has database access software options.



Clearly we've run through quite a number of useful kitchen appliances already, way beyond just the sink. Let's examine the more advanced services middleware might be providing.



Types of middleware

For many programmers, middleware is like a black box. Middleware helps get the job done more quickly and keeps the programmer from having to worry about even more things. Most application programmers prefer to keep that black box closed. They'll learn how to make calls to the box and get results back, but they won't try to understand what goes on in the box.

Middleware is sometimes called plumbing because it connects two sides of an application and passes data between them. Common middleware categories include:

1. Message Oriented Middleware. This is a large category and includes asynchronous store and forward application messaging capabilities as well as integration brokers that perform message transformation and routing or even business process coordination.
   
2. Object Middleware. This category consists largely of Object Request Brokers that were mentioned on one of the earlier definitions.
   
3. RPC Middleware. This type of middleware provides for calling procedures on remote systems, hence the name Remote Procedure Call. Unlike message oriented middleware, RPC middleware represents synchronous interactions between systems and is commonly used within an application.
   
4. Database Middleware. Database middleware allows direct access to data structures and provides interaction directly with databases. There are database gateways and a variety of connectivity options. Extract, Transform, and Load (ETL) packages are included in this category.
   
5. Transaction Middleware. This category as used in the Middleware Resource Center includes traditional transaction processing monitors (TPM) and web application servers. One could make the case for splitting the category.
   
6. Portals. We include enterprise portal servers as middleware largely because they facilitate what we refer to as "front end" integration. They allow interaction between the user's desktop and back end systems and services.