Client-server computing is the answer to a data processing manager’s prayer, right – you just plug a few Windows machines together, stick Sybase on a Unix server, maybe bung in a gateway to talk to the IMS database on the mainframe, and Bob’s your uncle, right? (And client-server means the same as Unix and downsizing, of course.) What could be simpler – they’re all standard pieces by now. And hey presto, you save millions of pounds, automatically, overnight, guaranteed. Because client-server is cheaper, right? Old computer solutions are evil and were concocted by people who fought in World War II, and we know better, correct? And open systems means the best deal for the customer because choice guarantees quality and honesty? Richard Finkelstein, president of Chicago-based Performance Computing Inc begs to differ. At DB/Expo San Francisco last month, explained why. You see, he wants to go home at a normal time occasionally.
Odd weekend free
He’d like to have the odd weekend free, and take his children to the zoo. What’s his problem? I’m tired of the 5pm-to-midnight shift and I’m tired of working every weekend. I spent a whole weekend once on a client-server bug that turned out to be a Goddam printer cable problem! I think it’s a good thing Bill Gates is getting married, because then he may find out there’s more to life than working on computers, thundered Finkelstein at the start of his Evaluating and Using SQL Client-Server Software seminar. He is a dedicated software professional, who believes in what he does. So when these client-server bolt-together systems you believe are so easy to build don’t work, which is nearly all the time, he feels he has to try and fix them. He says he feels he’s had a good day when the things print – just that, and he feels relieved and that he’s accomplished something. And he’s not going to take it any more, quite frankly. What is client-server? The simplest scenario involves, among other complexities, a set of function calls, or application programming interfaces, used by a software application to request information from a database, usually over a network. The interface sends requests or statements in SQL into the network library to talk to the right fragment of TCP/IP or named pipes or NetWare or whatever to get the data back. Every vendor provides different, specific bits, which you have to install. It’s supposed to be like using the phone. It’s not. In reality, nothing is transparent to the network, where for instance, what memory chip you use can have a big impact, says Finkelstein. Nothing is easy in this world – especially client-server. If vendors tell you it is, they’re either naive or don’t know what they’re talking about. Take standards. Take ’em and throw them away. We can evolve a Standard Rule right here: By choosing a standards-based way of doing things in the client-server world, I am happy to sacrifice performance and features in favour of portability and conformance. Get real this is the world of computer vendors like IBM Corp and Oracle Corp, remember. Take middleware. It’s very important in building client-server systems. One of the basic components is the application programming interface level. At the top level sits the application – if you’ve lost track of why this is important in all this chaos, that’s what we’re supposed to be doing all this for – which may speak to Excel, or Focus, or PowerBuilder or whatever. Underneath may be a whole layer: Excel using Microsoft Corp DLL calls, the PowerBuilder application speaking to a relational database API like Sybase, a standard API like Open Data Base Connectivity, or Focus speaking to a gateway API like EDA/SQL. (All of these may be intercommunicating with each other at this level). Then this layer will be speaking to specific database drivers, which will speak to local network drivers or to a wide area gateway. Now in the bad old days, goes the argument, you had to use the API that came with Oracle or Informix or whatever relational database, so you had to stick with that one. So what users really wanted
, or were told they wanted, was an open interface so they could have one for all uses, have portable applications, not be dependent on one relational database vendor and so forth. This is what things like SQL Access Group and such are all about.
By Gary Flood
The promise is that we’ll end up with one interface that works with all database servers. But! Following the practicality line, think about it: using the native relational database API maximises performance and functionality (remember, the Standard Rule), and means it’s not dependent on any other vendors, meaning release synchronisation is much easier. This point is incredibly important to understand. Consider a consortium like the SQL Access Group. It’s made up of 44 vendors. Have you ever seen anything useful come out of a body with that many (often viciously competing) players? The Group has tried, nobly, to wrestle with some difficult issues, sure – SQL syntax and semantics differences, codification of data types, error handling and reporting, catalogue table issues and do forth. But as Finkelstein says, It’s not completed, IBM does not participate, and no-one has implemented it and no-one will. Why? Because there are already too many standard APIs, and they’re not provided by neutral bodies – most are either for or against Microsoft or IBM. Instead of proprietary APIs we have standard proprietary APIs! This covers ODBC, IDAPI, Oracle Glue (or as Finkelstein jokes, Glue users to Oracle – this appears to be another marketing announcement with no engineering) and so on. Microsoft’s Access does not support the latest ODBC. So the vendor can’t even support its own standard! Consider ODBC. It’s based on the SQL Access Group call level interface – with extensions. It’s still evolving. It’s still got big performance and memory overhead problems. There are few drivers built, and it’s hard to build one. There are many sorts of conformance levels, core, level 1 and level 2. It’s also owned by Microsoft. That means to build drivers, (a) you have to depend on Microsoft to keep synchronised with all the other vendors’ new relational database APIs – and standards are always behind the latest release – and (b) as a vendor you have to go to Microsoft and tell it what you’re going to be doing with your database so it can build the drivers! Follow it through. The application talks to the IDAPI API which talks to the IDAPI driver which talks to the ODBC API which talks to the ODBC driver… what if they don’t translate properly? What if they’re unable to translate? What if they translate but it takes so much steam out of the system the users throw their mice at the screen in disgust? What if vendor A’s release is one release behind the ODBC spec vendor B is following? What if Microsoft decides it wants to favour vendor P’s implementation of row level locking over vendor Q’s? What are you going to do – cry? You may want to open the window in shock at this point. It’s a cliched image, but this really is the Emperor’s new clothes time. We’re all for standards in some way – it should be the genuine route for user independence.
Kids to the zoo
But in the real world, the world where you want to be able to have time to take your kids to the zoo, the free market has given us just a mess (Finkelstein’s phrase). Things like ODBC are not useful to you, or likely to be before the next Ice Age. Do not bother reading about them. Do not listen to a vendor telling you about them. Do not buy a product because it says it conforms to open standard X. Do not expend effort tracking which vendors say they adhere to any of them. Build simple, useful computer systems, systems that work, that won’t drive you into the ground building, and that won’t take three times as much maintaining as the old dumb terminal version. If that means buying everything from one vendor – do it! As Finkelstein says, Homogeneity means more time spent on application development and less time spent on interconnection and other networking issues. It also means more time with the family – and having a life. Just write
to the native API already! Write an application for one database server – if you can do that you’ll still be ahead of the game. But in fact what you should do is hint to your rivals that you’re not, so you’ll have a dozen applications in the field while they’re still layering IDAPI on ODBC APIs… is Finkelstein’s sly advice. We’ve picked on one tiny part of the client-server world to illustrate a point: these systems are not as easy to build or maintain as you’re told. Instant panaceas like open proprietary standards are a nice example, because they show that when it comes to building useful, real world applications, they’re not much use.
