Re: [wsrp-interfaces] State management/parameters

[Alejandro Abdelnur <alejandro.abdelnur@sun.com>]

This topic also is heading to the top of the charts, so here are
some quick comments before I disappear for 2 weeks.

I like the proposed categorization of navigational, action, request, 
session states:

* Request/session states are maintained by the server. The client
   only has a reference to the session state (i.e. a Cookie).

   In the Java Servlet world they are represented by the HttpSession
   and the HttpServletRequest attributes.

* Navigational/action states are not maintained by the server but by
   the client, i.e. as a link or form in the page or as a bookmark.

   In the Java Servlet world they are both accessible through the
   HttpServletRequest parameters.

   And, if using the HTTP intended semantics for GET and POST, GET is
   a navigational state and POST is an action state.
   (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)

   Going back to JavaServlets, the HttpServletRequest getMethod
   method indicates if the request is a POST or a GET.

   Doing some overloaded use of the POST, the URL may contain a
   QueryString. So it is possible to have a request that contains
   both types of state, navigational and action and still differ-
   entiate between the two. Navigational state will be the Query-
   String and action state will be the POSTED data.
   From the servlet API this is difficult to differentiate (but
   possible, it requires some extra work) because the way the spec
   defines the merging of the QueryString and POSTED data as
   parameters of the request.

The complexity, in WSRP, arises because we have a portal page with many 
portlets where one of the portlets may be receiving action state and the 
rest are receiving navigational state.

Also, we have a 3 tier model (client, consumer, producer), not a 2 tier 
model (browser web-server).

The thing is, how to model the navigational state and action state now 
that we have to deal with several components at once (the portlets in 
the portal page) and a 3 tier model.

It was discussed by email and conf calls of that the navigational state 
may rapidly grow because of many portlets in the portal page having 
navigational state. The problems this may have (long URLs, devices that 
can not handle much info) as well as the benefits that may bring 
(stateless producers and consumers).

I see as a valid way of tackling the propagation of the navigational 
state and action state all the way to the client. However, it is not the 
only way of doing it. This is an implementation detail.

But I do not want to restrict the protocol to set navigational state 
only as part of performAction because of one possible implementation. 
Other implementations may not have such limitations and allow a more 
flexible way of doing things.

I rather see vendors defining guidelines on how to implement portlets to 
take full advantage of their portal implementation. For example, if the 
portlet is coded in a way such that the navigational state is only set 
the perform action doing a redirect the portal will be able to handle 
the portlet in a stateless way. Otherwise, if the portlet sets 
navigational state as result of a call to the getMarkup, the portal will 
have to be statefull thus not scaling that much.

Another thing that worries me, coming from JSR168, is how to effectively 
use servlets and JSPs from the getMarkup call with the navigational 
state and action state, not going to both calls (performAction and 
getMarkup) and the navigational state being only set by the 
performAction. This is something I have not figure it out yet.

When I come back, I'll see what has been discussed and I'll probably 
restart the discussion with some other ideas and concerns.

Regards.

Alejandro.



