BEA's dev2dev site recently posted an article on building clustered federated portals that aggregate content using WSRP from a number of producer Portlets that contribute to a shared work-flow, solving the well-known problems of global identity management within federated portlet environments.

From the article:

The Web Services for Remote Portlets (WSRP) protocol was designed to support the federation of portals hosted by arbitrary portal servers and server clusters. Developers use WSRP to aggregate content and the user interface (UI) from various portlets hosted by other remote portals. By itself, though, WSRP does not address the challenge of implementing scalable, reliable, and high-performance federated portals that create, access, and manage the lifecycle of data shared by distributed portlets. Fortunately, BEA WebLogic Portal provides an extension to the WSRP specification that—when coupled with Tangosol Coherence—allows WSRP Consumers and Producers to create, view, modify, and control concurrent access to shared, scoped data in a scalable, reliable, and highly performant manner.

The cited WSRP extensions are being standardized, likely making this approach universal with the next version of the WSRP specification.

Just last week:
http://www.theserverside.com/news/thread.tss?thread_id=37818
it was eluded that 168 needs to be fixed, w/ some problems mentioned.

Right now Portlets are not a part of pending J2EE 5.0 and ... I think J2EE 5.0 should be delayed untill portlets ARE a part, it's not just an EJB server.

Do vendors expect developers to integrate it into JSF, etc?

Use Tiles in the mean time?

.V

I think this is very interesting and hope it works out since WSRP has really been synonymous with "slow" up to now.

Was intrigued by the subject of this article, only to read it and find no mention of JSR-168. Been working with Weblogic Portal 8.1 with JSR-168 Portlets (or JavaPortlets as they call them) and having quite a painful experience. Was hopeful this article hinted that BEA was going to treat JSR-168 portlets as more of a 'first class' portlet, instead of their proprietary framework based stuff.

I too would like to see JEE 5.0 held up until JSR-286 can be added to it. The app server vendors just aren't taking the current spec seriously and just treat it as a 'checkmark' item.

The app server vendors just aren't taking the current spec seriously and just treat it as a 'checkmark' item.

Correction... some of the *proprietary vendors* aren't taking the spec seriously and treating it as a checkmark item. If you look at some of the OS Portals, spec-compliance wrt portlets is at the top of their list. It is what defines the portal, at least in its early stages.... JBoss, Liferay, Jetspeed, and eXo, included.

Perhaps things will change in the future with BEAs recent acquisition of Plumtree?

STAY METAL!
Roy Russo

We've been testing with both 8.1 and 9.0, but haven't had any problems. I'm guessing that real applications stress the spec-compatibility of the portal server much more than our tests do at this point.

I guess another question is how WSRP and the Portlet spec overlap / integrate / compete, since theoretically I could be using "remote" portlets instead of "capital-P" portlets.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Jason Carreira did not post any news for us at TSS.

But, this useful news about the clustered federated portals appeared here today.

I will not say - The weird thing is that it took almost 20 (Nov 14 till today) days to show up here...

Thank you. Cameron Purdy brings in something useful every so often.

Jason Carreira did not post any news for us at TSS.But, this useful news about the clustered federated portals appeared here today.I will not say - The weird thing is that it took almost 20 (Nov 14 till today) days to show up here...Thank you. Cameron Purdy brings in something useful every so often.

Well, it's all part of the conspiracy...

Could anyone remind me... what was the name again of the JBoss product that has been supporting this for at least two years ?

Could anyone remind me... what was the name again of the JBoss product that has been supporting this for at least two years ?

Hehe... :-D