What is Middleware? Good question. If we listen to the vendors, middleware is anything that helps developers create networked applications. This includes the proverbial kitchen sink. 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 Advanced middleware services Plus: A typology of middlewar e 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: [Diagram: Basic Client/Server Component Model] 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: [Diagram: Client/Server Components-An Example] 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 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 netowrk. 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. Ac tually, 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. Advanced Middleware Services These advanced services are not yet common in middleware products, database-specific or more generic. Still, the functionality will be increasingly required by new enterprise applications. Single System Login -Missing from many database connectivity solutions is any separate authentication service. Without any security service tied into an enterprise scale directory service, users have to log into each RDBMS server separately. This means they'll either forget usernames and passwords (and call IS support all the time) or they'll breach security by keeping a list of everything on paper taped up on their monitor. Database administrators have to add a username and password to each server independently. If you remember NetWare 3.x bindery support, and how it required the administrator to do everything on each server independently, you'll have the flavor of how this works in the middleware market. Too many usernames and passwords is not a good idea. More advanced middleware solutions let the user log in once and only once to the middleware's security, which in turn handles authentication from there on using that credential. That security may or may not be the same system used in a file and print environment. Enhanced Security -Some middleware vendors have security options much better than just usernames and passwords. Look for support of card key solutions like SecureID's products. Oracle announced it was working with a fingerprint reader vendor. Beyond these access security solutions, however, don't forget to see that authentication information is passed over the network encrypted. You may even want data encryption for sensitive data. Location Transparency -Many middleware solutions don't offer a simple name service for their server or service names. If the user wants to connect to a server and can't remember the name of it, they'll have to call tech support. Advanced middleware solutions offer centralized naming services with some level of distribution. The issues are the same as those associated with DNS on the Internet or NDS on NetWare. A new frontier in middleware support for naming is in supporting more dynamic configurations, where redundant services must be targeted with load balancing and fault tolerance. Few products in the database arena are so sophisticated, but the push is on in the more general middleware market where high availability of redundant components is required. Database Oriented Services (Heterogeneous Joins, Replication) -In the database connectivity world, other services may be offered by middleware. One important service is heterogenous join support. If the middleware does a multi-RDBMS join transparently, then the client itself doesn't have to worry about the problems of handling differences and enhancing performance. Application Oriented Services (Transaction Monitoring, Queuing) -For more generic middleware environments, different application services may be required, incluing transaction monitoring and message queueing. These services are so critical that they really define different interaction mechanisms for distributed applications (see our middleware typology discussion ). Management (Configuration, Performance, Accounting) -It would be nice if a complex system like an enterprise middleware solution could be easily and effectively managed. Some products are beginning to hook into SNMP consoles, but more vendors are now offering products to monitor the health of their middleware networks specifically including third parties like BMC Software and Tivoli Systems . There's still no substitute for a Sniffer occasionally, however. Interaction With Other Network Services -While some middleware does provide its own set of advanced services, a better approach may be to offer support for external enterprise services that migth already be in use in the organization. By supporting other vendors services (security, directory, management), middleware can fit into the existing enterprise networking environment much more easily. It can leverage other systems to function more efficiently. SQL Server makes a good though proprietary example of how to hook in to enterprise services. The whole DCE world provides another. Part of Microsoft's BackOffice application server suite, SQL Server interacts with Microsoft Windows NT's domain directory for authentication services. The approach provides a server-side single login support. The user logs in once to the NT domain and never has to log in again to any BackOffice resource separately. This is a more effective approach than just caching passwords at the client, which Windows can do but many database middleware vendors don't support either, since there is only one username and password the user might ever have to change. Oracle has announced support for a variety of other services, including Banyan StreetTalk, Novell NetWare NDS, and DCE services. Sometimes, however, this support is not available on all platforms; Oracle7's NetWare NDS support is only available on the Oracle NetWare NLM server, and not for other more popular platforms. Next, let's take a closer look at a typology of the large variety of middleware products , and as well as some of the detailed considerations associated with efficient database networking middleware products . November 15, 1995 Print This Page E-mail this URL