Rajesh Agarwalla		IBM
	Steve Ims		IBM

 

Cable, Laurence P.G.		Holsman, Ian		IBM
Macromedia, Inc.		Novell, Inc.		Oracle
Scott, James L.		Sun Microsystems, Inc.		UBS

Expert Group Private Page

 

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: IBM Corp.

Name of Contact Person: Rajesh Agarwalla

E-Mail Address: agarwalr@us.ibm.com

Telephone Number: +1 412 667 4400

Fax Number: +1 412 667 4439

Specification Co-Lead: Steve Ims

E-Mail Address: steveims@us.ibm.com

Telephone Number: +1 919 543 8430

Fax Number: +1 919 254 6243

Specification Co-Lead: Rajesh Agarwalla

E-Mail Address: agarwalr@us.ibm.com

Telephone Number: +1 412 667 4400

Fax Number: +1 412 667 4439

Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

IBM Corporation

Section 2: Request

2.1 Please describe the proposed Specification:

This specification defines a standard application model and architecture for distributed page assembly within the J2EE framework. (Page assembly refers to the notion of assembling complex Web pages from smaller, simpler page "fragments"; distributed page assembly enables the assembly operation to occur on a different server than that generating the fragments.)

There are two key components of the required application model:

1. A fragment model, including the fragment's cacheability and rules affecting composition via a new JSP tag and/or extensions to the WAR deployment descriptor.
2. A template model, including a new JSP tag which supports remote inclusion. This expert group will determine the appropriate model for sharing application/user session information between distributed application servers.

Further, the distributed architecture will expand the role of the J2EE platform into surrogate proxies. Within such a four-tier architecture, the surrogate proxy will be capable of executing the page assembly function.

The implementation must support page assembly in a three-tier or four-tier architecture. That is, without user intervention, page assembly could be completed within a single application server or across distributed application servers. The specification will define a mechanism of communication and exchange of the JSPs from origin server to the surrogate proxy.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2EE

2.3 What need of the Java community will be addressed by the proposed specification?

J2EE is becoming a leading platform for web based applications with increasing J2EE compliant vendor offerings. At the same time, need for enhanced rich user experience is driving web content to make a fundamental shift from traditional static content to becoming dynamic, personalized and application generated. This is increasing the use of the J2EE web application model, specifically of fragments being generated and composed by JSPs taking into account specific characteristics of the user and the provider i.e. the fragments are being personalized.

Most personalized web applications currently require execution in the origin server. This adds load at the backend and degrades the user experience. To alleviate this and provide a better user experience, this specification defines the opportunity for a distributed J2EE application platform and extends the reach of the J2EE model beyond the application server and the enterprise data center into the network by defining a proposal for caching and composing fragments at a processing point outside the enterprise data center, thus enhancing the scalability of the application platform. At the same time, the proposal allows composition at the origin server, should such a capable processing point in the network not exist.

JSP is an ideal vehicle to help establish J2EE leadership for distributed page assembly at an edge processing point. By leveraging the standard JSP tag library extension mechanism, this new function integrates easily with the current JSP tooling platform.

Different approaches are currently being used by different customers and vendors. The proposed specification will allow developers to use a single set of tags with standard semantics to identify fragments and rules used to compose them into pages; instead of requiring the developers to understand different tags with different semantics in different application engines or having to directly modify HTML to enable this. As a result, this will enable better integrated authoring tools, reduced training/support costs, increased mindshare. Further it will allow for flexibility in terms of required capabilities at the edge processing node.

2.4 Why isn't this need met by existing specifications?

Although no other specification addresses distributed page assembly, this specification will build upon other work:

• JSR 52 is defining a standard tag library for JSPs, but it is focused on JDBC and LDAP integration. We expect the Java community will need to define additional standard tag libraries, such as outlined by this specification.
• JSR 107 addresses caching within the J2EE application server only and does not consider the needs of external edge based caching and composition of fragments.
• The JSP specification (specifically the jsp:include tag) supports page assembly only within a given web application (that is, the scope of included fragments is limited to a single web application).
• The specification will extend the horizontal scaling concepts introduced by the Servlet 2.2 API (specifically, the "distributable" element of WAR descriptors) to a vertical scaling.

2.5 Please give a short description of the underlying technology or technologies:

This will be based on JSP and extensions to JSP.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

TBD

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?

No.

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.

TBD

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

TBD

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.

3.2 Explanation of how these items might be used as a starting point for the work.