[wsrp] WSRP / JSR 168 Alignment

[Thomas Schaeck <SCHAECK@de.ibm.com>]

Dear WSRP / WSIA TC Members,

please find attached a summary of our recent discussions with the JSR 168
spec leads.

Alejandro, Rich and Carsten will give an overview of the recent discussions
in today's TC call.

Best regards,

Thomas

---------------------- Forwarded by Thomas Schaeck/Germany/IBM on
10/24/2002 01:42 PM ---------------------------

Stefan Hepper
10/24/2002 11:15 AM

To:    Thomas Schaeck/Germany/IBM@IBMDE, Carsten Leue/Germany/IBM, Rich
       Thompson/Watson/IBM
cc:    Alejandro Abdelnur <alejandro.abdelnur@sun.com>, JSR-168-EG@JCP.ORG
From:  Stefan Hepper/Germany/IBM@IBMDE
Subject:    recapping discussions with WSRP editors



Dear WSRP TC and JSR168 EG,

[This email is being sent to the WSRP editors and JSR168 EG aliases.]

Following there is the list of areas we found we have to work to
ensure a proper alignment between JSR168 and WSRP specifications.

This email is correction/addition/clarification to the previous
email we've sent to Thomas a while ago, the one that has been
forwarded to both groups.

Please let us know of any corrections, additions and questions
you may have.

Regards.

Alejandro / Stefan
JSR168 specification co-leads


[IINA acronym: Impact If there is Not Alignment ]

1-------------------------------------------------------------------
Action definition differs between JSR168 and WSRP.

WSRP defines actions as the event where all state changes happen.

JSR168 defines actions as the event where state changes that affect
other portlet changes happen. When JSR168 EG decided to get rid of
non-blocking action from the API one of the key arguments was that
it could still be possible to model non-blocking actions by using
getMarkup. This non-blocking behavior can and should only be used
if the portlet is not modifying a state that may affect other
portlets, otherwise the overall behavior may not be deterministic.

This means a different programming model for WSRP and JSR portlets.
Specifically, JSR168 allows changing properties in getMarkup. WSRP
does not allow changing properties during the getMarkup.

IINA: Medium/High. JSR168 based producers would have to use producer
managed properties. Providing that WSRP remove this restriction in
the case of producer managed properties. Or, as part of the WSRP
programming guidelines it would have to have extra requirements for
JSR168 portlet developers.

**After Discussion between JSR168 leads and WSRP editors:

Discussion drifted a little from initial issue.

WSRP editors consider it's a requirement for the entity to be aware
of the fact a copy on write happens. WSRP editors consider a binary
copy of properties upon clone is not enough. Making the entity aware
that is being copied/cloned it would allow the entity to clone its
backend state (other state than properties).

Alejandro does not see why backend information (external to the portal)
should be aware of the portlet entity is using it (i.e.: ERP systems,
financial systems). Portlets are just a presentation layer among many,
backend should not be aware of that.

JSR168 does not provide any mechanism to notify the portlet an entity
cloningt happens. JSR168 portlets receive a properties set with each
request, they do not care if the properties set is the default one
or a customized one. The portlet container, in a transparent maner,
makes a copy upon customization and provides the new copy from that
point forward. Early on JSR168 EG has decided entity lifecycle would
be out of scope for v1.0.

WSRP editors propose portlet containers to expose the entityID to
the portlets. This would allow a portlet, on an invocation, to check
if it's entityID has changed (it would store the last know value as
a property). If the entityID has changed the portlet could trigger
the backend copy/clone behavior and update the entityID stored in the
properties. if an JSR168 portlet wants to ensure a private entity
is used by it could trigger a entity clone by changing a property
value.

Solving the copy-on-write issue would therefore require:
1. Introduce Mike's proposal for performInteraction in WSRP
2. Introduce notion of portlet entity identity in JSR

Not resolved initial issues: modification of state (specifically
properties) in the getMarkup call. This requires further discussion
in the WSRP group.


