IN THE MIDDLE Continued

When the demo applet ran, it could see the data in the Informix database when it changed--the subscribe part. In fact, changes by other users were pushed out automatically to the client and highlighted differentially to show relative age. The Web becomes event enabled; there's no polling. Servers can talk to clients.

You don't have to replace existing applications (or front end s), such as the SAP R/3 client, for example. Instead, ActiveWeb gives another window into that data for different users--users to whom you couldn't or wouldn't distribute the whole SAP client. Besides, many users couldn't use something that complex and full featured anyway.

And the Winner Is... There is only one assured winner: users and developers who now have more options for realistic (scalable, secure, functional) Internet-enabled applications. Forsaking standards for function can be a good thing.

Unfortunately, my crystal ball is cloudy on the technology side. Which product will win or which appro ach will get sanctioned by the Internet Engineering Task Force (IETF) or the World Wide Web Consortium (W3C) is unknown.

Given its Internet weight, Netscape has the best shot at getting developers to utilize its Web middleware approach, but Netscape won't win all of its chosen battles. The big win would come if just a few approaches would gain major market share (as IBM MQ Series has insid e the firewall), so that developers wouldn't need to spend so much time evaluating, what are now, just too many options.

Every traditional middleware vendor must react with a Web option, either punting on the desktop to Web server part (and bridging the gap with marketing) or stepping back into the pocket and delivering complete products. Otherwise, new middleware vendors--including BEA Systems and Active Software--will gain mind-share, and muscle from the Web into corporate implementations.

Is HTTP Dead? More interesting is the effect all this activity will have on our thinking about the Web as an all-purpose application platform. With Java applets and nonstandard middleware, we've left behind the feature-thin but completely standards-based Web as we once knew it.

HTTP was a serious inhibitor to realistic Web applications. Now, however, HTML and HTTP together is only the menu system with Java (and ActiveX) programs handling the real work. Similarly, Web servers are less content loca tions than just file servers with better signposts (HTML documents) pointing to where applications (and middleware) can be downloaded.

Look to do serious work with Java development tools, particularly tools that can generate either Java, ActiveX and/or traditional Windows applications to allow the most flexibility. Once the application and middleware are downloaded, the Web server is out of the loop; desktops will communicate directly with appropriate services, be they on a Web server or some other box.

For thin, or at least thin enough, client applications, the Web HTTP/ HTML approach may still be a functional model. For larger applications--those you don't want to download across most networks every time they are invoked--even the menu system becomes useless. Is the Web only a fad--just a simple publishing architecture? Will the future be filled with applications talking to servers with little or no Web technology? Only time will tell. My guess: It won't be a Web-only world out there for long. Get ready.

Bruce Robertson is a program director with the META Group's Global Networking Strategies service. He can be reached at BruceR@metagroup.com.