Universal Data Access Technology Blog

Payment is a function of pain alleviation (opportunity cost) monetization.

This post is about highlighting the real pains associated with the $0.00 misconception associated with Data Access Drivers: ODBC, JDBC, ADO.NET, OLE-DB etc.

In the most basic sense, there are some fundament aspects of data access that are complex to implement and rarely implemented (if at all) by free drivers, the list includes:

1. Escape Syntaxes for Dates and Functions
2. Metadata Calls which enable smarter ODBC compliant applications (this feature is typically missing on Driver Side and abused on the Client side i.e., making clients DBMS specific by testing for specific DBMS names)
3. Scrollable Cursors, this is how you deal with change sensitivity, and most drivers actually fake support and get away with it due to shortage of applications to test proper cursor types (Static, Forward-Only, Key-Set, Dynamic, and Mixed models).

Okay, so we're done with actual driver sophistication re. implementation of critical features. Let's Up the ante by veering into the area of security. At the most basic level, It's extremely important to understand that all data access driver types provide read-write access to your databases; thus, it's imperative that data access drivers address the following:

1. Read-Only or Read-Write Access scoped to specific Users
2. Ditto applied to specific User Groups
3. Ditto applied to Database Names
4. Ditto applied to specific ODBC compliant applications
5. Ditto applied to specific ODBC host operating systems
6. Ditto applied to specific IP addresses or Ranges on your Network
7. Any combination of items 1-6 as part of a configurable data access rules/policy system.

Once you're done with security, you then have the thorny issue of data access and data flow management. In a nutshell, your driver needs to be able to handle:

1. Protection against cartesian product network flooding (e.g., user clicks on Customer Table via an ODBC compliant application without comprehension of back-end implications)
2. Enabling or Disabling of key DBMS engine data access optimization features (e.g. DBMS specific extensions exposed via Environment Variables of SQL commands based settings)
3. Conditional Connection Pooling across User, User Groups, Applications, Host Operating System, IP Address dimensions.

Once you've dealt with Security and Data Flow, you then have to address the enforcement of these settings across a myriad of ODBC compliant host, which is where Zeroconfig and centralized data access administration comes into play i.e., configure once (locally) and enforce globally.

When OpenLink Software entered the ODBC Driver Market segment in 1992, the issues above where the fundamental basis of our Multi-Tier Drivers. Thus, although we distinguished ourselves via performance, stability, and specification adherence, our fundamental engineering focus has always been skewed towards security and configurability, alongside high-performance and scalability.

As we close 2009, the security issues that pervade Native DBMS Drives, ODBC, JDBC, ADO.NET, OLE-DB etc. Drivers have only increased, courtesy of ubiquitous computing, sadly though, there remains a fundamental illusion that Data Access Drivers simply connect you to DBMS back-ends, and since you can get these drivers at $0.00 from most DBMS vendors they can't be that important.

I hope that this post brings some clarity to a very serious security and general configuration management issues associated with Data Access Drivers. Free ODBC Drivers offer nothing, when it comes to the real issues of Open Data Access. If they did, they wouldn't be worth $0.00!

Note: wondering if this has anything to do with Linked Data (my current data access focal point)? Well, remember, the Linked Data meme is fundamentally about REST based Open Data Access & Integration via HTTP; thus, what applies to Relational Model databases naturally applies to their more granular Graph Model relatives. Basically, data access security never goes away, it just gets more granular, complex, and ultimately, mercurial.

Related

• OpenLink Universal Data Access Drivers Overview - clickable diagram exposing features and benefits
• OpenLink Multi-Tier ODBC Drivers
• OpenLink Multi-Tier JDBC Drivers
• OpenLink Multi-Tier ADO.NET Providers
• Multi-Tier Drivers Overview (1993 White Paper excerpt)
• OpenLink ODBC White Paper (actual 1993 White Paper)
• OpenLink Virtuoso - which provides a Virtual Conceptual Model (via HTTP, RDF, based Linked Data) Layer above ODBC or JDBC accessible Data Sources
• Oracle Security Auditing Horror Stories -- Social Dimensions of Security compounded by Value (literal username and password) Based User Identity
• Database Security Strategies Need to Grow Up in 2010
• First Law of Data Quality
• Who's Data is it? Part 1
• Who's Data is it? Part 2

The highly anticipated December 2008 issue of the DataSpaces Bulletin is now available!

This month's DataSpaces contains material of interest to the Virtuoso developer and UDA user community alike —

1. Introduction to Virtuoso Universal Server (Cloud Edition).
2. Links to Virtuoso and Linked Data mailing lists.
3. UDA license management tips and tricks.

Here is another article titled "IBM Flexes XML Muscle" that covers the same general theme: IBM's appreciation of Unified Storage.

As indicated in an earlier post: IBM is clearly validating what we have done with Virtuoso (as was the case initially with their Virtual / Federated DBMS initiative ala DB2 Integrator). Here is an excerpt from today's eWeek article supporting this position:

To achieve maximum XML performance, bolstered indexing attributes in the technology will enable advanced search functions and a higher degree of filtering. IBM is also adding support for XPath and XQuery data models. This will allow users to create views that involve SQL and XQuery by sending the protocol through DB2's query optimizer for a unified query plan.

Read on..

Virtuoso has been doing this since 2000; unfortunately a lot of

Here are some excerpts (inlined) with my comments (outlined)

A revamped iodbc.org site is now live. A cross platform ODBC SDK (for writing Drivers, or making applications database independent) remains an important part of the tecnology spectrum for the information age. The further we go into the information age, the more obvious the value of data access, and a standards base API will become.

Here is a practical example of how to create RSS on the fly from SQL data sources leveraging Virtuoso 3.2's SQLX implementation.

This is further illuminates the content of my earlier post on this subject.

I've just read an

What Is This?

The MySQL-ODBC SDK enables you to make MySQL specific applications database independent via ODBC without wholesale re-writes of your MySQL specific application code. Thus, applications that are written directly to the MySQL Call Level Interface now end up being database independent via ODBC, and usable against any ODBC accessible database (including MySQL).

Why Is It Important?

The Open-Source community is rapidly producing innovative applications and in many cases these applications sit atop relational database management systems. Traditionally and historically, the tendency has been to look to MySQL as the default relational database service for Open Source Applications (the "M" in LAMP) which is unfortunately retrogressive since the concept of database independence has long been addressed industry wide via APIs such as ODBC, JDBC, OLE DB, and more recently ADO.NET.

In some case the existence of these APIs has been unknown to Open Source developers prior to application development, and in other cases the complexity of a port from the MySQL API to ODBC ends up being too difficult. There are numerous reasons why you can't mandate MySQL or any other database engine for that matter to every potential user of an Open Source database centric application:

1. Compromises freedom of choice ("Freedom of Choice" is a central theme of the Open Source movement and concept)
   
2. Database vendor lock-in reduces the deployment scope of your application, and it also potentially impedes functionality growth (what happens when the underlying database lacks the functionality that you desire? And cannot or will not deliver an implementation within your time-frame?)
   
3. Cost-Effectiveness is an Open Source value proposition main stay, so asking potential users to acquire yet another database (the real costs aren't $0.00 as resources will be required for administration, installation, configuration etc.) when functional ODBC accessible relational databases exist in house is simply contradictory at the very least.

ODBC as a concept has always been designed to be database-independent; iODBC as an Open Source project was devised to ensure platform neutrality for ODBC (just as Mono is pursuing the same goals re. .NET). When you write an application using the ODBC API database interchangeablity becomes a reality (the worst thing that can happen to you is a dysfunctional driver which is replaceable). Read on..