User Tools

Site Tools


Dave Orme muses about agile and functional programming.

My current work emphasizes SOA applications using Scala, Kubernetes, and AWS with a React-based SPA front-end. I'm also interested in progressive web applications and developer tools.


Scala, Clojure, and FP


The Cloud

Data-First Development

Older work

Coconut Palm Software home

Donate Bitcoin:



Kubernetes, Docker, Streaming Data, Spark, Scala, Clojure, OSGi, Karaf, GCP, AWS, SQL


Everything I say here is my own opinion and not necessarily that of my employer.


The Ideal Application Architecture

Recent, Ed Burnette of EclipsePowered identified several options for what the application platform of the future might look like and solicited feedback about what the rest of us thought would most likely be the winner. His choices were:

  • More and more clever use of DHTML in web browsers, e.g., oddmail, outlookwebaccess, bindows
  • A rejuvinated Browser War that spurs lots of innovation in browser enhancements, e.g., Apple Dashboard, what-wg
  • Standards group innovation plus better standards compliance, e.g., w3c forms, css3
  • “Smart-rich” apps that run like fat applications (with most logic on the client) but are updated and managed automatically over the network, e.g., Eclipse RCP
  • “Thin-rich” apps that provide a nice interactive API for the developer but are deployed using a shard thing client framework with most logic on the server, e.g., X windows, flex
  • Something different, e.g., XAML and XUL

The difficulty with this question is that it does not identify any of the forces that are shaping the application environment today, so it does not leave us any closer to an answer. Here is my assesment of the forces that are shaping application architectures today, intended to help answer the above question:

  • How rich should a client interface be?
  • Where does the business logic belong?
  • How are enterprise client applications kept updated and current?
  • What platforms have existing and/or developing vendor support in the industry?

Let's deal with each of these questions in turn and see where that leaves us leaning with regards to the likely choices for the future.

How rich should a client interface be?

It is not necessarily true that the richer the user experience, the better. For example, I cannot see how Google's interface could be much improved by moving it to a rich client platform. The online experience has definitely benefited from the document metaphor brought about through the web interface.

On the other hand, there are large categories of applications–mostly data-centric applications–for which the document-based interface of the web is inadequate. For example, no programmer would use a web browser interface to write code. The editors provided by the TextArea tag are just too primitive. Similarly, Quicken™ and similar products work best in a rich client environment. Business applications that rely heavily on data-entry or interactive graphics also benefit from a rich-client architecture.

So we see that from a user perspective, a large chunk of business applications really would make sense to develop as rich-client applications.

Where does the business logic belong?

Traditional client-server applications are caught in a quandry: If you implement the business rules of an application inside the rich client, you are forced to update each client on every desktop when those rules change. However, if you place the business rules in a server, the application must make a round-trip network call to the server whenever the user interface needs to validate some data. Since this frequently may happen whenever the user's focus leaves a data-entry field, the application is either forced to take the network traffic hit of calling the server as the user fills in data-entry forms or forgo the interactivity of validating data as it is entered into data-entry forms.

In other words, managability demands that the business logic reside on the server, but usability dictates that it belongs on the client. So what is the solution?

Web applications work around this limitation by shipping the business rules (in the form of JavaScript validation code) from the server to the client dynamically as the application executes. This can sometimes provide the interactivity desired by the users while at the same time reducing the costs to manage the application.

Until recently, rich clients were stuck in this area. There presently are two main choices: Either ship updates to the business logic to the client, and let them execute there (the :smart rich client“ option Ed proposed) or leave the entire application on the server and just let the user interface execute on the client (the “thin rich client” option that Ed proposed).

On balance, it appears that all three options have merit and must be balanced with the requirements at hand.

How are enterprise client applications kept updated and current?

In web applications and thin rich clients this is obvious: simply hot-deploy a new version to your server.

With smart rich clients, you deploy updates to your server that are picked up by the smart rich clients on a schedule or the next time they are restarted.

What platforms have existing and/or developing vendor support?

This question is the main one. Of the choices available:

  • All vendors appreciate the web as a platform for what it does well. It is likely to stay and to evolve, especially for information browsing, searching, and retrieval applications. But it is notable to observe that a sizable portion of the recent web advances (web services, aggregators) push the web away from the browser interface and toward specialized rich client interfaces.
  • Microsoft is pushing rich clients and web applications but does not have a smart rich client platform.
  • X terminals are probably the most broadly-deployed option for thin rich clients as some organizations realize that clients with zero moving parts and a five to ten-hear lifespan are much cheaper to maintain than a miniature mainframe on everyone's desk. However this option suffers from the lack of a major vendor backing it.
  • Smart rich clients, particularly in the form of the Eclipse Rich Client Platform, are well-positioned for broad market acceptance. Most of the major players except for Sun and Microsoft are supporting it in one way or another. And Eclipse, its parent project is one of the most highly-regarded open-source projects in industry.


On balance, it appears that most of the technologies that Ed identified will continue to have some influence. However, the three that appear to be best-positioned to have the widest influence are the venerable web browser interface, smart rich clients, and thin rich clients.

Note that a thin rich client interface can host either a web browser interface or a smart rich client if that thin rich client is X Windows or an equivalent, so these choices are not necessarily mutually exclusive.


blog/the_ideal_application_architecture.txt · Last modified: 2014/10/17 22:08 (external edit)