Michael Freedman wrote:
> Folks,
>    At the F2F I took on the task to clarify the proposed support for
> "stateless" entities.  In the meantime a discussion has ensued regarding
> whether sessionId can be collapsed into the markupParams.  This message
> provides an overall analysis of the general question of state management
> and its relationship to the protocol.  Based on this a particular
> usage/semantic pattern is proposed.  Its intent is to clarify both of
> the above issues.  Please let me know what you think.
> 
> Through various discussions/analysis 4 types of state can be defined.
> The first three are well understood web application states/styles.  The
> last is a new one that comes into existence because of the way our
> protocol works:
> 1) Navigational (URL) state -- this is state represented as parameters
> in the query strings of links that establish the "navigational context"
> of a page.  I.e. this is the state that allows a link to encode the
> state of a page so it may be bookmarked, refreshed, navigated to via
> next/back.  An example of this is the amazon.com link that references
> the page that describes a specific book. The parameters for this
> reference are part of the link making it bookmarkable/navigatable etc.
> 2) Session state -- this is user application state that doesn't vary as
> you navigate.  An example is your shopping cart in amazon.com.  The
> items in your shopping cart don't change as you use the next/prev
> buttons or redisplay.  Unlike navigational (URL) state, session state is
> not represented/maintained by the client, rather it is maintained by the
> server.  The client merely has a reference to this state.  This
> reference is typically in a cookie but can also be a URL parameter
> itself.
> 3) Action (transient) state -- this is state passed on requests that is
> meant to be processed (submitted) and then tossed -- though the
> processing usual results in changes to either session or navigational
> state.  The example for this is form submission.
> 4) Request (transient) state -- this is intermediate state meant to be
> created during action processing and used in the next render call of the
> portlet.  I.e. in our protocol a single user action results in two calls
> to the portlet performAction and getMarkup.  These two calls occur
> across 2 (connectionless) SOAP calls.  How does a portlet create
> transient state in an action that is can access in the following render
> while not needing to clean it up because it is recollected after the
> "request" completes?  I.e. in the servlet model during a single request
> logic can attach transient request state for later logic via request
> Attributes.  How does this work between an action/render pair in our
> protocol?  Answer: invent/support request state.
> 
> How should our protocol present the above styles/usages?
> 1) Navigational (URL) state is represented by query string parameters
> added to links generated by the portlet in its response to getMarkup (or
> redirects from performAction).  Such parameters are presented by the
> Portal on subsequent use to both a portlet's performAction [if an action
> url] and getMarkup calls as request parameters (in the RequestContext).
> They are always resubmitted on redisplay.
> 2) Action state is represented distinctly from navigational state by URL
> parameters added to action links generated by the portlet in its
> response to getMarkup.  I.e. action parameters and navigational
> parameters coexist in a link and can be distinguished by the portal.
> Action parameters are only presented by the Portal on subsequent use to
> a portlet's performAction.  They are not presented to getMarkup.  They
> are passed to performAction as interactionParams.
> 3) Session state is maintained by the portlet as needed and reacquired
> on request by reference (i.e. a sessionID is passed to all portlet APIs
> including performAction and getMarkup so it reattach to its in memory
> state) [See below for note on why I suggest we don't support having the
> Portal maintain this state on behalf of the portlet and resupply on each
> request].
> 4) Request state is an opaque value returned by a performAction call to
> the Portal and based to [only] the next getMarkup of that entity.  This
> state is represented by the markupParams returned by performAction and
> passed to the next getMarkup.  getMarkup wouldn't return markupParams --
> its navigational parameters/state would be encoded in its response
> links.
> 
> Note:  In the F2F we discussed supporting "stateless" portlets.  At the
> time we attempted to model not only "stateless" portlets as those that
> limit themselves to be represented merely by navigational state (URL
> parameters) but also session state.  I.e. one form of markupParams was
> to allow a portlet to package its session state and return it to the
> Portal for later submission rather then keep this information in memory
> and merely return a reference (sessionID).  I recommend we do not add
> this functionality to version 1 of the specification [though we could
> discuss dropping altogether from further consideration].  There are
> three reasons for this recommendation:
>      a) this "function" is not currently readily modelled in the web
> world.  Returning session state to the client prevents effective
> bookmarking/navigation.
>      b) adding this function complicates the API -- as sessionID covers
> the session state case why worry now about supporting a new/extra model?
> 
>      c) having the portal maintain the session state vs a session
> reference has negative performance/scalability implications.  When a
> portal is running in a load balanced environment state managed on behalf
> of the portlet/entity must be maintained in a manner so all nodes see a
> common/consistent view of this state.  In such a world writes (the time
> when state returned by the portlet has changed and needs to be rewritten
> to the shared state manager) are generally expensive.  Session
> references rarely change (are good).  Session state changes frequently
> (often on every request) and is therefore bad.
> 
>         -Mike-
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>