|
There are several differences, but all center around the location of the Sox client that communicates with the remote Sedona
device.
-
Sox Gateway
With Sox Gateway access, the Sox client is in the JACE/station. Instead of Workbench connecting to the Sedona device, either
directly or tunneled, the station itself connects to the Sedona device. In this case, the station does not require (or use) the SoxTunnelService.
Since you are only making a Fox (station) connection, your Workbench only needs the Sedona-related modules. However, the station’s
host platform requires the necessary Sedona environment files (manifests, kits, platform archives) used by this and other networked devices. The benefit of this approach is that the JACE/station
becomes the single point of management for all Sedona devices it has networked to it. See JACE workflow and Installing Sedona environment files in a JACE, and also Sedona environment overview for related details.
Finally, when accessing the app in a Sedona device through the Sox Gateway, no new “session nodes” are created in Workbench’s
Nav tree (for example, no Sox session). You can simply navigate to the Sedona device’s app. See Using the Sox Gateway.
-
Sox Gateway
With Sox tunneling, the Sox client is Workbench—that is, Workbench initiates the Sox connection. The “tunnel” capability allows
the connection to occur tunneled “through” the JACE, where its station requires the SoxTunnelService. This allows access to
Sedona devices not directly reachable.
However, because the Sox client is Workbench, this requires (at a minimum) your Workbench to have (in addition to Sedona-related
modules), all the necessary Sedona manifests used by the device in order to make a successful Sox connection.
Opening a Sox tunnel creates a new “session node” in the Nav tree under the Niagara host/station that you are tunneling through.
You manage this session just like any Fox (station) session or “direct” Sox connection, that is: Connect/Disconnect/Close.
|