Web Things, by Mark Baker

Exactly.
(link) [del.icio.us/distobj]

“The URI scheme should answer the question of “what application interface should I expect?”, which is a a lot more than “what protocol should I use?”” Amen.
(link) [del.icio.us/distobj]

I think Jorgen misses part of the point of the team comment for WS-Transfer, when he writes;

The W3C Staff comments on WS-Transfer make interesting reading – and really summarize what WS-Transfer is all about: […] WS-Transfer does not have all the features of HTTP regarding the manipulation of representations, such as caching, or content and language negotiation. However, the extensibility of SOAP would allow to add such capabilities incrementally, and it can benefit from the use of existing SOAP extensions such as WS-Security for security, or WS-Reliability or WS-Reliable Messaging for reliability.

How can it be a good thing, that all those features were lost and replaced with … wait for it … merely the opportunity to add them back in the future?! Do these folks realize the amount of money that’s been spent optimizing and deploying the Web, CDNs, and caching infrastructure in general? You think people are eager to redeploy all that? And for what, angle brackets?

Egads. Whether you believe in my position on Web services or not, hopefully you can at least appreciate that reuse and not reinvention is in everybody’s best interest. The authors of WS-Transfer clearly don’t. There’s even better ways to use SOAP for data transfer, ferchrisakes!

I’m calling bullshit on WS-Transfer. Please join me.

P.S. here’s some previous thoughts on this mess, before the W3C submission, when I was obviously in a much more agreeable mood. I guess I’m pissed off at the W3C for missing yet another opportunity to set these wayward soles straight.

Update; Thanks, Simon. Go, Mark. Even Rob can’t help himself. Kudos, Stefan.

Tags: soap, rest, web, webservices.

Amazon has just announced a storage service which seems somewhat similar to Google Base (erm, apparently we can expect “Google Drive” shortly too). from a technology POV, though the business model – charging directly for storage and bandwidth consumption – is quite different.

What’s most interest here I think, is that it presents both a HTTP and SOAP (RPC) based interface. But more than that, the HTTP interface is quite rich. For one, they haven’t made the common mistake of putting operation names in URIs. For another, they’re making use of “advanced” HTTP features like caching. In fact, it appears as though the RESTful interface was developed first. How can I tell? Because many of the HTTP headers they used were simply replicated in their SOAP/XML messages. Yes, really. See for yourselves.

The HTTP GET response;

HTTP/1.1 200 OK
x-amz-id-2: j5ULAWpFbJQJpukUsZ4tfXVOjVZExLtEyNTvY5feC+hHIegsN5p578JLTVpkFrpL
x-amz-request-id: BE39A20848A0D52B
Date: Thu, 17 Nov 2005 08:22:38 GMT
x-amz-meta-family: Muntz
Last-Modified: Thu, 17 Nov 2005 08:22:38 GMT
ETag: "828ef3fdfa96f00ad9f27c383fc9ac7f"
Content-Type: text/plain
Content-Length: 5
Connection: close
Server: AmazonS3

HA-HA

And the (I assume) semantically equivalent SOAP response;

<GetObjectResponse xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <GetObjectResponse>
    <Status>
      <Code>200</Code>
      <Description>OK</Description>
    </Status>
    <Metadata>
      <Name>Content-Type</Name>
      <Value>text/plain</Value>
    </Metadata>
    <Metadata>
      <Name>family</Name>
      <Value>Muntz</Value>
    </Metadata>
    <Data>aGEtaGE=</Data>
    <LastModified>2005-11-18T01:25:07.994Z</LastModified>
    <ETag>&quot;828ef3fdfa96f00ad9f27c383fc9ac7f&quot;</ETag>
  </GetObjectResponse>
</GetObjectResponse>

Ouch! I honestly don’t know where to start.

But what was wrong with simply supporting RESTful SOAP, and returning the data wrapped in a SOAP envelope, adorned with (essentially) the same HTTP metadata as in the pure HTTP example above? It would be returned if the HTTP request included a “Accept: application/soap+xml” header. That way you get to save face by telling folks you support SOAP, while also getting all the benefits of reusing the Web. *shrug*

I find it hard to believe that the bright folks at Amazon did this because they felt it was useful. I imagine there must have been a mandate that came down from up high dictating “All services must expose SOAP and REST interfaces”. Because that SOAP interface is comical. Nevermind 85%/15%, I’d be surprised if anybody used it.

