wsrp message

Subject: [wsrp][interfaces] Agenda for May 30th conference call

From: Michael Freedman <Michael.Freedman@oracle.com>
To: WSRP <wsrp@lists.oasis-open.org>
Date: Wed, 29 May 2002 15:58:56 -0700

Agenda for tomorrow's 8am PDT conference call:

Begin discussing the (attached) requirements document.  We will start at
the top with the sections that were in last weeks version [those dealing
with addressing, registering, and describing], and see how far we get.
If we get through the requirements that appeared last week we will start
on the two new sections [actions and sessions].

Calling information is the same as it has always been, namely:
1-877-302-8255 or 1-303-928-2609 (for intl)
code: 8814427

       -Mike-

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:
R1: [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:

Self-description/meta data:
R2: [must] A portlet service must be self-describing. A consumer must be able to interrogate the portlet service directly to acquire its meta data.
R3: [must] Portlet service meta data must be available to consumers before it is activated via consumer registration.
Q1: 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]?
R4: [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:
R5: [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:
R6: [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.
R7: [must] The specification must support registration.
R8: [may] Portals/portlet vendors may support additional [non-protocol] registration mechanisms. WSRP will not be concerned with defining such mechanisms.
Registration Inputs:
R9: [must] The specification must allow a portal to pass the following registration information:
portal name
portal [vendor] type
portal [type] specific meta data
list of supported portal extensions
list of supported portal services

R10: [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.]
R11: [may] The portal may pass information describing the portal [vendor] 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]
R12: [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]
R13: [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 are provided. When not empty a portlet service need not utilize any or all of a portals services.
R14: [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.
R21: [must] The portal service must not deny registration because of missing extensions (to enforce plug-and-play among various portal service vendors).
Q2: [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:
R15: [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.
R16: [must] Upon unsuccesful completion the portlet service must return a null identifier and a [webservices] error indicating the problem encountered.
Q3: [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.
R17: [must] A portlet service must safely perform the deregistration. It must deny new requests once it receives a deregistration reguest. It may either let existing requests complete before proceeding with the deregistration [i.e. make the deregistration a non-blocking pending operation] or perform the deregistration concurrently. If it performs the deregistration concurrently it must do so safely. Existing requests must detect that deregistration has occurred before executing code that references an active registration and return an error.
R18: [may] A portlet service may release transient and persistent resources associated with the registration [once it is safe].
Deregistration inputs:
R19: [must] The portal must pass the registration ID returned from the registration call.
Deregistration ouputs:
R20: [must] none if sucessful. Error otherwise.

State 2: Portlet Service Active

Summary:

Most of the interesting things happen while the portlet service is in the active state. This is where users can interact with the portal to (indirectly) operate on portlets. Rather then organizing requirements from the Usage document perspective (which looks at how a portal uses or operates on portlets), requirements are generally grouped by portlet operations (inferred from portal usage). These include:
Creating/managing/destroying persistent portlet entities.
Creating/managing/destroying sessions (transient).
Configuring a portlet
Customizing a portlet
Rendering a portlet
Processing a portlet action

Persistent Entities:

This sections discusses the requirements for creating/managing and deleting portlets that support persistent data of portal defined scope. I.e. customization data.

Sessions:

This section discusses the requirements for creating/managing and deleting sessions in support of transient information.

R22: [must] The specification must allow a portlet service to maintain transient information on an N to 1 basis where N is the number of discrete representations of transient data per portal and 1 being the portlet service.
R23: [must] The specification will provide this support by defining the concept of a session. A session will be an identifier passed between the portal and the service that allows the portlet entity to map back to the discrete transient information.
R24: [must] The specification must allow the portal to define the [portal] scope of the session. I.e. though its likely that a session is mapped to a user the portal must be free to define alternative scopes.
R25: [must] A session must be able to span all portlets managed by the portlet service.
R26: [must] The specification must allow for the session to be created either at the instigation of the portlet or the instigation of the portal.
R27: [must] A portal must maintain sessions needed by the portlet service.
R28: [may] A portlet service may choose to not create a session when requested to do so by the portal.
R29: [must] However if it chooses to not create upon request, it must never create a session as a side effect in future request processing. A portal may ignore such sessions created by non-conforming services.
R30: [must] The specification must allow a portal to tell the portlet service when a session is not longer valid/active.
R31: [may] A portal need not tell the portlet service when a session becomes invalid/inactive.
R32: [may] A portlet service may invalidate/inactivate a session at any time. A portlet service need not tell the portal when such invalidation/inactivation occurs.
R33: [must] A portal must never send a known invalid/inactive session to a portlet service.
R34: [must] A portlet service must be able to describe whether or not any of its portlets require session maintainence.
Q4: [open] Do we want/need to describe which portlets need sessions -- or sufficient as a boolean?

Portlet Configuration:

This section discusses the requirements for configuring and administering a portlet service. (This is an operation done to the service not the peristent entity).

Customization:

This section discusses the requirements for (and related to) customizing/altering a persistent entity.

Rendering:

This section discusses the requirements for (and related to) rendering portlets

Action handling:

This section discusses the requirements for (and related to) handling actions.

R35: [must] The specification must describe how a portlet represents an action request in markup it generates. And how such a repersentation translates to parameters it receives in its action handler.
R36: [must] An action must only have a single target [portlet].
R37: [may] A portlet entity need not define any actions.
R38: [must] Actions and their semantics are soley defined by a portlet entity.
R39: [may] A portlet entity may define many different actions [types].
R40: [must] The specification must allow a portlet entity to disambiguate which action has been invoked.
R41: [must] The portal must mediate action requests. I.e. all actions must be filtered through the portal. The portal must be able to recognize incoming [browser] requests as actions. A portal may provide other entry points for invoking actions.
R42: [must] The portal must invoke the action and wait for its completion before it invokes rendering on any component in its current render scope.
R43: [may] The portal may have an arbitrary timeout it waits for an action to complete. If such a timeout occurs the portal may choose to continue processing the request [or not]. However there must be no further communciation between the portal and the portlet (that timed out) during this request.
R44: [must] A portlet service must be able to alter the portal's notion of its window state and /or portlet mode in response to an action. The portal must honor such a request.
R45: [must] The specification must allow actions to be disambiguated
Q5: [open] Do actions imply rendering? Or should action responses indicate whether (a) rendering is needed (b) scope of rendering -- i.e. self/list of portlets/all (c) target/parameters for rendering request -- i.e. new portlet screen after form submission?