How Should Your Network-Attached Applications Access DB2 for z/OS?

Some relatively recent developments have plenty of people asking, "How should my applications that connect to a z/OS server via a network link access DB2 for z/OS data?" In writing today I hope to provide some information that will be useful to folks pondering this question. I'll organize my thoughts on the matter around two key questions.

z/OS Connect or DB2 Connect?

z/OS Connect, which is becoming one of my favorite IBM software products, first showed up a couple of years ago. It's been promoted pretty heavily by IBMers presenting at various events (with good reason), and that has caused some people to wonder whether z/OS Connect might be intended as a replacement for the more venerable DB2 Connect product. Such is most definitely NOT the case. DB2 Connect and z/OS Connect address two different DB2 data access situations.

First, DB2 Connect (and through the next several paragraphs, where you see "DB2 Connect," add, in your head, "and the IBM Data Server Driver" -- more on that in the second section of this blog entry). DB2 Connect does, and will continue to do, what it has always done: provide a means whereby an application program, running in an environment other than z/OS and with a TCP/IP connection to a DB2 for z/OS system, can use a non-DBMS-specific data access interface to interact with the target DB2 server.

One of the more popular of these non-DBMS-specific data access interfaces is JDBC, short for Java Database Connectivity. When a Java programmer codes JDBC calls for data access purposes, he or she knows that the target server is a relational database management system (or at least something that can look like an RDBMS -- IBM's IMS, a hierarchical database management system, has a JDBC interface). What the Java developer may not know (and certainly doesn't have to know) is technical information specific to the relational database management system that will be accessed from the Java program being written. The Java developer does not have to be concerned about DBMS-specific technical information because the JDBC driver that his or her program will use is going to take care of mapping non-DBMS-specific JDBC calls to a particular protocol that can be processed natively by the target data server. When the target data server is IBM's DB2 for z/OS, the JDBC driver is provided by IBM's DB2 Connect. Other RDBMS vendors similarly provide JDBC drivers that can be used to access their database server products. Thus it is that DB2 Connect abstracts for a Java programmer the particulars of the specific RDBMS called DB2 for z/OS (and what I've written about JDBC applies as well to other common, non-DBMS-specific data access interfaces such as ODBC and ADO.NET).

Now, suppose that an application developer is writing a program that will send some data to and/or receive some data from a relational database management system on a network-accessible server, but he or she does not care to know that a relational database management system will be involved in the equation. To this programmer, the nature of the data persistence engine on the server side of the application -- even if abstracted as a generic-looking RDBMS (an abstraction presented, as noted above, by way of a driver such as DB2 Connect) -- is "plumbing," and he or she does not want to be concerned with plumbing. Relational database management system? Sequential file? Hierarchical database? Hadoop-managed data store? Doesn't matter. All plumbing. All the programmer wants to do is invoke a service on the remote server. That service will take data from the application being coded by the programmer, and/or send data to the application. How that service does what it does is immaterial.

OK, how to invoke this service on the remote data processing platform? Not long ago, that service invocation mechanism might have been a SOAP call. SOAP is short for Simple Object Access Protocol. Only, it's not all that simple. Kind of involved, actually, with attendant XML documents that spell out the what and how of the associated service. How about something simpler? Something more lightweight? Enter REST, short for Representational State Transfer. REST is a protocol that enables remote services to be invoked through what are essentially extensions of basic HTTP verbs (GET, PUT, etc.), with data sent back and forth between client and server in a format called JSON (JavaScript Object Notation, a data representation involving name/value pairs that is very easy for programs -- and people -- to parse).

But what does this have to do with DB2 for z/OS? That's where z/OS Connect comes in. With z/OS Connect, a z/OS-based service, such as a CICS or an IMS transaction, or a DB2 stored procedure (or just a single SQL DML statement, if desired) can be invoked by a remote client via a REST call (making it, therefore, a so-called RESTful service). The client-side programmer doesn't have to know anything about CICS or IMS transactions or DB2 stored procedures, and z/OS-side programmers don't have to know anything about the REST protocol or the JSON data format. z/OS Connect provides the bridge that links these two worlds.

A bridge, and more: z/OS Connect provides security functions to ensure that z/OS-side services can be invoked only by authorized requesters, and it enables z/OS SMF tracing of service usage activity. z/OS Connect also provides "service discovery" functionality that allows requesters to find available services and to get information on how a service can be invoked and what the service delivers (using "Swagger," more formally known as the OpenAPI Specification -- a lingua franca for providers and consumers of RESTful services).

And when you think about z/OS Connect, think beyond your own organization's developers who would love to have a REST interface to z/OS-based services. Think, as well, about developers outside of your organization. Think of people developing applications with mobile front-ends like smart phones and tablets. Does your organization have (or could you readily have) z/OS-based services that could be exposed, securely and in an industry-standard fashion, to the wider world as REST APIs? Might these APIs be useful components of what could become a widely used mobile app? Could these APIs create new revenue streams for your organization, or, if provided in a no-charge manner, extend your organization's brand to new segments of a population and/or provide information that could deliver new and actionable insights for your company? The possibilities are wide-ranging and exciting. Get with some of your application development leaders and get some conversations started.

By the way, DB2 for z/OS Support for z/OS Connect Enterprise Edition is provided by way of the native REST support that was built into the distributed data facility (DDF) for DB2 12 for z/OS, and retrofitted to DB2 11 via the fix for APAR PI66828.


DB2 Connect or the IBM Data Server Driver?

When it's appropriate to use DB2 Connect instead of z/OS Connect (and that's the case when programmers know they are interfacing with a relational database management system and want to use a non-DBMS-specific data interface such as JDBC or ODBC), should you in fact use DB2 Connect itself, or should you use the IBM Data Server Driver?

