Forum .LRN Q&A: dotLRN Portal Framework and uPortal

Posted by Alfred Essa on 01/18/03 04:56 PM

If we are going to get wider adoption of dotLRN we need to make the system less monolithic. Heidelberg is spearheading the external authentication effort. We need to explore LDAP support for directory and profile information.

This thread is about the portal framework for dotLRN.

In higher education, uPortal is emerging as the defacto standard. We are seeing great adoption among higher educational institutions and government agencies. Sun recently announced that it "would redouble its support of the uPortal code".

Is it technically feasible to use uPortal for the portal framework for dotLRN? I am willing to put forward some seed money to explore this further if there is a feeling that this is technically feasible. What if we get potential adopter for dotLRN who wants to use uPortal as their portal framework? That's the question. What kind of effort would it be to deliver dotLRN information through uPortal channels/portlets? WebCT and Blackboard provide some integration and compatibility with uPortal. For example, here is WebCT's integration approach.

What is uPortal?

"uPortal is not an application; it is a framework, a set of technical specifications, and software. The framework provides a J2EE portal server (container) and well-defined interfaces that will permit individual institutions to customize the institutional portal by plugging in components in a well-defined and usable manner."

2: Re: dotLRN Portal Framework and uPortal (response to 1)

Posted by John Norman on 01/18/03 06:00 PM

We (Cambridge) have a long standing interest in uPortal. I notice the Sun announcement says JSR168 will be incorporated (at the conference last summer the developers said they had no plans to look at JSR168). We had shelved it to see how JSR168 got on at Jetspeed (Jakarta Project) and CHEF (UMichigan) because we felt JSR168 was likely to get widespread industry adoption and a Java portal development that ignored it was driving up a blind alley.

We would be keen to look at it again in the light of this development.

3: Re: dotLRN Portal Framework and uPortal (response to 1)

Posted by Lars Pind on 01/19/03 10:14 AM

Al,

I think this would be an absolutely outstanding and important thing to look into. As you said, this is an important part of opening up dotLRN/OpenACS to other systems, many organizations already have portal servers running to integrate all their different systems.

(Btw, support for iCalendar servers is another place where we need to open up, but that's irrelevant to this thread).

I'm really hoping this will happen.

/Lars

4: Re: dotLRN Portal Framework and uPortal (response to 1)

Posted by Mohan Pakkurti on 01/19/03 10:35 AM

Al,

This is a great suggestion. I have been talking to a university here in Stockholm that is implementing a campus wide portal system using uPortal, and they are also looking for an e-learning platform. In a conversation last week they mentioned that they would not even consider evaluating systems that don't have uPortal integration or definitive plans for that.

I am starting to look into how much work is involved to do this. Dan Wickstrom posted his comments on Oct 2002 here... Info on other academic portals.

/Mohan

5: Re: dotLRN Portal Framework and uPortal (response to 1)

Posted by Carl Robert Blesius on 01/20/03 03:56 AM

I have not looked at it in detail, but it seems that authentication might play a part in the uPortal/Portlets puzzle. Can anyone add anything about this?

6: Re: dotLRN Portal Framework and uPortal (response to 1)

Posted by John Norman on 01/20/03 01:50 PM

Although Portals can offer authentication, we think that solutions that use a separate authentication mechanism will be more flexible.

A logical starting place is simply to create a dotLRN portlet that means someone signing in to the portal can see a page like MySpace and be passed through to dotLRN from that page (with a path back). This would allow political/marketing claims to be made.

I think the next place to go is a significant but worthwhile development effort. That is to recreate the dotLRN portal functionality with some of the emerging standards. Web Services for Remote Portals (WSRP) sits on top of JSR168 portlet api for Java and a mooted C# portlet api for .NET

http://xml.coverpages.org/wsrp-overview200206.pdf
http://www.oasis-open.org/committees/wsrp/

The JSR168 specification is due to be adopted in uPortal, but should also work in IBM, Sun, Oracle and Jakarta Jetspeed portals. Supporting WSRP would allow integration of .NET portlets as well.

There is a real question about whether these developing specifications can support the depth and sophistication of dotLRN, but the involvement of Glenn Golden from the U Michigan CHEF project (which seeks to create dotLRN type functionality using JetSpeed) in the JSR168 effort suggests dotLRN type use cases are being considered.

Of course a lot of this may be 'pie in the sky' but I think these are relevant technologies if dotLRN wants to integrate 'standard' portal technology at more than a superficial level.

Finally, if going down the Java portlet route to get deeper integration with uPortal is felt to be undesireable, it may be worth considering a tcl portlet api to sit alongside JSR168 and a possible C# portlet api under WSRP (see p 11 of the wsrp link above)

7: Re: dotLRN Portal Framework and uPortal (response to 1)

Posted by Alfred Essa on 01/20/03 05:24 PM

Andrew Grumet has been doing some work in the authentication space trying to figure out OKI. He should be able to help with this piece of the puzzle.