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'.
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