Chapter 1. Eclipse as a Rich Client Platform
The term rich client was coined in the early 1990s with the rush to build client applications using the likes of Visual Basic and Delphi. The dramatic increase in the number and popularity of these client applications was due in part to the desire for a "rich" user experience.
Rich clients support a high-quality end-user experience for a particular domain by providing rich native user interfaces (UIs) as well as high-speed local processing. Rich UIs support native desktop metaphors such as drag-and-drop, system clipboard, navigation, and customization. When done well, a rich client is almost transparent between an end-user and their workfostering focus on the work and not the system. The term rich client was used to differentiate such clients from terminal client applications, or simple clients, which they replaced.
The rise of client technology was accompanied by improvements in development environments. WYSIWYG UI designers made building rich client applications easy and fun. These development tools allowed client programmers to reuse common building blocks to reduce development time.
Early rich client platforms (RCPs) were used to glue the client's business logic to the operating system (OS). They eliminated many of the menial programming tasks required to create UIs and access databases. The middleware provided frameworks and infrastructure so developers could spend more time programming domain logic rather than reinventing the wheel.
End-users were happy with the resultant rich client applications, as they were functional and easy to use. Information technology (IT) managers, however, found many hidden costs. Deploying and upgrading clients is a manual task and users often tweaked their installs, moved files, or installed other clients that overrode shared libraries.
Then along came the Internet and Web-based applications, or thin clients. Thin clients promised to solve many of the deployment and management problems related to rich clients. Since applications were on servers, updates were made centrally. User machines required only a Web browser. This reduced the cost of deploying and maintaining enterprise applications at the expense of the user experiencethin clients did not provide the UI features and high-speed interactions users had come to expect.
The cost savings and simplifications were popular, but the move to thin clients was ultimately a step back in functionality and capability. Thin client applications, using the request-and-response model, required more networking capability to ensure optimal interaction performance. Moreover, as applications and users became more sophisticated, a number of new requirements for distributing business logic and handling mobile devices and disconnected clients came to the surface. These could not be implemented using thin clients.
Today's users and problems are driving a return to rich clients. Domains are becoming more complex, and the amount of data to visualize and manipulate is increasing, as is the need for integration with other systems. The demand for rich clients goes beyond the desire for a richer UI. Users need to be mobile, work offline, integrate their content and workflows, collaborate, and take advantage of local hardware.
But what about the deployment and maintenance problems that caused the earlier shift to thin clients in the first place? Has something changed to mitigate those issues? Yes, today there is an increasing number of component mechanisms, such as Eclipse, available to rich client application developers. Componentized systems address both deployment and maintenance issues by insulating and isolating components from change. They also enable the type of application integration needed for today's dynamic scenarios. In short, this new brand of rich clients provides the best of both worlds.
| 
