The db2 tutorial we are watching is: Introduction to IBM DB2 Connect (1).
In Part 1 of this series, we briefly talk about the different programming interfaces provided by DB2 Connect and the drivers that implement these interfaces. In the final sections, we roughly describe the communication infrastructure provided by DB2 Connect and see how this infrastructure greatly reduces the use of mainframe resources and how it allows distributed applications to take full advantage of the mainframe platform (such as easy management of hybrid workloads and providing continuous application availability).
You may still remember Figure 1, in which DB2 Connect consists of a programming interface (implemented as JDBC™, SQLJ, ODBC, DB2 CLI, OLE DB, .NET® and Embedded SQL drivers) and a communications infrastructure.
Figure 1. DB2 Connect consists of a programming interface and a communication infrastructure that enables client server applications and web-based applications to take advantage of the mainframe.
In this article, we will discuss one of the functions of the above communication infrastructure, that is, how DB2 Connect provides unified access to heterogeneous distributed data.
Before discussing the details of such solutions in terms of unified access, distributed and heterogeneous aspects, we need to turn our attention to the communication infrastructure itself. DB2 Connect provides this communication infrastructure in the form of a communication server, which can be deployed on Windows®, Linux (such as Linux for zSeries) and UNIX® servers. This communication server is built using the same code base used when building a DB2 UDB database server, so it inherits all the qualities that are possessed in the architecture of the DB2 UDB server.
In fact, the functionality we described in this article has a requirement, which is to create a database on the DB2 Connect server itself (here you don't need DB2 Universal Database™ (UDB)). At first glance, this seems to contradict the statement in Part 1 of this series, where we say that DB2 Connect is simply connecting the application to the DB2 for z/OS and DB2 for iSeries® databases, and DB2 Connect does not manage the data. However, it should be clarified that the database we want to create on the DB2 Connect server does not store data. It is used simply as a single connection point to provide a unified or single database mirroring to the application. Therefore, the DB2 Connect server simply routes requests to data to different database servers that really manage data.
While in Part 1 you learn some of the features that really set DB2 Connect from other competitors’ communication pipelines, you probably already know that DB2 Connect at least does its responsibility (connecting the application to the mainframe). Now that you have a better understanding of the underlying architecture of DB2 Connect, it is time to provide further content than Part 1 (Subtitle - There is a Universe in the Inside) of this series of articles - we will start Part 2 from here.
In Part 2, we will talk about DB2 Connect as a data access platform, where we are not just talking about DB2 on the mainframe. For example, did you know that a DB2 Connect workstation can perform a distributed connection between a DB2 for z/OS database and Informix® IDS on a Windows database in the same transaction, and it can also update these data sources using built-in support for two-phase commits (2PC) within the same commit scope. I mentioned that you will find some clever features, and that's one of them! If this sounds like a federated, or more like a WebSphere® Information Integrator (formerly DB2 Information Integrator), that's right. In fact, all DB2 UDB and DB2 Connect servers come with WebSphere Information Integrator federated support for the entire DB2 UDB family and Informix IDS built into the engine. Products like WebSphere Information Integrator extend the scope of the federal engine to include other relational data sources (Oracle, Microsoft® SQL Server), non-relational data sources (ADABAS, VSAM), OLE DB, XML and any other data sources in the enterprise.
Unified access to heterogeneous distribution data sources
You may know what unified, distributed, and heterogeneous means, but you may not be clear how DB2 Connect implements these concepts. You may be familiar with IBM WebSphere Information Integrator products, and you will think that these words describe these products well. Please continue reading this article so that the relationship between these products will become clearer.
Unified access is a very good way to reduce the complexity of open applications in heterogeneous environments. Although application programmers can always establish connections to individual data sources one by one, it is easier to use only one database connection in the application. Different connections to different data sources require multiple drivers (e.g., a separate DB2 and Informix JDBC drivers). If multiple different connections are used in an application, the data cannot be treated as managed by a single database (for example, an application programmer must fetch data from multiple data sources before he can perform a connection operation). Moreover, when multiple different connections are used, the location of the code in the application is fixed so that data architects cannot freely modify the location of the data to adapt to changing business needs.
Instead, the unified data access mechanism provides application programmers with a single point of connection to all data assets of the enterprise. It allows the use of a single API (driver), allows for a style of SQL (you don't have to worry about SQL Server using currency data types while DB2 UDB does not), it also abstracts data locations so that data locations can be changed without affecting existing applications. Finally, it allows programmers to treat all data consistently as if they are from the same relational database, and that database can manage connections, sorting, and filtering of data while ensuring transaction integrity – and, thanks to the extension of the basic features of DB2 Connect, the backend data source does not have to be a relational data source (for example, it can be a VSAM or ADABAS data source).
I hope you have already understood that using a single database is much simpler than coordinating access to multiple data sources. But the difference between our IBM information management solution is that we do not expect you to cancel existing applications and port them all to DB2 databases because that is unrealistic.
DB2 Connect implements a simple and intuitive access method through one of the following three different mechanisms:
Federal Database
Stored Procedures
SQL Functions
DB2 Connect and federated databases
DB2 Connect comes with a built-in basic-class federation database function. You may be familiar with this function, because the IBM DataJoiner product also provided this function before. Starting from Version 8, federated database support has become part of the DB2 Connect and DB2 UDB servers, and anyone can use the feature without purchasing additional products. In other words, when you deploy a DB2 Connect server on Linux, Windows, and UNIX servers, you can create a federated database and the application can connect to this federated database. After establishing a connection to the federated database, the request is routed to the real data source - but the complexities such as function compensation, data type conversion, and optimization of valid data retrieval are transparent to the user.
The federated components of DB2 Connect include read/write support for DB2 UDB for Linux, DB2 UDB for UNIX, DB2 UDB for Windows, DB2 UDB for VSE/VM, DB2 UDB for z/OS, DB2 UDB for iSeries, and Informix IDS database servers.
You can use the federated function in DB2 Connect to perform distributed requests across these servers, as shown in Figure 2:
Figure 2. DB2 Connect’s federated database function
For example, the following statement:
SELECT * FROM T1, T2 where T1.C1
In Part 1 of this series, we briefly talk about the different programming interfaces provided by DB2 Connect and the drivers that implement these interfaces. In the final sections, we roughly describe the communication infrastructure provided by DB2 Connect and see how this infrastructure greatly reduces the use of mainframe resources and how it allows distributed applications to take full advantage of the mainframe platform (such as easy management of hybrid workloads and providing continuous application availability).
You may still remember Figure 1, in which DB2 Connect consists of a programming interface (implemented as JDBC™, SQLJ, ODBC, DB2 CLI, OLE DB, .NET® and Embedded SQL drivers) and a communications infrastructure.
Figure 1. DB2 Connect consists of a programming interface and a communication infrastructure that enables client server applications and web-based applications to take advantage of the mainframe.
In this article, we will discuss one of the functions of the above communication infrastructure, that is, how DB2 Connect provides unified access to heterogeneous distributed data.
Before discussing the details of such solutions in terms of unified access, distributed and heterogeneous aspects, we need to turn our attention to the communication infrastructure itself. DB2 Connect provides this communication infrastructure in the form of a communication server, which can be deployed on Windows®, Linux (such as Linux for zSeries) and UNIX® servers. This communication server is built using the same code base used when building a DB2 UDB database server, so it inherits all the qualities that are possessed in the architecture of the DB2 UDB server.
In fact, the functionality we described in this article has a requirement, which is to create a database on the DB2 Connect server itself (here you don't need DB2 Universal Database™ (UDB)). At first glance, this seems to contradict the statement in Part 1 of this series, where we say that DB2 Connect is simply connecting the application to the DB2 for z/OS and DB2 for iSeries® databases, and DB2 Connect does not manage the data. However, it should be clarified that the database we want to create on the DB2 Connect server does not store data. It is used simply as a single connection point to provide a unified or single database mirroring to the application. Therefore, the DB2 Connect server simply routes requests to data to different database servers that really manage data.
While in Part 1 you learn some of the features that really set DB2 Connect from other competitors’ communication pipelines, you probably already know that DB2 Connect at least does its responsibility (connecting the application to the mainframe). Now that you have a better understanding of the underlying architecture of DB2 Connect, it is time to provide further content than Part 1 (Subtitle - There is a Universe in the Inside) of this series of articles - we will start Part 2 from here.
In Part 2, we will talk about DB2 Connect as a data access platform, where we are not just talking about DB2 on the mainframe. For example, did you know that a DB2 Connect workstation can perform a distributed connection between a DB2 for z/OS database and Informix® IDS on a Windows database in the same transaction, and it can also update these data sources using built-in support for two-phase commits (2PC) within the same commit scope. I mentioned that you will find some clever features, and that's one of them! If this sounds like a federated, or more like a WebSphere® Information Integrator (formerly DB2 Information Integrator), that's right. In fact, all DB2 UDB and DB2 Connect servers come with WebSphere Information Integrator federated support for the entire DB2 UDB family and Informix IDS built into the engine. Products like WebSphere Information Integrator extend the scope of the federal engine to include other relational data sources (Oracle, Microsoft® SQL Server), non-relational data sources (ADABAS, VSAM), OLE DB, XML and any other data sources in the enterprise.
Unified access to heterogeneous distribution data sources
You may know what unified, distributed, and heterogeneous means, but you may not be clear how DB2 Connect implements these concepts. You may be familiar with IBM WebSphere Information Integrator products, and you will think that these words describe these products well. Please continue reading this article so that the relationship between these products will become clearer.
Unified access is a very good way to reduce the complexity of open applications in heterogeneous environments. Although application programmers can always establish connections to individual data sources one by one, it is easier to use only one database connection in the application. Different connections to different data sources require multiple drivers (e.g., a separate DB2 and Informix JDBC drivers). If multiple different connections are used in an application, the data cannot be treated as managed by a single database (for example, an application programmer must fetch data from multiple data sources before he can perform a connection operation). Moreover, when multiple different connections are used, the location of the code in the application is fixed so that data architects cannot freely modify the location of the data to adapt to changing business needs.
Instead, the unified data access mechanism provides application programmers with a single point of connection to all data assets of the enterprise. It allows the use of a single API (driver), allows for a style of SQL (you don't have to worry about SQL Server using currency data types while DB2 UDB does not), it also abstracts data locations so that data locations can be changed without affecting existing applications. Finally, it allows programmers to treat all data consistently as if they are from the same relational database, and that database can manage connections, sorting, and filtering of data while ensuring transaction integrity – and, thanks to the extension of the basic features of DB2 Connect, the backend data source does not have to be a relational data source (for example, it can be a VSAM or ADABAS data source).
I hope you have already understood that using a single database is much simpler than coordinating access to multiple data sources. But the difference between our IBM information management solution is that we do not expect you to cancel existing applications and port them all to DB2 databases because that is unrealistic.
DB2 Connect implements a simple and intuitive access method through one of the following three different mechanisms:
Federal Database
Stored Procedures
SQL Functions
DB2 Connect and federated databases
DB2 Connect comes with a built-in basic-class federation database function. You may be familiar with this function, because the IBM DataJoiner product also provided this function before. Starting from Version 8, federated database support has become part of the DB2 Connect and DB2 UDB servers, and anyone can use the feature without purchasing additional products. In other words, when you deploy a DB2 Connect server on Linux, Windows, and UNIX servers, you can create a federated database and the application can connect to this federated database. After establishing a connection to the federated database, the request is routed to the real data source - but the complexities such as function compensation, data type conversion, and optimization of valid data retrieval are transparent to the user.
The federated components of DB2 Connect include read/write support for DB2 UDB for Linux, DB2 UDB for UNIX, DB2 UDB for Windows, DB2 UDB for VSE/VM, DB2 UDB for z/OS, DB2 UDB for iSeries, and Informix IDS database servers.
You can use the federated function in DB2 Connect to perform distributed requests across these servers, as shown in Figure 2:
Figure 2. DB2 Connect’s federated database function
For example, the following statement:
SELECT * FROM T1, T2 where T1.C1