Although some users are lucky enough to have a parallel computer under their desk, most users will be developing and running parallel applications on remote systems. This means that PTP must support monitoring, running and debugging applications on computer systems that are geographically distant from the user's desktop. The traditional approach take to this problem was to require the users to log into a remote machine using a terminal emulation program, and then run commands directly on the remote system. Early versions of PTP also took this approach, requiring the use of the remote X11 protocol to display an Eclipse session that was actually running on the remote machine. However this technique suffers from a number of performance and usability problems that are difficult to overcome. The approach taken in later versions of PTP (2.0 and higher) is to run Eclipse locally on the user's desktop, and provide a proxy protocol to communicate with a lightweight agent running on the remote system, as described in the preceding sections. In addition to the proxy protocol, there are a number of other remote activities that must also take place to transparently support remote development. PTP support for these activities is described in the following sections.
Remote Services Abstraction
PTP takes the approach that the user should be spared from needing to know about specific details of how to interact with a remote computer system. That is, the user should only need to supply enough information to establish a connection to a remote machine (typically the name of the system, and a username and password), then everything else should be taken care of automatically. Details such as the protocol used for communication, how files are accessed, or commands initiated, do not need to be exposed to the user.
An additional requirement is that PTP should not be dependent on other Eclipse projects (apart from the platform). Unfortunately, while the Eclipse File System (EFS) provides an abstraction for accessing non-local resources, it does not support other kinds of services, such as remote command execution. The only alternative to EFS is the RSE project, but introducing such a dependency into PTP is not desirable at this time.
In order to address these requirements, PTP provides a remote services abstraction layer that allows uniform access to local and remote resources using arbitrary remote service providers. The following diagram shows the architecture of the remote services abstraction.
The top two layers (shown in orange) comprise the abstraction layer. The lower (green) layer are the actual service provider implementations. By providing this separation between the abstraction and the service providers, no additional dependencies are introduced into PTP.
Three primary service types are provided:
- Connection management
- Create and manage connections to the remote system. Once a connection has been established, it can be used to support additional activities.
- File management
- Provides services that allow browsing for and performing operations on remote resources, either files or directories.
- Process management
- Provides services for running commands on a remote system.
There is also support available for discovering and managing service providers.
The main plugin for remote services is found in the org.eclipse.ptp.remote. This plugin must be included in order to access the remote abstraction layer. The plugin provides an extension point for adding remote services implementations. Each remote services implementation supplies a remote services ID which is used to identify the particular implementation. The following table lists the current remote services implementations and their ID's.
|Plugin Name||ID||Remote Service Provider|
|org.eclipse.ptp.remote||org.eclipse.ptp.remote.LocalServices||Local filesystem and process services|
|org.eclipse.ptp.remote.rse||org.eclipse.ptp.remote.RSERemoteServices||Remote System Explorer|
In addition to providing a remote services ID, each plugin must provide implementations for the three main services types: connection management, file management, and process management. The plugin is also responsible for ensuring that it is initialized prior to any of the services being invoked.
Entry Point: PTPRemotePlugin
The activation class for the main remote services plugin is PTPRemotePlugin. This class provides two main methods for accessing the remote services:
- IRemoteServices PTPRemotePlugin.getAllRemoteServices()
- This method returns an array of all remote service providers that are currently available. A service provider for accessing local services is guaranteed to be available, so this method will always return an array containing at least one element.
- IRemoteServices PTPRemotePlugin.getRemoteServices(String id)
- This method returns the remote services provider that corresponds to the ID give by the
Typically, the remote service providers returned by getAllRemoteServices() will be used to populate a dropdown that allows the user to select the service they want to use. Once the provider has been selected, the getRemoteServices() method can be used to retrieve the remote services at a later date.
Obtaining Services: IRemoteServices
The IRemoteServices interface represents a particular set of remote services, and is the main interface for interacting with the remote service provider. There are four main methods available:
- boolean isInitialized()
- This should be called to check that the service has been initialized. Other methods should only be called if this returns true.
- IRemoteConnectionManager getConnectionManager()
- Returns a connection manager. This is used for creating and managing connections.
- IRemoteFileManager getFileManager()
- Returns a file manager for a given connection. A file manager is responsible for managing operations on files and directories.
- IRemoteProcessBuilder getProcessBuilder()
- Returns a process builder for a given connection. A process builder is responsible for running commands on a remote system.
Connection Managerment: IRemoteConnectionManager
Once the service provider has been selected, the first thing that typically needs to be done is create a new connection. This is done using the IRemoteConnectionManager.newConnection() method. This method will allow the user to create a new connection using whatever method the underlying service provider uses for this. Typically it will be some kind of dialog that allows the connection parameters to be entered (hostname, username, password, etc.) The result will be an IRemoteConnection object that represents the connection to the remote system.
File Management: IRemoteFileManager
If file-type operations are required, then the next step would be to call IRemoteServices.getFileManager() specifying the newly create connection. The resulting IRemoteFileManager object has a number of methods for selecting and manipulating files:
- IPath browseFile()
- This will present the user with a dialog allowing them to select a file on the remote system. The returned path will be the path of the remote file relative to the remote system.
- IPath browseDirectory()
- Similar to browseFile() but the user can select a directory.
- IRemoteResource getResource()
- Given a path on the remote system, this will return an object that can be used to manipulate the remote file or directory.
Process Manangement: IRemoteProcessBuilder