The pages are created and designed using HTML.

 Different Kinds of Server

First on our tour of the web, let's see what the different types of existing server look like using a W3 browser. (For the fancy demos, skip ahead)

FTP

An FTP server, for example, is simply presented as a hypertext list. The user does not have to know anything about FTP. This example is a server which has postscripts copies of preprints of physics papers. We can follow through the directory structure to the preprints directory, to the preprints from Rice, into the ps directory which I happen to know contains postscript files, and find a particular preprint of a physics paper.

Gopher

Looking at a Gopher server is very similar. Gopher is like WWW except that there is no hypertext: anything is either a plain document or a menu. Here we see an example of a gopher menu, and you can see that there are extra menu items which have been introduced to look like headings.

News

When a WWW browser reads news, it uses hypertext to give instant links between related articles and newsgroups. Looking for example at WWW's own newsgroup, comp.infosystems.www, let's select a reply message -- one starting with "Re:” [I can't leave you a link to this as news messages are deleted with time, so you have to pick one.] Notice that at the top of the article there is a link back to the newsgroup. Also, there is a link to any article references. If you are lucky with your choice, you will see a link within the text "in article <blah>, somebody writes". This is a good example of W3 software making links out of existing information.

W3 servers

Lastly, let us look at some real hypertext specifically written for W3. Here is the "STING" Software technology Interest Group service. We are presented with various options as to how we would like to search for data. Let's suppose we want to know what "objective" means in "objective C". We first select STING and give "Objective" as a search word. We get back a summary of what STING has found for us.

As STING is relatively intelligent, it gives us pointers to other good places to look too. We chose the software engineering glossary entry. This, like the search results, is a "virtual" hypertext document, in that it has been generated on the fly by a server. It isn't written in a disk file anywhere. It is relatively easy to write servers to generate hypertext spaces like this, allowing complex information to be very simply presented to a user with no special skills.

We have seen how a W3 client gives access to a vast range of existing data from existing servers, but how the hypertext data from HTTP (native W3) servers is a much richer and easier to explore.

  Application server, Web server: What's the difference?

 What is the difference between an application server and a Web server?

 Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:

 A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

 Let's examine each in more detail.

The Web server

A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (Java Server Pages), Servelets, ASPs (Active Server Pages), server-side Java Scripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.

Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.

While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.

The application server

As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).

Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.

In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise Java Bean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.

An example

As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.

Scenario 1: Web server without an application server

In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.

 To summarize, a Web server simply processes HTTP requests by responding with HTML pages.

Scenario 2: Web server with an application server

Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.

In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.

By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page.

 To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.

Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.

Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won't impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.

Types of Database

 A lot of the sites that we visit on the web today are generated by a script of some description, and a great deal of them will use a database in one form or another. Like it or loathe it, building pages dynamically from databases is a technique that is here to stay.

There are two main types of database; flat-file and relational. Which is the best one to use for a particular job will depend on factors such as the type and the amount of data to be processed; not to mention how frequently it will be used.

Flat-File

 The flat-file style of database are ideal for small amounts of data that needs to be human readable or edited by hand. Essentially all they are made up of is a set of strings in one or more files that can be parsed to get the information they store; great for storing simple lists and data values, but can get complicated when you try to replicate more complex data structures.

 That's not to say that it is impossible to store complex data in a flat-file database; just that doing so can be more costly in time and processing power compared to a relational database. The methods used for storing the more complex data types, are also likely to render the file unreadable and un-editable to anyone looking after the database.

The typical flat-file database is split up using a common delimiter. If the data is simple enough, this could be a comma, but more complex strings are usually split up using tabs, new lines or a combination of characters not likely to be found in the record itself.

One of the main problems with using flat files for even a semi-active database is the fact that it is very prone to corruption. There is no inherent locking mechanism that detects when a file is being used or modified, and so this has to be done on the script level. Even if care is taken to lock and unlock the file on each access, a busy script can cause a "race condition" and it is possible for a file to be wiped clean by two or more processes that are fighting for the lock; the timing of your file locks will become more and more important as a site gets busy.

Database Management (DBM)

The Database Management Layer allows script programmers to store information as a pair of strings; a key, which is used to find the associated value. Essentially, a DBM adds more functionality and better sortation during storage to the binary flat-files that it uses. There are several versions of DBMs available, but the most popular is the Berkley Database Manager; also known as the Berkley DB.

The Berkley DB is an improvement over normal flat-files, as it provides a way for programmers to use the database without having to worry about how the data is stored or how to retrieve the values. Retrieval of data using the Berkley DB is often much faster than from a flat-file, with the time savings being made by storing data in a way that speeds up the locating of a specific key-value pair.

Creating, editing and deleting data when using the Berkley DB is actually quite simple; once the database has been tied to the script you just use and manipulate the variables as normal. The problem of file locking that plagues flat-file databases is still apparent when using DBM, so you should still take care when planning scripts that utilize it.

