JA-SIG Portal Meeting Minutes

Feb 15, 2000 at Princeton University

Attendees:
From Princeton: Patty Gertz, Mike Barton, Debra Rundle, George Fleming, John Wagner Dwight Bashore
From IBS: Tony Holderith, Ken Weiner, Adam Rybicki
From Georgetown: Karen Dorschuer, Bob Brokaw,
From U. of Del: John Laker, Carl Jacobson, Dave Wallace
From U. of Washington: Ed Lightfoot, Greg Barnes
From Yale: Roger Despres, Andrew Newman
From Boston College: Ed Greene, Brian Savage, Bernie Gleason

JA-SIG

• Introduction from Carl, describing the JA-Sig clearinghouse as well as the portal effort.
• Stressed that collaboration is as key as product here.
• The Clearinghouse is a listing of descriptions. You get a contact at an institution. There is no code there. Institutions may vary in whether they charge, etc.

 Portal Reference Implementation

• The portal has two main components - framework and web community pieces.
• Requirements agreed to in Jan at Brown have been posted on the JA-Sig website, www.ja-sig.org
• Open source, open architecture.
• The framework is a reference specification. If you don't have java programmers and don't want to buy services, you will not be able to install and use this as a product.
• Reviewed IBS's Portal Framework document. Agreed to base spec on J2EE spec. Agreed to consider LDAP as a basic housing for security.

Thoughts on the portal:

• Can use applets, servlets for channels.
• Statistics component to show usage.
• Availability index - what is available for you to bring into your portal?
• UI of portal - should it be part of the customization? To what degree?
• Interfaces are key - an important one will persistify the channel.
• Where should you store your user profile? Store state? RDBMS, XML, LDAP?

Security - not just authentication, but how can we secure channel content? We agreed for now we must secure the whole page, even though it's overkill for things you don't care about. Works if you serve from 1 server, but there's a performance hit if you secure everything.

Secure objects ---->

Insecure objects ---> Server ----> Portal

Want to address time aware content.

Publish and Subscribe

No schools have formal methodology for what gets published where. Reduce the scope - what pieces should we build first. Publishing should be based on roles that determine what you are allowed to publish and who can see it.

What is needed on a developer's desktop?

• IDE - visual age for java, visual café, jbuilder
• Java Servlet Engine - TomKat, free apache java servlet engine w/ JSP1.1, Servlet 1.1
• SQL engine - HyperSonic SQL, CloudScape SQL
• EJB Engine??
• Authentication LDAP server??
  
• Compile the code (IDE)
• Run the code (Servlet Engine, Web Server)
• Database Component (SQL Engine)

Portal Demo

IBS' Ken gave a demo, which included the following:

• generic channel for applets
• channels minimized, maximized, deleted, editable
• could pass parameters, detach (make separate window)
• RSS channel, that's how we would access commercial stuff
• HTML page rendering

What do we need to address to get started?

• alert
• security
• publish & subscribe
• page rendering
• personalization/user profiles
• channels (generic flavors)
• channel chooser
• login
• environmental configuration (J2EE uses JNDI; do we need to store that stuff somewhere? In JNDI interface? jar file? Ldap?
• What are some JA-Sig Portal Channels?
• Portal JA-Sig docs
• Events
• Forum
• Generic channel to J2EE
• Clearinghouse (RSS)

Outstanding Issues

Quality Control/personal entries - Do you publish absolutely everything or control a list of what can be subscribed to? Should the registry be filtered?

Example: Sanctioned apps can receive ID/Password.

Should we require outside sites to be re-registered in local repository?

How do we secure what needs to be secure and open everything else?

Do we need source control? Possibly CVS, but not for first pass?

When do you put an app in the channel, when do you put a link to the app there. Channel should contain summary info only.

Should you allow publishing of all events, but only with authentication, like Stanford? Cannot publish anonymously.

This is open source. What does that mean for your school and contribution? You must copyright, you must charge, you can only code for schools, not commercial, etc.

What happens when the persistence times out?

Who has agreed to do what? / Next steps

• Security – Yale will use Java Naming and Directory Interface (JNDI)
• Yale and IBS will work on authentication interface, Princeton and Georgetown will work on related security issues
• HTML Rendering – Georgetown, Univ of Washington
• Code Repository, Forum – U of Del
• User Interface – Georgetown, Princeton and IBSChannel Registration – Princeton and IBS

It was agreed it would be helpful to meet in a month, but no definite plans were made.