Child pages
  • August, 2003 uPortal Developers Meeting Minutes
Skip to end of metadata
Go to start of metadata

Summer 2003 uPortal Developers Meeting Minutes

uPortal developers meeting Cornell University

August 7-8, 2003 (a Thursday and Friday)


Dan Ellentuck – Columbia U .
Alex Vigdor – Columbia U.
Stephen Barrett – Cornell U .
John Fereira – Cornell U.
Aaron Hamid – Cornell U.
Dave Koehler – Cornell U. – Thursday morning only
Rich Marisa – Cornell U. – Friday afternoon only
Michael Oltz – Cornell U.
Peter Kharchenko – IBS/Unicon
Ken Weiner – IBS/Unicon
Kevin Gary – Unicon/IBS, architect of Academus
Jon Allen – Instructional Media andMagic (IM&M)
Justin Tilton – IM&M
Jim Farmer – JA-Sig /IM&M(project 'clerk' or 'administrator')
Shoji Kajita-- Nagoya University , Associate Professor; and CEO of his own company which is the main distributor ofWebCT in Japan.
Mark Boyd – SCT
Jan Nielsen – SCT
Mike Zackrison-- SCT
Chuck Severance – U Michigan – Friday only

These notes were taken and edited by Michael Oltz ( and corrected with input from the
presenters and other attendees. Most of the links for companies, organizations, and standards are
provided only once, usually at the first appearance of the name. A few are provided multiple times.

If no link is given where you notice a word, go to the beginning of the document and search for it.

Decisions and action items are indicated by non-link underlines.

Thursday August 7

Ken – introductions, agenda changes
The goal of this meeting is to nail down the completion of 2.2 – one conversation will be how to complete what
we are working on,another to discuss future features.

JA-Sig board perspective, by Dave Koehler – he is directorof Business Information Systems at Cornell, and
is on JA-Sig Steering Committee (often called the "JA-Sig board")

JA-Sig started in 1999 (java In Administration) to cooperate developing academic
administration software in Java. Mostly to learn from each other, and reuse code.

The JA-Sig Clearinghouse is to exchange miscellaneous freecode and other things. The board intends to increase
promotion and use ofClearinghouse. (a) Share more than just code, e.g. channels (b) get at itthrough uPortal.

At the first JA-Sig meeting, it was asked, what should JA-Sigcollaborate on? All the schools were looking at
portals. So that's what they decided.After that started, a number of 'lurker' schools said, let therest of the
world use it too, not just for the schools that write it.JA-Sig went to (Mellon Foundation | ]
for money to support broadening what kinds ofschools could make use of it. They required that uPortal be open source.

The implementation schools are learning a lot from theproject. Bernie Gleason
(of Boston College ) said that the total effort had a value of $3 million,
but the results are given away free. Java and portals are not the onlythings that need coordination;
so now JA-Sig has the reputation of not justtalking but doing something. Colleges are asking JA-Sig to
give guidance re other open source ideas, what to use, how to connect it together, choosing standards.

For example JA-Sig is trying to help start up aneffort ofopen source financials (in conjuction with
National Association of College and University Business Officers NACUBO ]
including a vendor and several colleges; Mellon Foundation is not as interested in funding this one.

Dave mentioned 2 articles inChronicle of Higher Education August 1, 2003
about open source in general, and about effects on highereducation of Oracle's
takeover ofPeopleSoft .

He also mentioned a book"TheCathedral and the Bazaar "
– how open source model worksand why it works. (The Cathedral and the Bazaar: Musings on Linux and
OpenSource by an Accidental Revolutionary revised edition, by Eric S.Raymond, O'Reilly, 2001)

The first production site: Universityof British Columbia (hereinafter "UBC") went live
with uPortal inSeptember, 2000. 30,000 students. Live only with freshmen at first.

Mellon funding is running out. Unicon has offered to continueto support Ken and Peter at least through the end of 2003.

Some colleges are comparing raw uPortal with
(formerly called Campus Pipeline), which to go with. JA-Sig is pleased that companies are embedding uPortal.

next JA-Sig conference is in Miami Beach this winter

Jim question: Dave, what do you consider to be the impact ofthe Oracle/PeopleSoft merger?

Dave: If we don't bury our heads in the sand, the way wehave chosen is not necessarily the way that will sustain value.
Yale Princeton Columbia etc. will be in existence 50 to 100 years from now to support our environment, corporations
may not or may be doing different kinds of things.Our handshake to others is an open hand, palm up – we want it
for free. Our cycle is the gestation period of an elephant, it takes a long time to decide what to do.
Colleges tend to heavily customize canned products and that means we have to support it ourselves.
In the long run,the Oracle/PeopleSoft will at least be a wakeup call to consider strategy.
Nothing against the two companies as products, but what about total costand fit to the problem.
Dave's original take was it was a brilliantmarketing ploy for Oracle, not that Oracle reallywanted it.
Now it has evolved into a conflict between the CEO's. They're presently waiting for the anti-trust ruling.
But even if they do merge they would still be number 2 to SAP .

Carl Jacobsen (at Universityof Delaware , on JA-Sig Steering Committee) attended NACUBO conference.

Ken: What is the board's take on the portlet(JSR-168 ) spec.Does the
board expect uPortal to be compliant?
Dave: I'm not the technical member of the board. We have nothad a specific conversation about it. If you want
board approval orconsideration, write a one-page executive overview.

Ken: Will it be a problem if a lot of portlet-compliant containers come out and uPortal is not one of them?

Dave: We want open-standards, generally accepted things.

Jim: there is WSRP ,Portlet, and
Jetspeed's Velocity. Will a Sun Java
portlet spec emerge as a strong business force? Dave, what is JA-Sig board's relation to Sun ?

Dave: I don't think I can answer Ken's question. The developers have made good decisions in the past.
Ken, please keep telling us what technical issues we should consider important and evaluate.
Sun has been our benevolent benefactor so far. Weare more interested in their architects/luminaries than
in marketing types. They have contributed something toward conferences. Sun cancommunicate with this
kind of market without JA-sig, butnot as well. Sun was concerned about the percentage of sites running on
Sun boxes, but the issue is behind us.

Sun is not as eager to support the Clearinghouse as the other things. Dave thinks we have an influence on what Sun does.

Ken: What about Jim Farmer's role? What will happen when the funding runs out?

Dave: I don't know exactly how much is left in the pot. Jimis careful about spending. What Jim does is
'virtual glue' to other organizations. They are looking for some other source to continue this.

By the way, Columbia is trying to get a Mellon grant for CUCMS (Columbia University Content Management Suite,
information and download available from the JA-Sig Clearinghouse).

Alex: That grant application is currently sort of in limbo.
Dave: Mellon (especially Ira Fuchs) is moreinterested in funding matching-fund grants now. Thein-kind contribution of
developers is not as important an influence onthem now as it was.

Ken: is it that we don't want funding from them or that wecan't?

Dave: We would like to get the money but the bar is nowhigher. They won't give money for 'evangelism'
they want development tohappen from the money and they want to see a plan for after-grant
continuation of the results.

Jim: One bad thing is, if Mellon hadn't been so positive to begin with, the board might have
taken another direction back then and there would not be quite this problem.

Kevin: What is the board's metric of success re uPortal?
Dave: a) It's a great product in and of itself.
b) Continued exploration of the context of deliveringproducts and services to the community. E.g. the content management
project.SCT's learning management system. Connection to other standards groups and so on. A lot of serendipitous discovery is happening.

