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)
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
- Sasha - I would like to see the ability to not
find things through the UDDI directory
(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?
- 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?
WSRP Presentation (Thomas)
- Any comments on the presentation as modified?
- Agreed to by acclamation
Call Terminated