State: Open for more discussion

2--------------------------------------------------------------------
JSR168 allows setting properties not defined in the portlet (entity
type) definition

It is not clear if WSRP allows setting properties not defined in the
entity type metadata.

IINA: Low/Medium. JSR168 based producers would have to use producer
managed properties.

**After Discussion between JSR168 leads and WSRP editors:

WSRP does not forbid this for producer managed properties neither
consumer manage properties. WSRP would clarify it is possible to do
so.

State: If TC/EG agrees, closed

3--------------------------------------------------------------------
JSR168 property types are of String or String[]. Types are
interchangeable (a String value can be replaced with a String[] value)

WSRP allows type <any> for properties

IINA: None. Entities offered by JSR168 based producers would only
use String and String[] values. A JSR168 based producer would not
use other types.

**After Discussion between JSR168 leads and WSRP editors:

This is not an issues as JSR168 is using a subset of WSRP. As the
entity defines the properties types, JSR168 portlets would restrict
their property types to String, String[].

State: If TC/EG agrees, closed

4--------------------------------------------------------------------
JSR168 properties definition can define a property as non-modifiable
(by the end user)

WSRP does not define a non-modifiable attribute for properties.

IINA: Low/Medium. For producer managed properties none, this
functionality is handled completely by the producer. For consumer
manage properties, an extension would have to used.

**After Discussion between JSR168 leads and WSRP editors:

WSRP properties definition (PropertiesDescription data structure)
has an extension mechanism that could be used to express the
non-modifiability of a property.

In addition, WSRP editors suggest producers should not expose to
the consumer properties that are not meant to be modified by the
consumer.

State: If TC/EG agrees, closed

5--------------------------------------------------------------------
JSR168 does not define properties metadata such as value-type,
is-value-required, min-value, max-value, valid-values. JSR168 only
defines name/value/modifiable (String/String|String[]/boolean).

IINA: None. JSR168 producer implementations could define extensions
to expose WSRP properties metadata

**After Discussion between JSR168 leads and WSRP editors:

No issue here.
JSR Portlets can map XML fragments into preference values

State: If TC/EG agrees, closed

6--------------------------------------------------------------------
JSR168 defines the concept of windowID to uniquely identify an
occurrence of a portlet in a portal page. The windowID is used by
the JSR168 producer to manage the session scope for portlets. The
windowID must not change during the duration of a session.

INNA:

If the WSRP 'refHandle' can be used for this purpose this is a
non-issue (The copy-on-write or alternate-solution may have some
consequences on this).

Otherwise: Medium/High. Consumers wanting to interact with JSR168
based producers would have to implement the extension the JSR168
producer defines for that. This would be problematic as different
JSR168 based producers could define this extension in a different
way.

**After Discussion between JSR168 leads and WSRP editors:

Apparently this is not an issue. The first call a user makes the
entityHandle will be passed and the producers has to create the
refHandle for it. When creating a refHandle, a producer could
encode in it a windowID to be used in subsequent calls during the
same session.

State: If TC/EG agrees, closed

7--------------------------------------------------------------------
JSR168 wants to use the same CSS styles but with a more generic
prefix such as 'portlet-' or 'fragment-'

WSRP is defining 'wsia-' as prefix for the CSS sytles.

IINA: Medium/High. Common look and feel would not be achieved unless
the consumer uses both styles.

**After Discussion between JSR168 leads and WSRP editors:

It shouldn't be a problem agreeing in a common prefix, the idea
would be to use 'portlet-' until/unless a better name is found.

State: If TC/EG agrees, closed.

8--------------------------------------------------------------------
JSR168 portal/portlet-container extensions are expressed as String
name-value pairs (where a given name may have several occurrences,
a la HTTP headers)

WSRP allows type <any> for extensions

IINA: Medium/High. JSR168 producers and portlets will have to rely
on vendor provided types to access this extensions. Relying on
vendor provided types will most likely create runtime exceptions
because missing class or cast problems. It would impact JSR168
producers and portlets portability.

