AJAX, SOA, and the end of the Model 2 MVC

It appears that AJAX introduces the opportunity to deprecate many of the MVC (Model 2) frameworks that exist today in place of direct communication from the Web Browser to the ESB. I confirmed many of these assumptions recently when I integrated an AJAX enabled Ruby on Rails web application with an ESB backend based on Mule. While integrating these apps it appeared that much of the development seemed as logically implemented on the Web Browser client as the server. What lies ahead for Web Application frameworks? Is the quest for JSP 2.0, and the next JSF with AJAX support misguided?

Consider the following.

Asynchronous behavior is desirable on a user interface. In fact, traditional web interfaces have suffered from the lack of asynchronous behavior in the form of weak usability when compared with thick clients.

Anyone who has implemented a system based on an ESB discovers quickly that there is a philosophical difference between developing a synchronous application versus an asynchronous service. Moreover, the "problems" that immediately arise with integrating an asynchronous service with the web user interface, seem to evaporate when AJAX enters. Programs are often written with many synchronous assumptions. In fact, synchronous behavior in the physical world is not nearly as common as one might think. People rely on context when they communicate, not correlation id's. Such context can often be modeled with workflow engine contextes instead of relying on correlation at the thread level. Workflow engine's such as jBPM, OSWorkflow, and others make use of the application's ability to establish context.

So what does all this mean? SOA architects model documents asynchronously flowing from one service to another. AJAX models the asynchronous exchange of XML content (documents) to and from the web browser. One might deduce that standards such as REST, RDF, and AJAX (indeed most of Web 2.0) suggest that the web browser's interaction with the server is merely another component participating in the SOA.

If this philosophy is adopted, what does it mean for our beloved MVC container architecture? Most Java MVC frameworks are fairly synchronous by nature. In addition, some of the most valuable features of these frameworks are their validation and layout frameworks. I enjoy struts tiles. I enjoy struts validator. But when combined with AJAX, I find them less useful. The "tiles" like behavior is delegated to the client using div's, AJAX, and javascript. And the validation framework seems as if it can be fairly easily implemented on the client. Not to mention that any web services developer has fairly rich validation frameworks available with XML Schemas. Admittedly this area may be a little short though I might not be as up to speed with the Web Services, Web Client validation integration mechanisms as I should be.

Ultimately, is the answer to the ultimate server web framework to not have one at all? Time will tell.

In the mean time there are a few efforts I am keeping my eyes on in tracking these concepts.

• ws-wsajax is an IBM project that seems to be an Javascript AJAX SOAP client.
  
• REST provides an interesting possibility toward simplifying the Browser, Web Services Mechanisms.
  
• Mule provides a popular and very interoperable ESB implementation.
  

I am anxious to hear what others think.

Humbly,
Brian Cochran