JSR 168 missing Portlet Filters.

A portlet filter in Portlets is same as a servlet filter in Servlets. Hence a portlet filter is an object which intercepts or modify s the output to or from a portlet before it is aggregated to the portal page. I cant find anything in JSR 168 to achieve this feature but you can find vendor specific api's for it else you can use JSR 286 to work with it.

Inter-Portlet Communication missing in JSR168 !!

Inter-portlet communication is the ability of one portlet to communicate with another portlet. This is one of the most important feature when we talk about portlets and portals. Looking to its importance many portal vendors have provided their own specific api's to achieve inter-portlet communication but this is something JSR 168 is missing and have to work on it before releasing next version. As per now to achieve inter-portlet communication in JSR 168 the developers are storing data in session at application scope level or storing it at portal level.
Developers are also using Ajax for acheiving inter-portel communication. In my last project I have used Ajax to achieve inter-portelt communication between the portlets.

Introduction for JSR 168 - the Portlet Specification

JSR(Java Specification Request) 168 is basically the Portlet Specification version 1.0 where standard for Java Portlet API is described.Any portlet developed using this standard can be deployed on any JSR 168 compliant portal servers.

Before moving further, let me first tell you the need why this specification was introduced…

In my case, my company (http://www.syncex.com/) is practicing Portal technology for more than 4 years and are providing and developing collaborative portlets which are very useful from an organization’s perspective.If for the development of these portlets,we had used any specific vendor’s portlet API e.g API provided by IBM, then we would have targeted buisness of only those organizations whose portal servers are compatible with the portlets developed with this portlet API.For us it would have restricted our buisness since we cannot target all different available portal servers or we need to develop portlets with different portlet APIs available in the market which was never a solution.

This was my problem and I was in a desperate need of a kind of standard specification by which i can develop portlets which can run on many portal servers so that i can increase the business for my company.

This was my problem, now let me explain you the need in generalized manner .

As we know an enterprise portal is a unified access point for integrating information, people and processes of an organization often in the form of a web-based user interface. It is designed to aggregate and personalize information through application-specific portlets.

With the emergence of an increasing number of enterprise portals, various vendors have created different APIs to develop different portlets. This variety of incompatible interfaces generate problems for application providers, portal customers, and portal server vendors.

To overcome these problems,some smart people(experts of portlet technology) introduced JSR (Java Specification Request) 168, the Portlet Specification version 1.0 and this specification was started to provide interoperability between portlets and portals.

So let me conclude that this specification was introduced for:
(1) Portal server vendors so that they can provide portlet engines
that conform to this standard.
(2)To save portal customers from incompatibility issues.
(3)Application providers (like me ) who can now follow a standard for their applications.

If anybody have any thought or different perspective on the use of JSR 168 then do share with me by commenting.