Web Things, by Mark Baker

Inaccurate (“ruthless disregard for unpleasant facts” seems to be the purvey of SOA proponents), but very funny nonetheless 8-)
(link) [del.icio.us/distobj]

“and keeping in mind that ‘reach’ is another way of saying ‘wider adoption’, I’d venture to say that good habitability is a necessary condition for it”. Good thoughts from Eve Maler.
(link) [del.icio.us/distobj]

Dave writes;;

In the Web services vs REST debate, the sad part is that the communities are not coming closer together. There are things that could be done for Web services to integrate with REST but few people from either camp are jumping up and down.

Let me ask this, what’s the middle ground between a position which says “Interface constraints are required for Internet scale distributed systems”, and one which says “Service specific interfaces are required for Internet scale distributed systems”? IMO, there is none. “Support both”, which is how I’d characterize Dave’s many well intentioned efforts to bridge the divide, is not a middle ground, since supporting both requires rejecting the interface constraint. Either that, or you’re talking about supporting two distinct architectural styles, which is the aforementioned divide. Practically though – in terms of the many specs being developed, I think the only middle ground is RESTful SOAP, which isn’t so much in the middle from a REST POV (since it is REST), but is from a Web POV, in that SOAP would be used to extend the Web rather than walk all over it. FWIW, that position is what I’ve been fighting for since I joined the XMLP WG. I’m really quite a moderate. 8-) He ends;

[…]I call on technical people to engage in deeply technical debates and less on “marketing” campaigns.

Ouch! 8-O There’s certainly been some “non” and poor technical arguments made on the REST side (as I mentioned publicly, I didn’t care too much for one of Carlos’ posts on the topic), but by and large the arguments have been entirely technical! I’ve certainly primarily used technical arguments over the past five years. It is to Dave’s (enormous) credit that he made the effort to describe SOA as an architectural style, but he’s been the only Web service proponent who’s even attempted to use the language of software architecture to defend his position (even if I often disagree with him when he does). But notice how his efforts never made it into the Web Services Architecture document! What does that say about the aggregate respect for software architecture by the WG? Oodles, IMO. The truth is that there’s already been a whole lot of technical debate, some of it even fruitful. The camps have just agreed to disagree, insofar as Web services proponents argue, in effect or actuality, that either a) the architectural properties that SOA doesn’t have that REST does, aren’t important to Internet based systems, or b) that SOA does not have less of some architectural properties as REST proponents claim, digital marketing services. I’d also like to remind Dave how we got to this point. Web services were created because it was felt that Web architecture wasn’t sufficient to integrate disparate applications together over the Internet. Actually, that’s not quite right. The explanation that seems to better reflect reality is that the Web was never considered as a platform suitable for meeting the objectives of Web services, as can be demonstrated by the numerous articles talking about how Web services evolved from the likes of CORBA, DCOM, RMI, etc.., without mentioning the Web!! The Web just didn’t resemble what folks knew a distributed computing solution to look like, so it just never registered in the heads to consider it. Well, the myth of the Web being unsuitable has been largely dispelled by now. The big question then, I’d say, is why haven’t the implications of this – that Web services exist – been revised as a result?

Dare Obasanjo, RESTafarian 8-)
(link) [del.icio.us/distobj]

“Document style indicates that the SOAP body simply contains an XML document.”. Now there’s a definition I can get behind!! Too bad most contain wsa:Action nowadays.
(link) [del.icio.us/distobj]

“in my experience, a lot of folk who should be thinking of asynch. XML messaging in POP3 terms, think of it in SMTP terms”. +1. IME, it’s almost always a matter of trust.
(link) [del.icio.us/distobj]

Mike Champion asks;

[…]we all know what a service-oriented automated restaurant would look like — just like the human-powered service-oriented restaurants that have evolved over that last couple hundred years. What about a resource-oriented restaurant? I can see how that would work for fast food place (GET a menu, POST an order, which returns a URI one can GET the status of the order from ….). How about a real full-service restaurant, with a server who handles the details of the complex asynchronous interactions between a table full of people and a busy kitchen?

I could imagine an “order” document being submitted (POST) to the kitchen, either directly by the customer, or indirectly via the server. The server probably polls (GET) the kitchen on occasion in order to be able to estimate arrival time of the meals, or discover when they’re out of some ingredient. Or perhaps the kitchen notifies (POST) the server. Or both. In a nutshell, documents moving around.

Is there any more complex scenarios I should cover?

Mike finishes up that paragraph with this;

Sure, one could implement those interactions with XML and HTTP, but would a system design that talks about resources and representations really be more sensible than one that talks about services an d requests?

I don’t know about “sensible”; that seems a rather subjective call. But I do know that the resource oriented (RESTful) solution would exhibit greater degrees of architectural properties such as scalability, visibility, and simplicity than the service oriented solution, because RESTful solutions embody architectural constraints which induce those properties.

Nice piece from Micah. I’ll have a microformat related announcement to make next week.
(link) [del.icio.us/distobj]

Dojo’s first release, of sorts; an XmlHttpRequest wrapper. Addresses the back-button breaking problem that can happen with vanilla XmlHttpRequest.
(link) [del.icio.us/distobj]

Via Danny, a question from Julien Boyreau;

URI is first-class pillar in SemWeb AND Rest : do you know if there are large bridges between REST and SemWeb ?

There are a couple I’m aware of.

• Hash vs. Slash – when using URIs with hashes to identify resources, REST’s resource identification constraint (that resources be identified by a single datum, the URI in the case of the Web) isn’t being respected
• RDF and media types – the Semantic Web has a self-description problem in that there’s no path from an application/rdf+xml OWL or RDFS message to the axiomatic triples it encapsulates. Did the sender intend to communicate those triples to the recipient, or not?

More on that last point here.