A DB Sit.com
The latest media craze -- exposing the seamy side of family-oriented sitcoms -- reminds me a lot of Web database programming: The public interface has little to do with what’s going on behind the scenes. Creating Web applications that expose a database is the point where Web programming and Web design diverge. Web database programming is quickly evolving, and there are tradeoffs both in using the very latest techniques as well as in using older, proven techniques. Because the backend technologies used to connect Web users with their data has little bearing on the final HTML presentation, spiffy interfaces can often hide the kludges used to manage data on the Web. What Web applications share with classic TV shows like the
Brady Bunch is that the public view is not the end of the story.
Many tools can isolate a Web developer from understanding the communication between the front-end and the database. Under the hood, there are basically three models: client-side access, server-side access, and marshaled data packages. Each technique has different prerequisites for the deployment platform, so they are not likely to be intermixed.
Client-Side Access
Client-side database access means that the client’s browser is making a direct connection to a data source across the Internet. Like Greg Brady’s rock-star persona Johnny Bravo, Microsoft’s client-side solution known as Remote Data Services (RDS) is pretty flashy. Using an ActiveX component on the client machine, RDS allows a database connection that is reminiscent of the client-server database applications that were popular before the emergence of the Web. Using DHTML, the results of an RDS query can be bound to an HTML table, which can be updated dynamically as the results from the query arrive. The results of searches done using RDS will be kept in a client-side cache, and can be sorted without an additional roundtrip to the server.
The skeleton in the closet of RDS is that it is Microsoft specific. Only Windows users have access to the RDS component, and that component has to be downloaded to the client machine at some point. With the recent hubbub about the ILOVEYOU virus, the size of the population willing to download an unfamiliar ActiveX control will shrink even further. Additionally, RDS must publicly expose some information about the database connection in the HTML source code, which could expose your server to attacks. With the increasing popularity of non-Windows platforms like Palm, few vendors will want to tie themselves to Microsoft-only clients, leaving RDS in the same place as Greg Brady’s singing career.
Server-Side Access
At the Brady household, if you wanted mature advice, you talked to Alice the housekeeper. In Web-database integration, server-side access is the mature solution. In the server-side database world, all database access is performed on the server, while the resulting data is typically shuttled back and forth with the client using visible and hidden HTML form controls. Like many of the solutions offered by the Brady’s housekeeper, server-access is simple. It has been successfully implemented using dozens of host languages, including Perl, C++, Java, JavaScript, Visual Basic, Pascal, and COBOL. Server-side solutions are great at keeping the source code for your solution hidden from the client.
HTML form controls are not natively type-safe or validated. Server-access products often offer client-side JavaScript extensions to add data validation, type checking, and some limited dynamic behavior to the otherwise static HTML forms. Because client-side validation can’t be complete in a server-access solution, data is often validated a second time on the server. The best server-access tools allow a single definition of business rules that are used both on client -- as much as possible -- and server.
Marshal, Marshal, Marshal
Jan Brady was obsessed with her elder sister Marcia, but if Jan were a programmer, she’d be better off obsessing about marshalling: packing and unpacking data to ship it across the Internet. XML can now handle row-set marshalling for us. By storing XML data islands inside HTML, we can pass hierarchical sets of information between client and server on the Web without having to rely on simple HTML forms. The XML parser in the browser can automatically provide validation according to the document descriptor, so it’s much easier to maintain thorough client-side validation. Hence a marshaled data package solution is a server-side solution that offloads as much work as possible to an intelligent parser on the client.
The downside of the XML approach today is that browsers are only beginning to achieve decent XML capabilities. With the release of Netscape 6.0, however, both major browsers will have an XML-aware offering. Even better, the Gecko technologies used by Netscape are supposed to scale down to PalmPilot size.
Database applications happened on to the Web out of necessity, not out of elegance or beauty. While Web database development may not be as bizarre as the rumored romantic liaisons between members of America’s cleanest-cut family, it sure isn’t pretty. The XML future of Web database programming, however, should keep the seamy Web code of the twentieth century from becoming a story in any tabloid, other than this one. --Eric Binary Anderson has led projects at a number if enterprise software companies and is currently the senior architect at IBT Financial, an Internet-based training company in Bend, Ore. Contact him at ebinary@columnist.com.