Continue in 2 seconds

Just Say No to Proprietary APIs

  • August 01 2007, 1:00am EDT

Integration is the watchword in today's business organizations. Customer relationship management (CRM) applications strive to consolidate customer information from multiple IT systems, business intelligence (BI) applications strive to present cohesive views of entire organizations across IT platforms and supply chain management applications strive to integrate systems between IT environments within numerous disparate organizations. Web services and service-oriented architecture (SOA) are seeing rapid adoption in large part due to their ability to free business logic from bondage to specific back-end sources of data and transaction processing.

Enabling this "urge to merge" and helping to spur it on are application program interfaces (APIs) based on widely used industry standards such as ODBC, JDBC and ADO.NET. Nothing will toss a monkey wrench into an integration effort as completely as will the use of proprietary APIs. Business organizations running applications that use proprietary APIs typically take one of two approaches: they either undertake major development expenditures to effect integration or else they target those particular irksome applications for replacement with more standardized applications. Either solution is bad news for the bottom line.

The latter solution is also bad news if your organization happens to be an independent software vendor (ISV) marketing one of those targeted applications. If so, you are undoubtedly aware that more users want access to data from your application using third-party tools. For example, business organizations architecting comprehensive BI environments might wish to use popular reporting and analysis tools from Business Objects (Crystal Reports), or Cognos or Microsoft Excel. Developers might wish to use products such as Visual Studio and Java SDKs that have many capabilities for writing applications that connect to SQL-compliant databases. These third-party applications know how to connect using standards-based APIs and the SQL data model. They do not know how to use your proprietary API or file formats. The inclusion of standards-based APIs included with major commercial databases such as Oracle, for example, are what allow the aforementioned BI products - and scores of others - to operate on a plug-and-play basis in an organization that relies on the Oracle platform.

If your application uses a proprietary API, your customer can enlist its IT development staff to write extensions to your application that extend it to include the more powerful reporting or analytical functioning desired. Or they can contract your company to do it. Either way, it is an expensive and time-consuming proposition. It is much more economical to integrate a third-party reporting and/or analysis application. And, of course, if that third-party application can tie in numerous other applications into an overall BI solution, all the better. With ISVs offering products head-to-head with yours but including standard APIs, your product is likely to rise high on that replacement hit list, as well as lose value in the eyes of systems architects planning new infrastructure.

Standardized APIs also make it much easier for an organization to add security logic between the application accessing data and the data source - a usual requirement when a new means of accessing corporate data is made available. Modifying the middleware is sufficient for applications and databases using standardized APIs; those using proprietary APIs, however, must be modified and tested specifically. This is one reason that many heavily regulated industry verticals - such as energy and financial markets - are required to use applications that can claim to have an open interface. In most cases, a standards-based API meets that requirement.

However, standards-based APIs are not just for commercial relational database management systems. Data connectivity leaders provide tools that enable users to cost-effectively layer the API or data with a standards-based API.

How Not to Do It versus How to Do It

Even if your organization has decided (or has been compelled) to adopt standards-based APIs, you may have good reasons to keep the applications currently using proprietary APIs. They may be homegrown applications representing a large investment in time and resources, or they may be so intricately ensconced in your overall systems environment that their replacement would be costly and disruptive to mission-critical operations. If your company is an ISV, of course, you have a vested interest in making your existing products more open in order to expand their market.

Your organization could take on the effort of writing, say, an ODBC-driver component that fully complies with the specifications, for example. However, the effort and expense of taking this approach will nearly always outweigh the benefits. A much better approach is to license a third-party software development kit explicitly designed to create standards-based APIs over any type of data source. This approach can essentially give you as much as 99 percent of the code already completed: the extensive driver API specification compliance, the SQL calls, and the network and server components necessary.