JA-Sig is now kind of an aggregating group for higher ed.

HEKATE is a new higher educationorganization whose focus is on web services and on using the web to facilitateeducation.

So far you developers and uPortal in general have 'bet on the right horses'.

Jim: There will be questions based on the opensource article. Jim summarizing what Dave said:
1) Uportal – JA-Sig board expects project tocontinue more or less in the same form.
2) Board now strongly supports open standards.
3) Board has a broad application interest.
4) Board satisfied with architectural decisions.
5) Clearinghouse is important as a service to thecommunity.

Common Solutions Group has not actually come outwith any specific solutions.
UPortal has. Dave congratulates the uPortaldevelopment group; the product continues to "wow".

Jim: What about corporate interest?
Dave: We don't want uPortal to fork into a corporate vs. a higher ed version. We don't want to lose control.
We're wary. Companiesexpect high-class service.
Potential problems: (a) if corporations invest bunches of money, the H.E. community won't get as much attention.
(b) what if corporations hook in vertical-market standards orproprietary things, and we can't get
the code?E.g. ".NET" ??? That's how the forking would happen. "They're bigger elephants than we're used to."

Second session

Jim: Transitional comments: The reason for all thequestions at the end of Dave's talk was, we wanted you to have
authoritative answers;"When Dave talked to us, this is what he said"
a) What is happening to the uPortal project?
b) why are they doing other things?

Jim on CHEF: What is the "there" there? The CHEF project plans to implement their own 13 services there,
which is more academically relevant than raw OKI. This will not be incorporated inthe framework but will be available to uPortal community.
(CHEF is software for group collaboration developed at U Michigan. Presentation on it on Friday, see later)

Ken on Portlets (JSR-168) and WSRP (the second session]

[JSR-168 is a specification from the Java Community Process:
for an API for how to do what JA-Sig calls a "channel". WSRP is a specfrom Oasis:
it defines how a client can aggregate application data from a remoteserver via web services.
It would replace or parallel Ken's "remotechannels" feature.]

a) If we took the spec seriously, could we do it in uPortal 3.0?
b) Would we have to cut features?

Jan Nielsen thinks there's a great advantage, "we can't not do it". All the other horses will
overtake you if you don't do it.And we will be abandoned. SCT really
wants this. He's not so comfortable with WSRP, not as much confidence.
Jan expects the Java development community to run with JSR-168 "like a wildpack of dogs". (because it is from the Java community per se.)

Ken: WSRP is an enabler – it allows things to communicatewith each other once they have been written. (it is for remote channels)
JSR-168 is a container specification really. Do we write a wrapper for 168 ontop of uPortal? Or rewrite uPortal to 168 and make
a wrapper for IChannel? Rewriting uPortal would take about a year.

Kevin: Also get involved in the standards process for 168 version 2.0.
Peter: A technical detail, the spec says that portlets mustbe loaded with the same class loader as the framework.
This is problematic forour implementation of CAR files (channel archive files, like a jar).

Aaron: Did you say features would be cut?
Ken: Some of the features we've done may not make sense in 168.

Steve: What do people think is the timeframe of adoption and rollout?
Ken: As a first step write WSRP and try to write an adapter.

