More and more portal solutions are coming out of the woodwork. Jakarta has released Apache Pluto, which is the reference implementation of the Java Portlet Specfication. Brad Rippe has written an article discussing the open source uPortal framework. With various portal frameworks out there, how do you choose what to use? When will there be consilidation? Will we really be able to use the same portlets in these containers?

Apache Pluto Home

Start developing portals with JA-SIG uPortal

NOTE: we also just had an article on Introducing the eXo platform.

It seems that most portal providers are conforming to or will conform to JSR-168. Jetspeed 2 is planning to use Pluto as part of its core, I believe.

Basically, for future compatibility, you should be writing your portlets to the JSR-168 specs. The one thing that looks pretty sloppy, however, is that configruation files for each of these portal servers are currently quite different and pretty extensive. Implemnting the interfaces in JSR-168 is a breeze, but wading through all of the XML config files has a steeper learning curve.

I'm hoping that a users guide to Pluto will be released soon, so I can get on with the business of using Pluto in my own web application without having to go through the source and see what's actually going on under the covers.

Brian Kapellusch wrote :

"Basically, for future compatibility, you should be writing your portlets to the JSR-168 specs. The one thing that looks pretty sloppy, however, is that configruation files for each of these portal servers are currently quite different and pretty extensive. Implemnting the interfaces in JSR-168 is a breeze, but wading through all of the XML config files has a steeper learning curve."

With the eXo platform no new XML file is necessary for Tomcat and JBoss distribution (in coming Jetty). Also you just need to add a tag (servlet listener) in web.xml to make it work on every closed source server (Weblogic, websphere, Oracle...)

I cannot find neither binaries nor source code anywhere in jakarta site. Any clue?

ok, I found it in CVS. Module name is jakarta-pluto (it was not listed, I had to guess!)

Here is the pluto home page: http://jakarta.apache.org/pluto/

------------------------------

http://javarss.com
Just one bookmark - for all java news, articles and blogs.

------------------------------

Folks,

where the portlet technology fits into J2EE framework?

- Lawrence

Slightly to the left of JMS.

Slightly to the left of JMS.

JSR168 is just a standardization of the portlet/portal contract. WS-RP is a farther reaching standard around remote content syndication. Long term, WSRP is a much more interesting standard to watch since it allows for completely dynamic portals (i.e. code does not need to be dropped into the server as with JSR168 portlets). Portals can use WSDL, SOAP and UDDI for completely dynamic discovery and binding to remote portlets. It's a great pipe dream - let's hope it works out in the end.

> where the portlet technology fits into J2EE framework?

with this free implementation ...does it mean that Epicentric, Bea, IBM, ATG and Oracle Portal solutions are in danger ?

The best product pluto can be compared to is tomcat in the servlet container world. Many comercial implementations will use pluto as its core and add some additional features like portlets, personalization, cms, ...

> Bea, IBM, ATG and Oracle Portal solutions are in danger ?

Pluto is only the reference implementation for JSR-168,
not an entire portal solution.
Portal market will be the same of application server market:
big firm for big customer and nice free solution for SMS.
Anyway the competition is well :->

Ciao, Diego

PS: I found very interesting the recent "express" approach of big firm

No, it is not. In fact, from what I understand, a large portion of pluto was actually created by IBMers. They would not give it away if it was a threat.

As I read JSR-168, it should be easy to convert a Servlet generated Web page to a Portlet generated page fragment. Portlet container extends Servlet container and Portlet duplicates most Servlet behavior. So I would expect the new Portals coming out to be add-ons to existing Servlet containers and would allow me to reuse most of whatever MVC code I happen to have.

So far, I haven't seen these new Portal projects touting how Servlet/MVC code can be adapted to Portals. Can anyone clue me in on how well these Portals leverage existing Servlet/MVC code? eXo makes their own MVC for Java Server Faces and Liferay gives Struts/JSP examples but it's not clear if that's required.

Gary

Gary,

