So, what do AJAX and SOA have in common? The answer: Everything.

Is AJAX an enterprise technology? The answer: Absolutely.

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

AJAX is becoming the standard dynamic interface for the Web. It adds value to SOA as well, providing the core-enabling technology for user interaction no matter whether we're dealing with applications that are remotely hosted or local to the enterprise.

In essence, AJAX provides better edge technology for SOAs, or the top layer of technology dealing with the user interface. See, AJAX can extend visual service to a true interactive dynamic interface that's more attractive and functional for the end user.

The benefits of AJAX to the enterprise are clear and include:

The ability to leverage the same interface technology whether you're dealing with local or remote sites or applications. What's key about AJAX is that many enterprises can agree that it's the standard interface technology and, as such, standardize on it as a common platform-agnostic user interface. It doesn't matters if the AJAX interface is delivered on Windows, Linux, or the Mac. This makes deploying service-oriented enterprise applications that much easier, avoiding platform localization and testing issues.

The ability to leverage Web Services using a more dynamic and rich interface than traditional browser technology. While a browser is functional for Web-based applications, the lack of interactive and dynamic behavior limits its use in the enterprise. AJAX doesn't use the same "pump and pull" model that traditional HTTP-driven browser-based applications leverage. AJAX provides native-like application interfaces and performance, functioning as good as or better than native interface APIs, such as Win32.

The ability to create mashups to solve specific business problems quickly using standard dynamic interfaces that front services. Mashups are powerful ways of taking existing applications and services and creating something even more useful. AJAX provides better enabling technology to facilitate creating mashups and combining dynamic applications into a single interface with additional binding logic. Using this paradigm, enterprises can quickly create such useful mashups as integrating Google Maps with their delivery system.

The Emergence of the Rich Client for SOA and the Enterprise
Considering the architectural discussion above, as we look to make more practical use of Web Services, the need has emerged for a better user interface; one that's neither too fat nor too thin. We need an interface that lets developers make the most of the client's native features, while, at the same time, not bogging the client down with services that are better kept at the backend. We call this new hybrid interface a Rich Client and AJAX is an instance of rich client-enabling technology.

However, let's back up a bit. A rich client is a small piece of software that runs on the client to leverage and aggregate backend Web Services, letting them appear like a single, unified native application. Indeed, a new interface is needed as both developers and end users begin to understand the limitations of traditional Web-based interfaces that are the current interface-of-choice for many distributed applications. Figure 1, for instance, is a rich client interface embedded in Salesforce.com for application integration services. Notice how it supports drag-and-drop and the click-and-drag interface process. Impossible with traditional HTTP approaches to application development.

Why a rich client when deploying interfaces in enterprises? Truth be told, Web interfaces, widely used in enterprises, were never really designed to support true interactive applications. The Web was built as a content provider, serving up documents and not dynamic application services. If you think about it, you're reloading document after document to simulate an interactive application and always have to go to the backend Web server to ask for new content. Very little occurs at the client.

As the Web became popular and we looked to support business applications in the enterprise using the Web interface, we began to create new mechanisms to deliver dynamic content including dynamic HTTP/HTML pushers (e.g., CGI, ASAPI, and ISAPI) and new browsers that supported complex dynamic behavior. We're at such an advanced state today that entire enterprises run most of their relevant business applications using Web interfaces.

However, with the advent of Web Services and SOA, and the need to leverage dynamic behavior within the interfaces, traditional browsers fall way short. Their get/push model for driving interfaces isn't well suited to SOAs, which are - in essence - remote functions and are better suited to more visually rich types of interfaces, such as the more traditional GUI client/server interfaces popular a few years ago.

Rich clients are not a revolution, but an evolution of technology, including AJAX. Today we look to leverage dynamic behavior and deliver that experience directly to the end user, aggregating Web Services in an interface that appears as much like a native application as possible.

As said above, rich clients employing AJAX provide capabilities that thin clients can provide, including windowing features and data navigation control such as buttons, checkboxes, radio buttons, toggles, and palettes. They can also integrate content, communications, and platform-independent application interfaces for distribution through emerging SOAs. The rich client using AJAX becomes a Web Services/SOA terminal of sorts, letting applications communicate and even execute on one another in a distributed environment.

This is great news for those who are developing Web Services or implementing an SOA. With rich clients suddenly those services have a much higher value. Indeed, you can mix-and-match services in a rich client to create some very valuable applications. Perhaps, someday, the use of static and dynamic HTML and heavyweight protocols such as HTTP won't be the primary way we view distributed applications. Rich clients let us view applications that look and act like native client programs, even running remotely. That would be step in the right direction and the reason AJAX is so important to SOA.

So What's an SOA and Where Does AJAX Fit?
SOAs are like snowflakes...no two are alike. Moreover, everyone has their own definition of an SOA including everything from messaging systems to portals. However, many common patterns are beginning to emerge.

First, let me put forth my definition of SOA so we're working from the same foundation before we figure out where AJAX fits.

To me an SOA is a strategic framework of technology that lets all interested systems, inside and outside an organization, expose and access well-defined services, and information bound to those service, that may be further abstracted to orchestration layers, composite applications, and interfaces for solution development.

Pay special attention to the interfaces part.

So, why do we build SOAs? The primary benefits of an SOA include:

1. Reuse of services/behaviors or the ability to leverage application behavior from application-to-application without a significant amount of re-coding or integration. In other words, the ability to use the same application functionality (behavior) over and over again without having to port the code...leveraging remote application behavior as if it existed locally.
2. Agility or the ability to change business processes on top of existing services and information flows quickly and as needed to support a changing business. Overall, the consensus is that agility is more valuable than re-use.
3. Monitoring or the ability to monitor points of information and points of service in real-time to determine the well being of an enterprise or trading community. Moreover, the ability to change or adjust processes for the benefit of the organization in real-time.
4. Extend the reach or the ability to expose certain enterprise processes to other external entities for the purpose of inter-enterprise collaboration or shared processes. This is, in essence, next-generation supply chain integration.
5. The ability to put dynamic interfaces on both abstract data and services, letting the architect place volatility in a single domain between the services and the interface. This is where AJAX adds a tremendous amount of value.

What's unique about an SOA is that it's as much a strategy as a set of technologies, and it's really more of a journey than a destination. Moreover, it's a notion that's dependent on specific technologies or standards such as Web Services and interface technology such as AJAX but really requires many different kinds of technologies and standards for a complete SOA. The kinds of technologies you employ are dependent on your requirements. As mentioned above, all SOAs are a bit different; sometimes very different.

So, let's be a bit clearer as to where AJAX fits in this SOA mix by providing core reference architecture or the basics of SOA. Figure 2 is a diagram the SOA logical architecture, working from the most primitive to the most sophisticated, from the top to the bottom.

Base Services
At the lowest level you have base services, including legacy services, new services, and data services.

Legacy services, such as existing mainframe or ERP systems, can expose services typically through proprietary interfaces such as LU6.2 ACCP, or SAP's BAPI. These services usually provide both behavior and information bound to that behavior. In other words, there is functionality and structure.

New services are those services created from the ground up as services. These services have behavior as well as information bound to the behavior, but are built from scratch as services, so there's not much further abstraction required (see next level up). They are typically Web Services, but don't have to be as a rule.

Data services, as the name implies, are databases, data files, or other data stores that can produce and consume data. They support some behavior, but just enough to manage the data interaction services.