SCT says the industry will adopt JSR-168 rapidly.
Steve: We need an analysis of how much it needs to be altered to do it.
Ken: Gut feeling – a lot.
Mark: – It will be easier to rewrite uPortal as a portletcontainer than to write an adapter.

Ken: Adopting another JSR-168 portal framework in place of uPortal is technically one of our options.

Alex: What we're better at is value-added stuff, e.g. groups and permissions.

Jan: It would take 4 people for 6 months (a deliberately casual estimate)

Peter: The rendering is not going to be so difficult, it's the authentication, handling users, etc.
Ken: I am not so concerned about those issues. We alreadyhave mechanisms, just make the
168 API call that. I agree with their estimates.I compare it with what we did in going to
2.0 rewriting the internals. But itwill be easier to assign work this time around. And there
are compatibility tests available for 168. The difficult part will be morphing legacy code. Two person years. (4 people for 6 months).

Ken: If we don't implement JSR-168, we'd be making a one-off portal that isn't standards compliant.
Jan: Maybe JA-Sig should concentrate on integration rather than the framework.

Jim: In terms of adoption, Plumtree is first,
Vignette is second, and uPortal is third largest
enterprise portal in USA.

Steve: We should present several options to the board, andthe first option is to
get involved in the spec.

Mike Z: I suggested a year ago we get connected to the 168group. But at the time the uPortal group was focused on remotechannels/WSRP.

Jim: I recommended to the JA-Sig board some time ago thatthey not get involved in standards, because
it takes a half- or full-timeperson and a lot of travel money. Costs about $150,000a year.
UPortal has an opportunity to be commodity implementation because of so many sites.

Jim's suggestion:
(a) Ken and I will write up pros andcons of JSR-168,
(b) go to developer list for comments,
(c) go to ourcommercial partners and ask how important it is,
(d) present thedocument to the JA-Sig board. He thinks that Gartner and their competitors arehesitant to make a call about 168.

Jim: SAP is now selling their product with MySQL db instead of Oracle.Oracle is losing market share.

Dan: In reference to Ken's motivation. I think uPortal gotthe extent of adoption that it did because it was trying to be a creditableimplementation for higher education, not by trying to compete with anyone. Idon't think we should see ourselves as competitors to IBM and Sun.

Mark Boyd: I hear such comparisons often because uPortal isbeing used so much. The competition is in the eye of the beholder.

Kevin: I think uPortal's main competitor is Jetspeed. Ithink uPortal won by being advanced re XML, and by being by and foracademia.

Steve: Doing things the higher ed way, other vendors have tobe torqued in.

Mike Z: Within a year, anybody's shopping list for portalswill have a checkmark for 168 compliance.
Kevin: The market will become 'buy a portalcontainer', and 'buy portlets'.

Jim: Apache is really good about getting their products out.Except for Jetspeed.

Jim: If we do my suggestion, I don't think the board willdiscuss the technical aspects of it.

"Do we use the word 'portlet'?"

Ken: If we incrementally implement JSR-168, gradually, wewould have hybrid channels and people would start calling them portlets. Ken doesnot want to go down that road.

Jan: We need to find out whether Jetspeed will do 168 andhow soon.

Mark: Join efforts with Jetspeed????

Jim: Indiana is the only university that strongly supportedJetspeed. Michigan followed them. Now Michigan wants to go to uPortal.Possibly Indiana as well. I will continue tosay "channel".

Ken: Until we get feedback from the board, steady as we goon development, don't start this yet.

Peter: Our options will be limited by what resources areavailable. Could we get more programmers?

Jim: Two options (a) business partners may contribute time,(b) go to Mellon's competitors.

Update on WSRP (Ken)

Ken: talked to people on WSRP team atJava One . Ken usedAxis instead of Java XML reference implementation. He was able togenerate from the WSDL (analogous to IDL for RPC). Now he has to write the client and theserver part. He got started with it, got pulled away by other things,but he will resume this month (August). At first he thought just write aconsumer, but now he thinks will also write aproducer. It might not be perfectly compliant for 2.2 but it willbasically work, and we can clean it up for the dot release. The way you use itwill be just like remote channels. WSRP completely ignores user authentication. What we can do is if the channel usesCacheCredentials we can send the credentials along; this wouldn'tnecessarily be secure, but it's an option.
Steve: We (Cornell) are using authentication in the httpheader, so that takes it out of the standard for now, until thestandard addresses the issue.

Ken: I don't know how we will do this for sites in general.

Jim: When would a channel developer use WSRP?

Ken: A developer wouldn't use it, the choice is up to thesite admin: "where am I going to get my content from?"

Ken: Apache has a project Charon, which is based on codewritten at IBM Boeblingen. an WSRP compliance project.

Ken: One thing where WSRP is useful is you can load balance,move the cycles to another server. Or, share the information through avariety of servers.

Thursday afternoon session

CARs – Mark Boyd

A CAR is a way to distribute a uPortal channel in a single file, similar to a JAR.All the class files, media, stylesheets, and other resources are put into the file,and it is loaded from uPortal.
Mark will evaluate rewriting in order to take the Portlet(JSR-168) spec (the requirement about class loaders) into consideration.

JSR168 indicates that all portlets should be loaded with theweb container's class loader. Therefore he will see if the classpathcan be modified to find jars in the cars directory to help segregatechannel archives from third party libraries. Their names would alsohave to be changed from ".car" to ".jar" if we use the container'sclass loader. This would not permit dropping in new CARs withoutrestarting the server. You have to restart the container to see newjars. He will evaluate gonig back to using the container's classloader. With this in mind new CARs would not be recognized until thecontainer was stopped and restarted eliminating new feature item 4below. This approach would also eliminate use of third party librariesincluded within a CAR. On the positive side item 2 would be supportedautomatically.

