There has been an interesting slip in the JSR process this week. On Jan 9, Portlet API JSR 162 (posted by IBM) was announced as a new post on the JCP. A few days later, another Portlet API (JSR 167) was posted by Sun. The two JSR's are almost identical in scope and intent, but were thought of and submitted entirely independently.

The spec. leads for these JSR's are currently in the process of merging concepts into one JSR.

The Portlet specification will define a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security.

Read IBM's JSR @ http://www.jcp.org/jsr/detail/162.jsp

Read SUNS's JSR @ http://www.jcp.org/jsr/detail/167.jsp

Read the heated discussion on the Portlet JSR on TheServerSide @ http://www.theserverside.com/home/thread.jsp?thread_id=11106.

Notice who supports which.

162

"Supporting this JSR:

IBM"

---

167

"Supporting this JSR:

Accenture
BEA
Borland
Bowstreet
Cap Gemini Ernst & Young
Citrix
Documentum
Enformia Ltd.
Epicentric
Interwoven
Macromedia
Plumtree
Sybase
Tarantella, Inc.
Vignette"

JetSpeed is mentioned on both as one of the implementations. IBM didn't mention their server in 162 as a reference implementation, but IBM's portal is mentioned in 167.



In the 167 JSR:
"3.2 Explanation of how these items might be used as a starting point for the work.
They will be useful for gathering features and evaluating the effectiveness and shortcoming of each implementation."

The plot thickens.
Steve

Did Sun post this unaware of IBM's JSR or did they post it in spite of it? The JCP is all about COMMUNITY and standards so it would be ashame if Sun and partners could not agree with IBM to combine the JSR's to form one standard. They must work together otherwise the JCP will become worthless!

Re. "JetSpeed is mentioned on both as one of the implementations. IBM didn't mention their server in 162 as a reference implementation, but IBM's portal is mentioned in 167":

there is no point in mentioning both, as the IBM product is just a glorified version of Jetspeed. IBM has been one of the largest contributors to Jetspeed (large meaning about 3-4 developers) for the last year. Of course the fact that Jetspeeds status has not improved much over that time may lead one to believe that most effort went into improving the commercial product ("cannibalizing" the open source base)

As if a standard for building "portals" was necessary or useful... This is just silly.

A portlet API is important and needed. I have worked quite a bit with iPlanet Portal server and fool around with jetspeed and have learned that both have similar concepts and channel/portlet API's but there is no way you can move one to other or vice versa. Portlets are not just JSP's in frames, they are managed objects inside a framework just like EJB's. Also given that IBM and Sun are pushing their portal products a center pieces to their integration strategies and the plethora of java based portal implementations demands that there should be some sort of standardization to afford portability. The iPlanet portal server only runs on Solaris and up until recently I did not have a Solaris box. If this JSP is finalized that would mean I could develope my portlets in jetspeed and migrate them over to iPlanet for production, just like people use JBoss and BEA. Again, portlets are not just JSP's in frames there is a lot of customization and personalization involved that if standardized would benefit everyone who works with portlets.

Aaron, it's interesting that you're mentioning both iPlanet and Jetspeed, as it seems I will work with both on separate projects.
Can you list some experiences you had with any of these? It would be great.

FB