The Remote System Explorer is structured into three major layors:
This is the headless, barebones API layer that is used to interact with different protocols to provide remote services that can be integrated into RSE. By default, RSE defines the following types of services:
New service types can be added as needed, either in core RSE, or extensions to the base. The service interfaces are defined loosely so that different implementations of the same service can be made using different protocols. For example, the IFileService could be implemented locally with java.io, FTP, DataStore or some other protocol. Similarly, the IShellService could be implemented locally via DataStore, telnet, SSH or something else.
RSE subsystems integrate the services of the service layer with connection information, model artifacts and persistence. Each subsystem is associated with a single service type. For example, the file service subsystem is associated with the file service. Each subsystem is associated with one or more services from the service layer, a connector service and, in some cases, a model adapter, which is used to convert artifacts from the service layer into a form that is suitable for the subsystem layer.
Subsystems are contributed via the subsystem configuration extension point. A subsystem configuration is registered with one or more system type (i.e. Local, Linux, Windows, etc.). When there is an RSE host of a particular system type, the subsystem configurations that are registered with that system type are used to instantiate and configure the subsystems for that host. Each subsystem configuration determines the subsystem to instantiate, the service implementation, the connector service and anything else that requires customization for it's service.
Multiple subsystem configurations can exist for the same type of subsystem. This will be the case when there are more than one protocols that can be used to implement the same service. For example, there are both FTP and DataStore implementations of the IFileService. Subsystem configurations are contributed for both the FTP implementation and the DataStore one. In such cases, only one subsystem is instantiated for each host, however that subsystem can have its configuration changed from FTP to DataStore and vice versa.
Subsystems are RSE objects that are persistable and maintain higher level functionality from the service layer. Subsystems that are used to query information on a host often have filters. Filters provide the user the means to specify a criteria for which to query a set of data. In addition to filters, there are more arbitrary properties that can be associated with a subsystem, each of which can be saved and restored across sessions.
The Remote System Explorer perspective provides views that render the subsystems and associated artifacts. Users can create new connections, which can be expanded to reveal subsystems and the information the subsystems reveal about a system.