uPortal Developers Meeting February 2004 Tempe, AZ

uPortal Framework Developers Meeting

Arizona State University, Tempe, Arizona February 9-10, 2004

the building this was held in, Coor Hall, was dedicated 1 monthbefore

These notes were taken by Michael Oltz and put in his ownwords. They do not exhaustively represent every word that was said.Their intent is to show the topics discussed and the decisions made.

Attendees

• Trent[on D.] Adams – AthabascaU – trenta@athabascau.ca

• Nancy Lee – ASU --nancy.lee@asu.edu

• Bob Miller – ASU – bob.miller@asu.edu

• Ron Page – ASU – ron.page@asu.edu

• Al Wold – ASU – alwold@asu.edu

• Dan Ellentuck – ColumbiaU – de3@columbia.edu

• Alex Vigdor – Columbia U – av317@columbia.edu

• Steve Barrett – CornellU – smb1@cornell.edu

• Michael Oltz – Cornell U – mdo1@cornell.edu

• Michael Ivanov – instructionalmedia + magic (IMM) – mvi@immagic.com

• Nate Johnson – Indiana U -- natjohns@indiana.edu

• Jim Farmer – JA-SIG and IMM. – jxf@immagic.com

• John Bush – {{http://www.rsmart.com/index.php}}r•smart --jbush@rsmart.com

• Chris Coppola – r•smart-- chris.coppola@rsmart.com

• Mike DeSimone – r•smart-- mike.desimone@rsmart.com

• Bill Thompson – RutgersU – wgthom@rutgers.edu

• Dmitriy Kopylenko – Rutgers U – dkopylenko@acs.rutgers.edu

• Mark Boyd – SCT --mboyd@sct.com

• Jan Nielsen – SCT – jnielsen@sct.com

• Mike Zackrison – SCT – mzackris@sct.com

• Dave Wallace – U Delaware -- dwallace@udel.edu

• John Blakley – President of Unicon , sat in on theTuesdaymorning session.

• Nick Bolton – Unicon – nbolton@unicon.net

• Kevin Gary – Unicon – garyk@unicon.net

• Shawn Lonas – Unicon – shawn@unicon.net

• Ken Weiner – Unicon – kweiner@unicon.net

• Andrew Wills – Unicon – awills@unicon.net

• Susan Bramhall – Yale U-- susan.bramhall@yale.edu

• Howard Gilbert – Yale U – howard.gilbert@yale.edu

MONDAY

uPortal and Sakai -- Jim Farmer

At last fall's developers meeting (at Cornell University),

1) It was agreed that uPortal should support JSR-168 (portlets)and WSRP (web services for remote portlets) soon

2) Chuck Severance from UMich mentioned that there should be somecollaboration between uPortal developers and other efforts at Michigan,Indiana, and MIT.

At MIT, Jeff Merriman was leading the development of OSIDs (OKIServices Interface Definitions) which were defined as Java APIs.In September two people from the OSID project met at UMich with peoplefrom several universities and JA-Sig; out of that came aproposal. It was funded in December by the MellonFoundation : Indiana U, UMich, Stanford, MIT – a project to makecourse delivery and management and collaboration tools.

Originally UMich wanted somebody to put Pluto into Jetspeed.But they decided that uPortal may be a better platform to do this withrespect to higher ed,because it has:

1) internationalization

2) Aggregated layouts

3) Groups and permissions – it can be overridden to work differently

The second half of Sakai: tried to create a licensingarrangement to permit corporations to make extensions to it.

Should the OSID services be available only THROUGH the portalor also OUTSIDE of it?

The two projects compared:

"legacy" means, were there substantial existing projects thatneeded tobe incorporatedinto the new project when it began?

The Cornell meeting was the first one where corporate folk outnumbered people from higher education.

Biggest implication for JA-SIG is we need to have JSR-168 bySakai's schedule, "really fast" rather than at a more moderate pace.

Aggregated Layouts – Michael Ivanov

Layout content management is related to roles and groups,and is implemented chiefly in the Java classes AggregatedLayoutManagerandAggregatedLayoutStore.

There are many early limitations.Eventually there will be more ability to publish and subscribe, andeditors.So far you have to create fragments in XML and run an ant target'pushfragment' to put it in the db.So far fragments are all immutable, and they can only be tabs; youcan't have a column or smaller fragment.The early limitations are in the manager and store.

Should we do the enhancement in uPortal 2.3 rather than in 3.0?

Pushed fragments – can be added by administrators; who getsit is based on groups and permissions.'Marking nodes' are put in the layout to indicate whether and where afragment can be used.And there are different kinds of restrictions. Hidden, removable,immutable. And the 'priority range' – what order does the item appearin the tab/column tree. Each manager of fragments gets a range ofpriorities that they can assign to the fragments they create.How to do this will be explained in the upcoming uPortal documentation.

