Forum .LRN Q&A: Info on other academic portals

Posted by Michael Feldstein on
This article has an overview of what could be viewed as dotLRN's
competition, at least in higher education:

Of particular interest is the links to several example portals. Check
out, for example, UC Davis' description of their portal architecture:

Posted by Alfred Essa on
The most important portal initiative in higher education is uPortal. It's based on J2EE and XML and is gaining a lot of traction fast. It would be useful for folks in the OpenACS community to do a technology and feature comparison.
Posted by Michael Feldstein on
At first glance, it looks like uCampus' portlets communicate strictly via XML (especially RDF). It would be a good thing if dotLRN and OpenACS went in the same direction, not only for interoperability purposes but also to open up the possibility of content syndication.
Posted by Carl Robert Blesius on
Here is some architectural information on uPortal:

In uPortal, each separate little window of information that users can show on their pages is called a "channel". uPortal supports four basic kinds of channels: An ordinary URL (i.e. a normal web page), an RSS document, an applet, and a servlet.  After a user is logged-in the security context is available to channels via channelStaticData.

More here:

What uPortal seems to have nailed down with this structure is a nice presentation layer for various information resources on a organizational level. Integration with existing campus infrastructure seems to be simplified by the platform. I am not sure how much of a two way street it is, but it sounds really interesting.

Here is the first sentence from the architecture overview:
uPortal is a framework for an integrated delivery of content gathered from an assortment
of information sources. The primary function of the framework is to provide efficient and
flexible engine for assembling a presentation. Given a set of information sources
(channels), and a recipe on how to arrange and frame them (stylesheets), uPortal
framework coordinates the compilation of the final document.

I think dotLRN will offer similar "channel" functionality with the dotLRN-applets Ben has mentioned in the bboards. Obviously dotLRN is more than a data collection and presentation tool. dotLRN has course management facilities that are absent in uPortal. As more ACS modules get ported and new ones are created they will become the key selling point for dotLRN. dotLRN will reach critical mass very quickly as soon as more institutions adopt it and we work on marketing it a little.

On another note, WebCT recently reported support for the uPortal platform with a "channel utility" which facilitates the export of an XML Channel from WebCT to uPortal. This allows institutions using the WebCT course management system and uPortal to provide users with access to their WebCT course listings and campus announcements through uPortal. WebCT's uPortal Channel Utility also enables single sign-on between uPortal and WebCT, eliminating the need for students using both systems to enter multiple ids and passwords.

The beauty of dotLRN is the simplicity (and scalability) of the platform on which it is built and the library of tried and tested community building tools that are waiting to be added. It seems that uPortal just adds another layer of complexity to the cake.

Once again, the single sign-on feature is a needed function for implementing a system like dotLRN in large institutions (like my own). No one is interested in starting yet another user database. This kind of integration is something that we need to work on as soon as possible.

Posted by Caroline Meeks on
dotLRN as an uPortal channel

I went to the uPortal tutorial to learn about our open source competition.  Instead I may have found an excellent cooperative marketing opportunity.

The tutorial was a series of case studies by universities that have used uPortal to implement a portal for students or in some cases just staff.  Organizations chose uPortal when they already had the functionality they needed in various different systems and want to provide an integrated view.  uPortal seems to especially appeal to universities with a large number of home grown systems.

uPortals is small.  They said you could read the source in an evening.

Most of the systems demoed had a portlet/channel into their course management system (blackboard, WebCT).  This portlet was not very sophisticated, the one I saw just listed the classes the user was a member of and provided one click access to the class page.  The WebCT press release says their channel provides class links and announcements.

The hardest part is one login authentication. At this seminar, many of the universities launched initial systems without one login authentication then started a second project just for authentication.  One university found they had literally 20 systems each with a potentially different login name/password.

I will try to learn more about uPortal and what class management systems are providing in their channel while I’m at EduCause

