This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs for the special pre-order price, click here for more information. Aimed at everyone from enterprise developers to self-taught scripters, Real-World AJAX: Secrets of the Masters is the perfect book for anyone who wants to start developing AJAX applications.

Flavors of XML
Earlier we compared formatting payloads in JSON versus XML. One of the chief advantages of sticking with XML is that it can be validated, that is, that disparate systems can independently confirm that a given XML document is well-formed and complies with a particular schema. Schemas can be thought of as contracts that define the elements an XML document should contain and what constraints the elements and their values should be held to. Document Type Definitions (DTDs) are an older schema format that's losing favor among developers because of its lack of support of namespaces. Additionally, its successor, the XML Schema Definition (XSD), is well-formed XML and uses a far richer datatyping system.

Another of the chief advantages of sticking with XML is that most server-side languages will support it without needing any additional libraries, possibly without any additional processing at all. In fact, if the source data is already in some kind of XML-based language, another XML-based language known as Extensible Stylesheet Language Transformations (XSLTs) is probably all that will be needed. XSLT facilitates the translation of one flavor of XML to another.

XSLT works by transforming the source tree (from the source XML) into a result tree that can be serialized to the resulting XML document. It does so by applying a collection of template rules to the tree's nodes. These rules support conditional logic, sorting, looping, and expression matching. And while you may find yourself using XSLT on the server side to prepare XML payloads to return to XmlHttp requests, you should note that browsers increasingly support XSLT processing as well. In later versions of Internet Explorer, for instance, you'll use MSXML and in Firefox you'll use the XSLTProcesser class. Browser support of XSLT is limited, however, and is far from uniform or consistent. While libraries are available to facilitate more sophisticated transformations, you'll probably stick initially to navigating and manipulating an XML's DOM.

One other technology for getting at the data in your XML is XPath, which is analogous to SQL for querying relational databases. XPath consists of expressions that can be executed against an XML document to return matching nodes. Again, support for XPath varies widely across browsers.

Note that if you're doing any work with XML, Altova's XML Spy is the leading XML IDE available and has plug-ins for Microsoft Visual Studio.NET and recently the Eclipse platform: www.altova.com/features_eclipse.html.

POX, REST, SOAP, WS-*
As mentioned earlier, when first encountering and experimenting with AJAX patterns of Web development, developers often immediately think of the potential of a service-oriented architecture in which users might call services directly without an intermediate application server. The question of how the data returned from these services should be formatted is widely debated, with many arguing that nothing beats Plain Old XML (POX). POX is, well, just that: simple XML documents that aren't associated with schemas or multi-layered specifications like SOAP-based Web Services, XML-RPC, REST, or other XML Messaging specifications.

Another strategy that's gaining in popularity is Representational State Transfer (REST), a software architectural style that originated in a doctoral dissertation by Roy Fielding, one of the dominant figures in the HTTP specification. Unlike the more flexible but vastly more complicated abstraction layer of Remote Procedure Call (RPC)-styled Web Services, REST concentrates on well-defined operations like POST, GET, PUT, and DELETE – operations that are analogous to the Create, Read, Update, and Delete (CRUD) operations that developers use to persist data in a relational database between browser requests or sessions. In this paradigm, the objects of these operations are defined, to some extent, prior to the call. REST accomplishes this by specifying a universal syntax for the identification of resources, typically URLs. Requesting the GET operation from http://myHost.com/services/employees, for instance, might return a list of employees.

Another way to differentiate between REST and RPC-styled Web Services is that REST emphasizes the nouns while RPC concentrates on the verbs. In other words, an RPC application might expose a broad and possibly only casually consistent array of operations against objects such as getThisObject(), archiveThatObject(), authorizeSomeOtherObject(), and so on. In REST applications, the objects are already alluded to in the URLs and the operations are limited, but simple and consistent.

If you're looking for more than POX or REST, you're probably interested in doing actual Remote Procedure Calls and so are going to be looking at either XML-RPC or SOAP. XML-RPC, the lighter option of the two. An XML-RPC client can be written fairly easily and JavaScript libraries exist for their use in AJAX applications. XML-RPC uses XML to translate calls from one application to procedures on a remote application and accommodates basic calls that don't require passing objects or named parameters. XML-RPC will probably suffice for anything a browser is likely to do. See www.xmlrpc.com/directory/1568/implementations for a list of implementations.

Finally we look briefly at SOAP-based Web Services, which provide interoperability through open, XML-based and platform-agnostic standards. SOAP uses XML namespaces to define an envelope in which to wrap request and response data. So in your AJAX application, you might construct a SOAP message (possibly using functions from widely available JavaScript libraries) like the following, which requests the name of an employee with an ID of 367:

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
   <soap:Body>
     <getEmployee xmlns=”http://services.myHost.com/”>
         <employeeID>367</employeeID>
     </getEmployee>
   </soap:Body>
</soap:Envelope>

The host of this server would then process your SOAP request, looking it up in a database or some other routine that is irrelevant to you, returning a message like the following:

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
   <soap:Body>
     <getEmployeeResponse xmlns=”http://services.myHost.com/”>
       <getEmployeeResult>
         <name>
           <firstName>Ludwig</firstName>
           <lastName>Wittgenstein</lastName>
         </name>
       </getEmployeeResult>
     </getEmployeeResponse>
   </soap:Body>
</soap:Envelope>

How do you know what to put into the request envelope you send to the service? And how do you know what you're going to get back? You'll first want to consult the service's WSDL, which stands for Web Services Description Language. WSDLs tend to be pretty lengthy, so rather than show one here that might advertise the above operation, the reader is encouraged to look at some of the WSDLs on http://xmethods.net/, where the publicly available Web services on a wide variety of platforms can be explored and even interacted with in the browser via Mindreef's experimental Try It tools.

Because of the complexity and overhead of working with SOAP, the reader is encouraged to experiment with XML-RPC first, or even REST and POX. WS-I standards are still evolving, and with support for AJAX still evolving between browsers, it'll likely be a while before developers will easily be able to leverage them on their Web sites.

This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs, click here to order.