Relational

 The relational databases such as MySQL, Microsoft SQL Server and Oracle, have a much more logical structure in the way that it stores data. Tables can be used to represent real world objects, with each field acting like an attribute. For example, a table called books could have the columns title, author and ISBN, which describe the details of each book where each row in the table is a new book.

The "relation" comes from the fact that the tables can be linked to each other, for example the author of a book could be cross-referenced with the authors table (assuming there was one) to provide more information about the author. These kind of relations can be quite complex in nature, and would be hard to replicate in the standard flat-file format.

One major advantage of the relational model is that, if a database is designed efficiently, there should be no duplication of any data; helping to maintain database integrity. This can also represent a huge saving in file size, which is important when dealing with large volumes of data. Having said that, joining large tables to each other to get the data required for a query can be quite heavy on the processor; so in some cases, particularly when data is read only, it can be beneficial to have some duplicate data in a relational database.

Relational databases also have functions "built in" that help them to retrieve, sort and edit the data in many different ways. These functions save script designers from having to worry about filtering out the results that they get, and so can go quite some way to speeding up the development and production of web applications.

Database Comparisons

 In most cases, you would want your database to support various types of relations; such databases, particularly if designed correctly, can dramatically improve the speed of data retrieval as well as being easier to maintain. Ideally, you will want to avoid the replication of data within a database to keep a high level of integrity, otherwise changes to one field will have to be made manually to those that are related.

While several flat-files can be combined in such a way as to be able to emulate some of the behaviors of a relational database, it can prove to be slower in practice. A single connection to a relational database can access all the tables within that database; whereas a flat file implementation of the same data would result in a new file open operation for each table.

All the sorting for flat-file databases need to be done at the script level. Relational databases have functions that can sort and filter the data so the results that are sent to the script are pretty much what you need to work with. It is often quicker to sort the results before they are returned to the script than to have them sorted via a script, few scripting languages are designed to filter data effectively and so the more functions a database supports, the less work a script has to do.

If you are only working with a small amount of data that is rarely updated then a full blown relational database solution can be considered overkill. Flat-file databases are not as scaleable as the relational model, so if you are looking for a suitable database for more frequent and heavy use then a relational database is probably more suitable.

 ABOUT DATABASE USED:

 In our ms access database there are total of twelve tables used:

  1. User: This table contains two attributes username and password, both of them having their data type as text.

2. Suggestion, Share, Share the implementation (sh_imp): These tables contains a total of seven attributes s_id in suggestion, sh_id in share and sh_imp_id in share the implementation .Data type of all the three attributes is number.

Matter,subject,dated,no_of_links,deptt_id and no_of_upload are the common fields or attributes in all the three tables mentioned above ,matter is of data type memo and rest of all i.e. subject,dated,no_of_links,deptt_id and no_of_upload have their data type as text.

3.Link_s,Link_sh and Link_sh_imp: These tables contains two attributes, the links of suggestion, share  and share the implementation respectively as ‘url’ and their respective id as s_id, sh_id and sh_imp_id.Both id and url have text as their data type.

4. Upload_s, Upload_sh and Upload_sh_imp:   These tables contain two attributes, the ‘path’ of the uploaded matter and their respective id as s_id, sh_id and sh_imp_id.

Data type of id is memo and s_id, sh_id and sh_imp_id have text as their data type as text.

5. User1: This table contains three attributes deptt_id, username and password.

All of three have text as their data type.

6. Department (­deptt): This table has two fields or attributes deptt_id and deptt_name.

Text is their data type.

What Are Java Server Pages?

Put succinctly, Java Server Pages is a technology for developing web pages that include dynamic content. Unlike a plain HTML page, which contains static content that always remains the same, a JSP page can change its content based on any number of variable items, including the identity of the user, the user's browser type, information provided by the user, and selections made by the user. As you'll see later in the book, this functionality is key to web applications such as online shopping and employee directories, as well as for personalized and internationalized content.

A JSP page contains standard markup language elements, such as HTML tags, just like a regular web page. However, a JSP page also contains special JSP elements that allow the server to insert dynamic content in the page. JSP elements can be used for a variety of purposes, such as retrieving information from a database or registering user preferences. When a user asks for a JSP page, the server executes the JSP elements, merges the results with the static parts of the page, and sends the dynamically composed page back to the browser.

Generating dynamic content with JSP elements:

JSP defines a number of standard elements that are useful for any web application, such as accessing JavaBeans components, passing control between pages and sharing information between requests, pages, and users. Developers can also extend the JSP syntax by implementing application-specific elements that perform tasks such as accessing databases and Enterprise JavaBeans, sending email, and generating HTML to present application-specific data. One such set of commonly needed custom elements is defined by a specification related to the JSP specification: the JSP Standard Tag Library (JSTL) specification. The combination of standard elements and custom elements allows for the creation of powerful web applications.

Why Use JSP?

In the early days of the Web, the Common Gateway Interface (CGI) was the only tool for developing dynamic web content. However, CGI is not an efficient solution. For every request that comes in, the web server has to create a new operating-system process, load an interpreter and a script, execute the script, and then tear it all down again. This is very taxing for the server and doesn't scale well when the amount of traffic increases.