In 3.0 he wants to introduce user modifiable fragments. Thereare complicated questions as to how the two kinds of fragments willinteract.

There are also pulled fragments, that the user could be ableto choose at will, but there is as yet no UI to get to them; the storeand manager know how to handle them though.

Most of the default layouts in 2.2 consist of fragments only.This has caused some confusion; portal implementers expect them to beeditable in the UI – not yet!

There is a new target in uPortal called 'initportal' that runsall the initializations.

The chapters of the docs are checked in to CVS, not completeas yet.

There is a straightforward way to switch between AggregatedLayout and Simple. You change the properties for thelayoutmanager and the layoutstore, back to the SimpleLayout versions,and you'd have to set everybody to the older theme.

Rutgers: is it worthwhile to migrate to 2.2 if you don't want Aggregated Layouts yet? You can't use the new theme with the old layouts. (the only thing is the marking nodes information is not in theold XML, so the users would not be able to edit anything) Peter wanted to put these nodes into the old layout but it's not finished yet.

Using the old themes with the new layouts. It would render, but nothing would read the restrictions.In the old layouts, the knowledge of where stuff can be added or movedis in the XSLT. In the new layouts, the knowledge is in the manager,and the layout asks themanager where it can put stuff.

Who wants either of these? Susan: it would be nice to have a conversion path. Steve: the UI is changing a lot and needs lots ofstaff involved. Jim F.: Jon Allen at IMM is writing user and admindocs. For sites who are just coming online they can go directly to 2.2.Peter thought the ability to create and edit fragments would rarely beused, by admins. Jim: It will be used a lot by faculty.

Susan: simplest conversion would be to go to aggregatedlayouts without integrated modes. Then change to the new UI later.

Ken: we need someone to work on an upgrade path.

Michael I: Could we get editors into 2.3 or 3.0?

Dan E: At Columbia only a small percent of users bother tomodify their layouts.

Susan: Some sites have made customized themes not just skins.Will be hard to migrate.

Ken: A committee to work on migration?

Dave Wallace: What is the timeframe on getting a UI to edit?

Jim: Let's do it immediately. Ken: Doesn't want to commit dueto where would we get the resources.

Alex: Is there a way to do it like CuCMS does where youcould use a channel to edit the XML and write it out from there?

Jim: There aren't many resources available to do this. Hazardof promising to do this then not doing it.

Bill T: Rutgers' emphasis right now is content, we don't wantto spend time migrating now.

More about Sakai and 2.3/3.0 – Jim Farmer

Jim Farmer then showed the slides of his presentation on thestatus of uPortal, as theyfinally had the projector working. These slides will be/are availableonline.

He spoke about remaining limitations of the new features.These are listed on the slides.

In uPortal 2.3 the initial implementation JSR-168 will be donewithout regard toperformance. The preliminary WSRP (Web Services Remote Portlet) codefrom 2.2 will be completed.

In 3.0. Performance of JSR-168 will be improved. IChannel willstill be supported and existing channels will still work.

Future uPortal priorities are likely to be:

• Stability

• Performance

• Features

• —

• Product support

• Documentation

• Training

Future JA-SIG priorities are likely to be:

• Applications implemented as portlets or portal channels

  • OSPI ePortfolio

  • Sakai collaboration tools

• Services oriented architecture

JA-Sig priorities and activities represent interests, needs,andresources of the participants. There are changing needs in higher andfurther education, sothe priorities for the uPortal group are changing.

He also showed slides by Lois Brook of Stanford Universitydescribing Sakai Project to U of California CIO's.

Sakai products:

Tool Portability Profile: standard for writing tools to extendthe coreapps.

A Technical description

Describe a common path forward.

A complete CMS with assessment tools

Enterprise services based portal

Workflow engine

Research support collaboration system.

Skin in the game

$4m total from the four institutions

$2.4m from Mellon Foundation

Jim quoted Brad Wheeler as saying "There is no Plan B." Itgoesas planned, very fast, or it fails.

Gartner: "By 2007, 80 percent of e-learning platformfunctionality will be available through open source (0.7 probability)"

The Sakai Educational Partners Program (SEPP)

Who can be in it:

Ed institutions only

Administrators for planning purposes

Adopters who need support

Developers who want to contribute

What they get:

Can participate in community

Tech support for partners

Knowledgebase

Tech docs and specifications.

Early access

Access to SEPP staff

Access to knowledgebase

Time base. Jim showed a slide giving dates, all in 2004.

