The move of IRDS repository standards toward object orientation

Computer Standards & Interfaces 15 (1993) 307-318 307 North-Holland

The move of IRDS repository standards toward object orientation

Robert Hodges Texas Instruments, P.O. Box 86930.5, MS 8482, Plano, TX 75086, USA

Abstract

Standards for repository systems are in the midst of a move toward an object-oriented foundation. Repository systems need object management concepts like inheritance, encapsulating operations, and name overloading to function with the flexibility and extensibility required to control and integrate information at an enterprise level. Object orientation provides the necessary basis for future evolution of repository standards to knowledge management solutions that support a full and rigorous definition of the meaning of an enterprise's information and business policies.

Keywords. IRDS; repository; services architecture; object services.

1. Introduction

This article presents an overview of the author's understanding of the direction of the Information Resource Dictionary System (IRDS) standards toward the incorporation of object-oriented concepts. It represents work in progress of the X3H4 Technical Committee (TC) established by the American National Standards Institute (ANSI) for development of IRDS standards.

The first section provides background on the key problem areas an IRDS repository could ad- dress and IRDS standardization efforts. This background is then used to help establish why object management concepts are needed for IRDS standards. The article then introduces a proposed IRDS services architecture and illustrates the role object concepts play in that structure. The next section focuses on the services interface and its use of an object-request mechanism to make extensible object services available to using applications. Finally, the article ad- dresses the role of object concepts as a step

Correspondence to: R. Hodges, Texas Instruments, P.O. Box 869305, MS 8482, Piano, TX 75086, USA.

toward the emerging logic-based standards for IRDS conceptual schema.

The terms 'Information Resource Dictionary Systems' and 'repository system' can generally be considered synonymous in their usage within these standards bodies. Any IRDS implementation could be considered a repository, although all repositories may not adhere to IRDS standards. IRDS originally had a much narrower scope than that proposed under current standardization efforts, initially focusing on data dictionary applications. The term ' IRDS' is now being used to refer to the standards that define repository technology concerned with managing objects that contain and represent the information resources of an enterprise. The term 'repository system' is sometimes used instead of ' IRDS' to imply the broader and more active role of the systems now being standardized.

The services architecture discussed in this pa- per will be articulated in an IRDS Services Archi- tecture Technical Report being developed as a US National Body contribution to the ISO IRDS Rapporteur Group 1RDS Framework project. This architecture is intended to provide both a unifying mechanism for standards being developed within the IRDS standards bodies and for

