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

http://mis105.mis.udel.edu/ja-sig/uportal/uPortal_architecture_overview.pdf

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: http://mis105.mis.udel.edu/ja-sig/uportal/channel_docs/authoring/authoring.html

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.

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.

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

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.

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.

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).