Numerous CGI alternatives and enhancements, such as FastCGI, mod_perl from Apache, NSAPI from Netscape, ISAPI from Microsoft, and Java Servelets from Sun Microsystems, have been created over the years. While these solutions offer better performance and scalability, all these technologies suffer from a common problem: they generate web pages by embedding HTML directly in programming language code. This pushes the creation of dynamic web pages exclusively into the realm of programmers. Java Server Pages, however, changes all that.

What You Need to Get Started

Before we begin, let's quickly run through what you need to run the examples and develop your own applications. You really only need three things:

·         A PC or workstation, with a connection to the Internet so you can download the software you need

·         A Java 2 compatible-Java Software Development Kit (Java 2 SDK)

·         A JSP 2.0-enabled web server, such as Apache Tomcat from the Jakarta Project

The Apache Tomcat server is the reference implementation for JSP. All the examples in the book were tested on Tomcat.

Servelets

The JSP specification is based on the Java servlet specification. In fact, JSP pages are often combined with servlets in the same application. In this section, we take a brief look at what a servlet is, and then discuss the concepts shared by Servelets and JSP pages.

Advantages over Other Server-Side Technologies

In simple terms, a servlet is a piece of code that adds new functionality to a server (typically a web server), just like CGI and proprietary server extensions such as NSAPI and ISAPI. But compared to other technologies, servlets have a number of advantages:

Platform and vendor independence

All the major web servers and application servers support servlets, so a servlet-based solution doesn't tie you to one specific vendor. Also, servlets are written in the Java programming language, so they can be used on any operating system with a Java runtime environment.

Integration

Servlets are developed in Java and can therefore take advantage of all other Java technologies, such as JDBC for database access, JNDI for directory access, RMI for remote resource access, etc. Starting with Version 2.2, the servlet specification is part of the Java 2 Enterprise Edition (J2EE), making servlets an important ingredient of any large-scale enterprise application, with formalized relationships to other server-side technologies such as Enterprise JavaBeans.

Efficiency

Servlets execute in a process that is running until the servlet-based application is shut down. Each servlet request is executed as a separate thread in this permanent process. This is far more efficient that the CGI model, where a new process is created for each request. First of all (and most obvious), a servlet doesn't have the overhead of creating the process and loading the CGI script and possibly its interpreter. But another timesaver is that servlets can also access resources that remain loaded in the process memory between requests, such as database connections and persistent state.

Scalability

By virtue of being written in Java and the broad support for servlets, a servlet-based application is extremely scalable. You can develop and test the application on a Windows PC using the standalone servlet reference implementation, and deploy it on anything from a more powerful server running Linux and Apache to a cluster of high-end servers with an application server that supports loadbalancing and failover.

Robustness and security

Java is a strongly typed programming language. This means that you catch a lot of mistakes in the compilation phase that you would only catch during runtime if you used a script language such as Perl. Java's error handling is also much more robust than C/C++, where an error such as division by zero typically brings down the whole server.

In addition, servlets use specialized interfaces to server resources that aren't vulnerable to the traditional security attacks. For instance, a CGI Perl script typically uses shell command strings composed of data received from the client to ask the server to do things such as send email. People with nothing better to do love to find ways to send data that will cause the server to crash, remove all files on the hard disk, or plant a virus or a backdoor when the server executes the command. While a CGI script programmer must be very careful to screen all input to avoid these threats, such problems are almost nonexistent with a servlet because it doesn't communicate with the server in the same insecure way.

Servlet Containers

A servlet container is the connection between a web server and the servlets. It provides the runtime environment for all the servlets on the server as defined by the servlet specification, and is responsible for loading and invoking those servlets when the time is right.

The container typically loads a servlet class when it receives the first request for the servlet, gives it a chance to initialize itself, and then asks it to process the request. Subsequent requests use the same, initialized servlet until the server is shut down. The container then gives the servlet a chance to release resources and save its state (for instance, information accumulated during its lifetime).

There are many different types of servlet containers. Some containers are called add-ons, or plug-ins, and are used to add servlet support to web servers without native servlet support (such as Apache and IIS). They can run in the same operating-system process as the web server or in a separate process. Other containers are standalone servers.

A standalone server includes web server functionality to provide full support for HTTP in addition to the servlet runtime environment. Containers can also be embedded in other servers, such as a climate-control system, to offer a web-based interface to the system. A container bundled as part of an application server can distribute the execution of servlets over multiple hosts. The server can balance the load evenly over all containers, and some servers can even provide failover capabilities in case a host crashes.

No matter what type it is, the servlet container is responsible for mapping an incoming request to a servlet registered to handle the resource identified by the URI and passing the request message to that servlet. After the request is processed, it's the container's responsibility to convert the response created by the servlet into an HTTP response message and send it back to the client.

JSP Overview

JSP is the latest Java technology for web application development and is based on the servlet technology introduced in the previous chapter. While servlets are great in many ways, they are generally reserved for programmers. In this chapter, we look at the problems that JSP technology solves, the anatomy of a JSP page, the relationship between servlets and JSP, and how the server processes a JSP page.