First developers workshop for Sakai will be colocated with summerJA-SIG meeting, following it. After the Tempe meeting it was foundout that the date and location of that workshop may be changed It willcover the "Tool PortabilityProfile" and what has been done to existing products to make themcompliant.

According to a participant, the Federal govt has aneducational authentication standardsproject going. This will recommend a federation rather than a singlenational authentication service. It will use "commercially availablesoftware" – that suggests the Liberty Alliance. Federal govt hasagreement with banking community to usetheir ATM-card based identification systems for identification.

Collaboration is not everyone doing the same thing, butrather, doing different things that work together.

[OSID is onSourceforge under 'OKI']

There are twonewsfeeds on the IMM site under uPortal . Watch them often.

Integrated Modes – Ken Weiner

already been mentioned but we can talk about it more.

Since the projector is now working, Ken demonstratedintegrated modes.The default pushfragments file is in properties/al.The pushfragment files refer to channels by their functional names.There is a new icon at the top 'sitemap' that shows a summary of yourlayout as a text outline. Ken wrote a very simple channel to choose the language in which to showthe portal.There are currently three levels of language settings – browser,session, and user. Not yet at channel level.

Steve B asked to demonstrate how to move a channel.

Susan: Top of the portal takes up too much of the screen. Ken:You could change the theme. with a new integratedmodes.xsl (may also have to change the skin) Ken: "This happens because Justin works on avery large monitor, so on his screen it looks really good."

From the theme xsl, there are two links to CSS, one is theuPortal skin for the page, and another that points to a 'portlet' CSSso there will be a skin to comply to JSR-168 which has its own CSSspec. [well, WSIAstandard ] We'll need a new CSS for each skin. For 2.3 and 3.0 we(JA-SIG) will be converting most ofour channels to portlets, and a graphic designer will have to changethe CSSused by the channel to be the portlet one.

Internationalization (i18n) – Ken Weiner

Java locale preferences are specified at three levels. Thereis an algorithm which determines how the three levels override toresult in one list. The browser strings are not easily parsable intoJava locales. Nobody at the meeting indicated good familiarity with theissue. This needs addressing. There is an RFC:2616 section 14.4 that specifies how the browser language settings are supposed to look.

The channel gets an ordered list of locales, and it's up tothe channel to decide how to deliver content based on those locales.

There is a utility put into the XSLT util forinternationalization that can recognize locales. [getTransformermethod] This is what can select different XSLT files based on language.

Right now we have like, six different stylesheets if that onehas been internationalized. And it will get worse as we add morelanguages. The building of the language variants should happen at buildtime. Can we get a better arrangement of this by 2.3? Right now even ifa language specialist wants to keep their language current, there is nomechanism to do it.

Alex: I have a utility that inserts resource bundles into XML,which I wrote for CuCMS ,ifanyone wants to use that. Alex explained more about how his code worksand pointed out the advantage to doing it that way.

Jim: threw in a caveat that a single English phrase can betranslated various ways depending on the context.

The group began to feel that Alex's way to handle it may bewhat we want.

Jim: The original mentor of our i18n project is VP for i18n atOracle. We should ask him what he thinks about that.

Jan: We may want to write our own resource bundle code tocustomize the behavior.

Shawn: Maybe the language-string reading could happen atruntime, calling out from XSLT to get them.

Alex: This is sort of what my code does already.

WSRP – Ken Weiner

(he has a long bunch of slides about the topic that he wrote for doing uPortal 2.2 training; he only showed some of them in this session)

WSRP in uPortal does everything that Remote Channels did in2.1. (Nobody present had tried it yet) It only works for some channels and not others.There are some bugs that need fixing. There are some known limitationsmostlyhaving to do with authentication and user identity.

Publish parameters – the Service URL base. Don't forget thecontext name if needed. And the portlet handle name which in uPortal isthe functional name. The registration interface in WSRP is optional andin 2.2 ken didn't implement it; regstration-required services won'twork. The other optional interface is portal entity management. thatisn't in here. One institution in UK was interested.

Next steps for WSRP in uPortal:

WSRP4J

Compatibility testing

Authentication

Consumer URL rewriting

File upload/downloading

Use of Registration Interface

Use of Portlet management interface

Portlet Browsing and Subscription

(all of these things need help, Ken will not be able to do them all)

Jim asked what is Cornell's interest in WSRP: Steve replied,he thinks people will eventually stop writing servlets as such and willwrite portlets instead, and we will need to prepare for that.

Jim: For people who are writing portlets, which will you useWSRP or JSR-168?

Bill T: WSRP = remote portlets, which in our experience means'slow'. They more want local things.

Steve: You could still have a local WSRP.

Alex: If you write JSR-168 then you have WSRP.

Jim: In UK they write WSRP but in USA people seem to wantJSR-168.

