Re: Rough text for State finding

David - the first part of this is quite good, though I think there's
some terminology issues to work out ... as you might expect, since IME,
there's surprisingly little concensus on it.

I'll refrain from comment on the "ilities" sections for now.  More
inline ...

On Sat, Oct 15, 2005 at 11:54:46AM -0700, David Orchard wrote:
> Abstract example
> 
> Dirk decides to build an online banking application.  Customers will be
> able to view their account balances and make transfers.   The first step
> is logging on to the application.  When the customer selects accounts
> view, the banking application will ask them for their username and
> password.  If they have already entered their username and password,
> they will not be asked for it again.  The system will automatically log
> the customer out if they haven't done any activity for 10 minutes.  
> 
>  
> 
> We see a prototypical stateful application from the client perspective.
> The application has 2 states: logged-in and not-logged-in.    This state
> may be realized by storing state on the client or on the server.

I suspect you're just referring to what some (myself included) call
"session state".  I've heard this state called "application state"
before, but avoid the term because I find it too easy to confuse with
the state of the application state machine, e.g.  "selected 'from'
account", "selected 'to' account", "entering amount", etc...

> Given a decision of storing the state rather than data used to create
> the state, another decision is whether the state is stored on the client
> or the server.  Applications where the client stores the state are
> typically called stateless applications, even though there is state on
> the client.  

See below about "stateless application"...

> Example using HTTP Authentication
> 
> Dirk decides that the banking application will be stateless on the
> server and the client will resend the data for each request.

Terminology again... I think "application will be stateless" doesn't
communicate - at least to me - what you mean to communicate when you
say "client will resend the data for each request".  What some might
think you mean is that the application itself maintains no information,
which would, amoungst other things, make a bank transfer impossible 8-).
Instead, your use of "resend" tells me that you might have meant
something like "Dirk decides that the server will maintain no session
state, and that the client resends the session state with each
request".

I *think* this would also address Noah's concern about the different
types of state.

> The primary reasons for customized security are security concerns, that
> is wanting greater control over the security timing out,

I don't think so.  The server has full control of who gets access to
what, when, independent of where session state is maintained.

Moreover, cookie based authentication (and indeed, all stateful auth)
actually *weakens* the security of the site ... which is something you
should probably cover somewhere here, as another cost of stateful
interaction.

I think that by far the main reason why folks opt for cookie auth is
the user interface reason you gave (combined with good tooling support
for it);

>and ease of use
> concerns, particularly wanting direct control over the look and feel of
> the screens including helpful tips and links to forgotten passwords.  

[...]

> The URI per account design, sometimes called "deep-linking", has all the
> network effect advantages that the web has to offer: the users account
> is bookmarkable, exchangeable, etc.  
> 
>  
> 
> It does suffer from potential increased complexity as it may be easier
> to populate and parse the FORM POST data for the account id rather than
> the URI.

Sorry, I don't understand that.

> Web service example
> 
> Dirk is tasked with making the banking application available as a Web
> service rather than HTML pages.  He uses XML, SOAP, WSDL, and
> WS-Addressing to do this.  The banking application is a service with an
> interface containing two operations:log-in and getBalance.

Just curious, but why did you choose a login operation rather than
use some WS-* spec (there's got to be one somewhere! 8-) that defines
SOAP headers for authentication?  Was it to motivate the desire to use
reference parameters?  If so, I think it would only be fair to add a
Web services example where the client maintains the session state, lest
anybody think that Web services always maintain session state on the
server.

> Ease of Application construction
> 
>  
> 
> There are two primary types of designers that are relevant: the network
> administrator that controls the deployment of applications and
> publication of URIs, and the application developer that controls the
> contents of messages including http headers.  The application developer
> can develop the application without affecting the URI with the state id
> information and so avoid a potential conflict with the administrator.

>From what I've seen, an administrator would typically just delegate a
portion of their URI space below some base URI.  For example, they might
assign my project "http://example.com/foo/bar/baz/".  But what happens
under that, they don't care about.  Am I missing something?

...

In general, I mostly like what's here, but what concerns me is that it
reads like a defense for doing things counter to good practice on the
Web.  I think everybody understands that, in the small (i.e. Joe
Architect working on his EAI app at BigCo) the tradeoffs you describe
are often necessary.  But in the large - the large of the Web and of the
Internet - I think it's a different story altogether to argue for the
right for public specifications to disregard the good practice that the
W3C tries hard to promote, as that could easily lead to the good
practice being widely disregarded.  As Noah asked re EPRs, "Is this
something we're recommending?".  Note that the Web services bank
example you provided does have a reasonable solution that was both
both stateless and identified resources; should that not be promoted
as best practice?

Noah also made a suggestion to add some wording about the advantages of
promoting network effects, etc.. which I fully support.  But I'd also
like to see more detail be provided so that the enormous value of
statelessness and (most importantly) resource identification at scale,
can be explained.  Perhaps just some links to the relevant parts of AWWW
would suffice?  Dunno.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Monday, 17 October 2005 18:19:56 UTC