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

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.

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.

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

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

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

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. ;-)

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.

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. ;-)

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.

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

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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

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