Ken: Well if they want to use Java then JSR-168 is the way to write aportlet.

Jim: a project will begin in UK on Feb 16 to implement alibrary system as a web service.

Ken really wants others to test it a lot to help shake out thebugs.

(Ken had given a basic training for uPortal 2.2, in France theprevious week)

The people in the France training didn't like the way theportal controls who can get at a particular portlet. Right now if theportlet is permitted to the group Everyone, anyone can be a client ofit. They wanted a way to limit this.

There was a discussion about what this meant and how we mightoffer what they want. What if uPortal requires registration in thefuture? Registration is a temporary thing similar to establishing asession; it is not a persistent thing. When you connect to a WSRPproducer, you can find out whether the producer requires registration.

Jim: A university should decide on a consistent way to requireregistration, so that there's not a different way for every service.

More talk about portlets – Apache Pluto -- Ken Weiner

In 2.3, the classic channels will be there, and there will beone more channel type that would be a portlet. Those channel typeswould go through an adapter so the Pluto API will look like an oldchannel.

In 3.0, Pluto would be 'it'; most of the provided channelswill be JSR-168, and there will be an adapter to make the classicchannel API look like a portlet.

The Pluto build makes three jars.

portlet API jar file - javax.portlet type of code, almost allinterfaces. Likely to be stable

pluto1.0.jar – the Pluto container – meant to be imbedded in otherpeople's portals.

portalImpl.jar – the part that we're replacing – this was a minimalthing written by the Pluto team for testing and demonstration.

Their sources are in several pieces

javax.portlet – the portal API part – not yet distributed by Sun.

org.apache.pluto – the particular Pluto run code

org.apache.pluto.portalimpl – this was where the portalImpl came from.

Their 'portlet entity' is like uPortal's 'subscribeID' – an instanceof the portlet for a particular client.

(Ken spent some time going over the arrangement of the Pluto source and the purpose of some of the packages and classes)

In 2.3, there will be the two jars mentioned above, which willgo into the shared library directory, according to what servletcontainer you are using.

Seems to work on Tomcat and Resin but not on WebSphere .

There is a new package org.jasig.portal.container

In the StaticInformationProvider class there is somehard-coded information that needs more flexibility as to where it comesfrom.

Howard suggested a different way to implement this, having thePluto context be separate from the other portal context.

Alex: That means you can use the Tomcat management facility totake a portlet up and down separately when upgrading them.

