August, 2003 uPortal Developers Meeting Minutes
Summer 2003 uPortal Developers Meeting Minutes
uPortal developers meeting Cornell University
August 7-8, 2003 (a Thursday and Friday)
Attendees
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 (mdo1@cornell.edu) 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 | http://www.mellon.org/ ]
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
Luminis
(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:
http://www.jcp.org/en/jsr/detail?id=168
for an API for how to do what JA-Sig calls a "channel". WSRP is a specfrom Oasis:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp
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
Groups:
New filesystem group serviceorg.jasig.portal.groups.filesystem
Look at this file in the MAIN branch:
website/implementors/services/filesystemGroupService_tutorial.html
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.
Authorization:
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.
Motivations:
(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 www.osafoundation.org (common solutions group + Mellon giving Mitch Kapor money to make PIMs for higher ed)
OASIS
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:
http://sunxacml.sourceforge.net
http://www.jiffysoftware.com
Documentation:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
System roles:
Policy administration point – auth engine
Policy decision point – rules engine
Policy enforcement point – auth client
Policy information point – auth store
OKI
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.
Jim:
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
framework.
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
XLIFF 1.1
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 FTE.it 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?
Chuck:
(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 's group (was chair of WSRPcommittee)
at IBM Germany Stuttgart 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.
[ http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal]