Read an Excerpt
An extract from Chapter 1 of 'Professional Java Server Programming'
1
Web Application Development
Over the past few years, we've witnessed some incredible changes in the way we think about computers. We are no longer bound by large and cumbersome applications on the desktop. With the introduction of the Internet and the World Wide Web, we can now access information, and even do business, from virtually anywhere. The challenge that we, as application developers, now face is that of raising the bar yet again. With these recent advances in technology also comes the demand for faster, lighter, and more robust applications that we can deliver across the Web.Fortunately, we have some powerful tools to work with. In the past, if you wanted to deliver a database-driven application to customers over the Web, you were pretty much limited to writing CGI scripts to process form data and return some results. But in the last couple of years, a large number of technologies have appeared. The only trouble is trying to sort through the options and decide what is right for you and your organization.
CGI has served its purpose, of adding interactivity and dynamic content to the Web, well. The shortcomings of CGI, both in developing for it and in its scalability, have lead to the development of server-specific API's like ISAPI and NSAPI. While these APIs are indeed more efficient than their CGI predecessor, they suffer from increased complexity. Scripting solutions like Active Server Pages (ASP) and PHP have helped simplify web application development. Such solutions have provided a web interface to components used to handle logic and communicate with data sources - integrating technology to create web applications.
To address the potential of these technologies and to offer a more extensible and portable server-side solution, Sun has developed a new technology called servlets. Java servlets are very efficient, due to an intuitive threading model in which each request is handled by a new lightweight thread. Servlets are also platform independent because they interface to a particular server architecture through a set of standard interfaces (that make the servlet engine) and a Java Virtual Machine. Lastly, Java servlets provide an object-oriented and highly extensible middle tier for web applications. Servlets can access all of the enterprise Java APIs like JNDI, JDBC, RMI, and Enterprise JavaBeans, to name a few.
This book will introduce and examine Java servlets and these related server-side Java technologies. We hope to show conclusively how server-side Java can act as the key to developing n-tier applications, with browser clients accessing business logic and data services through servlets.
We will see how to code servlets and how they can be used to extend the functionality of the web server. We will also use the newest server-side Java technology, called JavaServer Pages (JSP). JavaServer Pages give us a way to 'glue together' HTML, Java code and components by simply creating a special web page that the web server will dynamically compile into a servlet the first time it is called. These two technologies form the basis for an exploration of the various parts of the typical n-tier application we show on the inside front cover.
This chapter will cover the following:
- Give an overview of web development.
- Discuss server-side applications vs. client-side applications.
- Introduce server-side Java technologies.
- Look at the advantages of using Java on the server.
Web Architecture
Before we can begin to build server-side Java applications, we must first review some basics. For those of you with some experience with web applications, please feel free to skip ahead to the next section. For the rest of you, let's start by showing what happens behind the scenes when you request a web page by typing in a simple URL (Universal Resource Locator) in your web browser.To open a web page in your browser, you usually either type in the URL or click an existing link to the URL. Once you submit this request and the web server receives it, the web server locates the web page and sends it back to the browser (see the figure below). The browser then displays the page. Each image in the page is also referenced by a URL and the browser requests each image URL from the server in the same way it requested the main HTML page.
When developing applications for this architecture, it helps to have a good understanding of the role of both the web browser and the web server. As you'll soon discover, a thorough knowledge of each is essential to the overall success of your application.
The Web Browser
The web browser can be thought of as a universal user interface. Whether you're doing some simple web browsing or transacting online banking, the web browser's responsibilities are that of presenting web content, issuing requests to the web server, and handling any results generated by the request. The ubiquity of browsers, the generic HTML and Internet access is what makes this interesting.In the past couple of years, we've seen considerable advances in the browser market. Both Microsoft and Netscape have continually raised the bar, giving us some incredible power on the client side. Both of the major browsers, Microsoft Internet Explorer and Netscape Communicator, have evolved into fully programmable document containers. Each has its own object model allowing for scripts, or objects, to manipulate the elements of the document itself. Scripting languages like VBScript or JavaScript can be used to perform client-side data validation, or provide some interactivity within the document.
Dynamic HTML (DHTML) is a combination of HTML, Cascading Style Sheets (CSS), the document object model, and scripting languages. Cascading Style Sheets are a better way of positioning and formatting your HTML elements. And since each property of the style sheet is made visible to the object model, you can use some script to manipulate and reposition your HTML elements. DHTML, as a whole, provides a greater level of interactivity within your pages. It also adds much more control over the presentation of them as well.
The latest must-have browser feature is Extensible Markup Language (XML) support. XML allows you to define your own tag set to characterize your data, and to construct documents and data structures using these tags. XML provides a way for structured data to be self-describing, and that means the data can be portable. Furthermore, with Extensible StyleSheets (XSL), you can select the data you want to see, and even change tag names, allowing you to transform XML tags to HTML, for instance. Exactly where you perform these translation steps depends on whether you can depend on XML support in your client browsers. In this book, because such browsers are by no means ubiquitous, we'll concentrate on making transformations to the XML on the server.
The web browser is also capable of executing applications within the same context as the document on view. The two most popular choices for client-side web applications are Microsoft's ActiveX technology and Java applets. ActiveX components are downloaded from the web server, registered with the Windows registry, and executed when called upon by other script elements. A Java applet is a small Java program also downloaded from the web server, and executed within the browser's own Java Virtual Machine (JVM). Both ActiveX objects and Java applets have full access to the browser's document object model and can exchange data between the browser and themselves.
Regardless of the way in which we make use of a browser, it will always serve the purpose of being our 'window to the world'. It serves as our primary user interface as we browse the web, conduct on-line business, or even play games.
The Web Server
At the heart of any web interaction is the web server. The web server is a program running on the server that listens for incoming requests and services those requests as they come in. Once the web server receives a request, it then springs into action. Depending on the type of request, the web server might look for a web page, or it might execute a program on the server. Either way, it will always return some kind of results to the web browser, even if its simply an error message saying that it couldn't process the request.
The web server will play an important role in our server-side applications that we develop. Java servlets can be run using just about any web server. Since servlets can be run using a standalone servlet engine, the web server doesn't necessarily have to support servlets in order for you to make use of them. In this book we use the Java web development kit, but Apache JServ, JRun or the Java Web Server can all host the examples.
N-tier Applications
When discussing web application development, it is appropriate to introduce the concept of n-tier architecture. Typical client/server systems have fallen into the category of a two-tiered architecture. The application exists entirely on the client PC while the database sits out on a server somewhere in the organization. While this approach allows us to share data across the enterprise, it does have many drawbacks.In a two-tiered application, the processing load is given to the PC while the more powerful server simply acts as a traffic controller between the application and the database. As a result, not only does the application performance suffer due to the limited resources of the PC, but the network traffic tends to increase as well. When the entire application is processed on a PC, the application is forced to make multiple requests for data before even presenting anything to the user. These multiple database requests can heavily tax the network.
Another problem with a two-tiered approach is that of maintenance. Even the smallest of changes to an application would involve a complete rollout to the entire user base. After a few rollouts, it may become hard to manage which versions exist where. Some users may not be ready for a full rollout and ignore the changes while another group insists on making the changes immediately. As a result, you now have two separate versions of the software to maintain.
To address these issues, the software community developed the notion of a three-tier architecture. The application is broken up into three separate logical layers, each with a well-defined set of interfaces. The first tier is referred to as the presentation layer and typically consists of a graphical user interface of some kind. The middle tier consists of the application logic and the third tier contains the data that is needed for the application.
The middle tier (application logic) is basically the code which the user calls upon (through the presentation layer) to retrieve the desired data. The presentation layer then receives the data and formats it for display. This separation of application logic from the user interface adds enormous flexibility to the design of the application. Multiple user interfaces can be built and deployed without ever changing the application logic, provided the application logic presents a clearly defined interface to the presentation layer.
The third tier contains the data that is needed for the application. This data can consist of any source of information, including an enterprise database like Oracle or Sybase, a set of XML documents (data that has been stored in a well-formed document conforming to the XML specification), or even a directory service like an LDAP server. The data for an application is not limited to just a relational database. There are many different sources of enterprise data that your applications can access.
By employing a three-tier architecture, the issues of performance, network traffic, and maintenance have all been addressed. This approach is almost where we would like it, but not quite yet. What it lacks is reusability and scalability. We could still end up with a series of "stovepipes" within an organization. We'd have dozens of applications that don't communicate with one another.
This is where n-tier architecture comes in. To turn a three-tier system into an n-tier system, we simply extend the middle tier by allowing for multiple application objects rather than just a single application (see figure below). These application objects must each have an interface which allows them to work together. An interface can be thought of as a contract. Each object states through its interface that it will accept certain parameters and return a specific set of results. Application objects communicate with each other using their interfaces.
With an n-tier architecture, we can now have multiple applications using a common set of business objects across an organization. This promotes the standardization of business practices by creating a single set of business functions for the entire organization to access. If a business rule changes, then changes have to be made to only the business object and, if necessary, its interface and subsequently any object that accesses the interface. It is important to note that when designing an object and its interface, it is a good idea to make the interface as generic as possible to avoid a lot of changes later on. Since other objects communicate with the interface and not the object itself, changes to the object, and not the interface, are relatively simple and quick.
Web Application Architecture
A web application typically follows a three tiered model (see figure below). The first tier consists of the presentation layer which, in the case of a web application, includes not only the web browser but also the web server, which is responsible for assembling the data into a presentable format. The second tier is the application layer. It usually consists of some sort of script or program. Finally, the third tier provides the second tier with the data that it needs. A typical web application will collect data from the user (first tier), send a request to the web server, run the requested server program (second and third tiers), package up the data to be presented in the web browser, and send it back to the browser for display (first tier).
Collecting the Data
The first step of a web application usually, but not always, involves collecting some kind of data from the user. Traditionally, this was always handled using a simple HTML form. The user would type some information into some form fields, press a Submit button, and wait for the results. While this is still used today quite extensively, there is an alternative.Since you're reading this book, I assume that you have some familiarity with a Java applet. Applets are Java programs that run inside a web page. Java applets can be used as a client to a server-side program by simply opening up a socket connection to the web server. This approach can help to move the majority of data formatting and validation off the server and onto the client. Remember that in a multi-tier architecture, we are not necessarily looking to move everything away from the client side. We are simply trying to put code where it belongs. While application logic doesn't belong on the client side, presentation logic might not always be appropriate on the server side. The main problem with applets remains the constrained bandwidth of most Internet access.
Sending the Web Server a Request
In order for the web server to 'spring into action' and execute a server program, the web browser needs to package up the user data and issue an HTTP request to the web server. An HTTP request consists of the URL for the page or script that the user wishes to access, form data (if entered), and any additional header info (browser information, length and type of request). A request is typically generated by the browser, but it's still important to understand how a request is constructed and used.Each request must specify which method the request is to use. The three most commonly-used methods are HEAD, GET, and POST.
- The HEAD method simply retrieves information about a document and not the document itself.
- The GET and POST methods are the ones that you use to issue requests to execute a web program. While they both accomplish the same task, their methods of doing so are quite different.
Using the GET Method
GET is used as the default method for all web requests. When a user makes a simple request for a web page, the browser issues the request as a GET request. Since a GET request packages all of the form data with the request string, the browser sees it as just another URL. If some previous results for the exact same request URL exist in the cache, then the older results might be displayed. Another potential problem with using the GET method is that the amount of data that can be passed is limited since it has to be appended to the request URL.
Using the POST Method
Requests that use the POST method also package up the form data as part of the request body. The server program will be able to read the contents of the input file and parse out the variable names and values. The POST method allows more data that can be passed and it will always send the request to the server (instead of looking to the cache directory).
Which Method Should You Use?
In most cases, it really won't matter which method that you use to issue a request to the web server. Ideally, a GET request should be used to retrieve information, that is, as it acts as a modified URL that issues instructions to the server. A POST request should be used if the request will actually modify the contents of a data store on the server. Along that line of thinking, a simple database search that returns a set of results should use a GET request and a timesheet entry program should use a POST request.
Executing the Server Script (or Program)
An important function of the web server is that of passing a request to a specific script, or program, to be processed. The web server first determines which type of operating environment it needs to load by looking at the extension of the requested file (or the directory the file is located in). This is done through mapping. When a web server is configured, it is told how to handle specific file types. For example, typically anything in the cgi-bin directory will be treated as a CGI script, or anything with a .jsp extension will be treated as a JavaServer Page.Once the web server determines the type of the requested file, it then loads any required runtime environment for the file to be executed. For example, if a CGI program were written in Perl, the web server would create a new process and load the Perl interpreter into it. For some types of programs it is not necessary to load a separate runtime environment. This is dependent on the web server and the technology being used. Either way, the web server fulfills its responsibility by directing the request to the right place.
Returning the Results to the Browser
The final step in a web application is to make some kind of response to the operation and return that to the browser. Generally speaking, the server script specifies the content type and then writes the response to an output stream. When the web browser receives the response, it will first look at the response header and determine the mime type so that it knows how to render the data. The most common content type is "text/html", but the server can return XML, unformatted text, GIFs and even streamed audio.
