CENTERFOLD

Still More Web Middleware (Still Less HTTP)

Will their wins be mere Pyrrhic victories, to be forgotten in a few years? Probably. In the meantime, we'll have gotten some business-saving applications out the door. No one can afford to wait too long for standards bodies to solve things. Often, corporations don't even wait for the industry to solve them; they come up with in-house solutions. These are, of course, the genesis of the next generation of products. As quickly as corporations realize that they are not alone in needing such solutions, they convince themselves to let others have their competitive-edge tools. It's a crazy d ynamic, but it's the way things work.

The Last and Longest Mile I came across yet another Web-oriented middleware product recently: Wayfarer Communications' QuickServer. QuickServer provides interesting insights into how incomplete most current Web tools and middleware are, but also falls into the same traps as others have and will.

Wayfarer (www.wayfarer.com) is jumping into the fray. Yet another new company has figured out that HTTP and the Hypertext Markup Language (HTML) aren't going to cut it for serious applications. The gamut of solutions that one cobbles together into making a half-donkeyed Internet-style application isn't worth the effort. So, Wayfarer set out to create a single system that can handle the entire thing.

QuickServer, like BEA System's Jolt, offers new middleware to handle the last (and longest and slowest) mile of desktop-to-server interaction over the Internet or on an intranet. QuickServer middleware offers asynchronous messaging beneath the covers, while transaction semantics are left to the programmer (or his/her toolkit). Asynchronous messaging is not just "nice;" it's very useful. Ever sit there while the Web page was stuck, having downloaded 20 percent at 64 Kbps? I often open two windows when I'm doing searches just so I can let one chug while I kick off another search elsewhere. As servers and networks slow functions, the user sits and waits, or hits the stop button and gives up.

With serious applications, leaving the user to sit and wait interminably is not a good idea. With the asynchronous messaging underpinning, the user can initiate interaction across the network and go on to other tasks while waiting for the answer. Given the reality of the Internet as a network, this behavior is required. In fact, the user could fire off multiple requests and let responses come back from different servers independently, rather than perform every interaction serially. Altogether, this adds up to applications that perform better over the same network.

Unlike Jolt, QuickServ er focuses on generating an application that is downloaded as a Netscape plug-in or full-scale Windows application. ActiveX will be in its future--no doubt enabling the more transparent downloading paradigm of the applet. Like Active Software's ActiveWeb, the back end interfaces with legacy systems, while the application is created using your favorite tool and/or language, including Visual Basic, Java, or C++. QuickServer is the infrastructure--the middleware--that the programmer uses.

QuickServer is available with per-user licensing for run times ($200 per user in quantity, with other OEM/VAR pricing options, plus a $995 developer kit). Unfortunately, with this pricing consumer use will not be practical. While per-seat licenses work inside the firewall on the intranet (where employees are the users), it won't work on the Internet. Without a realistic Internet option, is this the right infrastructure on which to bet?

QuickServer is also too complete--or at least too self-contained. Interfacing with any corporate directory for authentication or other user-attribute data is left to the developer. Support for the Lightweight Directory Access Protocol (LDAP) would make sense. In fact, until developers realize that one of the most important databases these products need to access in the back end is the corporate directory, the products will continue to come up short in terms of full enterprise integration and scalability. They should be clarifying how they'll move in the directory and security areas away from their first-cut proprietary solutions.

The Web Assumption: Always Online Like Jolt and ActiveWeb, QuickServer implies an online model application. There is little choice about offline enablement. Instead, a number of other vendors are focusing there.

Any e-mail client gradually will become a component holder for applets (and data) delivered by e-mail (and replication systems) rather than HTTP. After all, why should the Web browser have all the fun? We'll soon see e-mail systems adding in Java engi nes and ActiveX support. Moreover, since newer e-mail systems (Lotus Notes certainly, but others as well) offer replication of data to remote disconnected nodes, those applets can access data that is local rather than only over the network.