Meanwhile, if any of our Java hackers were inspired to download and install uPortal and see if it really is as easy as it looks to create the myGroups portlet as a channel, I think it would be awesome marketing for dotLRN.

Potential advantages of marketing dotLRN to uPortal customers and developers:

1.    They have already chosen an open source product.

2.    They have already picked a path that requires internal developers, sysadmins etc. and/or small company consultants.

3.    uPortal implementers already understand they need another system for course management.

4.    dotLRN provides a free-open source alternative to an organization that has already shown that they care about reducing licensing fees.

5.    dotLRN/OACS provides rich functionality not yet available as an uPortal channel.

6.    Although BlackBoard and other companies are starting to provide APIs that could be used to create channels, the users at this seminar worried that the APIs would not actually allow them all the functionality they needed.  A completely open source product allows whatever level of integration they choose to program.

7.    uPortal has wide name recognition and a well developed infrastructure with user and developer meeting throughout the year.

8.    An OpenACS/dotLRN consulting company could expand their market by also becoming a uPortal consulting company.

Posted by defunct defunct on
Hmm... interesting. i may have a look if I get time this week.

'An OpenACS/dotLRN consulting company could expand their market by also becoming a uPortal consulting company. '

If its really as small as you say, I can't see much of an opportunity there ;)

But I can see where you're coming from so it does make sense.

