Does the rise of Service Oriented UI (SOUI) means the death of server-assisted MVC?

by Jean-Jacques Dubray on Nov 12, 2007 |

The Model-View-Controller pattern has been a staple of application architecture ever since Graphical User Interfaces were invented at Xerox PARC. The pattern itself was invented by Trygve Reenskaug. The pattern was adapted in the mid-90s to support web applications (this adaptation became known as MVC2 in the Java World).

This adapted pattern lacked the ability to update the view from the controller, typically the user had to refresh the page to see updates to its content. The reason being that there was server-to-client connection. With the advent of Ajaxian Framework, this connection can now be emulated. Prototype, the most popular Ajax framework in 2006, was developed without MVC in mind, simply offering a remoting framework and a simpler dom manipulation. In this case, developers can choose whichever way they implement the MVC pattern including MVC2. Other frameworks like JSF/Ajax4JSF and Ruby on Rails are a lot more prescriptive in terms of how MVC is implemented.

Nolan Wright thinks server-assisted MVC implementations are a thing of the past:

MVC-based frameworks are simply unable by design to take advantage of the full power of Ajax and DHTML [even though] many of [these frameworks] have added support for Ajax (e.g., JBoss Seam via JSF/Ajax4JSF and Ruby on Rails). They force an almost airtight coupling between the user interface and the server, whereas Ajax enables a near-100% decoupling of the user interface and the server.

Therefore, we must take a step back and a look at the problem of web development with a fresh perspective.

Jeff Haynie agrees:

Refactoring allows us to continue tweaking something to make it better - and often you get incrementally better improvements. But, sometimes, when you take a step back, you’re looking at a big hairball of a design. That’s where we are with web architecture these days - and why I believe lighter-weight frameworks like Ruby on Rails have been wildly successful.

Try to do a simple web app in Java these days - name your framework? Arghhh. Puck. XML config files, web flows, JSPs, controllers, models and DAOs, WAR files, JARs, blah blah blah. And want to refactor your layout? Forget about it.

Enough is enough. We need to really rethink MVC on the server side as a way of building Rich Internet Applications.

Nolan and Jeff think that SOA is part of the solution:

Let’s take the opportunity to actually do service-oriented architecture (SOA). SOA shouldn’t just be a webservices bolt-on. It’s not an afterthought - or yet another set of crap in the middleware stack. No, it’s central to the design - it’s the main act.

Nolan offer a new foundation SOUIs (Service Oriented User Interfaces) based on Services, Ajax and DHTML:

Ajax and DHTML are highly complementary technologies - when combined they enable the creation of web applications that can surpass the capabilities of today’s desktop applications. As a result, a next-generation Web SDK is needed - one that seamlessly integrates Ajax and DHTML.

Nolan explains that it is perfectly ok to have the controllers deployed in the browser:

With one message, you can hide 3 HTML elements, show another, and send a service request – pretty cool.

Nolan sees many advantages:

Since SOUIs talk to services using lightweight messages, services can now be written in any programming language. In other words, a SOUI is programming language-agnostic. You can change your server programming language without changing a single line of SOUI code.

You create a simple message-based contract between the SOUI and its services. The result is a near-complete decoupling of the client and server; they are linked only by a lightweight message contract.

You can create client-only prototypes that are fully functional since they can use local mock message handlers. The SOUI does not know the difference between using a mock message handler and using a service. [Just switch the message handler with the real service when you are ready]

Jeff concludes:

Let’s get back to simple. Let’s get back to what really matters - creating applications. Enough of the complicated server architecture.

Related Editorial

Impact of Java EE Frameworks on the Structural Quality of Applications

Mobile Web Interfaces for your Java EE Apps: Made Easy

Beyond HTML5 and Native Development: Build Richer, More Functional Mobile Applications

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Infographic: Just How Big is the Nerd Economy

Related Sponsor

Get code level visibility into your web apps. All for free.

Try New Relic Today.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

How about UI frameworks like OpenLaszlo, NexaWeb, TIBCO GI? by Veniamin Goldin Posted

