jayjayjays

浏览: 214787 次
性别:
来自: 北京

最近访客更多访客>>

mf1389004071

yaoyuming

w4561445

huangyunbin

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

JSP Design Notes

博客分类：

java

JSP EJB HTML Servlet Bean

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

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.

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.

Return to Top of Page

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

分享到：

开发Enterprise JavaBeans | Enterprise JavaBeans Distilled

2004-07-09 14:12
浏览 619
评论(0)
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

JSP Design Notes

JSP Design Notes

White Paper Sections

Introduction to JSP Design Notes

The Technology

Prevalent Application

The Alternative

Conclusion

评论

发表评论

相关推荐

最近访客 更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

JSP Design Notes

JSP Design Notes

White Paper Sections

Introduction to JSP Design Notes

The Technology

Prevalent Application

The Alternative

Conclusion

评论

发表评论

相关推荐

Java字典:如何从程序员升级到架构师.

一个Java程序员应该掌握的10项技能

自定义log4j中的DailyRollingFileAppender

google 测试

项目测试风险总结

性能测试总结之性能监控篇

如何编写高质量的Java代码

一直在用的类注释

rapid-framework 连接 oracle时的一个bug

xapool的框架配置

NIO socket服务器注意的几点.

jsp分页

解决jsp中乱码问题

使用类文件的数据库连接方法

jsp中文显示问题

不用数据源直接连sqlserver数据库(jsp,中文)

WINDOWS 2000 环境下JAVA环境配置

Java 学习方法浅谈(http://www.javaeye.com站长Robbin著)

解决java中文问题的一些资源

JAVA程序桥联数据库

最近访客更多访客>>