Click on our Sponsors to help Support SunWorld

Sybase's Web tools strategy

web.works architecture includes innovations from Sybase and Powersoft

By Bill Rosenblatt
SunWorld
March  1996
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
The scramble to offer tools for integration of Web applications with relational databases has only just begun. With its new web.works Internet Architecture, Sybase is pushing its web.sql Web-database gateway and Powersoft's DataWindow technology. (1,800 words)


Mail this
article to
a friend

Last month, I noted that the major client/server tool vendors -- the Borlands and Powersofts of the world -- had been unable, so far, to offer tools for integrating World Wide Web applications with relational databases. Consequently, the first claim-stakers in the Web tools field have been public-domain entities and startups. Indeed, the number of Web tool startups seems to grow on a weekly basis, and we'll examine some exciting products from these new vendors in future columns. Not surprisingly, however, the big tool vendors are rapidly joining the fray, and this month we look at one of their offerings. Sybase recently announced the web.works Internet Architecture, a broad-brush initiative that, along with the level of vaporware customary in such statements, covers two components of note: Powersoft's leveraging of its DataWindow technology as a Web plug-in and Sybase's web.sql Web-database gateway.

If you're Powersoft (a subsidiary of Sybase), and you've invested hundreds of staff-years developing highly complex tool technology, would you really squander all that on an application architecture as skimpy as the Web in its current state -- HTML pages and CGI scripts? Powersoft has answered this question with a resounding "No." Its near-term future with the Web is based on plug-in technology from Netscape that allows different types of applications to coexist with HTML pages. Netscape has already introduced plug-in technology covering Java applets, Adobe Acrobat page images, VRML, and other formats as part of its Navigator 2.0 release.

Advertisements

Powersoft's DataWindows to the Web
Powersoft's plans for Web integration center on the best-known aspect of its PowerBuilder tool, DataWindow. DataWindow is an application object class that encapsulates relational data query and display functionality. It looks and acts like a highly customizable spreadsheet, but it also includes a lot of behind-the-scenes intelligence about database access and network connectivity. Powersoft has recognized that DataWindow, improved over the course of four major releases, is a valuable software asset it can leverage onto multiple platforms. PowerBuilder started on Windows and migrated to Windows NT, Unix (Motif), and the Macintosh. Now Powersoft is migrating DataWindow to the Web.

Clearly, Powersoft's DataWindow would be very attractive as part of a data-intensive Web application. But how can it be integrated? There are essentially three options:

  1. Create an HTML version of DataWindow.
  2. Create a Java version.
  3. Integrate platform-specific versions of DataWindow with existing Web technology.

The first option would follow the same path as tools we've been looking at over the past couple of months. We have found that the Web's HTML/CGI technology makes it relatively easy to get query parameters from the user, create SQL code from the queries and pass it to the database server, get results back, format the results into HTML, and display the HTML as a separate page. HTML/CGI's serious drawback is not allowing query results to be displayed on the same HTML page as the query itself, severely hampering the interactivity that Powersoft's DataWindow makes possible. So the HTML option seems like it would require too much "brain damaging" of DataWindow's features.

The Java option is more attractive because DataWindow is an excellent tool for producing Java applets. In fact, as the Java applet market develops, there will be a clear need for an easy, dependable way of producing database querying applets -- and a major opportunity for the vendor who gets in early with a good tool. Powersoft is in perfect position to capitalize on this opportunity, except for two factors. First, it would have to reimplement DataWindow so that it uses system services from the Java Virtual Machine rather than from Windows, NT, MacOS, or Unix/X Windows. Right now, even though PowerBuilder applications are largely portable between platforms, Powersoft maintains separate versions of PowerBuilder for each platform. Retooling for Java sounds like a lot of work.

Powersoft's second obstacle with Java is code size. The company has received much criticism for the multi-megabyte size of executables that PowerBuilder produces. Code size is much more of a limiting factor in the world of Java applets, which must be sent over the Internet to the user before they can run. The 28.8 kbps world is not yet ready for megabyte-size applets. At the same time, there's no big hurry -- let's not forget that Java doesn't run on Windows 3.1 or the Mac, and much of the Windows world hasn't migrated to Windows 95 or Windows NT.

Plugging in
That leaves the third option, integrating DataWindow with the Web -- Netscape's plug-in technology makes it possible. The plug-in scheme allows different formats to be seamlessly integrated into HTML pages, so that a page with plug-ins looks like one continuous page instead of one with clickable MIME attachments. Unlike Java applets, programs that run plug-ins can be existing applications that run on single platforms. The Adobe Acrobat Reader, for example, exists for Windows, Mac, Unix, and other platforms, but the executable files are different for each. This means it's necessary for users to have the version of the plug-in program that works with their specific operating system version. In Powersoft terms, this means users would have to obtain the correct DataWindow plug-in -- an annoying but not insurmountable software distribution obstacle.