Server/Client Coupling by Jacob Hookom Posted

MVC != Struts by Gavin King Posted

Re: MVC != Struts by Nolan Wright Posted

Re: MVC != Struts by 阮志敏 Posted

Re: MVC != Struts by hank jmatt Posted

Not really true by Ilya Sterin Posted

Isn't SOUIs the same thing as SOFEA? by Matt Raible Posted

Decouple it by Simon Buettner Posted

Browser Applications by Karl Traunmüller Posted

Re: Browser Applications by Jeff Highman Posted

Understanding of what SOA and MVC are? by Jeff Carlson Posted

Re: Understanding of what SOA and MVC are? by Nolan Wright Posted

Web frameworks peaking toward obsolescence by Roger Voss Posted

KISS? by Adron Hall Posted

APPLEBOX is a live example by Simon Gilligan Posted

Re: APPLEBOX is a live example by Francisco Jose Peredo Noguez Posted

Server/ by Oyun Cambazı Posted

How about UI frameworks like OpenLaszlo, NexaWeb, TIBCO GI? by Veniamin Goldin

Could UI frameworks like OpenLaszlo, NexaWeb, TIBCO GI be considered as SOAUI? They are completely decoupled from the server, handles controller on the client and introduces simple messaging between client and server in language agnostic manner.

Server/Client Coupling by Jacob Hookom

They [JSF/Ruby On Rails] force an almost airtight coupling between the user interface and the server, whereas Ajax enables a near-100% decoupling of the user interface and the server.

Couldn't you say the same for the inverse in going from the user interface to the server? If you are dealing with a (small) data domain and read-only interactions, then yes, the world looks pretty simple. As you build your user interface and need to coordinate read/write interactions and then supplementing services for specific use cases in your application in larger domain models, then things aren't as simple.

Pertaining to domain and user interface decoupling, I've noticed that all SOUI-like solutions do is cause you to re-specify domain artifacts multiple times in multiple contracts-- only increasing development time for naught.

Would it surprise people to know that JSF/Ajax4JSF has a 'message' implementation for meeting the same usecases described? Would it surprise people to know that you don't have to write custom messages and serialized forms (JSON/XML) of every artifact/usecase in your UI? I don't know how going without these tools creates 'less' coupling in your code and makes things simpler?

Really, this is just another case of someone finally 'getting' some concept and somehow losing the fact that these antagonist technologies (RoR included) have already met and surpassed the intended solution.

developers.sun.com/learning/javaoneonline/2006/...

MVC != Struts by Gavin King

MVC-based frameworks are simply unable by design to take advantage of the full power of Ajax and DHTML.

This is an assertion, for which no evidence was offered. Indeed, it seems unlikely to be true. Remember that the original MVC pattern was developed for use with user interfaces which *did* have a fine-grained eventing model (SmallTalk GUIs).

In my view, the "action" variant of the MVC pattern that was popularized by solutions such as Struts, WebWork, RoR, etc, is not as natural a fit for a fine-grained event model as modern component-oriented approaches like JSF, Tapestry, etc. But the "action" variant is not the only MVC, nor was it even the original MVC.

Let’s get back to simple. Let’s get back to what really matters - creating applications. Enough of the complicated server architecture.

But how is a "service-oriented" server-side simpler? It has all the same needs that an MVC framework fills: input validation and databinding, orchestration, state management and serialization of objects to markup.

(Arguably, *some* state can now be managed purely in the client, but in practice what happens is that you're forced to reload a bunch of persistent state from the database on every Ajax request, which is much less scalable in most systems. So you're going to wind up with a stateful server after all.)

So at this basic level there is very little difference in the request lifecycle of a server that serves pre-rendered HTML, and the request lifecycle of a RESTful web service that renders XML content.

What you'll end up with is a server-side that is just as complex as before, and a client-side which is *much* more complex because instead of a nice declarative user interface, you're stuck with some horrible HTML + scripting language where you have to re-solve the problem of transforming semantic XML content into HTML.

I challenge the proponents of this idea to produce a non-trivial web application which can't be implemented in less code using an MVC-type approach.

