Partitioning Web applications

This approach is by far the most popular configuration for intranet, electronic commerce and other dynamic data-driven Web applications typically requiring scalable access to one or more legacy databases. The database-integrated Web server does the heavy processing. It collects, merges and formats database query results into basic HTML and GIF documents for delivery to browsers, sometimes as plain text and sometimes in encrypted form using Web security protocols.

This architectural approach facilitates development of a consistent cross-platform look and feel for mainstream corporate database applications ported to the intranet.

By exercising only the lowest common denominator of functionality in the browser/client tier - the "thin" HTML client - developers have greater assurance that Web applications will display and execute approximately the same everywhere. All or most of the business logic is implemented and executed at the Web server, based on database connector interfaces and tool-based application templates.

Templates, such as those found in Microsoft's Active Server Pages (ASP) and Allaire Corp.'s Cold Fusion, provide visual tools for implementing the most common server-based database, security and other application features. For example, an electronic commerce application might include template-driven features for managing electronic catalogs; accessing product, user, pricing, inventory, promotion and shipping information; and defining order-processing workflow with business rules.

Developers at Silicon Reef, Inc., a Web firm in San Francisco, like this server-programming approach. By focusing on database integration and programming Java applications at the server level, rather than working with applets, the developers don't have to center as much on what's happening at the client level, says James Buszard-Welcher, chief technology officer at Silicon Reef.

To make data-driven three-tier applications practical, you need some way to connect Web and database servers effectively for online transaction processing. Connectivity software must translate user information requests into queries that the database can execute and return database results in a format that the Web server can process and deliver to the browser.

CGI is the most common Web server software interface specification. It lets developers create Web pages that return data based on user input, calling a compiled C program or Perl script to access databases and other data sources. But with CGI, a Web server must launch a new process every time it receives a request. This limitation bogs down CPU, memory and disk utilization when a server must handle hundreds or thousands of simultaneous database transactions.

A more scalable interfacing approach is provided via Web server vendor APIs. These APIs provide shared executable libraries available to all applications running on the server. Unfortunately, this approach generally commits you to running the application on the respective vendor's Web server software.

The most common database-server API is Open Database Connectivity (ODBC). However, ODBC is increasingly taking a backseat to the upstart Java Database Connectivity (JDBC), which interfaces applications to databases by means of standard Java programming classes and methods.

JDBC is supported in Sun's JDK Version 1.1, which is included in all commercial Java integrated development environments (IDE). These are software packages that facilitate creation and maintenance of attractive, dynamic, interactive, multipage Web applications. JDBC drivers, written in Java, can be downloaded as part of an applet or installed on a machine for bridging to existing database access libraries.

Your Web server applications and source databases will need to communicate either through matching software driver configurations, such as ODBC to ODBC or JDBC to JDBC, or through a software bridge that converts from one driver standard to another or to the native software drivers provided by relational DBMS vendors.

Most Java IDEs support all of these database connector options and usually provide a run-time license to a relational DBMS to support application development. Some database connector software requires that database driver and client software be installed on each client accessing a particular relational DBMS.

Depending on the number and variety of external databases accessed by your Web server, you may need to invest in software that translates between any of several database drivers. The need for this type of middleware will disappear as more relational DBMS vendors provide native JDBC drivers to match the JDBC drivers in Web browsers and servers. As you bring more distributed data-bases into your Web application, you may need to consider another layer of middleware in transaction servers such as Sybase, Inc.'s Jaguar CTS and Microsoft MTS. These transaction monitors support high-performance, scalable, secure, multiplatform, distributed enterprise transactions across networked data stores. Transaction servers support server-based concurrency control, transaction logging and rollback.

Once you've figured out this data-connection plumbing, you can begin integrating data stores with your Web servers. Most Web development IDEs provide sophisticated visual tools for importing, defining, dragging, dropping and customizing data objects in Web applications.

Enterprise-grade Web development tools offer rich database integration features on par with the best in the industry. They support visual creation of tables, stored procedures, triggers and business rules, as well as testing, debugging and tuning of SQL queries.

Jazzing up Web applications

XML lets Web developers define flexible, object-oriented document meta data formats for diverse applications. Web pages embedded with XML data tags can be browsed, searched and processed more efficiently than those using flat HTML.

In addition, developers are increasingly exploiting the possibilities of downloadable executables, such as Java applets and ActiveX Controls, and animation plug-ins, such as Macromedia, Inc.'s Shockwave. Making these elements play together at the browser is the work of standard scripting languages such as ECMAScript, JavaScript and JScript, and proprietary scripts such as Microsoft's VBScript and Netscape's LiveWire. Among other things, client-side scripts let browsers check the validity of data users key in forms before submitting the data to remote servers.

Keep in mind, however, that jazzing is the strategy under which Web applications most often lose their cross-platform functionality, since guaranteeing that all browser/clients have the same configuration is near impossible. For example, Microsoft's ASP templates only display and execute fully inside Internet Explorer 4.0. A developer may, however, configure the templates to serve equivalent (but possibly less sophisticated) Java applets to browsers that don't support ActiveX.

Unfortunately, today's browser wars have created an environment in which Microsoft and Netscape offer equivalent but subtly divergent Web client functionality in many areas. In addition, the plethora of (often free) downloadable, third-party plug-ins means that almost every browser in existence is a "roll your own" affair.

