Architecture¶
This page describes the three-tier architecture of OneClickExt, explaining what each component does, why the system is structured this way, and how the tiers communicate with each other.
Overview¶
flowchart LR
user([User])
subgraph oneclick["OneClick Server"]
oc[OC-Client]
sl[Scriptlauncher]
end
subgraph ss_host["SpectroSERVER"]
daemon[OcExt-Daemon]
ss[SpectroSERVER]
scripts[Scripts]
end
device[Device]
user -->|HTTP| oc
oc <--> sl
sl <-->|RMI| daemon
daemon <--> ss
daemon --> scripts
scripts -->|SSH| device
ss -->|SSH| device
The daemon is typically installed on the SpectroSERVER host (see Installation with Spectrum). It can also run on a dedicated separate host, in which case the daemon is installed using the standalone guide and configured to connect to SpectroSERVER via oneclickext.mls.primary and oneclickext.ss.host.
flowchart LR
user([User])
subgraph sl_server["Scriptlauncher Server"]
sl_servlet[Script Server]
end
subgraph scriptserver["Scriptserver"]
daemon[OcExt-Daemon]
scripts[Scripts]
end
device[Device]
user -->|HTTP| sl_servlet
sl_servlet <-->|RMI| daemon
daemon --> scripts
scripts -->|SSH| device
No Spectrum installation required. Scripts are invoked via the Script Server HTTP interface. See Standalone Installation.
Why a separate server daemon?¶
The Spectrum CORBA API requires a Spectrum username and runs only on the server host. Rather than embedding CORBA access inside the client applet (which runs in each user's browser session), OneClickExt uses a long-running daemon process that holds the single CORBA connection. The client communicates with this daemon over RMI.
This design has several consequences:
- The Spectrum username (
oneclickext.ss.user) is configured once on the server, not per user. - Script execution happens on the server host, not in the browser.
- The daemon can reconnect to Spectrum after a CORBA failure without any client-side action.
- Multiple OneClick Console users share the same daemon and its thread pool.
The two modules¶
OneClickExt ships with two separately-licensed functional modules:
| Module | License code | What it provides |
|---|---|---|
| ScriptLauncher | sl |
Launch shell scripts on managed devices from the Spectrum OneClick Console or a Script Server |
| DCSWatch | wt |
Manage Spectrum watch objects: Create DcsWatch, Copy Watch(es), Delete DcsWatch(es), Set DcsWatch Attributes |
Both modules are implemented in the same daemon and client. Which ones are active depends on the license.
The client¶
The client runs inside the Spectrum OneClick Console as a Java Swing application, loaded via JNLP. It connects to the server daemon at startup using RMI.
The RMI connection details are passed to the client as JVM system properties set in the JNLP launch file ($SPECROOT/tomcat/webapps/spectrum/oneclickext.jnlp). The installer sets these automatically:
oneclickext.rmi.host=<host>
oneclickext.rmi.port=<port>
If the primary server is unreachable, the client automatically tries a secondary server configured via:
oneclickext.rmi.secondary.host=<host>
oneclickext.rmi.secondary.port=<port>
This failover is attempted once at connection time: the client tries primary first, then secondary. If neither responds, the extension menu items are not shown.
When a script item in the menu config specifies a host and port directly (using the <item name="ScriptName_<hostname>_<port>"> syntax), that address overrides the system properties and both servers are bypassed.
The server daemon¶
The daemon is a standalone Java process (OneClickExtServer) that:
- Creates a local RMI registry and binds itself to it.
- Reads its configuration from
oneclickext.props. - Connects to SpectroSERVER via CORBA.
- Maintains a thread pool (
OneClickExtExecutor) for running scripts concurrently.
Script execution is queued: incoming runScript RMI calls add a ScriptRunner to a blocking queue, and worker threads pull from that queue. The number of worker threads is controlled by oneclickext.exec.threads.
Configuration hot-reload¶
The additional properties file list (oneclickext.additional.props) is re-evaluated before every script call. This means new scripts can be added or existing ones reconfigured by editing the additional props file, without restarting the daemon. Core settings (RMI ports, SpectroSERVER connection) require a restart.
The Script Server (optional)¶
The Script Server is a Tomcat servlet (ScriptServer) deployed separately from the daemon. It provides HTTP endpoints that allow scripts to be invoked from a web browser or external system without requiring the full Spectrum console.
The Script Server connects to the daemon over RMI (configured via sl.rmi.host and sl.rmi.port) and delegates all script execution to it. It also handles output history and syslog notifications independently.
See the Script Server reference for configuration details.