- 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
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 properties. > 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. Ok. > 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; http://www.artima.com/intv/distrib4.html > 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. Right. > 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-). MB -- 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