New features

1)* Documentation
2)* Services and channel types deployable from CAR
3)* Support of more browser accessible file types
4) Automatic recognition of new* or updated CARs (see sentences above)
5) Replacement of CarResourceWorker (this would still be feasible with jars,referring to e.g. loading images)
6) Semi-automatic and automatic publication.
7) Third party library content.

  • Available in 2.2
    A separate class loader was used to provide class loading from adifferent directory beyond those defined by the servlet spec forwebapps and to allow class containers to have the file extension of".car". Also related is the use of browser accessible content distributed aspart of the channel in a CAR. Images can be served out of the CAR byuse of the CarResourceWorker. This will be revisited to see how much ofa performance gain can be had if such resources were extracted from theCAR and placed into a web server area. However, such resources wouldhave to be identified in some way for the infrastructure to be able topull them out. We have discussed various ways of doing this via eitherdefining an internal structure on the CARs akin to that of theservlet's spec or by specifying files via a deployment descriptor. Ifthe CarClassLoader goes away then an internal structure approach couldnot be used. Item 3 would then be solely dependent on the web server.
    A problem: What if the name of categories and groups in adeployment descriptor does not match what's on the targetportal instance? He will be looking at ways to allow theadmins to resolve this issue including possibly allowing for partiallypublished channels that could be viewed in the current channel managerand category and groups values could then be selected to finalize thepublishing.

Kevin: You could have a repository of CAR files somewhereand just point at that, not have to put on the specific server.

Mark: SCT uses CARs as their standard way of packagingchannels. Since action to implement JSR168 support is pendingdirections from the jasig board we will keep the status quo for now butinvestigate those items not affected directly like semi/autopublishingand deployment descriptor defined web-visible files extraction.

Ken: If we are going to make October we should wrap upcheckins by mid-September.

Groups and Permissions – Dan Ellentuck

Additions for 2.2


New filesystem group serviceorg.jasig.portal.groups.filesystem
Look at this file in the MAIN branch:
leaves are files which contain lists ofprincipals or refer to other groups. The benefit to Dan is that it is so easyto use this model, a good introduction for novices to how groups work. Afterthe file has been read in, the timestamp is checked to notice if it haschanged. And it's good as a debugging tool.

Mark: How might a Group Manager beimproved to be able to handle such a need?

Steve: I have a channel that letsauthorized people to download lists of users, edit it, and upload itagain.

Alex: We are thinking of usingCuCMS (Columbia University Content Management System) to manage the files.


Some Columbia departments had their own sources of permission information and
wanted to be able to connect it directly to the portal. Dan decided that the
information requested to be imported was proprietary and all they would be doing
is rewriting various rule engines. Instead, you would ask the remote server, does
the user have this permission? And it would just say yes or no, possibly with an
expiration time.

Model a Permission Request and Permission Response

Request captures a question about an Owner, Principal, Activity and Target.
Response captures the answer at a specific point in time. May be cached,
e.g. for certain Sources or Principals.
Authorization Source
Implements simple request-response protocol
Lets portal use already-existing authorization service as a client
Each will have a factory and you define it in an XML file.

Portal Authorization Service has a Configuration with multiple Sources and a default combining Policy.
This will have a factory and you define it in an XMLfile (this will be an enhancement of the existing authorization service).
(Somebody spell this correctly: NYSO? NISO? in reference toa role information format.
There is a "NISO" having to do with libraries, but I couldn't find the 'role' standard there.)

Jim: Examples – library systems have a mechanism to findout roles (it happens to use SOAP ).

Steve: The concept of authorization 'policy' is justbeginning to be understood, a 'yes/no' answer is not sufficient.

Jim: When you get a channel that can depend on permissions more than "yes/no" – well, roles are actually Group memberships.

Current uPortal Permission model

A Principal performs an Activity on a Target within thecontext provided by an Owner. Only the principal is multi-valued
(multiple parts of each value) and gives a link into the groups system.

Could Activities and Targets also be groups? So you could assign permissions en masse? The reason
to do this is to reduce the work for the administrator.

Aaron: Instead of making the uPortal authorization morepowerful, why not put an API over it so it
can be ripped out later and replaced? In which case, you would pass in an Object and get back anObject.

(a) Requests came in over the last year for anative way to represent complex roles.
(b) Dan read the OKI materialsand saw their use of "types".

Dan is suggesting this as a future idea. "It feels like there's very little support for it here."
Jim: Not necessarily.

Jim: As an aside (common solutions group + Mellon giving Mitch Kapor money to make PIMs for higher ed)

Extensible Access Control Markup Language ("XACML")
A subject performs an action on a resource.This is captured by a target.
The logical unit of authorization is the Rule.Rules are aggregated into policies andpolicysets.

java implementations:


System roles:

Policy administration point – auth engine
Policy decision point – rules engine
Policy enforcement point – auth client
Policy information point – auth store


OKI Open Service Interface Definition ("OSID") for Authorization:

An Agent performs a Function within a Qualifier. This iscaptured by an Authorization.
Agent may be individual or group
Qualifier is context and may be nested
the Agent Function and Qualifier each contain aType, a nested category meant to model an organization.
AuthorizationManager reads and writes Authorizations andanswers authorization requests for a given Agent, Functionand Qualifier.

One way to work with OKI is to write an external OKIadapter, and interface to the Authorization Service. Or, we could wrapthe current AuthorizationService with OKI and therefore make itbidirectional.

1) Some people are skeptical because there's not much 'there' there.
2) Mellon doesn't know what to do regarding OKI. However,many parties are saying that said parties plan to rush to do it.
3) Michigan plans to implement OKI by October.

