Tuesday, October 13, 2009

uPortal vs. Liferay Comparison

Someone recently asked on the uportal-user list for a comparison of uPortal 3.1.1 to Liferay 5.2.3. I'm not an expert on either, and this is just what I've noticed. Please jump in if I've left out anything, or if what I'm saying is incorrect. Note: his original question indicated that he was planning on integrating Shibboleth.

uPortal

Miscellaneous:

* By default uPortal uses CAS for authN. Some info for how to get Shibboleth setup is here: http://www.ja-sig.org/wiki/display/UPM31/03+Shibboleth and James Hong is the last one to indicate that he Shibbolized a recent version. We plan to eventually move to uP 3.1.1 (or later) and shibbolize it, but I just did a quick spike (test) of shibbing it (I wasn't able to keep it from hitting Login even on the guest view, but I'm guessing I was doing something wrong). If you have any trouble Shibbolizing, let the list know and maybe James can assist.
* uPortal has handful of portlets "under its wing" here: https://www.ja-sig.org/svn/portlets/ (note that not all of the portlets in the list at http://www.jasig.org/portlets are functional/have been tested in uPortal 3.1.1, but I assume the ones in https://www.ja-sig.org/svn/portlets/ have although I'm not sure totally. There are also a few built-in to the uPortal codebase itself (for administration, etc.).

Pros

* Community is more University/school focused: I think there are many more universities/schools using uPortal vs. those using Liferay, but it not strictly used by universities.
* Has a Jasig portlet adoption process so that if you do contribute something that you can help get to the point where it meets standards (including being Apache-licensed), you should have some help in maintaining it.
* Works closely with Fluid group, so there is innovation in development of UI that first was shown in uP 3.1.
* CAS is built-in. Since many use CAS, this is good for them!
* Webproxy portlet can be used to share existing/new web applications and web content in the portal (but you'd need to use CSS classes implemented in your uPortal skin(s)).
* They offer free use of their Jira, Confluence, and Subversion for portlet and uPortal-related project development and community frequently will work together on portlets.

Cons

* Not fully up-to-date on latest portlet standard: Although support was added in preparation for JSR-286, the latest release version of uPortal still uses JSR-168. Note: JSR-286 support is slated for uPortal 3.3.
* Upgrades are non-trivial: Upgrades have been stated to be non-trivial and probably will run into things that are not-documented, but recently code was provided that should assist greatly in uP 2.5.3 and uP 2.6.1 upgrades to uPortal 3.x, and the community and developers are willing to assist.
* Configuration/Usage/Development may be more difficult: From what I read and hear from others, uPortal is just more difficult to use than Liferay, however there is much greater support from the uPortal community to help you through it.
* CAS is built-in. If you don't use CAS, it might not be as well-tested with your type of authN.
* Wiki documentation is sometimes out-of-date and lacking. They welcome anyone to assist with documentation that wants to help though.

Liferay

Pros

* Sun contributes to Liferay (Sun basically gave up with OpenPortal project and took on Liferay).
* The latest release version of Liferay uses the latest portlet spec JSR286.
* Default portal is pretty slick/feels polished: while the UI of uPortal quickstart has certainly greatly improved, Liferay's default version/skin/UI of the portal feels more polished. However, this probably doesn't mean much because you will end up needing to reskin it for your implementation.
* There is a project for those interested in developing portlets using JRuby on Rails (but it is Liferay and JSR-286 specific even though they welcome development to make it work with other portals): http://rails-portlet.rubyforge.org/
* There is a project for those interested in developing portlets using Grails (may be is Liferay specific and I think still only supports JSR-168): http://grails.org/plugin/portlets
* There are probably more portlets available in Liferay and I think they have more developers working on the project and more users, but am not sure.

Cons

* Community is less university/school focused
* CAS not built-in (if you are using CAS).
* Community/forums not nearly as helpful for universities or in-general as responsive at getting people up-to-speed (at least that is from what I hear. I can say for certain that the uPortal developers and community are very helpful).

Unsure

* Don't know anything about ease of Liferay upgrades.

Both uPortal and Liferay

Pros

* Both portals are Java-based: Integration with existing/new Java libraries is easier. Since Java has a very large userbase and there is a lot written in Java, you can develop portlets to do just about anything you can think of and reuse existing libraries from Apache/Jakarta, Sourceforge, Codehaus, Springsource, Hibernate, etc. along with plugins for Maven 2, tasks for Ant, etc.
* Both are standards-based and have active development and user communities.

Cons

* Portals in-general aren't as hot as they were years ago. There has been a lot of movement towards applications that make it easier to publish communication (Confluence/MediaWiki, Drupal/Joomla) or just in web applications that are faster to develop ((J/C)Ruby on Rails, etc.). However, there is still a place for them and the ability for users to customize them and what content they see is a great asset, and as long as you focus on continuing to provide things that the users actually want and need (even things outside of the institution's normal realm), the implementation will likely do well.

Update: Check out this great comparison of uPortal 3.1 to Liferay 5.2 created on Jan 05, 2010 by the University of Washington.

3 comments:

Gary S. Weaver said...

Check out this great post by Oren Sreebny about his thoughts on the future of the enterprise portal. He does a much better job than I did in my last few sentences.

Andrew Petro said...

Since James Hong's fine work, others have Shibbolized uPortal, not least the University of Chicago. Shibbolizing uPortal isn't hard, and the resulting configuration depends on the depth of Shibbolization desired.

One resource for this: notes from the Jasig UnConference session on Shibbolization of uPortal and more generally this whole wiki space devoted to documenting uPortal-Shib integration.

Shib for authentication by use of the Shib SP module and configuring uPortal to rely on the Remote User security context or by simply configuring CAS to make use of the Shibboleth SP and the remote user (thereby achieving use of Shibbolized CAS, the best of all possible worlds!). No custom code required.

Shib for user attributes by use of available integrating implementations of the PersonAttributeDAO. This code already exists as well.

Shib for delegated authentication thanks to the fine work of Unicon, the University of Chicago, and the Shibboleth project itself. See the design and implementation page in the Internet2 wiki.

Andrew Petro said...

A quick link for anyone finding this post today and looking for information on Shibbolizing uPortal: there's now a lovely page in the uPortal manual on this topic, discussing Shibboleth for authentication, user attributes, and for delegated authentication.