For our example Web services, we'll be loosely adhering to the REST principle and creating Web services that are addressable through the service's Uniform Resource Identifier (URI).

The beauty of Web services being platform-agnostic is that we can use any language to develop them - although there are features to watch for when choosing a language. While a Web service can return data in any format, the title of this chapter is 'Building AJAX-Friendly Web Services' and our examples will be returning XML or JSON. In keeping with that philosophy we'll look at languages with inherent XML support or a JSON library.

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.

When developers first realize what an AJAX client can do, they are often especially excited about its potential in playing the role of the View or even the Controller in the Model-View-Controller (MVC) patterns of application development, with Web services providing the Model layer. If you're unfamiliar with the term, MVC is a paradigm used by software developers to design user interface code (the View) that is decoupled from the data objects it displays (the Model). Rather than letting the View code directly manipulate the Model's data, the MVC pattern introduces a third party known as the Controller.

In the MainPage-9.html, we add a new link called 'Save' in the top toolbar. It's used to save the changes made by the user using an AJAX request.

Note in the 'setData' method of the SimpleTable, the following code. The code to add 'cellClicked' as an 'onclick' listener to each cell. The ID attribute of each attribute is set so that we can parse it to retrieve the row and column of the cell.

In the previous sections, we've discussed the HTML template and a component class called 'NavBar.' Next we'll discuss more templates and the component classes that are bound to the application data. But before that, we'll discuss how the data is converted to the internal form. The XML document received by the client is converted to the JavaScript object tree. The XMLToDataSet class is responsible for the conversion.

Refer to TopNavBar.html. This is a pure HTML document. It's created to act as a template for the navigation bar. Note the 'id' assigned to each anchor element. The screenshot of the navigation bar template is shown below.

Let's look at the source code organization in our sample application. It's important from two perspectives: a) it would be useful in browsing the sample code described in the following sections; and b) the directory structure helps visualize the structure of the pages. We use the directory structure below for source code organization.

JSP, JSF, special tags, configuration files, and tld files are all replaced by client-side HTML templates, components, and controllers. We only need a controller servlet on the server side.

When the user makes changes to the data, all the changes can be recorded locally up to some point or sent to the server immediately. It depends on the application situation. In a typical application, there are certain changes that are buffered until the user selects an operation to indicate 'save.'

The controller servlet orchestrates interaction between the client- and server-side components that serve as the real data sources or service providers. The client uses XML messages to send details of server invocations. The controller servlet interprets the XML messages and delegates calls to actual services. It might have to transform these XML messages to different protocols based on what's supported by each service.

We've seen how widgets can be developed on the browser/desktop. The same code can be used to develop a widget for a mobile device. The key difference between the browser and the mobile application is the use of the Opera Platform for mobile widget development.

In the previous section, we laid out the design considerations for mobile Web applications as recommended by the W3C. Here we'll discuss AJAX-specific considerations.

Having discussed the resurgence of browser-based applications and the significance of AJAX widgets on mobile devices, we'll turn to the design of AJAX applications/widgets.

Until AJAX came along, it wasn't easy to replicate the rich and responsive interaction design of native applications. AJAX is different from other previous attempts to address this problem since it's based on existing non-proprietary standards that are already familiar to developers.

Content owners include players like broadcasters (TV and radio), news agencies, publishers, entertainment companies (movies, music, and entertainment), and rights owner companies (music rights, sports rights, and general showbiz agents). Unlike the Internet, the general perception of the mobile Internet is that content isn't free. Content owners own the rights or represent copyright owners. Content owners believe that 'Content is king.'

Globally, at end of 2005, there were 2.1 billion mobile phones versus a billion Internet users. Among those billion Internet users over 200 million of them accessed the Internet via a mobile phone, mostly in Japan, China, and South Korea. So the sheer number of mobile phones, especially in developing countries and Asia, coupled with the growing technical capacity of mobile phones makes what we say here significant.

With the above feed service, incredible possibilities are opened up for the XInclude component discussed earlier. In essence, the XInclude component becomes a newsfeed reader, displaying the contents of the newsfeed either as a list of numbered entries or showing just one 'page' of that feed. Note that the contents here are just the summaries of the pages, not (in general) the pages themselves unless the newsfeeds actually are used to transmit the entire content.

The Web client cannot, in the traditional role of things, provide Web content. Of course, that's not quite true - form content sent to the server either directly via a form post submission, or via an XMLHttpRequest object, are very definitely content being 'served' to the server. The difference here is that the server is a passive entity - it can only send information when it gets a request from a client, while the client is increasingly able to do both. Even that definition begins to break down when you consider that the server can make requests from other servers for content.

