[wsrp][interfaces]: Operational questions to discuss

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?