MVC in the world of AJAX and SOA

Recently I was hit with the question - How does MVC play in AJAX world? Well, below is the perspective I put forward although not so eloquently or in such detail. My response expanded the scope from MVC and AJAX to include the more widely adopted back end architecture - SOA (Service Oriented Architecture). I am not sure if I was able to put across my thoughts vividly to the other person but based on the impression I got, I guess not. So I thought I blog about it to reach out to the online community and validate my thoughts.

Abstract:
The traditional MVC pattern requires a fundamental change in terms of the roles played by the three layers. This need arises from the advent of SOA at the server end and AJAX at the client end.
Please note that this is not about how the communication i.e sync or async occurs between the various layers. This is at a higher level and hence the sequence diagrams captured below may not depict the exact communication patterns.

Detail:
Traditional MVC has been:
Model: The data access layer and data persistence. This is the Hibernate, JPA layer in case of Java.
View: Presentation layer i.e how data is presented to user. JSP, JavaScript, HTML fall into this category.
Controller: Data validation, transformation and control the flow i.e identify the next view to be rendered. In case of Java, Servlets are used as controllers.





But in today's world where data driven architectures are replaced with service oriented architectures, the needs have changed with a diverse set of clients seeking the same set of information. The model is wrapped in a service layer that provides all the functionality required for diverse set of clients that include:
- A SOAP / WebService (i.e WS-*) client.
- API client i.e users need a programmatic access to the underlying functionality, either to enhance the functionality or integrate it into their own services.
- GUI - thin i.e web based, as well as thick i.e from IDE's such as Eclipse etc..

So in order to address the above needs, how can MVC help. Obviously the traditional MVC has to undergo few changes.
Model: is now wrapped by the service layer with enhanced set of functionality that enables distributed cache, scalability etc., across diverse set of client.

Controller: Since the data validation and transformation are needed by all the clients, these need to be moved into Service layer. So Controller is now left with flow logic only i.e to identify the view for the corresponding user event.

View: Any business logic at this layer needs to be moved into the service layer since the application MUST exhibit a consistent behavior across the diverse set of clients. How this data is rendered to the user is what primarily exists in the view and is the prerogative of the client.

Before we dive into how the layers can be refactored, let us how AJAX influences the layers. In the world of AJAX, the web UI is designed in a more modular fashion and there is a lesser need to render the complete page for every event. Only a certain content on the page could be refreshed with a different data set. The view remains the same. For eg: when browsing contacts page, the set of fields displayed for each user - First Name, LastName, Address etc., are the same. What changes when a different user is selected is the value of the First Name, Last Name and other fields. In other words the view stays the same while the data set is what changes. So the only role the controller plays is delegation from view to service / model. In other words, the role of Controller has diminished to that of a delegator.

The question arises to which layer does the Controller now really belong to? Should it be part of the View since its only role is to identify the view? Probably yes. The result is, if the view needs to change, either for a complete re-write to upgrade to latest technologies or for refactor purposes, changes at the View layer will in all probability effect the controller layer or what ever we may call it. But it is not necessary that the service layer undergo's any change.




The above is something we were able to achieve using GWT. I am not sure how the wide range of MVC frameworks out there enable the above. But, based on my past experiences, in an effort to enforce MVC pattern these API and interfaces could be rigid, although I would request the experts on these frameworks provide their inputs.