14.2. Introduction

EnSight is used in numerous differing computational environments that make distributed application launch challenging. Furthermore, EnSight has grown from a basic client/server application into a multi-component application utilizing anywhere from two to thousands of communicating processes. Historically, the task of accessing and launching the various EnSight components has been built into many of the EnSight components. This approach is no longer adequate.

Today's computational environments tend to be far more complex. Secure login is required to access remote computers. Firewalls may be used to restrict network access. Queuing systems are used to manage and control access to changing computational resources. Data may reside on computers several network hops away from the user's desktop workstation. Because of issues such as these, EnShell was developed to work easily and flexibly in such environments while at the same time simplifying the core EnSight components. [Throughout this document 'EnSight components' refers to the EnSight Client, Server, SOS, CollabHub, and DR Client.]

EnShell's main purpose is to provide a virtualized environment for launching EnSight components. Optionally, EnShell can also provide communication encapsulation and routing for EnSight components automatically and when necessary. By focusing solely on launching and communication, EnShell excels in supporting complex, modern environments that entail remote and/or distributed access, queuing systems, and firewall and tunneling issues. Furthermore, in such environments EnShell provides a more flexible, easier-to-use approach than is possible with EnSight's legacy methods.

While EnShell provides numerous advantages, EnShell support is entirely optional today. EnSight 2024 R2 still supports all of the same legacy methods for accessing and launching other EnSight components. Indeed, EnShell is not of much value when simply running just the EnSight Client and Server on the same computer; running ensight in such situations is completely appropriate. However, given all of EnShell's strengths and improved usability, users should plan to migrate to EnShell for use in distributed environments. In a future version of EnSight, EnShell will become the sole way of launching EnSight in distributed environments (as a side note, removing the varying legacy methods from EnSight will also result in better quality assurance for EnSight in these areas).