JSR 168- Java Portlet API

[Pawan Udernani]

HI-
I have been reading about these latest specs regarding portals. Surely, this is a step in right direction, but not sure wether it can remove all the differences that exist in portal space. Implementing a portal solution involves number of things apart from design portlets. An EIP would have integration points with other enterprise apps like ERP, Directories, Data Marts etc. All the vendors have their own ways to realize these integration points. I am just wondering if such specs as JSR 168 can be defined for these integration/interface points as well. I am just want to throw this up to invite more thougts and discussion from you guys..
Thanks,
-Pawan.

[Mike Farnham]

All good thoughts and questions.
We are moving from a non-JSR 168 Portal implementation (Epicentric 3.5) to a JSR-168 based portal (uPortal).

And, we are learning the differences between writing "portlets" that run all in the same web application vs. writing the JSR-168 portlets which are each seen, as a separate web application within the Portlet Container context. Portlets, in effect, exist in a smaller sandbox.

I guess there isn't too much activity yet by the Java Ranch developer community. I thought there would be a dedicated discussion section for Portlets. But, was surprised to not find one.

Here is a Yahoo! discussion group dedicated to all things portlet.
http://groups.yahoo.com/group/portlets/

You need to establish a Yahoo! account to access it.

Cheers,
Mike

[Scott Dunbar]

I would agree that for a JSR168 portlet to do real work the rest of the application framework would have to be somewhat standardized too.

One area that might help would be WSRP. It would, in theory, assist you with presenting a bunch of JSR168 portlets. Your application would concentrate on the presentation side and the provider would worry about the backend.

That is all well and good in theory but I feel that there are two problems with it:

Nobody is really doing anything but proof of concept type things right now

Talk about your distributed maintenance nightmare!

However, it does seem like this is a step in the right direction. In general I think alot more systems need to move the the RDF/web services type of model.

[Mike Farnham]

Scott,

>>One area that might help would be WSRP. It would, in theory, assist you with presenting a bunch of JSR168 portlets. Your application would concentrate on the presentation side and the provider would worry about the backend.
<<
WSRP is interesting. The thing is it like Archimedes said, "Give me a place to stand and I can lift the world." WSRP assumes you already have a portlet running somewhere. Then, it is just a matter of proxying in into another portal. If you use WSRP, then you are giving up any "branding" you might have, similar to how a portlet only produces a fragment of HTML and not the full HTML page.

With regards to our conversion, we looked at WSRP, as a possibility, but we would have to construct not only the existing web applications (meaning convert our existing "portlets" into stand-alone web apps), but also the WSRP layer (producer layer) to be able to have them accessible via WSRP consumer.

Cheers,
Mike