Interfaces topics for F2F

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

Decided to send this directly vs. adding a document in the OASIS system 
as it seems more reliable these days.  Anyway it will eventually get 
there.  This document outlines a process for adding new interface 
issues/features for future versions and lists a set of known 
issues/features [that we have discussed in the past] for possible 
inclusion.  At the F2F I want to define/adopt a process. If its based on 
what I propose I want to also identify as many issues/feature owners as 
possible.  I have sent this document out today so you can begin to look 
through it to both think about what process you would like to see and to 
give you all an opportunity to think about committing to owning a 
feature.  Also use it to identify features/issues I have fogotten/missed 
[and forward these to me] so I can have a moer complete list for the F2F.
     -Mike-

Title: WSRP 1

Overview

The following describe the currently known potential design areas for WSRP 1.1 and 2.0 [that have at one point or another been tagged as being related to “Interfaces”].   For the upcoming F2F I would like to discuss and agree on a process for dealing with these and other Interface design issues/features.  Following this overview I propose such a process.  If a close proximity of this process is adopted/supported I would also like to assign where possible issue/feature owners and then for such issues/features take a non-binding strawman vote on whether this issue/feature is likely to be approved [and in what form]:

 

Proposed Process

Steps to qualify/formalize an issue/feature for a WSRP release:

• Identify an issue/feature owner.

The issue owner is responsible for writing up the design for the solution.  This write-up once approved will ultimately be rewritten/incorporated into the specification by the specification lead.  If and only if there is volunteer to be an issue/feature owner can an issue/feature be approved for consideration in a given release.

• Approve an issue/feature for consideration.

Once an owner is identified the issue/feature must still be approved by the TC for consideration in a given release. This approval requires:

o       The owner to submit a document that describes:

o       The name/title of the issue/feature being considered

o       The release this issue/feature is being considered for.

o       A summary of the problem that raises this issues/requires this feature.

o       A use case this issue/feature is supposed to address

o       A description of scope.  Though likely to describe the scope of this issue/feature its as [probably more] important to describe what this issue/feature will not address.

o       A schedule including timetable for:

§         A strawman proposal [if part of plans] – a strawman proposal is the issue/feature owners preliminary design without general TC consultations.  This is often used as a way to jump start/frame discussions for an issue or feature.

§         An initial draft proposal – [if part of the plans] this is an initial draft based on a working consensus of the interested parties in the TC. Note: it is strongly encouraged that an owner build a consensus for a solution before submitting the issue/feature to the TC for approval.

§         Anticipated submission date

• A majority vote by the TC approving this submission for consideration.
• Once an issue/feature has been approved it can either be:
• Withdrawn: the owner indicates his/her desire to withdraw the issue by communicating with the Interfaces subcommittee chair.  Prior to withdrawing the issue/feature the chair will solicit the TC for a new owner. If a new owner is found the issue/feature can be transferred once a new schedule is published.   
• Voted on: A formal TC vote [majority rules] to accept/deny the feature.
• Once a feature/issue has been approved it can safely be incorporated into the targeted WSRP specification version.  [For timing reasons the spec lead may choose to iteratively update the WSRP specification with working “drafts” for an issue/feature].

 

The process used by an owner to build consensus for a solution is left to the discretion of the owner.  The owner has the following facilities to support this effort:

o       Utilize the [needs to be created] wsrp-interfaces mail list to post/receive feedback. In addition Utilize the wsrp-interfaces weekly conference call [Thursdays 8am, PST?]  to get interactive discussion/feedback.

o       When the issue is large enough/broad enough, setup a separate mail-list and/or conference call time.

WSRP 1.1 Issues/Features

·         Semantics of no UserProfile vs no UserProfile data [onwer:TBD]

The question seems to be whether a portlet wants to distinguish between the case when no UserProfile exists vs. the consumer chooses not to send UserProfile information.  The related question concerns what a consumer can send when the UserProfile/Identity represents a Group of individuals vs. a single individual.  Which brings up the interesting question of whether a portlet needs to know/care whether the identity/category/profile information refers to an individual or a group.

 

 

WSRP 2.0 Issues/Features

·         Security/Authorization [owner TBD: reconsitute wsrp-security??]

o        Security

Problem:  need to describe a more general purpose message level security protocol.  The proposal is we rely on WS-Security.  Is it as simple as stating that [i.e. its handled by lower protocol layers] or does WSRP need to do anything?

§         Are there levels of security not covered by our current standard [https] or the projected one [WS-Security] that we need to define/support?

o        Authorization – User Identity/Roles

Problem: need to describe mechanisms for portlets to conveniently acquire user identity/authorization information in an interoperable manner.

§         Currently how a producer/portlet authenticates and authorizes a request is largely left as an exercise to the portlet.  This presents real interoperability issues for portlets.

§         What use cases do we need to satisfy?

·         Trusted consumer passes information over our protocol.

o        Issue is value vs. using standard.

·         Trusted consumer passes information using standard WS protocol [SAML?]

o        Issue is which standards and when will there be general interoperable support.

·         Producer/portlet can bind to/communicate with the consumers authentication/authorization service.

 

Do we need to reconsitute the Security subcommittee??

 

·         Publish/Find/Bind [owner: wsrp-pfb [Alan?]]

Problem: How can consumers utilize [standard] registries to locate/use producers? A necessary question that needs to be answered to solve this is how can producers publish themselves [in a standard way] to [standard] registries so they can be located/used?

o        UDDI

o        ebXML

o        Anything else?

 

·         Caching [owner: TBD]

