Commercial Web tools: the stampede begins
Bluestone and Spider Technologies create commercial client/server tools for the Web
Another leg in the race to stake claims in the goldfields of World Wide Web application development tools. We've heard from the public domain and some of the major established vendors; now it's time for small start-ups to have their say. We examine tool entries from Spider Technologies and Bluestone. (1,900 words)
In previous months, we have been taking a look at some of the original client/server Web tools. First we saw what was available in the public domain, and then, last month, we saw Sybase/Powersoft's web.works announcement, which staked out territory in the Web tools area for that major database vendor and its market-leading tool subsidiary. Now, third-party vendors are beginning to step in. This month, we will look at new products from two of them: Spider from Spider Technologies (Palo Alto, CA) and Sapphire/Web from Bluestone, Inc. (Mt. Laurel, NJ). These and other vendors are creating tools that ease data-intensive client/server development by abstracting away the details of the Web/database interface, thus eliminating CGI programming and providing graphical tools for building front-ends and data interfaces. In other words, they are jockeying for positions as the potential Powersofts of the Web world.
Spider Technologies's Spider 1.5 is the most straightforward Web/database development tool available so far. The tool has two principal features of interest. First, its user interface consists of an HTML viewer and a database viewer. This is the analog of visual query builders in tools like Powerbuilder and Gupta's SQLWindows. Spider lets you define actions on your database, including the ability to run stored procedures whose parameters are set by input fields in an HTML form. Then you can create an HTML template for the query's results by dragging and dropping database columns to the HTML page. Spider automatically generates the SQL for the query and implements the Web/database gateway that makes the application complete.
Spider's second component of interest provides a way to overcome one of the most pernicious limitations of nontrivial Web-based client/server applications: the inefficiency of CGI. A CGI interface to a relational database can create major amounts of overhead in two ways: the Web server must fork a new process every time a CGI program is run and the CGI program itself must open and close a connection to the database for every query it runs.
Spider offers a solution to these inefficiencies similar to the one available in Sybase's web.sql, which we saw last month: it bypasses the entire CGI mechanism. Instead, Spider has a routine library that is designed to run with Netscape's Web server. It interfaces to the server through the Netscape Server API (NSAPI), eliminating the need to create a new process for every query from the user. Spider also solves the problem of continually opening and closing database connections by maintaining a pool of open connections and allocating them to incoming queries as needed. Spider claims a 10 times performance improvement over straight CGI with this scheme. (I should mention that Spider announced this innovation one month before Sybase announced its similar feature. Draw your own conclusions.)
Spider 1.5 is available for Sun, HP, and SGI versions of Unix and Sybase, Oracle, and Informix databases. It will undoubtedly prove to be a useful tool -- one that reduces development time and errors for an important class of Web-based client/server applications.
Bluestone's Sapphire/Web is a more ambitious tool whose potential has not yet been reached. Bluestone, a tool vendor for several years, built its reputation in the area of advanced user interface development tools for X Windows. Sapphire/Web, however, is not really a user interface development tool. Instead, it's a tool for constructing middleware that automates communication between forms on HTML pages and code objects on your server(s). As an important special case, Sapphire/Web facilitates data queries from HTML pages to relational database servers, as well as the display of query results back to the user in HTML. But that's only part of what Sapphire/Web can do.
Sapphire/Web's central component is called the Object Bind Editor (OBE). The OBE is a simple yet extremely powerful idea: It abstracts away the details of CGI for building interfaces between elements on HTML pages and various types of applications, objects, and data. The interesting wrinkle is that its mechanism for building these interfaces is not only easy to use, but also designed to be independent of the type of data source. In other words, it's not limited to relational data.
Let's review how CGI/database gateways work so that we can understand the value of the OBE. When you click on a "submit" button in a form on an HTML page, you are collecting all of the fields (variables) defined in the form and sending them, in a standard form, to a CGI program on the Web server. The CGI program uses these values as input to some processing that results in some standard output, which the server returns to the user as another HTML page. The only really interesting part about this transaction is the "some processing" part: This could be done by any sort of server program, as long as it's callable from (or part of) the CGI program. The gateways we've seen so far implement the "some processing" by formatting a SQL query and passing it to the database. That is, they have special knowledge about building SQL statements and connecting to relational databases.
But why not extend that "special knowledge" so that it includes connectivity to other types of data and programs on your server, and similarly abstracts away the details of that connectivity? That's exactly what OBE is set up to do. First of all, it knows how to handle relational database elements like tables, columns, and stored procedures. A visual front-end lets you create links from fields on an HTML form to any of these database elements. The kinds of links you can set up depend on the type of database element. For example, you might choose to have the value of a drop-down-box field determine which stored procedure to run on the database. Or, you could use the value of a text field to fill in the blank in an SQL query to the database. Another Sapphire tool called the Network Object Browser helps you find the database objects on your network and connect to them. Once you create the links, Sapphire/Web implements them by creating code for a CGI program, in your choice of C or C++, that calls the relevant database program with the appropriate arguments and retrieves the results. It puts the results into an HTML template that you designate -- either a predefined one or one of your own design. These templates are not unlike the HTS (HyperText Sybase) files that Sybase's web.sql gateway defines, as we saw in last month's column.
So far, this isn't too different from many of the other Web/database gateway products we've seen. But the real advantage of the OBE is in its ability to link to objects other than relational database elements. In the current initial production release of Sapphire/Web, the OBE can link to ASCII flat files and any server executable. The latter is a potentially handy mechanism for creating Web versions of Unix utilities like ls, finger, who, etc., or your own shell scripts.
Objectifying the Web
These features can save programming time and reduce errors, but they're not exactly rocket science. They are, however, but a prelude to something more interesting. The next release of Sapphire/Web will expand the OBE's capabilities with a piece called Object Bridge, which will allow the OBE to interface to distributed objects that conform to standards like the Object Management Group's CORBA. This worthy goal, ambitious as it is, will undoubtedly take a while to become reality. Adding support for distributed objects transports Sapphire/Web to a level at which it becomes object-oriented middleware for the enterprise.
I have said in various past columns that distributed object technology is the best way to achieve interoperability among heterogeneous types of information throughout an organization. Standards like CORBA offer the only reasonable ways to achieve this. If Web technology is really going to become the basis for "intranet" application development, then it needs to tie in with these distributed object standards. Nowadays, a crucial criterion for making the Web's HTML/CGI architecture a desirable platform for building nontrivial applications is the ability to access data -- and in today's environment, that largely means relational data. But the Web will eventually need to access data types ranging from legacy data on mainframes to spreadsheets on PCs.
When implemented, Bluestone's Object Bridge will make Sapphire/Web a viable solution for objectifying internal and external Webs with the exception of one thing, HTML. This brings us back to the original point of this month's column: The tools are coming, but they are running up against serious bottlenecks in Web technology relative to our expectations for their ability to build full-featured applications. HTML, to begin with, is not a wonderful user interface implementation language. It's not too bad for displaying relational query results, especially if you take advantage of the table features in Netscape's HTML. For object data, however, it's horrible -- and therefore it's clearly the weakest link in Sapphire/Web's (and other tools') ability to help objectify the Web. We'll see other attempts at making the Web more object-oriented in future columns. But in the meantime, HTML is certainly not going away; therefore, it's appropriate that tool vendors like Bluestone make the most of it as the rush to build client/server applications based on Web technology intensifies.
At present, Sapphire/Web is available for Sun, SGI, HP, IBM, and DEC Alpha versions of Unix, and Sybase, Oracle, and Informix databases. They expect to add support for Windows NT, Windows 95, and Microsoft SQL Server shortly. Bluestone's years of experience with object-oriented tools should make Sapphire/Web a good one to watch as its functionality grows.
If you have technical problems with this magazine, contact firstname.lastname@example.org