Web Things, by Mark Baker

Jon Udell urges the REST movement to not dismiss SOA. Specifically …

Now that the benefits of REST are abundantly clear, it’s time to circle back and ask when REST isn’t sufficient. The answer is that we’ll need the kinds of capabilities WS-* provides as our point-to-point, client/server-like applications evolve into webs of communicating services.

Yes, absolutey, we’ll need the capabilities that the WS-* stack provides (for the most part). But do we need the WS-* stack itself to provide those capabilities? I’m certainly all for trying to reuse existing specs where that makes sense. The issue though, is that with most of them, they explicitly or implicitly require disregarding a key contraints of REST, disrespecting Web architecture, or both. WSDL’s probably the poster child for this, as its raison d’etre is primarily to encourage rejection of REST’s uniform interface.

The good news is that not all of the Web services specs have this problem. Some off the top of my head that I consider more or less workable on the Web (not to suggest that they’re otherwise without fault, and also not to suggest I’ve had a serious look at every spec out there, even these) include SOAP, WS-Security, and SAML. If that’s what Jon has in mind, then we’re good to go. But if he was thinking about the likes of UDDI, the various reliability specs, transactions, etc.., I’d have to disagree with him. We need capabilities provided by solutions which were built with the Web and REST in mind, like those of the Semantic Web and ARRESTED.

Chris points to, and agrees with, some words from my old dist-obj buddy Stu Charlton. Those words include this snippet;

There are numerous SOAP successes today that are invisible to the blogosphere, because their inside corporations. Millions, if not billions of dollars of transactions run through SOAP at this very moment.

I’m confident that’s true.

But correct me if I’m wrong, but wasn’t the objective of “Web services” to build a universal, Internet (inter-corporate) scale, application-to-application integration platform? If so, then what exactly does pointing out that it’s primarily used for intra-corporate integration demonstrate?

My point has always been that Web services are unsuitable for Internet scale integration, and Stu’s observation just reinforces this for me (not that it needed reinforcing, of course 8-).

Sean McGrath:

So, the next time somebody says to you “lets just use SOAP”, say “Great!” and then ask him/her for a quick run-down of the proposed conversation models, the synch/asynch selections, the granularity, the semantics of the payloads. I’ll bet you that nine times out of ten none of the above will have been thought through.[…]

Architectural properties don’t appear out of thin air, they emanate from the principled application of architectural constraints. No constraints, no properties.

I wish I had the time to comment in detail on all the recent goings-on viz a viz SOAP/SOA-vs-REST, but alas, I don’t (in fact, you probably won’t be hearing very much from me until the summer).

I do wish though – and this comment is directed at both sides of the debate – that folks would stick to technical arguments. Because as much as agnosticism sounds like a reasonable position, it totally misses the point that there exist technical issues that make SOA completely unsuitable as an Internet scale integration architectural style. If you want to add transactions, reliability, asynchronicity, etc.. to the Web, you don’t need to relax any of REST’s constraints as SOA does, you need additional ones.

Carlos goes to town on Web services. Ouch!
(link) [del.icio.us/distobj]

Steve Maine and Mark Baker discuss whether putting operation names in URIs is a RESTful (specifically, respects the uniform interface constraint) or not
(link) [del.icio.us/distobj]

Via Tim, a great post from James Governor, a founder of analyst firm Redmonk, who’s apparently not afraid to call a spade a spade. Good on him.

Whats a web service? Still a great question. But anyone that defines a Web Service using SOAP in the definition is missing out on where the action is. Distinctions between enterprise and “consumer” are breaking down. REST is evidently where that convergence is being played out, not WS-I.

Even more interesting is that Joe McKendrick at ZDNet picked it up.