Question: Is the intention of WSRP to use <any> for future features
(post v1.0) and to state that extensions must be expressed as string
elements in v1.0?

**After Discussion between JSR168 leads and WSRP editors:

WSRP editors want to keep extensions as <any> elements.

It was discussed that JSR168 provider could handle this elements as
Strings containing the fragment of the <any> element. The <any>
element would have to specify the schema inline, to allow a proper
parsing and interpretation. If the type of the <any> element is of
String type, the JSR168 could process it and offer the parsed value
to the portlet.

State: Open for more discussion.

9--------------------------------------------------------------------
JSR168 needs the list of allowed portlet-modes and window-states on
processInteraction and getMarkup calls to allow the producer to
restrict to allowed values portlet-mode and window-states changes
and portletURL creation.

WSRP does not provide this information

IINA: Medium/High. Consumers wanting to interact with JSR168 based
producers would have to implement the extension the JSR168 producer
defines for that. This would be problematic as different JSR168
based producers could define this extension in a different way.

**After Discussion between JSR168 leads and WSRP editors:

WSRP editors state that validating the portlet-mode and window-state
set by the portlet in a URL at the time this is set has not much value
because at the time the user clicks the link the permissions may have
changed.

JSR168 EG considers portal/portlet container should use current
knowledge when creating PortletURLs to avoid creating URLs with
invalid portlet-modes and window-states. The use case of permissions
changing between the time a URL was created and when it's clicked is
considered rare.

JSR168 requires the container to throw an exception if a portlet
attempts to change to a portlet-mode or window-state during the
processAction call and the portlet/user is not allowed to change.
WSRP does not provide a mechanism to enable this. Furthermore, WSRP
does not require the consumer to process/accept the change.

JSR168 leads to provide an use case where not enforcing the change
and not throwing the exception would cause problems.