The Pluto spec says that you have to define a portlet inportlet.xml which is to be in WEB-INF. Each of the portlets will havenames. The uPortal adapter will look up the portlet in this file by the provided I.D. (see ken's explanation in previous session of configuring such a channel) Ken is testing with 2 instances of the TestPortlet that comes with thetestsuite portlet application in Pluto.

Next:

– change StaticInformationProvider to come through webapps to getinformation

– implement DynamicInformationProvider so you can respond to controlsin the portlet.

Ken thinks that much will be done in weeks not months. He ison vacation in March so he wants to get it done this far before that.

Talk about Peter's ideas for 3.0 – Ken Weiner

Peter Kharchenko (who works for Unicon but could not come tothe meeting) wants to have a 'portal context' with: a layout generator;more than one rendering pipeline e.g one through SAX filters, one withno transformations; and other services. In other words, have theuPortal be made up of more cleanly delineated snap-together parts, sothat the parts are easier to modify/replace

So there needs to be a pretty concise definition of whichpieces a particular portal implementation should fire up wheninitializing. Therefore we should use some standardized way ofspecifying this constellation of pieces. Our portal.properties file isa rather primitive way of doing this, specifying class names.

Apache's Avalon Merlin – Peter and Michael looked at this.

Bill Thompson has been looking at the Spring framework.

Some work has already been done on Merlin with uPortal so thisis not going to be brought to a halt. Probably soon there will be someparallel implementation with Spring etc.

The SpringExperience – Bill Thompson (Associate Director, new technology),Dmitriy Kopylenko (Sr. Software Engineer) Rutgers

ThePowerPoint slides for this presentation.

They picked Spring because of architecture, robustness, andscalability, with respect to focusing on business applications.

Intro to Spring:

J2EE should be easier to use.

Please go look at the JDBC abstraction layer in Spring.

AOP = Aspect Oriented Programming. a development methodology which considers the manner in whichan application does things. AO thinking can best be characterized bysentences beginning with "Whenever". For more information go to the Communications of the ACMarchive and look at the October 2001 issue. – Mike Oltz

Dmitriy spoke about how they took Pluto and reimplemented theportalImpl stuff with Spring. He showed a UML diagram of makingspecific Spring-style classes to implement the portalImpl interfaces.He showed a snippet from an XML file to define the beans for the Springinitializer. Then a sequence diagram of how the http requests arehandled using Spring.

Is Spring a good fit for uP3?
*Spring is easy to use
*Supports all three IoC types
*No dependencies on framework
*They have found productivity gains

Ken: how many jar files are required for Spring?

Dmitriy: It comes two ways. One enormous jar with everything, or theyhave several smaller jars so you can pick and choose a subset if thereare some major features you don't need.

Recommended book in print: ExpertOne-on-One J2EE Designand Development by Rod Johnson (Wrox, presumably now Wiley)9 0764543857 $59.99

Forthcoming books on Spring:

Spring Live by MattRaible. Sourcebeat(secure PDF subscription service). May 2004, $29.95

J2EE Development withoutEJB, Expert One-on-One by Rod Johnson and Juergen Hoeller.Wrox/Wiley, May 2004,

0764558315 $39.99

Professional Springby Thomas Risberg, Rod Johnson, Juergen Hoeller, Alef Arendsen, pluscontributions from several core

Spring developers. (Publication data not available at time of writing this report)

Apache Merlin – Michael Ivanov

Michael showed a UML diagram of some work he is doing (rePluto and uPortal 3) and used it as a starting point for his discussion.

Each Merlin "block" can define a context and services to beused in it.Some "lifecycle handlers" are provided and you can write your own such.He spoke about the initialization configuration file, for example howthe 'components' refer to particular Java classes, and one componentcan declare that it requires other components.Another config file outlines the dependencies between components.

Michael then showed the source of several of his classesregarding how the Merlin code works.

the conversation then turned to discussing the issue ingeneral

Dan: What were the specific advantages sought in deciding touse a component framework?

Michael: it makes the development better. We don't have toworry about the lifecycle of any objects, because the componentframework handles this for us.

Bill: One example the "portal context". The Aggregator, LayoutGenerator. Using these containers you make it easier to interchangedifferent implementations, and you put the dependencies and so on intothe configuration files rather than having to hard code it in the Java.You get a better object model. Better separation of concerns.

The other potential benefit is in the configuration itself.There are a number of properties files and they are growing. Choosing aframework should at least rationalize all that down. Improveconfiguring.

Alex: It seems the biggest benefit is consistency. It look tome as if the capabilities provided by the frameworks are not anythingwe couldn't write ourselves.

Bill: At Rutgers we make better architected applicationsbecause we're using Spring.

Steve: Are there tools to help you do all this? Editing XML (by hand) is a nightmare. They're not meant to be read by humans. How hard would this be to configure?

Bill: There will be an Eclipse plug-in for Spring.

Jim Farmer put the issue of frameworks into the context ofuPortal and Sakai:

Jim: One of the fundamental questions is – should you use aframework?

Re Sakai – they could choose either Jetspeed or uPortal. Itwas recommended that they use uPortal because of functionality. ButJetspeed had chosen Apache Avalon Merlin. The conclusion was, sinceSakai chose uPortal, and the other project they could have chosen wasusing a component framework, a framework would be desirable.

Now then, which one? Who makes the decision?

Several mistakes were made. (1) Was this Merlin decisionadvice, recommendation, or decision? Jim feels he did not make thisclear. (2) When should this question have been brought to this group?This question should have been asked of the uportal dev list inNovember rather than December or January; it's too late to change theinitial work.

The question is dollars, risk and time. Cannot delay uPortalpast August or preferably July. UMich considers 2.3 to be a fallback incase 3.0 is not ready. Their initial audience is only 1 or 2 thousand.

Alternatives:

1) Continue with Merlin, already 2 months work.

2) Recommend to change over to Spring.

3) What should be discussed in July about frameworks and whether andwhich?

The reason for 3.0 is that Peter and some others feel that 2.3won't scale, and it needs tuning and more things put in. The 'morethings' were decided in December 2003 at some discussions at the winterJA-Sig conference. And have been mentioned in a slide earlier today(for 2005 implementation). Basically we are relying on PeterKharchenko's decisions regarding this issue.

Susan: Maybe Peter feels that managing so many componentswithout a framework is too complex.

TUESDAY

Best Practices – Jim Farmer

In higher ed, there are many choices to make in major softwaredevelopment. How do we apply standards to these projects?

1) Is it appropriate for JA-Sig to have a role in that?

2) How would best practices be defined and advocated? When and underwhat circumstances?

From the UK there was a project to connect library systems.They chose to add name-value pairs to the end of an existingspecification for doing this, because Java cannot handle XML-basedextensions tostandards (problems with marshalling data for persistence or nettransfer). But there were disadvantages to this. Would JA-Sigappropriately have something to say about situations like this?

Mark Boyd: I think Sun Microsystems, Inc.--a JA-SIGcontributor, for example would be more likely tolisten to JA-SIG than to a single school.

