[wsrp][interfaces] Agenda for 5/23

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

I would like to talk about three things in our Thursday conference call:

a) I would like to address the open questions from last weeks discussion
on Instance Handles. [See my meeting summary or the end of this
message].

b) I would like to get preliminary feedback on the draft requirements
document covering the activation/deactivation phase.  [Requirements
attached]

c) I would like to discuss how we should proceed -- on this the issue is
there are many topics we can move onto -- what should we address next??
-- are there ways to accelerate our progress?

    -Mike-

Instance Handles Open Questions:
a) Can instance creation be implicitly requested by the portal?  If so
how is this implicit request reflected in the protocol?

Background:  If the portal is in control of instance creation (so it can
impose its semantics)  how do we intend to manage the interplay between
it and the portlet when a portlet operation should result in a new
instance?  For example, how does the following work? A portlet renders
its own customize screen but a portal wants to ensure a new "instance"
is created the first time a user customizes the portlet.  Do we require
the portal render/own the "submit" button so it can determine when the
action occurs?  Or do we pass information in the customize request to
the portlet so it can determine if it should create a new instance?

b) Do we need to support cascading operations?  If so for which
operations?

Background: Since we are supporting a notion of creating new instances
based on existing instances will portals use this to model hierachical
groups of portlets that they will want/need to support cascading
operations on?  For example, a portal on shared pages might have a
notion of the default/standard portlet instance that is used for all
users that haven't explicitly customized it.  Each user customization
would be a new instance derived from this initial one.   A portal might
want to have an efficient mechanism for copying this group of instances
(say if the portal supports a copy page function) or deleting this group
(say if a user with the default designer role deletes the instance).
Two mechanisms were described for handling this:  Have the protocol
support cascading operations.  Have the protocol support bulk
operations.    In the first, the protocol would accept a single instance
reference and the operation would cascade to all its children.  In the
later, the protocol would accept a list of instances references and the
operation would enumerate over each.

The main plus raised for cascading operations was the terseness in which
the request can be represented.

The minuses included making portlet development more complicated because
cascading operations require the portlet maintain the hierarchical
relationship and awkwardness/inability to return new instances
(mappings) on a cascading copy.

The pluses/minus for bulk operations are the reverse.

c) Finally, we discussed whether we required instance handles be scoped
to the entity that created them (the portal).  Unfortunately, I can't
find my notes for this discussion (They are at home).  I believe we said
that we wouldn't make this a requirement.  Rather, I think we said that
this "enforcement" should be doable via our security model.  Can someone
refresh my memory?

Title: Portal usage questions

Assumptions:

The portlet service is a container for one or more portlets.  How a portlet is implemented is defined by this container not by WSRP.  WSRP however strongly influences the model conveyed by the portlet service [container] to its portlets orginating requests from the portal are transported through it.

Security requirements are being discussed/captured in the Security subcommittee.  It is assumed there work will dovetail with this work.  Hence security requirements are [currently] not considered.

State 0:  Portlet Service Unknown

Summary:

> The portal has no knowledge that a portlet service exists. 
> From this state the portal transitions to a known state through a process
> of discovery.  Discovery is the process of learning the location address
> of the portlet service. The location address of a portlet service is the
> URL of its WSDL service description.

Requirements:

Two things need to be defined.  First, we must define what the location address of the portlet service is.  Second, we have to describe what if any requirements there are for discovering this address.

As stated in the summary, a portlet service's location address is the URL of its WSDL service description.

There are no must requirements for how this URL is discovered by a consumer.  Rather, portlet services expect that all consumers, at a minimum,  must be able to learn and utilize this address without any other software intermediary.    This leads to the may requirements:

[may] A portlet service may publish its URL through one or more public or private software intermediaries such as software registries.

As UDDI is the software registry in the web services stack a portlet service runs within, the WSRP group will publish a description of how a portlet service publishes itself via a public and a private UDDI service.

>

State 1:  Portlet Service Known

Summary:

