Evaluating uPortal
|
|
Fang Lin
|
Some javascript/style in this post has been disabled (why?)
Dear uPortal Community, At University of Washington we are about to start an evaluation
project of portal frameworks as the replacement of our home-grown portal http://myuw.washington.edu/). The
two candidates that will be evaluated are uPortal 3.1.1 and Liferay 5.2.5. We
would be very grateful if folks have gone through the portal evaluation process
can provide some advices. Our implementation platform will be Linux, Apache, Tomcat
or Jetty, and the Shibboleth SP software for SSO support. Should we set
up the evaluation portal using the portal only installation or the Quick Start
version? What might be the limitations of using the Quick Start version for
evaluation? Has
there been any
comparative analysis of uPortal 3.x with Liferay 5.x? Thanks! Fang
Lin Email:
[hidden email] UW
Technology, University of Washington -- |
||||||||||||||||
Domazlicky, Eric
|
Some javascript/style in this post has been disabled (why?)
Fang- We run
uPortal at Tacoma Community College. uPortal can do about anything any
mainstream portal can do nowadays and the new AJAX UI that allows dragging and
dropping channels around, and adding channels easily is great. I don’t think
there is much disadvantage to using the Quickstart except that building your
Portal from the bare source tree will help you learn more about how it works,
which configuration files to modify etc. The quick-start is great to try it out
though. The one big disadvantage of uPortal is that everything is Java-based,
if you want to make custom portlets you basically have to do them in Java. You
can use WebProxy channel but I found WebProxy channels to be unreliable and
quirky. If your staff already is familiar with Java Web Development then you
should be fine. Let me know
if you have any questions and I can try to help out. --- Eric
Domazlicky Portal/Student
E-Mail Administrator Tacoma
Community College From: [hidden email]
[mailto:[hidden email]] On Behalf Of Fang Lin Dear uPortal Community, At University of Washington we are about to start an
evaluation project of portal frameworks as the replacement of our home-grown
portal http://myuw.washington.edu/).
The two candidates that will be evaluated are uPortal 3.1.1 and Liferay
5.2.5. We would be very grateful if folks have gone through the portal
evaluation process can provide some advices. Our implementation platform will be Linux, Apache, Tomcat
or Jetty, and the Shibboleth SP software for SSO support. Should we set
up the evaluation portal using the portal only installation or the Quick Start
version? What might be the limitations of using the Quick Start version for
evaluation? Has there been any comparative
analysis of uPortal 3.x with Liferay 5.x? Thanks! Fang Lin Email: [hidden email] UW Technology, University of
Washington -- You are currently subscribed to [hidden email] as: [hidden email] -- |
Gary Weaver
|
In reply to this post
by Fang Lin
Fang,
Here is a comparison (I'm not an expert on either, but this is what I've noticed- others please jump in if I've left out anything or if what I'm saying is incorrect): 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. * 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. Pros of both uPortal and Liferay: * 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 of both uPortal and Liferay: * 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. Hope that helps, Gary Fang Lin wrote: > > Dear uPortal Community, > > > > At University of Washington we are about to start an evaluation > project of portal frameworks as the replacement of our home-grown > portal http://myuw.washington.edu/). The two candidates that will be > evaluated are uPortal 3.1.1 and Liferay 5.2.5. We would be very > grateful if folks have gone through the portal evaluation process can > provide some advices. > > > > Our implementation platform will be Linux, Apache, Tomcat or Jetty, > and the Shibboleth SP software for SSO support. Should we set up the > evaluation portal using the portal only installation or the Quick > Start version? What might be the limitations of using the Quick Start > version for evaluation? > > > > Has there been any comparative analysis of uPortal 3.x with Liferay 5.x? > > > > Thanks! > > Fang Lin > > Email: [hidden email] > > UW Technology, University of Washington > > > > -- > > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
Jen Bourey-2
|
In reply to this post
by Domazlicky, Eric
Some adopters have successfully used various WebProxy solutions to allow the integration of non-Java-based projects. Yale in particular has had a good deal of success with this strategy.
It's true that WebProxy has some drawbacks, particularly if the to-be-proxied site has a lot of javascript or custom CSS. That solution really works best when content is developed specifically with the portal in mind. It's possible to design an application (or a particular UI front-end for an application) that is specifically tailored to the portal. Some schools have successfully used a web proxy strategy even with Java projects in order to decouple the release and upgrade timelines of the portal and the portal's content. I'd agree that the current Web Proxy Portlet can be confusing to configure, and a number of bugs in the 3.1 branch have made the channel manager interface difficult to use. However, the upcoming release of uPortal will have a shiny new portlet management tool that should make portlet administration much more pleasant (http://www.ja-sig.org/wiki/display/UPC/Portlet+Administration+Portlet for a preview). - Jen On Mon, Oct 12, 2009 at 7:46 PM, Domazlicky, Eric <[hidden email]> wrote:
-- Jen Bourey -- |
||||||||||||||||
Jim Helwig-2
|
In reply to this post
by Fang Lin
FWIW, we use over 20 WebProxy portlets in our portal and find them to be very reliable. Note that this is with the portlet version; I am unfamiliar with the channel version.
It is very flexible and has allowed us to proxy home grown sites and applications as well as vendor applications. In fact, we have even demonstrated proxying PeopleSoft. One tricky bit, though, is proxying JavaScript. AJAX can be tricky, especially when you are dealing with closed source applications. JimH on 10/12/2009 6:46 PM Domazlicky, Eric said the following: > ..snip... > You can use WebProxy channel but I found WebProxy channels to be unreliable > and quirky. --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
|
Domazlicky, Eric
|
Maybe it's the version I am using (haven't tried it since the new
improvements). The persistent problem I have is that if you try to send the username attribute to a proxied page it works the first time, but the next time it won't send the username. Javascript and the POST backing mechanism of ASP.NET applications has also been problematic for me. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Jim Helwig Sent: Tuesday, October 13, 2009 9:09 AM To: [hidden email] Subject: Re: [uportal-user] Evaluating uPortal FWIW, we use over 20 WebProxy portlets in our portal and find them to be very reliable. Note that this is with the portlet version; I am unfamiliar with the channel version. It is very flexible and has allowed us to proxy home grown sites and applications as well as vendor applications. In fact, we have even demonstrated proxying PeopleSoft. One tricky bit, though, is proxying JavaScript. AJAX can be tricky, especially when you are dealing with closed source applications. JimH on 10/12/2009 6:46 PM Domazlicky, Eric said the following: > ..snip... > You can use WebProxy channel but I found WebProxy channels to be unreliable > and quirky. --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
Susan Bramhall
|
Some javascript/style in this post has been disabled (why?)
I think that was an old bug in CWebProxy channel. You are much better
off using the Web Proxy Portlet that ships with uPortal 3.x.Susan Domazlicky, Eric wrote: Maybe it's the version I am using (haven't tried it since the new improvements). The persistent problem I have is that if you try to send the username attribute to a proxied page it works the first time, but the next time it won't send the username. Javascript and the POST backing mechanism of ASP.NET applications has also been problematic for me. -----Original Message----- From: [hidden email] [[hidden email]] On Behalf Of Jim Helwig Sent: Tuesday, October 13, 2009 9:09 AM To: [hidden email] Subject: Re: [uportal-user] Evaluating uPortal FWIW, we use over 20 WebProxy portlets in our portal and find them to be very reliable. Note that this is with the portlet version; I am unfamiliar with the channel version. It is very flexible and has allowed us to proxy home grown sites and applications as well as vendor applications. In fact, we have even demonstrated proxying PeopleSoft. One tricky bit, though, is proxying JavaScript. AJAX can be tricky, especially when you are dealing with closed source applications. JimH on 10/12/2009 6:46 PM Domazlicky, Eric said the following: --
Susan Bramhall ([hidden email]) -- |
||||||||||||||||
|
Fang Lin
|
In reply to this post
by Jim Helwig-2
Thank you all!
It's very helpful to know that the Web Proxy Portlet is reliable and issues to watch out. We will rely on it for integrating most of our personal contents. Some of them do load multiple JavaScript and CSS files in the channel content, perform a transaction and then refresh the channel via JS. Does uPortal support integration with Enterprise Directory Service via RESTful Web Services API? -Fang -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Jim Helwig Sent: Tuesday, October 13, 2009 9:09 AM To: [hidden email] Subject: Re: [uportal-user] Evaluating uPortal FWIW, we use over 20 WebProxy portlets in our portal and find them to be very reliable. Note that this is with the portlet version; I am unfamiliar with the channel version. It is very flexible and has allowed us to proxy home grown sites and applications as well as vendor applications. In fact, we have even demonstrated proxying PeopleSoft. One tricky bit, though, is proxying JavaScript. AJAX can be tricky, especially when you are dealing with closed source applications. JimH on 10/12/2009 6:46 PM Domazlicky, Eric said the following: > ..snip... > You can use WebProxy channel but I found WebProxy channels to be unreliable > and quirky. --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
|
Fang Lin
|
In reply to this post
by Gary Weaver
Hi Gray,
I will share your inputs with my team, thank you!! On UW campus there are still a lot of expectations on the conventional enterprise web portal. It seems too early to let go with it. We also realize that the portal won't meet all the needs. See Oren Sreebny's blog: http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/ and comments made by David Lassner, CIO of University of Hawaii, and Cliff Frost, their chief tech architect. -Fang -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Weaver Sent: Tuesday, October 13, 2009 7:37 AM To: [hidden email] Cc: Janice C. Granberg; Leman Chung Subject: Re: [uportal-user] Evaluating uPortal Fang, Here is a comparison (I'm not an expert on either, but this is what I've noticed- others please jump in if I've left out anything or if what I'm saying is incorrect): 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. * 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. Pros of both uPortal and Liferay: * 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 of both uPortal and Liferay: * 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. Hope that helps, Gary Fang Lin wrote: > > Dear uPortal Community, > > > > At University of Washington we are about to start an evaluation > project of portal frameworks as the replacement of our home-grown > portal http://myuw.washington.edu/). The two candidates that will be > evaluated are uPortal 3.1.1 and Liferay 5.2.5. We would be very > grateful if folks have gone through the portal evaluation process can > provide some advices. > > > > Our implementation platform will be Linux, Apache, Tomcat or Jetty, > and the Shibboleth SP software for SSO support. Should we set up the > evaluation portal using the portal only installation or the Quick > Start version? What might be the limitations of using the Quick Start > version for evaluation? > > > > Has there been any comparative analysis of uPortal 3.x with Liferay 5.x? > > > > Thanks! > > Fang Lin > > Email: [hidden email] > > UW Technology, University of Washington > > > > -- > > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
|
Gary Weaver
|
Fang,
Glad that helped. I definitely was not suggesting for UW to abandon the concept of a portal. I was just trying to present both sides. Thanks for passing on the great post by Oren! The less people that people talk about something, the more that people will think it is not worth talking about. It would be great to hear some feedback on what the rest of the Jasig community thinks about uPortal vs. Liferay vs. other portals. Perhaps this could help identify features/enhancements that might benefit from more focus of development over others. I could be wrong though. Take care, Gary Fang Lin wrote: > Hi Gray, > > I will share your inputs with my team, thank you!! > > On UW campus there are still a lot of expectations on the conventional enterprise web portal. It seems too early to let go with it. > > We also realize that the portal won't meet all the needs. See Oren Sreebny's blog: > http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/ and comments made by David Lassner, CIO of University of Hawaii, and Cliff Frost, their chief tech architect. > > -Fang > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Weaver > Sent: Tuesday, October 13, 2009 7:37 AM > To: [hidden email] > Cc: Janice C. Granberg; Leman Chung > Subject: Re: [uportal-user] Evaluating uPortal > > Fang, > > Here is a comparison (I'm not an expert on either, but this is what I've > noticed- others please jump in if I've left out anything or if what I'm > saying is incorrect): > > 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. > * 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. > > Pros of both uPortal and Liferay: > * 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 of both uPortal and Liferay: > * 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. > > Hope that helps, > > Gary > > > Fang Lin wrote: > >> Dear uPortal Community, >> >> >> >> At University of Washington we are about to start an evaluation >> project of portal frameworks as the replacement of our home-grown >> portal http://myuw.washington.edu/). The two candidates that will be >> evaluated are uPortal 3.1.1 and Liferay 5.2.5. We would be very >> grateful if folks have gone through the portal evaluation process can >> provide some advices. >> >> >> >> Our implementation platform will be Linux, Apache, Tomcat or Jetty, >> and the Shibboleth SP software for SSO support. Should we set up the >> evaluation portal using the portal only installation or the Quick >> Start version? What might be the limitations of using the Quick Start >> version for evaluation? >> >> >> >> Has there been any comparative analysis of uPortal 3.x with Liferay 5.x? >> >> >> >> Thanks! >> >> Fang Lin >> >> Email: [hidden email] >> >> UW Technology, University of Washington >> >> >> >> -- >> >> You are currently subscribed to [hidden email] as: [hidden email] >> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user >> > > > --- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user > > --- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user > > --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
|
Fang Lin
|
Gary,
Personally I do have some concerns about how long the conventional enterprise web portal will last. UW just adopted Google Apps Education Edition (GAEE). We did a brief investigation to see if iGoogle can be used as the portal platform; it is summarized below: "GAEE has no conventional enterprise portal. Alternatively, Google Sites are where we present personalized contents to users and have total control of the user interface. The personal contents are delivered on Google Sites via Google Gadgets, which may be further configured by the users. The users may add the gadgets onto their iGoogle pages where they have the total control. But users can not change the layout of the Google Sites. Google Sites can be configured to allow only authorized users to access to the content and gadgets." When we finish our evaluation we will be happy to share our report here. Warm regards, -Fang -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Weaver Sent: Wednesday, October 14, 2009 7:42 AM To: [hidden email] Subject: Re: [uportal-user] Evaluating uPortal Fang, Glad that helped. I definitely was not suggesting for UW to abandon the concept of a portal. I was just trying to present both sides. Thanks for passing on the great post by Oren! The less people that people talk about something, the more that people will think it is not worth talking about. It would be great to hear some feedback on what the rest of the Jasig community thinks about uPortal vs. Liferay vs. other portals. Perhaps this could help identify features/enhancements that might benefit from more focus of development over others. I could be wrong though. Take care, Gary Fang Lin wrote: > Hi Gray, > > I will share your inputs with my team, thank you!! > > On UW campus there are still a lot of expectations on the conventional enterprise web portal. It seems too early to let go with it. > > We also realize that the portal won't meet all the needs. See Oren Sreebny's blog: > http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/ and comments made by David Lassner, CIO of University of Hawaii, and Cliff Frost, their chief tech architect. > > -Fang > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Weaver > Sent: Tuesday, October 13, 2009 7:37 AM > To: [hidden email] > Cc: Janice C. Granberg; Leman Chung > Subject: Re: [uportal-user] Evaluating uPortal > > Fang, > > Here is a comparison (I'm not an expert on either, but this is what I've > noticed- others please jump in if I've left out anything or if what I'm > saying is incorrect): > > 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. > * 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. > > Pros of both uPortal and Liferay: > * 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 of both uPortal and Liferay: > * 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. > > Hope that helps, > > Gary > > > Fang Lin wrote: > >> Dear uPortal Community, >> >> >> >> At University of Washington we are about to start an evaluation >> project of portal frameworks as the replacement of our home-grown >> portal http://myuw.washington.edu/). The two candidates that will be >> evaluated are uPortal 3.1.1 and Liferay 5.2.5. We would be very >> grateful if folks have gone through the portal evaluation process can >> provide some advices. >> >> >> >> Our implementation platform will be Linux, Apache, Tomcat or Jetty, >> and the Shibboleth SP software for SSO support. Should we set up the >> evaluation portal using the portal only installation or the Quick >> Start version? What might be the limitations of using the Quick Start >> version for evaluation? >> >> >> >> Has there been any comparative analysis of uPortal 3.x with Liferay 5.x? >> >> >> >> Thanks! >> >> Fang Lin >> >> Email: [hidden email] >> >> UW Technology, University of Washington >> >> >> >> -- >> >> You are currently subscribed to [hidden email] as: [hidden email] >> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user >> > > > --- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user > > --- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user > > --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
Dwight Raum
|
Fang,
I have to agree with some of the sentiments you've expressed. We see the era of portals as a heavy application stack coming to an end too. As much as possible, we've modeled our implementation of uPortal (myJohnsHopkins) to minimize heavyweight dependencies, and to use uPortal as more of a lightweight container for personalization and aggregation. To that end, here are some key things we've done: * Integration: We rely heavily upon existing services within the enterprise -- this includes our enterprise directory, groups management (Active Directory), content management (SiteExecutive), institutional calendar (ActiveData Calendar), and SSO (CA SiteMinder). uPortal is pretty good at doing this, especially on the directory side of things. We have configured the SmartLdapGroupStore against our Active Directory, and we also use PAGS extensively for dynamic group mappings, and as a result have become largely independent of uPortal's local groups management structures altogether. Also, we pretty much avoid using proper JSR-168 portlets, particularly since they must live within the same JVM as uPortal. Early on we experienced stability problems with the uPortal environment due to independent issues within a specific homegrown portlet. This lack of compartmentalization between the portal and portlets is significant, and affects not only reliability but also scalability. Instead, we make extensive use of the WebProxy portlet -- this is absolutely key to our content and apps strategy. We've developed a custom pre-interceptor for WebProxyPortlet to pass along person-attributes through the proxied requests. The reliance on WebProxyPortlet also allows us to scale our apps and content their source. There is still burden on uPortal to personalize and aggregate, but a resource intensive application has little effect on the overall performance of uPortal. The tradeoffs are that apps are not intimately intertwined with the portal stack, and can be 'limited' in their UI. By devolving our content/apps to most basic forms, we've effectively diminished our dependencies so we're not 'locked' into a portal framework. * Delegated administration: Hopkins is a very decentralized place -- apps and content are administered all over the place. It would be impossible, organizationally, to centralize administration of content for our audiences. With the Portal, our ultimate end goal is to pass off the drudgeries of simple content and layout management to non-technical "content owners" of each sub-section within our portal. Because we're trying to leverage our existing services for directory, groupings, apps and content, it made little sense to pull their administration into uPortal. Our constituent services already have a reasonable set of tools for delegated administration, and by relying on them to provide their services to uPortal we've sidestepped some administration issues. One area where we couldn't sidestep uPortal is DLM Fragment Administration; however, working with Unicon we've implemented tools within uPortal that allow for better delegated management. These tools are used extensively by our communities to manage and maintain their respective areas of myJohnsHopkins. * URL based personalization: Since we're so decentralized, we've extended our single instance of uPortal to support multiple identities. So for example: http://my.jhmi.edu http://my.jhu.edu http://insider.sais-jhu.edu http://myep.jhu.edu These are all actually part of the same instance of uPortal, but the environment is flexible enough that we can deliver a unique experience based upon entry URL. We also employ uPortal template users to dynamically apply the initial user skin setting derived from enterprise directory data. So, like many technology answers "it depends". We've been very successful in using uPortal as a lightweight framework to personalize and aggregate content & applications. We also have a lot of the services necessary to implement a portal in our environment, and little desire to re-invent the wheel. The model for personalization and use of groups for uPortal is quite good, and when coupled with delegation is incredibly powerful. Thanks, Dwight Raum Director Enterprise Services, Johns Hopkins [hidden email] -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Fang Lin Sent: Wednesday, October 14, 2009 1:12 PM To: [hidden email] Subject: RE: [uportal-user] Evaluating uPortal Gary, Personally I do have some concerns about how long the conventional enterprise web portal will last. UW just adopted Google Apps Education Edition (GAEE). We did a brief investigation to see if iGoogle can be used as the portal platform; it is summarized below: "GAEE has no conventional enterprise portal. Alternatively, Google Sites are where we present personalized contents to users and have total control of the user interface. The personal contents are delivered on Google Sites via Google Gadgets, which may be further configured by the users. The users may add the gadgets onto their iGoogle pages where they have the total control. But users can not change the layout of the Google Sites. Google Sites can be configured to allow only authorized users to access to the content and gadgets." When we finish our evaluation we will be happy to share our report here. Warm regards, -Fang -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Weaver Sent: Wednesday, October 14, 2009 7:42 AM To: [hidden email] Subject: Re: [uportal-user] Evaluating uPortal Fang, Glad that helped. I definitely was not suggesting for UW to abandon the concept of a portal. I was just trying to present both sides. Thanks for passing on the great post by Oren! The less people that people talk about something, the more that people will think it is not worth talking about. It would be great to hear some feedback on what the rest of the Jasig community thinks about uPortal vs. Liferay vs. other portals. Perhaps this could help identify features/enhancements that might benefit from more focus of development over others. I could be wrong though. Take care, Gary Fang Lin wrote: > Hi Gray, > > I will share your inputs with my team, thank you!! > > On UW campus there are still a lot of expectations on the conventional enterprise web portal. It seems too early to let go with it. > > We also realize that the portal won't meet all the needs. See Oren Sreebny's blog: > http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/ and comments made by David Lassner, CIO of University of Hawaii, and Cliff Frost, their chief tech architect. > > -Fang > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Weaver > Sent: Tuesday, October 13, 2009 7:37 AM > To: [hidden email] > Cc: Janice C. Granberg; Leman Chung > Subject: Re: [uportal-user] Evaluating uPortal > > Fang, > > Here is a comparison (I'm not an expert on either, but this is what I've > noticed- others please jump in if I've left out anything or if what I'm > saying is incorrect): > > 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. > * 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. > > Pros of both uPortal and Liferay: > * 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 of both uPortal and Liferay: > * 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. > > Hope that helps, > > Gary > > > Fang Lin wrote: > >> Dear uPortal Community, >> >> >> >> At University of Washington we are about to start an evaluation >> project of portal frameworks as the replacement of our home-grown >> portal http://myuw.washington.edu/). The two candidates that will be >> evaluated are uPortal 3.1.1 and Liferay 5.2.5. We would be very >> grateful if folks have gone through the portal evaluation process can >> provide some advices. >> >> >> >> Our implementation platform will be Linux, Apache, Tomcat or Jetty, >> and the Shibboleth SP software for SSO support. Should we set up the >> evaluation portal using the portal only installation or the Quick >> Start version? What might be the limitations of using the Quick Start >> version for evaluation? >> >> >> >> Has there been any comparative analysis of uPortal 3.x with Liferay 5.x? >> >> >> >> Thanks! >> >> Fang Lin >> >> Email: [hidden email] >> >> UW Technology, University of Washington >> >> >> >> -- >> >> You are currently subscribed to [hidden email] as: [hidden email] >> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user >> > > > --- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user > > --- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user > > --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
|
Fang Lin
|
Dwight,
This is going to be very helpful to set the integration strategy at UW. Thank you so much for sharing your insights! I have learned that Johns Hopkins has developed a mobile version of the portal (http://www.jasig.org/johns-hopkins-university-selects-unicon-). Could you also share the status of that project? -Fang -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Dwight Raum Sent: Friday, October 16, 2009 1:39 PM To: [hidden email] Subject: RE: [uportal-user] Evaluating uPortal Fang, I have to agree with some of the sentiments you've expressed. We see the era of portals as a heavy application stack coming to an end too. As much as possible, we've modeled our implementation of uPortal (myJohnsHopkins) to minimize heavyweight dependencies, and to use uPortal as more of a lightweight container for personalization and aggregation. To that end, here are some key things we've done: * Integration: We rely heavily upon existing services within the enterprise -- this includes our enterprise directory, groups management (Active Directory), content management (SiteExecutive), institutional calendar (ActiveData Calendar), and SSO (CA SiteMinder). uPortal is pretty good at doing this, especially on the directory side of things. We have configured the SmartLdapGroupStore against our Active Directory, and we also use PAGS extensively for dynamic group mappings, and as a result have become largely independent of uPortal's local groups management structures altogether. Also, we pretty much avoid using proper JSR-168 portlets, particularly since they must live within the same JVM as uPortal. Early on we experienced stability problems with the uPortal environment due to independent issues within a specific homegrown portlet. This lack of compartmentalization between the portal and portlets is significant, and affects not only reliability but also scalability. Instead, we make extensive use of the WebProxy portlet -- this is absolutely key to our content and apps strategy. We've developed a custom pre-interceptor for WebProxyPortlet to pass along person-attributes through the proxied requests. The reliance on WebProxyPortlet also allows us to scale our apps and content their source. There is still burden on uPortal to personalize and aggregate, but a resource intensive application has little effect on the overall performance of uPortal. The tradeoffs are that apps are not intimately intertwined with the portal stack, and can be 'limited' in their UI. By devolving our content/apps to most basic forms, we've effectively diminished our dependencies so we're not 'locked' into a portal framework. * Delegated administration: Hopkins is a very decentralized place -- apps and content are administered all over the place. It would be impossible, organizationally, to centralize administration of content for our audiences. With the Portal, our ultimate end goal is to pass off the drudgeries of simple content and layout management to non-technical "content owners" of each sub-section within our portal. Because we're trying to leverage our existing services for directory, groupings, apps and content, it made little sense to pull their administration into uPortal. Our constituent services already have a reasonable set of tools for delegated administration, and by relying on them to provide their services to uPortal we've sidestepped some administration issues. One area where we couldn't sidestep uPortal is DLM Fragment Administration; however, working with Unicon we've implemented tools within uPortal that allow for better delegated management. These tools are used extensively by our communities to manage and maintain their respective areas of myJohnsHopkins. * URL based personalization: Since we're so decentralized, we've extended our single instance of uPortal to support multiple identities. So for example: http://my.jhmi.edu http://my.jhu.edu http://insider.sais-jhu.edu http://myep.jhu.edu These are all actually part of the same instance of uPortal, but the environment is flexible enough that we can deliver a unique experience based upon entry URL. We also employ uPortal template users to dynamically apply the initial user skin setting derived from enterprise directory data. So, like many technology answers "it depends". We've been very successful in using uPortal as a lightweight framework to personalize and aggregate content & applications. We also have a lot of the services necessary to implement a portal in our environment, and little desire to re-invent the wheel. The model for personalization and use of groups for uPortal is quite good, and when coupled with delegation is incredibly powerful. Thanks, Dwight Raum Director Enterprise Services, Johns Hopkins [hidden email] -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Fang Lin Sent: Wednesday, October 14, 2009 1:12 PM To: [hidden email] Subject: RE: [uportal-user] Evaluating uPortal Gary, Personally I do have some concerns about how long the conventional enterprise web portal will last. UW just adopted Google Apps Education Edition (GAEE). We did a brief investigation to see if iGoogle can be used as the portal platform; it is summarized below: "GAEE has no conventional enterprise portal. Alternatively, Google Sites are where we present personalized contents to users and have total control of the user interface. The personal contents are delivered on Google Sites via Google Gadgets, which may be further configured by the users. The users may add the gadgets onto their iGoogle pages where they have the total control. But users can not change the layout of the Google Sites. Google Sites can be configured to allow only authorized users to access to the content and gadgets." When we finish our evaluation we will be happy to share our report here. Warm regards, -Fang -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Weaver Sent: Wednesday, October 14, 2009 7:42 AM To: [hidden email] Subject: Re: [uportal-user] Evaluating uPortal Fang, Glad that helped. I definitely was not suggesting for UW to abandon the concept of a portal. I was just trying to present both sides. Thanks for passing on the great post by Oren! The less people that people talk about something, the more that people will think it is not worth talking about. It would be great to hear some feedback on what the rest of the Jasig community thinks about uPortal vs. Liferay vs. other portals. Perhaps this could help identify features/enhancements that might benefit from more focus of development over others. I could be wrong though. Take care, Gary Fang Lin wrote: > Hi Gray, > > I will share your inputs with my team, thank you!! > > On UW campus there are still a lot of expectations on the conventional enterprise web portal. It seems too early to let go with it. > > We also realize that the portal won't meet all the needs. See Oren Sreebny's blog: > http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/ and comments made by David Lassner, CIO of University of Hawaii, and Cliff Frost, their chief tech architect. > > -Fang > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Weaver > Sent: Tuesday, October 13, 2009 7:37 AM > To: [hidden email] > Cc: Janice C. Granberg; Leman Chung > Subject: Re: [uportal-user] Evaluating uPortal > > Fang, > > Here is a comparison (I'm not an expert on either, but this is what I've > noticed- others please jump in if I've left out anything or if what I'm > saying is incorrect): > > 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. > * 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. > > Pros of both uPortal and Liferay: > * 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 of both uPortal and Liferay: > * 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. > > Hope that helps, > > Gary > > > Fang Lin wrote: > >> Dear uPortal Community, >> >> >> >> At University of Washington we are about to start an evaluation >> project of portal frameworks as the replacement of our home-grown >> portal http://myuw.washington.edu/). The two candidates that will be >> evaluated are uPortal 3.1.1 and Liferay 5.2.5. We would be very >> grateful if folks have gone through the portal evaluation process can >> provide some advices. >> >> >> >> Our implementation platform will be Linux, Apache, Tomcat or Jetty, >> and the Shibboleth SP software for SSO support. Should we set up the >> evaluation portal using the portal only installation or the Quick >> Start version? What might be the limitations of using the Quick Start >> version for evaluation? >> >> >> >> Has there been any comparative analysis of uPortal 3.x with Liferay 5.x? >> >> >> >> Thanks! >> >> Fang Lin >> >> Email: [hidden email] >> >> UW Technology, University of Washington >> >> >> >> -- >> >> You are currently subscribed to [hidden email] as: [hidden email] >> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user >> > > > --- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user > > --- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user > > --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
