JSP Design Notes

原创 2004年07月09日 14:12:00

JSP Design Notes


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抯.

3-tier architectural web application

Return to Top of Page

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.

Return to Top of Page

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.

Return to Top of Page

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.

physical control flow without the use of custom tags

Logically identical, figure 3 illustrates the use of tag handlers by the JSP. This is the hidden logic implied in HTML example 2.

illustrates the use of tag handlers by the JSP

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.

Return to Top of Page


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"~


46. Lotus Notes中编程发送邮件(一)

邮件是Lotus Notes体系的核心和基本功能,以至于Send()是NotesDocument的一个方法,任何一个文档都可以被发送出去,Notes里的一封邮件也只是一个有一些特殊字段的文档。在程序开...
  • starrow
  • starrow
  • 2013年08月14日 17:24
  • 9124

如何去完成一个SAP notes的实现

本文主要介绍如何去看SAP notes,以及如何去实现SAP notes,有那些注意事项: 1、查看SAP notes: 2、实现SAP notes: 3、注意事项:...
  • zzj_rainbow
  • zzj_rainbow
  • 2013年12月04日 14:32
  • 2815

IBM Notes常见问题及解决办法

问题: Notes客户端是否支持Win8系统,如何下载安装介质? 解决方法: 标题:Notes/Domino产品系统要求 链接:http://www-01.ibm.com/suppor...
  • zhpengfei0915
  • zhpengfei0915
  • 2015年04月25日 11:44
  • 10232

computer organization and design notes(2)

(1) 在MIPS中,一个字的地址必须是4的倍数,这叫做严格对齐。(alignment restriction) (2) MIPS采用big endian. (3) MIPS寻址时,偏移量先乘4再...
  • droid_builder
  • droid_builder
  • 2012年01月08日 07:46
  • 427

打开Dreamweaver在onLoad运行Design Notes_onOpen.htm时发生了javascript脚本错误的解决方法

困扰已久的Dreamweaver在onLoad运行Design Notes_onOpen.htm时发生了javascript脚本错误的完美解决方法。   以前在做网站开发要用到 Dreamweave...
  • huang19910712
  • huang19910712
  • 2014年03月07日 10:26
  • 1401

computer organization and design notes(4)-MIPS寻址

(1) 32比特立即数的操作       MIPS有一个指令:load upper immediate(lui)。这个指令专门用于设置寄存器中常数的高16位。这样后续的指令可以设置常数的低16位。 ...
  • droid_builder
  • droid_builder
  • 2012年01月09日 05:31
  • 548

OO Design Principle Notes

Robert Martin在《敏捷软件开发 原则、模式和实践》中,阐述了 OO设计的5项原则: 1)  The Single Responsiblilty Principle 单一职责原则   ...
  • tiercel2008
  • tiercel2008
  • 2011年10月25日 10:52
  • 384

Ogre Paging as a core feature - design notes(ogre paging 设计相关说明)

by sinbad » Tue Mar 03, 2009 7:39 pm Hi folks,Thanks to a co-operative project that I'm doing with a...
  • pizi0475
  • pizi0475
  • 2011年05月10日 10:33
  • 1312

Head First Design Patterns Notes

1. Strategy Pattern The Strategy Pattern defines a family of algorithms, encapsulates each one, and...
  • nomad2
  • nomad2
  • 2012年04月14日 20:15
  • 1386

computer organization and design notes(3)-程序调用

(1) 当一个程序调用另外一个程序时,需要以下6个步骤:       1 将参数放在被调程序能够获得的地方;       2 将控制权交给被调程序;       3 获取被调程序所需的存储资源;...
  • droid_builder
  • droid_builder
  • 2012年01月08日 13:22
  • 193
您举报文章:JSP Design Notes