If your servlet generates part of HTML you can access from a portlet using the PortletRequestDispatcher (almost the same than the servlet dispatcher). Therefore all your code can be reused in the eXo platform, you just need to deploy you servlet and access it through a portlet. You can even access a Struts URL.

Actually, the eXo platform is the only portal/portlet-container that allows portlets hot deployment in a transparent way using separate wars (both on Tomcat and Jboss).

Also you wrote : "eXo makes their own MVC for Java Server Faces" which is not correct :)

We made an MVC framework - à la Struts - for portlets in order to manage roles (J2EE declarative security) and portlet modes. The Java Server Faces framework is only used to build the portal and it is transparent to portlet developers.

> allows portlets hot deployment in a transparent way using separate wars

From years WebSphere Portal Server does it, too.
Don't forget that IBM has been strongly committed on JSR-168 :->

Ciao, Diego

Ok my mistake, I should have said :

"Actually, the eXo platform is the only OPEN SOURCE portal/portlet-container that allows portlets hot deployment in a transparent way using separate wars"

A good solution for some out there may be Liferay Enterprise Portal, because it comes with a lot of built in portlets such as email, document management, calendar, directory services. It's also one of the prettier ones out there.

It's built off of Struts, Hibernate, and uses Session Beans for distributed access to the business logic.

You can see a demo of it at http://my.liferay.com

Or see our web site at http://www.liferay.com

hi, do you published the architecture for your liferay? I have waited too long.

So try the eXo platform... there is an architecture article somewhere :)

Jeff,

Thanks for your patience.

Liferay is a JSR 168 open source portal with many portlets: email, document library, calendar, message boards all integrated.

The architecture overview is now available at

http://www.liferay.com/documentation/architecture.jsp

After playing a bit with Liferay (LPortal), I think, LPortal is the most beautiful Open Source Portal out there! I'm really surprised with all the "portlets" and "business components" from LPortal. Therefore we are now integrating the business components from LPortal into OpenUSS!

So, to tell you all the truth, this discussion:
"Where are all the components?"
http://www.theserverside.com/home/thread.jsp?thread_id=21257
is simply not true.

There are surely some points which can be improved to make the reuse of those components easier but you can just ask for this (therefore you have the community, right?) and Brian is very helpful. At the first step we are integrating the Business Component of LPortal (Bookmark Component) into OpenUSS and not yet the portlet itself. After this I'll write a step-by-step "docu HOW-TO" integrate LPortal Business Components into YOUR own applications.

Brian, I saw your roadmap:
* Integrate with an issue tracker
* Integrate with a project management and time tracker

You can check iTracker: http://sourceforge.net/projects/itracker/ for this purpose, maybe you can integrate it into LPortal? I've seen the code and also talked to the developer of itracker. It seems that it's also possible to integrate the Business Component. A good place to see the functionality of iTracker is (download the sourcecode and see):
\itracker\src\cowsultants\itracker\ejb\client\interfaces\*.*

iTracker would be also the next step to integrate in OpenUSS after LPortal ;-) I'm really looking forward to the Business Components integration of LPortal in OpenUSS!

Hope this helps and thanks!

Best regards,
Lofi.
http://www.openuss.org

We'll definitely make Liferay as open as possible so other projects can integrate easily. I'll check out itracker as well.

Thanks Lofi!

I agree that Liferay looks like a great implementation of many relevant standards and functions (relevant to me, anyway). I've checked out about 12 potential solutions including Python, PHP and Java solutions. Zope seems to be by far the richest and most mature, but for various reasons J2EE is best for my needs, and Liferay appears to be the most complete Open Source portal implementation I've seen.

I've seen Liferay's versatility at http://my.liferay.com, with what appears to be many user's data. Content management and workflows are areas where it may need work (though the document management facility seems nicely donem with versioning 'n' all); I hope Liferay proves out with standard, useable, leading edge solutions (perhaps by adopting a third party workflow solution like exo, another excellent, but interesting in different ways, portal implementation).

I am involved in non-commercial projects in government and health, and currently interactive software development and easy access to diverse data are themes. It appears that several developers are involved in Liferay's growth, which also seems to be going just where I need it to go. Keep it up! I hope to be able to contribute to the project in the future.

