Eclipse-based applications targeted at developers’ tasks and needs are proliferating. But what does Eclipse have to offer to other user groups, to be more precise non-technical user groups in particular in combination with Rich Client Platform applications?
Just take a closer look at your daily work, and you may probably realize that the greater part of your working routine is spent doing the research and gathering information required for your job - no matter how this information is structured.

What’s the idea behind this series?

First and foremost, the intention of the series is to show how an Eclipse RCP can be used to quickly and efficiently provide the staff of an enterprise with the up-to-date information relevant for their work. How easily this can be achieved will be demonstrated using a typical application. Last but not least, writing this article will help me get my thoughts sorted and to compile all the key information on EclipseCon that I will present during a talk at some later stage.

A short overview of the topics to be discussed:

• Preliminary considerations
• General Eclipse-based architecture
• (EMF) data model
• Use of Eclipse IDE components
• Data management
• Data updates and synchronisation
• Data processing
• UI stripping
• Collaboration

Distributed Information Repositories

A surprising number of enterprises on a more web-focused infrastructure consisting of context-dependent web applications and portals that enable users to obtain information. And for these there is an array of applications for almost each topic each with its own user interfaces, operational concepts and data visualisation. What is even more, as a rule this wealth of information belonging to individual systems is not connected in any way. The task of merging all this information is left to users who are responsible for making the connections. Another problem arises then, namely that a user’s view on data structures may differ significantly from that of other users working in different fields. Generally, users have to first explore where to obtain the needed information and how it is structured. Consequently, collaborative activities often sidestep such information distribution applications, they cannot be coordinated or may simply be dropped because the process would be too laborious.

Centralized Data Distribution continues on the Client

Another point to mention is that users often go on to process the information further. If I succeed in my search for a presentation on the web, I may adapt it to my needs, delete some slides, add some more…finally ending up with new information units distinct from the central data pool. Furthermore, management does not know which information has any relevance or qualitative use for a specific user, nor can any other central instance update the information: it is up to users alone to keep them updated. Such scenarios can only be avoided if the information distribution process is carried over to the client by offering possibilities that reflect user-specific applications or processes. This should be considered a valid requirement for any RCP application, since specific bundles (e.g. JDT for Java source code editing) with information editing capabilities are available.

Local Data Processing – natural use only for a few user groups

It is nothing unusual for developers to edit source code on their local machine and update the server system at intermittent intervals. Nobody would even think of distributing each bit of data manipulation separately. Only after the source code has been updated to a repository can the pertaining business process such as deployment, unit testing etc. be started. Alas, as much as this ‘division of labor’ between server and client may make sense, it is not that widespread and many users have no local access to data or are hampered by much shorter synchronisation intervals, which at worst can be a website request response cycle. The necessity of such excessive communication is hardly ever challenged, probably because the benefits of balanced data management during the process itself is often underestimated. And then there is the higher degree of distribution which drives up maintenance and security costs. In most cases, it may safely be assumed that complex data structures, even those with high demands on the UI and user interaction, can be optimally visualised using the graphical powers offered by an Eclipse Rich Client. And integration in the operating system (Desktop-Notification, OLE, FileTransfer, TrayIcon, …) also offers the great advantage of greatly simplified communication with other software applications.

Information from Third-party Suppliers – required, but often underestimated

Sure, there are applications that provide all the information that users need, but most processes have information requirements that force users to leave an application or even complete system landscapes. A client which draws on content from different repositories would provide an optimal connecting link. Information is only connected where this is really needed and in such way that it offers added value to users. Finally, the feature of allowing third-party vendor access to client applications could deliver additional momentum to application development, without the necessity of major changes to the IT environment.

Prospects

The next step now is to lay down some technical aspects focusing on Eclipse-related considerations and lay the foundation for an RCP implemenation. Let me, dear reader, apologize in advance for the in part rudimentary implementation of my software example, as it is not meant to be an application for demonstrating the built-in functionalities of Eclipse. Rather, my intention is to exemplify a specific perspective taken in building RCP applications. Stay tuned!