Section 1.4.  Uses of RCP - Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications

1.4. Uses of RCP

Even in the relatively short 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 hereor there for that matter. Rather, we highlight two uses that stand out as compelling examples of what RCP is all about: IBM Workplace and the NASA Maestro project.

1.4.1. IBM Workplace Client Technology™

The Workplace 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 productivity tools (e.g., email, 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 Workplace 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.

The net result of this effort is the Workplace Client Technology platform, a server-managed application container that runs on your desktop. One use of this technology has users interact with the system through a server-based portal. The portal supplies various applications depending on the user and their role. Application implementation technology varies from portlets and Java server 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 standalone 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 Workplace configuration. Down the left side is a chooser that lists the applications available to the user. This list is based on a user's roles 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 Workplace

[View full size image]

On the right are 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. The IBM Workplace Managed Client™ is completely pluggable and the layout 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.

Speaking of look and feel, notice that Workplace looks nothing like standard Eclipse. The Workplace team used the extensibility of 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 Workplace to further customize and brand the UI.

Workplace is in use today 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 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 exploring Mars.

In mid-2004, the Maestro team changed to use Eclipse as their development environment and the Eclipse RCP as the base for Maestro. Figure 1-2 shows the Eclipse RCP-based Maestro manipulating some Mars Rover data.

Figure 1-2. Maestro

[View full size image]

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) 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 Update Manager ensures 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 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 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 Eclipse RCP within NASA has spread rapidly. The new Ensemble project seeks to broaden Maestro and form a base for all NASA mission software tools.