OASIS Web Services for Remote Portals (WSRP) TC

WSRP Conference Call (5/2/2002)

Roll Call

Alan Kropp, Epicentric
Madoka Mitsuoka, Fujitsu
Takao Mohri, Fujitsu
Carsten Leue, IBM
Rich Thompson, IBM
Charlie Wiecha, IBM
Jon Klein, Reed-Elsivier
Adam Nolen, Reed-Elsivier
Mike Freedman, Oracle
Mike Hillerman, Peoplesoft
Sasha Aickin, Plumtree
Jeff Broberg, SilverStream
Alejandro Abdelnur, Sun
Stephen White, SeeBeyond
Andreas Kuehne, Individual Member
Thomas Schaeck, IBM
Andre Kramer, Citrix
Davanum, Computer Associates
Angel Diaz, IBM

Agenda

Accepting Minutes (Thomas)

• Accepted by acclamation

Usage Scenarios

Carsten's Content For Portals Scenario

• Content for portals
• 2 companies: contentforportals corporation acts as provider, another company acting as consumer
• ContentForPortals wants to make its content available to as many end users as possible
  • Needs an effective publication mechanism (so consumers can find the content easily)
  • Finding should be easy, as should integration
  • Portals act as cache to reduce hits on ContentForPortals
• Requirements for producer
  • Directory structure, e.g. UDDI, to find services
  • Standardized interface to integrate portlets easily
  • End users must be able to see the markup that ContentForPortals generates
• Requirements for aggregator
  • Needs to be able to aggregate multiple services and serve the info up for customers
  • Needs to have user information and authentication
  • Business Objective: It would be possible to provide a huge number of external pieces of information
  • Must be easy to integrate: be able to look up in a registry and integrate in a few clicks
  • Technology Requirement: the aggregator acts as a cache to make response time as small as possible and to lessen load on ContentForPortals
• Comments?
  • If you're going to have caching support, we're going to have to do a lot of stuff around caching and consistency
    • Carsten - we will need to have things like Expiry and other caching issues.
  • Thomas - Maybe we should make that last scenario (from last call) be a special case of this case
    • General agreement
  • Sasha - I would like to see the ability to not find things through the UDDI directory
    • Thomas - sounds good

(Sasha's phone goes dead. He misses the next 5 minutes or so of the call. Apologies to all.)

Adam's Scenario

• Four actors
  • News Feed service
  • Portal Administrator
  • Portal Service
  • End Users
• Basic flow
  • Portal Administrator will discover (through UDDI or not) the service and will add portlet to portal
  • Portal Administrator will customize the portlet to some degree
    • has a business relationship as a precondition
    • business relationship will be transferred by admin login
  • Two edit modes: admin editing and end user editing
  • Must be able to specify what caching mechanism is available; when the consumer should come back to the producer
  • End user will be able to override admin default personalization, choose what topics they are interested in
    • When they get a document, the end user id and the admin login is passed back to the portlet
• Alternate flow
  • Proxy relationship not transparent to portlet, the portlet is told that the content is being aggregated
• Comments?
  • Why do we need the alternate flow?
    • Adam - we need to know what organization the end user is from as part of business relationship
  • Sasha -- Do you want to know this information to be able to prohibit the consumer or so the portlet can act differently?
    • Adam - so the portlet can act differently; the protocol isn't the right place to deal with prohibiting this misuse.
  • Do you want to know who the end user is? Are you looking for the identity of the end user?
    • Adam - I was just assuming we needed to know that there is another consumer in the middle. We need to know who the business relationship is with.
  • Thomas - do you think that the admin and user prefs are separately identified?
    • Adam - They should be munged. There isn't an idea
  • Sasha - But there is some notion of the portlet providing admin editing view or end user editing view, yes?
    • Adam - I think in the setup the portlet would say "here are the parameters that are settable by admins, and which things are settable by others"
  • Alejandro - who would enforce this?
    • Adam - It's the portlet container's job to make sure that only the correct people get the correct access to the right preferences
  • Thomas - Is the UI for manipulating prefs provided by the portlet or created by the portal?
    • Adam - Either paradigm is workable. I would like for the portlet to provide a programmatic interface. Once you have the portlet provide the UI, then the portlet has all responsibility for deciding which prefs can be seen by whom
      • But isn't this a good idea? Shouldn't the responsibility for figuring out roles be at the portlet?
        • Adam - Maybe.
  • Thomas - we could have the portal send information about "I would like the admin edit view" or "I would like the end-user edit view"
  • This is a larger question of access control levels that the provider provides.
  • This is a huge issue for us in general - mapping portal users to the portlet, defining roles and groups will be a big problem.

• Thomas - Adam, can you take a second pass with these comments and add requirements to the doc?
  • Adam - Sure.

WSRP Presentation (Thomas)

• Any comments on the presentation as modified?
  • Angel - Great job!
• Agreed to by acclamation

Call Terminated