30Oct
Filed in Uncategorized
Leave a comment
Dave made the following suggestion for a SOAP definition;
It’s a simple way to call procedures running on other machines, on other OSes, written in other languages, using different economic systems, without being forced to pay a tax to Microsoft, IBM, Apple, Sun or the W3C.
SOAP isn’t that at all. That’s XML-RPC. Dave’s a bright guy who writes great software, but when it comes to distributed systems, there’s a lot he doesn’t understand.
The SOAP 1.2 spec defines SOAP as;
SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.
Which is a pretty decent definition, though not very detailed as to how one actually might use it. For a better definition, I look to SOAP’s brethren, PEP. It’s defined as;
The Protocol Extension Protocol (PEP) is an extension mechanism designed to accommodate dynamic extension of HTTP applications by software components; and to address the tension between private agreement and public specification.
Of course, SOAP isn’t tied to HTTP, but PEP didn’t really need to be either. It could also be patched to be an extension protocol for non-HTTP protocols, as SOAP 1.1 was “patched” in the form of SOAP 1.2.
Please, if SOAP has any chance of success, let’s try to distance it from RPC.
soap, travel, w3c, xml
29Oct
Filed in Uncategorized
Leave a comment
A couple of recent blogs and messages I’ve seen prompted me to write this. They both suggest that a “SOAP message” is necessarily a “message”. I disagree.
When bound to an application protocol, a SOAP message/envelope is not a message because it doesn’t contain the necessary information with which to understand what it means. For example, a SOAP envelope which included a HR-XML resume is not a message, because it doesn’t say what is to be done with the resume; is it to be forwarded on to somebody else? Submitted as part of a job application? Meant to update an existing resume? This is where the envelope of the underlying protocol, such as HTTP comes in; the HTTP request line (method, URI, version), headers, and the body which includes the SOAP envelope, forms the entire message.
If HTTP were a transport protocol, then a SOAP envelope/message sent over HTTP would always be a message. But it isn’t, it’s an application protocol. And please don’t think this is nitpicking. Far from it, I believe it’s the single biggest misunderstanding that has lead us to where we are at with Web services (i.e. a mess). If people knew what an application protocol was, I think many more (not all, of course) would have thought twice about proceeding with Web services.
mobile, soap, xml
25Oct
Filed in Uncategorized
Leave a comment
Peter Drayton writes that some folks have had “RESTian awakenings” as a result of his presentation, which is just awesome. While reading up on one of his references though, I found this in Alexis Smirnov’s blog which suggests that at least some people still have a ways to go;
After his talk, Peter, Tim and Sam talked about a need to get a WSDL from a SOAP URI.
My response to that is, no, there is no need for WSDL. The fundamental advancement of the Web over previous distributed object systems is that it doesn’t need an interface language because all components expose a uniform interface.
An analogy; if you’re a Java programmer, think of it as working with all your objects after they’ve been downcast to java.lang.Object. Obviously java.lang.Object will only define methods which are common to all objects, so you wouldn’t expect it to have a method such as “buyBook” because not all objects are books. This is what REST’s uniform interface constraint is all about.
rest, soap
17Oct
Filed in Uncategorized
Leave a comment
Paul writes that innovation in the browser ain’t dead yet. I agree. From a distributed systems POV, I think there’s two important things that need to happen to the browser, in addition to the richer languages that Paul talks about (and don’t forget about RDF and OWL!);
- making the browser a peer
- allowing the browser to own application state
The former deals with integrating a Web server into the Web browser, enabling the “Two Way Web”, like KnowNow and Idokorro (my company) do.
The latter, related to the former, suggests that cookies can be replaced by purely client-side application state. What this would look like, is that you’d drag-and-drop items from a browser window into a desktop-located container – for example, a shopping basket – and then to check out, you drag the container back to the page. This keeps the session state – the basket – on the client, per REST’s Stateless constraint. This would require an extension to HTML/XHTML to support draggable objects, as well as a means to support file upload via a drop action (i.e. targetted at some element on the page).
architecture, xml
17Oct
Filed in Uncategorized
Leave a comment
WS-I released the first draft of the Basic Profile today. I don’t know how they manage to write so much about something that isn’t necessary; you wouldn’t need profiles if interoperability were well defined. It seems to be purely a political move to bundle specs together so that the technology doesn’t look like it could be easily marginalized (though it can).
I mean, really, why on earth does anybody need to specify the possible HTTP response codes to be used, when HTTP clients can already deal with all of them (even if only to fallback to x00)?
And cookies for state management? Puh-leeze! Cookies are a hack, and only make any kind of sense when you’re dealing with an installed base (browsers) that support them. Remove the browser, and you could do state management properly, on the client (and only on the client) instead of the server. This is Distributed Systems 101 stuff here, sheesh.
Sigh. It disappoints me to think of all the time and money the industry is wasting on this.
webarch
15Oct
Filed in Uncategorized
Leave a comment
A message I sent to www-ws-arch this past summer seems to be making the rounds again. I don’t think I ever mentioned it in my weblog, so here ya go. Looks like it was mentioned on xml-dev, so perhaps that’s why. Er, and I forgot that I mentioned it in my “Playing Checkers with a Chess Set” blog too. Duh.
BTW, 10 kudos to whomever finds the “flaw” in the argument I made in that message. It’s not a fatal flaw, of course, but it does hilight the late binding issue, which I didn’t introduce in it (for fear of losing the simplicity of the point I was trying to make).
Update; the flaw is that when you get to the get/GET part, the message no longer means “get stock quote”, it just means “get a representation of what’s identified by this URI”. You find out if it’s a stock quote after you invoke GET. That’s late binding.
jimgray, xml