Kevin: Why are they reinventing the wheel, when are theygoing to actually do something, and it doesn't seem to be verye-learning oriented.

Peter: it seems that MIT had some problems they wanted tosolve on their own and wanted to do it in a general way.

Kevin: Why is CHEF (see session below) talking to OKI?

Jim: Mellon funded OKI, and Mellon is funding Michigan (their model is collaborative) Stanford's model is
assessment. Mellonfunded U Washington to do PubCookie
but everybody else is using Yale's Central Authentication Service (CAS).
He feels XACML seems to have the least momentum behind it of all the role representations. SAP has released
all its interfaces,and PeopleSoft is coming along, so these don't seem to be such a big deal.
(side note: Aggregated layouts relies heavily on groups and permissions and is not very fast)

Jim: It seems that the external authorization need is moreof a channel concern rather than a framework
concern. the local groupsand permissions model was written more for the

Internationalization: 2 vs 3 letter codes, Ken

How does the locale get represented? the default 2 lettercodes or 3 letter? 2 letters leave out many countries and languages. isthere a way to use the existing object and squeeze 3 letters in it?

Ken: make a custom one that can return a java.util.Localeobject on request.

Jan: maybe we can use the variant field of the defaultLocale object to hold the 3-letter part. This is better because we canuse the object with standard resource bundles.
Ken: but we can still do it with our custom class by lettingit return a default Locale object whenever we need it. if we use3-letter as a variant, what would we pick as the 2-letter base code?

Jan: The variant is a vendor-specific field. so we canchoose whatever we like for the 2-letter code?

Jim: Let's write a letter to the Javacommunity to recommend that they use3-letter standards because libraries started to useit. Also write to WSRP and JSR-168. Alsoto the U.S. governmentOffice of Management and Budget (OMB)to recommend that federal procurementrequire this. Drop the 3-letter requirement for uPortal for now andwait for the responses. jim writes, vetted by developers, vetted by the board,go out.

The group agreed tomove forward with 2 letter code support for uPortal 2.2. Thisallows us to use the standard java.util.Locale object throughoutuPortal.

XLIFF: (by Justin)

(a sort of IDL for making files in N languages) you make a skeleton, then translate the
text into other languages. OriginallyJustin and Peter were using the original English
string as the translation unitidentifier but that will not work in
where it has to be a single token.Peter is writing a Swing tool that makes skeletons and allows you to fill them in.

Peter says the editor won't be ready for 2.2 but suggests that there is some preparatory work
that might fit. Make a helper class that reads the list of locales then read couldn't type fast enough

There was some discussion of implementation details of this idea.

Friday, August 08, 2003

uPortal and CHEF by Chuck Severance

The Comprehensive collaborativE Framework (CHEF) initiative isa Jetspeed-based application developmentframework from the University of Michigan. The CHEF project would like their tools to work both withJetspeed and with uPortal.
"We're kind of a bad portal." – The personalization is very limited.We're very interested in building a lot oftools. it doesn't LOOK like Jetspeed.
Course Management System – Course tools
"Work Tools" – Research collaboration system
It's more like an aggregated layout rather than user personalizable.
U Mich created "My UMich" based on Apple WebObjects .But a new manager at U. Michigan decided not to continue that project due to financialconsiderations.

The portal engine is Jetspeed/Velocity /CHEF."Teamlets" are what they call the 'channels'.
There are these things called "Services" – variousAPI's to do various common things like DB connections.
They have a concept like uPortal servants.

CHEF is more an application rather than a portal. They emphasize the tools behind it rather than the framework.
Jetspeed will be evolving based on WSRP and JSR-168.
UMich wants to take advantage of various uportal thrusts:
– aggregated content
– XML at the core
– WSRP and JSR-168 implementations

Want to add these things to what JA-Sig is doing
– Notion of services
– Super-duper-channel
– CAR and then Super-CAR

CHEF implemented their services before OKI appeared.
OKI has a concept of 'API's' and 'Factories'; it's just interfaces.
Chuck considers a service to be the actual implementation, rather than the API.

What is a Service?
– Long-term lifecycle
– One instance
– Must be aware that multiple users can use service
– Can use memory resident information
– Pluggable interfaces

Each service has a 'cover' (a design pattern) for how to instantify it.
UMich uses Jakarta Turbine to find and load services.

Super-CAR file (he wants something like this)
Standardization for interchange of two types of packaged components
– User Interface package is one kind
– Service package which describes the broker forgetting at the service.

(Essentially he envisions the portal as being assembled from pluggable pieces.)
He wants there to be an "UI" layer so that a channel could go either to a portal or run standalone.

CHEF 1.1 just released (July? 2003), there is still another year on the project.

Secret Plan for Total World Domination:
– uPortal and CHEF steal best practice from each other

