To help set Mark straight; Servlets are a Java API for implementing HTTP operations. (Incidentally Servlets don’t have a client side – for that you need to either use the URL class or the commons-httpclient library). So Servlets take care of the server-side part of HTTP protocol for you. To use REST speak, Servlets implement the server side of the transfer part of REST.
HttpServlets do expose a client side API, they just do it in a language neutral way via the HTTP protocol. I could have also compared SDO to java.net or HttpClient I suppose, but my argument would have been the same.
SDO on the other hand is a generic Java API for any arbitrary typesafe blob of state. It says nothing of how you fetch the state, where it comes from, what transfer/marshalling mechanism etc. The state could come from anywhere; from parsing any XML document, calling some RESTful service, a web service, an RMI call, an EJB / JDO / JDBC / JNDI / JMX query etc.
Yes, true, just as a RESTful service could front for an EJB, JDO, JDBC, JNDI, JMX query etc.
When I first reviewed it, I looked for a “smoking gun”; that thing that would stand out as evidence that the authors hadn’t studied the Web in sufficient detail. I didn’t see any at the time, but after having a second look I’d say it’s the use of XPath; SDO should have used URIs (or perhaps both) as the means of relating objects. Perhaps that might help you see where I’m coming from with my objections, James.
Thanks for the feed/pushback.
Update: James responds again. I think his last paragraph is all I really need to comment on;
Incidentally, the interesting thing about SDO is that the navigation mechanism is pluggable. So Mark, an SDO implementation could use URIs (or XPointer, or XQuery etc) to navigate through the data graph.
Yes, understood, but that misses the point of the Web. URIs aren’t just another identification mechanism, they are the most general identification mechanism, enabling other mechanisms to be defined in its terms (e.g. FTP file names engulfed via the ftp URI scheme, email addresses engulfed via mailto: etc..).
Sure, the Web can be treated as just another system, but as soon as you do that, any attempt to build a general model that includes it ends up being an attempt to reinvent it, because that’s what the Web is; the system of all systems.