Many developers are discovering that the front end of a Web application can be a dangerous trap. Sure, it seems simple at first: just grab one of the HTML application development tools and knock out a quick front end and connect to the tool's back end. This works well as long as the application remains a simple HTML application that isn't going anywhere.

But, developers are quickly discovering that what begins, say, as a simple little intranet application becomes so popular that suddenly people are clamoring to put it onto the extranet, and even on the Internet where it can be accessed by the general public. As soon as the developer tries to redeploy the application, he or she falls into the front-end trap. The nice, clean, simple little HTML front end connecting to some tool's proprietary Web application back end can't support the functionality required for new deployment options.

Suddenly, you need a lot of functionality that you didn't think you would need when the application was first deployed. This extra functionality calls for Java on the front end, but the simple HTML front end doesn't effectively support Java. You're trapped. The only recourse is to rebuild the entire application.

In other cases, the developers use a Java front end. Often times, the chosen architecture/tools do not support an HTML front end very well, which you still need. In addition, the resulting solution will not be open and/or scalable. In yet other situations, we find that the back-end solution for the Java and the HTML front end are different, which leads to a situation where the developers cannot reuse business objects on the server.

Developers fall into such traps when they don't think ahead and allow for multiple deployment options. The various options—Internet, intranet, extranet—serve different audiences, have different requirements and must reflect the different computing environments. For example, developers have better knowledge of and, possibly, control over the desktop systems that will connect to an intranet application. Similarly, developers can count on intranet and extranet users to have faster network connections than dial-up Internet users. When dealing with intranet/extranet users, the state capabilities and interaction of a Java front end are both feasible and welcome. HTML, on the other hand, has the advantage when dealing with dial-up users on the Internet.

The plurality of end-user interface types will become even more important over time. End-users will want to access anything from anywhere. This means access from the office, the home, a hotel, a taxicab or a plane. They'll be using Windows'98, Mac, PalmPilot, Windows CE, WebTV, etc. Developers can't fall into the trap of having to completely rebuild the front-end application for each deployment scenario.

Fortunately, there is a solution. You need to support both Java and HTML front ends and variations of each depending on the case (e.g., DHTML). And the way to do that is to opt for a Java application server built on top of open platforms. Java application servers are extremely well suited for the Java/HTML front end, since a Java front end to a Java application server is an apples to apples connection. In addition, the servlet API with the JDK provides very robust HTML support. Java Server Pages makes it even stronger while remaining an open solution. Developers are praising the servlet API for its support for all popular Web Servers and its extremely effective architecture and design.

My preferred approach is to use Java Application Server with CORBA and open platform services, plus an HTML front end using standard servlet and JSP APIs via HTTP, and a Java front end via IIOP protocol. Using open platform services such as Java Transaction Service (JTS) allows the development team to select a service implementation. Anything else is either not supportive of intra/extra/Internet combinations or based on proprietary architectures that will shut down your options, or both.

In the end, developers cannot simply build the front end of the Web application for the immediate problem at hand. We know that Web applications take on a life of their own. The developer might be building an intranet application this month but within a few months the application may need to be deployed on an extranet or even the Internet. Unless you want to continuously rebuild applications to run with different front ends under different deployment options, you must build front-end flexibility into the application from the start.