XML and Java: Developing Web Applications, Second Edition

10.1 The Background of the XML Application Server

Most readers have heard of commercial Web application servers such as IBM's WebSphere, BEA's WebLogic, and Sun's iPlanet. These are Java-based middleware, so developers can write Web applications in Java on top of them. If a Web application server can process XML as a first-class data format, we call it an XML application server.

In this section, we describe what an XML application server is and why it is needed.

10.1.1 The Need for a Common Framework for Building Web Applications

When we develop Web applications in Java, we need to consider an enormous number of requirements梖or example, HTTP protocol handling at the transport layer, XML-based protocol handling such as SOAP at the messaging layer, storing XML into relational databases and vice versa, transactions, authentication, and authorization. These are not all the requirements but are the major ones.

It is not an easy job for average developers to collect and combine all the necessary technologies to build a Web application by themselves. For example, ensuring the security of an application server is quite difficult for those who are not security experts if many libraries and many types of middleware are installed. Furthermore, it may increase the total cost to maintain these underlying technologies. In the worst case, some technology may not work with another technology at the same time. Another type of issue is that we may lose the portability of our applications. Specifically, it becomes very difficult to deploy an application from one computer environment to another depending on the requirements of various libraries and middleware.

Accordingly, we want a single and sound framework for building Web applications that can integrate all the required technologies into a single server or a cluster of servers. For portability, such a framework should not depend on a particular vendor's product; it should be vendor-neutral. Portability is one of the most important factors for Java applications.

What is the most common framework for building Web applications in Java? Java 2 Enterprise Edition (J2EE). J2EE is a set of standard architectures and APIs. Many companies, including IBM and Sun, are participating in defining the J2EE standard in the open organization called Java Community Process (JCP). IBM's WebSphere, BEA's WebLogic, and Sun's iPlanet are the most famous J2EE-compliant application servers. Needless to say, an application written for a J2EE-compliant application server should work with another J2EE-compliant application server.

J2EE adopts existing Java and Internet technologies梖or example, Servlet, JSP, and Enterprise JavaBeans (EJB) as legacy technologies; and SOAP and Web services as emerging technologies. We describe EJB in Chapter 11, SOAP in Chapter 12, and Web services in Chapter 13. Therefore, we focus on Servlet and JSP in this section. J2EE will continue to involve various Internet standards and provide rich functions for building enterprise Web applications, keeping its vendor-neutral characteristics.

Servlet is an API and application framework to write application logic that runs on the server side. A server-side component called a servlet container that runs on one or more Java virtual machines (VMs) launches a servlet instance as a thread for handling HTTP requests. It is faster and more efficient than a CGI script because it is instantiated as a long-term, semipermanent process in an operating system.

JavaServer Pages allows us to embed application logic that runs on the server side into a text document, such as an HTML document or an XML document. The concept is not new; we see the same concept in Server-Side Include (SSI), Active Server Pages (ASP), and the PHP scripting language.

J2EE adopts XML as a data format for describing a portable application, such as Web Application Archive (WAR) and Enterprise Application Archive (EAR). For example, a "web.xml" in WAR is used to configure servlets and JSPs.

10.1.2 What Is an XML Application Server?

When we develop a B2B application using XML, we need to consider how to handle XML at the server side梩hat is, receiving an XML document as a request from the client, analyzing it, and processing it according to an XML-based protocol such as SOAP. In many cases, the application needs to send back a response to the client as an XML document.

Many application servers bundle an XML parser for processing XML documents, but most of them do not provide any support for XML-based protocols as of this writing.^[1] One reason is that an XML-based protocol is an emerging technology and is still under discussion at the World Wide Web Consortium (W3C).

^[1] IBM's WebSphere Application Server is the first commercial one to bundle Apache SOAP, which is a SOAP engine developed by Apache Software Foundation. However, it is offered as a servlet application and is not deeply incorporated into the heart of the application server itself.

Even if a standard XML-based protocol (most likely SOAP) matures, there may be a need for an application-specific XML-based protocol in some cases, depending on an industry-specific requirement. Therefore, it is worthwhile that we discuss a typical way to handle an XML-based protocol using Java programs. Thus we describe how to handle and generate XML documents by using Servlet in Section 10.2 and JSP in Section 10.3.

As we mentioned, J2EE will include support for Web services and SOAP in the near future. For example, "Java Specification Request (JSR) 109: Implementing Enterprise Web Services," which is a specification for supporting Web services in the next version of the J2EE framework, is being defined by JCP. When application servers support JSR 109, building SOAP and Web services will become much easier than it is today. To learn what functions are required for processing SOAP and building Web services with SOAP, refer to Chapters 12 and 13.

We typically want to store incoming XML documents into a relational database management system (RDBMS) if they contain important information for the business梖or example, an XML document that requests a purchase order and an invoice for the request. We may also want to retrieve the data from the RDBMS as an XML document. Although J2EE does not support such functions now, we can do it by combining the database connectivity and XML processing API that J2EE does support. We discuss how to accomplish such functions in Chapter 11.

B2B seems to be well supported by the J2EE framework. How about B2C? If we assume we already have some data source as XML documents on the server side, we may want to provide a service that targets not only a business but also a consumer. For example, the weather report application in Chapter 1 may want to support both machine clients and human clients at the same time. In other words, we may want to integrate B2B and B2C applications. How do we support such requirements? With Apache Cocoon, an XML publishing framework developed by Apache Software Foundation. We describe an example in which both machine clients and human clients are supported by Cocoon in Section 10.4.

As we mentioned, most common functions for processing XML in Web applications will be integrated into the J2EE framework. It will drastically increase the portability of XML-based Web applications and decrease the effort required for building XML-based Web applications. We believe it should be the final goal of XML application servers.

In this section, we discussed the needs of XML application servers from the J2EE point of view. J2EE is a Java standard framework for building Web applications. XML-based protocols are still undergoing standardization and are subject to change. Therefore, we do not describe any specific XML-based protocol in this section. Rather, we describe a generic way of handling XML-based protocols.

Next, we explain the basics of XML processing on the server side by using Servlet.