0920-5489/93/$06.00 (© 1993 - Elsevier Science Publishers B.V. All rights reserved

308 R. Hodges

those standards being developed elsewhere which the IRDS standards depend on or support. The architecture will be the organizational structure for the specification of requirements, not a specification of the repository system design or implementation approach.

2. Background

2.1. A brief history and status of IRDS and repository standards

In 1988 ANSI created the first IRDS standard, X3.138. That standard was subsequently established as a US Federal Information Processing Standard (FIPS). ANSI has since issued IRDS standards for a services interface (X3.185) and an Export / Import File Format (X3.195). ISO, in an overlapping effort, standardized the ISO IRDS Framework (IS 10027) and ISO IRDS Service Interface (ISO 10728).

The definitions of services in these existing IRDS standards assume either a relational data model (in DIS 10728) or an entity-relationship

data model (in X3.138). In both cases, repository contents are essentially passive data stores that are acted upon by a variety of external information management processes.

The US national body for IRDS standards, X3H4, and the ISO IRDS Rapporteur Group are now working on extensions to the current standards (in the form of change proposals to IS 10728) that define a repository that contains objects. Besides stored state information, the objects define the operations that act on the information. This encapsulation of the stored data by the active operations that manipulate it will enable repository systems to provide specialized services to manage and manipulate complex information. The common characteristics of objects will be factored into object types that may serve as supertypes, allowing sharing and reuse through inheritance.

The US X3H4 IRDS TC has also proposed development of a new standard for an IRDS Normative Schema that would be capable of expressing the full semantics of IRDS managed information. An accompanying normative language will provide one means of expressing the

Application system Layer

Repository Symms Layer

Support Systems Layer

thmr,~ksUorm

Funa~rm

Technk~ Applk,~u,~

Irl~nlltle~ Model ~nl~l I d o l /

FodllUes

eommunl~alon Protocol

/ Kemd

DDIJDML I~,~.,~ CoK¢'ol Brdn~ Bndrn~

Comnlunleelm~ Protocol Blndln~ I eammunlc~lon

Content Module Interface

Support Services Interface

Fig. 1. Repository context reference model.

IRDS repository standards 3{}9

normative schema constructs. Other semantically equivalent languages may also be defined to allow alternate language interfaces.

2.2. Role of a repository within an enterprise

A repository is used within the context of an enterprise to solve several fundamental problems. The need to solve these problems supplies the underlying motivation for the development of repository systems and the standards that enable those systems to work together in an open environment. These problems are becoming more critical in an increasingly information intensive competitive environment. The challenge of integrating diverse data and the applications that manipulate it into a meaningful information base is the main reason for repository systems. Some of these problems will require solutions that deal with information as objects.

Figure 1 shows a layered representation of the repository context within an enterprise taken from the Repository Context Reference Model Techni- cal Report recently approved by X3H4. This model shows the repository systems layer in its role of providing services to varied enterprise applications. Those services are provided through bindings to a diverse collection of underlying support services that actively link the repository system to the information resources of the enterprise. Fundamentally, the repository system's role includes bridging between software development and operations environments, between distributed, heterogeneous applications, and between separate cooperating enterprises. The repository system must become a key enabler for enterprise integration. This enterprise integration role is elaborated in the problem discussions that follow.

2.2.1. Integrating data and applications An enterprise depends on information and

data processing resources that have grown incre- mentally over many years of development. These data stores and applications often contain hidden inconsistencies and incompatibilities. They usually span a wide range of technologies and support environments. Business policies and rules are embedded within application logic and storage schemas of these systems, and subtleties of

meaning can be lost. To compound this problem, new applications must be developed to implement changing business policies and replace resources whose policies are no longer aligned with the enterprise. The new systems must often inter- act with existing information resources.

End users, those responsible for running the enterprise, must somehow deal with this array of applications and information. They need a resource that helps them cope with the complexity and diversity of this environment while maintain- ing their focus on the meaning of the information.

Developers and maintainers of information systems also need a single logically integrated source of information about information resources to support the cost effective evolution of those systems to stay current with evolving business policies. Change must somehow occur at increasingly rapid rates to keep up with global competition, changing management styles, and unpredictable economic, political and technologi- cal forces.

A repository system will provide services and facilities for storing a wide range of information about enterprise policies, information and processes. By defining, standardizing and integrating the information about an enterprise's information systems, the repository becomes the vehicle for managing those resources as a business asset. Repository objects that represent and encapsu- late legacy data and applications can enable active methods providing access to needed information. The repository will begin to play a key role in the end users day-to-day use of information as well as aiding the development of new information systems.

2. 2. 2. Managing distributed applications Information management and processing ap-

plications are becoming increasingly distributed. Cost effective solutions to business problems must exploit the increasingly economical computing resources of distributed server environments. These resources will become more critical to the enterprise as centralized mainframe applications are downsized to midrange systems and servers.

Distributed information resources present a growing management challenge because tools to manage distributed environments are lagging the

310 R. Hodges

development tools and consequently, the applications. Development organizations may take such infrastructure tools for granted because of their ubiquitous availability in mainframe computing environments. Enterprises need a coordinated way to locate, maintain and manage their distributed information resources and to apply business policies for information management.

A repository system will offer a globally available resource for specifying and enacting an enterprise's policies for managing the distributed information environment. A common services interface and portable API bindings will make repository facilities available from a wide range of platforms. The integration of information about network resources with information about the applications and data they support will provide a foundation for control and production level support in a heterogeneous, distributed environment.

els must be defined in a way that preserves their meaning. The information can then help the enterprise manage, maintain, and use the opera- tional systems the CASE processes generated.

As CASE tools become increasingly open and standardized in their representation of software engineering information and repository implementations become more robust and available, the gap between the CASE process and opera- tional information environment will diminish. CASE tools will seamlessly populate the enterprise's repository and will make the repository objects readily available to the CASE processes. Common services such as configuration management and change control will be used by CASE tools through shared repository facilities. The in- creased consistency will enhance the enterprise's ability to coordinate management of its information assets.

2.2.3. Integrating CASE development with systems opera tions

Capturing data about the information resources of an enterprise can be a difficult and labor intensive task. Capturing accurate information about new systems being developed is chal- lenging, but that challenge pales in comparision to the task of documenting existing information and applications. An enterprise needs a coordinated means of capturing and integrating data about its information resources.

The information captured by Computer-aided Software Engineering (CASE) tools can provide a rich source of data about the enterprise, its information and processes. Modeling tools, reverse engineering tools and reengineering tools all con- tribute to this pool of useful information. The CASE tools, on the other hand, need a source of information about systems being updated or in- terfaced to. The value of this information is lim- ited to the development lifecycle unless it is integrated into a repository of information about operating systems.

This integration may be complicated if information from CASE processes, is fragmented into separate models (possibly using different modeling techniques). To leverage this source of information, the CASE data must be captured and managed as a global resource. The complex objects and relationships that compose CASE mod-

2.2.4. Enabling inter-enterprise information sharing Modern enterprises must often cooperate with

one another in teaming arrangements that include partners and customers with separate and incompatible information resources. To succeed in these teaming arrangements, the separate enterprises must learn how to exchange and share information in ways that preserve its meaning and integrity. The complexity of modern products and businesses will continue to increase the problems of sharing increasingly complex information.

Teams need mechanisms that simplify the specification of the shared objects upon which enterprises can base information interchange. These common business models can then become the basis for analysis and mapping of enterprise- specific information to standard interchange formats for inter-enterprise exchanges.

The information repository will provide a means for specifying, standardizing and exchang- ing content models defining meaning and structure of the shared information. Standards such as Electronic Data Interchange (EDI) and Product Data Exchange Specification (PDES/STEP) will continue to proliferate and offer a foundation for information interchange between enterprises. The repository will become the manager of these common models and enable an enterprise to more easily map their existing information to an exchange specification or shared database

IRDS repository standards 311

3. Why repository standards need object information management

The standards for information repository implementations need concepts that have evolved from object-oriented methodologies. The characteristics of object information management models help solve problems of managing an enterprise's information resources.

3.1. Encapsulating dit,erse representations

The information of an enterprise exists in many forms. Computerized systems for managing information have typically evolved over many years, based on technologies that were prevalent at the time. Many of these information systems remain essential to the operation of the enterprise, while becoming more difficult to maintain and integrate with new systems as they age.

An object model can provide a unified view of information while encapsulating the details of the information's representation, location or methods of access. Type specific operations on repository objects can actually access external methods implemented for specific types of data. Data stored in flat files, hierarchical, network, or relational databases can be treated as information objects within an object-oriented repository. The object encapsulation hides the physical aspects of the data management technology, allowing the information to be more easily used and integrated.

3.2. Defining behavior of active resources

The information of an enterprise is a dynamic resource that undergoes constant change as the information is created, is manipulated and is deleted or archived. Other behaviors are not lifecycle related, but reflect events and changes in the business environment. A state change in op- erational data may itself be valuable information to decision makers. Changes in business data might need to trigger processes that propagate the change through a system of interactions that represent the policies of the enterprise.

In this dynamic environment, information resources are best represented as active objects with specialized behavior. A single object can offer different operations as it transitions through

its predefined lifecycle. Processes that change the state of objects may be enacted in response to requests or environmental conditions. The concept of set of operations establishing the behavior of an object is well suited to a repository that must manage active resources in a constant state of flux.

3.3. Achieving reuse and consistency through inheritance

Information used by an enterprise varies widely in meaning, representation and behavior. These variations, however, naturally fall into repetitive patterns where distinct types of information share common properties. The natural organization of information into general classes by shared characteristics, coupled with the specialization by noted differences forms one basis for human understanding of a complex world. To manage information in a cost effective way, similarities must be exploited, but without masking essential differences that have business significance.

The generalization-specialization concept of object inheritance exploits this organization to maximize the sharing and reuse of common resources. It further helps avoid unnecessary complexity by promoting a consistent treatment of the common aspects of information. The definition of common behaviors that can be associated with general classes maximizes the potential for reuse of implementation resources by promoting reuse of repository methods. The diversity of information and resources managed by repository systems requires inheritance and specialization to support the many problem domains with a single management solution.

3.4. Supporting diversity with an object request interface

A variety of database formats now typically coexist to manage structured enterprise data. New information types such as graphic images, pre-in- dexed text, video and sound will require optimized management solutions. The repository system of an enterprise will eventually need to manage many such optimized repositories implemented on distributed heterogeneous host platforms.

312 R. Hodges

The information of an enterprise is spread out in many storage systems using different formats and interfaces. Information from different sources is often needed by a single application. Rather than forcing the application developer to deal with multiple, application-specific interfaces, object-orientation allows the use of a single interface that accepts requests in the form of messages. A single object request protocol can allow an application to access information and obtain services from a variety of sources. An object request can be passed through adapters to the systems providing the services without making the execution details visible to the requester.

Although the repositories may be specialized to manage particular types of objects, common object interface concepts will allow them to support a generic interface for object requests and queries. This common object services interface

will allow a diverse collection of specialized repositories to be managed as a single, virtual repository system that integrates the complete array of information of the enterprise

4. An object-oriented services architecture for repository standards

An architecture is a unified and coherent structure that specifies components and the inter- relationships that establish how those components fit and work together. An architecture can be conceptualized from a specific perspective focusing on an aspect or view of its subject. These perspectives are architectures that can, themselves, become components in a higher-level architecture serving to integrate and unify them into a coherent whole.

COMMON ( USER INTERFACE

APPUCATION

SERVICES INTERFACE I

CONTENT f MODULES

KERNEL SERVICES

SPECIFICATION

PRESENTATION EVENT CAPTURE DIALOG MANAGEMENT ]

\ i / Mode~

OBJECT REQUEST OBJECT QUBRY OBJECT CONTROL

i CORE OBJECT MODEL

IDENTn'Y - ENCAPSULATION - INHERITANCE - POLYIdORPHISM

COMMUNICA"i'ION 8TORAGIE MANAGIBABcr ~ MANAGEMB/T

ENVIRONMENT

TOOL

BINDING

I REPOSITORY FACILITIES

KERNEL IMPLEMENTATION

IMPLEMENTATION

Fig. 2. Repository services architecture overview.

1RDS repository standards 313

A software architecture applies this definition of architecture to the domain of software systems. A software architecture is a structure that supports specification of software components and their interconnections. The software components can include not only those which define pro- grammed instructions for execution by computer processors, but also those that specify software in human terms. The interconnections between software components include both compositional structures that govern how subcomponents are combined to become more complex components and the interfaces that knit components together into a unified structure.

Repository standards focus on a further specialization of software architecture, a services architecture that deals with the specification and dynamic organization of services provided by heterogeneous executable components. Components in a serves architecture can be added or removed dynamically after a system is running. This is sometimes called 'plug and play' integration. The components may exist independently and yet be incorporated into the services architecture. The architecture establishes a structure to unify these components or service 'building blocks' into a single coherent topology. Thus, a services architecture is a specification of a set of executable software components, the integration mechanisms for their combination and interaction, and their dynamic composition into a unified structure with common external interface semantics.

A services architecture does not specify the details of implementation, it can establish rules or constraints that must be observed in making implementat ion choices. These rules are particu- larly important for services architectures to en- sure that additional service components can be dynamically incorporated.

Requirements for repository standards are being organized through a services architecture that partitions repository functionality using object- oriented concepts. A core object model will support the definition of generic base services that together form the kernel of the repository system. That kernel will support content modules that represent the models for the information the repository contains. Together, the content modules for a repository system define the information model for the enterprise. Figure 2 provides an overview of the repository services architecture structure. Portions of this illustration will be discussed in the sections that follow.

4.1. Terms and definitions

object type: A specification of properties (attributes and relationships), operations that define the behavior of objects and integrity rules that apply to those objects.

seruice: A related set of operations that are invoked through the interfaces for one or more object types in response to requests or detected conditions.

content moduh,: A specification, for a particular universe of discourse, of a set of object types including the rules governing the interaction and behavior of objects of these types.

facility': An implementat ion of a content module 's with methods to support all operations defined by the content module 's object types and the capability to store the module 's persistent objects.

application programming interface (API): A set of functions that provide the complete interface required by an application for obtaining services from a tool or facility.

API binding: The implementat ion of an API within a specific programming environment.

sert~ices interface: An application programming interface with a core object model that serves as the foundation of the object types defining the offered services.

repository core object modek The specification of the behavior of the root object type. All other repository object types inherit properties, operations and integrity rules from the root object type.

root object type: The object type that packages primitive properties, operations and integrity rules that must be used as the basis for all other object types.

repository kernel." The combination of the core object model, its underlying defining and normative schemas and the set of base services that are inherent to repository systems.

repository base serL,ices: That set of services that are inherent to repository systems, for example, naming, versioning, and object lifecycle services.

foundational content modules: The content modules whose subject area is the repository system as a universe of discourse.

314 R. Hodges

4. 2. The repository core object model

A core object model is the heart of the services architecture. It realizes the concepts of object identity, encapsulation, inheritance, and operation name overloading. The repository standards will build upon the efforts of other standards efforts such as the Object Information Manage- ment Technical Committee (X3H7) for definition of that core model. The IRDS conceptual schema will provide a rigorous basis for defining the semantics of the core object model used by the repository architecture.

An important extension of the core object model will be the definition of an appropriate object specification language for the object services and content modules. This language may be based on work to extend the SQL standard to encompass object concepts. It will also need to provide semantic extensions to declaratively define aspects of meaning that go beyond the current capabilities of object orientation.

4.3. Base services of the repository kernel

The common behaviors required of repository objects will be specified as a collection of base services. The services will become implicit 'library' of repository objects types. Some of these types will be used through inheritance to the domain

specific objects that represent the enterprise information assets. Other services will be provided to repository objects through exchange of message based requests. Multiple inheritance and subtype specialization of inherited behaviors will enable this collection of services to be tailored and extended to meet the particular needs of different enterprises.

Examples of repository base services include services such as: • Lifecycle service • Name service • Version service • Event service • Relationship service • Security service • Audit-trail service • and many others.

The specification of repository base services will use the efforts of a diverse range of standards bodies and consortia that are focusing on particular subsets of the needed object behaviors. Where possible, the requirements generated through the repository services architecture will be offered to other groups developing standards for base services needed by repository systems.

The base services will also provide the means to integrate the repository system with the information systems of the enterprise. The fundamental services for communication management, stor-

C O R E O B J E C T M O D E L I D E N T I T Y - E N C A P S U L A T I O N - I N H E R I T A N C E - P O L Y M O R P H I S M

Fig. 3. Core object model and base services.


age management, and process management will be tied to this core model. Communication services will enable use of a variety of protocols to link the repository system to the computing platforms of the enterprise. Storage services will provide access to storage systems that employ varied formats, including those of enterprise legacy systems. Process management services will provide for external execution of object methods through mechanisms such as object requests, remote invo- cation of transactions or adaptations of existing executable software. Figure 3 illustrates these components of the repository kernel.

4.4. Repository content modules

The information model for the repository, defining the information assets an enterprise needs to manage with the repository system, will take the form of a set of content modules. A content module is an object model that defines the collection of object types for a particular subject area. Many existing models from information engineering or other modeling disciplines could become content modules within a repository.

Some content modules will focus on the repository itself by defining subject areas such as common models for directory management or reference management information. Content modules for underlying storage management schemas (e.g. SQL or Unix file structures) will enable generic

access methods for externally stored information. Most of the content modules, however, will deal with the subjects that compose the information of an enterprise.

Many content modules will, themselves, be candidates for standardization by the standards bodies that govern particular subject areas. Possi- ble examples include the X.12 specifications for EDI, P D E S / S T E P , or CASE Data Interchange Format (CDIF). Standards for information models for CASE, library science or specific business areas are also potential subjects for future standardization.

Each enterprise will probably supplement se- lected standard content modules with specialized models that represent the unique aspects of their information or business policies. The integration of the collection of content modules will provide the definition for the objects to be contained in or managed through the repository.

Content modules will not exist in isolation from one another. The integration of the models for separate content areas offers much of the potential for enterprise integration through the repository. There are many technical issues still to be resolved in this area. Object concepts for dynamic schema evolution that allow the object types of a populated database to be extended or changed offer an initial direction for this integration. The IRDS work on conceptual schema will provide a more general basis for addressing the semantics of integration as it is defined. Figure 4

Repository Definition Network and Maintenance Management

Rnf twara RalJ~A

importr=xport

Fig. 4. Repository content modules.

316 R. Hodges

illustrates a set of content modules that cold support repository-specific subject areas.

4.5. Facility implementation and method bindings

plications from irrelevant or unnecessary details of service-providing implementations. The interface provides the mechanism for offering a wide range of services using common request syntax and semantics (Fig. 5).

The implementation of one or more integrated content modules becomes a repository facility. A facility can be used to help users work with the objects from a specific subject area perspective. To create a repository facility, a developer must use repository kernel services to make the objects of the module persistent. Then the developer must provide any specialized methods (implemented operations) that supply the specified behaviors for those objects. The methods of a facility need not employ an object-oriented implementation approach if the meaning and behavior of the content module specification are sup- ported. Different styles of implementation can be bound to the repository system using the process management services of the repository kernel.

4.6. An object-based services interface

4. 6.1. Need for a generic, common API The diversity of the information to be man-

aged through repository systems, and the broad base of vendors that will provide repository system implementations will generate a wide variety of repository implementation approaches. An enterprise will need to maintain flexibility to use a heterogeneous mix of repository and facility implementations. They will also wish to preserve an ability to migrate their repositories from one ven- dor product to another without costly loss of the information content.

To accomplish this goal, the diverse repository systems must provide a generic, common application programming interface (API) and services interface. A change in repository implementation should not require revision of all applications that use repository services if such a standard interface is used.

The facilities of a repository system are made available to applications through the repository system's services interface. These diverse services can be obtained by an application using a generic interface protocol. The interface acts as a neutral intermediary that shields service-requesting ap-

4.6.2. Pass-through object requests The mechanism that can enable creation of a

single, common services interface is the object request. When coupled with an object query lan-

USER ( INTERFACE I PRESENTATION ENVIRONMENT

APPLICATIONS

\

\ Support

EVENT Cd~u'TU RE

OBJECT QUERY

DIALOG MANAGEMENT I

/ Modeling

/ C++{~=AMI.~)BINDING 1

OBJECT CONTROL

Fig. 5. Repository services interface.


guage, the object request allows any application to operate in terms of the content module objects of its particular subject area view. A standard definition of the request structure and message passing semantics will allow a common interface to serve a wide variety of using applications.

The messages containing the object requests are passed through the services interface to the facility that provides the implementation of the requested operation. The requesting application need not know how or where the method is executed. This interface-based layering provides the enterprise with the needed flexibility to manage, maintain and evolve their repository system implementation without a costly ripple effect through using applications.

4.6.3. Object query language interface A repository system needs to be able to per-

form queries that select collections of objects based on declarative selection criteria. The information that is managed through the repository system may be most useful in meaningful aggre- gations. These combinations of objects can represent the knowledge that supports business deci- sions. An object query language is needed to

serve as an adjunct to procedural programming language methods and to supplement predefined operations with an ad-hoc query ability.

4.6.4. Distributed object request brokering Standard approaches for managing distributed

object request interfaces and implementations (i.e. OMG's Common Object Request Broker Ar- chitecture) could provide a sound basis for the distribution of repository systems components within the infrastructure for an enterprise. When coupled with an integrated enterprise-wide directory management facility, object request brokering may become a key enabling technology for repository systems. Requests may be routed to the repository from requesting applications. The repository may in turn make requests of remote support systems or other repository servers.

4.6.5. Transparent integration of external methods The rules that embody the policies of an enter-

prise are typically captured in the many programs of existing information systems that operate on the enterprise data. To manage costs, this legacy of information processing resources must often be preserved until the rules they implement

[ • . I R D S

i.' Normative L a n g u a g e s

CORE OBJECT MODEL KIF

e.g., IDENTITY- ENCAPSULATION -INHERITANCE - POLYMORPHISM IRDS sc~ma~r~5

IRDS Normative Schema e.g., CORE OBJECT MODEL CONSTRUCTS + OTHERS

IRDS Defining Schema e.g., TYPE, IMPLICATION, NEGATION, OBJECT, ASSOCIATION

Fig. 6. Conceptual schema foundation for the core object model.

318 R. Hodges

change. When the data these systems operate on is defined to a repository as objects, the programs become the methods that implement the operations on those objects.

An operation request made through the services interface could actually be implemented with a legacy method. Such integration of existing programs with object models for enterprise information could enable the repository to help bridge from legacy information processing resources to future information management solutions.

4. 7. A step toward higher-order semantics

Although object orientation promises solutions to many problems of repository system standards, it clearly falls short of the vision of a knowledge- based repository. Much of the knowledge of an enterprise cannot be captured declaratively in an object model. The future of IRDS standards for repository management of knowledge lies in the use of even more fundamental representations of knowledge, in the form of logic-based conceptual schemas (Fig. 6).

4. 7.1. Semantic limits of object concepts Object models effectively capture the charac-

teristics and behavior of individual objects. Inher- itance, encapsulation and aggregation provide the means for defining more complicated behavior patterns for complex objects. These techniques still fall short in the ability to declaratively define the constraints applied against operations and the behavior of a collection of objects that comprise a system.

An object specification consists of the properties and operations of the object types that char- acterize an object. These specifications are in terms of an interface, but do not elaborate on the assumptions about what happens when that operation is performed. That information, if captured at all, is usually in the form of structured language or pseudocode. This can lead to method implementations that inadvertently vary in signifi- cant ways.

A further limitation of object models is in the ability to clearly define the ways that communi- ties of cooperating objects behave as a system enacting a complex business process. The com-

plexities of states and interactions make it difficult to use object model specifications to define deterministic behavior for such a system.

4. 7.2. Role of conceptual schemas in future repository standards

Active work is progressing in the IRDS standards groups to define a more fundamental basis for the specification of knowledge managed through repository systems. The object model of the repository can be based on the more general conceptual schema that is itself based on a defining schema of fundamental concepts. The object model can then be extended with the use of logic-based languages that are based on that common foundation.

5. Conclusion

The move of repository standards toward a foundation based on object-oriented concepts is a necessary next step toward the vision of an enterprise-wide knowledge base. Object orientation provides constructs for organizing information such as encapsulating behavior, inheritance and identity that are not available in entity-relationship or relational standards. This standard's evolution will enable the development of repository implementations that can cooperate in an open, heterogeneous, distributed environment. This move will also support the evolution of IRDS standards toward a more fundamental logic basis that will allow a realization of the repository as the aggregation of the collective knowledge of an enterprise.

~ i l ~ Bob Hodges works in the Advanced Enterprise Systems Department of Texas Instruments Information Sys- tems and Services group. As a Mem- ber, Group Technical Staff of TI's Information Technology Group, Bob contributes to the definition and architecture of TI's future computing infrastructure. Bob currently chairs the IRDS Archi- tecture and Integration Task Group and serves as editor of the Repository Services Architecture Technical Re-

port. Bob also edited the Repository Context Reference Model Technical Report that was recently approved by the X3H4 committee. In addition to working on the IRDS committee, Bob acts as TI's alternate to the newly formed X3H7 Techni- cal Committee for Object Information Management.

The move of IRDS repository standards toward object orientation

Documents

Transcript of The move of IRDS repository standards toward object orientation