|
Anyone programming in a client/server environment knows that middleware is the glue that binds an application to a database. In the early days of client/server computing there were few choices of middleware software. Your friendly database vendor usually supplied the middleware, which was based on a proprietary API. The middleware worked well as long as you were accessing a compatible database. At best, you could access distributed databases spread across your network as long as they were from the same vendor. As time went on, the ODBC specification was released and promised to give developers database access from a single API based on open standards. ODBC caught on, and everybody was happy. Or so we thought. What are you to do when you have to access data in a heterogeneous database environment? A majority of customers I have worked with have more than one type of database system installed on their corporate networks. The International Software Group has created ISG Navigator to solve the problem of integrating data from multiple databases spread across a network. ISG Navigator is distributed middleware that allows you to build an application that integrates data from a host of mixed data sources. The data sources supported include relational database systems, indexed sequential files, mail folders, spreadsheets, flat files, and hierarchical database systems. ISG Navigator is Open Database Connectivity (ODBC), Object Linking and Embedding Database (OLE DB), and ActiveX Data Object (ADO) compliant. Thus you have several options available to you when deciding how to access data on your network.
I tested version 1.5 beta, although the production release of ISG Navigator should be available by the time you read this article. For my testing I used a 166MHz Pentium running Windows 95 and a 90MHz Compaq Deskpro running Windows NT Server 4.0 and Microsoft SQL Server 6.5. Using Microsoft Query I was able to test the ISG Navigator ODBC driver, and I used Internet Explorer to test ADO using Active Server Pages (ASP). Although many databases are supported, I was only able to test access to SQL Server and access to a sample "database" of D-ISAM format.
OLE DB and ADO are the next generation of data access specifications from Microsoft and are designed to meet the needs of developers well into the next millennium. Universal Data Access is the strategy to provide access to relational and nonrelational data sources. (See Tom Spitzerıs feature on universal access, "All Data to all Consumers.") ISG Navigator is one of the first products to implement the OLE DB and ADO model for data access and supports the following platforms: Windows 95, Intel-based NT, Alpha-based NT, HP-UX, Sun-Solaris, IBM-AIX, Alpha Unix, Alpha OpenVMS, and Dec OpenVMS. It supports the following databases: Oracle, Sybase, Informix, OpenIngres, SQL Server, RMS, Rdb, Adabas, DB2, and C-ISAM.
Because ISG Navigator is multitiered middleware, the product contains several components that are installed on the client as well as on the machine containing your database. ISG Navigator Client includes a query processor and optimizer, data source drivers, and client/server communication, and interfaces to OLE DB and ODBC. ISG Navigator Server includes a query processor and optimizer, data source drivers, and client/server communications. The ISG Navigator Bridge includes the query processor and optimizer, OLE DB data source driver, and an interface to ODBC. The Navigator Bridge lets you test OLE DB providers with ODBC applications. The query processor and optimizer creates an execution plan optimized for the fastest response time and gives you functionality that may not be available in the data source. This means you have a consistent way to access multiple types of data. The query processor decides where the query should be executed, opting for the data source if possible. It keeps network traffic to a minimum by locally caching remote data. It also supports SQL queries on nonrelational data sources. This powerful feature gives the developer an open door to data integration.
You must install and configure ISG Navigator on both the client and server machines. Installation is as easy as running the setup program from the CD-ROM, and the configuration is straightforward. But you must consider the time required to configure and support client machines, especially where the number of clients is large and possibly spread out over a large area. The ISG directory structure took only 6.6MB of disk space, which by todayıs standards is relatively small. This 6.6MB includes a sample database and sample code for ASP, ADO, Microsoft Access, Microsoft Query, and SQL Server. The sample database provided with ISG Navigator provided me with the opportunity to test a heterogeneous join (more on this later). On the client machine you need to edit a bindings file, which contains information about your data sources. You enter information such as the remote machine name and the name and type of data source you are accessing. Itıs all very straightforward, except when I had to move the bindings file to the root directory of my hard drive to get it to work. The documentation claims you can set an environment variable to point to the location of the bindings file, but it did not solve my problem. There is also a security file that needs to be modified for each data source. This file exists on the client machine and had to be moved to the root directory. Once I moved it, configuring the client was surprisingly easy. Iıve used other middleware products where the configuration was considerably more complex.
After the binding and security files are configured, you need to create an ODBC data source. You need to supply the name of the bindings file and the name of the data source. You also have the option to deselect a checkbox labeled "single." When finished, you are allowed to specify tables from all the data sources specified in your bindings file. This ability to specify data sources from multiple machines and vendors makes data integration possible. Once the client is configured, you can move on to your server(s). You install ISG Navigator and configure a bindings and security file.
I also had to install the Microsoft Data Access Components (MDAC 1.5c) on the server (the machine with my SQL Server database). Navigator requires MDAC if you are going to use ADO and ASP. With the configuration complete you can start the ISG Server process. This process runs on the remote machine with the data source and listens for and manages connections to the data source. ISG Navigator uses its own communication scheme based on remote procedure calls (RPC). Performance during testing was more than adequate, although I did not do a rigorous performance test or compare performance with native drivers or other middleware products. During the installation process, you have to register the product on the server machine using a supplied utility program. This is a simple step in which you enter licensing information for your site. ISG Navigator will not function unless registration is complete. ISG Navigator also handles all the security details required to connect to a data source. By running the security utility on the client, a username password pair is entered on the client machine. This information is then encrypted and sorted on the client. A process running on the server performs the authentication with the data source.
Once the configuration was complete, I was able to connect into my data source (which was a SQL Server database). My first set of tests consisted of basic access to a remote database. I was able to retrieve, update, delete, and insert data with no problems and with very good performance. I tried several different queries, each differing in complexity. ISG Navigator performed very well during these initial tests. Just for the fun of it, I decided to try and access my database from an Excel spreadsheet. I created a simple VBA function that opened the data source, executed a query, and displayed the rows in my spreadsheet. I was surprised at how easy it was to create the code and have it work properly on my second try. You can develop an application using Excel and ISG Navigator that integrates data from your existing databases and presents it to the user in a tool that allows analysis, charting, and integration to email.
During my testing, I performed a variety of select statements. ISG Navigator also supports the following SQL statements: insert, update, delete, create and drop tables, create index, and create view.
I then tested a heterogeneous join using my remote database and the test database supplied with ISG Navigator. The test database is not really a database but a series of D-ISAM files and provided me with a chance to access relational and nonrelational data from one SQL statement. Once I built my tables with the proper key fields, I fired up Query and built the SQL to access data from both databases. When "adding tables" to your query, the option is presented to select your data source. As long as you did not select "single" during the ODBC data source setup, all data sources specified in the bindings file are available to you. (See Figure 1.) Again, ISG Navigator worked flawlessly during my testing. Traditionally, you may encounter limitations on heterogeneous joins, such as discrepancies between datatype representations (when is an integer not an integer), date and time representations, limits on the number of tables and columns you can join, and the support of views. I was not able to test for any of these situations, but they certainly should be investigated during any product selection process.
While ISG Navigator provides a robust ODBC interface, the real power and uniqueness of this software is its support of OLE DB and ADO. OLE DB is a model in which all types of data (relational and nonrelational) can be accessed through the use of a series of "data providers" ı each using a consistent interface, or API. Microsoftıs OLE DB specification details the methods a data source can and must implement. ISG Navigator is a single data source object that connects to many data providers. Applications can make direct OLE DB calls to access ISG Navigator or use ADO. OLE DB and ADO are based on Microsoftıs component object model (COM) and distributed component object model (DCOM). For those platforms that do not have COM or DCOM, ISG Navigator supplies an "Object Manager," which provides DCOM-like connectivity to objects. ISG Navigator will use DCOM to access remote objects if possible, otherwise it will use an RPC connection.
ISG Navigator also supports chaptered rowsets, scrollable rowsets, and dynasets, even where these features do not exist in the data source. Chaptered rowsets are ones in which a single column from a row of data actually represents a set of rows. This is useful for efficiently retrieving hierarchical data and performing drill down-type data analysis. These features are all part of the extensions to SQL 92 that ISG Navigator supports. The fact that these features can be implemented regardless of the platform or data source is truly amazing. It allows for the "consistent interface to data" that I mentioned earlier.
Where OLE DB is a low-level object model, ADO has a simpler object model and hides many of the gory details of OLE DB. ADO has only three types of objects and is much simpler to use. The "simpler to use" part caught my attention as I decided on the next level of tests that I wanted to perform. You can use Visual Basic to build an application that uses ADO and ISG Navigator. You can also use Active Server Pages and VBScript to access data sources via a Web browser. By taking advantage of the ASP samples that come with ISG Navigator, I was able to test ADO and database access using my Web browser. I copied the sample Active Server pages to the machine running Internet Information Server (IIS). I initially had some difficulty getting the example to work, but that was because of my configuration of ADO and had nothing to do with ISG Navigator. After tweaking the code a bit I was able to access my database via Internet Explorer. To start the test, Navigator displays a "connection" page that allows you to enter a data source name and a SQL statement. Your entries are passed to another ASP that contains VBScript code, which connects to your data source and executes the query. It then references a "results" page that manages the creation of the HTML page with the data retrieved from the database. This is simple, easy-to-use, Web database access. What more could you want these days? Performance was again very good, even on a low-end machine that I was using as my "server."
Any product under consideration for development must address the Year 2000 issue. ISG Navigator will convert two-digit years into four-digit representations using either a fixed window or sliding window solution as outlined by IBM. You have the option of selecting the policy that is right for you by setting the environment variable YEAR2000_POLICY. By default, it implements the sliding window solution, which is able to handle dates up to five years into the future.
Although the software worked flawlessly throughout my testing, I felt the printed documentation needed some work. The installation guide did not indicate what needed to be done and in what order. Working with a representative of ISG, I learned that the actual procedure was straightforward, but the documentation didnıt indicate that. I thought the examples of the binding files could be better explained and should be clearly indicated for each platform. Each supported platform will have a slightly different syntax, which the examples did not distinguish clearly. Online documentation contained more information and diagrams than the printed manuals.
All in all, I give ISG Navigator a thumbs up. If you are looking for a distributed data access middleware product that allows consistent access to a multitude of databases, then take a good look at ISG Navigator. You may find it to be just the solution you are looking for.
