Portlets
What the heck is a Portlet, anyway?
Well, you can edit this page (tab at top) to have informative content about Portlets...
I understand Portlets in a broad sense but my grip on the precise details may be tenuous...
Portlets in uPortal 2
A portlet is rendered as a channel in uPortal 2, the user will probably never be aware that it is a portlet that they are using, anymore than they are currently aware that the uPortal channel they are using is an IChannel or CWebProxy channel.
The JSR-168 portlet standard is an attempt to make channel content compatible across portal platform boundaries. Standard interfaces have been defined to allow a portlet author to produce one portlet that should be capable of being deployed on uPortal, Oracle Portal, Jetspeed, BEA WebLogicPortal, Plumtree Corporate Portal, IBM WebSphere Portal, Liferay Enterprise Portal, SunONE Portal, Novell exteNd, SAKAI or any other JSR-168 compliant portal platform.
WSRP is a closely tracked, cross platform/technology standard dealing with subscribing to remote content, allowing say a portal to subscribe to content hosted on a remote "producer" either another portlet, or some other web-service provider. Kind of like webproxy on steroids.
The following page contains information from a seminar delivered at the JA-SIG conference with general information about writing both portal-agnostic portlets and portlets for the uPortal 2.x series:
Portlet specifications
For the technically minded, a good introduction to the JSR168 portlet specification can be found in the following JavaWorld articles (although note that the specs have changed slightly since these were published):
Introducing the Portlet Specification, Part 1
Introducing the Portlet Specification, Part 2
There are essentially two flavours of portlets, JSR168 and Web Services for Remote Portlets (WSRP). JSR168 is a Java specification. WSRP was developed in collaboration with JSR168 but in itself is not Java specific. WSRP is a web service standard that could be implemented in any suitable underlying technology.
JSR168 portlets need to reside on the same application server instance (e.g. Tomcat) as uPortal. WSRP portlets would usually reside on a remote server.
Apache Pluto is the reference implementation of the JSR168 portlet specification. It is Pluto that is the basis of the current uPortal 2 portlet implementation. At the time of writing uPortal 2 currently contains a means of consuming and producing JSR168 compliant portlets. Several test portlets are included in the uPortal distribution including a RSS portlet and Google portlet from the Portlet Open Source Trading site (POST).
The current version of uPortal 2 is also able to consume WSRP portlets. The WSRP consumer code that uPortal uses is based on the Apache WSRP4J project code. The ability to produce WSRP portlets for remote consumption will be added in a future version.
Portlets in uPortal 3
uPortal 3.0 is being designed with portlets, rather than channels, as the core means of content delivery.
uPortal 3.0 is also being developed as the adhesive for the components of the SAKAI project, one of the aims of this project is to be JSR168 specification compliant.
See also:
Guide to Working with Portlets in uPortal
uPortal Portlet Example
Punit Pandey's Portlets Blog
Portlet Wiki Space
JSR168.org
Open Source Portlets
Portlets based on the JSR-168 standard should, in theory, work in every portal server that supports this standard. Soon after the first version of the JSR-168 spec was approved, the primary vendors behind the spec introduced a Web site to allow sharing of open source portlets. This site, called Portlet Open Source Trading site, is here: http://portlet-opensrc.sourceforge.net/. This site has not been very active.
More recently, in September of 2005, JBoss took another attempt at achieving more or less the same goal. It's called JBoss PortletSwap, and the site is here: http://www.portletswap.com/. There are several portlets posted there, including a Web clipping portlet that was verified to work in uPortal 2.5.
