[wsia] RE: [wsrp-interfaces] [wsrp][interfaces] Statemanagement/paramet ers and Object Model

[Rex Brooks <rexb@starbourne.com>]

Gil, I think Mike just said that we should not add session state 
information in addition to navigaional state information to stateless 
portlets. I agree. However...

I have two concerns with this process of discussion.

A. I thought we were going to follow Alan's lead to discuss data 
objects or a data object model. Alan started this and no one followed 
up. My own response to his model is that the classes for objects he 
has modeled have yet again new names, except entity itself, and 
though I understand that they are abstract concepts, they seem to 
imply new terms, which is one of our most difficult problems because 
every time someone tries to explore a new wrinkle or finds yet 
another exception (either a needed feature that isn't specifically 
covered by prior terminology or a feature that is perceived as not 
working in a way that some case might require by a process covered by 
prior terminology) to the current spec, they feel compelled to invent 
a new term or redefine an old one. If we could just have our data 
object model adhere to the terms we have it would be more clear as 
modelled, because the model diagram itself is quite adequate.

B. While Michael's summary, which brings to completion the task he 
took on during the F2F,  is excellent for RP especially as focused on 
compliance to the servlet model for portlets to which we are married, 
or which we must address in some fashion, it seems, it struck out in 
yet another new direction. I am sure he meant only to convey the 
concerns of his working group in a way that captures all the cases 
they are turning up while addressing some ensuing discussions. Since 
I happen to agree with what he expressed, it is difficult to 
criticize it except that it serves to illustrate the main problem 
with this process. We seem unable to remain focused.

I proposed a set of criteria, which was amended suitably and which 
has been largely ignored as we delve ever deeper into the intricacies 
of how the core protocol SEEMS to be structured and how it MIGHT NOT 
work perfectly and scalably and reliably and securely for every 
instance we can imagine, and how it might require some of us to 
rewrite work done prior to the spec, especially if it seems like 
there might be quite a bit of it, and of which the aggregate amount 
is increasing inexorably as we work. I apologize if I make it seem 
like I am miffed at having my own pet notion dismissed, because that 
is not the point. Nor am I suggesting that we have not carried 
forward some legitimate concerns that we have made decent progress 
toward resolving. The point is that we seem to have reached a point 
where, metaphorically, we are stuck in the mud spinning our wheels.

Are we capable of carrying a proposed discussion through to 
completion without recasting it or setting it aside as we go 
following down paths suggested by whatever new thoughts occur to us 
or those with whom we are working? I am going to suggest that we at 
least attempt to do so.

I think we need to pare the spec down to simplest bare necessities to 
cover the existing work to date and allow for both WSIA and WSRP to 
then  proceed with the more complex issues of eventing and 
customization.

Ciao,
Rex

At 9:40 AM +0300 7/21/02, Gil Tayar wrote:
>Mike,
>
>Great summary _and_ proposal. I think you hit the nail on the spot.
>
>On your "note". I'm not sure I understood it. Actually, I didn't understand
>it at all :-). Could you respecify the problem?
>
>Gil
>
>-----Original Message-----
>From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
>Sent: Fri, July 19, 2002 18:42
>To: interfaces; wsrp-wsia
>Subject: [wsrp-interfaces] [wsrp][interfaces] State
>management/parameters
>
>
>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>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com