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 end users and their work—fostering 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 dramatically reduced the cost of deploying and maintaining enterprise applications at the expense of the user experience—thin clients did not provide the UI features and high-speed interactions users had come to expect.
The usability and applicability of thin clients were enhanced with the evolution of rich Internet applications, or RIAs. RIAs brought common desktop characteristics and metaphors to Web-based applications via improved UI technology. Current RIAs are built using technologies such as Adobe Flash/AIR, Google Web Toolkit (GWT), Microsoft Silverlight, and Mozilla’s XULRunner.
The cost savings and deployment simplifications were popular, but the move to thin clients and RIAs was still a step back in functionality, capability, and development efficiency. Thin client applications, using the request-and-response model, require more networking capability to ensure optimal interaction performance. Typical RIA technologies lack a strong model of modularity, a setback for teams used to the power that, for example, the Eclipse modularity model brings. The Eclipse Rich Ajax Platform (RAP) is a notable exception here.
Today’s users and problems continue to drive the use of rich clients from the Web to the desktop. 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.
The technologies outlined here at least partially address these topics but ultimately result in more and more functionality in the browser—making the thin clients not so thin and reviving many of the old thick client topics. These approaches trade the operating and window system for the browser but still leave the challenges of modularity and versioning.
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 an increasing number of component mechanisms, such as Eclipse, are available to rich client application developers. Componentized systems address both deployment and maintenance issues by insulating and isolating components from change. New deployment mechanisms such as Equinox p2 and enterprise management systems such as Yoxos virtually eliminate the need for personalized enterprise software management. In short, this new brand of rich clients enables the type of application integration needed for today’s dynamic scenarios and provides the best of both worlds.
1.1 Eclipse
If you are new to Eclipse, you are probably wondering, “What is Eclipse?” First and foremost, Eclipse is an open-source community of people building Java-based tools and infrastructure to help you solve your problems. The most obvious output of the community is the Eclipse Java Integrated Development Environment (IDE). This world-class Java IDE regularly tops the charts in developer satisfaction and use. It’s also free from http://eclipse.org.
Underneath the IDE is a generic tooling platform that supports a wide range of tools for languages and systems, from Java to C to Python to Web technologies to data manipulation and reporting. The Eclipse component model means that these tools can be combined and integrated as needed.
Under the tooling platform is the Eclipse RCP. This is a generic platform for running applications. The Eclipse IDE happens to be one such application. This book focuses on how you can take advantage of the Eclipse RCP to build your application.
1.2 The Eclipse Rich Client Platform
Why is Eclipse particularly suited to building rich client applications? To answer that question, let’s look at the history of rich and thin clients and observe how the characteristics of Eclipse maintain the benefits and address the pitfalls of past approaches. Those characteristics are summarized here:
Components—Eclipse includes a robust component model. Eclipse-based systems are built by composing components known as plug-ins. Plug-ins are versioned and can be shared by more than one application. Multiple versions of the same plug-in can be installed side by side, and applications can be configured to run with the exact versions they need. This approach is attractive as it allows applications to evolve over time by adding and replacing components.
Middleware and infrastructure—On top of this component model is a set of frameworks and facilities that makes the job of writing client applications much easier. The Eclipse RCP is essentially the middleware function that you don’t want to write because it is a means, not an end, for your domain. It includes facilities such as a flexible UI paradigm, scalable UIs, extensible applications, Help support, context-sensitive Help, network updates, error handling, and much more.
Native user experience—In contrast to what is provided by thin clients, users want a rich, comfortable, and native user experience. This includes a smooth, responsive UI that integrates into the desktop. The Eclipse Standard Widget Toolkit (SWT) provides a graphical user interface (GUI) toolkit for Java that allows efficient and portable access to the native UI facilities of the OS.
Portability—Thin clients have the advantage of running everywhere. Eclipse provides support for heterogeneous OSs and client environments, ranging from traditional PCs, to thinner devices such as tablets and kiosks, down to mobile and embedded devices such as PDAs and smartphones. As long as you can find a Java Virtual Machine (JVM) with the J2ME Foundation libraries or greater (e.g., J2SE 6.0), you can run your client. Chapter 23, “RCP Everywhere,” talks about how to use Eclipse to design clients that essentially run everywhere.
Intelligent install and update—Controlling the costs associated with deploying and maintaining rich client applications was a problem in the early days. Eclipse’s component framework enables plug-ins to be deployed and updated using any number of mechanisms: HTTP, Java Web Start, repositories, simple file copying, or sophisticated enterprise management systems. Chapter 26, “The Last Mile,” details the task of getting your Eclipse RCP applications to your users.
Disconnected operation—Because rich client applications run on a local machine, they can run stand-alone without a network connection. This is a major advantage over thin clients. Applications that are inherently disconnected can use local caches, replicas, and store-and-forward mechanisms to accommodate network interruptions.
Development tooling support—Developers in the first wave of rich clients enjoyed IDEs that helped them build their applications. Eclipse provides a first-class Java IDE that contains integrated tooling for developing, testing, and packaging rich client applications.
Component libraries—A component framework is not complete without a comprehensive set of components with which to build applications. The Eclipse community has produced plug-ins for building pluggable UIs, managing Help content, install and update support, text editing, consoles, product introductions, graphical editing frameworks, modeling frameworks, reporting, data manipulation, and much more. Some of these are discussed in Chapter 29, “Eclipse Ecosystem.”
1.3 Eclipse RCP over the Years
The Eclipse project did not start with the intention of building an RCP. Instead, its goal was to create a platform for integrating development tools. Eclipse as an RCP started in the Eclipse 2.1 release time frame as a hacker activity. The word was out that Eclipse-based IDEs were professional, good-looking, and polished, and they performed well. A few intrepid developers further observed that the same framework that made tooling easier to write and more attractive could be used to build more generic applications.
By and large they were right, but there were many challenges. The most obvious of these were the interweaving of assumptions based on Eclipse as a tooling platform and the resultant inability to change certain elements of the environment’s look and feel.
Eclipse 3.0 was a major enabling step for Eclipse as an RCP. Virtually all of the IDE-related interdependencies were eliminated, and many of the different parts of the UI were opened to customization. The groundwork for dynamic plug-in installation, removal, and updating was established with the introduction of an OSGi-based (http://osgi.org) runtime. These two work items amounted to a massive refactoring of the main aspects of the platform.
With these improvements, interest in RCP rose sharply and commercial applications began to emerge. IBM revamped its Lotus product suite to be based on RCP; NASA started using RCP for managing, modeling, and analyzing space missions; and RCP showed up unnoticed in applications in various domains. Today RCP is used as the basis of software platforms from banking and insurance to health care and geographical information systems.
This book’s release follows closely upon the release of Eclipse 3.5 (Galileo). Eclipse 3.5 contains countless improvements, refinements, and wholesale leaps in the support of diverse application scenarios. The tooling for creating and editing product definitions is one such leap. RCP developers are now able to define the branding, content, and deployment strategies for their products using purpose-built editors and wizards.
1.4 Uses of RCP
Over the life of the Eclipse RCP, we have seen quite a number and range of applications adopting the technology. A few are noted on the RCP applications page of the Eclipse RCP Web site at http://eclipse.org/rcp. There are, however, too many to detail here—or there, for that matter. Rather, we highlight two uses that stand out as compelling examples of what RCP is all about: IBM Lotus Expeditor and the NASA Maestro project.
1.4.1 IBM Lotus and Eclipse RCP
The Lotus team at IBM was one of the leading innovators in the use of Eclipse for generic applications. They were looking to build the next generation of the Lotus platform and productivity tools (e.g., e-mail, messaging, document management) for enterprises and address the following issues:
• Management costs
• Deploying coherent componentized systems
• Role-based function delivery
• Rich user experiences
• Collaboration
The Lotus team chose to build on Eclipse as a cross-platform, industrial-strength base to enable supporting applications such as messaging, document management, collaboration, and other business applications. An additional driver was that the extensible componentized Eclipse platform provides integration on-ramps for existing technologies. These requirements cannot be reasonably met with other technologies, such as the Flash and JavaScript client platforms.
The net result of this effort is the Lotus Expeditor platform, a server-managed application container that runs on the desktop. In one usage of this technology, users interact with the system through a server-based portal. The portal supplies various applications depending on the user and his or her role. Application implementation technology varies from portlets and JavaServer Pages (JSPs) running on the server to Eclipse RCP-based applications that are dynamically downloaded to and run on the client. The set of applications available to a user is managed by the server, as is the deployment of those applications.
The application container that runs on the client is essentially a stand-alone Eclipse RCP shell with additional middleware, security, UI, and management support. Both platform-optional components and end-user applications are incrementally provisioned by the server; that is, the server provisions Eclipse plug-ins to the client. These plug-ins are dynamically installed and run, thus giving the user access to the application. A key benefit of this model is that only the platform extensions and applications a user has permission to use are provisioned, resulting in a minimal fit-for-purpose configuration.
The container itself is highly configurable. Figure 1-1 shows a typical Expeditor configuration. On the left side is a chooser that lists the applications available to the user. This list is based on the user’s role and is centrally configured. Again, some applications may run on the server, some on the desktop. Of those that run on the desktop, only the ones in use are physically installed on the desktop; the others are downloaded and installed on demand.
Figure 1-1 IBM Lotus Expeditor Client for Desktop
On the right is a set of views showing tools such as instant messaging contacts and data related to the application in the middle of the screen. In this example the application is a three-dimensional product lifecycle management tool displaying an automobile with its parts assembly. IBM Lotus Expeditor is completely pluggable, and the layout is highly customizable using declarative markup. A different user, in a different role, might experience a different look and feel and have access to a different set of applications. This is all configured on, and managed by, the server.
Eclipse and Expeditor proved to be a powerful platform, so in mid-2007 Lotus announced Notes V8, the Lotus Notes client within the Eclipse-based Expeditor environment, as shown in Figure 1-2. On top of that, the Lotus team revamped the Sametime V7.5 client to be based on Expeditor technology also.
Speaking of look and feel, notice that Expeditor and Notes look nothing like standard Eclipse. The Expeditor and Notes teams used the extensibility of the Eclipse RCP to create unique user interaction paradigms and models to fit their needs. They in turn expose a personality mechanism that allows consumers of Expeditor to further customize and brand the UI.
Today, Lotus technologies like Expeditor and Notes are used in various enterprises that range from financial services to banking to government and the public sector. Usage scenarios range from desktops to call center and bank teller workstations to kiosks.
1.4.2 NASA and the Eclipse RCP
In the late 1990s, NASA embarked on a software project that eventually became known as Maestro. It was an ambitious project to write Java-based tools for managing remote vehicles and experiments on space missions such as the Mars Polar Lander. They started out using various Java technologies, including applets, and progressively improved the capability and usability of their applications by moving to more powerful rich client approaches. This culminated in a series of scientific analysis and planning tools used in surface missions such as Spirit and Opportunity to explore Mars.
In mid-2004, the Maestro team switched to Eclipse as their development environment and the Eclipse RCP as the base for Maestro. Figure 1-3 shows the Eclipse RCP–based Maestro manipulating some Mars rover data.
Mission software has its unique characteristics, but by and large it is subject to the same requirements as the applications you write:
Diverse functional requirements—Any given mission involves a vast number of tools from data browsing to target acquisition to activity generation to spacecraft monitoring and reporting. These particular tools likely do not apply in your domain, but the underlying technologies (e.g., sophisticated user interaction, complex rendering, data management, reporting, etc.) and the related Eclipse plug-ins are of interest in a wide variety of scenarios.
Adaptation—The cumulative set of requirements on the system changes radically and quickly. Each mission is different, each experiment unique. In effect, each mission requires that a new suite of tools be brought together. The Eclipse component model enables the sharing and reconfiguration of functions.
Diverse user base—Mission software has a wide range of users from computer-shy domain experts to technophile engineers to members of the general public. The Eclipse frameworks simplify the creation of world-class, accessible UIs that scale to meet the needs of the user.
Central management—Much of the work done with mission software is, as the name implies, mission-critical. As such, the deployed software must be closely managed to ensure that it is consistent and correct. The Eclipse Equinox p2 update facilities ensure that the correct components are deployed.
Beyond Maestro and its use of Eclipse RCP facilities, the move to the Eclipse RCP has had a more profound impact. For example, the use of the Eclipse component model has fundamentally changed the way NASA teams build their mission systems. Components are developed independently by geographically and organizationally dispersed teams. These components must be integrated on a continuous basis. The fact that all components are defined in common terms (e.g., plug-ins and features), and their dependencies are fully expressed, brings structure and control to this process. NASA has, in effect, created a platform for space exploration mission software, and the teams are plugging into that platform.
The wealth of high-quality plug-ins available from the Eclipse project and elsewhere has allowed the NASA team to throw away enormous chunks of their existing code. For example, they had previously written their own update mechanism. Now they can use the one in Eclipse. The earlier software had its own UI frameworks and mechanisms. These have been replaced with the Eclipse Workbench model. The team as a whole is now able to focus more on the problem of mission software and less on the infrastructure and middleware inherent in writing sophisticated applications.
The use of the Eclipse RCP within NASA has spread rapidly. The team is now working toward an even more ambitious tool for the next Mars rover mission as well as numerous tools for advanced robotic systems for use on the moon and on Earth.
1.5 Summary
Eclipse is many things to many people. This book focuses on Eclipse as an RCP. As you have seen, rich client applications are making a comeback, and componentized approaches are making them even more attractive.
The Eclipse RCP addresses complex application scenarios that span the spectrum from thin to rich clients and from enterprise- and business-oriented systems to scientific and data management scenarios. The example use cases are from vastly different domains and environments, yet they illustrate Eclipse as it addresses the universal themes of
• Componentization
• Focus on the domain rather than the infrastructure
• Adaptation to changing requirements
The goal of this book is to describe the use cases, processes, and steps for using the Eclipse RCP to similar effect and benefit while building your rich client applications quickly and effectively.
1.6 Pointers
• The Eclipse RCP wiki (http://wiki.eclipse.org/RCP) is a great first stop for RCP information.
• To see more interesting uses of RCP, including case studies, check out the RCP community site (http://eclipse.org/community/rcp.php).