Skip to main content

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.

Comments

Post a Comment

Popular posts from this blog

Passing end-user details from client to real backend endpoint via JWT token

In real-world business system,WSO2 API Manager useful on exposing company APIs, in a secured and controlled manner with the features provided by APIManager as; OAuth support [To secure API invocations] Throttling support [To control API invocations] Monitoring support [To track API usage] More technically what happening is when a user sends a particular API request,it will goes to WSO2 APIManager node and from there,the request will route to the real implemented back-end endpoint of the particular API and get back the response and returned it to the API invoked user. There can be a use-case,that this back-end endpoint may expect the details of API invoked user as to pass those details to some internal company usage  as; Additional authentication/authorization Track usage data from an internal system. So how to support above requirement from WSO2 AM. There comes the use of JSON Web Token[JWT] implementation done inside WSO2 AM. JWT is a means of representing claims to...
7 comments
Read more

TPP Journey through WSO2 Open Banking

Introduction 2018 is all set to be a game-changing year for European banking. The Revised Payment Services Directive (PSD2) has opened the door to new third party providers [TPPs] to connect with banks and manage finances of bank customers on behalf of them. The PSD2 regulation has mandated banks to expose their core-banking account data and payment services to authorized TPPs to consume. Thus as a bank it’s essential to have a solution which will securely expose their internal banking services to third party providers in a trusted manner. WSO2 Open Banking solution provides all required components to expose bank APIs in a well secured manner in order to become PSD2 compliant. This article explains about the importance of the TPP role in PSD2 domain, the requirements set that banks need to provide for TPPs by PSD2 regulations and how WSO2 Open Banking solution supports these requirements.  From my last blog ,I have given an introduction for PSD2 and WSO2 Open Banking soluti...
4 comments
Read more

How to rollback/commit processing messages from WSO2 ESB when enabled JMS transaction

This blog post describes the below use-case where WSO2 ESB 4.6.0 act as the intermediate channel in-between two JMS queues. The Use-case First messages will be de-queue to a proxy service deployed in WSO2 ESB from an queue in ActiveMQ message broker. Then inside ESB,the incoming messages will undergo with some message mediation flow and then the message will be send to another JMS queue deployed in JBoss server. Inside the ESB,following failures could be happen;            a) Failures during message mediation process failure inside ESB [for example if you                use   dbreportmediator/lookup mediator inside mediation flow,some times failures can                happen due  to database connection failures]          b) Message sending failure,due to endpoint is unavailability.[For example,the JBoss  ...
4 comments
Read more