o        Invalidating cached markup

Problem: WSRP 1.0 doesn’t support invalidation based caching meaning

·         In-band invalidation: Actions that change “models” aren’t guaranteed to expunge stale cached content.  For example, if a user updates her customization values, WSRP doesn’t define how the portlet can invalidate content dependent on these value.  This leads to the possibility that after a user submits new customization values the portal page won’t be updated to reflect the new values because the existing content based on the old values continues to come from the cache.

§         Out-of-band invalidation:  Some portlets change their “models” based on external events.  I.e. an event not caused through the normal sequence of processing an user interaction.  If these portlets are cached they may not be called until the content expires.  They need an out-of-band invalidation mechansim to communicate this change.

Requirement: Invalidation caching is not required of consumers that support validation/expiry caching.  I.e. it’s a layered model.  Additional layering is likely required to allow consumers to support in-band but not out-of-band invalidation.

·         Mode Control [Owner: TBD]

o        By the Portlet

Problem: WSRP 1.0 provides no support for a consumer to influence the “Look” of Portlet Modes.  In particular Modes like “Edit” and “Help” are dialogs in which the user interacts with a control/informational aspect of the portlet before returning to viwe the regular content.  As there is significant value to the end user when such UI consistency can be provided, consumers have a strong interest in influencing the placement and labels/images used in these dialogs when rendered by the portlet.

 

Problem: WSRP 1.0 provides no [stateless] support for a portlet to maintain navigational integrity.  Portlets may want to support a navigational hierarchy through its Modes [for example View->Edit->Help and back out again].  WSRP 1.0 doesn’t provide a mechanism for stateless portlets to accomplish this given that Consumers can provide operations that get users into Modes while Portlets often provide operations that get users out of Modes.

o        By the Consumer

Problem: Our current property description isn’t sufficient to allow Consumers to provide quality user interfaces for Edit mode.

 

·         Publishing/Transportability [owner: TBD]

Problem: Consumer often exist in an environment that supports the ability to be independently developed, staged, and externalized.  The Consumer needs a way to transition its WSRP producers/portlets across these environments.  Currently WSRP registrations are tied to a single Consumer [version/instance].  This is too limited to support the above Consumer environment.  In addition, in such environments consumers want to selectively publish protions of the portlet [e.g. only some entities but not others … shared [default] customizations but not per user customizations].  From another perspective the user/authentication/authorization systems likely vary across this environment.  How does the Producer/Portlet adjust?

 

Problem: Consumers sometimes want to prepackage/ship WSRP portlets along with pre-built portal pages [applications] for installation in a customers network/environment.  How can we support installable environments in which a selected set of customized entities are shipped?

 

·         Multiple Consumer Portlet Windows [owner: TBD]

Problem: In WSRP 1.0 there is strong assumption of a 1:1 correspondence between a portlet entity session and a portlet window.  I.e.  a portlet entity session runs within a single consumer portlet window.  As a number of modes are dialog-ish [“help”, “edit”] some consumers would prefer the ability to render one or more of these dialogs in seprate [pop-up] windows.  What needs to be defined to support this?

Problem: If we support the above do we need to give the portlet an ability to influence the placement/use of these separate windows?

 

·         Portlet interoperability [owner: wsrp-coord [Rich]]

Problem: WSRP 1.0 doesn’t provide any mechanism for two portlets managed by a consumer to coordinate their function.  However this is an important function many consumers currently provide.

o        Interchange [mediated] state

o        Interchange [mediated] events

 

·         Document rendering [owner: TBD: wsrp-markup???]

Problem: There are a variety of use cases where a portlet needs to render [invisible] “content” in other page locations from where the portlet appears on the page.  WSRP 1.0 doesn’t allow for this. 

 

·         Add ability for Portlets to return resources directly [owner: TBD]

Problem: The WSRP 1.0 specification deals with web resources [images, etc] as separate entities referred to but not supplied by the portlet.  I.e. it relies directly on HTTP to deal with resources. Shouldn’t the WSRP protocol be capable of supplying all the content that represents a portlet?

 

·         Leasing of [Registration?] Handles [owner: TBD]

[Problem – I Think??] WSRP producers have no way to indicate a duration for consumer registrations.  It merely has the ability to revoke a registration whenever it seems fit.  Is there a need for producers to support registration handle leasing?

 

·         Support Consumer defined portlet hierarchies [owner: TBD]

Problem: WSRP doesn’t define hierarchical relationships between portlet entities.  Some consumers find value in this.  What needs to be added to WSRP so a Consumer can do this?

 

·         Extend Redirect support [owner: TBD]

Problem: In WSRP 1.0 redirecting from a performBlockingInteraction is mutually-exclusive from returning a new cloned entity, setting up a session, etc.  Is this too limiting?

 

·         Add back performInteraction() [owner: TBD]

Problem: We removed this optimization to simplify the specification.  However, we have other [complex] optimizations in the specification which will likely be extended to new uses.  Shouldn’t we optimize the scenario in which a portlet is session based and knows that user actions targeted to it have no side-effects beyond that particular entity [i.e. no internal shared models nor external shared models/events]?  This seems to be a form of a canonical portlet yet its not optimized.

 

·         Add PropertyDescription.propertyUsage field [owner: TBD]

 

·         Add UpdateResponse.isSecure field [owner: TBD]

 

·         Add BlockingInteractionResponse.rewriteRedirectURL field [owner: TBD]

 

·         Add RegistrationData.version field [owner: TBD]

 

·         Add releaseCookie() [owner: TBD]