[Alejandro's afterthought] JSR168 had, for non-blocking actions, the
current behavior WSRP has now for change of portlet-mode and window-
state when doing a performInteraction. But for blocking actions if a
portlet requested a change and it was valid, the portal must do it.
This different behavior also was eliminated with the removal of non-
blocking actions. At that time also JSR168 EG discussed and agreed
that change request must be honored because if not a portlet could
not be ensured it would change to a new portlet-mode or window-state.
The use case for this being a must was a performInteraction processing
an EDIT, updating some properties and asking the portlet to go back to
VIEW mode.

[outcome of the last JSR conf call about this topic]:
The JSR168 EG thinks it does make sense to give the portlet feedback about
the window states and portlet modes the current user is allowed to access.
For URLs that are created it is accepted to loosen the requirement that
the portlet must be called in the state/mode encoded in the URL. For URLs
the portlet container need to act on the best knowledge available at the
time the portlet creates the URL, but there are no guarantees.
For setting a portlet mode or window state in the blocking action the EG
does not see why the container can not provide immediate feedback if the
mode change is allowed or not. The portlet must rely on the bahavior that
a successfully set portlet mode or window state in the action will be the
mode/state that the portlet will be in for the following render call.



State: Open for more discussion. Issue with setting portlet mode and window
state
in action still not solved.

10-------------------------------------------------------------------
JSR168 defines a simple expiration cache on a per session basis.

WSRP is considering a more complex validating cache mechanism.

IINA: None. JSR168 producers could expose the WSRP caching as an
extension.

NOTE: JSR168 EG is waiting for WSRP resolution on caching to see if a
more complex mechanism could be supported in v1.0.

**After Discussion between JSR168 leads and WSRP editors:

This is not an issue as JSR168 provides a special case of what WSRP
is considering.

State: JSR168 EG will evaluate WSRP proposal. JSR168 community draft
would state this a more complex caching mechanism may appear in the
final spec.

11-------------------------------------------------------------------
JSR168 can not model WSRP entity creation using copy-on-write without
exposing the copy-on-write behavior to the portlet developers.

IINA: High. It would seriously affect interoperability between JSR168
and WSRP.

**After Discussion between JSR168 leads and WSRP editors:

Current WSRP dicussion on this could address this issue.
See also issue no. 1

State: Open until WSRP concludes this dicussion.

12-------------------------------------------------------------------
Window States and Portlet Modes constants differ between JSR168 and
WSRP.

WSRP: VIEW_NORMAL, VIEW_MINIMIZED, VIEW_MAXIMIZED, VIEW_MODE,
      EDIT_MODE, HELP_MODE.

JSR168: NORMAL, MINIMIZED, MAXIMIZED, VIEW, EDIT, HELP

IINA: Low. JSR168 producers would have to map the WSRP window state
names to the JSR168 window state names on each performInteraction/
getMarkup.

**After Discussion between JSR168 leads and WSRP editors:

This is not a big issue, a simple mapping could be done if there
is not aligment.

It was agreed that it would be nice to have common names here. Also
it seems that current WSRP constants names are redundant.

State: Will raise issue in WSRP proposing JSR168 style and drop
the redundant VIEW_ and _MODE.

13-------------------------------------------------------------------
JSR168 does not provide localization support for portlet type
metadata (portlet name, init parameters, properties).

IINA: None. JSR168 producer implementations could define extensions
to expose WSRP properties metadata.

**After Discussion between JSR168 leads and WSRP editors:

JSR168 will define an xml:lang attribute for the deployment
descriptor elements that require localization.

From the discussion it seems a JSR168 producer could use this info
for WSRP purposes.

WSRP should use the approach for WSRP titles and descriptions.

State: If TC/EG agrees, closed

[outcome of the last JSR conf call about this topic]:
JSR168 EG agreed to introduce the xml:lang attribute.

14-------------------------------------------------------------------
JSR168 defines User Information as String name-value pairs with not
structure.

WSRP defines a structured element for User Information.

IINA: Low. JSR168 producer will have to flatten the WSRP User
Information structure into String name-value pairs.

**After Discussion between JSR168 leads and WSRP editors:

WSRP editors suggest JSR168 should make a recommendation to use
P3P-names/WSRP-names styles.

As JSR168 defines a mapping mechanism for this is not really an
interoperability issue. It would just help plug&play.

JSR Leads will propose in the EG to make an appendix with a recommendation
to portlet programmers to use P3P user attribute names for
interoperability.

State: If TC/EG agrees, closed

15-------------------------------------------------------------------
JSR168 allows portlets to access uploaded data from both
performInteraction and getMarkup. If the request was made with an
action URL uploaded data is available in the performInteraction call.
If the request was made with a render URL uploaded data is available
in the getMarkup call.

In WSRP uploaded data is only available in performInteraction.

**After Discussion between JSR168 leads and WSRP editors:

JSR action and render phases do not need to be mapped to WSRP
performAction and getMarkup calls. For the JSR non-blocking actions
that are created with a special API call (PortletResponse.createRenderURL)
the portlet container can tag this URL and return it as WSRP
action URL. When the container receives the WSRP performAction call
the container calls portlet.render() returns the WSRP params as
response to the action and caches the markup produced by the portlet.
When the container receives the getMarkup call from the WSRP consumer
it returns the cached portlet response.

State: If proposed solution works for all cases, closed.


====================================================================

NEW ISUE NOT DISCUSSED BETWEEN WSRP editors and JSR leads:

16-------------------------------------------------------------------
JSR 168 portlets must define valid modes per markupType.

The WSRP EntityDescription structure (WSRP0.8 7.1.1) does not provide
for this information.

IINA: Medium/High  A consumer portal will not be able to correctly
generate EDIT/HELP links on the portlet decorations for different
markups (e.g. a portlet may support EDIT for HTML, but not for WML).


State: not yet discussed
---------------------------------------------------------------------