ABIS Infor - 2016-11
Where has the DB2 Connect Gateway gone?
Abstract
The path taken by application requests to reach the DB2 data store on z/OS for many years pivoted around the, "classic" DB2 client and the DB2 Connect gateway. These pieces of software, for DB2, bridged the gap between the "distributed" (DB2 for LUW) environment and the host (DB2 for z/OS, IBM i). The type of application ("legacy" client, web, mobile or cloud) will for sure be a criterion to decide on the connection topology.
What is the current state of the connection landscape for applications that have a DB2 backend as a target? What are the options, if any?
DB2 connection topologies, the big picture.
What is missing?
DB2 Connect or IBM Data Server driver?
What are we talking about?
What we are looking for when a client DB2 application wants to connect to DB2 for z/OS is a piece of software that will translate the application's data interface protocol to DRDA, which is what DB2 for z/OS's DDFs language is. This is where DB2 Connect and the IBM Data Server driver come in.
Currently there is a strong preference for the connection path without the DB2 Connect Gateway. This option results in a simpler infrastructure and better performance caused by the elimination of an intermediate stage between the client and DB2. Software upgrade and code maintenance becomes less complex. The Data Server driver, builds on "type 4" driver technology, and delivers "Connect" features as there are connection pooling, transaction pooling, and Sysplex workload balancing.
You still need Connect licensing, basically each client connecting directly to the DB2 for z/OS backend needs a "Connect" license. Where we used to set this up via the Connect Gateway, this can now be centrally managed via DB2 Connect Unlimited (Advanced) Edition, the alternative being that you distribute a license to all client systems that need to directly connect.
What concerns client functionality the IBM Data Server Driver replaces the "classic" client instance/directory configuration approach by the db2dsdriver.cfg file. The driver package is quite complete and includes support for JCC, ODBC/CLI, Open Source interfaces, CLPPlus, OLE DB and .NET. (In a Java only environment the IBM Data Server Driver for JDBC and SQLJ can be a valid alternative)
Only if you need administrative tools and features on the client side, or you want to compile programs and make use of the Embedded SQL application interface, the setup and configuration of the DB2 Data Server Client is necessary.
Broaden the connectivity spectrum: DB2 connectivity becomes z/OS connectivity.
What are we talking about?
If you want to reuse optimally the assets running in the mainframe environment, if on the client side the REST/JSON technique is used, then on the mainframe side there is z/OS Connect. z/OS Connect provides a common and consistent REST/JSON interface to the different mainframe backend systems. The z/OS Connect code is written to run in WAS Liberty Profile for z/OS. Access to data in DB2 for z/OS via z/OS Connect is through CICS, IMS and batch programs. Direct access to DB2 from z/OS is available since (delivered in) IBM DB2 Accessories for z/OS v3.3. The advantages of using z/OS Connect that it can function as a common and consistent entry point for mobile access, its Java so it runs on specialty engines and it shields backend systems from RESTful URIs and JSON data formats.
z/OS Connect can also be used as the way into the mainframe environment by the IBM MobileFirst Server. The MobileFirst Server is part of the IBM MobileFirst platform, and designed to seamlessly channel back-end enterprise systems to mobile devices. Currently the IBM MobileFirst platform is Linux for zSystems only.
For a wider Web/Java application support, there is the full functional WebSphere Application Server on z/OS that you can use as a hub into the z/OS environment. Client/Web applications can access the Application Server environment on z/OS directly and WAS Data Source objects through JDBC providers will further enable DB2 on z/OS access. Traditionally there is the choice between type 2 (single LPAR) or type 4 (DRDA distributed) connections. The following scheme tries to give you a summary.
Conclusion
Accessing DB2 for z/OS data from the "distributed" environment for many applications, existing and new, still is an important issue. This access can be achieved based on a "database connection protocol" or a "distributed/web application protocol" the choice you make depends on the type of the application.
Today for DB2 connections the idea is to let IBM Data Server Driver or Client replace the DB2 Connect Gateway. This solution delivers at least equivalent function, probably improves performance, and in all circumstances reduces complexity both in configuration and layers (direct connection).
The alternative solutions make use of the Java runtime on z/OS and let distributed/web/mobile applications connect to an application server run time, that in its turn will connect via drivers to the DB2 for z/OS backend. The latest addition in this field is called z/OS connect (with DB2 adapter), a z/OS application gateway specialized in support for REST/JSON.