Supported Configurations for the Web Gateway

Supported Configurations

During development, a web server, a Web Gateway, and an InterSystems IRIS instance may be on a single machine. In a large scale deployment, there may be multiple web servers and multiple InterSystems IRIS instances, all on different machines. Each web server requires a dedicated Web Gateway. A single Web Gateway can communicate with multiple InterSystems IRIS instances.

The InterSystems IRIS Gateway Registry enables you to monitor and manage the connections. All web server installations and Web Gateway installations are registered with InterSystems IRIS as they connect. The registry contains the infrastructure to allow InterSystems IRIS code to interact with connected Web Gateway installations for the purpose of reading and writing the configuration and monitoring the system status and Web Gateway Event Log.

Supported Web Servers

You can use the following web servers with the InterSystems Web Gateway in a production environment:

• Microsoft Windows:

  • Microsoft IIS. The connectivity options include the default IIS option and several alternative options for IIS 7 or later.

  • Apache. The connectivity options include the default Apache option and several alternative options for Windows Apache.

  • Nginx

• Linux, UNIX®, and macOS:

  • Apache. Several connectivity options are available: the default Apache option, the NSD, locked-down Apache web server, and several other atypical Apache configurations.

  • Nginx

More detailed information on supported web servers can be found in Supported Web Servers in InterSystems Supported Platforms.

The Web Gateway provides high-performance connectivity solutions for Microsoft, Apache, and Nginx web servers. In addition to these solutions, connectivity to InterSystems IRIS through the CGI is available for all supported operating systems.

Microsoft web servers support a multi-threaded API which allows extensions, in the form of dynamically bound libraries, to be made to the web server’s core functionality. Current versions of the Web Gateway make full use of these APIs in order to bring high-performance web connectivity to the InterSystems IRIS system. The Windows version of Apache also operates in an exclusively multi-threaded mode and, as such, can also take advantage of the Web Gateway implemented as a dynamically bound library.

The UNIX® versions of Apache are architecturally different from the Microsoft Windows based web servers in that they are not exclusively multi-threaded. Apache version 2.4 is implemented using a hybrid model made up of threads and multiple processes. In this model, each UNIX® process is effectively a multi-threaded server in its own right.

The Apache web server publishes a proprietary API in addition to supporting extensions implemented as CGI modules. Extra functionality can be added to Apache by means of user-defined modules (compiled C programs). In fact, a large part of Apache’s core functionality is implemented as a set of modules. You can add modules to Apache by one of two methods. First, the source to the module can be compiled directly into the Apache core. This option arguably offers the best performance but, unfortunately, involves reconfiguring and rebuilding the web server. As an alternative to building the module source directly into the Apache core, Apache versions 1.3 onwards support extensions implemented as dynamically linked libraries. This facility allows you to take advantage of the high performance of Apache modules without the need to physically build the module into the core of Apache. The CSP module is distributed as a Windows Dynamic Link Library (DLL), and as a UNIX® Dynamic Shared Object (DSO). UNIX® Shared Objects are conceptually similar to a Windows Dynamic Link Library (DLL) and are linked at run time. The overhead involved in linking to a library at run time is very low on modern operating systems.

Unlike other web servers, Nginx is based on an asynchronous event-driven architecture. With the event-driven architecture, notifications or signals are used to mark the initiation and completion of each individual operation. A consequence of this design is that while web requests are being processed, resources can be temporarily released and used by other operations. Resources can be allocated and released dynamically and are only associated with the processing of a web request while they actually required. This leads to a highly optimized use of memory and CPU. The asynchronous nature of this architecture results in threads executing concurrently without blocking each other, thus further enhancing the sharing of resources that might otherwise be associated with a thread waiting on a blocking operation. Nginx is supplied with an API to allow extensions, such as CSP, to be added to its core functionality. However, unlike other web servers, extension modules must be built into the web server core at compilation time. Nginx does not support dynamically loaded extension modules.

An alternative architecture is also provided in which the functionality of the Web Gateway is implemented as a stand-alone executable, operating in its own process and not directly connected to a web server. This version of the Web Gateway is known as the NSD. In this context, the NSD is responsible for providing the Web Gateway’s core functionality and maintaining persistent connections to InterSystems IRIS. The web server communicates with the NSD via small modules of which there are two types: modules that work to the hosting web server’s proprietary API and modules implemented as CGI executables. The NSD-based architecture is therefore used in cases where there is a requirement to extend the web server by means of the CGI standard, or in cases where it is desirable to disengage the functionality of the Web Gateway from that of the hosting web server.