There's A Web -- Is There A Way?

Software Magazine
April 1997/Tony Baer

Andersen Windows in Bayport, Minn., thinks that the World Wide Web may be the best place to turn to extend its highly successful "mass customization" business strategy. For the past two years, it has operated a client/server order management system with an external network of 100 wholesale distributors. The application, written in the FortZ&Mac255; development environment with an Oracle7 database, helps customers configure window choices, place orders and check their status. In the partitioned application, validation functions run on client platforms outside the company, while core functions execute safely back on the server. Last year, the FortZ&Mac255; application handled over eight million transactions.

Now Andersen wants to extend the application to selected retailers. However, the company's business relationship with retailers isn't as intimate as it is with wholesalers, who purchase high volumes of custom windows for new construction projects and therefore conduct numerous transactions on a regular basis. Retailers, on the other hand, are likely buying replacement windows, and therefore ordering far fewer. Because the business relationship with retailers isn't as structured as with wholesalers, Andersen would have much less control over the client platform, though the architecture would remain largely the same, with FortZ&Mac255;'s SDK capabilities generating the Web interface. All these factors have Mike Tremblay, Andersen's CIO and manager of business systems, wondering. "The question I can't answer yet is, 'Will it really work?'" he says.

Tremblay has reason to be both enthusiastic and wary. On the plus side, the Web's uniform deployment environment is an appealing alternative to the chaotic, multiplatform client/server world. Furthermore, the Andersen application being deployed has a proven architecture, and the only difference -- the new front end -- is a change that most consider relatively elementary. "The ability to graft HTML pages [to an existing application] is simply a bridge strategy," says Evan Quinn, an analyst at International Data Corp. (IDC), Framingham, Mass.

However, the Web's immature communications and application infrastructure is problematic. The transaction processing environment is skeletal: There are few if any tools to manage IP transmission over the Internet, and the application development technologies are numerous, and in most cases, still in initial versions.

Then there are questions about the robustness of the public network. Even organizations considering deploying intranets rank network bandwidth as a prime concern. "We'll have to engineer carefully so as not to bring our internal network to its knees," says Jim Kennedy, director of technology management for Trigon Blue Cross Blue Shield, Richmond, Va., which is mulling over its Web development options.

For its part, Andersen Windows' application will involve a public network, and Tremblay has issues to work out. "We're dealing with communications speeds and reliability issues that we still need to sort out," he admits.

Though these issues may seem to be communications, rather than application problems, that's not the case, says Michael Prince, CIO for Burlington Coat Factory. The Burlington, N.J.-based firm is deploying an Oracle Developer 2000 intranet retailing application via satellite, a medium that, while more reliable than public networks, may prove far slower due to the one-to-two- second delays inherent in radio transmission. Prince says Web applications should be designed to compensate for transmission speeds or network interruptions. For example, developers might design the Web page to cache user input until it's ready to be submitted. "Fortunately, the Web browser buffers the input," Prince says.

According to IDC's Quinn, 1996 was a year of "experimentation" for intranet applications. He says developers were getting used to Java and trying Web enterprise development tools such as NetDynamics, which combines a Visual Java development environment with ODBC database connectivity. The result are applications with more sophisticated database querying than first-generation document servers. This year, he expects users to begin developing business-critical, but few mission-critical, applications.

Users following that script include Los Alamos National Laboratory (LANL), Los Alamos, N.M., and GE Medical Systems, Waukesha, Wisc. Last year, LANL got its feet wet by Web-enabling an existing PowerBuilder data warehouse application, using the Web.pb tool from Powersoft Corp., Concord, Mass. They used Web.pb to separate the application logic from the client and move it to the Web server. LANL took the contents of a PowerBuilder data window, converted it to HTML, and embedded it within an HTML page. "Because we used PowerBuilder, we were able to leverage a lot of code that was already written," says Michael Calhoun, project leader. Later this year, LANL will develop transaction processing applications including staff timesheets, travel reporting and purchasing. They are considering using Java tools to support the more complex applications.

At GE Medical, IS officials recently phased in a Web-based manufacturing statistical quality application,which performs limited transaction processing, for the company's production sites across three continents. The company used Sapphire Web, a visual server development tool from Bluestone Inc., Mt. Laurel, N.J., to deploy the application because it provided a faster alternative to developing PowerBuilder applications.

However, mission-critical transaction processing applications will have to wait, says Larry Walker, technology planner for GE Medical. Walker is concerned that no mechanism exists for ensuring that transaction messages are delivered. He wants to find a way to implement a Web interface to the DCE (Distributed Computing Environment) RPC (remote procedure call) middleware architecture to which the firm is already committed.

There are other hurdles to overcome before the Web is ready for prime-time business applications. Beyond the challenge of maintaining a stable transaction environment (see sidebar, "How 'Open' is the Web?" pg. 54) is the immaturity of the tools. Although most client/server 4GL tools vendors are providing modules for generating HTML pages, their Java strategies are just starting to materialize as product. For instance, the first half of 1997 will see first-generation visual Java development environments from Oracle Corp., Redwood Shores, Calif., Unify Inc., San Jose, Calif., and Powersoft. Different products are introducing untested features such as automatic Java code generation from 4GLs, overlaying rich client/server visual controls such as drop-down menus (currently not supported by Java), and the ability to debug applications within the browser, rather than as detached code.

