| home / programming / java_server / 1 |   [previous] |
|
|
|
HTTP is great for serving up static content, and web servers excel at that function out of the box. But creating dynamic content requires writing code. Even though HTTP is simple, it still takes some work to write programs that work with it. You have to parse the headers, understand what they mean, and then create new headers in the proper format. That’s what the Java Servlet application programming interface (API) is all about: providing an object-oriented view of the world that makes it easier to develop web applications.5 HTTP requests and responses are encapsulated as objects, and you get access to input and output streams so that you can read a user’s response and write dynamic content. Requests are handled by servlets—objects that handle a particular set of HTTP requests.
A standard J2EE web application is, by definition, based on the Servlet API. Servlets run inside a container, which is essentially a Java application that performs all of the grunt work associated with running multiple servlets, associating the resources grouped together as a web application, and managing all sorts of other services. The most popular servlet container is Tomcat [ASF, Tomcat], but J2EE application servers such as IBM WebSphere [IBM, WAS] and the Sun Java System Application Server [Sun, JSAS] provide servlet containers as well.
As we mentioned in the previous section, one of the big problems with HTTP is that it’s stateless. Web applications get around this problem through the use of
sessions—they make it seem as if the users are always there, even if they’re not. Sessions are one of the biggest benefits that the Servlet API provides. Even though behind the scenes they make use of cookies or URL rewriting, the programmer is shielded from those complexities.
The Servlet API also provides lots of other goodies, like security, logging, lifecycle events, filters, packaging and deployment, and so on. These features all form the base of JavaServer Faces. As a matter of fact, JSF is implemented as a servlet, and all JSF applications are standard J2EE web applications.
JSF takes things a bit further than the Servlet API, though. Servlets cover the basic infrastructure necessary for building web applications. But at the end of the day, you still have to deal with requests and responses, which are properties of the underlying protocol, HTTP. JSF applications have UI components, which are associated with backing beans and can generate events that are consumed by application logic. Faces uses the Servlet API for all of its plumbing, but the developer gets the benefit of working at a higher level of abstraction: You can develop web applications without worrying about HTTP or the specifics of the Servlet API itself.
Most web applications serve dynamic content from a data store—usually a database. (Even if the business logic is running on another type of server, like an EJB or Common Object Request Broker Architecture [CORBA] server, eventually some code talks to a database.) Since the early days of the Web, however, there has been a need for software that aggregates information from different data sources into an easy-to-use interface. These types of applications, called portals, were originally the domain of companies like Netscape and Yahoo! However, more and more companies now realize that the same concept works well for aggregating information from different internal data sources for employee use. So a variety of vendors, including heavyweights like IBM, BEA, and Oracle, offer portal products to simplify this task. Each data source is normally displayed in a region within a web page that behaves similarly to a window—you can close the region, customize its behavior, or interact with it independent of the rest of the page. Each one of these regions is called a portlet.
Each of these vendors developed a completely different API for writing portlets that work with their portal products. In order to make it easier to develop portlets that work in multiple portals, the JCP developed the Portlet specification [Sun, Portlet], which was released in late 2003. All of the major portal vendors (including Sun, BEA, IBM, and Oracle) and open source organizations like the Apache Software Foundation have announced support for this specification in their portal products.
The Portlet specification defines the Portlet API, which, like the Servlet API, defines a lot of low-level details but doesn’t simplify UI development or mask HTTP. That’s where JSF comes into the picture; it was developed so that it can work with the Portlet API (which is similar in many ways to the Servlet API). You can use ordinary JSF components, event handling, and other features inside portlets, just as you can inside servlets.
NOTE Throughout this book, we mostly talk about JSF in relation to servlets. However, most of our discussions apply to portlets as well.
Quite a few Java web developers think that JavaBeans are simply classes with some properties exposed via getter and setter methods (accessors and mutators). For example, a Java class with the methods getName and setName exposes a readwrite property called name. However, properties are just the tip of the iceberg; JavaBeans is a full-fledged component architecture designed with tool support in mind.
This is significant, because it means there’s a lot more to it than just properties. JavaBeans conform to a set of patterns that allow other Java classes to dynamically discover events and other metadata in addition to properties. As a matter of fact, JavaBeans is the technology that enables Swing and makes it possible for IDEs to provide GUI builders for desktop applications and applets.
Using JavaBeans, you can develop a component that not only cooperates nicely with a visual GUI builder but also provides a specialized wizard (or customizer) to walk the user through the configuration process. JavaBeans also includes a powerful event model (the same one used with Swing and JSF components), persistence services, and other neat features.
Understanding the power of JavaBeans will help you comprehend the full power of JSF. Like Swing components, every JSF component is a full-fledged Java- Bean. In addition, Faces components are designed to work with backing beans— objects that are implemented as JavaBeans and also handle events.
If you’re just planning to write application code or build UIs, then a basic knowledge of JavaBeans (mutators and accessors) is sufficient. If you’re going to be developing custom components, a deep understanding of JavaBeans will make your life much easier.
Servlets are great low-level building blocks for web development, but they don’t adequately simplify the task of displaying dynamic content. You have to manually write out the response to every request.
Let’s say that every line of HTML you were sending was written as a separate line of Java code. You have about 30 pages in your application, and each page has about 80 lines of HTML. All of the sudden, you have 2400 lines of code that looks a lot like this:
out.println("This is a really repetitive task, and \"escaping\"" +
" text is a pain. ");
This is really tedious work, especially because you have to escape a lot of characters, and it’s hard to quickly make changes. Clearly there has to be a better way. To solve this problem, Sun introduced JavaServer Pages (JSP) as a standard template mechanism. JavaServer Pages look like an HTML page, but they have special tags that do custom processing or display JavaBean values, and can also have Java code embedded in them.6 Ultimately, they behave like a servlet that looks a lot like the previous code snippet. The JSP translator does the boring work so that you don’t have to.
You can create your own custom tags7 to perform additional processing (such as accessing a database), and there’s a useful set of standard tags called the Java- Server Pages Standard Tag Library (JSTL) [Sun, JSTL]. The idea is that you can define the UI with HTML-like tags, not Java code.
Even though JSP is the industry standard display technology, you can choose among many alternatives. You could use a full Extensible Markup Language/ Extensible Style Sheet Language Transformations (XML/XSLT) approach with something like Cocoon [ASF, Cocoon], or a stricter template-based approach like Velocity [ASF, Velocity] or WebMacro [WebMacro]. Many other options are available as well.
One of the key design goals of JSF was to avoid relying on a particular display technology. So JSF provides pluggable interfaces that allow developers to integrate it with various display technologies. However, because JSF is a standard Java technology, and so is JSP, it’s no surprise that Faces comes with a JSP implementation (via custom tags) right out of the box. And because JSP is the only display technology that must be integrated with JavaServer Faces, most of the examples in this book use JSP as well.
| home / programming / java_server / 1 | [previous] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: November 23, 2004
URL: http://webreference.com/programming/java_server/1
