Middleware Solutions

Many of the new middleware packages allow the applications to be developed independently of the databases, providing drivers for more than 25 database products. Some products such as UniFace accomplish this with data choreography where the developer specifies the data with query by example. The developer does not have to write SQL, and UniFace takes care of all of the I/O and relationship management. A middleware product that is capable of enforcing business rules across database architectures is also needed. One important aspect of UniFace is the ability to enforce referential integrity across platforms. For example, a customer database may exist at corporate headquarters using Oracle, but the orders are taken in the field using a C/ISAM database. The tool will maintain the business rules between these tables, even though they are in different databases at different locations.

Some large IS shops have had great success using gateway technology to link multiplatform databases. For example, consider a company that supports IMS, DB2, and Oracle. After looking at various solutions to try to make these databases communicate, they may choose two different gateway products. One gateway might be Oracle’s transparent gateway for communication from Oracle applications to DB2 and IMS, and the other gateway could be IBM’s DDCS and Data Joiner to handle communications from DB2 into Oracle databases. Many companies use Oracle’s transparent gateway, since it allows them to treat calls to DB2 as if DB2 was just another Oracle database. The gateway product takes care of the translation into DB2 SQL. The company will then have the capability to join two DB2 tables, each on a separate processor, from within an Oracle application. While these gateway solutions are definitely functional, the long-term goal for most companies is to avoid gateways altogether and move into a three-tiered architecture with a protocol layer such as CORBA or DCE.

It is interesting to note that demand for mainframe resources does not always decline after the company has made a commitment to embrace open systems. Having a single database may have offered definite advantages in the mainframe days, but most large IS shops are now both decentralized and distributed worldwide. To complicate matters, many of the remote locations have the authority to choose their own database—usually selecting whatever is in vogue at the time, or perhaps the cheapest database available. This approach can lead to a realtime support load problem. Interestingly, even after a large company completes its push into open systems, the largest share of costs may still be on the mainframe. Although new development is moving to open systems, companies are still seeing mainframe requirements growing at a rate of 15 to 20 percent per year—even though total dollar cost has dropped.

As we move further away from proprietary operating systems to open systems, it seems evident that the days of single-vendor environments are numbered. We are already witnessing the shift toward a plug-and-play RDBMS environment.

It is becoming clear that the differences between proprietary databases will become less of a problem as robust interfaces are developed. Very little theoretical reason can support remaining bound to the technology of a single database vendor. Within the next few years, we will be entering an era when cross-platform joins will be demanded. Vendors who do not provide the capability to do so will be seen as hampering the flow of information, therefore decreasing productivity. This doesn’t mean that vendors will abandon their notable differences in favor of a standardized database environment. In fact, these differences are likely to intensify with the addition of new functionality, since each RDBMS will need to emphasize its strengths to establish superiority over the competition.

Some vendors have seen a market opportunity for a tool that could easily access multivendor databases, both for retrieval and updates. One such product is called Passport, an object-oriented tool that makes the development of three-tiered multivendor applications unbelievably easy. Passport started out as a front-end tool when Oracle and Ingres dominated the market. It wasn’t long, however, before customers wanted to mix-and-match databases. For example, they might want one database for the tool set and another database for the SQL. Either case requires a tool that quickly allows the developer to switch databases on an as-needed basis.

Some of the new middleware products have the capability of leveraging on their object-oriented architecture to easily access multiple databases. For example, some middleware treats each database as an object with its own attributes and behaviors, making it trivial to swap out one database for another. These middleware products have an inherent distributed database model to manage two-phase commits across numerous midrange and PC databases, so that a single update screen can display data from many different databases. When update time comes, the tool uses synchronous communications to ensure that all databases are updated.

Remote Measurement

One trend in the marketplace is linking diverse databases with a common tool, an approach primarily used for measuring database and system performance. For example, the Patrol product by BMC Software can provide a common interface to numerous relational databases. Patrol uses a Knowledge Module on each database to collect information on each remote database, shipping exception information to the master console. We call this our fat-agent technology, since most of the processing is done on the agent. These agents contain all of the protocols needed to communicate with the master console, regardless of the agent’s platform. Our knowledge modules also abstract the user interface, making it possible for the knowledge module to adapt to a Unix or MVS view of the data and providing a way to cover up to 5,000 databases from a single console. A complete overview can be found in Chapter 11, Oracle Application Monitoring.

Summary

Today we are seeing more heterogeneous database platforms than ever before. Data continues to reside on many platforms and within many different databases, and methods need to be created for building bridges between these islands of information. The immediate future for managing cross-database communications lies in emerging standards such as the OMG’s CORBA specification and Microsoft’s OLE 2.0 standard. It is only with these frameworks that true, seamless distributed systems will be practical.