RSE Architecture

The Remote System Explorer is structured into three major layors:

Service Layer
Subsystem Layer
UI Layer
RSE Service Layer
This is the headless, barebones API layer that is used to interact with differen
t protocols to provide remote services that can be integrated into RSE. By defau
lt, RSE defines the following types of services:
File Service - for listing, modifying, copying, and transfering remote file
and folders
Shell Service - for launching remote shells and interacting with the associa
ted IO
Process Services - for listing remote processes
New service types can be added as needed, either in core RSE, or extensions to t
he base. The service interfaces are defined loosely so that different implementa
tions of the same service can be made using different protocols. For example, th
e IFileService could be implemented locally with java.io, FTP, DataStore or some
other protocol. Similarly, the IShellService could be implemented locally via D
ataStore, telnet, SSH or something else.
RSE Subsystem Layer
RSE subsystems integrate the services of the service layer with connection infor
mation, model artifacts and persistence. Each subsystem is associated with a sin
gle 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 s
ervice 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 fo
r the subsystem layer.
Subsystems are contributed via the subsystem configuration extension point. A su
bsystem configuration is registered with one or more system type (i.e. Local, Li
nux, 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 i
nstantiate and configure the subsystems for that host. Each subsystem configurat
ion determines the subsystem to instantiate, the service implementation, the con
nector 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 imp
lement the same service. For example, there are both FTP and DataStore implement
ations of the IFileService. Subsystem configurations are contributed for both th
e FTP implementation and the DataStore one. In such cases, only one subsystem is
instantiated for each host, however that subsystem can have its configuration c
hanged from FTP to DataStore and vice versa.
Subsystems do not have to be implemented on top of a formally defined service la
yer, although this is highly recommended. Instead it may have all the services i
mplemented directly in the subsystem itself. If a subsystem does not use a servi
ce layer it should return null when implementing getServiceType().
Subsystems are RSE objects that are persistable and maintain higher level functi
onality 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 crit

eria for which to query a set of data. In addition to filters, there are more ar
bitrary properties that can be associated with a subsystem, each of which can be
saved and restored across sessions.
RSE UI Layer
The Remote System Explorer perspective provides views that render the subsystems
and associated artifacts. Users can create new connections, which can be expand
ed to reveal subsystems and the information the subsystems reveal about a system
.