The more I think about my main contribution to the RDF/XML Rec, the more I like its implications.
And congrats to the Atompub WG on Atom going, effectively, 1.0. I have mixed feelings about the syndication format; IMO, it should have reused existing formats, warts and all, in the spirit of paving the cowpaths. On the other hand, with Microsoft’s buy-in, its success now seems assured (though it will continue to trail RSS for years to come, it seems). I’m much more excited about the potential of the protocol though.
(link) [del.icio.us/distobj]
Via Tim, a thorougly interesting piece from Benjamin Carlyle on REST and Object Orientation.
If you’ve ever emailed me, you know my address is “distobj@acm.org”, where “distobj” is, of course, short for “distributed object”. So I think it’s fair to say that I’ve given this particular relationship a whole lot of brain-time over the past several years (nine, in fact). I agree with Ben’s presumed hypothesis that there’s a deep relationship here, and he comes very close to nailing it, but falls just short, IMO.
Where I think things go wrong is when he talks about Java Beans;
The real meat in my pie is the use of properties, or as I would call them: Resources.
Nope, properties are properties, resources are the Beans themselves. Imagine a “Person” Bean which might expose the properties; name, birth date, birth city. Now imagine that Bean as a resource, with its own http URI; invoke GET on it and you receive, say, an XML document like this;
<Person> <name>Mark Smith</name> <birthDate>55</birthDate> <birthCity>Bristol</birthCity> </Person>
So the properties of a Bean represent (at least some of) the state of the Bean, and therefore are returned together in a request for a representation of its state, i.e. GET.
Distributed objects are dead! Long live distributed objects!
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
Don Smith (belatedly) wonders what it means to be document oriented;
To me, document-oriented (also called message-oriented or message-centric) is less about programming models or on-the-wire representations and more about the developer’s mindset. I recommend all Web service developers try to change the way they think about distributed solutions … especially if they’ve come from a DCOM, Remoting, etc. background. When you’re not thinking in terms of messages, certain inappropriate concepts can seep into your service. For example, object-oriented concepts like inheritence and polymorphism don’t belong in a service interface. Don’t get me wrong, there are ways to acheive the benefits these concepts provide, but it’s done differently. Developers with an RPC mindset also think in terms of object instances which don’t really apply to the messaging mindset. Lastly, RPC is largely dependent on the request-response exchange pattern. Messages can be one-way, pub-sub, solicit response, or request-response. Okay, one more thing to distinguish these mindsets … messaging scenarios are better equiped to handle async, store and forward, and queuing scenarios.
It amazes me that I can agree so emphatically with with what’s written above, yet also know that Don, like other Web services proponents, is missing the point; if you’re not doing state transfer, you’re just putting lipstick (XML) on a pig (RPC). How can you tell the difference? If there’s an operation name in your “document”, then you’re not document oriented.
Still standing. This isn’t heroic or even brave; it is enlightened self-interest. Openness and transparency protect freedom. Even with the pain, it is better than ignorance because with knowledge, the future is pregnant with choices instead of inevitabilities. Stupid is bad for anyone regardless of how powerful or how pitiful.
(link) [del.icio.us/distobj]
Another gem from Dave;
This is the main thesis of this article, that the application layer modeling is affected by the underlying protocol.
Absolutely. I think the leaks that Dave so accurately describes there, is, largely, his fault (but a Very Good Thing! 8-). He has tried to respect the architecture of the Web in his work on Web services, and as a result, created the problems he now describes, along with everybody else who ever pushed to defend a principle or constraint of Web architecture, including myself. I was very frankly surprised that it took this long for a Web services proponent to point it out, but I’ve been doing it for a while (and long before that post – it’s just the most succinct description I could recall of the layering problems with Web services, albeit slightly different ones than Dave’s describing).
He goes on…
Another possibility is to throw out anything “extra” from the underlying protocol, that is effectively dumbing HTTP down to UDP.
Yes, that’s the only way that what most Web services proponents know “protocol independence” to mean, could be realized, and the leaky abstractions Dave speaks of, avoided.
The next sentence reads;
Web services using SOAP and WSDL 1.1 has already done that by ignoring the HTTP Operation.
Right. And as I mention in the above mentioned post, there’s more than just the operation which is ignored, including the Request-URI when using wsa:To, and the response code when assuming any response with a SOAP fault element is a fault.
Unfortunately, at that point, Dave apparently reiterates his undying faith in this beast of an architecture, and attempts to resolve this fundamental problem within it. Ouch!
There is another way; embrace the Web.
Oh, and all this reminds me that Steve Vinoski and I just had a great chat where we came to agree on what was and wasn’t desirable to do in the name of “protocol independence”.