Mike Glendinning wrote: > > > --- In [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com>, Todd Biske > <[EMAIL PROTECTED]> wrote: > > > > One point that Anne made which still doesn't get a lot of press is > > the difference between Resource Oriented Architecture and Service > > Oriented Architecture. In a companion article, it was called out > > that REST is about the nouns, where SOA is about the verbs. This is > > part that I think needs some honest debate. Is a resource oriented > > view of the world going to be better than a service oriented view? > > Many people keep associating REST with SOA, but I think that's an > > inaccurate portrayal. The people I've spoken with have been doing > > POX over HTTP, which is not REST, and I'd argue that there are some > > very big differences. > > > > -tb > > Todd, > > Wasn't the noun-oriented view of the world thoroughly and effectively > ridiculed by Steve Yegge last year (see [1])? Whilst his target is > clearly Java in this case, the same comments could be applied to REST.
I thought what ridiculed was the idea of a language that did not have have first class functions, only object methods. That wouldn't be HTTP, or REST generally. It would be like WS as I've seen it in RPC-encoded form. > Kent puts it all rather well on page 19: > > "...we are not modelling reality, but the way information about > reality is processed, by people." > > This is a hard problem and one that is not going to get simpler. > > If you're a developer, I hope you can see that it is never that > obvious what your "resources" should be (for REST) or what operations > you need to perform on them. Whether you need to concentrate on the > nouns or the verbs will not always be clear. And what is "right" for > one application may be entirely wrong for another. I agree with this (and with the Bill Kent recommendation). But it's no problem to argue that it's never obvious what the operations should be and thus SOA isn't obviously saving any effort; especially at the granularity of a service - being business level concerns one can fully expect services to be inconsistently exposed. The salient point around REST here is that all objects can be at least be accessed uniformly (ie REST is analogous to what Yegge recommends). That acts an engineering forcing function to allow at least one layer to be nailed down, and variation/coordination happens elsewhere. It's not clear to me that SOA (or WS) is ever going to provide that level of structure. SOA seems to encourage business to meddle in IT at the wrong levels and might actually prevent commoditization by making all this stuff specific to a business at-a-point-in-time; like encouraging Service Oriented Electricity instead of electrical Grids and uniform access to outlets. > In the past few years, I sense that conceptual modelling has become > rather unfashionable. I find that developers tend to just throw > together a few Java classes (without much thought) and then assume > some magical O/R tool will create an appropriate database for them. That's probably because people don't 1) want to wait a long time for the conceptualizing to end, 2) get stuck with the wrong concepts. If you are throwing 'any old stuff' together, it can at least force the issue of being adaptable to change, so you can move onto some new 'any old stuff'. cheers Bill
