[wsrp][interfaces] Agenda for 5/8 call

[Michael Freedman <Michael.Freedman@oracle.com>]

Our agenda is to continue discussing registration.  Attached is the
updated "Portal Usage Questions" documents.  Comments in bold are my
notes of things we have already discussed/decided.  So the current form
of this document also serves as "minutes" from last week.  I am
beginning to work on a requirements document that represents our answers
as requirements.  Hopefully I will have something to pass along within a
week.  Anyway ..

Tomorrow, we will pick up where we left off.  Namely, I would like to
start with:

What kinds of initialization do we envision a service doing when a new
portal is registered?  What information will it need from the portal to
be able to do these initializations?  I.e. what do we want to enable a
service to be able to do during registration?

I think one key aspect we will want to discuss is how/what does a
service/portal negotiate how they will interact?  For example, how does
the "negotiation" work between the two parties to resolve who will
manage the personalization data repository?

If we get through these we will continue down the list.

Title: Portal usage questions

State 0:  Portlet Service Unknown

Summary:

> The portal has no knowledge that a portlet service exists.

To define:

Portal locates portlet service.

Portal locates portlet service:

• Do we need to explictly define how a portal locates a portlet service? [No -- a service is found by address -- we will publish best practices for some common mechanisms such as UDDI]
• If we don't are there non-portal technologies we anticipate being used for locating the service and if so do we need to define how portals recognize portal services in these mechanisms (and what information they can get from them)? [Yes, UDDI]

If we don't, what identifies the portlet service?  [It is the URL of the WSDL service description]?

>

State 1:  Portlet Service becomes known

Summary:

Portal registers itself with portlet service
Portal acquires meta data from portlet service
 

To define:

Scope of a portlet [service]:

What is the scope of a portlet service?  Does it represent a single portlet or can it represent a set of portlets running in/managed by the single service? [A portlet service is a portlet container] -- Requires we can identify the portlet within the container.  No specific requirements for what this identity is -- leave to the spec leads to make a proposal -- obviously it must be unique within the context of the service.  Basic idea is the service will generate the id and return to potral at registration time.
• What function does a portlet service expect a portal to provide for it transparently? Some possible function includes:
In the protocol
• customization management:  is this optional or required?  what is the default behavior?
• URL rewriting
• Authentication
• Identity/Profile
• event [and action] management/dispatching.
• view context


We will talk about these in moer detail as they come up naturally in discussions.

Portal registers itself with the portlet service:

We have identified the following as function that should be possible during registration, are there others, do we need all of these (in our initial specification)?

establish the portal vendors  identify -- so the portlet can make adjustments to run in venders portal [Should we support extensibility -- most say yes -- one says no]

establish the portals identify -- so the portlet can distinguish between it and another portal it is servicing.

establish a trust relationship with the portal (that can be maintained on susequent calls) -- so the portlet can control the level of security it requires.

initialize themselves to be able to service this portal

complete a subscription process

communicate the set of portal services available to the portlet to plug into.  (Examples include, logging service, monitoring service, personalization repository service, etc.)

What information needs to be sent to establish a portal vendors identity?

urn, version -- Do we need to name the extensibility features themselves? - i.e. let a portlet service see a list of extensions it can bind to, it would be interesting if you could indicate manadatory/or not.  Is this separate from a portal vendors identity?  Folks think it is -- so move out as a separate data type.

What information needs to be sent to establish a portal's identity?

URN (URL) of the portal.
Should we support anonymously (i.e. an anonymous portal)?
Portal gets id on return from portlet service.
 

What portal meta data is passed?

extensibility list

service list -- URLs to WSDL service descriptions

URN of the portal -- context root

extensible list so vendor specific meta data can be passed

Should we restrict certain data just to registration time?  Or pass information all the time?

Should portlet services that need to know about portal meta data need to be stateful?  or can they be stateless?  I.e. is there enough

Question:  what calls in the protocol are required vs. optional?  i.e. is registration optional?  IBM says this can be expressed in the WSDL -- however then backed off and said this isn't standard/required in the wsdl spec.  Suggest instead folks could implement simple stubs for "optional" calls -- The original question was can we and how do we support simple portlets via our API -- i.e. one that doesn't want to implement the complexity of our container.

How does a vendor/portal pass non-standard information during registration so "aware" portals can have extended behaviors? [Via the extensibility list]

What should a portlet vendor be able to indicate/express in their extensibility list?  Just extension's name?

What kinds of initialization do we envision a service doing when a new portal is registered?  What information will it need from the portal to be able to do these initializations?

How does functional negotiation occur between the portal and portlets?

What information needs to be passed for a portal to make a portlet service aware of its services?  Are there specific services we need to define as common to all portals?  If so what are they?

What information (if any) does the portlet service return to the portal on successful completion of registration? [A registration id that the portal uses to identify itself in subsequent calls]

What information (if any) does the portlet service return to the portal on unsuccessful completion of registration?

Note:  this question may merely be asking what are the error states/codes we want to identify can be returned.

What information needs to be supplied by the portal to complete a subscription process?  How does a portal know it needs this information and ultimately get this information (particularly when the service is located using a standard directory service)?

Should a portlet service notify the portal that its been "upgraded"?  I.e. that some information communicated via the registration phase has changed (most likely meta data) -- or if a service represents multiple portlets, the addition of new portlets managed by the service.  If so how is this communicated?  If it involves the portlet calling the portal what information does the portlet service receive and how does the portlet receive it in order to learn where/how to communicate back to the portal?  Is this just another service type a portal can pass during registration? I.e. a portlet invalidation service? or just an event sent to the portal?

Should a portlet service be able to notify the portal that being disabled/enabled (i.e. the portal will [temporaily] be unable to communicate with it?  If it involves the portlet calling the portal what information does the portlet service receive and how does the portlet receive it in order to learn where/how to communicate back to the portal?  Is this just another service type a portal can pass during registration? I.e. a portlet "disabled" service?  or is it just an event sent to the portal? [deferred to after v1]

The following are security related questions that are being addressed by the security subcomittee.

• Does the portal need to be able to perform registration over a secure channel?  If so how does a portal know/discover that it needs to do this?  What technologies must it be prepared to use to communicate securely?
• What are the levels of trust that can be established/maintained?
• How are each level established/maintained?

Portal acquires meta data from portlet service:

• Can Portal's acquire meta data without being registered?  All meta data or just some?
• What information does the portal need to properly manage/use the service?
• How can the service's that understand vender specific extensions provide meta data concerning these extensions?
• When/how is this information expressed?  I.e. What information does the service need to know to return the meta data including vendor specific meta data.
• As a portlet service represents multiple portlets what forms of acquire meta data do we need to support?  I.e. just getMetaData which returns meta data for all portlets managed by the service or additionally a getPortletMetaData which returns meta data for a specific portlet.
• How should internationalization be supported by our meta data framework?  I.e. must all NLS strings be passed in the meta request or only a subset?  If not all, does the portal identify the specific set it is interested in?