The plug-in option requires the least amount of development work, so it's the easiest for Powersoft to pursue quickly. Accordingly, Powersoft said it will create a plug-in version of DataWindow for Netscape HTML, which will be available for free from Powersoft's Web site. It's probable that, like most other plug-ins, the initial version will run on Windows 95 and NT only.

The platform specificity and large code size imply that the DataWindow plug-in will be more appropriate for "intranet" LAN applications than those outside the firewall. But Powersoft is pursuing a parallel course that is even better suited to this type of internal application: It is also packaging DataWindow as an OLE Control, or OCX. An OCX is a type of reusable object that can be used within Windows 95 and NT applications -- sort of a Java applet for 32-bit Windows.

(Microsoft initially positioned OCXs as competition to Java, but was swamped by Java's cross-platform tidal wave. There are many problems with OCXs as Internet applets -- security is one of them. Yet, paradoxically, it's also possible to use OCXs as Web plug-ins -- as long as the user's client is Windows 95. The technology that enables this is NCompass from the ExCITE Centre at Simon Fraser University (Burnaby, BC, Canada).)

Powersoft has elected to become a core technology provider to the Web rather than rely on existing framework. It is sidestepping HTML and putting true platform independence (through Java) into the future. This is a bold strategy predicated -- appropriately -- on Powersoft's recognition that DataWindow is the market leader. However, nothing lasts forever, and DataWindow's sway may fade rapidly as the Internet and the Intranet blur.

Sybase's web.sql
Contrast this approach with that of Sybase's web.sql -- the other interesting part of the web.works architecture announcement. It works mostly within the existing confines of HTML and CGI. Web.sql is an HTML-Sybase gateway that works very much like a combination of the Decoux gateway for Oracle and the sybperl exposure of Sybase's Open Client API, both of which we discussed in January's column.

Web.sql uses template files for formatting the results of queries into HTML pages before they are sent back over the network to the user. The template files are in a format called HTS (for HyperText Sybase). HTS is a proper superset of HTML that contains exactly one new tag: <SYB> and its matching closer </SYB>. The <SYB> tag takes a TYPE= argument, which (currently) can take one of two values: SQL and PERL. Anything inside a <SYB TYPE=SQL> tag is interpreted as a SQL query to the database. Web.sql submits the query and substitutes the query's results for everything within the <SYB> and </SYB> tags.

Similarly, code inside a <SYB TYPE=PERL> tag is interpreted as perl code, the standard output of which is substituted back into the HTS file. After all of the <SYB> tags are processed in this way, the resulting HTML page is sent back to the user. You can define perl global variables inside a <SYB TYPE=PERL> tag; these are available not only within subsequent <SYB> tags but also throughout the rest of the HTS file. This scheme lets you easily substitute values for HTML form fields, today's date, or whatever you like. Web.sql also provides Sybase Open Client calls as perl functions in the manner of the freeware sybperl program.

The glue that hooks this scheme to the standard Web server architecture takes two forms. One is quite simple: You store each HTS page in a directory as if it were a CGI script, and you treat it as a normal URL. But when the user visits that URL, your Web server runs a web.sql CGI script that uses your HTS file as input. It's as if web.sql were a command interpreter, just like perl or any Unix shell.

A second version of the web.sql processor provides a more efficient way of integrating web.sql with your Web server. The first version runs as a CGI program, meaning it creates a new server process -- and possibly several new database connections -- every time a user hits a URL corresponding to an HTS file. That's a lot of process creation that can generate a lot of needless overhead on the server. The second version, in contrast, does not run as a CGI script. Instead, its code is linked directly into the HTTP server process, so that it's continuously running. It also maintains open database connections by caching them. The result is much less process creation and therefore more efficiency.

At this writing, web.sql is in beta and available for free download. It runs with Sybase System 10 or 11 on Sun Solaris 2.4, with ports to other Unix versions (SGI, IBM, and HP) and Windows NT available in the next few months.

Although web.sql is not much different from Web/database gateways that have existed for a few years, it is the first such product that is (or will be) supported by a major vendor. With web.sql, Sybase has done for this type of tool what Powersoft hopes to do for the DataWindow plug-in: establish a line in the sand in the market. Web.sql covers all the basics of Web/RDBMS integration in a simple, elegant way, provides added flexibility through perl programming, and overcomes the efficiency bottleneck that results from starting a new process whenever a CGI script is invoked. In other words, its functionality is good enough and it's supported by a major player. Startup tool vendors will have to demonstrate truly significant, added functionality if they are going to compete.


Click on our Sponsors to help Support SunWorld

Resources

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-03-1996/swol-03-cs.html
Last modified: