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:
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:
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:
Conclusions
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.
~~LINKBACK~~ ~~DISCUSSION:closed~~