Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Simplify Cloud Data Access through a Central Database Driver Management Service called UDI (Universal Data Integrator)

IP.com Disclosure Number: IPCOM000246864D
Publication Date: 2016-Jul-08
Document File: 3 page(s) / 57K

Publishing Venue

The IP.com Prior Art Database


This article proposes a Database Driver Management Service for Cloud based Platform As a Service (PAAS) environments. The proposed service will be a central repository for all database drivers needed to communicate with databases in the PAAS, leading to easier lifecycle management of database drivers.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 01 of 3

Simplify Cloud Data Access through a Central Database Driver Management Service called UDI (Universal Data Integrator)

Database vendors for both relational and unstructured data ("BigData", "noSQL") supply their own Database drivers to allow connectivity, reads, writes and other advanced features such as workload balancing and failover with their database servers. These drivers need to be pre-installed on the clients before any distributed communication to the database server is possible.

In a Cloud environment, many services need database access. These services bundle database drivers that allows them connectivity to either on-prem or Cloud deployments of databases. A service may need to access to multiple databases, in which case it may end up bundling more than one database driver to support a heterogenous database environment.

In addition to Cloud services and applications, even remote applications may need access to cloud databases. And vendors may provide a different version of the driver for Cloud deployments as compared to on-prem. So, to access Database from one vendor on the Cloud or on-prem, there may be 2 types of drivers available (one for Cloud, one for on-prem). Application needs to download the right type of driver depending on the target database.

This model of driver management is inflexible, complex to maintain and the problem becomes more aggravated in Cloud environments because -
1) Single Cloud platform may have database from multiple vendors, which means that other services wanting to communicate with these databases need drivers for each.

2) Database vendors update their drivers frequently, hence services would need to be re-bundled with newer versions of the drivers and refreshed in Cloud.

3) If Cloud services continue using older drivers due to the overhead of updating, the driver may not be at levels recommended for a particular server version, leading to loss of functionality or bug fixes.

4) In one Cloud based workflow, multiple services may be used that need database access and each of those services may bundle different version of the driver for the same database server - this will lead to difficulty in problem determination as well. Ideally all services in one workflow use the level of driver recommended for the server version to avoid any communication issues due to level mismatch.

5) If applications are in control of which driver to download (depending on Cloud or on-prem deployment of database), there is a chance that it may end up downloading the wrong type and encounter runtime issues later.

To take one example, let's say IBM, there are many types of database drivers for different flavors of DB2 (z/OS, LUW, i series), Informix, BigInsight etc. Different services on Bluemix needing to access different server endpoints end up bundling all these drivers. Lifecycle management of these drivers in bundled products is not automated or efficient - bundled drivers need to be manually updated and the bun...