Ken: I don't think uPortal and CHEF are as similar as you mentioned
Ken: Is Jetspeed really moving toward 168?
Chuck: Those Jetspeed people have been doing something insecret. it seems to be 168 related but they are not talking about it.

Jim: Regarding services, when and how with respect to OKI?
Chuck: Someone was supposed to be working on OKI but theywere pulled off to work on 1.1 but from now on we will have 1.0 will probably take a year for theirone person to get an OKI reference implementation done.

Jim: What is the priority of the 13 CHEF services you have?Would they be available to JA-Sig developers? How would you expect usto use them?
Chuck: They are done, and yes. For example the userdirectory service, he explained how to do it – it would require use ofTurbine.
Aaron: This seems to look like Web Services?
Chuck: No it looks like Turbine. Turbine is pretty much a service broker. (Ken thought it had a lot more in it.)
Aaron: Could you layer Turbine on a Web Service?
Chuck: Absolutely.

Jan: You seem to want a broker for (brokers such as CORBA orEJB's). I (Jan) wouldn't find EJB's attractive in uPortal context.
Chuck: a) "My first desire is to create a market ofpeople writing services."
b) My second desire is to get uPortal to use our services.

Jan sees the lifecycle aspect of CHEF as key to the designand most useful to others.
"Chuck's OKI periodical table thing." A way tofind and connect to all the modules of a web thing.

Dan: a) What do you expect to get out of other places using your stuff?
b) What do you get out of being an OKI implementer?

(a) Our provost is willing to invest large-scale indevelopment at UMich only if we collaborate with others.
(b) Michigan has received more than a million dollars ingrants related to its CHEF effort.
If something doesn't have OKI it's going to be harder to sell.
OKI is becoming a checkoff. (A question that people ask before adopting something)

Jim: When will the point come that this can be used by forexample UPortfolio?
Chuck: Right away.

Jim: Jeff Merriman at OKI said in Italy "Web Services are dead".
Chuck: What he really means is Web Servicesare not the only thing on this planet. But he has to say
it dramatically to get other people to think out of the box.

Chuck: The concept of a channel or a teamlet needs to be broadened.

Ken: If Jetspeed is doing 168, do you think we should do thesame thing, or combine efforts?
Chuck: Been thinking about that. Look at what the true valueof uPortal and CHEF is. The aggregated
layout aspect, which I don'tthink 168 handles well. Should uPortal be a competitor to Jetspeed?
I (Chuck)will not write another 168. I won't invest the year of my 8 or 9 programmers todo 168.

Ken: If we didn't do 168, would you still adopt uPortalanyway based on functionality?
Chuck: If Jetspeed had 168 but no aggregated content, anduportal had no 168 but it did have
really cool aggregated layout, I would pick uPortal. What I really want is 168, aggregated layout,
and CHEF tools working in it, with OKI. Should you merge? Well there are certain predispositions in
Jetspeed that may make that painful. Butif you jump into Jetspeed, don't lose the unique things that make uPortal what it is.

(Later in the morning, Chuck Severance arranged a conference call with one of his staff so we could ask questions.)

Glenn Golden, chief architect of CHEF, one of the Jetspeed committers, on aspeakerphone

"Jetspeed 2" project is probably JSR-168 related.
Project Pluto is a Jakarta project
that will be the referenceimplementation of JSR-168. Thomas Sheck (question)'s group (was chair of WSRPcommittee)
at IBM Germany Stuttgart (question) is writing it and contributingit to Jakarta as soon as the voting
process on JSR-168 is finished. It is aportlet container, not the other aspects of Jakarta.
(there seems to be an email that leaked out). Pluto would implement the API's and the lifecycles.

Chuck: uPortal group was thinking it would take 2 personyears to do JSR-168. Will Jetspeed be able to put that much into it?

Glenn: IBM has probably known for a year or more what 168 would look like. I think that the
Pluto code will actually come out. Ithink Jetspeed will go in this direction.

Chuck: Will Jetspeed's Velocity survive?

Glenn: I think so, it doesn't overlap what JSR-168 specifies.
(end of call)

Ken: Let's wait for Pluto and see if we can integrate it.


Internationalization, Shoji Kajita

Here is an information page .
To-do list:
1. User interface changes
2. Database changes
3. Resource translations
4. Code changes
5. Documentation
6. what next

1. UI Changes
to let users select the language to be rendered insubscribing channels. Some of this will be in 2.2.

2. Database changes
One additional column in UP_LAYOUT_STRUCT table(LAYOUT)
Eight new tables
*: added after meeting

3. Resource Translations
It was pointed out that there need to be more changes to the database.
Metadata is also needed for UP_USER_LAYOUT(question) and for theUP_USER_PROFILE

4. LocaleManager class
One instance of this class for each user
There is a locale choice associated with:
user profile
user layout
channel definition (provided by developer, may be modified when published at a particular site)
layout struct level (subscribe time)
HTTP session parameter
browser (i.e. ACCEPT_LANGUAGE)
uPortal default locale from properties
JVM default locale setting
(if a given listed setting isnull, fall down the table to the next setting, etc.)

should there be a separate class for GUEST user? Peterpointed out that the logic would be different.

Ken: In properties, we specify all the languages that could possibly be chosen for the framework.
But channels can specify they have other languages, so you can add another language.
The user profile level will for the time being be the same as the properties.
At the user layout level there will be a Language Preference channel, to specify preferred
languages in order, from thelist provided in the properties.