The best-of-breed API SDKs available have the ability to make anything - flat file data, proprietary data or a Web site - appear as a SQL database that application tools based on standard APIs know how to talk to. Such SDKs contain prebuilt components that implement the driver APIs. This code exposes the required APIs and interfaces and implements all the rules defined by the respective specification for various OS platforms.

A truly comprehensive SDK will also include a SQL engine with support for ANSI SQL92 and be capable of efficiently executing queries over any type of data store; this interfaces with the code your development staff supplies to access your particular data source.

Finally, the SDK should include the network communications components to allow deployment of a client/server configuration where the SQL engine runs as a server process on the particular OS platform supported . There is a need for the SDK to have high performance and for it to support Unicode. The high performance is required to allow the standards-based API to be able to be comparable to the proprietary API in terms of data access speed and scalability. Unicode is required in order to meet today's demand for internationalized applications.

Using this approach, your staff's development effort consists strictly of writing code to obtain information from the SQL engine and to use in processing rows of data from your data source. The scope of this code is to implement about 10 functions that expose a virtual schema and build rows for these virtual tables; the code performs the required functions by using the application's data access layer or, in some cases, reading directly from the application's file store.

The code is independent of the driver you are creating, the platform you will run on, or whether it is a single tier or a client/server implementation. In any case, your development staff writes the code with very little concern for the driver interface, SQL, networking, optimization, data types and a host of other factors involved. Their only concern is with taking a request to process data for which the kit provides all the information needed to accomplish this optimally. The SDK should allow the code to be written in C, C++, Java, or a .NET language by developers of average programming expertise, in a matter of weeks. The code is the same whether you want to support ODBC, JDBC, OLE DB or ADO .NET.

Because the third-party vendor is responsible for prepacking and fully testing the lion's share of functionality, your organization has very little code to write, debug and maintain into the future - a saving of time and cost that could easily justify the cost of the SDK itself.

To implement a client/server ODBC driver as shown here, you'd use the ODBC component, the network library component, the SQL engine component, and the data source-specific code. All but the last element can be provided by an API SDK. Depending upon your IT environment, you may want to be sure you have the option to plug in your own SQL engine to provide standards-based access to it - for example, if you rely on JDBC rather than ODBC, and want to use this configuration to implement ODBC.

Essentially, the steps for implementing a custom driver using a well-equipped commercially available API SDK consist of the following:

  • Define the view of your data. The SDK should include a function, triggered by an incoming query, that is responsible for returning the details of the tables that are part of the query.
  • Determine how you will interact with the SQL engine. That is, whether the interaction will be row based or query based.
  • Determine features you will support. Select, Update, Delete, Insert.
  • Implement your custom-supplied code. These consist of the functions to obtain information from the SQL engine and to use in processing rows of data from your data source. A comprehensive API SDK should include templates and/or examples to get your developers started.
  • Test sample queries through ODBCISQL.
  • Package the software up for redistribution.

An example of an organization that made successful use of a third-party API SDK is GTECH, a leading gaming technology and services company that supplies the platform and gaming content for building regional lottery systems. GTECH decided to develop back-office applications with tools that use ODBC and JDBC in order to tap into the highly available pool of fourth-generation programming language and programmers as well as to use standards-based APIs for customers to expand their system. Data in their platform is stored in memory and in IBM DB2 RDBMSs and was accessed using a proprietary API. Using a commercially available API SDK, developers at GTECH created standards-based ODBC and JDBC drivers for Windows, Linux, AIX and AIX64 with minimal coding in C.
Considering how easy and cost-effective comprehensive API SDKs now make it to provide standards-based access to applications previously restricted to access via proprietary APIs, there is no longer any reason to let proprietary APIs limit your plans. If you want to include such applications in BI or CRM solutions that employ best-of-breed third-party applications, if you want to add OTS reporting or analytical functionality to those applications, if you want to leverage those applications to gain the advantages that SOA can provide in securely integrating IT functionality across the enterprise and beyond, an API SDK could be just the ticket to achieving your goals.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access