If you haven't defined or aren't enforcing intranet client standards, you'll be shooting at a moving target. Developing applications that depend only on those functions, formats and APIs supported in the current versions of the most prevalent browser/client environments on your intranet may limit usage.

Internet Explorer 4.0 and Communicator 4.0 principally differ on many Web page formatting and tagging standards as well as on run-time environment, scripting language and security standards. In addition, they diverge on style sheet, multimedia format, object technology, push channel definition and software distribution package standards (see list, page 17).

You've got to tread carefully into development tools that promise you all these bells and whistles. Otherwise, you might be rigging your applications to favor one browser vendor over another.

Breaking down applications

At the Web server level, a persistent Java object is called a servlet. Such an object provides the ability to extend the server's core function set. It requires a server-side JVM to run.

JavaBeans is the leading component technology for Web applications. JavaBeans are reusable Java code modules that developers can integrate and compile into Java applications at any of the three tiers. EJB extends the JavaBeans component model to support server-side applications with security, online transaction processing, database-integration and other scalable enterprise functionality.

Run-time interactions between JavaBeans across all tiers are enabled through Java's Remote Method Invocation interface over the Java Remote Method Protocol or Internet Inter-ORB Protocol.

The number of visually oriented Web IDEs that support Java and JavaBeans technologies far outstrips those supporting development of ActiveX components.

And while the World Wide Web Consortium only recently ratified EJB as an official recommendation, tool vendors are quickly moving to support this component model. EJB's real limiting factor will be the container environments, or EJB servers. Only WebLogic, Inc.'s Tengah Java application server offers an EJB container now, though other vendors promise they'll deliver similar functionality over the next six months, says Costa of Giga.

Costa ranks Symantec Corp.'s Visual Café 2.1 and Microsoft's Visual J++ as No. 1 and 2, respectively, in the Java IDE market. Inprise Corp., IBM and Sybase IDEs are in a dead heat for third place.

JavaBeans' ascendancy is all for the best because it focuses Web developers on a cohesive set of mainstream component specifications for cross-platform applications. It also has spawned a fast-growing market for third-party JavaBeans that can be integrated with any IDE. In fact, most JavaBeans IDEs come bundled with Beans from the IDE vendor and at least one outside Bean supplier.

JavaBeans IDEs also generally let users import new Beans from other sources or build their own Beans. Most IDEs provide visual, drag-and-drop palettes and wizards for laying, linking and customizing Beans and associated business logic. These tools let you build complex, ready-to-run applications with almost no original code.

However, JavaBeans is no panacea for the cross-platform incompatibility blues and may, if you're not careful, worsen the situation. There are three reasons why.

First, different JavaBeans IDEs may incorporate different versions of Sun's JDK or may not fully implement the Java classes, methods, properties and event models contained within the JDK.

Second, different client and server environments often support different JavaBeans containers, the run-time Java environments consisting of JVMs, JIT compilers and Java foundation classes. These containers also provide basic, platform-integrated system services for executing JavaBeans. These services include threading, transactions, state management and resource sharing. System vendors have the flexibility to implement these features in various ways, so long as they conform to basic Java interface specifications.

Third, you may find JVMs (which interpret code prior to execution) and JIT compilers (which compile code on the fly at run-time) too slow for your JavaBeans application. This may spur you to compile your JavaBeans to the target hardware or operating system platform. Once you've done that, the code cannot, by definition, run on another platform without modification - in other words, without recompilation.

The risk is that JavaBeans applications or applets developed in one IDE may not display or execute properly in all run-time platforms. The only way you can know for sure is to test your applications fully in all target containers for the relevant tiers.

For JavaBeans developed to run in the client tier, you want at least to test in the latest versions of Internet Explorer and Communicator. For Beans designed for Web application servers, test under whatever servers are running on your intranet. For database server Beans, make sure to test with the containers developed by your enterprise relational DBMS vendors.

Only when you've tested your JavaBeans and have shown them to execute the same in all equivalent environments will you have true cross-platform portability of application components. Carefully consider a JavaBeans IDE's debugging features - especially debugging of Beans in various client and server environments. You'll live and die by them.

Still, JavaBeans is not the only component technology.

To the extent you already have ActiveX components installed at various intranet tiers, you'll have to concern yourself with bridging JavaBeans to those components via the Common Object Request Broker Architecture or some other object protocol. We'll continue to have to deal with JavaBeans-to-ActiveX integration issues for the indefinite future, considering ActiveX is the principal component technology for the world's dominant computing environment, Windows.

Developers have turned to ActiveX for distributing updates to applications running on Windows desktops. "Many applications that would have been deployed as Windows executables are now being deployed as ActiveX Controls that run in [Internet Explorer]," Costa explains. Just about every tool that can develop for Windows supports ActiveX, Costa adds.

Pushing app development

Java and HTML are the twin pillars upon which the Web's cross-platform hopes rest. Obviously, these standards have not eliminated vendor-proprietary development APIs, formats and technologies. However, owing to their universal acceptance, they have made it possible for intrepid, dogged software developers to cobble together more-than-rudimentary Web applications that play the same in most clients environments and that can be ported to various Web servers.

Truly write once, run anywhere Web applications will only be feasible if two big things happen: the Java industry shakes out into a single, rigorously standardized community, and Microsoft scraps ActiveX, COM and DCOM and rearchitects Windows around Java and its component technologies.

Neither of these will likely happen any time soon, but don't let that stop you from trying to scale the cross-platform application mountain with available Web tools and technologies. You'll be surprised at what you can accomplish.