I just realized that Client Server 2.0 is a much better name for the application architecture that is causing the current browser war than my proposal from yesterday. This architecture, javascript clients running in the browser, communicating with SOA servers, requires better memory handling and javascript performance from browsers. (Basically a standards based implementation of what some people call SOFEA or SOUI).
This architecture, made popular by web applications like gmail, doesn’t depend on application-servers to render web pages. Instead, the application is downloaded to the browser as javascript, and the javascript will render most of the dynamic parts of your interface. The rest can be handled by static html. Application-servers will only be needed for hosting services used by these javascript applications.
Client Server 2.0 just makes the most sense for this architecture. Just look at the history of application architecture:
- Terminal-servers. Servers render the user interface, client terminals only display the user interface rendered by the server. The server processes the user input.
- Client-server. The code that is needed to create the user interface is running on the client pc. The application only contacts the server for central data and business functions.
- Terminal-server 2.0 (html websites). This is very much like the original terminal server, where a server renders a user interface, and the client is only used to display this user interface. User input is mostly sent to the server to be processed. A whole bunch of mvc frameworks and serverside ui components have been created to facilitate this way of programming.
- ClientServer 2.0 (Javascript applications). The server no longer renders the user interface, and doesn’t take part in processing the user input. Like with client-server 1.0, it’s purpose is to make data and business functions available. The client is completely written in javascript, and runs in the browser. You will no longer need an MVC framework on your server, instead, if you need it, it will be running in javascript in the browser.
Ajax enhanced serverside view frameworks like JSP and JSF are only a temporary solution while we are moving from Terminal Server 2.0 to Client Server 2.0.
Update
Here’s a slightly modified picture i used a couple of months ago. It illustrates the trends towards client-server 2.0. Back then i though flex, silverlight or javafx the best options for implementing client-server 2.0, but i now realise that most of the same goals can also be achieved using javascript, html and css. The advantage is that this solution is completely based on open standards.
Update
Oracle Forms is actually a funny example, as until Forms 6 it was client-server 1.0, but now that it runs as an applet in the browser, it actually fits in the client-server 2.0 box. Unfortunately it’s not really standards based.
Update
Here’s a quick client server 2.0 architecture picture, mainly to illustrates that SOA/WOA containers are an essential part of this architecture.
September 5th, 2008 at 20:14:45
Hi!
Actually, Oracle once worked on a Forms version nicknamed Cherokee. Rumours said that it had a standards-based HTML/CSS/JavaScript UI.
Chris
September 6th, 2008 at 11:26:58
No matter which client technology – Javascript/HTML/CSS, Flex, SilverLight, JavaFX – one thing is clear. We’re on the verge of creating more responsive, pleasant UI’s for our customers. They had to do without it for far too long.
Personally I like Flex better – for now – because of the more rich widgets and better/faster possibilities to talk to backend services. Much of Flex (and those backend technologies – like BlazeDS) have been open sourced and are (mostly) standards based also. On top of that it has a community which is growing steadily and I ’see’ developers flocking to it more and more.
I think we first need some consolidation on the Javascript frameworks side, as there are far too many in my view. Kind of reminds me of the abundance of web development frameworks that were/are out there. (Or are you writing ‘raw’ Javascript without the use of framework(s)
)
September 8th, 2008 at 15:41:07
So how does a technology like GWT fit in there ?
September 8th, 2008 at 16:09:13
GWT is client-server 2.0 (i’ve updated the illustration) as it generates a javascript client which runs stateful in the browser. The javascript generates all the html needed to display the application. No application server is involved in producing the user interface. It’s just a static file server for the javascript files.
The only reason why GWT is not completely client-server 2.0 is that the communication with the server is not based on a standard like soap or rest. So i think the services used by the gwt application aren’t really reusable by other technologies. My experience with gwt is limited though, so i might be wrong here.
January 15th, 2009 at 16:56:15
[...] Client-Server 2.0 [...]
January 15th, 2009 at 17:01:33
[...] weeks ago i wrote a post suggesting the name client server 2.0 for browser applications which are completely generated in the browser using static javascript, [...]