In any web application, a program on the server processes requests and generates responses. In a simple one-page application, such as an online bulletin board, you don't need to be overly concerned about the design of this piece of code; all logic can be lumped together in a single program. However, when the application grows into something bigger (spanning multiple pages, using external resources such as databases, with more options and support for more types of clients), it's a different story.

The way your site is designed is critical to how well it can be adapted to new requirements and continue to evolve. The good news is that JSP technology can be used as an important part in all kinds of web applications, from the simplest to the most complex. Therefore, this chapter also introduces the primary concepts in the design model recommended for web applications and the different roles played by JSP and other Java technologies in this model.

 JSP Processing

Just as a web server needs a servlet container to provide an interface to servlets, the server needs a JSP container to process JSP pages. The JSP container is responsible for intercepting requests for JSP pages. To process all JSP elements in the page, the container first turns the JSP page into a servlet (known as the JSP page implementation class). The conversion is pretty straightforward; all template text is converted to println( ) statements similar to the ones in the hand coded servlet, and all JSP elements are converted to Java code that implements the corresponding dynamic behavior. The container then compiles the servlet class.

Converting the JSP page to a servlet and compiling the servlet form the translation phase. The JSP container initiates the translation phase for a page automatically when it receives the first request for the page. Since the translation phase takes a bit of time, the first user to request a JSP page notices a slight delay. The translation phase can also be initiated explicitly; this is referred to as precompilation of a JSP page. Precompiling a JSP page is a way to avoid hitting the first user with this delay. The JSP container is also responsible for invoking the JSP page implementation class (the generated servlet) to process each request and generate the response. This is called the request processing phase.

As long as the JSP page remains unchanged, any subsequent request goes straight to the request processing phase (i.e., the container simply executes the class file). When the JSP page is modified, it goes through the translation phase again before entering the request processing phase.

The JSP container is often implemented as a servlet configured to handle all requests for JSP pages. In fact, these two containers—a servlet container and a JSP container—are often combined in one package under the name web container.

So in a way, a JSP page is really just another way to write a servlet without having to be a Java programming wiz. Except for the translation phase, a JSP page is handled exactly like a regular servlet; it's loaded once and called repeatedly, until the server is shut down. By virtue of being an automatically generated servlet, a JSP page inherits all the advantages of a servlet, platform and vendor independence, integration, efficiency, scalability, robustness, and security.

 JSP Elements

There are three types of JSP elements you can use: directive, action, and scripting. A new construct added in JSP 2.0 is an Expression Language (EL) expression; let's call this a forth element type, even though it's a bit different than the other three.

 Directive elements

The directive elements, shown in  following table, specify information about the page itself that remains the same between requests—for example, if session tracking is required or not, buffering requirements, and the name of a page that should be used to report errors, if any.

<%@ page ... %>

<%@ include ... %>

<%@ taglib ... %>

Custom action elements and the JSP Standard Tag Library

In addition to the standard actions, the JSP specification defines how to develop custom actions to extend the JSP language, either as Java classes or as text files with JSP elements. The JSP Standard Tag Library (JSTL) is such an extension, with the special status of being defined by a formal specification from Sun and typically bundled with the JSP container. JSTL contains action elements for the type of processing needed in most JSP applications, such as conditional processing, database access, internationalization, and more. This book covers all the JSTL actions in detail.

If JSTL isn't enough, your team (or a third party) can use these extension mechanisms to develop additional custom actions, maybe to access application-specific resources or simplify application-specific processing. The examples in this book use a few custom actions in addition to the JSTL actions.

 Scripting elements

Scripting elements, shown in Table, allow you to add small pieces of code (typically Java code) in a JSP page, such as an if statement to generate different HTML depending on a certain condition. Like actions, they are also executed when the page is requested. You should use scripting elements with extreme care: if you embed too much code in your JSP pages, you will end up with the same kind of maintenance problems as with servlets embedding HTML.

<% ... %>

<%= ... %>

<%! ... %>

Expression Language expressions

A new feature in JSP 2.0 is the Expression Language (EL), originally developed as part of the JSTL specification. The EL is a simple language for accessing request data and data made available through application classes. EL expressions can be used directly in template text or to assign values to action element attributes. Its syntax is similar to JavaScript, but much more forgiving; it's constrained in terms of functionality, since it's not intended to be a full-fledged programming language. Rather, it is a glue for tying together action elements and other application components. There are way too many elements of the EL to list here.

 JavaBeans components

JSP elements, such as action and scripting elements, are often used to work with JavaBeans components. Put succinctly, a JavaBeans component is a Java class that complies with certain coding conventions. JavaBeans components are typically used as containers for information that describes application entities, such as a customer or an order.

Setting Up the JSP Environment

This book contains plenty of examples to illustrate all the JSP features. All examples were developed and tested with the JSP reference implementation, known as the Apache Tomcat server, which is developed by the Apache Jakarta project. In this chapter you will learn how to install the Tomcat server and add a web application containing all the examples used in this book. You can, of course, use any web server that supports JSP 2.0, but Tomcat is a good server for development and test purposes.

 Installing the Java Software Development Kit

