There's a bit of a debate going on about whether Ajax can properly co-exist with web services in service-oriented architectures.  Why not?  Michael Meehan's excellent article mentions that while Ajax isn't a great arranged marriage for SOA, they can work very well together (think peanut butter and chocolate).  Others argue that XMLHTTP isn't new and as such serves to be a square peg in modern abstracted, message-centric service development - putting too much emphasis on presentation-layer cosmetics and therefore sitting outside the scope of true SOA.  Also:

"According to a recent Forrester Research Inc. report, cascading style sheets, the DynamicHTML Document Object Model and a client-side JavaScript engine that decides when to call the server for backup helps to make Ajax user interfaces faster, more responsive and partially immune to connection losses. Ajax also lightens the server load and doesn't require downloads for rich content."

I'm not so sure if I fully agree with the last sentence - yes, Ajax-style remote script invocation doesn't force a ton of data to load on a single viewable page (and can/should it?) and enhances the user's experience in eliminating the annoying wait (in my opinion, if you're bringing down so much data that you need to periodically flush output, it's probably too much anyway).  But with JavaScript today throwing errors for "remote" scripts not existing on the same host as the calling page using XMLHTTP, the load for the server is actually doubled, in having to call, process and return a response from at least two pages (local and remote), and even more so in cases when remote scripts are called to handle rapid-fire events like OnKeyUp, like in Google Suggest.  The interactivity is more pleasant, but I'm not so sure performance is done any more efficiently.

"Yet the report notes that Ajax is not without its flaws either...the hype about Ajax is unfortunately overblown: Technical limitations, missing standards and narrow applicability make it more like a different flavor of Java applets than a complete Web revolution," the report found."

Agreed.  There's a lot of natural interest in the platform by developers (including much by yours truly) just because it's the new kid on the block and it's a new and interesting way to do things.  My biggest concern at the moment is trying to incorporate best-practice Ajax-style programming into data access, SOA, web services, and other aspects, such that using it won't be counterproductive and actually hurt my stuff.  We don't really have a good frame of reference of what works and in what capacity at the moment.  Vendor implementations of Ajax will certainly take care of that.  But why try and fit a Ferrari engine into a Camry?

Michael Mahemoff likened the Ajax hype in his must-download Ajax podcast to Java applets and Flash - noting how both of the latter never quite lived up to their billing due to poor implementation, failed promises, superior alternatives and bad timing.  But he mentions that with community-driven support from blogs, podcasts, and mainstream media push, the moment is right for Ajax to really become something effecitve, not just special and gimmicky.