MSDN Magazine - October 2007 - (Page 44)

much longer route of Document Object Model (DOM) scripting. Note that ASP.NET AJAX Extensions does not currently provide an object model for representing chunks of markup as controls. Flavors of Services In AJAX, a service indicates a piece of code that is resident on the domain of the application and exposes functionality to client script code. A service used in AJAX requires some designing to create an implementation that shields the real application’s back end and middle tier from direct interaction with the end user. Is such a service a WS-* Web service? Can it be a service-oriented architecture (SOA) service? The ideal service for AJAX applications is primarily concerned with exposing data and resources to Web clients. It is reachable over HTTP and requires that clients use URLs (and optionally HTTP headers) to access data and command operations. Clients interact with the service using HTTP verbs such as GET, POST, PUT, and DELETE. In other words, the URL represents a resource and the HTTP verb describes the action you want to take on the resource. Data exchanged in those interactions is represented in simple formats, such as JSON and plain XML, as well as in syndication formats such as RSS and ATOM. A service with these characteristics is a Representational State Transfer (REST) service. For more information on the definition of REST, you should read the original paper that describes the vision behind REST (available at ics.uci.edu/~fielding/pubs/dissertation/top.htm). monly used format, but others, such as plain XML and raw text, can also be used. JSON is a text-based format designed to move the state of an object across the tiers of an application. A JSON string can easily be evaluated to a JavaScript object through the familiar eval function. The JSON format describes the object, as shown here: {“ID”:”ALFKI”, “Company”:”Alfred Futterkiste”} The string indicates an object with two properties, ID and Company, and their respective, text-serialized values. If a property is assigned a non-primitive value, say a custom object, the value is recursively serialized to JSON, like so: { “ID”:”ALFKI”, “Company”:”Alfreds Futterkiste”, “Location”: “{“City”:”Berlin”, “Country”:”Germany”}”, } In the end, services used by AJAX applications tend not to use SOAP to communicate and are not necessarily autonomous services in the SOA sense. Instead, they are bound to the platform and the domain where they’re hosted. Based on this, they can hardly be called WS-* Web services or SOA services. In addition, these services make a point of not having public documentation or a discovery schema—unlike, Now that AJAX is changing for example, Web Services the Web, XML is being Description Language (WSDL) for WS-* Web pushed to the corner in services. This reduces the favor of JSON, as far as data number of dependencies representation is concerned. on the service and allows for more rapid evolution of the service code. All in all, the paradigm recommended for AJAX services is less ambitious than the paradigm behind Web and SOA services, but it’s still effective for the context in which it is intended to be used. Note that in the remainder of this column, I’ll use the expression “AJAX services” to indicate services used to implement the back end of an AJAX application using the script services approach. When processed with the eval function, JSON strings become an associative array—a sort of name/value collection—where each entry has a name and a value. If the JSON string is meant to represent the state of a custom object, say Customer, it’s your responsibility to ensure that the definition of the corresponding class is available on the client. In other words, the JavaScript’s eval function alone extracts information out of the JSON string to a generic container. If you need such information to be exposed as a custom object, say a Customer object, the task of providing the class definition and loading data into it is entirely up to you or the framework you use. For more information on the syntax and purposes of JSON, have a look at www.json.org. JSON Versus XML For years, XML has been touted as the lingua franca of the Web. Now that AJAX is changing the Web as we know it, XML is being pushed to the corner in favor of JSON, as far as data representation is concerned. JSON is slightly simpler and more appropriate for use with the JavaScript language. While you can argue over which is easier to understand for humans, JSON is certainly easier than XML for a Web browser to process. With JSON, you don’t need anything like an XML parser. Everything you need in order to parse the text is built right into the JavaScript language. Because JSON is much less ambitious than XML, it is also less verbose. That’s not to say JSON is perfect; the vast quantity of commas and quotes JSON requires makes it a rather quirky format. With JSON you also gain a key architectural benefit at a relatively low cost. You reason in terms of objects everywhere. On the server, you define your entities and implement them as classes in your favorite managed language. When a service method needs to return an instance of any class, the state of the object is serialized to JSON and travels over the wire. On the client, the JSON string is received and processed and its contents are loaded into an array or a kind of mirror JavaScript object with the same interface as the server class. The interface of the class is inferred from the JSON stream. In this way, both the service and the client page code use the same logical definition of an entity. What Do AJAX Services Return? Since AJAX services are exposed exclusively through HTTP, you can use virtually any text format to pack the body of requests and responses. JavaScript Object Notation (JSON) is the most com44 msdnmagazine Cutting Edge http://ics.uci.edu/~fielding/pubs/dissertation/top.htm http://ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.json.org

Table of Contents Feed for the Digital Edition of MSDN Magazine - October 2007

Cover Contents Toolbox CLR Inside Out Basic Instincts Data Points Cutting Edge Pooled Threads WPF Threads Parallel Linq Parallel Performance Mobile Apps Test Run Foundations Windows with C++ Netting C++ .NET Matters { End Bracket } Net Nuptials

MSDN Magazine - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.