Although the term 'Ajax' was coined in 2005, most histories of the technologies that enable Ajax start a decade earlier with Microsoft's initiatives in developing Remote Scripting. However techniques for the asynchronous loading of content on an existing web page without requiring a full reload date back as far as the IFRAME element type (introduced in Internet Explorer 3 in 1996) and the LAYER element type (introduced in Netscape 4 in 1997, abandoned during early development of Mozilla). Both element types had a src attribute that could take any external URL, and by loading a page containing javascript that manipulated the parent page, Ajax-like effects could be attained.

Microsoft's Remote Scripting (or MSRS, introduced in 1998) acted as a more elegant replacement for these techniques, with data being pulled in by a Java applet which the client side could communicate with using JavaScript. This technique worked on both Internet Explorer version 4 and Netscape Navigator version 4 onwards. Microsoft took first advantage of these techniques in Outlook Web Access supplied with the Microsoft Exchange Server 2000 release.

The web development community, first collaborating via the microsoft.public.scripting.remote newsgroup and later through blog aggregation, subsequently developed a range of techniques for remote scripting in order to enable consistent results across different browsers. Early examples include JSRS library from 2000, the introduction of the Image/Cookie technique in 2000, and the JavaScript on Demand technique in 2002. In 2002, a user-community modification to Microsoft Remote Scripting was made to replace the Java applet with XMLHttpRequest.

Remote Scripting Frameworks such as ARSCIF surfaced in 2003 not long before Microsoft introduced Callbacks in ASP.NET.

Since XMLHttpRequest is now implemented across the majority of browsers in use, alternative techniques are used infrequently. However, they are still used where wide compatibility, small implementation, or cross-site access are required. One alternative, the SVGT protocol, employs a persistent connection for continuous exchange between browser and service.

Please see wikipedia.org for more information on AJax.

In computing, the term service-oriented architecture (SOA) expresses a perspective of software architecture that defines the use of loosely coupled software services to support the requirements of the business processes and software users. In an SOA environment, resources on a network[1] are made available as independent services that can be accessed without knowledge of their underlying platform implementation

A service-oriented architecture is not tied to a specific technology and may be implemented using a wide range of interoperability standards including RPC, DCOM, ORB or Web Services. SOA can be implemented without any of these protocols, and might, for example, use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces which can be called to perform their tasks in a standard way, without the service having pre-knowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.