Database Middleware: The Details Matter Now that we've discussed the theory of middleware, let's discuss the facts. The facts are many. In fact, often the devil is in those details. A few examples from database networking middleware products we've worked with. Some are no longer obstacles (more recent product releases have handled certain dependencies), but the examples still serve to warn any implementer to sweat the details and pilot everything on real networks and platforms before going forward. If we look back to the general diagram, we see that there are many dependencies that must be checked. Just conside r every border between each component. [Diagram: Basic Client/Server Component Model] Here are a variety of points to verify: The front end tool must interface with the database networking middleware. While ODBC has helped, you still get tools that don't support the client API offered by the middleware, particularly outside of the major vendors. Versions of each piece of software matter. Older versions of a tool may not support a given API, but the newer version does. We noticed that older versions of middleware client software were causing problems with some applications too. The client and server middleware products must run on the operating systems needed. You can't connect Macs to your Informix database: they simply have no Macintosh based client software to use. Make sure the middleware vendor doesn't require you upgrade operating systems--that might be a little more work than you intended. The middleware needs to support the network protocols you have in use , particularly those on the clients and servers you need to connect. While the single protocol tyranny can be overcome using database relay products , it doesn't do much good if you only run NetWare IPX/SPX in your shop and the middleware requires TCP/IP. Moreover, we've seen where versions were excruciatingly important. On Windows, most middleware now supports the WinSOCK interface, but there are still TCP/IP stacks out there that don't offer it. Or, you may not have upgraded to the new version. The middleware should be consistant across the network. As servers and clients upgrade their middleware software on independent schedules, make sure that mis-matched versions of middl eware still provide functionality. The tool probably still needs to support the specific RDBMS being connected to. Despite the advent of ODBC, getting the most out of a given database server may require not only using the RDBMS specific client API but also proprietary SQL extensions. Make sure your tool specifically supports your RDBMS as necessary. November 15, 1995 Print This Page E-mail this URL