Posted by Roberto Mello on
Here at USU they were looking for a portal system and I pitched dotLRN. They were interested but their mainframe software maker (handles all classes and grades, etc) made a channel (or however it's called) to a (very expensive, requiring very expensive hardware) uPortal-based Java product, AFAIK.

So the idea of making dotlrn functionality available as uPortal channels is not a bad one at all.

Posted by Dan Wickstrom on
uPortal appears to be a servlet application that will run in any compliant servlet containter.  As far as reading the source in one evening, that might have been true for the first version, but the second version appears to have grown significantly.  There are 260 .java files, and I think you would be in for a very long evening if you planned to read all of the source in one sitting.

I downloaded their quick-start application (includes tomcat, ant, and a Hypersonic SQL db).  The application was easy to setup and start, but it threw an execption when I went to the start page, so I couldn't really get a good feel for what it was about.

Posted by Alfred Essa on
If we can use uPortal + dotLRN, it would be a glorious combination for a variety of reasons.

First, uPortal has a lot of traction in the academic community and is gaining significant momentum. Some of the institutions involved include Yale and Princeton. There are also certain problems that they are attacking and there could be a nice division of labor.

Second, this also gives dotLRN / OpenACS a good solution to the vexing marketing question about Java vs TCL. When we started down this road, I remember having a conversation about this with Ben. His answer, which made eminent sense to me, was "Why port everything from TCL to Java? What's the sense of that, especially if there is a way in which we can utilize Java classes/servlets from within OpenACS." I think he was referring to ns_java. So, here it is. Here is a Java app/solution that we might wish to take advantage of. From a marketing perspective this will be phenomenal, because we no longer have to say it's either/or (TCL or Java). Here's a Java implementation and it's just part of the architecture.

If the community and the dotLRN Technical Advisory Board agree that this is a good way to go, I can try to secure some funding for people to begin working on this.

Posted by Caroline Meeks on
uPortal has a station inside the Sun Booth.  I spoke with a representative there who said that some other open source course management projects were also working on connecting up with uPortal.  He also stated they are working on a web services based channel implementation to support non-java channels.  That is good news for the future but probably in the short run it will be faster for us to use ns_java then wait for them to finish their Web Services interface.

I also stopped by the Campus Pipeline booth.  They are using uPortal as their top level portal to integrate their various products.  When you look at the first page of the demo at their booth you see uPortal. If you drill into a class you see another page that looks like a portal page but is actually powered by a content management system not uPortal.  Their top level page did not have as broad or deep aggregation of group data as SloanSpace’s mySpace.

Integration with uPortal seems to fall along a continuum described as:

1.    A link to the other site requiring an additional login. - Princeton’s site seems to have many of these to legacy systems including Blackboard and Oracle’s WebDB

2.    A link with single login - Blackboard is now supporting this level

3.    A link to each class, similar to the myGroups portlet - Cal Poly used Blackboards APIs to create this and everyone seemed impressed.

4.    MyGroups plus group announcements brought to the top level - WebCT is supporting this level.

5.    Use of uPortal as the entry user interface for the system - Campus Pipeline. My guess is this was much cheaper then building their own portal system.

UPortal is involved with standards creation for Portals.  I am supposed to be getting more links on that in email and will post.  As a long range vision: If the rewrite of new-portals is a move towards industry standards then developers for different implementations of dotLRN could fairly easily vary the level of integration with uPortal, or even a commercial portal system that supported standards, to meet the needs of their specific organization.

Posted by Dan Wickstrom on
I was able to get uPortal version 2.0 working, and It looks nice.  It seems they have spent alot of effort on the presentation/templating layer (they use xslt), and I can see why it would be popular for aggregating a bunch of legacy systems.

It's interesting to note that it seems very similar in structure to dotLRN portlets, except uPortal has a more polished appearance.  I don't think it would be too difficult to recreate the uPortal functionality in openacs/dotLRN.

In order to have a seamless integration for a channel, it seems that it would be necessary to use either a servlet, or an applet based channel.  I've always disliked applets, as they invariably crash my browser, and they take too long to download, if they have any significant functionality.  Therefore, I think the servlet based channel approach would be the best method for implementing a new channel to dotLRN.

Servlets could use a variety of methods for collecting the channel data, but I think the web-services approach is the best way to create a channel, and I think it wouldn't be too hard to do so using existing open-source tools like the apache axis soap implementation.

The axis projects is a follow-on to the apache soap project, and it has been architected to be modular.  It provides for callbacks in the request and response phases of a soap transaction, and it also allows for the use of multiple transport layers for transporting soap messages.  It should be possible to hook in aolserver as the transport layer for axis (residing in nsjava), and export dotLRN functionality via webservices.  Since uPortal is a servlet application, an axis soap client could be easily integrated with uPortal.  The bulk of the work would probably be in developing the uPortal channel servlet application.  Lately, I've been interested in providing web-services for openacs, and I will attempt to tie the axis transport layer to aolserver in the near future (as soon as I get the new version of OpenFTS out the door), and see if I can implement a general web-service package using nsjava.

Posted by Caroline Meeks on
Thanks for moving so fast on this Dan. We certainly do need web services functionality for OACS and I agree long term its the way to go. But from what I read and heard it doesn't sound like the web services interface to uPortal is quite ready yet.

Is there a simpler way to do a proof of concept so that we can generate interest from uPortal users, thus increasing the available resources for additional integration?

Posted by Dan Wickstrom on
If you want to import dotLRN as a url or rss channel, then I assume that it could be done quite quickly - at least I hope it could.  That would be the way to develop a proof-of-concept. Of course neither a rss or url channel is that exciting, so I don't see that it would generate much interest - but I could be wrong.

For a real-tie in to uPortal, I think you need to use a servlet or applet base channel, and I think that is quite a bit more work - more work, better results.  What I was trying to point out was that a servlet based channel which uses xml as a datasource could probably be implemented quite easily using existing soap services provided by axis.  I mean if you go to the trouble to develop a servlet-based channel, then the additional step of tying in a web-services client to uPortal should be simple.  The only additional work is creating a transport layer for axis that talks to aolserver.  I've been looking at this part of the puzzle recently, since I've been interested in adding web-services for openacs. I think that it won't be too difficult to implement this, since axis was designed to be transport-agnostic.  Currently, implementations of axis have implemented the transport layer using tcp, http, stmp, and they also have an example using files as a transport mechanism (the axis server watches for a particular file and uses it as a soap message input and responds with another file for the response).