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>"828ef3fdfa96f00ad9f27c383fc9ac7f"</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.
William Henry wrote a little piece called Poor Service Semantics where he criticizes uses of CORBA IDL that offer operations like “runIt” or “doIt”. He writes;
The problem with these is that the semantics are lost as to what the business actually is doing.
Rubbish! “what the business actually is doing” is determined by the implementation of the service. Do you want clients of your services to have dependencies upon those implementations? I thought not. We have a name for that practice, “tight coupling”.
submitPizzaOrder() tells you less about what the business is doing than submitPepperoniPizzaOrder(), but is it somehow less of business semantic as a result? No, of course not, it’s just more general. Likewise, submitOrder() is more general still, and submit() yet more general again … so general in fact that it can’t be generalized any further (i.e. it’s uniform).
doIt, runIt, submit, processMessage, or POST; whatever you want to call your “process this document” semantic, it’s most definitely a business operation, just a highly reusable one.
Tags: soa, rest, mest, webservices.
Don Box gives us his two cents on a Microsoft-internal “REST vs. SOA(P)” debate;
The following design decisions are orthogonal, even though people often conflate two or more of them:
- Whether one uses SOAP or POX (plain-old-XML).
- Whether or not one publishes an XML schema for their formats.
- Whether or not one generates static language bindings from an XML schema.
- The degree to which one relies on HTTP-specific features. That stated, screw with GET at your peril.
- Whether one adopts a message-centric design approach or a resource-centric design approach.
Some of the decisions (specifically 5) are architectural and sometimes philosophical.
I don’t know about that. Numbers 1, 2, 4, and 5 are architectural, as all impact either the components, connectors, or data of the system. Only number 3 isn’t, since it’s an implementation detail. Number 2 is debateable I suppose, but most Web services based uses of XML schemas I’ve seen involves removing descriptive information from the message in deference to an implicit pointer to a WSDL document (and therefore a schema).
He also added;
If you want to reach both audiences before your competition does, you’ll avoid indulging in religious debates and ship something.
Of course, religious debates should always be avoided. But architectural debates should not, and REST vs. SOA(P) is an architectural debate. Period. If anybody thinks this is a religious debate, you simply haven’t done your homework.
Also of interest, his advice was preceded by this qualifier;
In hopes I never have to address this debate again, […]
Hah, that’s a good one 8-) Resistance is futile. You can’t fight loose coupling, man. It’s infectious. Muhaha!
Tags: soap, rest, microsoft, webservices.
I started writing this before Jeff’s hilarious Lego piece (that must have been fun to put together 8-), but if anything, it just re-emphasized the need for me to write this, because Jeff makes the same mistake that most of the rest of the industry is making; believing that the SOAP processing model is the analogue of the Lego brick.
For an apples-to-apples comparison of SOA and Lego, one needs to realize that the analogue of the Lego brick is actually the WSDL document that describes the service. Lego works as it does because each brick exposes the same application interface, not just because each brick is made from the same plastic (which makes a better SOAP analogue, IMO).
Just check out his example of a non-recombinant system here; it’s not recombinant because it’s topped off with a piece which exposes a different “WSDL” than other “services”.
Jeff says a lot of valuable things in his piece that resonate with me, including;
The fundamental notion is that the true uses of the functions/data will not be known until after the system is put into production.
The future of software is about the creation and utilization of building blocks. It is about letting our users play with their Lego’s.
(modulo the fact that the plural of Lego is not “Legos” 8-)
… it’s just unfortunate that they all resonate with me from a Web/REST POV, not from an SOA POV.