Again, it’s a shame SOAP is getting caught up in this backlash, since it’s not the spec that’s the problem, it’s how people are (mis)using it. Oh well, it’s not like that’s much of a surprise 8-) 8-(

As relayed by Nelson Minar, author of two of the Google APIs;

From my experience nothing interoperates well, even in the basic SOAP stack. rpc/encoded used to work OK, within its limitations but now that’s deprecated it’s not a realistic option for new services. So you’re stuck with document/literal where practice isn’t great.

And remember, this is just SOAP 1.1 a spec that is five years old, and which (apparently) requires clarification upon clarification… but still can’t seem to get it right.

Ouch. Even if you like the (presumed) architecture of Web services, this would seem reason enough to give pause and to motivate consideration of a Web based solution, no?

Update; based on some offline feedback, I should clarify that the problem Nelson talks about with the doc/lit encoding isn’t specific to Web services and could also be encountered in a Web based solution. But my intent here is just to throw cold water on the general concept of “SOAP = interoperability”, and to point out that the largest distributed application ever created by mankind – the Web – got that way because it truly embraced interop, and wasn’t just paying it lip service.

Update; mea culpa, it was of course Steve’s post, not Tim’s. My apologies to both. One of the disadvantages of reading blogs through Bloglines, since all the styling is lost.

A thoroughly enjoyable post from Steve. After a preamble on isomorphism, he presents an example SOAP message and asks;

So, an open question to the audience: are the SOAP messages I described above more “RPC style” or “document-oriented?” Are these services talking to each other, or stateful objects? Are you a good witch or a bad witch? To all these questions and others I answer: mu.

My answer is that they are RPC style. Let me explain further in response to his conclusion, which reads;

Amazon.com’s e-commerce implementation is one of the most successful and highly touted REST API’s in existence today. The implications of the fact it’s also 100% structurally isomorphic to SOAP + WS-Addressing are left as an exercise to the reader.

Actually, it’s not isomorphic in that sense since the contract is very different in the REST and WS/SOA cases (does that fall under “structurally isomorphic”? dunno).

Let me start by tweaking Steve’s example to be what I would call a “document-oriented” style interaction;

<S:Envelope xmlns:ht="http://schemas.hyperthink.net/" ... >
   <S:Header>
     ...
    <wsa:To>http://hyperthink.net/xml</wsa:To>

    <wsa:MessageId>uuid:123...</wsa:MessageId>
    <wsa:ReplyTo> ... </wsa:ReplyTo>
    <ht:Service>CommerceService</ht:Service>

    <ht:SubscriptionId>12ABC</ht:SubscriptionId>
     ...
   </S:Header>
   <S:Body>
     <ht:CartId>47</ht:CartId>

     <ht:HMACToken>[blah]</ht:HMACToken>
   </S:Body>
</S:Envelope>

Notice the difference? wsa:Action has been removed. So I could submit that message to a service, and it could return exactly the same response as Steve’s example service does (though I’d remove the wsa:Action from it too).

Document in, document out. Simple.

Now, back to Steve’s Amazon URI based example. My claim is that the contract is different, just as the contract is different between Steve’s GetCart example and mine above. Specifically, with the SOAP message, the request semantics are “GetCart”, and the response semantics are “GetCart was successful”. But in the URI example, the response semantics are “GET was successful” since the request semantics are GET. In other words, with the URI, the client has zero visibility into the semantics of the “GetCart” string (aka the URI is opaque), but in the SOAP message, it has full visibility.

So rather than provide homework as Steve did 8-), I’ll ask a single multiple choice question; what’s the operation in my SOAP message example above? Is it;

• A. GetCart
• B. ProcessMessage
• C. POST
• D. B and C
• E. There is no operation

Hint; there’s always an operation, since something has to succeed or fail.

Via Edd, a link to an interview with Stewart Butterfield. It’s a great interview all-round, but here’s a couple of points on topic for my weblog;

People who would be reluctant to provide metadata most of the time do so on Flickr because there’s a payoff for them. A) other people see their work–work is probably the wrong word because I don’t think most people see it as work in a serious artistic sense– but people see what they’re up to, see what they’re creating. And B) because they derive some pleasure from building value in the global collection.

I think this point is often missed by those who hold the “no cheap metadata” position. Turning “metadata” keywords into dereferencable URIs – as Flickr (among others) does – provides the means by which these “payoffs” that Stewart refers to, can be realized, cheaply. For me, it also helps drive home the point that one person’s metadata is another’s data, as this feedback loop is exactly the same one that exists when you publish any data behind a dereferencable URI. Taking it further, one might, for example, provide metadata for the Flickr metadata, which this is, if you squint a bit (not literally 8-). And to complete the loop and emphasize the point, one could easily republish many of these new images as new squared circles. Fractal!

As pointed out by Edd, Stewart also had this to say about Web services/REST;

I think we had one person inquire about using the SOAP version of the API. I don’t know if any apps were actually built. There is at least one application built on XML-RPC. But all the others–I don’t even know how many there are–are built on the REST API. It’s just so easy to develop that way; I think it’s foolish to do anything else.