About JCP
Get Involved
Community Resources
Community News
FAQ
Contact Us
|
|
This JSR has been Withdrawn
Reason: Withdrawn at the request of the Specification Lead.
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Original Summary: The JESI tag library facilitates the use of Edge Side Include (ESI) in-markup language within a JSP application. JESI tags simplify the declaration of cacheable dynamic fragments, content invalidation and personalization.
Section 1. Identification
Submitting Member: Oracle
Name of Contact Person: Julie Basu
E-Mail Address: Julie.Basu@oracle.com
Telephone Number: +1 650 506 3261
Fax Number: +1 650 506 7225
Specification Lead: Olga Peschansky
E-Mail Address: Olga.Peschansky@oracle.com
Telephone Number: +1 650 506 6125
Fax Number: +1 650 506 7225
Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)
Akamai
ATG
BEA Systems
Circadence
Digital Island
Fort Point Partners, Inc.
Interwoven, Inc.
Macromedia
Mirror Image Internet
Open Market
Oracle
Silverstream
Vignette
More members are in the process of endorsing this JSR.
Section 2: Request
2.1 Please describe the proposed Specification:
Background: Edge Side Includes
The World Wide Web has evolved beyond simply displaying static Web pages. Increasingly, businesses are delivering dynamically generated content, and using JavaServer Pages to do it.
Dynamically generated content presents e-businesses with new a challenge -delivering
Web pages quickly. As traffic on Web sites increases, the computing overhead associated with building personalized pages on-the-fly for thousands of concurrent users can result in increasing delays and failures in data delivery.
Dynamic content presents a problem for traditional Web site architectures, because
the same infrastructure that is used to generate the content is used to deliver the content - namely, the application server. An application server will ususally: dispatch requests, execute server-side (Java) code, perform disk or network I/O as code queries back-end databases, assemble and format data and send it to the browser.
E-businesses need a simple way to separate content delivery from content generation.
Edge Side Includes is a simple markup language that developers can use to identify content fragments for dynamic assembly at the network edge. ESI also specifies a content invalidation protocol for transparent content management across ESI-compliant solutions, such as application servers and Content Delivery Networks (CDN). The ability to assemble dynamic pages from individual page fragments means that only non-cacheable or expired fragments need to be fetched from the origin Web site, thereby lowering the need to retrieve complete pages and decreasing the load on the Web site's content generation infrastructure (see Figure 1).
Figure 1. Content Delivery Network with Edge Servers
ESI enables Web pages to be broken down into fragments of differing cacheability profiles. These fragments are maintained as separate elements in the application server?s local cache and/or on the CDN. Each fragment is treated as separate entity. Cached templates and fragments may be shared among multiple users. This means that for a large percentage of requests, the entire page can be assembled using shared components and delivered from the edge. ESI obviates the need for full-page updates when individual page fragments change.
ESI provides a number of ways to manage the consistency (freshness) of cached objects, including the
ability to define expiration policies. Due to the unpredictable nature of frequently changing content, ESI also includes a content invalidation specification. The invalidation message tells the cache or delivery network to overwrite the metadata associated with particular objects residing on edge servers. In this way, e-businesses are able to control the validity of volatile content just as if it were residing on static Web servers.
Proposal: Edge Side Includes for Java
Edge Side Includes for Java (JESI) is the topic of this JSR. JESI provides extensions to Java that make it easy to program JSPs which will generate ESI markup. JESI will be delivered in the form of a custom JSP tag library. As ESI adoption grows, it will be natural and inevitable that different custom JSP tag libraries for ESI generation will be written by different developers, because ESI is used for caching of dynamic content, and JSP is used for generating such dynamic content in the first place.
In the interest of portability among J2EE platforms we propose to standardize such a tag library from the start.
For JSP developers, JESI represents an easy way to express the modularity of pages and the cacheability, invalidation policies and personalization of those modules - in the spirit of ESI specification -? without requiring developers to learn a new programming syntax.
While ESI tags can be directly used in JSPs and servlets, there are several reasons why a custom JSP tag library on top of ESI is useful for JSP developers:?
Standard JSP framework: Although ESI is XML-based and looks similar to a custom JSP tag library, it is nevertheless a different kind of mark-up language. JSP developers and JSP IDE tools are used to dealing with the standard framework of JSP custom tag libraries. For example, the path references in a JSP page are either page-relative or application-relative. These URIs can be translated by the JESI tag library into absolute path references expected by ESI.
Short-cut syntax: The JESI tag library can simplify the following common tasks:
Specifying meta-data information, such as expiry time for all page fragments in a "template" JESI tag.
Sending invalidation messages to purge URLs on edge servers.
Personalizing dynamic pages using cookie information.
The JESI tags can translate these tasks into appropriate calls, such as generating an HTTP request for invalidation, translating into the appropriate ESI tag in the generated page, setting the appropriate HTTP response header etc.
Convenient application-level configuration files: The JESI tag library can make use of application-level configuration files to specify deployment-time parameters and default settings for various options. The config file allows parameters such as the username and password for invalidation to be conveniently specified externally at deployment time, without requiring changes to the application code.
Rich expressions for dynamic content. While ESI specification has a rudimentary support for expressions in the form of string operators and a few environment variables, JESI tags allow full use of Java code fragments and JSP expressions in generation of ESI mark-up.
Following a common practice in Java standards, JESI tags will fall into two categories:
Mandatory JESI tags, which must be implemented by any JESI-compliant tag library.
(for a mandatory tag, there may be some implementation optional attributes).
Optional JESI tags, which have well defined semantics, but are not required to be available
in every JESI implementation.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
Java 2 Enterprise Edition.
2.3 What need of the Java community will be addressed by the proposed specification?
JSPs allow easy generation of dynamic content. ESI markup adds the ability to cache and assemble generated dynamic fragments on remote nodes away from the origin server. However, ESI tags were not designed for Java. Thus, they are not as dynamic as JSPs, have a separate interface with HTTP request attributes, and are cumbersome to include into JSP source. They cannot take advantage of Java language expressions, available to JSP.
JESI tags address these integration needs and allow dynamic content caching to be expressed in syntax and semantics that follows the JSP standard, and is familiar to JSP programmers . Edge Side caching ability will further advance JSP position as the first choice in dynamic content generation.
2.4 Why isn't this need met by existing specifications?
There is no other JSP tag library which targets ESI markup language.
2.5 Please give a short description of the underlying technology or technologies:
JSP custom tags: Custom tags is a standard JSP 1.1 technology. A set of related tags that facilitate a common JSP programming task are collected in a "tag library". Syntax for related tags is formally described by an XML document called Tag Library Definition (TLD). TLD and implementation classes are collected in a tag library JAR.
Having a standard for a tag library allows JSP developers to write pages, which are portable across different J2EE platforms.
ESI Tags & Processors: Edge Side Includes (ESI) is an XML based "in-markup" language, which is a publicly available specification endorsed by a broad cross-section of industry leaders.
ESI tags must be generated by an origin server and included into the resulting document, usually within HTML. ESI tags will be processed and consumed by so called "edge side servers" further away from the origin server before the final enity is delivered to the client. Through ESI tags the origin server instructs edge side servers to fetch different fragments of the final page from different URLs, as well as sets the cacheability and expiration attributes of the fragments. It is expected that subsequent requests for the final content will be served by edge side servers from cached copies, without going to the origin server. At the same time, the content may be customized for particular client, and is kept fresh either with expiration policy, or by invalidation messages from the origin server.
ESI tags are also used by edge side servers to inform the origin server of their identity and capabilities. This second group of tags is not currently considered for JESI tag library, but will be considered in the future.
2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
javax.servlet.jsp.tags.jesi
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
No.
2.8 Are there any security issues that cannot be addressed by the current security model?
No.
2.9 Are there any internationalization or localization issues?
NLS issues are similar to those of JSP pages.
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
No.
2.11 Please describe the anticipated schedule for the development of this
specification.
Initiation: May 2001
Community Review: July 2001
Public review: October 2001
Final draft proposal: December 2001
2.12 Please describe the anticipated working model for the Expert Group working on developing this
specification.
Initial specification draft will be circulated, followed by email discussion, feedback on drafts, and regular face to face meetings of the participants.
Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.
Edge Architecture Specification
ESI Language Specification
JESI Tag Library Specification
Oracle and Akamai plan to release their respective implementations of JESI Tag Library and
ESI Processor in the nearest future.
3.2 Explanation of how these items might be used as a starting point for the work.
The expert group will study the above specification proposals and vendor implementations in order to form a consensus on a set of standard tag syntax and semantics.
Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
The JESI proposal arose from strong customer need for conveniently generating ESI tags in a JSP. Both Oracle and Akamai provide ESI processors, as well as JESI tag libraries, in response to their clients' requirements.
While the two libraries differ in some respects, it has been possible to define a common intersection of the features, which form the basis of this proposal. The existence of multiple implementations proves the need for a standard.
|
