IN THE MIDDLE

Web Middleware Tolls The Death Knell Of HTTP

by Bruce Robertson

Is the Hypertext Transport Protocol (HTTP) getting old?Lately there have been many announcements regarding Web-enabling some existing applications. Although many of the products are development tool oriented, new middleware alternatives to HTTP also are being proposed to get around the document centrism, performance, efficiency, robustness and security limitations in HTTP. Unfortunately, HTTP is proving inadequate for many applications--wide but not deep in functionality.

For example, Distributed Computing Environment (DCE) vendors are working on a DCE-enabled middleware offering that runs HTTP over its secure remote procedure call (RPC) infrastructure. Netscape Communications is pushing the Common Object Request Broker Architecture's Internet Inter-ORB Protocol (IIOP), while Microsoft is going its own way (what a surprise!) with Distributed Common Object Model (DCOM) and the Viper transaction system (and a few other code names that I never can keep straight).

Other vendors--including BEA Systems and Active Software--are shipping products to replace HTTP. Considering this trend toward applets and new middleware, I'd even suggest that HTTP and the Hypertext Markup Language (HTML) will devolve into no more than an Internet menuing system--an alternative to Windows Program Manager icons to start real applications that get work done.

Black Tie, Black Coffee BEA Systems (www.beasys. com) has announced BEA Jolt, a Web connection into its TUXEDO transaction monitor an d message-oriented middleware infrastructure. If you have TUXEDO internally, you can add Web access via simple Java applets calling TUXEDO Java-class libraries and encapsulating internal business functions. If you don't have TUXEDO, it's more work.

Along with the applet, you'll download a proprietary middleware subsystem to replace HTTP between the desktop and the BEA Jolt server with BEA's Jolt Transaction Protocol. This functionality is beyond JavaSoft's Java Database Connectivity (JDBC) for database access and Java Remote Method Invocation (JRMI) for ORB access. Beta Jolt will be available on September 30, with pricing based on server class and starting at $3,000 per server (no client licensing).

Architecturally, BEA is extending the reliability and security of TUXEDO's middleware over the Internet from the Jolt server to the Web browser with its lightweight HTTP protocol replacement. And the middleware is on-the-fly downloadable, like the Java applets it supports. Instead of a dual middleware arch itecture, there's a single middleware architecture provided by a single vendor that should simplify development of large-scale Internet/Web-enabled applications including electronic commerce. The Active Approach to Web Middleware Start-up Active Software's ActiveWeb (www.activesw.com) offers Web-enabled legacy system integration, with Java front-end access to relational database management systems (RDBMSes), including Informix, Oracle and Sybase. Web enablement of SAP's R/3 is coming wi th an Andersen Consulting partnership, but existing CICS transactions would require writing an adapter.

ActiveWeb functions as an alternative to traditional third-party data-access solutions, such as Information Builders' EDA/SQL, but with different application programming interfaces (APIs) and middleware. The API is an event-oriented publish/subscribe model, running on top of a CORBA-like ORB (Orbix). But, Active Software doesn't offer a CORBA interface. There's no back-end programming required where an adapt er is provided (that is, to Oracle, Informix and Sybase RDBMS data). ActiveWeb is available now from Active Software in Mountain View, Calif. (It is priced at $5,000 for the first purchase; $2,000 for additional developers. Brokers are $5,000 each; an RDBMS adapter costs $3,000 per RDBMS.)

An infrastructure of ActiveWeb Information Brokers or servers (available on SunSoft's Solaris now, with a Microsoft Windows NT version in beta) can distribute updates efficiently (though not using IP multicast). And this infrastructure can provide asynchronous but guaranteed and correctly ordered encrypted messaging, with queuing as necessary when remote nodes are unavailable. Servers can signal clients bidirectionally, and Active Software is looking at mapping priorities to network quality of service options for certain events. ActiveWeb performs content-based, not address-based, routing and filtering, and it automatically caches events at remote ActiveWeb brokers as necessary.

Going through the firewall is possibl e. Only the ActiveWeb server sending down Java applets and then acting as the broker for that client must be exposed to connections through the firewall. Moreover, only a single machine, another ActiveWeb server (broker), needs to communicate with internal RDBMSes. Clients communicate with ActiveWeb servers, but not with the actual RDBMS directly.

Active Software demonstrated creating a Java front-end and middle-tier resource server with its tools in about 30 minutes. First, Active Software set up ba sic database field choices, such as SQL with joins, sorts, primary keys and so on--the publish part. The SQL goes from ActiveWeb resource server--not from the client--to the RDBMS. Then, Active Software created the GUI based on that data definition.

Finally, it generated a downloadable Java applet. Along with this application applet is a 50-KB underlying communications applet that returns a non-HTTP connection to the Web server from which the applet came (remember Java security: Applets can only talk back to the server from which they were downloaded).