Tomcat 5 is a pure Java web server with support for the Servlet 2.4 and JSP 2.0 specifications. In order to use it, you must first install a Java runtime environment.

I recommend that you download and install the Java 2 SDK (a.k.a. JDK), as opposed to the slimmed-down Runtime Environment (JRE) distribution. The reason is that JSP requires a Java compiler, included in the SDK but not in the JRE.

Another alternative is to use the JRE plus the Jikes compiler from IBM. Tomcat can be configured to use Jikes instead of the javac compiler available in the Java 2 SDK from Sun; read the Tomcat documentation if you would like to try this. To make things simple, though, I suggest installing the Java 2 SDK from Sun. The examples were developed and tested with Java 2 SDK, Standard Edition, v1.4.2. I suggest that you use the latest version of the SDK available for your platform.

If you need an SDK for a platform other than Windows, Linux, or Solaris, there's a partial list of ports made by other companies.

Also check your operating-system vendor's web site. Most operating-system vendors have their own SDK implementation available for free.

Installation of the SDK varies per platform but is typically easy to do. Just follow the instructions on the web site where you download the SDK.

Before you install and run Tomcat, make sure that the JAVA_HOME environment variable is set to the installation directory of your Java environment and that the Java bin directory is included in the PATH environment variable. On a Windows system, you can see if an environment variable is set by typing the following command in a Command Prompt window:

C:\> echo %JAVA_HOME%

C:\jdk1.4.2

If JAVA_HOME isn't set, you can set it and include the bin directory in the PATH on a Windows system like this (assuming Java is installed in C:\jdk1.4.2):

C:\> set JAVA_HOME=C:\jdk1.4.2

C:\> set PATH=%JAVA_HOME%\bin;% PATH%

On a Windows 95/98/ME system, add these commands to the C:\AUTOEXEC.BAT file to set them permanently. Just use a text editor, such as Notepad, and add lines with the set commands. The next time you boot the PC, the environment variables will be set automatically. For Windows NT, you can set them permanently from the Environment tab in the System Properties tool in the Control Panel, and for Windows 2000 and Windows XP, you can do the same with the Control Panel System tool by first selecting the advanced tab and then Environment Variables.

Installing the Tomcat Server