Not really true by Ilya Sterin

have added support for Ajax (e.g., JBoss Seam via JSF/Ajax4JSF and Ruby on Rails). They force an almost airtight coupling between the user interface and the server

That's not true, since the server has a web and a domain layer. The web layer is responsible for integrating and decoupling the UI from the domain layer. There is no tight coupling, the web layer is just a delegation of UI use cases to the domain layer. Of course I'm sure many don't architect that way and you can have just as tightly coupled of a ajax front end as you would with today's MVC frameworks.

Now, I do love the front end controller on the client idea. I love flex and various other architecture frameworks that offer it. I still there that a backend integration layer is needed, even if it's just a small web layer that is responsible for ensuring that json/xml data passed to the server is unmarshalled properly and passed on to the domain layer. There are frameworks that handle that for you through proxying, but let's not forget that that layer still exists.

Ilya

Isn't SOUIs the same thing as SOFEA? by Matt Raible

Aren't these the same concepts introduced in Life Above the Service Tier? I think so.

Of course, you know the success of any concept (especially in this open source world) is often about timing and marketing. I think we're going to need a better acronym than SOUI or SOFEA for this to take off. ;-)

Popular practice or good idea? by Jeff Highman

So let’s say (SOUI = Ajax) and (MVC death is evident by the most popular Ajax frameworks). Does that suggest that we should jump back into a Model-1 design and declare that in so doing we are now more service-oriented in the presentation tier?

SOA should yield composite applications. Therefore, SOUI should not be bound to the Ajax-workaround to browser limitations (XMLHTTPRequest & javascript).

I beg the question is the BROWSER is the right container for composite applications? I am sure that the popular opinion is yes, but Model-1 web programming was popular once too.

Decouple it by Simon Buettner

I dont think that a "server-generated" ui is the problem. I think that most of the current frameworks are to tightly coupled. For a developer its a nice thing to have full blown data access in the controller (like rails, grails, ...) but the whole data side should be extracted.

It would be much nicer to program against a dataservice from an ui framework rather than mixing db access and ui generation.

Most of the newly created apps have problems when it comes to scaling and accessing the data in another form of an ui (swing client, eclipse rcp, plugin,...).

On the side you can see many nice examples of this kind of decoupling (google apis, facebook apis,...) where people just connect their ui to a "data-service".

Sorry for decoupling the content from the grammar. ;-)

Re: MVC != Struts by Nolan Wright

Whether a "service-oriented" server-side is simpler depends on the implementation. In our platform, clients and services are linked only by a message-based contract. The result is that services are stateless and they do not contain presentation logic. This enables service programmers to do their job more effectively since they only have to implement the message contract. They don't need to know about who or what is calling their service, and this is how it should be. It's never made sense to me to mix presentation logic with server code.

Our clients are the same in that they know nothing about the services they consume (except for the message contract). They don't know if they are calling services written in Java, PHP, Ruby, .NET or Python, and they shouldn't know; this information doesn't help them do their job.

As for Ajax, it's a client/server technology. MVC-based web frameworks have used it effectively to enable partial page refreshes, but if MVC changed to fully leverage the capabilities that Ajax enables, it wouldn't be MVC - it would be client/server, which brings me to my next point.

I think client/server is the future for web-based architectures. MVC did not become the dominant web architecture because its better than client/server, it became dominant because it was the best choice given the technologies that were available at the time. That is no longer the case. There is evidence of this shift in the market. Frameworks like OpenLaszlo, Adobe Flex, Google Web Toolkit, and Appcelerator are based on a client/server architecture. I think the shift is inevitable; it's just a matter of time.

I like your idea of a challenge. Debates are nice, but results are what count. If you are serious about this, let me know. We are always game for a good challenge.

Browser Applications by Karl Traunmüller

I mostly agree. I'm not happy with the way web applications are built today. There has been no major step forward in the way we develop web applications for the last 10 years or so. Rails and other frameworks have improved only on some parts of the game, and only marginally (not by an order of magnitude, say).

