Last month, I began a discussion on the various types of enterprise application integration (EAI) software with a look at message-oriented middleware. This month, I'm going to continue that discussion with a look at database-oriented middleware technology. I use the term technology because database-oriented middleware (DOM) is not really a separate software product, but a set of technologies and standards included in most EAI products to simplify data retrieval from multiple types of databases. In this column, I will discuss these technologies and standards at a high level.
We need to start with a good working definition. Database-oriented middleware is a technological function bundled with most EAI software that enables access to databases of different types, on different platforms and/or in multiple locations. DOM is defined by various connectivity standards such as product- specific, open database connectivity (ODBC) and Java database connectivity (JDBC). It uses access drivers that function to create data integration at a virtual level.
Many database vendors provide their own proprietary solutions to database access. They incorporate native middleware technology into their products. This can be a good thing or a bad thing depending on your situation. Native middleware technology often provides faster access times for data-access requests because it doesn't have to use any outside translation mechanisms. However, unless you're completely entrenched throughout your organization in a single platform or database system, you'll need more than product-specific middleware. You'll probably need ODBC or JDBC.
ODBC is not a product, but rather a translation-layer set of connectivity standards created by Microsoft for use in the Windows environment. ODBC enables developers to use various drivers to access data from Microsoft platforms such as Windows and NT. It also works with several other operating systems. ODBC is a must if you're working with Microsoft products in any database role. ODBC is a good fit for EAI in two other circumstances as well if you're planning to scale up in system size or if your current environment is multidatabase and multiplatform.
One word of caution about ODBC: because there is an extra communication step that must take place when utilizing non-native access drivers, performance can be hampered a bit. However, if you know about potential performance issues ahead of time, you can adjust for them. With the multiproduct and/or platform access that ODBC provides, the benefits of using ODBC outweigh the drawbacks of nominal performance issues.
Like ODBC, JDBC or Java database connectivity is not a product. JDBC is a Java-based set of standards that function in the same role as ODBC but in a different way. JavaSoft created JDBC to enable Java developers to use Java classes as drivers to enable Java applets, servlets or other Java applications to access data from multiple database environments such as Oracle, Sybase, etc. Obviously, if you're working with Java in any capacity, you'll want an EAI product that utilizes JDBC standards to provide database access and integration. This means that if you're going to include any of your intranet or Internet-based systems in your EAI project, JDBC is a must.
ODBC and JDBC Together
Realistically, you're most likely to be working with Microsoft and Java-based products, as well as myriad other vendors' software, databases and platforms. Inevitably, you're going to need both ODBC and JDBC on the same EAI project. Your first question is obviously, "Will the two standards sets collide and cancel each other out in some gruesome, matter-anti-matter explosion?" No, they won't. Actually, they work quite well together if you have the right JDBC driver to act as a conduit between the two standards. The conduit driver decodes JDBC messages so that an ODBC-driven application program interface can understand them.
Because of the increased technical complexity of using ODBC and JDBC together, you'll have to know early in the game that you need to use both. That way, you'll be able to plan for any added development time or architectural add-ons. However, the small amount of increased complexity in the technical architecture incurred is a small price to pay for a set of technologies that allows you to integrate a nearly endless array of databases, platforms and development environments into one smooth-running, virtual information technology (IT) system.
EAI is becoming increasingly important as an IT initiative, so there's a lot of information available on database integration technologies as well as ODBC and JDBC standards. Also, I'm sure your friendly neighborhood consultant or EAI vendor will be happy to provide you with more in-depth information. At any rate, our discussion of EAI technology is not over. Next month, it's EAI nirvana (well, almost): message brokers.
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
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access