Increasingly these days, you'll see in presentations from IBM DB2 for z/OS people (myself included) references to functionality provided by the IBM Data Server Driver, and you might find yourself wondering, "Is that same functionality present in DB2 Connect, and if it is, why isn't that mentioned?" Yes, the functionality mentioned is virtually certain to be present in DB2 Connect (given an equivalent version, such as 11.1 or 10.5). Why is DB2 Connect not mentioned? Two reasons: 1) "The IBM Data Server Driver and DB2 Connect" is kind of a mouthful, and (more importantly) 2) we REALLY want you to be using the IBM Data Server Driver instead of DB2 Connect (and by "we" I mean IBM DB2 for z/OS specialists "in the field," such as myself, and people in the DB2 for z/OS development organization and people in the DB2 Connect/Data Server Driver development organization). Why are we so keen on your using the IBM Data Server Driver instead of DB2 Connect? Several reasons:

1. It's a lighter-weight piece of code.
2. It should deliver better performance, as it is a "type 4" driver that provides a direct path from an application server to a DB2 for z/OS system, thereby avoiding what would otherwise be an extra "hop" to a DB2 Connect gateway server.
3. It can help with management of your DB2 for z/OS client-server environment, in particular with things like problem source identification (as pointed out in an entry that I posted to this blog last year).
4. It's easier to upgrade than DB2 Connect.
5. It provides most all the functionality that you get with DB2 Connect (including connection pooling, connection concentration, and Sysplex workload balancing).

How can you use the Data Server Driver? Easy. Your DB2 Connect license entitles you to use the Data Server Driver instead of DB2 Connect (the one exception of which I'm aware being a "concurrent user" DB2 Connect license, which requires use of a DB2 Connect gateway server).

Is there any DB2 Connect functionality that is not in the Data Server Driver? Two things come to mind. One is the federation capability provided by way of DB2 Connect "nicknames." The other is support for two-phase commit when the application server in use utilizes a so-called dual-transport model. IBM's WebSphere Application Server uses a single-transport model, so no problem there. I believe that the Encina and Tuxedo transaction managers use a dual-transport model. Even if you have a transaction manager that utilizes a dual-transport model, if two-phase commit functionality is not needed you shouldn't have an issue in using the IBM Data Server Driver instead of DB2 Connect.

And there you go. Hope this information is helpful for you. As always, use the right tool for the right job.