“You know its bad when I feel like I’m channeling Mark Baker!” 8-)
(link) [del.icio.us/distobj]

Yup! “I predict (and I certainly hope) that many implementations will incorporate support for RESTful applications using SOAP messages. As even Mark Baker would agree, there’s nothing inherently wrong with SOAP itself and there is no reason it can’t be a
(link) [del.icio.us/distobj]

In the comments on an inquisitive blog post by David Megginson, Mike Champion asks;

Show us the WS-* success stories, show us the secure, reliable and truly RESTifarian success stories, and let the world judge from the evidence.

to which I responded;

Mike – empirical evidence is wonderful to have of course, but it’s also extraordinarily costly to come by. It’s also unnecessary, since we’ve had at our disposal for years (since Perry & Wolf’s “Foundations” paper in the early 90s) a method of evaluating software architectural styles for their suitability for any particular task in any particular environment. Applying that method to SOA/WS tells us a number things, most importantly that it doesn’t scale across trust boundaries (which I’ve been saying for many years, and folks now seem to be acknowledging viz a viz WS use behind the firewall). That same method also tells us which other styles do (ones that adopt interface constraints, of which REST is just one example). This whole debate is not much more complicated than that.

I just thought that worth replicating here. Of course, that extraordinary cost I referred to has already been born out over the past few years by Web services ISVs, their customers, and others, so there should be an abundance of evidence for Mike.

Tags: soap, soa, rest, softwarearchitecture, webservices.

As if on queue, the Zapthink guys release a report which shows that they’ve been paying attention;

Since the Web plays such a large role for SMBs in their use of Web Services, it makes sense that many of them use the cheapest, simplest approach available for implementing B2B Web Services interactions. Using approaches such as Representational State Transfer (REST) gives companies a simple, straightforward HTTP-based approach to Web Services-based integration that is adequate for the needs of many SMBs.

and …

Many SMBs have been leveraging Web Services to reduce the cost of older approaches to addressing their external integration needs. The simple addition of Web Services interfaces, however, typically remain as inflexible as the API approaches that came before. Only through the application of SOA can midsize firms build and leverage loosely coupled Web Services that are flexible enough to respond to ongoing change in the business environment.

I really like that second last sentence, where they’re saying, no, SOA does not encompass all forms of service. And though they don’t explicitly state what they do think SOA entails, it’s made clear that their interpretation of SOA does not include “the simple addition of Web Services interfaces”, which seems to mean that they include some sort of interface constraint.

Some of those snippets are taken somewhat out of context; as you’d expect, there’s a bit of the “SOAP is for heavy lifting” stuff in there too. But still, from these historically foaming-at-the-mouth WS/SOA types (kidding guys! 8-), some good stuff.

Tags: soa, rest, web, webservices.

Sage advice from Patrick Logan;

Simple dynamic programming languages and simple dynamic coordination languages are winning. Vendors will have to differentiate themselves on something more than wizards that mask complexity.

On the upside, when most every other vendor is hocking snake oil, differentiation from those vendors isn’t hard. On the downside, as Patrick points out, mature products like Apache are the competition.

Of course, there’s always many ways forward. Fair competition being one (build a better Web-server/CMS/router/whatever..), subversion, another. But lots of other possibilities in between.

I’m also reminded of a prediction I made about three years ago;

By the end of 2005, IBM’s content management software division will have absorbed their enterprise software group

Ok, so my timing’s off (as usual), but the message seems even more pertinent after the recent discussions; content management is enterprise integration.

Tags: soa, rest, web, webservices.

Now don’t get me wrong, I do appreciate the bevy of pro – or at least neutral – REST commentary in the recent discussion. But I just can’t get excited about the “moderate” conclusions such as this from Dare Obasanjo;

If you know the target platform of the consumers of your service is going to be .NET or some other platform with rich WS-* support then you should use SOAP/WSDL/WS-*. On the other hand, if you can’t guarantee the target platform of your customers then you should build a Plain Old XML over HTTP (POX/HTTP) or REST web service.

I mean, that looks fine and dandy – as did Don’s conclusions – until you realize that the architectural properties of the resulting system aren’t a factor in the decision.

Oops! This is not progress. This is not principled design.

Tags: soap, soa, rest, webservices.