Regardless of whether you use web services to serve the XML or you use REST services, in either case the success of your project depends on how you design the interfaces to these services.
Before we can get down to the technical details, it's important to discuss what makes an AJAX application successful in the eyes of end users. There's no objective measure of how effective an AJAX UI is: as with any UI design, success is measured subjectively: do the end users "feel good" about using the UI.
If I were to summarize the most user visibile difference between AJAX and a regular web UI, it would be that a regular web UI is "click...wait...wait...refresh" whereas an AJAX UI avoids refreshing the whole page and gives the appearanceof near instantaneous response. Notice I used the phrase "gives the appearance of" not "gives". That caveat is the most important aspect of designing service interfaces for AJAX.
This is where we get into the subjective nature of UI design. For very simple things (e.g. hovering over a user name displays their email address), subjectivity and service interface design aren't big issues. But, as you get into using AJAX for more sophisticated UI's is where the subjectivity starts to play.
Let's me use an example. Let's say you want to display a purchase order with 200 line items. There are two ways you could do this:
Download the complete purchase order at once. So, to the end user this might appear as:
wait 8 seconds...
Download the purchase order in chuncks. So, to the end user this might appear as
...wait 1s until PO header and first line items appear on-screen
...see line items arriving over next 11 seconds.
In this example, the first approach (a traditional web approach) takes a total of 8 seconds and the second approach (an AJAX-like approach) takes a total of 12 seconds. Which would the user subjectively think is faster? 9.5 times out of 10 they will pick the second approach. The reason is that they see something happening within 1 second, even though everything is not done at that point. This allows them to start reading the information (i.e. being productive) while the rest is being loaded. So if you were to do objective measurements, you'd likely find that the AJAX UI also improves user productivity - but even if there was no measurable productivty gain, the users would "feel" more productive since they have less time spend waiting for something to appear.
So, the key to designing an effective interface for AJAX is to understand how to effectively chunk large documents, delivering them over a series of smaller, more frequent requests to the backend service (rather than as one big "all in one" document).
As a tie back to my previous blog entry, you'll see that it would make no difference whether you used synchronous or asynchronous messaging (or even sync/async programming model) if you didn't chunk effectively.
When designing a service interface for AJAX, you should think "what information does the user want to see first" then "what do they want to see next", down to "what might they rarely want to look at. In my purchase order example, the end user might never be interested in the bulk of the line items - so why load them. Instead the service could send the first 10 line items along with the total number of line items, and the AJAX application could retrieve other line items if it needed them. In fact, it might pre-fetch the next 10 in the background but not display them so that, if the user wanted to see them, it would be an instantaneous update (since they would already be at the web browser, just not yet displayed).
So, proper service interface design for AJAX means that, instead of defining your service as "retrieve everything as a single document" (as would be typical for web services), you need to have more granular (and faster) operations that can retrieve subsets of documents at a time. In many ways this goes counter to traditional "web service philosophy", but it's critical if you want to build AJAX applications that your end users like to use.
Of course, in the long, the last thing you want to do is code different service interfaces for different types of of consumers (e.g. other services versus AJAX consumers). So, in a follow-up I'll talk a bit about how you can design service interfaces that are effective both for AJAX and other consumers.