JSP Design Notes
White Paper Sections
Introduction to JSP Design Notes
Java Server Pages (JSP's) permit server side Java logic to reside within the requested document. Upon request of a JSP document the server activates the specified JSP. The JSP then becomes responsible for providing an HTML response.
The server side logic within a JSP is written in Java. The Java code segments, referred to as scriptlets, are generally responsible for providing dynamic HTML content to the JSP's response HTML. The JSP itself is compiled by the server, and is executed as an object that extends the Java Servlet API. As such, the HTTP Servlet request and response objects are available by the scriptlets defined within the JSP.
This document reviews client-server design considerations in respect to the use of JSP抯. Implementation options, particularly the use of JSP language extensions and use of Enterprise Java Beans (EJB's) will also be discussed. Focus will be placed on the presentation layer and how the JSP is used to provide a user interface and communicate business logic requests to the supporting system.
If we consider a 3-tier architectural WEB application, the browser becomes the client side application. The user communicates requests to the WEB/app server via the browser. The presentation layer receives the client requests and prepares the response and server side business functionality is executed. In the context of this example, the JSP engine represents the presentation layer. It is responsible for processing requests and responses. Additional messages may be passed between this layer and that which handles business processes represented below as EJB抯.
The Technology
JSP technology uses XML - like tags and scriptlets. They are used to encapsulate presentation logic within the JSP. They can also initiate messages to distributed or server-side applications. The logical separation of presentation and business logic lies in the implementation of the JSP.
Enterprise Java Beans provide a distinct relationship between the implementation of business logic and the remote interfaces provided to the EJB client. The use of an EJB typically follows the pattern:
- The client application identifies itself to the server
- The client application uses the Java Naming Directory service to locate the desired EJB
- The client application retrieves a handle to the EJB Home and subsequently Remote interfaces.
The remote interface contains methods that the client is permitted to use. They represent a summary of the business logic that is implemented by the bean. The implementation logic is defined within the primary bean class. All IPC, database and resource details are restricted to the bean class.
Prevalent Application
Design constraints and conventions maintain the separation of presentation logic from business logic in the middle tier. Prior to JSP 1.1, a JSP implementation using EJB's might have included various scriptlet sections performing EJB remote interface logic/communication.
Consider the example below:
The JSP is designed to provide a welcome message to an e-commerce user. Assume the request included an HTML name-value pair that identified the (pre-registered) Customer ID.
<html> <title>E-commerce Site</title> <body> <% String CustomerName; String CustomerCompany; String customerID; customerID = (String) pageContext.getRequest().getParameter("CustID"); Context ctx = getContext("some.ejb.jndi.name"); EJBHome home = (EJBHome)ctx.createHomeInterface(); EJBRemote remote = (EJBRemote)home.findCustomer(customerID); CustomerName = remote.getCustomerName(); CustomerCompany = remote.getCustomerCompany(); %> Welcome <%=CustomerName%> we look forward to processing your needs. <br> <%=CustomerCompany%> is one of our favorite companies to work with. </body> </html> |
The resulting JSP is a hybrid of scripting logic and html. In constructing a JSP document, the creation of the HTML base is a prudent step. It becomes the visual template that JSP scriptlets are merged into. The post execution HTML produced from the completed JSP should be that of the original HTML document. With the exception of comment, dynamically generated HTML sections and JSP content substitutions. The scripting logic, except for where desired, is completely non visual in regard to the response HTML text.
The construction of the HTML layout conceivably begins with a Web developer. The creation of the JSP pages would be similar if not identical to the methods used to construct industry HTML pages. The next step would be the addition of JSP specific logic to identify the sections of the HTML that might be generated dynamically. This conversion step from pure HTML to JSP is where server side logic is added to the page.
A completed JSP logically embodies presentation layer services and business functionality. Physically they are blended within the JSP in an as needed swapping of HTML and JSP code. Continued maintenance of the application and changes in the business logic need not affect the presentation layout. Likewise, changes in the presentation layout need not affect the scriptlet logic, it will however require that the WEB developer, not necessarily a JAVA programmer, show care in the handling of this file which is no longer pure HTML should any HTML maintenance become necessary.
The Alternative
A design consideration intended to reduce the complexity of maintaining the HTML aspect of a JSP is to minimize the use of scriptlets in constructing a JSP. Custom tags, introduced in JSP 1.1, can equally produce the functionality provided by JSP scriptlets.
Custom tags are application defined language extensions to Java Server Pages. Custom tags can be used within a JSP in the following ways:
- to produce html output
- to produce JSP output (JSP expressions, directives, ...)
- to create objects
- to define objects that can be seen as scripting variables within the parent JSP
- to iterate over a body of JSP/HTML text in a finite manner
- to determine if section of the calling JSP should be processed or skipped
The goal of using custom tags to minimize the presence of scriptlets is to produce a more HTML ?like JSP. The advantages of this goal are self-evident if we consider projects that expect frequent HTML modifications. Assuming the business logic, pre-presented by the JSP tags, is stable it can be identically merged into various forms of the HTML layout, without explicitly inserting duplicate sections of scriptlet logic (Java code).
Tag handlers implement JSP custom tags. One or more tag handlers can be listed in the Tag Library Descriptor files. References to these files are included in the JSP that intends to use a given tag handler. The tag handler itself is implemented as a Java object that extends the JSP body. Upon execution it has access capabilities to the JSP's Http servlet objects, page attribute and session attribute objects. It can, conceivably, provide a full HTML response to the client in the way that servlets operate. A significant distinction from Java Server Pages is that tag handlers are not designed to be dynamically compiled by the server.
In respect to EJB's, a tag handler accesses an EJB in the same manner as the above scriptlet. It can additionally make available any object it creates, available to other tag handlers and JSP抯. This is accomplished by the use of storage methods that operate within the scope of the page and session. This includes the retention of EJB remote interface objects that can be created once and re-used by subsequent JSP抯 via scriptlets or tags.
The previous JSP example implemented using custom tags might appear as follows:
<%taglib declaration; prefix=tagpre%> <html> <title>E-commerce Site</title> <body> <tagpre:lookupCustomer> Welcome <%=CustomerName%> we look forward to processing your needs. <br> <%=CustomerCompany%> is one of our favorite companies to work with. </tagpre:lookupCustomer> </body> </html> |
As stated previously, the JSP engine and Java Server Pages logically produce presentation layer services. They also provide the interface to business services (i.e. EJB抯). The physical separation of the logic associated with these middle tier components is evident in the above example. The same EJB logic in the previous example is represented here by the tag references.
Figure 2 gives a graphical representation of the physical control flow without the use of custom tags. The client initiates execution with a JSP request. The request via URL is directed to the WEB server that is responsible for servicing such requests. The JSP request triggers the JSP engine to locate and execute the corresponding JSP as a servlet object. The execution of the business logic is represented by the use of Enterprise Java Beans.
Logically identical, figure 3 illustrates the use of tag handlers by the JSP. This is the hidden logic implied in HTML example 2.
The JSP engine, in both figures, treats the compiled JSP object as a servlet object. Figure 3抯 tag handler object extends the JSP page body. This relationship grants tag handler access to various servlet attributes. These attributes therefore permit the tag handler to conceivably inspect parameters passed by the client.
Conclusion
As with other tools of the trade, innovations and nuances to existing tools do not invalidate existing design methodologies. They do however provide new versatility and the expansion of possibilities with regard to application design.
Custom tag extensions, in contrast to standard tags, provide the application builder the ability to define custom tags to satisfy some functionality not provided by the standard API. To benefit by using tag extensions to reduce the amount of Java functionality that the JSP API provides, might seem oxymorinic, and it is. With the exception of dynamically compiled JSP抯, the functionality provided by the two given examples are identical, which suggests that the payoff for implementing this server side alternative is purely cosmetic, and it is.
While a server side application designer does not typically consider the cosmetic aspect of implementing source code, JSP source code might prove to be the exception. It does after all suggest the strong possibility that a Web/HTML developer perform the continued maintenance of the HTML portion of the JSP. This is a role, of course, traditionally allied with client side responsibilities.
The nuances introduced by JSP custom tags present nuances in the maintenance of JSP抯. The arguments presented here presume that the HTML produced by the JSP抯 in discussion are non-trivial HTML documents, although non-complex HTML documents may benefit from similar design considerations.
~end of Aurora Information Systems' White Paper Series #9
"JSP Design Notes"~
5921
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
