[wsrp][interfaces]: Operational questions to discuss

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

Attached is the beginnings of the document I promised from our last concall. 
I apologize that it is incomplete as I have been drawn into other things
in the past week.  Anyway the document is intended to ask the questions
we need to answer to identify the requirements for the set of operations
we have identified are pertinent to our initial specification in the Portal
Usage document.  Currently the document lays our the set of questions
for state 1 -- when a portlet service becomes known or registered with
a portal.

Please:

• send me additional questions you think we need to discuss in this section
• begin to discuss your viewpoint(s) in the forum
• be prepared to begin discussing these questions during our next conference call this coming Thursday.
• be prepared to discuss whether/which questions we don't need to discuss because we don't believe the initial version of the specification should address.

It would be helpful to me (in maintaining this document), if you could
separate the correspondence relating to adding additional questions from
those that discuss your views on specific questions.  One way we might
accomplish this is to have you send questions you would like added directly
to me while posting your views to the general list.  I will then update
the document with your questions [and repost before Thursday].

In the coming week I will update the document with the additional sections/questions relating to portlet instances.
        -Mike-

Title: Portal usage questions

State 0:  Portlet Service Unknown

Summary:

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

To define:

> No communication/operations to define.

>

State 1:  Portlet Service becomes known

Summary:

Portal locates portlet service
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?
• What function does a portlet service expect a portal to provide for it transparently? Some possible function includes:
• personalization management:  is this optional or required?  what is the default behavior?
• event [and action] management/dispatching.

Portal locates portlet service:

• Do we need to explictly define how a portal locates a portlet service?
• 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)?
• If we don't, what identifies the portlet service?  Is it the URL to the WSDL?

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

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?

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

What are the levels of trust that can be established/maintained?

How are each level established/maintained?

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?

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)?

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?

How does a vendor/portal pass non-standard information during registration so "aware" portals can have extended behaviors?

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 information (if any) does the portlet service return to the portal on successful completion of registration?

What information (if any) does the protlet 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.

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 jsut 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?

Portal acquires meta data from portlet service:

• 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?
• If 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?