A suggestion to be able to specify language at fragmentlevel (tab, column), was
rejected because there is not enough time to implement it.

Peter said that the languages that a particular channel can support is known by the channel
developer and should be in thedeployment descriptor (see the CAR concept).Provided at prepublication.
when loaded into a particular site, thesite admin should be able to modify it.

At the publication time, show the site admin what the sitedefault is, and let them copy in
to the specific channel's list if theywant. Or they can leave it blank.

At subscribe, if there's zero or one language the channelcan display, then the user should not
be given the ability to choose a language for that channel.

There will be a language preference connected per user also (there will be a UP_USER_MDATA table)

What is the priority of the locale, as looked at by channelwhen deciding how to render itself:
This is the order in which thevarious locale settings will be put into the array that is sent to the localeresolver.

subscribe time setting for a channel (could be null)
publish time setting for a channel (could be null)
user layout preference
browser specification
portal wide (.properties) setting
Java locale default

for a guest user, they would have an empty localepreference, and use the same logic.

The resolver will be an interface with a defaultimplementation, chosen in

Alex volunteered to write the resolver part. orat least start it.

Ken: Who will make the database changes, they haveto be done first? Nobody will volunteer to do it. It has to be done beforeOctober. There was a lengthy silence.

Peter: "I can be in charge of finding somebody to do it." (laughter)
The problem isn't merely to do it, but to test itagainst many varieties of database. Peter will find someone.

Steve: We should abstract the database accesses.

Dan: Irrespective of how we do database access, weneed some unit tests, which would make it easier to make changes.

Aaron: Could we use Hibernate ? A generic persistence layer,database adapters etc. behind it.

Ken: Shoji will make the data.xml and tables.xml filechanges and send them to Ken. And the developers will introduce onetable at a time into the 2.2 codebase.

Shoji: A channel may want to know who specified a particularLocale in the input array.

Other people disagreed at first.

Dan: A particular channel may find it wants to override itslocale setting.

Alex: A particular channel may want to override itsresolver.

Ken: The need for such a thing will be rare, so there shouldbe some way to do this but not in the regular channel interface.

Peter: in RuntimeData there is no reference back to the portal.

Ken: What if we can choose a custom resolver at publishtime?

A discussion ensued about how to address this concern. Somedevelopers thought the array of Locales should not be in theRuntimeData or StaticData, as it's kind of aviolation of the insulation of a channel from the framework.

Ken: The channel should talk to the framework to find outthis information. Why not use IPrivileged?

Peter: No, the purpose of IPrivileged is for changingthings about the framework, like the Preferences channel.
People have been misusing it to access container information e.g. HTTPRequest which was not its original intent.

Ken made a command decision to end the discussion, andproposed that there will be a utility method somewhere
to be called todo the resolving. Others said that it would not work that way, it can't get atenough data to make the decision.

(the break for lunch occurred at this time)

Ken: The official word for 2.2 is that channels do not know the source of the locale array entries. As a workaround useIPrivileged.

Ken: Shoji checked in a class called LocaleAwareXSLT but Kenis worried that it will give an impression that this is the enduringofficial way to do it. The XLIFF group may change it all around in the future.So should it be checked in? Perhaps we will build this functionality into thegeneric XSLT class. Result: we are going to keep this class but change thenaming convention from what Shoji originally had. There would be a defaultfile with no special extension.

Shoji: Documentation – who will write it?

business logic" of Aggregated Layout – Peter

He showed a diagram of how Aggregated Layout (A.L.) code processes the rendering,and explained it.

He explained how you describe pushed fragments in XML, thenyou run an Ant target to load it into the database.
Michael (Ivanov) isworking on ability to load pulled fragments this way also.There were some comments
to improve the syntax of these files (most notably the groups should be referred to by their unique id, and not by their names).

restrictions on where a fragment can be in the user's layout,and whether and how it could be moved.
e.g. priority – how close to front of tabs or folders it appears.
depth – how far from root of tree it is.
parent – restrictions on what the priority of the parent folder can be.

Then you give a structure of folders and channels, and tellwhether they are immutable, unremovable, and/or hidden.

Then Peter gave functional descriptions of what the most important methods do, such as AddNode

Dan: By 2.2, make a couple of examples.

Ken: In 2.2 Aggregated Layouts will be enabled by default.

Peter: IUserLayoutManager (and its defaultimplementation) have been enhanced withseveral more methods to do A.L.

Integrated Modes" – the user interface partof Aggregated Layouts – Justin

New "Integrated Modes" Structure and Theme

Fragment Construction
This removes dependency on the "Preferences" channel;
should make new structure development easier
The User Preferences as a separate channel is gone.
There are some request parameters that the UI uses to do the integrated-modes editing:
delete node, show move targets, move node, show add targets, etc.
Justin showed what they look like in a URL line

There's no longer a header or footer channel; the lack of a headerchannel gives the site more control over what appears at the top.

The login channel appears as a wide narrow strip just underthe tabs. Again this leaves more clear room for graphics etc. at thetop.

If you resize fonts in the browser or change sizes of icons,the layout will adjust accordingly without the site having to twiddlewith it.

Justin and Jon Allen put a lot of effort into making it workthe same or at least work, on a wide variety of browsers, even Netscape4.x;
making this structure and theme work on NS 4 took about 80 percent oftheir entire time on the project.

Should we use tables any more, or just use nested divs? Somepeople were still using NS 4 which does not support DIVs.
But theydegrade fairly quickly, don't work well.

