Why Do I Need To Pay For ODBC , JDBC, ADO.NET, OLE-DB Drivers? (Update 3)

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

rdfoledbjdbcsqlodbcoraclelinked_datasemanticwebvirtuosoopenlinkDataSpace

Comments

[uggboots]

holding the visitors without a shot until 25 minutes into the game. Cortland earned a pair of penalty corners late in the first half and a trio of corners at the start of the second, but the F&M defense clamped down to maintain the one-goal advantage.