Tools to meld the Web & relational databases, Part II
Web-aware database development tools promise
to make client/server app deployment easier
February 1996
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Tools to meld the Web & relational databases, Part II
Web-aware database development tools promise
|
February 1996
|
The shareware programs Web/Genera and Oraywww are powerful middleware between Web servers and relational databases. The author explores why no vendors (yet) sell similar software, and what this may mean for the future of client/server software. (2,200 words)
 Mail this article to a friend |
I ended last month's look at relational database development tools for the World Wide Web by suggesting that who is not developing these tools is at least as important as who is. This month, we'll examine this little conundrum as it relates to a larger matter: the Web. Among its zillion other revolutionary aspects lies the potential to change the nature of the client-server software development tool business. How? Let's explore.
Last month, we covered the importance of interfacing Web clients with relational database servers. We listed some of the requirements for tools that facilitate this integration, and examined some of the more basic tools that begin to meet those requirements. These ranged from low-level routine libraries, such as sybperl and oraperl, to more sophisticated query result formatters such as the Decoux gateway.
Notice that none of these come from traditional tool vendors, or even from database makers. Most tools are listed on Web sites of Sybase and Oracle as unsupported third-party software. All are all freeware or public-domain software. Why don't the commercial tool vendors sell these products? Where, for example, is "PowerWeb" from Sybase/ Powersoft or "DelphiWeb" from Borland?
They don't exist yet for a variety of reasons. First, the technology is still new, and even savvy development organizations like Borland and Powersoft need to grow expertise. Second, these companies would naturally want to integrate new Web-oriented offerings with their existing tools, and such integration is not easy. These vendors, and others like them, are indeed working feverishly on Web-oriented tools and in some cases have even made preliminary product announcements (as we saw in last month's news story "4GL's becoming Web savvy").
A third and more important reason has to do with the nature of the Web itself and how it meshes with the traditional revenue model for client-server tools. Typically, vendors make money by selling developer seats and charging runtime fees. Developer seats, or copies of the development tool itself, sell for a few thousand dollars each. In most cases this is chicken feed compared to runtimes, the fees you pay for distributing applications created with the tool. If you want to distribute an application to a thousand users, and the runtime fees are $100 per user, then you should understand very quickly how tool vendors make their real money. Of course there are other sources of revenue, too, such as maintenance fees, training, and consulting.
The problem is that it's difficult to charge runtimes for tools that act as "middleware" between relational databases and HTML. We looked at a couple of the simpler tools of this type last month. One of the more advanced tools is Web/Genera, developed by Stanley Letovsky of the Human Genome Data Base project at Johns Hopkins University in Baltimore.
|
|
|
|
|
Web/Genera
Web/Genera works with Sybase databases. It has two main components:
sybfmt and sch2sql. Assuming you already have
a database to work with, you start by creating a template file that
describes how you want your data to appear in HTML format. The
sch2sql program, given your template file as input, produces
SQL code that queries the database and extracts the data you want to
display. Sybfmt also takes a template file as input; it's a
gateway that runs SQL code according to a query passed to it through a
CGI interface, formats the result in HTML according to the template,
and passes the resulting page back to the user. Web/Genera also
includes a program called sch2db, which takes a template file
and constructs table definitions for a database, if you don't have one
already.
The design of the Web/Genera scheme is based on a particular set of assumptions about your data and how you want it displayed. It assumes your queries will produce results that are best displayed as "objects" rather than as tables. Put another way, it assumes that your results will be complex enough so that each row will contain enough data to merit an entire HTML page of display -- i.e., a single URL for each row. This is an appropriate model for the highly complex genetics data in the Genome Data Base, but it may be awkward for simpler databases.
Web/Genera also includes many features for linking query results with other data through hyperlinks. As with the UMass Information Navigator, discussed in this column last month, you can use Web/Genera to create hyperlinks that follow "joins" between the data displayed on a given HTML page to other data. But while the UMass Information Navigator automatically figures out what hyperlinks to create by examining database table definitions, with Web/Genera you must specify manually the links you want in your template file. On the other hand, Web/Genera gives you more control over formatting of the data display -- even allowing you to insert hyperlinks to other URLs, not just to joined relational data.
Oraywww
Another interesting tool that provides advanced HTML formatting
capability is
Oraywww,
developed by Arthur Yasinski while working at the Canadian Forest
Service. Oraywww, as its name implies, works with Oracle -- where,
incidentally, Yasinski is now employed. The tool reads your database
schema and uses it to help you create a QBE-style form in HTML, very
much like a simplified version of GUI relational database query tools
such as
Gupta's
Quest.
As the example on the Oraywww Web page shows, Oraywww creates
a form that allows you a few combinations of Boolean field
values, both within fields (e.g., First Name = Bill OR Hal) and
between fields (e.g., First Name = Hal AND Last Name =
Stern).
After you create a form with Oraywww, it produces code in Perl for the CGI program that implements the Oracle gateway in the usual manner: by reading the field values passed from the HTML form, passing query parameters to the database, retrieving the results, formatting them into HTML, and sending the HTML page back to the user. The Perl code that Oraywww generates requires oraperl, a freeware package developed by Kevin Stock in the UK that makes Oracle's C runtime library available as Perl routines. Oraperl is widely available; follow the link above and arrive at one of its many sources.
Clearly, Oraywww and Web/Genera differ in a couple significant ways. Oraywww facilitates building the end-user's query interface, yet does not give you many options for formatting the query output. Web/Genera, on the other hand, does not offer much help with the query interface, but sports robust output formatting capabilities. (In fact, Oraywww gives you only two output formatting options: list and table.) Oraywww also seems to be designed for simpler databases than those for which Web/Genera is appropriate; online Oraywww examples like employee contact information and oil-well database bear this point out.
The end of runtime charges?
However, Oraywww and Web/Genera have one important thing in common: they
both produce code that generates HTML. This is a very important
point that leads to a number of interesting difficulties for commercial
tool vendors. On the one hand, these tools produce client-server
database applications. On the other, what they produce isn't
much different, when you think about it, from Microsoft
Word or WordPerfect documents. This relates to the increasingly
blurry line between applications and documents that I
covered in the column
"The disappearing line" (SunWorld Online, December, 1995).
There are two problems with the business model for tools like Web/Genera and Oraywww. First, there is very little precedent for charging "runtimes" for HTML documents, just as no one charges for Word or WordPerfect documents. Second, and more fundamentally, the nature of the Web renders impossible the whole idea of charging for software by number of users. Unlike typical client software that operates over a LAN, Web users do not have HTML pages installed on their machines -- they simply load them temporarily into their machines' RAM and use them. You could save an HTML page to your hard drive, but there is usually no reason to do so.
Instead, it would be more appropriate to adopt the electronic commerce model and charge by transaction -- in this case, by database query. This makes sense with a tool like Oraywww. It's based on a simple model -- user fills out a form, user gets back a page of information -- that implies a clear-cut value per transaction. For example, assume your Web site has a database querying form that you built with Oraywww. Your Web site is about as popular as SunWorld Online: roughly 2,000 people per day hit it and execute a query. If the maker of Oraywww were to collect a penny for each transaction, that's $20 per day, $7,300 per year, and maybe $20,000 for the life of the application (assuming a perhaps too-generous three-year life span). That's equivalent to the amount of revenue that a client-server tool maker would make on runtime licenses for 200 users at $100 each: not exactly a windfall, but in the ballpark for the tool vendor.
Two issues arise from this example. First, are you willing to pay a penny per query? You might if your application produces direct revenue per query (e.g., if you run a database of historical stock price information). Otherwise, this is not what one would expect on the Web where "Information wants to be free." Second, if your application is more complex, then the value-per-transaction equation may no longer hold. Some queries may be trivial or may be for behind-the-scenes bookkeeping purposes, while others may produce information of more value to the user or to you.
In Regard to the first of these issues, developers will undoubtedly be willing to pay runtimes for commercial Web application development tools if the tools are good enough. Tools like Oraywww and Web/Genera are important innovations, but clearly there's a lot of room for the Powersofts and Borlands of the world to provide more features, robustness, support, and training. Since such tools will presumably let you produce arbitrarily complex applications the second of the above issues becomes relevant. Tool vendors should be compensated for giving their customers the ability to build powerful, popular applications -- but what pricing model makes sense in the world of the Web? How, in general, can you gauge the value of a transaction? The answer's not obvious.
The complexity of Web applications that you can build can be even greater if we look beyond HTML. As we discussed last month, the HTML/CGI paradigm has some fairly severe limitations on how it can be used to support client-server database applications. Tools that produce Java code, analogous to the many tools that produce C++ code, will soon appear, as will robust Java code libraries for querying relational databases -- analogous to Rogue Wave's DBtools.h++.
For our purposes here, the key difference between Java-producing tools and HTML-producing tools is not that the former are more complex or do more work. It's that Java applets are more like traditional client applications because they reside on users' machines. We may be wandering off into arcane philosophical territory here, but it seems there should be a difference in developer runtime fees based on whether the runtime object is a permanent piece of code installed on users' computers or an ephemeral HTML page.
Tools for developing client-server HTML applications or Java applets, the final ingredient to throw into this stew, may become just as useful for in-house applications that run on LANs as they are for the World Wide Web. When that happens the tool vendors will come up directly against their traditional per-user runtime pricing model. Now what do you do about runtime pricing? How will tool vendors make money in this increasingly interconnected world? This is one of the more fascinating questions in the client-server software development field today.
P.S. For those of you who read the
October 1995 Client/Server column on the Open Document Management
API (ODMA) standard and wondered where you can find the standard
online, thanks for your patience -- it has been rewarded. The
Association for Information and Image Management (AIIM) is the
custodian of the ODMA standard. It has made the standard document and
other relevant information, including the API itself, available through
anonymous FTP at
ftp.capcon.net/pub/aiim/services/api.
|
|
Resources
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright96.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-02-1996/swol-02-cs.html
Last modified: