There is a lot of talk about the Eclipse Rich Client Platform (RCP). Jeff McAffer and I delivered a webinar on the topic a few days ago and I’m getting ready to deliver a similar talk at Javapolis in Belgium next week. One of the things that I like to include in a talk is a definition of “Rich Client”.
Wikipedia does a terrible job of defining Rich Client. In fact, it just redirects you to Fat Client, which I think this is wrong. In many ways, a rich client is very similar to a fat client: both provide a rich user experience using time-honoured user-interface components with great graphical features, drag and drop and the like. Both run interesting behaviour on the client workstation (contrast with the browser which tends to run view rendering and minor application-specific logic on the workstation). Both rich clients and fat clients have an implied server component (though this is not necessarily the case as it is possible to build completely standalone applications with both).
Perhaps one of the bigger differences, at least at some conceptual level, is that rich clients tend to leverage relatively interesting backend resources like an application server; fat clients tend to connect directly to databases. Of course, this is not necessarily the case, as it is completely possible and totally reasonable to build a rich client that connects directly to a database. It is also the case that many fat clients do access more interesting backend resources.
For those of you who like to see pictures, here’s what a fat client might look like:
And here’s a rich client:
I don’t know that it’s a particularly good graphic, but the basic idea is that some of the control and business logic for the application is shared between the rich client and the application server. As a general rule, I tend to try and hide the database access behind the application server, but that’s a discussion for another day.
But the differences are bigger than the nature of the server. In my opinon, a rich client:
Delivers a rich user experience. This is obvious.
Is typically a client for some backend service. Again, this is pretty obvious
Is platform independent. In the salad days of client-server development–when fat clients were all the rage–we had pretty tight control over the delivery platform. That’s just not the case anymore. Even within relatively small organizations, it is not uncommon to see multiple platforms (Windows, Mac, Linux, …). Being able to support these multiple platforms using native look and feel (looks and acts like a “Mac” application on the Mac, etc.) is pretty important. Very often, the rich client is an integration point and so must be able to leverage platform component services and such as well.
Runs with little or no modification on multiple platforms and devices. This is related to the previous point, but with a hook: devices. More and more of our work is being done on relatively small devices like PDAs and phones. Even if you’re not doing this today, you’ll likely be doing in some time in the future. Development resources are pretty expensive, so being able to move existing applications to new platforms relatively easily is critical.
Has robust component model. We built components in those previously-mentioned salad days, but we did through architecture of the application. An explicit component model framework is absolutely critical when it comes to building rich clients. Applications today are simply too complex and integrate too many different technologies from too many different groups to not have a sophisticated framework for managing dependencies and communication between components.
Has an integrated update mechanism. One of the biggest challenges with fat client applications is keeping them up-to-date (just deploying them is pretty hard). Rich client applications must be able to update themselves easily.
Must be extensible. Change is an important force in software development that cannot be overlooked. A rich client application must be able to accommodate change. We must be able to easily change the behaviour or add new and completely unanticipated behavior. This, of course, relates to the need for an update mechanism, as we need to have a way to deliver this new functionality.
Has the potential to work offline. We’re almost to the point where we’re always connected. Maybe in another ten years or so, it will be difficult to find a place where we’re not. However, in the meantime, reality is that many of us need to be able to work disconnected from a server.
Since I’m often accused of being a little long winded, I have opted to keep my discussion of each of these points short. I’ll try to build on some of these over the next few days and weeks.