Chris: We will be ahead of IMS (IMS Global LearningConsortium)in our project. [see Chris's session for the context of this remark.]

Jan: We chose to use the IMS spec. There was a politicaladvantage inmarketing, but the way the data is converted for being sent makes itharder to parse it at the other end. Most of the XML standards arefocused on standardizing the data format, rather than focused oncommunicating the data from place to place. There are some portions ofthe IMS Enterprise that are ambiguous or do not specify features wefound to be needed. So we (SCT) extended the standard for what we need.

Jim: The Departmentof Homeland Security will probably require you to change the wayyou represent names within the next 12 months. DHS tested 200,000 namesagainst their database, and got 14,000 false positives, because the waythe names are represented by the various sources of information is notexact enough.

How do we handle things like what Jan did?

1) Record the changes you made and make them public.

2) During public comment period on the standard, express these concernsto IMS Global.

3) If too overworked, do nothing.

John Bush: the academic people create the standards but thenthe developers in the trenches find out they're to some degreeunworkable.

Chris: There are so many voices speaking to IMS, and the only ones who have a voice are the ones who pay membership in IMS. In order for JA-SIG to have a voice, either you'd have to speak through anexisting member, or you could have a very public meeting independent ofIMS to review and critique the specifications from the point of view ofdevelopers, then publish the recommendations.

John Bush: Did you have input into JSR-168?

no, because JA-SIG has not been in a position for the heavy involvement needed to be in a standards committee.

Susan: JSR-168 feels like a step backward for uPortal.

Jim: uPortal has been given power because of its deployment.

Howard: We set out to write 'best technology' but JSR-168sought the lowest common denominator to be able to be inclusive.

There ensued a debate over whether we were supposed to'support' 168, as Ken is planning to do in uPortal 2.3, or 'embrace' it(in that it will be the central kind of 'channel' in uPortal 3.0)

Jan: You have to focus on the particular technology inquestion. What is the advantage of 168 compared to ours? (Jim made an analogy with error logging) With logging for example, logging is notour core business, so it's not a big deal to throw out personal codeand use a standard that has reached some maturity even if we loseflexibility. With using JSR-168 we will be able to write portlets anduse other vendors' which is a tremendous advantage.

What is the disadvantage of JSR-168?

Howard: With XML we can have uniformity and better security.With JSR-168's stream of bytes, the framework cannot look at it andimpose uniformity or add security to it. For example we can't handlemixed content (http/https) any more because we can't find the itemsthat need to be proxied.

Jan: We would have to impose additional requirements on othervendors' JSR-168 portlets.

Chris: Then you lose some of the point of having a portletstandard.

Jim: The market does tend to choose less flexible and lesswell defined standards because they are simpler and more familiar.

Mark: was the point of JSR-168 an attempt by people with aninstalled base to keep the market in their camp rather than losingpeople who want to move forward technologically?

Ken: By adding the character stream interface (for rendering channels) we have already lost this flexibility. It feels like everyoneis clamoring for JSR-168.

Mark: But we added char stream to support legacy apps.

Ken: ... and for those who didn't care about the flexibilityand wanted better performance.

Jim: (1) The market chooses familiar things rather thancurrent technology, and (2) make sure not to forget to think forward,not merely support such a standard.

Howard: The way we think about the portal is, the world is XMLand we will parse and render it. The way the others think about portalsis, the world is a set of web pages and a portal aggregates them andshows them together.

Jim: A corollary – we should establish best practices forparties implementing portlets. It looks to me like we're split onwhether we should influence things by quietly deploying what we thinkis best, or by directly participating in standards development. Ifyou're a developer you ought to know or be able to find out how othershave done something similarly. If you want to extend IMS Enterprise forexample, go find out how others have extended it. A communicationspoint, be sure to communicate to others what you are doing.

Jim: I don't think we could have had an impact on JSR-168because it was formulated based on what people were doing rather thanon what people should be doing.

Dan: Isn't there an inherent ambivalence in our community? (1)A bunch of universities get together to do something the way they want,and it will be cheap. (2) And this is an advantage to corporations anda way to get business for them. For Columbia for example, a portal isnot their core business, it's a "filing cabinet." I don't see how youcan ever see a harmonic resolution of both perspectives. That's notbad, we just need to manage the dissonance.

Jim: There are people here who want to do something genuinelygood, in an environment where good enough will suffice.

Often standards representatives are from the marketing part oftheir corporations rather than the technical part, even though they mayhave a technical sounding title.

Dissonance: (1) Quality vs. good enough. (2) Marketing vs.development perspectives.

Again, the best way to deal with the dissonance iscommunicating.

Jim: Give me recommendations on what to do, and I will presentit to the board.

