Internet Alchemy

However, the insidious thing is that the failure wasn’t because their application was improperly coded to fail if it saw a fruit it didn’t know, it was because the platform they built on was statically typed. Specifically, the Web Services platform automatically converted the XML to objects by looking at our WSDL file (i.e. the interface definition language which stated up front which types are returned by our service) . So this meant that any time new types were added to our service, our WSDL file would be updated and any application invoking our service which was built on a Web services platform that performed such XML<->object mapping and was statically typed would need to be recompiled. Yes, recompiled.

Classic!

It’s clearly SOAP-beating day. Here’s Nelson Minar’s view:

The deeper problem with SOAP is strong typing. WSDL accomplishes its magic via XML Schema and strongly typed messages. But strong typing is a bad choice for loosely coupled distributed systems. The moment you need to change anything, the type signature changes and all the clients that were built to your earlier protocol spec break. And I don’t just mean major semantic changes break things, but cosmetic things like accepting a 64 bit int where you use used to only accept 32 bit ints, or making a parameter optional. SOAP, in practice, is incredibly brittle. If you’re building a web service for the world to use, you need to make it flexible and loose and a bit sloppy. Strong typing is the wrong choice.

via Tim Bray

If you haven’t seen Pete Lacey’s socratic dialogue on the evolution of SOAP then please go and read it straight away. An excerpt to whet your whistle:

Dev: Okay, where’s the spec on this?

SG: Oh, there is no spec. This is just what Microsoft seems to be doing. Looked like a good idea, so now all the cool kids are doing it. However, there is this new thing. I think you’re gonna like it. It’s called the Web Services Interoperability Group, or the WS-I. What they’re doing is trying to remove a lot of the ambiguity in the SOAP and WSDL specs. I know how you like specs.

Dev: So, in other words, the specs were so bad you need a standards body to standardize the standards. Lord. Well, will this solve my interoperability problems?

SG: Oh, yeah. So long as you use a WS-I compliant SOAP stack, avoid using 8/10ths of XML Schema, don’t use any unusual data types, and don’t count on working with WebSphere and Apache Axis.

There must be something in the air because Duncan Cragg has also written some fun and informative articles in the same style for a new series called the REST dialogues: Getting Data and Setting Data. If you want to get a better view of what it means to be resource-oriented then this series looks to be the business.

Blogging here is going to be a bit light for a while. I’ve started blogging more regularly on a new Talis group blog: Nodalities. Recent postings:

• The Right Tool – if you’re a medium level organisation, not too small and not too large and you don’t deal with the public over the Internet then the 60+ specifications of the WS-* stack would appear to be suitable for you
• Atom Support – syndicating changesets over Atom gives us a lightweight and web-friendly synchronisation mechanism for data stores.
• Web of Data – fostering of a web of data built on the foundations of the document-oriented web that we have today

Technorati Tags: nodalities, talis, webservices, rdf, atom

Sometime you need to make extreme statements to make a subtle point clearer:

It doesn’t matter how easy it is in [awesome VisualStudio/RubyOnRails/Python/IntellijIDEA]. It has to be easy in COBOL.

Robert Sayre on the permathread that is REST vs WS-*

This piece from Dare Obasanjo hot on the heels of the UDDI public registry closure adds weight to my suspicion that SOAP is finally being sidelined into a niche activity.

When I worked on the XML team, I used to interact regularly with the Indigo folks. At the time, I got the impression that they had two clear goals (i) build the world’s best Web services framework built on SOAP & WS-* and (ii) unify the diverse distributed computing offerings produced by Microsoft. As I spent time on my new job I realized that the first goal of Indigo folks didn’t jibe with the reality of how we built services. Despite how much various evangelists and marketing folks have tried to make it seem otherwise, SOAP based Web services aren’t the only Web service on the planet. Technically they aren’t even the most popular. If anything the most popular Web services is RSS which for all intents and purposes is a RESTful Web service. Today, across our division we have services that talk SOAP, RSS, JSON, XML-RPC and even WebDAV. The probability of all of these services being replaced by SOAP-based services is 0.

Peter Rip writes on Enterprise Web 2.0:

Today’s Enterprise IT budgets continue to be largely defined by the consolidation happening in the legacy software businesses. Over the next 24 months I think we will see are a lot of IT folks doing heavy lifting with legacy apps by day and playing with lightweight Web 2.0 technologies by night. The innovation at the edge is going to wash into the Enterprise. And when it does, we’re going to see IT Departments finally see a platform shift worth making. The potential losers are the legacy vendors with their ’software mainframes.’ The winners will be the companies that package componentized functionality with light, maybe even non-procedural, methods of stitching together flexible Web applications quickly.

Too right! It’s going to happen from the outside in and it’s going to be grounded in the Web. This is exactly the thinking that’s happening at Talis, specifically around our Silkworm project where we’re bringing together all kinds of components to create a genuinely new type of development platform.

Mark Nottingham characterises the old REST vs SOAP debate in a different way. Now it’s SOAP vs. HTTP:

you can get any of the listed architectural styles [SOA, RPC, REST] with both SOAP and HTTP.

…[useful table - go see it!]…

When doing so, notice that REST is native in HTTP, and SOAP is native for SOA. Intuitively, I’d rather use HTTP if my chosen architectural style were REST, especially considering how widely deployed and provably interoperable it is. I can choose any number of off-the-shelf, commercial or Open Source intermediaries, caches and libraries to take advantage of REST in HTTP, but the same is not true of REST in SOAP.

My takeaway is: use HTTP if you’re doing REST (document based), use SOAP if you want SOA (message based).

Alex Bosworth on why Search engine APIs are failing:

Talking to Google engineers, I was informed that Google thinks of their 3rd party API program as a complete failure and only a couple people have made anything vaguely useful from it. The reason why is they have no real committment to making these programs work. For example their terms and conditions are so draconian and laden with legalese there is no motive for developers to work with them.

I’ve been collecting webapp APIs. Here’s what I have so far. I’m bound to have missed some. Drop me a line or leave a comment if you know of any others.

• Yahoo!
• Flickr
• 43 Things
• Bloglines
• Upcoming.org
• eBay
• Webjay
• Typepad Atom API
• Audioscrobbler
• A9
• Amazon
• Feedmap
• Simpy
• hostip
• Backpack
• del.icio.us
• Google search
• Google adwords

Oh, and if you think the links look odd, I’m also experimenting with my own tagging webapp.