RCE provides two possibilities to connect your RCE instance to other RCE instances and to use the user-integrated tools and components published on those instances: The RCE network connections and SSH connections. RCE connections are meant to be used only in a trusted network (e.g. your institution's internal network). The RCE network traffic is currently not encrypted. This means that it is not secure to expose RCE server ports to untrusted networks like the internet. In the case that it is not possible or not secure to use RCE connections, SSH connections provide a more secure alternative. The following table compares the two connection types:
Table 3.13. Connection types
| Connection type | Access to all published tools | Supporting all RCE network functions (e.g. remote monitoring) | Encrypted traffic | Using login name and password or RSA key | Symmetrical |
|---|---|---|---|---|---|
| RCE connections | yes | yes | no | no | yes |
| SSH connections | yes | no | yes | yes | no |
RCE connections are meant to be used only in a trusted network (e.g. your institution's internal network). To build up a network of RCE instances, at least one of the instances has to be configured as a server (see the "Configuration" section or the sample configuration file "Relay server" for details).
On the client side, RCE network connections can be added in the "network" view by clicking "Add network connection" and entering the hostname and port of an RCE server instance. The connections are shown in the "RCE Network"->"Connections" subtree. They can also be edited, connected and disconnected in the network view. However, the changes made here are not saved in the configuration yet, i.e. they will be lost when RCE is closed or restarted. To permanently add connections, you can edit the configuration file (see the "Configuration" section for details).
In the "RCE Network" -> "Instances" subtree all RCE instances in the network are listed. When expanding the entry for an instance, you can see monitoring data like CPU or RAM usage for this instance, and the published components and tools of this instance (if it has any).
The published components and tools of the other instances in your network are also shown in the palette of the Workflow Editor. From there, you can use them in your workflows just like your local components and tools. When you start a workflow, in the "Execute Workflow" wizard there is an overview which component will be run on which RCE instance. If a component is available on several instances, you can choose here on which instance it should be run. In the same wizard, you can also choose another instance as the "Controller Target Instance", which means that the workflow execution will be controlled by this instance (see the section "Configuration Parameters" for more information). This can be useful when you start a long-running workflow where all components are run on remote instances and you do not want to keep your local computer connected all the time.
SSH connections provide a more secure alternative to the standard RCE connections and can be used to access tools remotely. The published tools are shown in the palette of the client's Workflow Editor (this may take a few seconds after connecting, as the tool list is fetched from the remote hosts every few seconds). From there, you can use them in your workflows just like your local components and tools. Differently from tools accessed by RCE network connections, in this case the component is shown to be executed on your local instance in the Workflow Execution wizard.
Also workflows that were published on the remote instance (for information about the publishing see section "Remote Tool and Workflow Access") are shown as components in the palette of the client's Workflow Editor in the group "SSH Remote Access Workflows" (if the client runs RCE 7.1 or newer). These remote workflows can be added to workflows and executed like local components/tools.
The RCE instance that publishes the tool, or another instance connected to it by RCE network connections, has to be configured as an RCE remote access server (see the "Configuration" section or the sample configuration file "Remote access server" for details).
Note
When configuring an SSH account using a key file, note that for using key files, both server and client have to run RCE 7.1 or newer and that only RSA-Keys in the OpenSSH format are supported by RCE. You can generate such keys on Linux e.g. using the "ssh-keygen" tool (which creates the correct format by default). On Windows, you can use the software "puttygen" to generate a key (choose the type "SSH-2 RSA") and convert it to the OpenSSH format ("Conversions"->"Export OpenSSH key" in puttygen).
On the client side, SSH connections can be added in the "network" view by clicking "Add SSH Remote Access Connection". In the following dialog, enter the hostname and port of an RCE instance that provides an SSH server as well as the user name and the authentication data of an SSH account configured on this instance. Depending on the SSH account, you have to authenticate using a passphrase or by an RSA private key file. If your private key is protected by a passphrase, select the authentication type "Keyfile with passphrase protection", else select "Keyfile without passphrase protection".
The connections are shown in the "SSH Remote Access"->"SSH Remote Access Connections" subtree. They can also be edited, connected and disconnected in the "network" view. It is possible to store passphrases using the Eclipse Secure Storage Mechanism (this is only available on Windows). However, the changes made here are not saved in the configuration yet, i.e. they will be lost when RCE is closed or restarted. To permanently add SSH connections, you can edit the configuration file (see the "Configuration" section for details). However, it is not possible yet to store the passphrases for such connections permanently.
This section describes how an RCE network with several project partners could be structured. RCE provides two different types of connections between RCE instances which can both be used to access published tools:
Standard RCE connections are meant to be used in a trusted (internal) network, as the data exchanged via those connections is not encrypted. These connections are bidirectional and allow to share more data than just the information about published tools (e.g. they can be used to access data about executed workflows on another instance).
RCE SSH connections use the SSH protocol to provide an encrypted connection. They are meant to securely connect RCE instances from different institutions over the internet. These connections are one-directional and allow the client to run published tools and workflows on the server (of course, both instances can be configured as client AND server at the same time if necessary so they can use each other’s tools).
In practice, most partners will probably use both types of connections: RCE connections to connect different RCE instances within their institution and SSH connections to connect to the other partners. The following figure gives an example of how such a project network could be structured:
The four project partners in the example all have an internal network of RCE instances which are connected by standard RCE connections. SSH connections are used to connect between the different partners. Therefore, each partner who wants to publish tools to other partners has one RCE instance which is configured as an SSH server. Only this one instance per institution has to be reachable via SSH over the internet, all other instances in the institution’s internal network can be connected to it by standard RCE connections and still publish tools to the other partners/access tools published by other partners.
In the example, the RCE instances in Partner A’s network can access the tools published in Partner C’s network and vice versa. One of the instances from Partner D can access Partner C’s tools; and all the partners can access the tools in Partner B’s network.
Each institution in the example has a different internal setup, all of which are possible:
Partner A has a dedicated RCE server where the published tools are located, which is connected to the SSH server by an RCE connection. All other RCE users in the internal network are connected to this server.
Partner B has put all the tools directly on the SSH server.
In Partner C’s network, some tools are located on the SSH server, but some tools are also published by users directly on their own machines. As long as they are connected to the SSH server, also those tools can be used by the other partners.
Partner D has not published any tools and has no SSH server, instead the users’ computers connect directly to the other partner’s SSH servers.