An Interoperability Development Environment For Intelligent Information Systems1 Michael L. Brodie (
[email protected]) Mark F. Hornick (
[email protected]) Intelligent Database Systems Department GTE Laboratories Incorporated Waltham, MA 02254 USA This paper discusses concepts underlying the interoperability layer of an Intelligent Information System. An early prototype of a development environment supporting the design/development, monitoring/browsing, and operation/maintenance forms the basis of this work. Future Computing Paradigm The dominant paradigm for distributed computing (circa 1995-2000) will involve large numbers of intelligent agents distributed over large computer/communication networks. Agents include humans, humans interacting with computers, humans working with computer support, and computer systems performing tasks without human intervention. Work will be conducted on the network in many forms. Work tasks will be defined by one or more agents and will be executed by agents acting autonomously, cooperatively, or collaboratively, depending on the resources required to complete the task. Single agent tasks are typically centralized, e.g. complex engineering tasks. Multi-agent tasks are typically decentralized, e.g. monitoring many life-support systems for a patient or stations in a factory. PAgents will request and acquire resources (e.g., processing, knowledge, data) without knowing what resources are required or how to acquire them. These resources will be orchestrated to achieve the desired result. A goal of this vision is to be able to efficiently, and transparently, use all computing resources that are available on computers in large computer / communications networks. We call such a system an Intelligent Information System (IIS). The design, construction, use, and evolution of IISs within the above paradigm will require sophisticated support for all aspects of the IIS life cycle.
Information System 1
Information System i
Information System n
Interoperability Layer
Figure 1: IIS composed of Information Systems
1 Published in Proceedings of the International Workshop on the Development of Intelligent Information Systems, Niagara-on-the-Lake, April 1991. Copyright 1989 GTE Laboratories Incorporated
A simple and compelling IIS example is one in which agents are full-fledged information systems, as illustrated in Figure 1. In an IIS, each information system communicates with others, possibly using the full functionality of the other systems. This vision is compelling since it addresses a major critical need in information processing. Most information systems were not designed to communicate, let alone interoperate. Almost all organizations with multiple information systems require interoperability. The technology discussed in this paper is intended to provide interoperability between any two computing resources of which information systems are particularly complex examples. DOM Approach To Interoperability The goal of the Distributed Object Management (DOM) project2 [1] is to produce generic technology with which to provide flexible, efficient, and transparent interoperability between arbitrary computing resources. Transparency for a participating computing resource means that its use of other resources is independent of their location, systems environment, interaction mode or language, or data representation. DOM is intended to provide generic interoperability technology similar to the way that DBMS technology provides generic technology for dataintensive applications. The technical approach is based on object-orientation and distributed database management concepts. Object-oriented technology is used to encapsulate each computing resource as an object space3 . Distributed database management techniques are then used to integrate the object spaces of the distributed computing resources to form a global DOM Object Space (DOM-OS). Within the DOM-OS an object can communicate with any other, thereby achieving interoperability.
HyperCard HyperCard LAI
Sybase Sybase LAI
HyperCard LAI
DOM 2
DOM 3
DOM 4 DOM 1
Oracle
NEMIS
Oracle LAI
Figure 2: An Example using the DOM Systems Architecture4 The systems architecture of a DOM system contains three types of software components: applications, Local Application Interfaces (LAI), and Distributed Object Managers (DOMs). Figure 2 illustrates a possible DOM network.
2 The DOM team consists of Frank Manola (PI); Research Team: Michael L. Brodie, Alex Buchmann, Dimitrios Georgakopoulos, Tamer Ozsu; Development Team: Mark Hornick, Dinesh Desai, Vivek Virmani. 3 We use the term object space to mean something roughly equivalent to database in database terminology. It consists of a set of type descriptions (a schema) and a set of instances of the defined types. 4 This figure depicts several DOM architectural couplings between applications and DOMs. The details of which are beyond the scope of this paper.
2
An application is any computing resource. Generally, applications are autonomous, independent, and domain specific (e.g., information system, word processor, spread sheet, scientific computing system, database). An application can be considered as a collection of structured data and functionality, ideally with an application programmer interface (API). An LAI provides interoperability between an application and the DOM-OS. DOMs provide object management for the DOMOS, just as distributed data managers manage a distributed database. Typically, a machine will contain one DOM component, one or more LAIs (one for each application or application class, such as an SQL-RDBMS), and one or more applications. The IIS Object Space contains everything in the global system (i.e., application data and functionality, objects that define and represent applications, LAIs, and DOMs see Figure 3). All objects in the DOM-OS are defined in a type lattice based on one object model [2, 3]. The functionality of a DOM is defined by the types that comprise its lattice. The LAI comprises objects (including types) in the DOM component and its application's functionality and data accessible through the application's API. These resources (functionality + data) must be registered with the application's LAI to be part of the DOM-OS. IIS Object Space
Application
Application
Functionality + Data
Functionality + Data
LAI
LAI
Functionality + Data
DOM Object Space
Functionality + Data
LAI
LAI
Objects
Objects
DOM
DOM
Objects
Objects
Figure 3: IIS and DOM Object Space Distinctions IIS Development In the DOM context, the development of an IIS involves the selection of an existing information system or the creation of a new one, and its integration into the DOMOS. This complex activity could be supported by an IIS Development Environment (see Figure 4) which consists of an Application Development Environment(s) (e.g., CASE) and a DOM Interoperability Development Environment (DOM-IDE). As described below, powerful tools are required to build the interoperability layer. This paper focuses on the DOM-IDE which supports LAI and DOM development in their respective environments. DOM development is done entirely in terms of the DOM-OS. LAI development integrates the application
3
with the DOM-OS through LAI objects and application resources. Application Development Environment
Case
Application Functionality + Data
IIS Development Environment
LAI Development Environment
Interoperability Development Environment
LAI Functionality + Data
LAI Objects DOM Development Environment
DOM Objects
Figure 4: IIS Development Environment Components Using An IIS Development Environment The functions of a DOM-IDE are described in terms of IIS development stages. 1. Develop an application or select an existing application. Figure 5 illustrates the integration of a Sybase relational DBMS application, which includes a Person relation, into the DOM-OS via the LAI type SPerson. The DOM-OS provides for the integration of multiple applicationspecific "person" structures through a DOM object, in this example, called DomPerson. DOM DOM Type: DomPerson Sybase LAI D1 Type: SPerson
Sybase
S1 Person
Figure 5: Mapping A Person Relation Into the DOM-OS 2. Generate a DOM on a given machine • Modify a copy of the DOM component types for the target machine (communications, OS) • Install the modified DOM component on the machine • Register the DOM component with the global DOM system so that it becomes part of the DOM-OS . 3. Generate an LAI in the DOM component
4
• Modify a copy of the LAI component types to meet the application's requirements. • Install the LAI component on the now installed DOM component. 4. Mapping the Application into the DOM-OS 4.1 Attach the Application to the DOM-OS • Create a one-to-one mapping of application structures to LAI types. This involves creating object types that correspond to each application structure and attaching these types to the LAI. This action incorporates them into the local lattice as well as into the DOM-OS. In the example in Figure 5, the Person relation in the Sybase application is mapped one-to-one to the SPerson LAI type. • Modify the LAI application types to meet requirements of the DOM-OS. This may involve specializing the types to define the view of the application desired for the DOM-OS. These specializations allow creating views of the application data as well as deriving complex objects to represent, for example, relational joins. The SPerson object can have information hidden (e.g., salary) and can have specializations created (e.g., SEmployee and SCustomer) for presentation to the DOM-OS. 4.2 Integrate the Application into the DOM-OS Use all the power of the type editing environment to create or modify DOM objects to integrate application objects into the DOM-OS. For example, SPerson, SEmployee, and SCustomer can be integrated into the global, integrated object types, DomPerson, DomCustomer, and DomEmployee. DomPerson is an object which integrates all person object types from select attached applications in the DOM-OS. Functionality of An Interoperability Development Environment In the DOM context, a development environment is a collection of tools to support browsing/view, manipulation/execution, and design/development of the DOM-OS, as described above. The primary tools are thus various forms of intelligent editors. Since everything in DOM is an object, each editor is specialized to edit instances of specific types. Examples of such editors and the kinds of objects they are used to edit include: • Graphical Editors: tailored for iconically representing network components in a graph, types in a lattice, and distributed complex object in the DOMOS. •ּComplex Object Editors: tailored for manipulating complex objects such as types, operations, and network messages. • Simple Object Editor: generalized for editing an instance of any type. The functionality of some of these editors as provided by the NEMIS prototype [4], which is built upon a prototype DOM component [5], is given below. It may be useful to think of the above IIS development example in which these functions would be used.
5
• Network Editor - Type Lattice Retrieval - Network Browsing - DOM/LAI/Application Icon-to-Component Mapping - Component Startup/Shutdown - Connections - Network Path Specification - Monitoring Message Traffic • Lattice Editor - Type browsing and editing - Remote Object Update - Instance Creation (type objects and their instances) - Inheritance Modification •ּInstance Editor - Property Value Changes • Message List Editor - Sorting/selecting Messages (local querying) • Message Editor - Creating/sending/viewing messages Implementing An Interoperability Development Environment The observation that the NEMIS editors could be generalized led to the notion of an Object Space Environment (OSE). The OSE is a graphical environment in which to explore, manipulate, and enhance the DOM-OS. The OSE provides means for defining how objects should be browsed, displayed, and manipulated. The OSE can be used to generate, tailor, or enhance an LAI or other DOM-level service by defining for each relevant object the browse, display, and manipulate mechanisms. For example, if we represent network components as objects and want to view DOMs as circles, LAIs as rounded rectangles, and applications as rectangles with textual and iconic annotations, the OSE allows a user to specify such displays. Furthermore, a user may expand a component to view the components it is connected to. Based on the kind of component returned via this expansion process, the proper icon is used with lines connecting the components. Using the generic instance editor allows users to change property values of the component instances. Hence, the OSE is a framework for DOM-IDE development. The fundamental components of our prototype OSE are: • Object View Definition (OViD) A user specifies how an object should be displayed in the Object Display Window and what object functionality is allowed. • Object Display Window Objects in the DOM-OS are visually depicted and manipulatable according to the defined OViDs.
6
• DOM Query Language Editor To retrieve distributed, complex DOM objects, the OSE provides an interface for specifying DOM queries. The retrieved objects appear within an Object Display Window, depicted according to their corresponding OViDs. • Icon Editor The OSE icon editor supports complex object and reference annotation specification. It also provides a conveniently accessible icon editor for the creation of icons to represent DOM objects. As illustrated in Figure 4, a DOM-IDE consists of a DOM Development Environment and an LAI Development Environment. The DOM Development Environment can be built by augmenting the above OSE components with: • • • • • • •
Type Editor Operation Editor Instance List Editor Instance Editor Lattice Editor Message Editor Message List Editor
With our current understanding of DOM functionality, we have developed a DOM Development Environment. We are currently investigating LAI functionality. We have designed and implemented several LAIs (e.g., for Sybase, HyperCard, ONTOS5), but require additional experience to be able to automatically generate LAIs to specification, let alone to design corresponding LAI Development Environments. Once we better understand the type lattice for LAIs, the OSE will facilitate the design and generation of the corresponding LAI Development Environment. LAI Research LAI research is aimed at a deeper understanding of LAI functionality so that we can provide a set of LAI types to meet the requirements of all types of computing resources (i.e., applications). For example, we might have a collection of Relational DBMS LAIs which contain a number of SQL LAIs, etc. Figure 6 depicts an example of an LAI generalization hierarchy from which users may choose LAI components. Research issues with respect to LAIs, and hence with respect to an LAI Development Environment, include: • consistency specification between application data and LAI objects • consistency specification between LAI objects and other DOM objects • support for specifying primitive data mapping between an application and DOM • support for specifying concepts between an application and DOM • a toolkit for handling heterogeneity:
5
An ONTOS LAI is in progress.
7
execution environments, interfaces, application domains, autonomy • materialization specification support • local application querying: mapping the DOM Query Language to the application language • transaction integration/interaction between DOM and the application LAIs
RDBMS
QUEL
SpreadSheet
HyperText
SQL
Oracle
Sybase
Figure 6: LAI Generalization Hierarchy Most requirements of a DOM-IDE are determined by the object model and related computational model underlying the DOM. The object model for DOM, called FROOM [5], is the primary focus of DOM research. Some of the characteristics of the model that the DOM-IDE must accommodate are: • object-orientation • inheritance and subtyping • distribution • distributed computing • complex objects • consistency mapping • materialization support • query processing/optimization/mapping • transaction integration/interaction/mapping • active objects. IIS Development Workshop Themes The work described above addresses some of the themes of the IIS Development Workshop. The OSE provides a means for writing specifications and transforming them into designs, automatically generating implementations, and providing means for monitoring and maintaining the DOM-OS (and in part, the IIS). DOM takes advantage of reusability that comes largely from object-oriented technology. The DOM Object Library and the DOM-OS will contain DOMs, LAIs, and many other objects that can be modified, using the OSE, to meet specific requirements instead of developing these components from scratch (e.g., as described above in the section Using An IIS Development Environment). A significant form of reuse is the primary motivation of the DOM research, namely support of interoperability amongst heterogeneous, distributed computing resources. This permits the reuse of entire information systems and their combination with new and existing computing resources.
8
References [1]
Frank Manola, "Distributed Object Management Technology," TM-0014-0688-165, GTE Laboratories Incorporated, June 30, 1988.
[2]
Frank Manola, "Object Model Capabilities for Distributed Object Management," TM-0149-06-89-165, GTE Laboratories Incorporated, June 30, 1989.
[3]
Frank Manola, Alejandro Buchmann, "A Functional/Relational Object-Oriented Model for Distributed Object Management: Preliminary Description," TM0331-11-90-165, GTE Laboratories Incorporated, December 31, 1990.
[4]
Mark F. Hornick, "NEMIS: Network Editor and Monitor Interface System," TC0108-08-90-165, GTE Laboratories Incorporated, August 1990.
[5]
Mark F. Hornick, "An Initial DOM Prototype," TC-0102-06-90-165, GTE Laboratories Incorporated, June 1990.
9