Web apps are still rather cumbersome in terms of development, and rather awkward to use (the only way of data submission being HTML form posts with full server roundtrips / page reloads; AJAX and partial page updates can only mitigate that partially, and to me it feels just like one big ugly hack).

In our company, we also poked at the idea of rich-interface, stateful "browser applications" (in contrast to traditional, server-generated HTML web applications). Regarding Jeff's question whether the browser is the right platform: I think the browser is capable enough to handle these kinds of applications, and frameworks like Prototype, qooxdoo, or ExtJS provide a solid foundation to build on. I mean, Javascript is fine. You can write clean code with JavaScript; just look into the source of mentioned libraries.

But I don't think the server side can be built solely of stateless services. That just won't work. You'll have to have some state on the server in any non-trivial case. So there needs to be some kind of stateful EJBs with Web service (or whatever) bindings, state management / container services, and orchestration.

That has to be taken into account when designing the "next generation Web SDK", I think.

Nevertheless, an interesting idea worth discussing.

Karl

Re: Browser Applications by Jeff Highman

I tend to think of SOA in terms of an overall enterprise, where the web presence is only a part of the picture. In information intensive enterprises SOA must support stakeholders in the back office as well as customers in the front. Back office folks may work-the-information all day everyday. For those stakeholders the browser is a huge constraint. In most cases simply not plausible despite the progression of AJAX enabled libraries. So for a SOA strategy to be relevant across an enterprise, the idea of pushing logic above the middle tier across-the-board may be robbing Peter to pay Paul.

The Eclipse RCP solution space is a compelling way to approach the notional SOUI in the back office. A Multi-platform UI with native components gives a very rich presentation. Leveraging all of the client’s resources for always-on functionality is intrinsically feasible. The application workbench, perspectives, and other pre-built functionality speed the development. And the underlying OSGI kernel allows right-coupling. I have found that services designed to address the “M” in MVC are readily re-used in web based application variants, including Ajax ones that don’t prescribe to MVC. You can blend the browser into the RCP space very as well. There are limitations, but when comparing those limitations to the browser-all-by-itself, it’s really not much of a comparison.

I am not knocking the browser approach for the front office or the next generation web SDK, but I think that SOUI is a broader concept, to further Roger statement, that needs change the game otherwise it’s just Web UI.

Understanding of what SOA and MVC are? by Jeff Carlson

It appears as the authors of the blogs referenced here are misunderstanding the point of SOA and vilifying MVC becasue they don't like a few web frameworks that follow this pattern.

SOA is an approach to solving business problems where most of the heavy lifting is in the business process definition, mapping and automation and governance areas. MVC is a pattern to simplify GUI development - you have data (M), and a view (V) and the view has to be able to get the data and manipulate it (C).

The ideas presented in these posts and in this summary post seems, IMO to be misplaced. If folks hate Struts and all of the Java "MVC" frameworks they should say that specifically. MVC as a pattern is the best pattern available for GUI development. Saying MVC is dead is like saying the GUI is dead. Or at the very least it is like saying 'lets write tons and tons of spaghetti code that will be less maintainable with every line we write'. Doesn't seem like something that should be heralded as a good idea.

Saying that SOA is all about the GUI is, IMO, also misinformed. The GUI is ancillary at best to any SOA initiative. Much of a full SOA environment has no exposed human interface. Think the B2B and C2C traffic as well as all of the layers of data / application / process services - the clients/consumers are other services or programs.

This article is something I would expect Dilbert's boss to be quite excited about and that is the only reason I am posting here. It would be lovely for a few folks to look at this a little more carefully before cross and reposting this and before our managers read these new terms in a trade rag.

If I misunderstood these articles and the authors did not mean that MVC is dead or that SOA is all about the GUI then I withdraw my criticism and would appreciate it if someone smarter than I am could explain these positions more clearly.

Web frameworks peaking toward obsolescence by Roger Voss

My article here on this topic puts it even more succinctly:

Web frameworks peaking toward obsolescence

The bottom line of that posting:

"In short, implementing MVC on the server-side will become regarded as retrograde."

