AJAX has set the world on fire when you're considering creating a Web-delivered dynamic application, or what many call a RIA (rich internet application). With AJAX World occurring this week (which I'm not attending by the way), I figured it's time to look at the links between AJAX and SOA once again…drilling down a bit deeper this time. We use AJAX other RIA development environments for several different reasons AJAX has set the world on fire when you’re considering creating a Web-delivered dynamic application, or what many call a RIA (rich internet application). With AJAX World occurring this week (which I’m not attending by the way), I figured it’s time to look at the links between AJAX and SOA once again…drilling down a bit deeper this time. We use AJAX other RIA development environments for several different reasons: Leverage dynamic behavior at the user interface. This means supporting the dynamic user interaction that most thick clients provide. Now we’re moving the “thick” functionality to Web clients. These clients should be able to provide windowing features and data navigation controls such as check boxes, buttons, radio buttons, toggles, dialogs, menus, etc. Moreover, a RIA needs to provide rich-media component objects such as animated sprites, multi-track sound and video. Loosely couple the presentation layer and logic layer. Thus, each RIA interface is changeable without also changing the back-end services, and changes to back-end services won’t necessarily drive changes to the clients. This loose coupling saves a bunch of development time and money if designed and deployed correctly. Provide both connected and unconnected modes of usage. This means that the clients may or may not be connected to the back-end services. Users can work in situations where network connections are not available, such as at client sites or on airplanes. This is a core feature needed for supporting mobile devices, such as cell phones, laptops and personal digital assistants. The RIA interacts with the back-end services when connected but is able to continue functioning when not connected, perhaps queuing up requests. Improve integration for data residing locally and remotely. Traditional thin clients cannot easily integrate data that resides locally. RIAs overcome this limitation by processing on the client. Moreover, RIAs can reach out and talk to any data source, local or remote, using the interface, not the back end, as the point of processing. This is more like the traditional client/server model and offers a flexible architecture. As SOA becomes more of a standard way of looking at architecture, many are seeking new standards-oriented interfaces that are able to externalize services to user interfaces, in many instances, on the platform for the Web. AJAX tools seem to fit the bill nicely, and many are more oriented towards SOA than others. Most recently, I took a look at SmartClient from Isomorphic Software. What I like about this tool is that they work from the data, up to the processes, logic, and the interface. Call me “old school”, but working from the data up seems more logical and natural to me, especially when considering how SOAs are built…from the data up to the services, and then the processes, typically. Of course, SmartClient is not the only AJAX game in town, there are dozens of development tools to choose from, all with different approaches, and intended uses. However, when thinking about SOA you need to consider how these tools will provide a loosely coupled framework for your architecture, and enabling services for human interaction. Most development tools will work, but AJAX seems to provide the path of least resistance when it comes to SOA. Software Development