It may only be an automata, but I’m gettin’ good lovin’ from The Classic IQ Test;
Mark, you are a Visionary Philosopher. This means you are highly intelligent and have a powerful mix of skills and insight that can be applied in a variety of different ways.
Update; they ask for personal info on page three, but you don’t need to enter accurate information (i.e. email address) to get your results
The Web Services Description WG offered up their latest attempt at an HTTP binding for WSDL last week. I think it’s about as good as you can hope something like that to get, without rejecting Web services. But it seems the group asked itself some good questions while reviewing it, in particular this one;
Is it good practice to extract part of your content to parameterize your URI? If not, what is the best way?
To which I responded;
Invoke GET on the URI to retrieve a document, and include in that a declaration of how the URI can be parameterized. This is what forms are for (well, “GET forms” anyhow); see XForms or RDF Forms.
If you didn’t recognize it, this is a textbook case of bootstrapping; see a URI, GET it, etc.. It reminds me of the Java Beans component model, which, for all its flaws (namely, that it wasn’t useful for much more than GUI stuff), had its own wonderful bootstrap mechanism; the zero argument constructor (sorry, no good URI for it). This permitted anybody who was in possession of a bean class to instantiate it without a priori information about it. Some might argue that this was just deferring binding, and they’d be right, but there’s no “just” about it; deferred (aka late) binding permits more functionality to be internalized into the system. In the case of beans, this was realized via the use of a wizard which could be triggered when instantiating beans that needed parameterizing.
Bootstrapping is your friend.
Dave Bettin comments on my previous blog entry. He writes;
Mark Baker discusses the causality of redundant message metadata due to the protocol independence nature of Soap. HTTP is not the omnipresent protocol in the services ecosystem; i.e., there are internal business cases where HTTP is not necessary and straight TCP is preferred. I want my metadata to live in the Soap packet; I don’t want leaky metadata abstractions.
I don’t mean to offend Dave with this comment, but that response is typical of what I hear when I make my claim that protocol independence is a bug.
So, how to respond? Let me try a few on for size;
Perhaps one or more of those will take. 8-)
John Beatty reminded me that a friend told me a great business (aka non-plumbing) description of the differences between transport and transfer in the supply chain management space, where they use those very same terms. Paraphrasing, he said;
Transport refers to the movement of goods between locations. Transfer refers to the change of ownership of those goods.
Compare that with this REST vs. SOA diagram.
From early on in my work as a member of the XML Protocol WG to make SOAP 1.2 usable in a REST based architecture, I found myself up against the unmoveable force known as “protocol independence”.
I was reflecting on this experience in the car this morning, and realized that I could perhaps explain the different viewpoints – of “protocol independence” and “transport vs. transfer” specifically – in terms of message metadata.
Message metadata is that data in a message which defines the context for interpretation of the rest of the data in the message. Application protocols typically have a handful of pieces of it. For example, HTTP has the protocol version, request methods, request URIs, and response codes, and each one of those changes the meaning of their message fundamentally.
My issue with “protocol independence”, which essentially says that you should put everything you need to know in the SOAP envelope, is that it requires me to a) disregard the metadata already provided by application protocols, and b) requires me to reinvent the same mechanisms higher up! Here’s two examples of that form of reinvention;
One type of message metadata that hasn’t, to my knowledge, been reinvented, is the response code metadata. I don’t mean the response codes themselves, as SOAP does have different standard fault types. I mean a standardized place in a SOAP envelope which indicates whether the SOAP message is a fault or not. What’s that you say? The mere presence of a SOAP fault in the body of the envelope is sufficient information to identify the fault? Ah, I see. Well then, you’ve got a message metadata problem. To explain it, consider a Web service with an operation whose job is to return the last fault that the service generated. How do you distinguish between the success of that operation and its failure? Both return faults inside the SOAP envelope! One way would be to define a wrapper that encapsulates the fault in the not-a-real-fault case, thereby hiding it. But that wrapper is exactly the kind of message metadata that I’m talking about!! Another case of reinvention, and again, completely unnecessary when you’re using an application protocol which already has a place for such metadata. When you consider that SOAP doesn’t define this wrapper, then you have to conclude that either a) SOAP is broken, as it prevents me from defining services which return data that looks like a fault, or b) there’s another way to use SOAP, as an extension protocol which reuses the message metadata of the underlying protocol (when it has any, which all application protocols do).
Compare and contrast.
A common trend still is that there are no generally accepted definitions of (web) services, and people spent way too much time criticising each others definitions.
Dan Connolly wrote, this in response to a question regarding the value of dereferenceable URIs;
my answer to “but what if I don’t want to publish representations or descriptions of the thing” is: then you’re not doing what you can to establish consensus around your terms.
My point being that perhaps if there were more Web services to which people could look for definitions, conferences like the one Werner’s attending (not to mention the Web Services Architecture WG and indeed most other Web services standardization groups) could be more productive.
Nothing facilitates concensus quite like running code.
Don’t chicken-and-the-egg problems suck?
The more I learn about Zope, the more I like. Mostly.
I’ve always had a keen interest in software composition, and so was particulary impressed with Zope’s notion of “acquisition”, which is just composition by aggregation. What’s really novel here is not that, which has been done before, many times, but the binding of the URI hierarchy to containment relationships. Kudos for that.
One of the very few criticisms I have about Zope though is the use of “URL Traversal”, to locate scripts named in a URI. I added some comments to that page (itself, a nifty feature!), as you can see there;
I was thoroughly impressed with most of what I’d seen in Zope, but not so much with this feature. Perhaps it’s convenient, but it’s also quite dangerous in general I think. The examples of “feed” and “wash” are are called “unsafe” methods in Web architecture terms (http://www.w3.org/TR/webarch/); that is, they change the state of the object. Therefore they, shouldn’t be invoked with GET, as Googlebot might come along and accidentally feed your hippos. If you want to change the hippo directly to the fed state, use PUT with a document which represents the state of that fed hippo. If you just want to give him food (that he may or may not choose to eat), use POST with a description of the food.
I also wonder if the same misunderstanding about GET vs. POST was responsible for some problems I noticed with object publishing. For example, both GET and POST end up invoking the “index_html” method (eek, a horrid name) of an object (basically the equivalent of doGet() for you servlet fans). It’s odd that the object model define ambiguous dispatch behaviour for GET/POST, yet define proper dispatch behaviour for PUT, HEAD, and the WebDAV extensions. Perhaps a legacy mistake that’s too costly to fix? Dunno. But the more I read the publishing section, the more it seems that Zope has a bit of split personality in supporting both the Web and RPC models.
Hopefully that doesn’t get in the way of what I want to do with it.
Today the WS-I announced a bunch of implementations of a sample application they’d speced out. Seems like a good idea.
I downloaded a couple of them, and was very pleased to see a series of URIs that appeared as though they were identifying domain objects;
http://localhost:8080/wsi/scm/logging http://localhost:8080/wsi/scm/retailer http://localhost:8080/wsi/scm/warehousea http://localhost:8080/wsi/scm/warehouseb http://localhost:8080/wsi/scm/warehousec http://localhost:8080/wsi/scm/manufacturera http://localhost:8080/wsi/scm/manufacturerb http://localhost:8080/wsi/scm/manufacturerc
For a moment there, I thought my days of REST promotion were over and that secretly and collectively, WS-I members had “got it”. But alas, that wasn’t the case. Though you can invoke GET on the URIs, all they return – at least in the case of BEA’s WarehouseA URI is an HTML description of the object, include exposed operations and sample code. Bowstreet’s URI returns a SOAP fault, Sun’s returns an HTML page describing the state of the SOAP services, IBM’s returns a prophetic HTML page, and Microsoft’s returns an indication that GET isn’t supported at all. Ditto for Oracle.
So why wasn’t the returned document a description of the state of the warehouse, including inventory information? Once you’ve got the URI for a domain object (kudos on that, at least), why not serialize the state of that domain object as a response to GET requests?
When you double-click an application[…]
Isn’t that cute? It’s so 1988. Of course, any self-respecting application developer today single-clicks theirs. 8-)