Tomcat supports many features and configuration options. In this section, I only describe the basics that you must know to get Tomcat up and running. If you plan to use Tomcat extensively for development or as a production server, refer to Tomcat: The Definitive Guide by Jason Brittain and Ian Darwin (O'Reilly).

You can download the Tomcat server in binary format or as source code that you compile yourself. If you're primarily interested in learning about JSP, I recommend that you use the binary download for running the examples in this book and to develop your own applications. If you're a Java programmer and are interested in seeing how Tomcat is implemented, feel free to download the source as well and take a look at the internals.

On this page you find three types of builds: release builds, milestone builds, and nightly builds. Release builds are stable releases that have been tested extensively and verified to comply with the servlet and JSP specifications. Milestone builds are created as intermediary steps towards a release build. They often contain new features that aren't yet fully tested but are generally known to work. A nightly build, however, may be very unstable. It's actually a snapshot of the latest source code and may have been tested only by the person who made the latest change. You should use a nightly build only if you're involved in the development of Tomcat.

Testing Tomcat

The Tomcat installation directory contains a number of subdirectories. All of them are described in the README.txt file, but the most important ones are:

bin

Scripts for starting and stopping the Tomcat server.

conf

Tomcat configuration files.

webapps

Default  location for web applications served by Tomcat.

Two more subdirectories under the Tomcat home directory are created the first time you start the server:

logs

Server log files. If something doesn't work as expected, look in the files in this directory for clues as to what's wrong.

work

A directory for temporary files created by the JSP container and other files. This directory is where the servlets generated from JSP pages are stored.

5.4.1 JSP Comments

 JSP comment looks like:

<%-- Calculate the sum of 1 + 2 + 3 dynamically --%>

Everything between <%-- and --%> is ignored when the JSP page is processed. You can use this type of comment to describe what's going on in the page or to temporarily comment out pieces of the page to test different alternatives. Since a JSP comment is a JSP element, it's never sent to the browser.

familiar with XML syntax, you may recognize that the prefix is used as an XML namespace. You define the namespace prefix you want to use for the library with the taglib directive described earlier:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

    ...

    <c:out value="${1 + 2 + 3}" />

The prefix serves two purposes: it makes it possible for actions in different libraries to have the same name, and it makes it possible for the container to figure out to which library a specific action belongs. When the container finds an action element, it locates the taglib directive that declares the library that corresponds to the action name prefix. The taglib directive's uri attribute is a unique identifier for the tag library, which the container uses to find the information it needs to process the action.

Actions can be grouped into three categories: standard, custom, and JSP Standard Tag Library.

Standard actions are the actions defined by the JSP specification itself.Following table lists all standard actions that you can use in a regular JSP page. The JSP standard actions use the prefix jsp. Since the prefix is fixed, and the behavior for all standard actions is defined by the specification, you don't declare the standard actions with a taglib directive.

<jsp:useBean>

<jsp:getProperty>

<jsp:setProperty>

<jsp:include>

<jsp:forward>

<jsp:param>

<jsp:plugin>

<jsp:attribute>

<jsp:body>

<jsp:element>

<jsp:text>

The JSP specification also defines how to develop new actions that can be used in any JSP page. Such actions are called custom actions.

The JSP Expression Language

.

[]

(  )

? :

+

-

*

empty

func(arg)

An EL expression can also contain variables. Variables are named references to data (objects), created by the application or made available implicitly by the EL.

Accessing a Database

Almost all the web applications that you see on the Internet access a database. Databases store customer information, order information, product information, even discussion forum messages—in short, all information that needs to survive a server restart and is too complex to handle in plain-text files.

There are many types of databases used in the industry today. However, relational databases are by far the most common. A relational database uses tables to represent the information it handles. A table consists of rows of columns, with each column holding a single value of a predefined data type. Examples of these data types are text data, numeric data, dates, and binary data such as images and sound. A specialized language called Structured Query Language (SQL) is used to access the data. SQL is an ANSI standard and is supported by all major database vendors.

Relational database engines come in all shapes and sizes, from simple one-person databases with limited features, to sophisticated databases capable of handling large numbers of concurrent users with support for transactions distributed over multiple servers and extremely optimized search algorithms.

Even though they all use SQL as the data access language, the API used to execute SQL statements is different for each database engine. To help programmers write code that's portable between database engines, the standard Java libraries include an API called the Java Database Connectivity (JDBC) API. JDBC defines a set of classes that can execute SQL statements the same way in any relational database.

The complexity of databases varies extensively. A database for an online discussion forum, for instance, requires only one or two tables, while a database for a human resources system may contain hundreds of related tables. In this chapter, we look at a set of JSTL database actions you can use to build any type of database-driven web application.

But if the database is complex, you may want to use another approach: hiding the database behind application-specific beans and custom actions, or moving all database processing to a servlet and using JSP only to show the result.

Accessing a Database from a JSP Page

JSTL includes a number of actions for database access to make it easy to develop simple database-driven JSP applications. The actions provide the following features:

·         Using a connection pool for better performance and scalability

·         Supporting queries, updates, and inserts

·         Handling the most common data type conversions

·         Supporting a combination of database operations in one transaction

Using Scriptlets

The scriptlet element can be used to add a whole block of code to a page, including variable declarations. The code block must be enclosed by a scriptlet start-identifier, <%, and an end-identifier, %>.Following example shows a scriptlet that creates test data for action elements.

Example... Scriptlet creating test data (scriptlet.jsp)

<%@ page language="java" contentType="text/html" %>

<%@ page import="java.util.*" %>

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>

<%

  // Create an ArrayList with test data

  ArrayList list = new ArrayList(  );

  Map author1 = new HashMap(  );

  author1.put("name", "John Irving");

  author1.put("id", new Integer(1));

  list.add(author1);

  Map author2 = new HashMap(  );

  author2.put("name", "William Gibson");

  author2.put("id", new Integer(2));

  list.add(author2);

  Map author3 = new HashMap(  );

  author3.put("name", "Douglas Adams");

  author3.put("id", new Integer(3));

  list.add(author3);

  pageContext.setAttribute("authors", list);

%>

<html>

  <head>

    <title>Search result: Authors</title>

  </head>

  <body bgcolor="white">

    Here are all authors matching your search critera:

    <table>

      <th>Name</th>

      <th>Id</th>

      <c:forEach items="${authors}" var="current">

        <tr>

          <td>${fn:escapeXml(current.name)}<td>

          <td>${fn:escapeXml(current.id)}<td>

        </tr>

      </c:forEach>

    </table>

  </body>

</html>

The scriptlet element contains Java code that creates a java.util.ArrayList with java.util.HashMap elements and saves the list as a page scope attribute named authors by calling the setAttribute( ) method on the implicit pageScope object. The ArrayList is then used as the items attribute value in a <c:forEach> action. You can use a scriptlet like this to test the main page functionality before the real data.

JSP vs ASP

Introduction:

5-6 years back it was easy to choose a server-side language as CGI used to be only the only scripting language available. But in due course of time, the developers found out that CGI scripts were inefficient and it was very difficult to write server extensions.

 At that time, Microsoft came up with Active Server Pages (ASP), which allows developers to use simple scripting to access the server and its extensions. But ASP had some disadvantages.

It limits you to work on Microsoft platforms, and the simplest of mistakes in the script can cause the server to crash or hang, effectively bringing down your website.

In response to ASP, Sun Microsystems gave the world Java Server Pages (JSP) technology, which is entirely based on Java programming language. Internally, JSP pages are dynamically converted into Servelets, which are simply Java classes. This means JSP enjoys all the capabilities that Java programming supports.

 JSP is a great deal more efficient than many other scripting languages, such as CGI and ASP. Tags can be defined in tag libraries and then used within any JSP page.

This makes for a better separation of page content from its code, which leads to less scattered code and hence, the site is easier to maintain. Global changes need to be made only to the tags defined in these tag libraries, making time-consuming, page-by-page fixes things of the past.

JSP versus ASP

JSP and ASP have some basic concepts in common.

1) They both make use of simple sever-side scripting to provide access to Web server information and functionality.

