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.
No comments:
Post a Comment