While I wait for amazon to deliver RESTful Web Services, there's plenty to read on the web...
Jon Udell posts an interesting example of a RESTing transaction... seems to me there are very few 'example interactions' around to help people understand how REST is 'different', so it makes an interesting read.
If you prefer an explanation rather than a lot of reading, watch Pablo Castro introduce Astoria Data Services (pre-MIX) and at MIX "Accessing Data Services in the Cloud" (then subscribe to his blog about Astoria and Entity Framework stuff).
SOT: If, like me (after doing a bit of reading about REST and then JSON), you started to wonder if JSON isn't superior to Xml in many respects, you'll want to download JSON Viewer as you start to build applications with it.
P.S. How do you get a job like Pablo's?
Monday, 23 July 2007
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).
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
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
Tuesday, 10 July 2007
Synchronized dragging: Silverlight and Live Maps/Virtual Earth
Further to this post on Synchronizing Live Maps & Silverlight canvas, you can now pan by dragging rather than just using the rather clumsy up/down/left/right links: both the Silverlight Canvas containing the animation AND the underlying Microsoft Live Maps can be dragged (together)!
You can try out the demo of a Silverlight & Live Maps overlay with synchronized dragging to pan (it's not yet integrated into RaceReplay.net).
It was a relatively simple implementation of the sample code provided by then Silverlight Mouse Support documentation on MSDN. As with most Silverlight stuff, you can just View Source to see how it works...
Look out MapCruncher (joking!)
UPDATE: zooming now works too. When 'implementing' the Mouse Support example, I blindly copied
You can try out the demo of a Silverlight & Live Maps overlay with synchronized dragging to pan (it's not yet integrated into RaceReplay.net).
It was a relatively simple implementation of the sample code provided by then Silverlight Mouse Support documentation on MSDN. As with most Silverlight stuff, you can just View Source to see how it works...
Look out MapCruncher (joking!)
UPDATE: zooming now works too. When 'implementing' the Mouse Support example, I blindly copied
canvasT.X = canvasPixel.x;into onMouseUp(), forgetting that I was also updating
canvasT.Y = canvasPixel.y;
sender["Canvas.Left"] += currX - beginX;in onMouseMove(). Oops. Better to update that same property and avoid applying the 'transformation' twice...
sender["Canvas.Top"] += currY - beginY;
sender["Canvas.Left"] = canvasPixel.x;Also added a new cursor to indicate the map is 'draggable' - unfortunately Silverlight has a limited set of cursors to choose from, so the hand-pointing is used rather than open-hand.
sender["Canvas.Top"] = canvasPixel.y;
Wednesday, 4 July 2007
Thinq Linq
If your initial impressions of Linq are that it's mainly for data-access (because of the syntax similarities to SQL, and the availability of Linq to SQL), thinq again!
The Linq Cookbook (although in Visual Basic) demonstrates the sorts of problems you can now solve in a couple of lines of code:
If you do want to read more about Linq and SQL/data access, Explore LINQ, SQLMetal and SqlTac courtesy of Red-Gate.
The Linq Cookbook (although in Visual Basic) demonstrates the sorts of problems you can now solve in a couple of lines of code:
- Change the font for all labels on a windows form
- Find all capitalized words in a phrase and sort by length (then alphabetically)
- Find all complex types in a given assembly
- Find all the prime numbers in a given range
- Concatenating the selected strings from a CheckedListBox
If you do want to read more about Linq and SQL/data access, Explore LINQ, SQLMetal and SqlTac courtesy of Red-Gate.