From DareO
"The key point is that you should be passing around messages with state not executable code. The fundamental genius of the SOAP 1.1 specification is that it (emphasis mine) brought this idea into the mainstream and built this concept into its very core"

Good thing SOAP1.1 came along!

"Service oriented architectures dictate that you pass around state while the methods exist at the service end point, (e.g. an HTTP GET or HTTP POST request sends some state to the server either in the form of a payload or as HTTP headers which are then operated upon by the server which sends a result after said processing is done)."

Kind of neat how SOA is now the one dictating things. Shifts in marketecture are so entertaining.

Wow - I hadn't seen this position from Dare before:
"However experience from enterprise messaging systems and global distributed systems such as the World Wide Web show that you can build scalable, loosely coupled yet powerful applications in an architecture based on passing around messages and defining a couple of operations that can be performed on these messages. Would the Web be as successful if to make web requests you had to fire up Java RMI, DCOM, CORBA or some equivalent instead of making HTTP GET & HTTP POST requests over network sockets with text payloads? "

I wonder if the latency between Fielding's paper, the original RESTafarian parties and this quote emitted from MS are some measure of the diffusion of innovation

This - Service Oriented Enterprise - is a good blog to read. I'll be following it and hopefully learning things.

I like his summary of his analysis of REST. His point #5 - "Additional exercises should be performed to document how many RPC style verbs would be translated into a more REST-style. Verbs that don't translate shouldn't be forced to fit, rather new verbs should be introduces as part of the first-order vocabulary." - can be an enlightening excersize when you find that a great many verbs actually do translate very easily. And the ones that don't translate easily are enjoyable puzzles and occasionally give me a chance to learn more about the full flexibility and capability of the Web.

Now here's a phrase I think has staying power... "the services web".
In relation to XML databases, Jon says "... They're becoming the high-performance pumps that push XML traffic around on the emerging services web..."

Jon's Radio - XML databases move to the middle

As you probably didn't notice, I haven't posted for a couple years... I was busy at a startup (which has since folded) and I 'took some time off' before joining another company. In trying to move on from the startup frenzy I went in search of a large, stable, slow company - unfortunately I wound up at Amazon which should explain the more-than-year-long absence of posts.

In the past two years the REST approach has gathered a lot of attention and Web-scale architectural discussions are much more common. It's too bad I didn't take the time to blog that era of growing awareness, but there are plenty of others better at it than I would have been.

It is very enjoyable to me to encounter anecdotes of organizations big and small that investigate RESTish approaches and choose to implement systems in that style - (for example: Well, these guys punted on UDDI and spent a day writing a small directory using RESTish terms with easy http access. They are very happy.) I'm sure these will lead to growing body of examples that will help fuel the next phase of the adoption of the REST architectural style.