Since the mid-'90s we've seen the quality of Web programming paradigms mature at an astonishing rate: from static pages with animation, CGI-based programs, and JDBC connectivity to back-end relational databases and servlets processing requests on application servers. We commonly hear about Web pages being more interactive, likely using HTML forms, JavaScript, or Java applets.

Beyond the battle being waged on the first tier, the client, it's important to understand the drive toward scalable, platform-neutral technologies on the middle and back-end tiers. In particular, Java and XML set the stage for the growth of B2B Web marketplaces, where participants in supply chain management (SCM) and enterprise resource planning (ERP) will realize enormous gains in speed and access to data.

In this article we'll look at a simple application that uses Java and XML to manage data: the Conference Survey Web page. To develop complex Web pages, particularly pages based on a server-side programming model, programmer productivity is strongly affected by the tools used. We'll show how the IBM VisualAge for Java suite of tools can be used to develop, build, and test this page.

Conference Survey Web Page
At the end of the fictitious e-Business 2000 conference, participants are asked to fill in a survey to rate the various sessions and to provide comments and suggestions for future use. To ensure attendee responses aren't lost and don't need to be scanned or typed into a system, a Web page has been set up (see Figure 1).

Behind this HTML form is a three-tiered Web application (see Figure 2). The essential pieces of the application can be grouped as follows:

• Tier 1: HTML form, JSP pages
• Tier 2: Java servlet, JavaBeans, XML parser, all running under an application server
• Tier 3: XML files

In our Conference Survey application we opted to use HTML on the client Web browser instead of XML for two reasons:

1. HTML forms are prolific and drop-dead easy to implement. Simple forms support a thin-client model, in contrast to Java applets, which are too cumbersome as a data transfer mechanism.
2. At this writing XML support in popular Web browsers is inconsistent. You don't want to find that your application isn't accessible because of the foibles of a browser.

Tier 2, the middle tier, represents those parts of the application that run on an application server (e.g., IBM WebSphere Application Server). The servlet essentially acts as a traffic cop for the application flow: when the servlet receives a POST request, it records a survey response and updates the summary bean; when the servlet receives a GET request (from a private Web page requesting a summary status), it displays a statistical summary of all responses (see Figure 3). When the application starts, the summary is initialized from the summary file (on the back-end tier), if it exists. Beans for the responses and summary are used to store state data and write out XML to persistent files on the back end. To assist with the parsing of the XML data from the back-end tier, a SAX-based XML parser also runs on the application server. When the application is closed, the summary bean writes out its state data to the summary XML document.

By processing XML on the middle tier, the Conference Survey application is well placed to exchange data with other XML-based applications. If multiple applications reside on the same application server, events in one application could trigger listener beans in another application to read its state data and subsequently mine it differently. For example, suppose another application wanted to take the opinions voiced by a survey respondent to help build a customer profile. The data could be used to target specific kinds of Web advertising to users based on the preferences they cited in their survey response.

On Tier 3, using XML documents as the vehicle for persistent data, you maintain the flexibility to mine the data as you deem fit without being forced down any particular path in terms of how it will be presented. For the amount of data being represented here, using a relational database would be overkill, while using serialized beans is overly complex. Because XML is self-describing by definition, and XML parsers are readily available, using XML is preferable to a flat file (which might use, for example, name-value pairs), where the programmer is forced to write a custom parser.

The XML fragment in Listing 1 illustrates the data that's written out to a file for each response.

The technology used in the Conference Survey example provides a scalable model for building three-tier Web applications. If the amount of persistent data grows very large, XML files could be stored in a relational database. As additional kinds of data mining could be applied to the data, additional servlets and beans can be deployed to the application server. As popular Web browsers standardize on how to handle XML, then XML and XSL stylesheets could eventually replace HTML pages and JSP pages.

Although the application architecture is straightforward enough, the challenge remains to find a suite of tools that can work together to let you easily develop and test the end-to-end application. Enter VisualAge for Java.

Integrated Tools
Using VisualAge for Java, version 3.5, you can develop, test, and debug full-blown XML-based Web applications, all within the VisualAge for Java environment. Most development tool suites don't provide you with adequate integration. For example, you might have a great editor and compiler, but you need to deploy your code to a Web application server for testing and debugging. Unless these tools are integrated, you'll spend a lot of time redeploying code for testing rather than testing your code in a development environment. VisualAge for Java includes tools to create and run end-to-end Web applications like the Conference Survey application.

• WebSphere test environment: This run-time environment is a version of the IBM WebSphere Application Server, Advanced Edition product, streamlined for use specifically inside VisualAge for Java. The environment includes tools to start, stop, and configure the server (see Figure 4). If server-side source code is changed, VisualAge for Java incrementally compiles the code and hotlinks it into a running program.

  You can run multiple, end-to-end Web application scenarios in this environment, such as e-commerce (store and customer applications) or B2B (supplier, vendor, and manufacturer applications). You can also pass data between the various applications, all from within the comfort of the WebSphere test environment.

