Web Things, by Mark Baker

WS-Eventing, from BEA, MS, and Tibco.

The good news is that finally, we’ve got a Web services spec that tackles the hard problem, interfaces. Yes, WS-Eventing is an application protocol (do we have to bind SOAP to it too?)

The bad news is that it continues the track record of abusing other application protocols (if indeed it’s objective is to be used with them, which I can only assume is the case); the more that goes in the SOAP envelope, the less suitable it is for use with them, as it just duplicates what they already provide. Once again we see WS-Addressing as the culprit; wsa:Action and wsa:To exist to replace their counterparts in any underlying application protocol. For example, for HTTP, the counterparts of wsa:Action and wsa:To are the request method and request URI, respectively.

A point of frustration for me is that the semantics of subscription itself are largely uniform. What I mean is, wouldn’t it be great if all Web services supported “subscribe”? So why not use HTTP like I’ve done, which is built for uniform semantics? Using a SOAP envelope with MONITOR and for the resultant notifications would be really sweet.

One pleasant surprise is the form that notifications take, as in this example. Notice the use of wsa:Action; the value is no longer a method, but is instead a type. Woot! That’s the first time I’ve seen the “action” semantic used properly in any Web services work. Presumably this is due to notification semantics being entirely geared towards simply getting some data to some other application; basically, POST. Of course, technically, I don’t believe any “action” is required in this case, as there’s no intent on behalf of the notification sender beyond simple data submission; the intent is determined and assigned by the recipient of the notification. But that’s still progress!

Another upside is the use of fine grained URIs for identifying the endpoints, e.g. “http://www.other.example.com/OnStormWarning”, rather than something like “http://www.other.example.com/RPCrouter”.

Overall, very disappointing from a protocol and pub/sub POV, but the progress on resource identification, uniform semantics (even if it’s accidental 8-), and intent declaration is quite encouraging. Perhaps the next attempt will be done as an HTTP extension with a SOAP binding to MONITOR (the existing binding to POST would suffice for notifications).

Dave Orchard wonders how XQuery might be put on the Web.

My position seems to fly in the face of at least one part of Dave’s position;

But clearly XQuery inputs are not going to be sent in URIs

Why admit defeat so easily? Did the TAG not say, “Use GET … if the interaction is more like a question ..”? Well, aren’t XQuery documents questions? I think it’s quite clear that they are, and therefore XQuery would benefit from being able to be serialized into URI form. That’s not to say that all XQuery documents would benefit, but many could.

I got a lot of pushback from some in the XQuery WG when I suggested this to them a few months ago, but I think the TAG finding is quite clear. I also strongly believe that doing this is the only significant way in which XQuery can be “put on the Web”.

On the upside, Dave says good things about the value of generic operations;

I first tried to re-use the Xquery functionality rather than providing specific operations in the SAML spec. My idea was that instead of SAML defining bunch of operations (getAuthorizationAssertionBySubjectAssertion, getAuthorizationAssertionListBySubjectSubset, ..), that SAML would define a Schema data model which could be queried against. A provider would offer a generic operation (evaluateQuery) which took in the query against that data model.[…]

Of course, while you’re generalizing, why not go a little further and just use “POST” (suitably extended) instead of “evaluateQuery”?

I also like what Dare had to say about this too, in particular;

One thing lacking in the XML Web Services world are the simple REST-like notions of GET and POST. In the RESTful HTTP world one would simply specify a URI which one could perform an HTTP GET on an get back an XML document. One could then either use the hierarchy of the URI to select subsets of the document or perhaps use HTTP POST to send more complex queries. All this indirection with WSDL files and SOAP headers yet functionality such as what Yahoo has done with their Yahoo! News Search RSS feeds isn’t straightforward. I agree that WSDL annotations would do the trick but then you have to deal with the fact that WSDL’s themselves are not discoverable. *sigh* Yet more human intervebtion is needed instead of loosely coupled application building.

Heh, good one, especially the use of the “human argument” against Web services. 8-)

He writes;

Is it a transport protocol or not?

Definitely not a transport protocol. It’s a state transfer protocol.

The difference is this: the HTTP interface is vague and the Linda interface is specific. Linda has precise, simple semantics. The possible range of behaviors exhibited in Linda-based systems benefit from being layered on *top* of those precise, simple semantics.

Hmm, I’m not seeing it. How is get, put, and post any more vague than rd, write, and take? All have “precise, simple semantics”. IMO, the only really important difference between them is that the former are operations defined on a more general abstraction than the latter; the resource for REST, and the tuple space for Linda. If it helps, I drew that relationship once upon a time.

Also, regarding Linda, I don’t see how the range of behaviours is a result of layering. Perhaps this is just a nomenclature problem, but I attribute the wide range of behaviours to the generality of the Linda interface. For example, if your operation was getStockQuote(), then you’re only going to be able to use it for stock quotes. If it were getQuote(), then that would be more general, as you could also use it for insurance quotes too. If it were GET or rd, well, you could use it for most anything, couldn’t you?