David

Hello David,

Can you explain :

"... like exo, another excellent, but interesting in different ways, portal implementation"

why different ways?

Cheers

Hi Benjamin,

Certainly, for an admirable project like yours I'd be glad to help in any way.

I've identified a need for discussion areas, login across all functions using very standard interfaces, content mangement with versioning, access and search, CVS and bug/change request tracking, and the ability to fit my specialized functionality into a reasonable, standard/open framework. Liferay has all that, along with a simple wiki, webmail, calendars, etc.

I realize a lot of this may be standard components, but ... they're there. And the more big buzzwords (portlets, ejb, struts, jaas, cm interfaces, etc) the better in real terms of involving people, creating a versatile system, and using what emerges as standard solutions to problems. (Ok, the last sentence with a BIT of skepticism, and with a minimum of configuration files, please - an integrated IDE [redundancy noted] would close the loop nicely).

Perhaps because of the principal developer's history with commercial Portal systems and his ability to apply his work to a community, Liferay seems to provide most of that today, and if my.liferay.com is any indication, in a very useable format that has withstood an initial, mixed set of visitors.

Exo appears to have some really advanced possibilities indicated by the software that is coming out for it, for example the integrated IRC server, use of AspectJ for content management, and so on. Sorry if I misunderstand any aspect of Exo, and I am really interested in the "personal proxy" idea where all a person and group's information, including for example IRC, can be accessed and organized. Exo seems to be far ahead in those terms, but it seems to be a bit more to bite off in terms of technology and development required to make it ready for users (in my sector, the definitive "regular people), despite the comprehensive documentation.

I don't expect every 'solution' to be the same in every way. And maybe in the future a better solution might emerge (and it could be Exo), but if Liferay lives up what I've seen so far, it would just seem to fufill my medium term requirements "out of the box" more completely.

Thank you for all your hard work! I hope the development stays strong. These open, standards based projects provide ways to cooperate so that people can choose among diverse, high quality components, and maybe we are reaching a plateau of integration. It is going to be very enabling for everyone involved.

David

Until the API is final and the eXo platform is certified, we decided to focus on the kernel (portlet container - portal - CMS) and to provide core portlets for the portal.

This is why - up to now - we emphased the technology solution and not really the use cases and related portlets. Lportal had another approch, they distribute many portlets and their associated EJB but the kernel will not be able to get certified (unless they use pluto, eXo portlet container or make quite hudge modifications). So I would suggest to use the eXo platform as your portal and port the lportal portlets. One goal of the JSR 168 is allow component portability, so you will see many more portlets on eXo very soon...

Anyway, the incoming beta3 version will be functionnal and it will include many new - home made - portlets.

Hi again Benjamin (if you are still around),

I appreciate your point of view, and understand that, in a sense, Lportal is "broad" rather than "deep," and in a different stage of evolution (possibly a less dynamic one than your own project). However, I need to focus on my medium term "business need" of having certain functionality in X months, while Lportal's JSR 168 conformance and exo's "out of the box" (where I want to be for the most part) facilities (interface and portlets) will hopefully improve.

In any case, I do need to focus on the content management aspect. I was really appreciative of Zope/Plone's "deep" concepts of content (and to a lesser degree workflow). It is easy to do rich searches across, and manage, diverse content, and there are many useful "products," whereas what I have seen of other solutions is more scattered. Can exo offer this today? It is hard to tell with the demo that is posted. I am definately going to track exo as it might have more promise in this area, and keep an eye out for good solutions.

Regards,

David

Hello David,

We will update the online demo as soon as the beta3 is out. With that functional version you will be able to access the CMS with a CMS portlet.

To say the truth, I have not used Zope but hope we can have as much functionnalities as you said. Come and post on our forum if you have suggestions, this is the best way to be sure you will get exactly what you want.

Lportal and the eXo platform are two very active concurent projects that have a different strategy, of course I hope and think the eXo's is better :). Anyway, we have quite good connections with Brian and I think that quite soon you will see all lportal portlets on eXo.