2) They both have similar styles of delimiting this scripting from a page's content. In fact, Microsoft's has recently come up with ASP+ is much more similar to JSP than ASP.

Yet while ASP primarily supports two scripting languages, JScript and VBScript, JSP actually supports real Java code, not a new scripting language. The difference is that the Java code inside a JSP page is more script-like because it doesn't require Java class and package definitions. JScript, VBScript, and Java (in JSP) are all object oriented to some degree as they are all provided with a set of pre-established objects by the Web server that they use to generate a dynamic Web page.

 The following table lists some of the instantiated objects that are available in both ASP and JSP.

JSP ASP Definition

Request Request Access to request information.

Response Response Access to response information.

Session Session Access to session information.

Application Application Access to application information.

Out Response. Write Access to the response output stream

 Note that JSP is case sensitive. But VBScript is not.  

As I mentioned earlier, both ASP and JSP support a similar way of delimiting scripting from content on a page. <% and %> are used to set of sections of script, '<%=' and '%>' are used to return a value within content, and <%@ and %> are used to delimit page directives.

 JSP supports two basic styles of delimiting its scripting elements from page content. The first looks a great deal like ASP, whereas the second can be used to create JSP that is fully XML compliant. Here, let's examine these styles:

 Base Style XML Style Description

<%@ directive %> <jsp: directive.directive/> Directives are used to specify page information, include other files, and specify tag libraries being used.

<%! Declarative code %> <jsp: declaration>

Declarative code

</jsp: declaration>

 You can declare new methods using these tags.

<% code fragment %> <jsp: scriptlet>

Code fragment

</jsp: scriptlet>

 This code is placed within a base method of the generated servlet.

<%= code expression %> <jsp: expression>

Code expression

</jsp: expression>

 This code is appended to the output stream being returned for the page.

Conclusion

 In many ways, the biggest difference between JSP and ASP technologies lies in the approach to the software design itself.

 JSP technology is designed to be both platform and server independent, created with input from a broader community of tool, server, and database vendors. In contrast, ASP is a Microsoft technology that relies primarily on Microsoft technologies.

 Now as we have seen the advantages of JSP over ASP, I'll like to share some information on JSP with you:

 “There are a number of servers that support JSP on the market. The popular ones are Tomcat, Jrun and Enhydra.

 “Another powerful feature of JSP that we haven't covered in this article is its ability to utilize JavaBeans with special tags defined in JSP. For more information about this, you can refer to Sun's JavaBeans overview.

 An Overview of the Technology

 Comparing these two technologies is both a difficult and sensitive task but it is important to appreciate the differences in the way that the various interface, and the applications that connect to them, work.

 Java Server Pages (JSP) and Microsoft Active Server Pages (ASP) technologies provide a simplified, fast way to create web pages that display dynamically generated content. While ASP and JSP technologies are similar in many ways, they also differ significantly in some ways.

  Both the technologies follow the same model of separating programming logic from page design through the use of components that are called from the page itself. And both provide developers an easier and faster alternative to creating web applications using CGI scripts.

 The biggest difference between JSP and ASP technologies lies in the approach to the software design. ASP is based on ISAPI whereas JSP is implemented as a part of J2EE.

 ASP consists of a single DLL (asp.dll) which generates dynamic content when an ASP page with server-side script combined with HTML is parsed through it. Similarly, the JSP-enabled engine on the web server will process the JSP page, which may include technology-specific tags, declarations, and possibly Script lets in JAVA, along with HTML or XML tags.

 Here I have attempted to describe the main strengths of JSP as compared to ASP:

 ·         Portability

A Portable application environment gives organizations the flexibility to migrate servers and swap tools, as business needs change. Portability also enables developers to share their work with a wider audience.

 Java Server Pages technology delivers "Write Once, Run Anywhere" capability, offering unprecedented reuse on any platform and on any server.

 JSP is being developed through an industry-wide initiative led by Sun Microsystems and is designed to be both platform and server independent. In contrast, ASP is purely a Microsoft based technology deployed primarily on Windows NT servers.

 JSP technology was designed to support numerous servers, browsers and tools. Apache web server, which hosts more than 70/% of the websites worldwide, will now fully support the JSP technology under the Jakarta Tomcat project.

So, having to hosting a web application on a robust UNIX OS with JSP is not a distant dream. JSP is also being supported on the NT platform using third party components.

 ·         Performance

Pages built using JSP technology are typically implemented using a translation phase that is performed once, the first time the page is called. The page is compiled into a Java Servlet class and remains in server memory, so subsequent calls to the page have very fast response time whereas in ASP the page is recompiled for every request.

 JSP implementations support a Java programming language-based scripting language, which provides inherent scalability and support for complex operations.