One other point I want to respond to;

Vanessa Williams provides an elaboration of HTTP for a tuple space application protocol. As I understand REST this should therefore provide the application protocol of a tuple space on the architectural style of REST using the HTTP transport/application protocol mix. In this case the advantage of using REST and HTTP is supposed to be found in the hardware and software that would already be in place between the client and the server.

I wouldn’t say that’s what Vanessa did. What I would say she did, is that she described how one could build an HTTP gateway (a Facade) to a tuple space system; identifying each space with a URI, and mapping HTTP operations to tuple space operations.

Offline, I suggested to Patrick that if we took Linda to the IETF to standardize, that we’d be placed in the Applications Area where we’d be tasked with defining “TTP”, the “Tuple Transfer Protocol”. This application protocol would include operations such as READ, WRITE, TAKE, etc.. Perhaps it might even accomodate extensions so that somebody could, in the future, define the “TTP-NOTIFY” extension protocol which added the “NOTIFY” operation. That would also, as with HTTP, most definitely not be a transport protocol … though I’m sure most SOAP proponents would want to treat it like one. 8-)

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;

• HTTP was just an example in that entry; the message metadata issue is important to the use of all application protocols … but not transport protocols. If you’re using a transport protocol, like TCP, then all the message metadata should be in the SOAP envelope as TCP doesn’t provide any of its own.
• So you agree SOAP is broken, as you can’t define a service which returns faults?
• Comparing HTTP and TCP is like comparing HTML and Ethernet.
• You can have your metadata in the SOAP packet, but firewalls won’t find it there, as they look for it in HTTP, SMTP, and other application protocols. If firewall admins learn that metadata important to their duties (i.e. protecting their intranets) is being hidden from them, you’ll be shutdown pronto.
• SOAP, the spec, should be protocol independent, permitting bindings to protocols other than HTTP to be created. It’s the use of SOAP which shouldn’t be protocol independent.

Perhaps one or more of those will take. 8-)

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;

• the one I talk about a lot; defining a new place to put the requested operation
• putting the target identifier in the SOAP envelope

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).

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?

Until last week, the SOAP document/literal examples I’d seen differed from the rpc/encoded ones only by the encoding. Then I spotted this example (in section 5.1 – sorry, no URI) in the WSDL 2.0 Primer;

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
	<customerName>Kevin Liu</customerName>
	<checkInDate>2002-09-01</checkInDate>
	<checkOutDate>2002-09-10</checkOutDate>
	<roomType>double</roomType>
	<comments>the customer will be arriving late in the evening</comments>
 </env:Body>
</env:Envelope>

Ignoring the problem that there’s not a single child element of env:Body, this is, from a Web architecture POV, quite encouraging; we have a SOAP envelope encapsulating state. Very RESTful (at least the part of the architecture that is visible in that example).

But if you know where (how?) to look, the Web is nearby. The key is to realize, once you’re dealing in state, that the obvious next question is, “The state of what?”

Don Box asks;

In a world in which all SOAP messages have <wsa:Action> header blocks, why do my Body elements need XML namespace qualification?

First order answer; I’d say simply because an intermediary that doesn’t know the value of the Action header might want to look at the payload.

Second order answer; I think it’s a fairly small & uninteresting world where it would it make sense to have Action headers within the SOAP envelope. In order for SOAP to make proper use of application protocols (well, transfer protocols at least), SOAP headers should be constrained to containing representation data and metadata, as that’s the data that remains constant between hops over different application protocols. For example, through a HTTP to SMTP bridge, a SOAP envelope should remain constant. “Action” is message metadata, and therefore does not necessarily remain constant between different protocols; it’s hop-by-hop.

Where it would make sense to put the Action header (and other non-representation headers) in the SOAP envelope, is when SOAP is used with transport protocols. But I don’t think there’s much value to that, at least in the short/medium term; the value of reusing established application protocols is too great.

A good and seemingly fair comparison of different approaches to using Amazon Web services in PHP, via SOAP and REST.

I’d previously heard Tim O’Reilly’s 85% number (relayed via Jeff Barr), but just learned of another interesting stat in that article; Amazon’s RESTful queries (via GET) are 6x faster than their non-RESTful ones (via POST). That seems high to me, but not having any more details in front of me, it’s hard to dissect why that might be the case. Anyone got the details?

In a report on Web services tools, PC Magazine‘s Robert P. Lipschutz writes;

Data-based strategies such as Roy Fielding’s REST (REpresentation State Transfer) replace SOAP and put the content, Uniform Resource Identifiers (URIs), and XML at the center of the equation. It’s too early to make the call on REST, but don’t rule this option out.