Handbook of Local Area Networks, 1998 Edition:LAN-based Application Development Issues and Solutions Click Here! Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next 6-6Using CORBA to Integrate Distributed Data Base Systems BHAVANI THURAISINGHAM Information has become the most critical resource in many organizations, and the rapid growth of networking and data base technologies has had a major impact on information processing requirements. Efficient access to information, as well as sharing it, have become urgent needs. As a result, an increasing number of data bases in different sites are being interconnected. To reconcile the contrasting requirements of the different data base management systems (DBMSs), tools that enable users of one system to use other systems are being developed. Efficient solutions for interconnecting and administering different data base systems are also being investigated. There are two aspects to the object-oriented approach to integrating heterogeneous database systems. In one approach, an object-oriented data model could be used as a generic representation scheme so that the schema transformations between the different data base systems could be facilitated. In the other approach, a distributed object management system could be used to interconnect heterogeneous database systems. This chapter explores the distributed object management system approach by focusing on a specific distributed object management system—the object management group’s (OMG) common object request broker architecture (CORBA). INTEROPERABILITY ISSUES Although research on interconnecting different DBMSs has been under way for more than a decade, only recently have many of the difficult problems been addressed. Schema Heterogeneity. Not all of the data bases in a heterogeneous architecture are represented by the same schema (data model). Therefore, the different conceptual schemas have to be integrated. To do this, translators that transform the constructs of one schema into those of another are being developed. Transaction Processing Heterogeneity. Different DBMSs may use different algorithms for transaction processing. Work is being directed toward integrating the various transaction processing mechanisms. Techniques that integrate locking, timestamping, and validation mechanisms are being developed. However, strict serializability may have to be sacrificed in order to create a heterogeneous environment. Query Processing Heterogeneity. Different DBMSs may also use different query processing and optimization strategies. Research is being conducted to develop a global cost model for distributed query optimization. Query Language Heterogeneity. Query language heterogeneity should also be addressed. Even if the DBMSs are based on the relational model, structured query language (SQL) and relational calculus could be used to achieve heterogeneity. Standardization efforts are under way to develop a uniform interface language. Constraint Heterogeneity. Different DBMSs enforce different integrity constraints, which are often inconsistent. For example, one DBMS could enforce a constraint that all employees must work at least 40 hours, even though another DBMS may not enforce such a constraint. Semantic Heterogeneity. Data may be interpreted differently by different components. For example, the entity address could represent just the country for one component, or it could represent the number, street, city, and country for another component. THE COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) The major components of CORBA are the object model, the object request broker (ORB) and object adapters, and the interface definition language (CORBA-IDL). The Object Model The object model describes object semantics and object implementation. Object semantics describe the semantics of an object, type, requests, object creation and destruction, interfaces, operations, and attributes. Object implementation describes the execution model and the construction model. In general, the object model of CORBA has the essential constructs of most object models. The Object Request Broker (ORB) The ORB essentially enables communication between a client and a server object. A client invokes an operation on the object, and the object implementation provides the code and data needed to implement the object. The ORB provides the necessary mechanisms to find the object implementation for a particular request and enables the object implementation to receive the request. The communication mechanisms necessary to deliver the request are also provided by the ORB. In addition, the ORB supports the activation and deactivation of objects and their implementations as well as generating and interpreting object references. Although the ORB provides the mechanisms to locate the object and communicate the client’s request to the object, the exact location of the object, as well as the details of its implementation, are transparent to the client. Objects use object adapters to access the services provided by the ORB. Communication between a client and a server object using the ORB is illustrated in Exhibit 6-6-1. Exhibit 6-6-1.  Communication Through Object Request Broker (ORB) Interface Definition Language (IDL) IDL is the language used to describe the interfaces that are called by client objects and provided by object implementations. IDL is a declarative language. Client and object implementations are not written in IDL. IDL grammar is a subset of ANSI C++ with additional constructs to support the operation invocation mechanism. An IDL binding to the C language has been specified, and other language bindings are being processed. Exhibit 6-6-2 illustrates how IDL is used for communication between a client and a server. The client’s request is passed to the ORB using an IDL stub. An IDL skeleton delivers the request to the server object. Exhibit 6-6-2.  Interface Definition Language (IDL) Interface to Object Request Broker Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.