|
|
| Line 27: |
Line 27: |
| | == [[PTP/designs/2.x/debug_platform | Debug Platform]] == | | == [[PTP/designs/2.x/debug_platform | Debug Platform]] == |
| | | | |
| − | == Remote Services == | + | == [[PTP/designs/2.x/remote_services | Remote Services]] == |
| − | | + | |
| − | === Overview ===
| + | |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − | [[Image:remote_services.png|center]] | + | |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − | === Implementation Details ===
| + | |
| − | | + | |
| − | The main plugin for remote services is found in the <tt>org.eclipse.ptp.remote</tt>. 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 <i>remote services ID</i> which is used to identify the particular implementation. The following table lists the current remote services implementations and their ID's.
| + | |
| − | | + | |
| − | {| style="width:75%" align="center" border="1"
| + | |
| − | |-
| + | |
| − | ! Plugin Name !! ID !! Remote Service Provider
| + | |
| − | |-
| + | |
| − | | <tt>org.eclipse.ptp.remote</tt> || <tt>org.eclipse.ptp.remote.LocalServices</tt> || Local filesystem and process services
| + | |
| − | |-
| + | |
| − | | <tt>org.eclipse.ptp.remote.rse</tt> || <tt>org.eclipse.ptp.remote.RSERemoteServices</tt> || 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 <tt>PTPRemotePlugin</tt>. This class provides two main methods for accessing the remote services:
| + | |
| − | | + | |
| − | ; <tt>IRemoteServices[] PTPRemotePlugin.getAllRemoteServices()</tt> : 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.
| + | |
| − | | + | |
| − | ; <tt>IRemoteServices PTPRemotePlugin.getRemoteServices(String id)</tt> : This method returns the remote services provider that corresponds to the ID give by the <code>id</code> argument.
| + | |
| − | | + | |
| − | Typically, the remote service providers returned by <tt>getAllRemoteServices()</tt> 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 <tt>getRemoteServices()</tt> method can be used to retrieve the remote services at a later date.
| + | |
| − | | + | |
| − | ==== Obtaining Services: IRemoteServices ==== | + | |
| − | | + | |
| − | The <tt>IRemoteServices</tt> 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:
| + | |
| − | | + | |
| − | ; <tt>boolean isInitialized()</tt> : This should be called to check that the service has been initialized. Other methods should only be called if this returns true.
| + | |
| − | | + | |
| − | ; <tt>IRemoteConnectionManager getConnectionManager()</tt> : Returns a connection manager. This is used for creating and managing connections.
| + | |
| − | | + | |
| − | ; <tt>IRemoteFileManager getFileManager()</tt> : Returns a file manager for a given connection. A file manager is responsible for managing operations on files and directories.
| + | |
| − | | + | |
| − | ; <tt>IRemoteProcessBuilder getProcessBuilder()</tt> : 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 <tt>IRemoteConnectionManager.newConnection()</tt> 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 <tt>IRemoteConnection</tt> 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 <tt>IRemoteServices.getFileManager()</tt> specifying the newly create connection. The resulting <tt>IRemoteFileManager</tt> object has a number of methods for selecting and manipulating files:
| + | |
| − | | + | |
| − | ; <tt>IPath browseFile()</tt> : 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.
| + | |
| − | | + | |
| − | ; <tt>IPath browseDirectory()</tt> : Similar to browseFile() but the user can select a directory.
| + | |
| − | | + | |
| − | ; <tt>IRemoteResource getResource()</tt> : 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 ====
| + | |
| − | | + | |
| − | Coming...
| + | |
| − | | + | |
| − | ==== Other Services ====
| + | |
| − | | + | |
| − | Coming...
| + | |
| | | | |
| | == Tool Integration Services == | | == Tool Integration Services == |
NOTE: THIS DOCUMENT IS A DRAFT CURRENTLY UNDER DEVELOPMENT. THERE MAY BE SUBSTANTIAL CHANGES IN THE NEAR FUTURE.
The Parallel Tools Platform (PTP) is a portable, scalable, standards-based integrated development environment specifically suited for application development for parallel computer architectures. The PTP combines existing functionality in the Eclipse Platform, the C/C++ Development Tools, and new services specifically designed to interface with parallel computing systems, to enable the development of parallel programs suitable for a range of scientific, engineering and commercial applications.
This document provides a detailed design description of the major elements of the Parallel Tools Platform version 2.x.
The Parallel Tools Platform provides an Eclipse-based environment for supporting the integration of development tools that interact with parallel computer systems. PTP provides pre-installed tools for launching, controlling, monitoring, and debugging parallel applications. A number of services and extension points are also provided to enable other tools to be integrated with Eclipse an fully utilize the PTP functionality.
Unlike traditional computer systems, launching a parallel program is a complicated process. Although there is some standardization in the way to write parallel codes (such as MPI), there is little standardization in how to launch, control and interact with a parallel program. To further complicate matters, many parallel systems employ some form of resource allocation system, such as a job scheduler, and in many cases execution of the parallel program must be managed by the resource allocation system, rather than by direct invocation by the user.
In most parallel computing environments, the parallel computer system is remote from the user's location. This necessitates that the parallel runtime environment be able to communicate with the parallel computer system remotely.
The PTP architecture has been designed to address these requirements. The following diagram provides an overview of the overall architecture.
