Monday, March 15, 2010

Java Portlet Specification


Introduction

The Java Portlet Specification provides a standard for developing portal components with the Java programming language. This specification, originally released in October 2003 called as JSR168, is gaining popularity as not only a standard for traditional portals, but also as a framework for deploying 'plug-ins' for standard Web applications.

Currently there are three Java Portlet Specifications as JSR168, JSR170 and JSR 286.

JSR 168

JSR168 is a standard relating to portlets within Java-based portals. JSR168 defines a standard set of behavior for portlets and a standard interface that governs how portlets interact with the portlet container (typically a portal package) in which they are hosted. In simple way it defines a portlet specification, including a contract between the portlet container and the portlet. JSR 168 is defined by the Java Community Process (JCP) in October 2003.

Goals of JSR168

• Define the runtime environment, or the portlet container for portlets.
• Define the API between portlet container and portlets.
• Provide mechanisms to store transient and persistent data portlets.
• Provide a mechanism that allows portlets to include servlets and JSP.
• Define a packaging of portlets to allow easy deployment.
• Allow binary portlet portability among JSR168 portals.
• Run JSR168 portlets as remote portlets using WSRP protocol.

JSR 168 offers numerous useful portal-specific capabilities as follows.

• Portlet modes – JSR 168 provides three modes for portlet interactions.
VIEW - This mode, a mandatory one that's defined by a portlet, renders markup fragments.
EDIT - This optional mode enables changes to per-user settings to customize rendering.
HELP – This optional mode displays help information.

The major changes and enhancements of JSR168

• Decoupling the portlet class from servlets.
• Ensuring that JSR168 aligns well with the emerging WSRP specification in areas such as URL rewriting, portlet modes, window states, multistep navigational state and portal container context.
• Offering general architectural cleanup to allow for flexibility and extensibility over time.
• This standard ensures that portlets were cross-vendor and -server compatible.

Issues in JSR 168

• Inter-portlet communication and event model. This is arguably the most important gap in the JSR168 specification
• Provision for client-side portals.
• Tight coupling with one or more user interface frameworks, such as Struts, Java Server Faces (JSF) and Barracuda.

JSR170

JSR-170 is a specification developed under the Java Community Process (JCP) program in April, 2005.
It promises the Java world, and possibly beyond, a unified API that allows accessing any compliant repository in a vendor- or implementation-neutral fashion, leading to the kind of clean separation of concerns that characterizes modern IT architectures.
The JSR-170 API defines how an application and a content repository interact with respect to a number of content services. For example the versioning facilities of a content repository are clearly defined, so an application knows how to browse the version history, check in and checkout content items, or update and merge content in a standard fashion.

JSR 286

While JSR-168 laid the foundation for the portal architecture, it lacked many features that applications and developers needed. This forced developers back into creating non-portable, vendor-specific solutions, which therefore defeated the very purpose of having a portal specification. Then The Java Portlet Specification V2.0 (JSR-286) was created to enhance JSR-168 and improve upon its shortcomings. On June 12th, 2008, JSR-286, went final and was publicly released.

Major enhancements of JSR 286
  • WSRP 2.0 alignment
  • Serving AJAX or JSON data directly through portlets
  • Serving dynamically generated resources directly through portlets
  • Inter-Portlet Communication through events
  • Setting Markup Head Elements
  • Caching Changes
  • Public Render Parameters
  • Window ID / Namespacing Consistency
  • Additional CSS classes
What was left out of the JSR286 Specification
  • Clear Read / Write AJAX support
Developers have no way to make sure other Portlets receive state change information, when updating state through a Resource URL.
  • Improved Groups and Permissions Support
  • More CSS Classes
Although some additional CSS classes have been defined by the JSR 286 specification, they are insufficient to meet the demands of good user interfaces.

No comments:

Post a Comment