Cheers
Benjamin

Uportal seems to be the best choice because of large community and supported by Sun. In next release it will follow JSR168 and provide i18n.
How do you think about Uportal?

Seems that a few bit twiddles are Enamored with technology.

What is the business case?
Look at http://www.microsoft.com/sharepoint/server/evaluation/overview/technologies.asp, or PHP Nukes, or Plone or Zope, things that are successfully deployed.

Who cares about API, what does it do for me?
Security, CMS, Forums, ... things I can bill for.

I want a KISS platform, that lets me do something

basicPortal.com takes a "simplest" approach to accomplish business needs (Security, CMS, Forums, etc.) and de-emphasizes technology (Struts/Tiles/Display Tag/iBatis)

Kiss anyone?

.V

From personal experience, I can tell you that quite often off-the-shelf products like PHP Nuke don't fulfill the business requirements. Sometimes it's much better to have a looser skeleton and fill in the missing parts than to go with a finished solution and have to hack away at it... especially when you're dealing with open source products that you've modified the source for (specifically for your app), and then you want to try to upgrade.

So, if you can make the customer happy with a finished product, that's great. If you need to constantly maintain it for your employer, it's not so great.

The solutions you describe are simple and good when you control the entire site, or always deploy on the same portal. Then you don't care about API compatibility. That applies to more than just portlets - you don't need JDBC if you always use the same DB, for example. But once you don't control the whole site, or you have multiple portals containing your portlet, you begin to care a lot about API compatibility.

My own company is in that position. Part of what we sell bridges a system local government departments use internally to make it available online. We're not providing the whole .gov, just parts of the site, so it has to merge seamlessly with the rest of the site. The easiest way to do this is when they use a portal, and we can just present our content inside their site.

If we only had 1 customer doing this, it still wouldn't make sense for us to worry about a portlet API, but we have hundreds of customers, each of which has gone with a different portal vendor, or no portal at all (so we provide a microsite, themed like the rest of their site).

For us to sell to people using say, 20 different portals, as "portlets" of some kind, without a standard API, would mean us maintaining 20 separate portal integration layers. No thanks, thats not simple, its stupid, and expensive.

Again, you're dead right that the portlet API isn't needed if you intend to write the UI for the whole site yourself. But as soon as you need off-the-shelf components in a site, portlets win, and WSRP wins bigger (since it means we can support non-java portals).

-Baz

I reproduce here a comment I made on the eXo platform forums :

"Pluto is the Reference Implementation of the JSR 168 and its release is a good thing for portal vendors and for the community. It provides JSR 168 use cases examples and let us test the portability of our portlets and our portlet framework.

Portal vendors can choose to build their products on Pluto or build their own portlet container. We decided to implement our for several reasons :
*pluto was created by IBM and given to the Apache fundation. As IBM build a closed commercial product portal too...I think you get what I mean
*performance : most of RI have bad design... maybe to encourage use of non RI products
*receptivity : we prefer using a code we wrote, with unit tests in order to be receptive and quick to fix bugs.
*portability : pluto is tied to tomcat as we already provide JBoss and tomcat implementation.

Jetspeed 2 will use pluto and maybe Lportal too, so we will be the only platform with a coherent stack that has been design in the same way. That makes us more receptive and performant. We have an unified architecture that is also quite easy to grasp..."

Hi All,
        I am trying to pick a open source portal framework for a lightweight project. I really do not want to go the EJB way because my project is pretty lightweight. I was really interested in using Redhat WAF but 2 days of banging my head in the wall trying work with one of their nightly releases and I had enuff. Heard some pretty good things about liferay but I really do not want the complexity of an Application Server thrown into the mix. In the case of jetspeed looks like I will have to spend a lot of time learning Turbine/Velocity/Lucene blah blah. I am looking for a basic framework running inside a servlet container (preferably tomcat ) and easily extensible.
    Please let me know your recommendations.

Thanks Much

The eXo platform works - in its express edition - within a simple servlet engine like Tomcat or Jetty.