The framework UI uses very little Javascript. Only the clock, the alert/confirms, and the pop for the window detach are Javascript.

The new User Preferences Mode puts icons, text boxes, etc.all over the place right in the actual layout,
to allow the user tomodify things.

Demonstration of how a channel will be added; the userchooses which tab they want to add a channel to,
then choose which channel, then as a final step where on the tab they want to add it.
Up to 2.1 wehave had to choose the exact position first and then which channel to putthere.

John Allen tried to demonstrate the new stuff butit crashed several times; someone back at the
office had tinkered the demo portal the previous evening.

"If the demo crashes, that means it's good code --it's fresh code." – Chuck Severance

There is a demo site at
From the "im+m Portal Accounts" channel, choose"Aggregated Layouts/Integrated Modes"; that takes you to the 2.2portal.

Steve: why does the login channel look different?it seems to be in the toolbar of the channel.

Justin: We didn't want people to think of the login channelas a channel. We hacked the
stylesheet. We moved the login channel downinto the tab area so that the institution could have a cleaner header.

Chuck: I think it is great that every part of even the framework is itself a channel.

Peter: (reactions to implementation details mentioned in passing)
a) I think sending content to the theme stylesheet to get itdisplayed, is the wrong approach.
b) And the theme stylesheet should not explicitly refer tothe name of the login channel. The reason we put it in the header,
isso they could be in the same place all the time, and would render the same wayas any other channel.
if you want to move the login channel somewhere else, you need a different example of something being in the header.
c) It seems intuitive to me for the orange command line (during preferences editing) to be above the tabs.

Proposals for new features – moderated by Ken

a) Yale's Howard Gilbert's proposal for a new way to doerror handling. The uPortal framework code as it is, needs work in this area.
He wanted to be here via speakerphone but there was no speakerphone.

Use try/finally to close constructs
PortalException should not be thrown all the way to Tomcat. Should be captured first and have a more meaningful error message.

We called Susan Bramhall to ask some questions.

The ExceptionHelper is careful to log the error exactlyonce, and not multiple times as it goes up. The Helper
is put into the PortalException class. She thinks it gets called as a result of creating the PortalException.

There are many places in the code where a NullPointerExceptionhappens because the database can't be reached;
it is far better to throw some other exception, not return null.

Ken: Howard (who was out of the office when we called) needs to show the actual new classes he wrote, and give a couple of
examples, before we could make any decision. On August 13, 2003, a few days after the meeting, Howard posted a
long message to the developer mailing list about his proposal. Subject "Re: Questions raised about exception handling"

Dan: Howard should also explain the difference between throwing different classes of exceptions, and using the I.D.'s
and what is the advantage of the latter.

Susan: Maybe the Columbia people could come up to New Haven and we could have ...

Ken: An "error conference"

John Fereira: Someone at UBC had been talking about automatically contacting a specified
person when an error occurs. But what about frameworkchannels? It would be the portal administrator.

UBC was not present, but Ken read two proposals on theirbehalf. They want to be able to do an
HTTPS post and then go to an HTTPpage. So, they want to have a configuration parameter so that
after a secure login (authentication) they could go to an HTTP page.

Keith at SCT has the SSL channels thing mentioned at theprevious developers meeting partly done, should
he check in what he has done, or not? He asked some questions and got no answers. HTTPS is a separate cookie space.

Jan: "You will get popups in nested frames if you don'thandle SSL and non-SSL content consistently."

Resolution: Ken will suggest on the email that Keithcomment out the "Focus" ability and check in the rest of it.
He sent this email on August 8.

Ken: UBC wants to add the cababillity for image URLs to bere-written on the fly so they end up being loaded
via a proxy.This way the image URLs and the portal page will both be served viahttps and the annoying browser
pop up messages won't appear. We decided that we want to implement UBC's changes.

Jan: Wanted to use log4j directly so we can use categories.That is each message is in a particular category.

Consensus was that we would not do that, but extend LogService with categories, so that we could drop in another
implementation behind it when we drop support for 1.3 (see below)

Ken: When should we stop supporting 1.3?

Conclusion was, containers take a long time to switchto a newer major dot release. For example,
WebSphere tends to be abouta year behind. So Jan said we should
wait until 1.5 becomes widely available.

Steve: The PreparedStatements implementation in RDBMServicesis not complete enough; we need to make the
PreparedStatements field public. (or, make a get for it( (Alex: or make it more complete)

Steve: He wants more published channel metadata.We put two more columns in UP_CHANNEL to note a
primary and secondary contactperson for each channel.

Kevin: Nick – swapping out different versions of Xerces . Heposted a message to
the developer list on July 29 (Subject "Xercesdependency removal status") stating some of the issues he has with
particular parsers etc. but he did get it working for Xerces anyhow.check it in?

Kevin: We would like to see an abstraction of the CharacterCache.

Kevin: Enhancements for a character (text only) content channel that
does an end run around the transformations for efficiency.

Peter: Be sure to tell developers NOT to use it except as a
last resort. It's mostly for legacy applications.

Jan: He wants a factory method for the ChannelManager so he can plug in a different implementation.

Steve: He wants an implementation specific method for theStats classes.

Jim: Chuck has been trying to resolve the differences between OKI, JA-Sig, and Michigan.

Ken: Try out aggregated layouts and internationalization. Wrap up implementation by end of September.

  • No labels