Enterprise Architecture and Components – Jim Farmer

SAP has madesome decisionsthat have changed the market

1) Use web services to integrate

2) The "packaged composite applications" approach as explained in thefollowing two books:

Packaged CompositeApplications: An O'Reilly Field Guide toEnterprise Softwareby Dan Woods. O'Reilly & Associates; 1st edition (June 2003) ISBN:0596005520

Enterprise ServicesArchitecture by Dan Woods. O'Reilly& Associates;1st Edition (September 5, 2003) ISBN: 0596005512

(Jim Farmer comments: "Purchasing these two books is notrecommended. The themes and examples would make better short papersthan a book. The overall description of the SAP approach is useful.Since SAP does have dominance in the ERP sector, they do have power todefine integration).

They developed standards for access to human resources, etc.

If you develop an accounting app for example, would you usethe same interfaces as SAP or develop your own?

What interest would there be in JA-SIG in discussing andstudying how to do integration?

Steve: Spoke briefly about WebMethods atCornell.

WebMethods advantages. (by Jim)

1) They developed a tool for automating the design of interfaces to ERPsystems.

2) They reverse engineered all the processes in PeopleSoft

3) They put the web services on top of it.

SAP took a similar approach to integration.

break

OSPI ePortfolio --Chris Coppola ({{http://www.rsmart.com/index.php}}r•smart)

Project started late in 2002, officially in Feb 2003. It's acontinuation of an electronic portfolio project at U Minnesota for fiveor six years.

An electronic portfolio – a web-based application,individual-centric, in which the person can store a bunch of stuffwhich is samples of their work, or works in progress, for disciplinessuch as art and archaeology, which are based more on visual or digitalmedia than on text or math. If it were an enterprise application, itwould have much more potential because the information can be used forassessment of progress. And do statistical analysis and so on.

The first step was to remove proprietary ties that UMinn hadused, such as use of PeopleSoft.In July 2003 the first version came out.

There hasa been a lot of interest in the product. About 850parties have downloaded the software, 1000 to 1100 people haveregistered for the online demo.

After July, how would it go foward, how would it get funded?They have a different organizational structure. There is a council(board, re funding and interface to other organizations, proceduralquestions) and committers (keepers of the s/w archives, make thetechnical decisions).

The original application started out as an archive tofacilitate reflective practices. No assessment or reporting capability.Yet the community that is interested in portfolios finds assessmentvital, so that will be the focus of version 2 development. But keep theindividual the "center of the universe", unlike course scheduling etc.

Sakai and ePortfolio v2 were funded around the same time andthe list of players overlaps somewhat. So what Sakai is doing willprobably influence ePortfolio development.

IndianaU and r•smart co. are workingtogether on v2.

OKI OSIDs will be used for v2. r•smartwill use the Tool Portability Profile from Sakai. ePortfolio will notuse the digital repository part of OSIDs because they feel it is notrobust enough. Instead they will use Fedora which is another Mellon funded project.

Jim: OSPI project is important to JA-SIG because1) For many it will be a standalone application. This is anarchitectural problem for how it could be available also as channels.

2) Authorization – this will require document-level authorization. AtUMinn, a student could grant another person access to part of theirfiles, even if the person has no affiliation to the institution. [SCT's Documentum hassimilarcapability] (Chris: This will be enhanced in future releases ofePortfolio.)

3) The people who did uPortal had knowledge of what a portal should do.But there is a diversity of opinion as to what a portfolio is and does.The student puts the item in; the teacher comments and shows it to theclass; perhaps the student wants to show their work to a potentialemployer. If you apply electronically, you are two or three weeksahead, because a third-party company is usually contracted to get theresumes online and it delays the application; the paper form is neverread as such.

Chris: Complexity issues in data standards are going to bevery important. Portfolios must be portable across multipleinstitutions and still be individual-centric. For example takingclasses at a community college and using the same files at thestudent's job or internship. That's a future issue for OSPI. This willdeploy as standalone, but some institutions will deploy in a portal;some places will have a hybrid deployment. (so he wants us to exposeOSIDs outside of the portal.)

Jim: I think it's going to be a 'guerilla' application; thatis, it will start quietly in one department's server then graduallygrow out to the university. Another example of use of portfolios isnursing training where there are specific projects you must accomplishso it has relevance to certification processes.

(Note by Mike Oltz.. I originally thought Jim said 'gorilla' but he provided this definition:

A "guerrilla application" is one that is installed, say, in a department and becomes an enterprise application because it is adopted

one department or user after another. It would never have been approved as an enterprise system initially. For example, many uPortal implementations are "guerrilla applications." A "gorilla application"would be one that everyone has to have, which is what portals are becoming.)

Susan: are there commercial offerings?

Chris: There are maybe 50 to 100 portfolio applications inall, maybe 14 or so commercially available (Jim: all with sharply different functionality)

Ken: Will you use WSRP?

John: Well we'll be using Web Services at some level.

Ken: 168?

John: Yes, because that's what Sakai is using. We did not feel free to make a different choice.

Ken: they might be able to write WSRP services faster than they could do JSR-168.

Chris: V2 is going to be a complete rewrite.

Jim: There is a reason for WSRP, because if you do a 'guerilla' application in one department, and it gradually grows, having WSRP putsyou in a better position to become mission-critical.

http://www.theospi.org/

Bill Thompson: We also got a request to have something standalone and also as a portal. Has anyone else faced this situation?

Jim: Peter Kharchenko did something like that but it was along time ago.

Chris: Is there a forum to talk about such (integration) issues between meetings?

Jim: One problem is to notice and identify the issues. Howwould anybody have known that there is a resumé standard heavilyused since last April? There is no mailing list regarding integratingapplications.

Bill; Is anyone involved in Open EAI? (U of Illinois)
Jan: SCT is.

http://www.openeai.org

Jan: There was a mailing list for developers They wanted to make itopen source but it hasn't happened yet.

John: They said they didn't have the resources to support an opensource community.

Should the JA-SIG take a role in fostering communication amongall these efforts? Or will Sakai do it because it is bigger?

Error Handling

(two proposals for improving error handling in uPortalframework)

Howard Gilbert

1) What is broken in the portal that needs to be fixed?

