CONNX has positioned itself in the marketplace as "Simplified Data Access" for over 20 years. But what does "Simplified Data Access" really mean?

This high-level "view" of CONNX helps to explain how it's done.

Here is a selection of relational and legacy ISAM/hierarchical data sources that CONNX supports:

It is difficult to provide end users a consistent data access interface because different data sources have different external capabilities (such as record locking). A significant development effort would be required to extract a single value from both legacy systems data and direct modern relational API. CONNX provides end users a consistent interface to access their data no matter what the source, shielding the user from the complexity, development and quality assurance costs while providing consistent access methods and functionality across all the supported DBMS systems. The following is the organizational chart of CONNX Client and Server Components:

As the chart shows, CONNX uses a client/server based networked architecture. The CONNX client can be installed on every desktop in the organization or only on a select number of machines that serve data through a web interface or SOA application.

CONNX supports a variety of enterprise organizational models.

If all components reside on the same machine, it is possible to use either a special in-memory pipe for faster communication, or the operating system loop-back device for ultra-fast communications.

CONNX supports the following access methods:

All the access methods will route through the client and then to a server which has the most direct contact with any back-end database.

A CONNX server may either be a process separate from the CONNX Client or it may be a DLL/library extension to the CONNX Client. Non-relational ISAM databases are usually implemented in a separate CONNX Remote server process and relational databases are implemented as DLL/library extensions to the CONNX Client. Any supported database with an API that services a network protocol will be implemented as a DLL/library extension to the CONNX Client. The workload is about the same whether using a DLL/library extension or a remote server.

The CONNX client and server perform the following distinct functions:

The DLL/library extension workload is determined by the capabilities of the back-end database:

The CONNX Remote server contains a CONNX Listener component, a separate process that spawns the correct type of independent server processes to service user requests. The CONNX Listener requires a minimal amount of system resources.

The JDBC/RCI server can be considered a CONNX client with an attached listener, with the additional functionality and protocol support needed by JDBC and RCI applications. The JDBC/RCI server supports multiple threads of execution and directly links to the end user's CONNX application if they share the same machine.

The CONNX License server service is a networked application that combines the elements of both a listener and a server. The CONNX License server requires a minimal amount of system resources.

The CONNX Client and CONNX License server service are available on Windows, Linux, Linux Z-Frame, and AIX. Because the CONNX CDD manager and license configuration utilities are only available on Windows, CONNX requires at least one Windows machine to create and manage CDDs, and to install and configure CONNX licenses. Windows and UNIX have separate CONNX client configurations and configuration utilities.