In our case it was experience with Flex RIA web app + SOA development that brought us to arriving at that conclusion.

Re: Understanding of what SOA and MVC are? by Nolan Wright

Good comments. My target, as you stated, was really the traditional web MVC-based frameworks. I attempted to make that clear, but I probably was not clear enough. The point of the post was to generate discussion around how we can improve the ways in which we build web applications. I completely agree with your statement that MVC is great as a GUI pattern.

Also, I did not mean to imply that SOA is all about the GUI; I don't think that at all. But, I do think we can do some things on the web tier to make it easier for web-based applications to leverage the investment made in SOA. I think it's time for the server-side web tier to be SOA-based. It is possible to have a clean separation between the web client and the services that it consumes. Services should be free of presentation logic and stateless where possible, and web clients should be built in a way that enables them to consume these types of services - i.e., a Service Oriented User Interface.

Anyway, I hope this helps to clarify my thoughts and intentions.

KISS? by Adron Hall

Keep it Simple Stupid? This doesn't seem any simpler than one or the other or ones not mentioned.

"Let’s get back to simple. Let’s get back to what really matters - creating applications. Enough of the complicated server architecture."

I've seen some of the new MVC patterns, I see them getting simpler and easier to implement. Maybe the concept behind SOA UI needs more explanation. Maybe, just maybe a real framework needs built before it is discussed as something that will takeover the need for MVC.

Either way, enough talking, I want to see some results. In the end, that IS what its all about!

Re: MVC != Struts by 阮志敏

Both approaches have their own advantages and disadvanges, and both can excel under different situations and requiements.

Server-assisted MVC exists because of the powerful of the application server. With stateful connection with the backend, the code need to write in front-end pages is greatly reduced. However, stateful connection needs state management and state synchronization between servers, which results in the difficulty of scalability.

Service Oriented UI prefer stateless connection(decouple) with the backend, it maintains the state of business object in the front-end. Ofcourse, this is a greate idea, because it can lead to near linear scalability. However, too much work needs to be done in the front-end, like message sending/receiving, rendering message, maintaining state .etc, all of these leads to the complexity of the front-end. The complexity of the front-end can be reduced greately with existence of front-end framework and UI component libaries.

APPLEBOX is a live example by Simon Gilligan

What this discussion lacks is a solid example of a SOUI in action. Until we can see what can be done, it's all posturing on which architecture is best. From Gavin King "I challenge the proponents of this idea to produce a non-trivial web application which can't be implemented in less code using an MVC-type approach."

Go to applebox.com.au , click 'Browse DVDs' and you'll see a SOUI in action. You can read more about it here applebox.com.au/blog/2007/12/mda-soa-and-server...

APPLEBOX is a non trivial, consumer application completely implemented with SOUI techniques. I would LOVE to see a server bound MVC implementation of APPLEBOX achieved with less code. My take - not possible. Go server MVC and you will compromise the responsiveness and RIA capabilities of the UI. And in consumer land - it's the UI that matters, not us arguing over which architecture best implements it.

Re: APPLEBOX is a live example by Francisco Jose Peredo Noguez

Yes, just go to APPLEBOX and and try to bookmark the DVD you find... you can't? sorry for you, SOUI is the future, and you can not bookmark it.

Re: MVC != Struts by hank jmatt

I've seen some of the new MVC patterns, I see them getting simpler and easier to implement. Maybe the concept behind SOA UI needs more explanation. Maybe, just maybe a real framework needs built before it is discussed as something that will takeover the need for MVC tower defense.

Server/ by Oyun Cambazı

Therefore, SOUI should not be bound to the Ajax-workaround to browser limitations (XMLHTTPRequest & javascript). I beg the question is the BROWSER is the right container for composite applications? I am sure that the popular opinion is yes, but Model-1 web programming was popular once too. I'm really very useful to follow a long-time see this as a blog here Thank you for your valuable information.

Server/ by Oyun Cambazı

I'm really very useful to follow a long-time see this as a blog here Thank you for your valuable information.Oyun