Spotted over in service-orientated-architecture , from Jeff Schneider;
Personally, I believe that inter-enterprise service catalog has been the biggest single failure of Web services. Not too long ago, I dumped the data from the UBR and wrote a program to test all of the services, 92% of all entries were fake or broken. Quintessential eh?
So remind me again, is 404 a bug or a feature? 8-)
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.
… has been posted.
In addition to my DevDay co-chairing duties, I’ll be part of a panel called – at least for now – “Web services considered harmful?” 8-). You’ll recognize all the participants, but I won’t name any yet since I’m not sure who’s confirmed. Rohit Khare will be moderating.
If you’re in Boston and interested in meeting up, let me know!
I’ll be seeing far too much of Boston over the next three weeks. I’ll be there on the 17th and 18th (departing on the evening of the 18th), as well as 27th through March 2nd (departing afternoon of the 3rd). I’m currently only booked up on the evening of the 27th, though I expect that one of the other evenings that week will be booked up too.
Gee, I can’t remember how long it’s been since I last saw James.
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;
Hint; there’s always an operation, since something has to succeed or fail.