In thinking about the emerging trends that are starting to penetrate the Internet, especially the trend towards richer experiences, it’s interesting to watch how various technologies that would otherwise have little do with each other are aligning.
For example, the desire to deliver richer experiences is starting to gain some serious traction. People are starting to really push the limits of delivering interface over the web. AJAX, Flex and later on XAML are introducing a whole new breed of applications. This trend is forcing information architects and front-end developers to rethink how their applications are designed. But beyond the people on the interface end, some pretty dramatic things are going to start happening on the server-side as well.
Here’s the general process that occurs today:
- User clicks on a link or button in a web browser.
- The server receives the request.
- It grabs whatever data is needed from some data source.
- It grabs some templates or interface elements (HTML, CSS, images, etc.).
- It takes the data and the markup (i.e. the “interface”) and effectively “assembles” the page for delivery.
- It sends the stitched-together interface – data and all – back to the client.
This is fine and good for traditional web applications, but RIA’s like Flex & AJAX require a more granular delivery mechanism. Let’s look at the same process in the context of an RIA:
- User visits a web application.
- Persistent interface elements are delivered to the client (some data may come along with them).
- User interacts with the application in some way (notice here it can really be anything – not just clicking on links – clicking, typing, dragging, etc.).
- The user action (or event) fires off a request for some data (not an entire page).
- The server gets the request.
- It grabs the data and sends it back to the client.
- The client now does the work of “assembling” the data with the interface.
As to the preferred method of interface assembly – pick your poison – XUL, XAML, AJAX, MXML, etc. What’s interesting about all this is that the changes coming down not only affect front-end designers but those that architect back-ends as well. Application servers aren’t really application servers anymore. A nice chunk of the application is sitting on the client – where it belongs. The servers are now more focused on delivering data as needed. A very different proposition.
All of this sheds a whole new light on web services (whether SOAP or REST, it doesn’t really matter). In the past, the key selling point for web services has been the hope of easing integration with disparate systems. This is, of course, a key benefit. However, beyond the more conventional arguments for web services, these new interfaces further underscore the need for more granular, event-driven delivery of data. These new applications don’t want fully rendered pages anymore. They’ve already covered that. They want data.
So in light of all this, you have to wonder if organizations that have invested heavily in web application infrastructures are going to be ready for this shift. My guess is some will be but many won’t. It just takes a little planning and foresight to be properly positioned for the changes to come.