Monday, 16 July 2007

Microsoft admits: "Xml isn't everything"

With Xml, Serialization and Web Services baked into the first .NET Framework at a time that the Java world only had fairly rudimentary optional add-ons, it seemed like Microsoft was 'finally embracing an open standard' ahead of the curve... Xml has continued to become a cornerstone of .NET and Office (and BizTalk, and SharePoint, and...) ever since.

The "problem" with Xml is the growing 'weight' of Xml implementing even a basic solution "properly" - namespaces, XSD, WSDL, SOAP, WS-* standards, etc. It's no longer just a simple case of throwing a few tags together to get something done.

While Microsoft continued down the Xml-and-WS-in-.NET road, others (the Ruby community, for a start) popularised Representational State Transfer (REST Web Services).

It's light-weight and much easier to use with AJAX and other RIAs, in part because it's not Xml-centric but open to simpler 'data syntax' such as JSON. JSON slots seemlessly into browser script interpreters without pesky translations or reliability on XmlHttp implementations, so the cross-browser/standards crowd cottoned on quickly. Even 3rd party Microsoft solutions like Ajax.NET Pro used JSON.

Which brings us back to Microsoft, who appear to have 'got the message'.

MSDN recently featured an Introduction to JavaScript Object Notation (JSON) in JavaScript and .NET, comparing JSON to XML, and then subsequently released Astoria at Mix07 (an announcement likely overshadowed by the release of Silverlight).

Astoria enable(s) applications to expose data as a data service that can be consumed by web clients within corporate networks and across the internet. The data service is reachable over regular HTTP requests, and standard HTTP verbs such as GET, POST, PUT and DELETE are used to perform operations against the service.
The payload format for the service is controllable by the application, but all options are simple, open formats such as plan XML and JSON.
The use of web-friendly technologies make it ideal as a data back-end for AJAX-style applications, Rich Interactive Applications and other applications that need to operate against data that is across the web.

Compare the request format
http://astoria.sandbox.live.com/encarta/encarta.rse/Articles[Title%20eq%20'Aerobics']?$expand=RelatedArticles to a comparable SOAP-formatted request... and if it wasn't disabled by default, you'd get JSON back instead with http://astoria.sandbox.live.com/encarta/encarta.rse/Articles[Title%20eq%20'Aerobics']?$expand=RelatedArticles&$format=json

For now Astoria is an alpha/beta to help us become familiar with the concepts behind it. It is (apparently) based on Windows Communication Foundation (.NET 3.0), so it may not end-up being as 'light' as you think.

Would/could/should you base your SOA on REST/JSON, or stick with XML/SOAP? The answer may be in O'Reilly's RESTful Web Services, but then there's no substitute for trying it out yourself... your application's authorization, authentication, topology, scalability, complexity, distribution, platform, usergroup/s can only begin to guide you towards the right decision.

UPDATE: Came across these links after posting:
Will Web 2.0 displace the WS-* protocols?
The Merging of SOA and Web 2.0

2 comments:

  1. Don't you mean "SOAP isn't everything"? RESTful webservices are still based on XML.

    ReplyDelete
  2. Yeah - that is more accurate, or else "WS-* isn't everything" perhaps? Note that I hadn't read the OReilly book when I posted :)

    One of things I like about Astoria is the availability of JSON as a format - so _no_ XML at all - pure URI-addressability and browser-friendly responses.

    I'm trying to find the time to install the Astoria client for Silverlight 1.1 - but have high hopes for it.

    ReplyDelete