Most JSP pages rely on reusable, cross-platform components (JavaBeans or Enterprise JavaBeans TM components) to perform the more complex processing required of the application, instead of relying heavily on scripting within the page itself. Developers can share and exchange components that perform common operations, or make them available to larger customer communities. The component-based approach speeds overall development and lets organizations leverage their existing expertise and development efforts for optimal results.

The results of a performance test (ASP vs. JSP) done by a JSP enthusiast is available for your comments - http://www.geocities.com/gslender/. Be sure the results would improve if MySQL and UNIX were used in the test configuration.

 ·         Development & Deployment Component-based Architecture

As mentioned earlier, JSP follows the model of separating programming logic from page design through the use of components like JavaBeans, Enterprise JavaBeans (EJB) and custom JSP tags.

Assuming that web page developers are not familiar with scripting languages, JSP technology encapsulates much of the functionality required for dynamic content generation in easy-to-use JavaBeans components. The page developer can instantiate JavaBeans components set or retrieve bean attributes and perform other functions that are otherwise more difficult and time-consuming to code.

Microsoft's answer to component architecture relies on COM/DCOM to supplement the ASP technology. Given the complexity involved in developing COM components in VC++ or VB, it is by no means a comparison to the simplicity of JavaBeans, which can be easily, developed using Java.

  ·         Custom Tag Libraries

The JSP technology is extensible through the development of customized tag libraries. This lets web page developers work with familiar tools and constructs, such as tags, to perform sophisticated functions. ASP does not directly support custom tags like JSP but supports XML.

 ·         MVC (Model-View-Controller) or Model 2 Architecture

Separation of Presentation and Business Logic has never been so easy with ASP or JSP. With increasing complexity the pages would clutter with Scriplets and processing code, making it hard to debug or make changes. To counter this problem, the JSP/Servlet's Model 2 architecture was introduced, providing a cleaner approach to code manageability.

This is a hybrid approach for serving dynamic content combining the use of Servelets and JSP. It takes advantage of the strengths of both technologies: JSP is used to generate the presentation layer and Servelets to perform process-intensive tasks.

 The Servlet acts as the controller processing the requests, creating beans (models) or objects used by the JSP, and depending on the user's actions, dispatches the appropriate JSP page to the user. The JSP (view) page, which contains no processing logic, is simply responsible for extracting and inserting the dynamic content from the Servlet into static templates.

Being an EX- diehard fan of Microsoft, from experience I have discovered the JSP/Servelets Technology to be more than just an answer to Microsoft's ASP technology.

Conclusion

 JSP has become more robust and scalable with the release of J2EE. With an ever-growing support for the Java technology the JSP solution is gaining prominence and immense respect from the developer community. Its time to break free from the tyranny of Microsoft and embrace the technology from the Open Source world.

 WHAT IS HTML?

Hypertext Markup Language is the basic language used to write web pages. HTML is a mark up language and not a full-blown programming language so is therefore essentially static in nature. HTML is parsed by your web browser when a web page downloads and consists of tags (commands to tell the browser how to render the text, where to load in graphics etc on the web page) as well as the actual text.

There are certain things you'll need to get started. These are...

·         A Text Editor

Any text editor. If it can save in plain (ASCII) text, it will do. This means that anything from Microsoft Word 6.0 to the DOS Edit program to Teach Text to UNIX vi will work. All it has to do is save the documents in plain, flat, unstyled ASCII-style text.

·         A Web Browser

Netscape Navigator, NCSA Mosaic, Microsoft Internet Explorer, Lynx, MacWeb/WinWeb, Cello, Chimera, Web Explorer, Net Cruiser, whatever. In fact, it's a good idea to keep more than one browser around for testing purposes (more about that later).

·         A Graphics Tool

This gets a bit trickier. Sure, you can draw pictures with no problem, but can you get them into the right format? In order to include a picture in a Web page, it needs to be in the Graphic Interchange Format (GIF). Adobe Photoshop will save indexed color files as GIF files, and there are a number of format converters on the market. Whatever you get, make sure you can get your files A Graphics Tool

This gets a bit trickier. Sure, you can draw pictures with no problem, but can you get them into the right format? In order to include a picture in a Web page, it needs to be in the Graphic Interchange Format (GIF). Adobe Photoshop will save indexed color files as GIF files, and there are into GIF.

·         A Web Server

Strictly speaking, this is optional. You can write Web pages in a text editor, save them to your machine's hard drive, and load the pages into your Web browser in order to see how they look. You don't even need a network connection to do this. The option to load pages from your hard drive is typically called something like "Open Local" (Mosaic) or simply "Open File" (Netscape).

However, if you plan to publish your documents so the rest of the world can benefit from them, you'll need to put them on a Web server. As long as you're using a Windows-based PC, a Macintosh, or a UNIX box, and it's connected to the Internet, you can set your machine up as a Web server. For example, the program Mac HTTP will let you turn your Mac into a Web server. Check around to see if you can locate something for your platform of choice.