> In this state the portal knows the location [and existence]
> of the portlet service.  From this state the portal can [uninterestingly]
> transition back to the unknown state.  Typically, however it transitions
> to the Active state through a process called enabling. Additionally, this
> is the state at which the portal can request a portlet service to describe
> itself.  This later ability is present through all states until it
> returns to unknown.

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

Requirements:

Meta data:

[must] A portlet service must be self-describing.  A consumer must be able to interrogate the portlet service directly to acquire its meta data.
[must] Portlet service meta data must be available to consumers before it is activated via consumer registration.

Question:  Do we need to define 2 levels of meta-data (summary and detailed) where only the summary information is available prior to registration [for security purposes]?

[may] A portlet service may publish some or all of its meta data externally to be accessed by consumers before becoming known or as an alternative afterwards.

We will define specific meta data requirements later to define the scope of the characteristics portlet meta data should cover.  For now it may be useful to note:

[must] A portlet service must be able to describe portal specific meta data in response to requests.  I.e. if a portlet is required to provide portal specific meta data to take advantage of portal specific capabilities (extensions), it must be able to do so.
 

Registration:

[must] To activate a portlet service [for a given portal], a portal must register its use. This is a one time event.  I.e. During the active state, a portal never reregisters an existing registration.
[must] Our protocol must support registration.
[may]  Portals/portlet vendors may support additional [non-protocol] registration mechanisms.  WSRP will not be concerned with defining such mechanisms.

Registration Inputs:
[must] The portal must pass a name for itself.  [Thinking is this may be a URN to the portal root/context -- this needs to be fleshed out.]
[may] The portal may pass information describing the portal [vender] type and version.  A portlet service may use this information for logging/monitoring or other purposes.  It may also use this information to infer extra portal capabilities [though it is recommended it use the extensibility list]
[may] The portal may pass an extensibility list.  The extensibility list defines the set of portal extensions the portlet service may choose to utilize.  This list may be empty [null] signifying no extensions are supported. When not empty a portlet service need not utilize any or all of a portals extensions.  [There was discussion concerning whether there might be mandatory extensions -- if there are this needs to be represented in the extensibility list.  Also it would be defined that portlet services that choose not to utilize mandatory extensions deny the registration]
[may] The portal may pass a service list.  The service list defines a name, location, and description for a set of web services offered by the portal for the portlet services's use. This list may be empty [null] signifying no services arer provided. When not empty a portlet service need not utilize any or all of a portals services
[may] The portal may pass a list of portal/vender specific meta data allowing the portal to describe/pass any non-standard information about it that it wishes. This list may be empty [null] signifying there is no additional meta data.   When not empty, a portlet service may ignore any or all of this extra information

[open] We discussed supporting completing a subscription process via registration.  Should we support in our first version or leave this as a portal specific extension for the time being?

Registration Ouputs:
[must] Upon successful completion the portlet service must return a registration identifier to the portal.  This identifier must be unique within the context of the service.
[must] Upon unsuccesful completion the portlet service must return a null identifier and a  [webservices] error indicating the problem encountered.

[open] We have speculated that a portlet service and a portal may need to negotiate to properly resolve what/how a behavior will be managed.  For example we have discussed that either the portlet service or the portal may manage personalization data.  How does this negotiation take place?  Does it effect registration?
 

Deregistration:

[Ultimately, I will move this to the section concerning disabling an active (registered) service.  I include here/now for symmetry so we might begin defining this API.]

When a portal wants to leave the Active state and return to the Known state [or subsequently to the unknown state], it deregisters itself.

[must] A portlet service must safely perform the deregistration. It must deny new requests.  It may either let existing requests complete [i.e. make the deregistration a non-blocking pending operation] or return runtime errors.
[may] A portlet service may release transient and persistent resources asscoiaetd with the registration [once it is safe].

Deregistration inputs:
[must] The portal must pass the registration ID returned from the registration call.

Deregistration ouputs:
none if sucessful.  Error otherswise.