Core JSP By Damon Hougland and Aaron Tavistock - Part4

Couple of Days back i started reading Core JSP By Damon Hougland and Aaron Tavistock.

Nice book written by Damon Hougland and Aaron Tavistock.

Few important quotations i wanted to share from next two chapters (7-8).

1) JSP is typically used to create HTML or XML pages that are delivered using HTTP.Previous chapters have gone through heavy discussions on HTTP requests and responses. One of the limitations of HTTP is that it is a stateless and connectionless protocol. This means that the protocol has no recollection of any transaction that occurred in the past. Each new request from the client creates a whole new transaction that has no relation to any past, concurrent, or future transaction. The client makes a request, the server completes the request to the best of its abilities, and then the transaction is completed and finished.

2) Hidden form fields are one of the oldest methods of preserving state information that is still in use today. The fact that it is still in use seems to indicate that it fills an important need, in particular where the task is not complex but still needs to keep some "state" information. A common case where this might used would be where a user must fill the form that is mailed to the webmaster. If the user forgets an important field it can be specifically requested on the next "page;" all of the previous data is stored on the same page unbeknownst to the user.

3) Hidden Frames

Another means of getting the client to preserve and send state information is using hidden frames. Implementing hidden frames is outside the scope of this book, but understanding how they work adds perspective to other methods.By using a client-side scripting language and the browser's Document Object Model it is possible to retrieve and store data from any frame on a browser. It is also possible to create frames that are not seen by the user. Combining these two ideas allows a page author to create a hidden frame that can be used by the developer as a "scratch pad" to add and remove information as needed.Using hidden frame fields results in an extremely flexible way of preserving state.Unfortunately, not all browsers support hidden frames, and browsers that do support hidden frames often behave differently.Overall, getting hidden frames to work properly can be a complex combination of client-side and server-side programming that can quickly become daunting and overwhelming.

4) URL Rewriting

State information can also be preserved by dynamically changing the URL that a user might click on. There are several ways that the URL can be modified and used to include extra information about the transaction.

State information can be put into the URL as standard HTTP GET parameters, for example:
http://www.javadesktop.com/catalog?category=books

The same general idea can be applied using a custom separator that is recognized by the server but different from the standard HTTP GET separator.
http://www.javadesktop.com/catalog;category=books

Alternatively, the path information can be parsed by indicating a real page and a separate parameter, for example:
http://www.javadesktop.com/catalog/books
where catalog is the page, and books is the parameter.

Ultimately, URL rewriting has similar advantages and disadvantages to using hidden form fields. One advantage is that URL rewriting can change information that does not reside within a form. Additionally, when used with a session ID less data is transferred with each transaction. Unfortunately, URL rewriting is significantly more complex to implement.

URLs are limited in length, so URL rewriting can be limited in the amount of information it can include. This is where session IDs tend to become extremely important. Most URL rewriting in use will add only one parameter, a session ID.

5) Cookies

Cookies are undoubtedly the most efficient and effective way to store state. In fact, all of the previous listed methods are attempts at using preexisting facilities in new ways to preserve state. Cookies are the only method that is expressly designed from the ground up for preserving information about the state of the client.

6) The HttpSession API

The actual work of managing sessions using a session ID is a complex task. It involves generating unique keys that must be encoded properly, storing data transactions, and expiring sessions that are too old. Then notable parts from each transaction need to be stored in some internal database and be readily available when given the session ID key.

Fortunately there are methods built into the JSP API that will manage sessions. The API takes almost all the complexities of handling sessions and makes them into a simple and elegant interface that is easy to implement.

7) Using the Session Object

By default, JSPs have session tracking enabled and a new HttpSession object is instantiated for each new client automatically. There is nothing special that the JSP author needs to do to enable session tracking. In fact, actually disabling session tracking requires explicitly turning it off by setting the page directive session attribute to false:

<%@ page session="false" %>

The JSP engine exposes the HttpSession object to the JSP author through the implicit session object. Since this object is already provided to the JSP author, the author can immediately begin storing and retrieving data from the object without any initialization or getSession().

8) A JavaBean is basically a standard Java class that adheres to a set of fairly simple design and naming conventions. A JavaBean defines its exported methods and objects in a standardized naming convention that can be easily derived by the calling application. This provides a programmatic entry (interface) into the JavaBean without understanding how the JavaBean works internally.

There are actually no requirements for a JavaBean to extend or super class any other object. Any class that follows the JavaBean conventions is a JavaBean. The true essence of creating new JavaBeans is really a programming paradigm more than calling specific API methods.

The JavaBean API does provide a simple container class that knows how to expose these properties in special ways to create interfaces. This is really not relevant to the JSP author or JavaBean developer. The JavaBean API really applies to applications
that "handle" JavaBeans, such as "Bean boxes" or the JSP engine itself.

9) What is LDAP?

Lightweight Directory Access Protocol (LDAP) is a common directory service used by many large companies. It's derived from the older directory service standard X.500.

To avoid conflicts with these services, Enterprise Beans are explicitly restricted from performing operations involving managing threads, using any file services in java.io, listening on sockets, or using native libraries.

Also, since Enterprise JavaBeans are typically used to represent business logic and processes, it's very common for an Enterprise JavaBean to have restrictions on the type of presentation it can make. For example, Enterprise JavaBeans are explicitly restricted from manipulating AWT components.

JavaBeans are a powerful programming addition to Java, and their use in JSP pages helps migrate Web programming to a component model. JavaBeans serve as the business logic layer while JSP pages act as presentation logic. In this way more scaleable and powerful Web applications can be built.

About the Authors

DAMON HOUGLAND is a Program Manager and Technical Architect for eFORCE, Inc., where he designs and develops Java enterprise applications. Previously Damon led the Web Application Infrastructure team at Lawrence Berkeley National Laboratory, which specialized in reporting scientific data through web-enabled databases and applications. He has worked as a software developer and technical manager over the last nine years.

AARON TAVISTOCK has over 10 years of experience with UNIX systems and application development. He has used his extensive knowledge of Java, JSP, and taglibs to create a leading edge web application compiler. Aaron is currently the Web Compiler Architect for Snapshop.com, Inc., a provider of B2B2C (business-to-business-to-consumer) web applications.