2) How do you make classes and so on to fix it?

When a top-level method throws an exception,PortalSessionManager would throw ServletException to the container andthe end user would see a stacktrace.

What Howard did was to catch it in the SessionManager andtrace it on the log. Show a more human message to the user.

Another example, at many places in the uPortal code,getConnection may throw a null, and the next line of code tries to USEit without checking.

When database problems are caught--

in the logon you get a SecurityException

in the groups manager you get a GroupsException

but they're BOTH a database problem.

getProperty() if it can't find the file, no value, value badformat, it throws a RuntimeException.

We didn't have a global strategy for error management.Misunderstanding of java Exception handling followed stylistic modelsrather than solid software engineering design.

trap all errors at component boundaries.

don't allow any errors to percolate up to the container.

Ditto, don't let anything out of a channel to the framework.

Avoid wardrobe malfunctions – don't hang out in front of a largeaudience.

Buck Stops here

Classification –

*who – end user, configuration, network services, programmer
*what: retry, kill session, kill portal
*when – try again, try later, try tomorrow
*where – local, caller, portal, end user
*how: log at throw, log at catch, don't log.

ErrorID objects:Instead of many error classes, have one class and put an errorID intoit.You call a particular method from all catch clauses and it does muchclerical work, such as trimming down the stacktrace to only show thepart in the portal code.rewrite getProperty to provide default values, add a throw clause tothrow the PortatlException not a RuntimeException.

(there ensued a debate regarding Howard's contention that a hierarchy of exception classes is bad.)

Jan Nielsen

From Jan's point of view, SCT have taken the traditional Javaapproach, using a hierarchy of classes, and multiple catch clauses.

Agrees no end user should ever see a stacktrace.

Somebody has to write logic to determine whether the exceptionwas, for example, a database exception or an authentication exception.The way they do this is to have a database abstraction layer. Theabstraction layer returns a particular kind of object to indicate theerror.

When I design an API with a checked exception, I require thecaller to either handle it or explicitly declare that they are nothandling it. With an unchecked exception, I don't expect the caller tobe able to do anything about it.

(the meeting broke for lunch without resolving the debate. Ken asked Howard and Jan to have lunch together and debate out the issues.)

Ken said that Howard and Jan made progress toward resolvingtheir differences and they will take the issue offline and hope to geta solution plan in a couple of weeks.

Suggestions and ideas from Dan Ellentuck

1) Use Optimized Collections classes

Addresses bugs related to "Concurrency" classes, regardingconcurrent access to maps. Dan found concurrency classes written by Doug Lea, that are coming out in JDK 1.5. Presently the package iscalled EDU.oswego.cs.dl.util.concurrent.Dan thinks they are high quality and easy to use.He specifically looked at the concurrent maps classes.

Compared to collections.synchronizedMap this:

scales much better

High level of concurrency on long running operations

Prevents ConcurrentModificationExceptions under load

Simplifies coding

Disadvantages

Another external dependency

Funky package name (as yet)

Background reading:

Textof JSR-166spec

An article on the IBM developerworks site by Brian Goetz about the concurrentcollections classes implementation.

An overviewof the util.concurrent package by Doug Lea.