W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

Re: WSDL, app protocols, URI schemes

From: Mark Baker <distobj@acm.org>
Date: Sat, 28 Sep 2002 20:34:16 -0400
To: David Orchard <dorchard@bea.com>
Cc: www-ws-arch@w3.org
Message-ID: <20020928203416.Y24048@www.markbaker.ca>

On Sat, Sep 28, 2002 at 01:21:59PM -0700, David Orchard wrote:
> There are 3 things jumbled together here: 1) what is the optimal solution;
> 2) dispute of an assertion; 3) extrapolating and focusing on the higher
> order issues.
> The question isn't whether there's a solution or not.  It's about what is
> the optimal solution.  I could still program in Assembler, but that's not
> optimal for most of my application development, even though some people
> still use it.

"optimal" isn't the word I would have used, but I agree with the
sentiment.  The objective is to design a system that has the required
properties.  To do this, you choose constraints that give you those

> The original point of this debate was that you made the assertion that wsdl
> files are like URI schemes.  Aside from the technical disagreement I have,
> there's a potential political problem as well.  The TAG document currently
> says that new URI schemes SHOULD be avoided.

Exactly.  New interfaces are very expensive to deploy.

>  I wanted to make sure that a
> dispute of WSDL files are like URI schemes is on the record, particularly
> for a TAG review.


> The question should be about what requirements or principles are being met
> by the web and by web services, and where they may be different or the same.
> Accepting the different requirements/principles, one can then create
> different constraints.

s/requirements/properties, sure.

> A good example of this is the constraint of statelessness.  Stateless makes
> a lot of sense given the requirements of browser/human interactions.  And
> that includes humans mailing other humans URIs.  But those requirements
> don't all match up with web services.  So a stateful application design does
> make sense, given certain requirements.

Anything makes sense given "certain requirements", so I don't consider
that a useful criterion.  The issue is, does a stateless constraint
help induce the properties we desire in our system?

Statelessness is extremely important in any large scale distributed
system where visibility, reliability, and scalability are desired
properties.  As an example of how important it is, digital signatures
make no sense unless the interaction is stateless, otherwise you're wide
open to replay attacks.  For example, if I had a stateful message that
communicated "You have my approval to go ahead with it" and signed it,
then an attacker could replay that in some other context.  On the other
hand, if the message said "Bob Jones (identified by http://example.org/
employee/bobjones23), you have my approval to go ahead with the deal
identified by the URI, http://example.org/deal/23423434", then that's
safe to sign because its meaning is self contained (aka stateless).

And that's just the tip of the iceberg on the value of statelessness.
Next to the uniform interface, I consider it the most important
constraint of REST.  And notice how none of that had anything to do
with browsers.

FWIW, Ken Arnold talked about the value of statelessness here;


> Roy has regularly said that you apply constraints to get behaviour out of a
> system.  If you don't use the constraints, you don't get the behaviour.  The
> question is always about what are desirable behaviours.


> This is also why Roy has said the TAG document should talk about principles
> (requirements) and then the constraints to get those.  And I think our works
> should do the same.  I had wanted to start from bottom's up (soap and wsdl)
> to get some pen to paper.  Once we finish that, we might want to start with
> examinition of the requirements.

Sure, I'm all for that.  That's why I brought up the constraints when
I did.  We're done our requirements, at least for now.

So, onward with constraints, right?

(note to self, it's not "we" any longer 8-).

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Saturday, 28 September 2002 20:33:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:59 UTC