The XInclude Binding serves as a good example showcasing how such bindings can be created. If you are familiar with XBL bindings, the one aspect that is missing in the JavaScript version is the use of a specific template. This can be readily overcome within the constructor, especially since, unlike the formally defined binding languages, this approach does not create 'shadow trees,' which are somehow distinct from the rest of the DOM.

In Mozilla, the XBL binding language (an XML language) is used to associate bindings with their respective elements, with these tied in via CSS. Unfortunately, there are no clean hooks for adding a binding in this way for Opera (and a different mechanism for handling it in Internet Explorer).

The first thing that may strike you as you're looking at this code is the fact that there is no inline scripting; the page as given is entirely XML driven. The presentation was handled by a simple CSS file included in the style block (which could have also been handled by a element) (jsbinding.css)

The use of JavaScript as a scripting language has emerged primarily in response to this largely monolithic approach to extensions and components. Similarly, the use of the HTML (and later, XML) DOM provided the hooks by which each particular tag could be treated as its own internal component. This approach, the finite set approach, has meant that so long as the underlying browser implementation has support for a given feature, one can create more elaborate structures that essentially built upon this fixed set. Much of the existing AJAX methodology is ultimately built around this particular view of Web programming.

Over the last year, the term mashup has gained a certain degree of currency, the implication of course being that Web programming has entered a phase in which you could take a mapping routine from over here, a set of libraries from over there, perhaps a Web service or two from somewhere else and before you know it you're able to create a Web application that will show you the present and likely future positions of Bigfoot as he (presumably he) pursues bikini-clad Swedish models (okay, I may be spending just a wee bit too much time watching Canadian television, but the idea is sound).

Every so often a new way of developing software comes along, a different approach in design methodology that takes advantage of recent advances in technology to more effectively create applications. Typically, the first efforts to use the technology is to try to build things that are similar to older technologies. But over time, the possibilities opened up by that technology open up new design methodologies and a new understanding of what the technology is capable of doing.

The object notation used by JavaScript has made its way into a way to transmit structure better in a number of different languages. JSON (JavaScript Object Notation) has gained a fair amount of interest as a somewhat lighter-weight alternative to XML, especially when used across pipes for AJAX transmission.

The flip side of parsing is serialization, which, in the loosest sense, is the conversion of an object from an internal representation to some (possibly text) format that can be reloaded in the future.

Parsing and serialization were touched on briefly in the discussion of innerHTML, but both issues deserve more extensive coverage. A significant amount of work with AJAX-based systems involves converting strings of XML text into some form of DOM representation, a process formally known as XML parsing, or the reverse process of converting the DOM representation back to text, known formally as XML serialization.

One advantage comes from learning to work with JavaScript code asynchronously - it makes explaining the XMLHttpRequest object, arguably the cornerstone of AJAX, much easier.

This approach, while simple, has a couple of major problems that makes it less than perfect for library functions. One of the first is the fact that the setInterval() and setTimeout methods may be invoked even after a page (or the browser) is closed.

For a long time user interface development has gotten something of a bum rap with the programming community, in great part because such programming usually doesn't involve high-performance computing, complex mathematical algorithms, or the manipulation of large sets of data.

Up to this point, the discussion has focused on JavaScript exclusively. However, it's reasonable to assume that if you're involved in AJAX development, you'll almost certainly be working in the context of an HTML or XHTML page.

There's an interesting phenomenon going on right now. Several of the critical technologies used by AJAX first appeared in Microsoft's Internet Explorer, which still has a large (though diminishing) market share according to most statistics.

Regular expressions (or Regexes, as they are sometimes called) provide a way of defining text patterns that can be used for validation, testing, and string replacement.

Strings, like arrays, are objects, though because of their ubiquity and the way they're declared, it's sometimes easy to lose sight of this. Strings can be created either by using the String() object or via the single or double quotes

Objects (and object functions) are remarkably useful things, but there are times when all you're really concerned about is a list of items. List manipulation can be found at the heart of any number of sophisticated languages so it's probably not surprising to discover that JavaScript actually has quite a powerful toolset of array capabilities.

The function is one of the most fundamental blocks in any language, but in JavaScript the function is in many respects far more powerful and pervasive than it is in nearly any other language. Indeed, the degree to which you can work with functions in JavaScript begins to approach what can be done in languages such as LISP, Haskell, Prolog, and other 'functional' languages.

Objects are possibly an odd place to start when talking about JavaScript, but if you understand exactly how JavaScript handles objects, you'll have one of the most powerful tools possible for working with AJAX-based components.

Learning JavaScript can be a pain, largely because in most cases you're either limited to working in the browser's command line or building JavaScript in script blocks and leaning heavily on the refresh button in a browser. While JavaScript command-line environments are available, one of the more useful is an extension to the Firefox browser.