Portal Meeting

1/12/00 — Providence, Rhode Island

Attendees:
Yale University
Cornell University
University of Washington
Boston College
University of Delaware
Brown University (host)
Georgetown University
Princeton University
Interactive Business Solutions

Purpose:

Issues:

Clearinghouse:

A "dating service" for offering and finding applications of interest e.g., student elections module. The individual institutions can set the rules for sharing — free, cheap, or expensive. The clearinghouse just facilitates the sharing but doesn’t get in the middle of the process.

Portal Reference Implementation:

This will be shared freely with any other institution of higher education. You need to check with your own institutions vis-à-vis legal issues related to code ownership/licensing. To be written in a way that supports standards but doesn’t require them e.g., LDAP, EJB, Authentication/Authorization, DCE. Encourages best practice but doesn’t require it.

Focus Areas for Meeting:

User Interfaces

My page with a login that will allow secure transmission of data- a container for channels.
Maintain state
Personal "grab me"
Personal recognition
Institutional as well as outside info
Content types: alerts, personal messages, etc
Styles — tabs, channels, portlets
Customize the home page? — organizer approach. If we build a customizer then there is no reason that this could not be used by departmental home pages as well.
Should there be any default real estate — stuff that just has to be there.
There is going to be a demand to have a space that allows for mandatory PUSH content
Logout
Channels need to be editable, removable,
     Display data
     List of links
     Graphics
     Applets e.g., grade point calculator
     Form input e.g., quick library search
Application window
How do we maintain portal state — launch new pages, my personal, ask jeeves. We will need to allow flexibility in our reference implementation on this issue because it could become divisive.
Maintain authentication so that you don’t have to keep logging onto apps
The reference implementation needs to allow an institution to start out with something simpler and perhaps less ideal but work their way up to the ideal
You should be able to run a portal in a channel — recursive portals
Multiple role people e.g., staff and alum
Directory standards — LDAP? Or some other "rickety" directory
Customization of the portal would be similar to the capabilities you have with your desktop e.g., color of the skin.
Buttons, tools for community
Channel examples
     Alerts, announcements, things to do, events, address book, books checked out
     Personal business things, today’s weather…

Publishing

Questions:
How do I interface to various content?
How do I make it know to channels and containers?
How do I protect the published info?

Issues:
Channel registration — institutional, department, intercampus (other institutions could use this channel)
Eligibility, Authorization/Access control — roles, time, rules
Channel standards
Time
Permit server/grouper

Internet 2 Middleware Initiative — Steve Carmody, Brown University

National interoperative middleware development. Campus-based middleware infrastructures. NSF project. Primary interests are directory services, web authentication/authorization. In search of best practices in these areas. This will be used to guide early adopters. Interest in the federal PKI effort. Undergrads are expected to have certs to manage the student loans. Portals are a really good example of an application that could benefit tremendously by having this sort of infrastructure in place. Steve said that his group would like to stay in touch with us. Steve informed the group that more information could be found at www.internet2.edu/middleware

Subscribing

Good example on Netscape’s NETCENTER
Ability to subscribe to services off campus
What’s new on channels
User profile to store someone’s subscription will bring to light the datamodel issues e.g., time, roles, workgroups

Portal demo

Demo of zero reference implementation coded by Interactive Business Solutions. Pure JAVA, relies on JSP and XML. Working primarily on the structure/user interface architecture rather than content.

Page renderer is similar to the idea of a recursive portal. Keeping the user interface open enough that it allows for growth in the future e.g., bill paying channel might start out as only paying your institutional bill but might wind up allowing you to pay any bill you owe. DXML product from Object Space was used to narrow the gap when XML is parsed. DXML takes the output of the parser and builds the classes that make it easy to do something with it. Every channel has a method called edit. A channel also renders itself and it tells the container things about itself e.g., whether it is minimizable, movable, editable.

Requirements spec was started. Reviewed the object model and a data model. It was defined as a DTD (document type definition). There is an implementation of a class that does the work of the channel. On the back side you can make method calls to an application. Follow on meetings needed to discuss both "container" and "content".

Is there an apps server requirement? You need JSP1 and the ability to run serverlets, otherwise can use any app server product. This does not require EJB. Where is the data being stored? Is it in XML? Yes, it is in XML but can be stored as a blob in sql. This version pulls up static XML. Discussion of whether to store user profile data in SQL or would it be XML? XML Advantage — you don’t need to do table changes. XML Disadvantage — you lose the services that an RDBMS offers. What about storing the profile data in a directory such as LDAP. The EJB security spec says that a user or machine is a principle with roles that it is allowed to play. An application has a set of roles as well. If you as a principle match one of those roles of the EJB.

What are the reasons that this is a good model
      Open standards
      Very lightweight, lowcost initial investment
      Early enough in the process to make a difference
      Other alternatives — Apache, Minnesota framework

Community Tools

Forums, chat, browser client for imap, calendar, FAQs, newsletter, doc vault, group support…

General Campus Web Direction

Discussion: How does this fit in with the static web page environment?

You want to encourage folks to use the portal rather than the static pages. Ed Lightfoot suggested that you might want to only offer these pages only through the portal. Carl defined the portal as an abridged version of the campus web. The mistake would be to build this to fix the mess. You need an enterprise web site that makes sense and an abridged version. A move to more user-centered web design. Grades and financial aid award are good examples of stuff that you would not want to do so often that they would be on the front page of the portal. Things like the gpa calculator or a barometer of your debt are probably useful community tools. Engaging prospective students. One way of thinking about a portal is as a predefined search engine. A network load lightener.

Next Steps

The 30 institutions that are part of the JA-SIG must have a forum to participate and help define the requirements. There is no requirement to contribute to participate. Participation does not really have to be exclusive. For example, Washington already has a framework but their future development may be useful to the effort. Disucssed possibly of using open source object from Apache and plugging them into the JA-SIG framework. The JA-SIG framework would be a framework we could own and control.

Meeting minutes will be posted, requirements specification will be posted, framework demo will be posted. Institutions interesting in contributing to coding effort should contact Carl Jacobson at University of Delaware (carlj@udel.edu). A meeting will be schedule among coding institutions to develop work plan. Coding opportunities exist in framework as well as with tools to build Web community.