|
William Cox |
BEA |
|
Graeme Riddell |
Bowstreet |
|
Srinivas Vadhri |
Commerce One |
|
Monica Martin |
Drake Certivo |
Y |
Alan Kropp |
Epicentric (chair) |
Y |
Charles Wiecha |
IBM |
Y |
Rich Thompson |
IBM |
Y |
Carsten Leue |
IBM |
|
Thomas Schaeck |
IBM |
Y |
Rex Brooks |
Individual |
Y |
Joe Rudnicki |
U.S. Navy |
Y |
Mike Freedman |
Oracle |
|
Stefan Beck |
SAP |
|
Jeffrey C. Broberg |
Silverstream |
|
Suresh Damodaran |
Sterling Commerce |
|
Eilon Reshef |
WebCollage |
|
Gil Tayar |
WebCollage |
Y |
Steve Pruett |
Silverstream |
Y |
Mike Hillerman |
Peoplesoft |
|
Aditi Karandikar |
France Telecom |
Y |
Ravi Konuru |
IBM |
|
Howard Melman |
Silverstream |
|
Angel Diaz |
IBM |
Y |
Alejandro Abdelnur |
Sun |
Y |
Eric van Lyndegraf |
Kinzan |
Y |
Yossi Tamari |
SAP |
1. Based on our discussion from Thursdays WSRP Interfaces call, Mike sent out a couple of emails regarding levels of state, and most recently, session modeling. I think it would be useful to spend time going over the major points to nail down session/state basics:
a.) What are markup parameters? Are they transient request state? Expanded to encompass session state for special circumstances (below)?
b.) Should we model "stateless" producers as somehow putting the burden of managing session state on the Consumer, via the expanded notion of markup parameters? What should "stateless" imply regarding Producer's expectations on Consumer?
c.) Is there a need for a separate initSession call, to avoid session creation race conditions? What about session timeout, and handling non-J2EE containers which may not be able to re-establish an expired session?
2. Hopefully smaller-scale discussions on...
a.) Should userAgent, locale & deviceInfo be part of the user profile data or some other structure (now is in RequestContext)?
b.) Page 32 / line 3 of
0.22 draft ... Is SHOULD or MAY the right statement?
c.) Should modes and states
be an int[] or a bitvector ... both have appeared in different versions of the
spec ... which is preferred?
The hour was spent discussing the proposals for dealing with various types of state. I’ll attempt to summarize the gist of it here.
There has been an assumption in the specification that markup parameters are a serialization of the state of a service, so that the Producer doesn’t have to support sessions (or really, any state persistence at all).
The Producer may (again, as presently specified) rely on the Consumer to manage its session state externally, in the form of the markup parameters returned by both getMarkup and performInteraction. The Consumer must be sure to pass the markup parameters back to the Producer in any invocation, to allow the entity to “re-connect” to the state it left off with in the prior invocation.
This is objectionable (in the eyes of some), because it places too heavy a burden on the Consumer, and creates scalability problems since we can reasonably expect session state to change frequently. Also, it represents scope creep, since the markup parameters concept wasn’t explicitly intended, with regards to the relevant F2F discussion, to be a mechanism for the Consumer to manage externalized Producer state.
An alternate view and proposal is based largely on an e-mail Mike F. wrote near the end of last week. In it, the concept of state gets broken out into various levels (see Mike’s email for details). The important point is that state needs to be managed at its source:
This is state that is transparent to the Consumer. It is an implementation detail how the Consumer chooses to handle these, though it’s expected (especially for bookmarking) that these will be encoded in the URL.
1. Navigational state, what is proposed as a replacement for the markup parameters concept, is the state that enables the entity to re-render a page. This is for client refresh and bookmark-ability.
Discussion: When a Producer specifies a service is “stateless”, the only expectation on the Consumer with regards to state is that it will maintain and return navigational state, and where applicable, action state.
2. Action state, what used to be referred to as transient state in early discussions, represents state specific to the request, such as a form submit. This state survives only for the duration of the request.
Discussion: How should action and navigational parameters be distinguished? Namespacing?
Discussion: If a Producer service requires session state, it will create and manage the session itself, and pass to the Consumer a unique handle. It will not externalize this state and expect the Consumer to manage on its behalf.
Discussion: The interplay of performInteraction and getMarkup is getting clearer. performInteraction may return, in the form of an opaque string value, these specialized request parameters. It does not return markup. The Consumer then invokes getMarkup passing this value as a parameter, and it generates markup accordingly. It returns only markup.
Discussion: I don’t think we have settled on exposing sessionID as a top-level parameter, or burying it in a structure. Today’s discussion would seem to favor it as a top-level param. Anyone?
Action item: Mike (and others) to post scenarios/diagrams to elicit further details and comment on these proposals.