- Written by members of the team responsible for the creation and evolution of JRun, the first commercial JSP server
- JSP combines the promise and power of Java with the ease-of-use and minimal learning curve of a scripting language
- JSP is supported by leading application servers such as IBM, Allaire and others
|Product dimensions:||7.34(w) x 9.10(h) x 0.99(d)|
Read an Excerpt
In this chapter we will go through some Internet and World Wide Web basics, recapping some of the Web's past to bring us up to date quickly. Then we will discuss Java, the basis for everything in JSP. If you are interested in the Java programming language, then JSP is a great way to start learning it. If you aren't, then you don't have to learn it. There is a lot you can do with JSP without knowing Java, although this will be truer in the near future than it is as we are writing this book.
Internet and World Wide Web Basics
One crucial distinction to make in understanding the World Wide Web's history is between the Internet and the Web. They aren't exactly the same thing, nor are they the same age, though a common perception is that they are. Learning this distinction is a good basis for any budding Web developer. If you are already wise to this distinction and the history of the Web, please bear with us for a moment.
The Internet began inthe late 1960s as a small network of computer systems run by the United States Department of Defense. The original name for the network was ARPANET, which stood for Advanced Research Projects Agency Network. Over the years, the network extended to American universities and colleges, then international ones. Email, telnet, Usenet newsgroups, Ethernet, FTP, and a host of other Internet fixtures were invented and developed in the 1970s. Corporations built their own private networks while the government and communications companies expanded and interconnected the original ARPANET and other networks. By 1990, TCP/IP, NNTP, DNS, and IRC had all been invented. But the Internet, as it had been known since the early 1980s, was home primarily to the military, scientists, students/researchers, and serious computer geeks.
The World Wide Web
In the early 1990s, Tim Berners-Lee, a scientist at the CERN physics research center in Switzerland, began developing a software application for visually rendering documents transferred over the Internet. He worked on this graphical tool while also contributing to the development of two related technologies. One was Hypertext Transfer Protocol (HTTP), a simple protocol layered over the existing TCP/IP protocols that had been the basis for Internet communication since the early 1980s. The other was a simple derivation of SGML (Standard Generalized Markup Language) called Hypertext Markup Language (HTML), which allowed documents and other information to be formatted, linked and cross-referenced in a very userfriendly way across the Internet. Thus was born the World Wide Web, which was the original name for this software application. The World Wide Web browser/editor originally ran only on NeXT computers, and the first full alpha version wasn't released until 1993.
You can see that the World Wide Web as we know it has only existed since 1993 at the earliest. The Internet far precedes the Web. But the interesting thing is that, as soon as HTML, HTTP, and a Web browser became available, the World Wide Web took off like a rocket, and the Internet provided the foundation.
Web Browsers and Web Servers
The National Center for Supercomputing Applications (NCSA), University of Illinois, UrbanaChampaign, was a hotbed of activity for World Wide Web development. The NCSA developed a Web browser called Mosaic that quickly became widely used. It seemed that putting a user interface on the Internet suddenly made it much more accessible. Eventually, Marc Andreessen, who led NCSA's Mosaic team, started up a company called Netscape and developed a Web browser we all know as Navigator.
Also at the NCSA was one of the first and most popular pieces of Web server software, called httpd, for Hypertext Transfer Protocol Daemon. A Web server was originally a simple but necessary piece of client/server software used to send responses to client requests for HTML documents. However, soon an interested party of Webmasters and budding Web server developers got together and coordinated their efforts to patch and extend the original httpd, developed by Rob McCool at NCSA. This little group, founded by Brian Behlendorf and Cliff Skolnick, wound up calling its server Apache, because it was a cool-sounding pun that described their "patchy" server. Now Apache is the most widely used Web server on the Internet. Apache and other popular servers such as Microsoft's Internet Information Server (IIS) and Netscape's iPlanet do far more than just manage the transfer of text documents over the Internet.
Web servers typically perform user authentication, datastream encryption (using Secure Sockets Layer (SSL)), and dynamic content generation. This last capability is where servlets, JavaServer Pages, and a host of other technologies come into play. Some technologies, such as Perl and ASP, extend the server via pluggable components that can be tied tightly to the Web server by integrating with its native application programming interface (API). Others are tied more loosely to the Web server but handle special processing for the server and hand back results via the common gateway interface protocol (CGI).
To the user, all this processing is transparent. The only inkling most users have of how a Web server is doing its work is by watching the URLs in the browser. For example, if you see files being served with a .cfm extension, then the server is using Allaire's ColdFusion application server. If you see . php, they are PHP pages. If you see . asp, those are Microsoft's Active Server Pages. If you see https:// instead of http:// in the URL, then you know the connection you are currently making to the server is SSL encrypted, and so on. Static content is still prevalent, but dynamic content is here to stay. Most Web sites are a combination of the two.
Client/server computing has been a great success. It's a distributed approach to computing, allowing for easier distribution of computing resources across a network. The "old" way of enterprise-level computing was that of connecting lots of "dumb terminal" clients directly to the mainframe. Mainframes are massive and powerful computers capable of handling thousands of simultaneous users at a time. The earliest business computers were mostly mainframes, often filling an entire room. Now mainframes are about the size of refrigerators, but they are still incredibly powerful. Mainframes probably aren't going anywhere. There are too many computers with major investments in them and thousands upon thousands of custom programs written for them. Most major companies use mainframes or somewhat smaller computers called midrange computers for their critical business data and systems.
Nevertheless, there is a need to "Webify" nearly everything in business these days. Whether it's business-to-business (for example, Ford ordering engine parts from one of its automotive parts suppliers) or business-to-consumer (for example, you buying books online from www. books. com), every business needs to integrate its data and business systems with other people and businesses across the country and the world.
There is a huge area between the client's PC and the enterprise's mainframes or databases, referred to as the "middle tier." The middle tier can pretty much consist of anything that helps get data from one place to another. Some sort of processing needs to happen, especially when that data needs to go from a large warehouse-like repository to an end user. Data in its raw form is usually pretty ugly. A user likes to see his online shopping cart represented as a little icon he can click on; he likes to click on buttons and see data organized visually into colorful tables on the Web. The middle tier is where intermediate systems process raw data (whether it's stored in hexadecimal, ASCII, or binary form) from databases into nice-looking Web pages.
Likewise, when you are shopping on mm. amazon. com, browsing a public library's holdings online, or retrieving your bank statement via an online banking system, the user interface that makes navigation and interaction (hopefully) intuitive to you is all bells and whistles. Behind the scenes, it's all bits and bytes, abstracting the raw data away from the user interface again and storing it in a database, usually after some sort of business logic has been applied to it.
When Web servers were first being extended to do more than just serve HTML pages, there was no connection to enterprise systems-no middle tier. But that soon changed. Web servers became the front line of larger back-end systems that handled business processing for Webbased clients. It made sense to use the popular World Wide Web for retail business as well as business-to-business transactions. Web servers couldn't handle all the work, so extensions were written. The extensions evolved into the middle tier. The whole application on the server side, from handling the business process from the Web server to the database and back, started being called an application server.
Application server is a rather vague term. For some people it refers to the whole back end of their Web site, including all the various components and containers, from the server software to the middleware to the database. Microsoft ships products that it calls "servers," which has probably helped confuse the issue. When you buy Microsoft's Back Office Server, you get a Web server (IIS), database (SQL Server), messaging server (Exchange), and more. It's all one huge package. The main disadvantage to this scenario is that everything resides on one system, provided by one vendor, written to proprietary APIs. And in the case of Windows, you have both vendor lock-in and platform lock-in.
Others take the term application server to refer to any piece of middleware that's sophisticated enough to provide everything you need for connecting your Web server to your database and other back-end components. These application servers tend to be more modest than Microsoft Back Office. They shoot for a different market, aiming to fill in the gap between server and enterprise rather than to be a complete drop-in solution. Examples of these sorts of application servers include ColdFusion Application Server, PHP, and any server that's branded as J2EE, the Java 2 Enterprise Edition.
Sometimes these application servers plug directly into your Web server as if they were Web server extensions. ColdFusion and PHP are like that. Others, like Orion and JRun, can plug into your Web server or run standalone and receive requests directly from clients. The key advantages of these kinds of application servers are that they do not lock you into a single vendor for your total server-side business solution, and they typically run on multiple platforms. ColdFusion, for example, runs on Linux, Solaris, HP-UX, and Windows. A pure Java J2EE implementation will run on any platform that has a Java 2 JVM...
Table of ContentsIntroduction.
What You'll Learn.
1. Understanding JSP.
The Internet. The World Wide Web. Web Browsers and Web Servers. Application Servers. Components, Containers, and Connectors.
The Java Advantage.
Understanding Java. The Java Virtual Machine. Java Terminology.
JSP and Servlets. Putting Java to Work.
2. Creating a JSP Page.
Hello World. Getting the Request. Translating the Page.
Viewing the Source.
JRun. Resin. The Jakarta Project.
Understanding Access Models.
Understanding the Model-View-Controller (MVC) Pattern.
A Quick History Lesson on MVC. WYSIWYG Example. Web Application Example.
The page Directive. The include Directive. The taglib Directive.
Commenting Your Code.
Source Comments. Hidden Comments.
3. Using Scripting Elements.
Using Strings in Expressions. Using Methods and Constructors in Expressions.
Java's Primitive Data Types. Java's Operators. Creating a Hit Counter in JSP. Creating a Table Using a JSP Declaration.
4. Using Available Objects.
Understanding Object Instantiation. Relating JSP to Servlets, CGI, and HTTP. Understanding the Java Reflection API. Understanding Inheritance. Using the exception Object. Viewing the Class Hierarchies of All the Implicit Objects. Understanding Encapsulation. Using Reflection to Introspect the Implicit Objects. Understanding Scope. Understanding the Scope of the JSP Implicit Objects.
5. Using Beans.
Accessor/Mutator Methods and the No-Argument Constructor. Writing Your Own JavaBeans. Using JSP Standard Actions and JavaBeans.
Using JavaBeans in JSP.
Creating a Hit Counter in JSP. Creating a Quote Randomizer in JSP. Creating a Message Board Web Application in JSP.
6. Connecting Pages.
Constructing a URL. Scheme: request.getScheme(). Server Name: request.getServerName(). Port Number: request.getServerPort(). Script Name: request.getRequestURI(). Filename and Extension: request.getServletPath(). Query String: request.getQueryString(). HTML Anchor: Client-Side Functionality.
Using the GET Method. Using Query Strings.
Generating Query Strings. Processing Query Strings. Escaping URLs.
Linking JSP to HTML, JSP, and Servlets with
Forwarding to HTML and JSP. Forwarding to Servlets.
7. Working with Forms.
8. Interacting with Databases.
Type 1: JDBC-ODBC Bridge and ODBC Driver. Type 2: Native-API Partly Java Driver. Type 3: JDBC-Net Pure Java Driver. Type 4: Native Protocol Pure Java Driver.
Creating Your Database. Connecting to a Database. Executing SQL Statements
9. Securing Your Applications.
Protecting Your Server. Protecting Your Data. Protecting Your Users. Protecting Your Application.
Rolling Your Own Authentication. Form-Based Authentication. HTTP Challenge and Response.
The Java Naming and Directory Interface (JNDI). LDAP Integration.
Implementing Access Control.
Using a Text File for Authentication. Using LDAP Authentication. Using Servlet 2.2 Web Application Security.
10. Managing Session States.
Setting Simple Values into the Session Scope. Saving Complex Data Types in the Session Scope. Managing the Session.
Using Embedded URLs (Rewriting). Using Cookies. Using Hidden Form Fields. Summary.
11. Integrating with Email.
Creating javax.mail.Session. Using javax.mail.Transport. Composing javax.mail.Message. Connecting to javax.mail.Store. Using javax.mail.Folder. ColdMail.com: A JSP and JavaMail Case Study. Introduction to Tag Extensions
12. Developing Custom Tags.
Defining a Tag. CFML Tags.
Developing Simple Tags: No Attributes or Body Content.
Obtaining the JSP and Servlet APIs. Understanding a Basic Tag Handler. Understanding the Tag and BodyTag Interfaces. Understanding the TagSupport and BodyTagSupport Classes. Writing Our First Tag Handler.
Developing Complex Tags: Adding Attributes and Evaluating Body Content.
A Tag for Retrieving and Formatting Syndication Content.
Existing JSP Tag Library Projects.
JRun Tag Library from Allaire Corporation. Orion Tag Libraries from Orionserver. Taglibs Project from Jakarta.
13. Interacting with Enterprise JavaBeans.
The Container. The Remote Interface. The Home Interface. The Bean Implementation.
Stateless Session Beans. Stateful Session Beans.
Container-Managed Persistence. Bean-Managed Persistence. An Entity Bean Example.
Implementing Enterprise JavaBeans.
Interacting with an Entity Bean. Interacting with a Stateless Session Bean. Interacting with Stateful Session Beans.
14. Handling Errors.
The try Block. The catch Clause. The finally Block. Bubbling Up. Runtime Exceptions. Throwing Exceptions.
Using Error Pages. Summary.
15. Debugging and Troubleshooting.
Non-Compliant Containers. Deploying Your JSPs, Beans, and Servlets. Port Conflicts. Properties and Configuration Files. Using Logs.
Java Virtual Machine Problems.
Getting an OutOfMemoryError. Getting a NullPointerException. Getting a NoClassDefFoundError. Unresponsive JSP Containers. Getting Dr. Watsons or Core Dumps.
Choosing the Best JDBC Driver. Performance and Profiling Tools.
Using IDEs to Code and Debug JSPs.
Appendix A. JSP Syntax.
Appendix B. Using Popular JSP Servers.
Appendix C. Using Java Methods to Retrieve CGI Environment Variables.