With the RSE, you can create and manipulate the following artifacts, which we introduce here:
All the classes and interfaces mentioned here are defined in the org.eclipse.rse.core plugin.
The RSE's Remote Systems view shows all existing Hosts to remote systems. Hosts are objects that are persisted, containing the information needed to access a particular remote host. The view contains a prompt to create new Hosts, and pop-up menu actions to rename, copy, delete, and reorder existing Hosts.
Hosts contain attributes, or data, that is saved between sessions of the workbench. These attributes are
the host name, the remote system's host name and system type, an optional description, and a user Id that is
used by default by each subordinate subsystem, at host time.
Underneath, all Hosts are stored via RSE persistence in an Eclipse project named RemoteSystemsConnections, which
the user can enable for team support, allowing Hosts to be shared by a team.
To facilitate team-shared and user-unique Hosts,
Hosts are owned by profiles. These are simply folders in the RemoteSystemsConnections
project, as it turns out, within which all other data including Hosts are scoped. Internally profiles are realized as
SystemProfile objects, managed by the SystemProfileManager.
For each profile there is also a SystemHostPool object
created to manage the Hosts within that profile. There are menu actions for the
user to create and manage profiles. The collective of all Hosts of all active profiles are shown in the
Remote Systems view,
and the user can easily decide which profiles are active using the local pulldown menu of the Remote Systems view.
The list of profiles currently active is stored locally on each user's workstation, and not shared by teams.
By default, there exists a profile named Team, and a profile with a name unique to this user. When the first
host is created the user is asked to supply this unique name, which defaults to the hostname of their
workstation. Whenever a new host is created, the user is prompted for an active profile to contain the new
host. Both default profiles are active initially, so all Hosts from each are shown. There is a preferences
setting to show the host names qualified by their profile name. After synchronizing the RemoteSystemsConnections
project with a team repository, using the RSE team view, all profiles of all members of
the team will exist in the user's workspace, and hence
all the Hosts created by all the team members. However, only the two default profiles are active, so the Hosts
in the other profiles are not seen unless the user explicitly makes another profile active. This design allows
for:
As an aside, user IDs and passwords are not shared with the team repository, but rather stored only locally per workstation. Each subsystem can have a unique user ID, which if not set is inherited from its host, which in turn if not set is inherited from the user ID preferences setting for the appropriate system type.
When you expand a host, any tools registered with the Remote System Explorer are shown under the host. These tools are referred to as subsystems. The tool provider registers a subsystem configuration class via an RSE extension point, and whenever a new host is created, the configuration is asked to create a new subsystem object for that host. This subsystem is responsible for communicating with the remote host, and exposing artifacts and actions for working with remote resources. The subsystem configuration can elect not to supply a subsystem for a given host if it does not support the system type of that host
RSE supplies two subsystem configurations that supply common subsystems for all Hosts:
While not seen by the user, subsystem objects are required to return a connectorservice object via the getConnectorService() method. A connectorService object is an object implementing the IConnectorService interface. A connectorService object manages the live host to the remote system, and supports lifecycle methods for that host such as connect, disconnect, and isConnected. The communication layer for that host is entirely the programmer's responsibility, and might use sockets, JDBC, HTTP or SOAP. It is up the provider of the subsystem factory to author their own communication layer; the framework only dictates the handful of methods in IConnectorService, that the RSE UI depends upon. The framework supplies a base system class that is easily extended.
It may be the case that multiple subsystems, each from a different subsystem configuration, share the same live host for a given host object. To enable this, the framework supplies a base connector service manager class that can be used to manage a single shared connector service object across multiple subsystems. It uses a hashtable to store and return the connector service objects, keyed by a subsystem interface that all subsystems sharing the same connector service object are to implement. The subclass of the base connector service manager class supplies that interface. Further, the subclass must also implement the method for instantiating new instances of the connector service class, when no instance is found in the hashtable.
It is possible to author a subsystem configuration whose subsystems simply use the same connector service object as that used by the RSE-supplied subsystems. You might do this if the subsystem configuration uses only the RSE-supplied APIs for accessing remote objects, in which case there is no need for a unique communication layer. By sharing the same connector service object, it prevents the user from being prompted to signon multiple times. To do this, simply access any RSE-supplied subsystem for a given host, and ask for its connector service manager in your own subsystem's getConnectorServiceManager method.
When a subsystem is expanded, users usually see filters. Since subsystems typically list remote artifacts, it is typical that a mechanism is needed to allow users to define which artifacts they wish to see, with some form of filtering criteria. Filters are this mechanism. The filter support is fully supplied by the RSE framework. A filter is simply a ISystemFilter object containing a name and a collection of filter strings. Filter strings are just strings, which the subsystem is required to interpret. When a user expands a filter, the owning subsystem is asked to resolve the filter strings within the filter. The subsystem typically interprets each filter string as some form of filtering pattern, and returns a list of remote artifacts matching one or more of the filter string patterns in the filter. For example, file subsystems expect each filter string to represent a folder, and a file name pattern. Then, all files in the folder, matching the name pattern, are returned. The subsystem supplies the user interface the you use to create and change filter strings, so it is responsible for defining what the filter strings look like and for subsequently resolving those filter strings on a filter expansion. A default user interface for the filter string prompt is supplied, but it is a simple entry field.
It is possible to author a subsystem that does not support filters, if this is desired.
Subsystems do not actually "own" filters. Since each host has unique subsystems, if each subsystem owned its own filters then filters could not be shared across Hosts, which is sometimes desirable. Instead, filters are actually contained within filter pools. Filter pools are simply ISystemFilterPool objects which have a name and a collection of filters. Filter pools are owned by subsystem configurations, per profile. That is, each subsystem configuration will contain filter pools scoped by profile. Each such configuration plus profile grouping is known internally as a filter pool manager. Subsystems contain references to filter pools. By default, each subsystem configuration automatically creates one filter pool for each profile, named the "xxx Filter Pool", where "xxx" is the name of the profile. Subsystems contain references to filter pools, so that as the filters in the pool are created, changed, deleted or re-ordered, those changes are automatically reflected in every subsystem (and hence host) that references that filter pool. By default, subsystems are given a reference to the default filter pool in their host's profile (for their parent subsystem configuration, so file filters are not used in command subsystems, for example).
By default, users do not see filter pools. Instead, filters are created in the default filter pool referenced by this subsystem. As a result, users will see the same list of filters for every host. However, users can use a preference setting to see filter pools. In this case, when a subsystem is expanded, the users see the filter pools referenced by this subsystem. Only then when a filter pool is expanded will the user see the filters within that filter pool. In this mode, users also see new actions to create filter pools and to add and remove references to filter pools within a subsystem. Whenever filters are changed by the user, this change is reflected in all subsystems that reference the parent filter pool. This design of filter pools owned by profiles, and subsystems that reference filter pools, facilitates filter sharing:
Many of the default characteristics of the Remote System Explorer view and perspective are configurable by each user by way of the Remote Systems node of the Preferences window, accessible from the Window pull-down of the main menu. Furthermore, many of these preferences are directly accessible from the pull-down menu of the title bar for the Remote Systems view. These preferences, like all preferences, are unique to each user and not shared by the team, although they can be exported and imported.
The programmatic front door to all the artifacts in the RSE is the System Registry, which is an object implementing ISystemRegistry. This is a singleton object that you can access by calling the static method getSystemRegistry() in the SystemStartHere class in the org.eclipse.rse.ui plugin.