Java itself continues to be a work in progress. Today, Java applets are primarily graphical; few have been designed to execute complex business logic. Blame at least part of that on Java's immaturity and the lack of trained developers. Furthermore, there's as yet no consensus that Java, as a 3GL, is innately suitable as a business application development language. "Java is like the 3GL vs. 4GL fight," says Sergey Fradkov, senior technology specialist for UNIF/X Inc., an application development consulting firm in New York City. "It is a programming language, and you need to write a significant amount of code to achieve the same result as you would in a 4GL."

More problematic is the lack of the necessary interior plumbing, including a faster compiler and more robust database connectivity. The compiler is critical because the existing tool supplied by JavaSoft is quite slow, and the process of deploying applications at runtime over a network can present bottlenecks that worsen when applications are used on a continuing basis. To address this, JavaSoft says it will deliver a new "just-in-time" compiler later this year. As for database access, JavaSoft's current JDBC interface trails the ODBC standard when it comes to scrolling through long lists of data and mapping it to tables defined in an application.

Yet, in spite of all the tactical questions surrounding Web and Java application development, most organizations are staying the course because of one very simple reason -- they don't want to have to worry about where their applications will run. "We want to get out of the deployment game," says LANL's Calhoun.

How 'Open' Is the Web?

April 1997/Tony Baer

The most touted advantage of World Wide Web-based applications is that they can be deployed on any client platform running a standard Web browser. That's true, as long as the application is written in HTML or Java, and uses HTTP and TCP/IP for navigation and communications. Pure vanilla implementations have proven fine for simple, information-sharing Web applications such as employee phone directories. However, applications involving business logic and transaction processing are likely to require at least some proprietary technology.

It starts with minor variations in the ways Microsoft and Netscape browsers display Web pages. Although they support an HTML standard, the browsers are often slightly out of sync when supporting new HTML features. Furthermore, they sport different style sheets, which govern features such as screen colors. The result is that Web pages may look slightly different, or in some cases jumbled, when viewed from the "other" browser -- an annoyance, but not a show stopper.

However, more important differences lie in the way application logic is deployed. Netscape supports Java and JavaScript, while Microsoft supports Java, ActiveX and a slight variant of JavaScript. The differences are far from academic because applications written in popular client/server development tools such as Delphi, Visual Basic and PowerBuilder already incorporate ActiveX components or their OLE control or VBX predecessors. Similarly, many Netscape plug-ins also use Java and JavaScript. If business logic is involved, developers cannot take for granted that their Web applications will run anywhere.

"A position that we'll have to take is that we'll probably have to standardize on one browser, because Netscape and Microsoft seem to be heading in different directions," says Jim Kennedy, director of technology management for Trigon Blue Cross Blue Shield, Richmond, Va.

Some users employ workarounds. One solution promoted by Microsoft and Netscape is to encapsulate Java applets within ActiveX controls, or vice versa. The idea seems sound, but the reality is that each application approach relies on a different object model and API: Java's Corba heritage vs. ActiveX's DCOM orientation. This could cause interoperability problems in the short run, says Evan Quinn, an analyst at International Data Corp., Framingham, Mass., but he believes that "the interfaces should be cleaner" by later this year.

Beyond the issue of browser platform is the question of what must run on the client. If the client-side application is designed to run with pure HTML, Java or ActiveX controls, then all that's needed is a Web browser. If a window or component written in the 4GL's native language is embedded within an HTML page, however, the client may require a runtime version of the 4GL itself. There are tradeoffs to this approach: While many 4GLs provide greater functionality than is currently possible with Java, the Web client is no longer universal, and many question how efficiently native client/server applications not optimized for thin-client environments will run within the browser.

Transaction processing is another issue. HTML is known as a "stateless" environment, because it has no way to track or maintain the status of a transaction. Each time a user clicks on a new Web page, the connection with the database must be reestablished -- a situation that plays havoc with access control and transaction integrity, and which effectively limits the complexity and volume of transactions that can be conducted over a Web application. Conceivably, transaction management could be accomplished with a Java application. However, the most mature tools for Internet transaction processing currently come from the usual suspects -- Oracle, Progress and other database vendors -- and are therefore somewhat proprietary.



Webbed Options

Developers toying with Web applications have a vast array of technology choices, most of which are works in progress.

First-generation applications included "passive" Web pages that consisted of HTML formats and PERL scripts for staging retrieved data for display. HTML and PERL are extremely simple languages for formatting Web pages and mapping data to them -- and extremely limited in their capabilities.

Sun's introduction of Java two years ago promised to free Web applications from their static legacy. Java, a neutered form of C++, offers both compactness and portability, the key ingredients for success in the highly-distributed, thin-client environment of the Web. Still, the 3GL heritage of Java is a stumbling block for developers used to more powerful 4GL tools.

Within the past six months, the first RAD-oriented Visual Java tools have begun to appear, starting with Visual CafZ&Mac255; Pro from Symantec Corp. Today, choosing between the tools involves tradeoffs. For instance, Dan Gutierrez, president of Amulet Consulting, an application development consulting firm in Los Angeles, recently switched from CafZ&Mac255; to Visual J++. The decision, he says, was largely a tradeoff between CafZ&Mac255;'s superior visual development environment and Visual J++'s database connectivity.

Microsoft's introduction of ActiveX provides a means for Web-enabling the OLE controls that pervade Windows applications. Its Visual J++ tool will enable developers to encapsulate ActiveX controls as Java applets and vice versa.

Then there's JavaScript, a high-level, 4GL-like Netscape scripting language. JavaScript is easier to use but less functional than Java, and has been primarily used in Netscape Navigator plug-in applications. A kinder and gentler Java derivative is Java Beans, a set of APIs that JavaSoft introduced in late 1996 for building Java components.