• Servlet wizard: The Create Servlet SmartGuide (see Figure 5) provides a quick way to create servlets and related Web resources files (HTML and JSP pages).

• XML Parser for Java: This parser is a version of IBM's XML4J parser, which conforms to standards and recommendations for XML, DOM, SAX, and Namespaces support.

  In the Conference Survey application, the parser is used when the servlet starts. It reads the summary file, if it exists. If any responses aren't reflected in the summary file, the parser reads in those records and modifies the summary bean, as appropriate.

• XML Generator: This tool generates sample XML documents based on a DTD you provide. While an application like the Conference Survey is too simple to require this tool, you could use the XML generator to generate a diverse range of test cases.
• Integrated debugger: This debugger includes the features found in all good debuggers: breakpoint setting, variable inspection and modification, step into and through methods, multithread support, define expressions to watch as you step through programs, and so on. In addition, you can halt execution in the middle of a running program, change a variable value, and resume execution. In a complex scenario with multiple applications that pass data between each other, this debugging support can speed your development considerably. (see Figure 6).

• JSP execution monitor: This tool provides an integrated run-time view of your JSP page, letting you quickly debug problems arising from JSP-generated code. As with a debugger, you can step through a JSP page and see both the generated intermediary Java source and the generated HTML (see Figure 7).

Setting Up the Application
To set up the end-to-end environment in VisualAge for Java, we need to follow these steps:

1. Load all necessary projects into the workspace. Add the IBM WebSphere Test Environment, IBM XML Parser for Java, and Sun Servlet API. Of course, your application project will also need to be in the workspace.

   In the response bean an instance of IBM XML Parser for Java is created:

   String parserClass = "com.ibm.xml.parsers.SAXParser";
   parser = ParserFactory.makeParser(parserClass);
   parser.setDocumentHandler(handler);

   Note that the SAX-based instance of this parser has been tested to work with the WebSphere Test Environment and is not guaranteed to work with other application servers.

2. Edit the WebSphere Test Environment's servlet initialization file. On server start-up, you can specify that the WebSphere Test Environment initialize a specific servlet instance with particular parameters. In the default_app.webapp XML file, we've added a servlet entity for the SurveyServlet servlet. The entity specifies the directory where the application will be writing an XML file for each survey response (see Listing 2).
3. Add all client-side Web resources (HTML, JSP, GIF) to the WebSphere Test Environment's default Web directory. In the Conference Survey application we add the HTML and JSP pages, and all associated artwork files, to the \ide\project_ resources\IBM WebSphere Test Environment\hosts\ default_host\default_ app\web directory.

1. Start the servlet engine in the Servlet Engine page of the WebSphere Test Environment Control Center. The Console window provides status information on the servlet engine as it starts.
2. Open a Web browser to the server-based URL (not file-based!) where the survey Web client resides (see the URL in Figure 1). The WebSphere Test Environment uses port 8080 as the default port. In our example, the URL is http://localhost:8080/survey/survey.html.
3. Fill in the survey and submit it. When you receive the "success" message in the browser, you've essentially gone to the back end of the application and back: the servlet processed the submission and created an instance of a response bean; the bean wrote out response information to an XML response document (in the directory specified in default_app.webapp); and a JSP page returned a status message back to the browser.

Debugging the Application
Problems inevitably arise during development - even to the best of us! Perhaps the code that creates the summary bean isn't properly storing the data it's parsing from an XML response document. In Figure 6, we've set a breakpoint where the summary bean is assigning values to a variable that holds parsed comment text. We step into the setComments() method and find the problem: instead of appending comments in the comment summary, the comment summary contents are replaced with current XML document contents. Modify the method and retest.

Consider a situation in which the summary page displayed in the Web browser isn't quite right. You need to debug your JSP file, but how? Notice that in the Control Center (see Figure 4) when we started the servlet engine we enabled the "JSP source debugger." This lets us debug the JSP source using the IDE debugger. You can inspect variables generated dynamically from the JSP source. On another page of the Control Center, the JSP Execution Monitor Options page, select the "Enable monitoring JSP execution" option, and the JSP Execution Monitor will appear the next time the JSP page is invoked. With the JSP Execution Monitor we can step through JSP code to see the corresponding generated Java source and generated HTML (see Figure 7).

Extending the Application
Other information can be mined from the survey data:

• Calculate survey scores for each response based on some kind of weighting system. Store the score as part of the XML data for each response. Write a separate servlet that extracts the comment text from the high-scoring responses. The conference organizers could then look for inspiring quotations they could use next year.
• In the same manner, calculate session scores for the summary. The results provide information on which sessions and speakers were popular - and which should be avoided!

Conclusion
Using Java and XML, our sample application remains extensible. Using VisualAge for Java, you can quickly prototype Web applications. Servlets, JSP pages, an XML parser, and XML files can be used together in the VisualAge for Java development environment, making development and debugging a snap.