1、ANSI INCITS TR-12-1993(formerly ANSI X3/TR-12-1993) Information Processing SystemsTechnical ReportRepository ContextInformation Resource Dictionary System (IRDS)Reference ModelInformation Processing SystemsTechnical ReportX3/TR-12-93Repository ContextInformation Resource Dictionary System (IRDS)Refe
2、rence ModelDeveloped by American NationalStandards CommitteeX3, Information Processing SystemsiAccredited Standards CommitteeX3, Information Processing SystemsDoc. No.: X3H4.1/92-002R3X3H4/92-079R2Doc. Date: September 24, 1992Project: 570-DTReply to: Robert E. HodgesTexas Instruments, Inc.P.O. Box 8
3、69305, MS 8482Plano, TX 75086(214) 575-3442, FAX 575-Repository ContextReference ModelTechnical ReportSecretariatComputer and Business Equipment Manufacturers AssociationApprovedAmerican National Standards Institute, Inc.AbstractThis Technical Report is an Accredited Standards Committee X3H4 working
4、 paperintended to provide a picture of the full strategic scope of repository functionality as itis currently understood. This report describes the positioning of repository functionswith respect to information technologies that use repository services and those thatsupport repository implementation
5、. The focus of this report is on the interfaces thatserve as isolation layers between the repository and these related informationtechnologies.X3s Technical Report SeriesThis Technical Report is one in a series produced by American National Standards Committee,X3, Information Processing Systems. The
6、 Secretariat for X3 is held by the Computer andBusiness Equipment Manufacturers Association (CBEMA), 1250 Eye Street, NW, Suite 200,Washington, DC 20005.As a by-product of the standards development process and the resources of knowledge devotedto it, X3 from time to time produces Technical Reports.
7、Such Technical Reports are not standards,nor are they intended to be used as such. X3 Technical Reports are produced in some cases to disseminate the technical and logical con-cepts reflected in standards already published or under development. In other cases, they derivefrom studies in areas where
8、it is found premature to develop a standard due to a still-changingtechnology, or inappropriate to develop a rigorous standard due to the existence of a number ofviable options, the choice of which depends on the users particular requirements. TheseTechnical Reports, thus, provide guidelines, the us
9、e of which can result in greater consistencyand coherence of information processing systems.When the draft Technical Report is completed, the Technical Committee approval process is thesame as for a draft standard. Processing by X3 is also similar to that for a draft standard. Published byAmerican N
10、ational Standards Institute11 West 42nd Street, New York, New York 10036Copyright 1993 by American National Standards InstituteAll rights reserved.No part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permission of the publishe
11、r.Printed in the United States of AmericaAPS1.5C1093/40ii CONTENTS 0. Foreword . 11. Introduction . 32. Scope 43. Normative References . 64. Definitions it is consistent in that the database is left in a consistent state following thetransaction; it is isolated from other transactions; and it is dur
12、able following completion ofthe transaction. A transaction is uniquely identified by a transaction identifier.version:A configuration of all or part of an information system at a specific point in time.125. Goals and ObjectivesThe objectives of the Repository Context Reference Model support the gene
13、ral goals forrepository standardization. These goals provide the motivation behind the objectives of thisdocument. This section defines the objectives for this reference model and the broader goalsfor repository standardization that drive those objectives.5.1. Reference Model MotivationThe Repositor
14、y Context Reference Model needs to support several major goals that forrepository standardization. These goals include the following : Enable information sharing. Support location independence. Minimize support costs. Provide controlled commit or rollback of repository work units. Allow heterogeneou
15、s facilities to cooperate. Enable information interchange between repository systems. Integrate related standards.5.1.1. Enable Information SharingThe objects managed in information repositories contain and represent information resourcesof an enterprise. The functions that operate the enterprise ne
16、ed a shared understanding ofwhat the information means, how it is used, and how to obtain or maintain it. Globallyaccessible repository objects capture meaning, behavior and access methods forinformation, and thus enable the sharing of the information itself.5.1.2. Support Location IndependenceA use
17、r of a repository does not need to know where information is physically stored.Requests for repository services should identify the objects of interest by logicalcharacteristics instead of the address or location of the objects. Consistent enterprise-wideobject addressing needs to be an implicit asp
18、ect of repository standards to enable location tobe transparently accomplished by the repository system.5.1.3. Minimize Support CostsThe cost of supporting an information system accrues from all phases of its life cycle,including both development and operational costs. A key goal of repository stand
19、ards is toallow the users of repositories to maximize benefits from current information systems in achanging environment. Repository standards must help lower costs by providing the basis forinteroperability of existing and new information resources and maximizing potential forcontinued use and reus
20、e of existing assets.135.1.4. Provide Controlled Commit or Rollback of Work UnitsRepository users need to have control over groups of operations that can be applied withatomic, consistent, isolated and durable results. These operations may involveheterogeneous, distributed repository facilities or s
21、upport systems. The database transactionconcept is the appropriate basis for addressing the issues of integrity, recovery, andconcurrency control for a repository system. Repository standards need to supporttransaction management for repository operations.5.1.5. Allow Heterogeneous Facilities to Coo
22、perateIt must not be necessary for all repository facilities to be supplied by the same vendor tohave the services interoperate. Heterogeneous repository facilities need standards forconsistent use and exchange of common services. The facilities should react predictablywhen a service request receive
23、d from any requester.5.1.6. Enable Information Interchange between RepositoriesTo share information among cooperating repository systems, standard import/export formatsare needed. Import and export facilities are particularly important in permitting the sharing ofinformation between CASE tools and r
24、epository facilities. These interchange formats mustalso support the preservation of archived repository information. Interchange standards canensure that evolving repository implementations can use archived information. Objectinterchange standards should support import and export of object schemas
25、and theinformation bearing objects themselves.5.1.7. Integrate Related StandardsRepository implementations necessarily intersect a wide range of standards focusing onspecific technologies. Repository standards must address these points of intersection tominimize redundancy and incompatibility and en
26、sure complete coverage of the technologiesrequiring standardization. Just as repositories can help integrate enterprise information,repositories can support the effective use of separate standards by integrating theinformation models of those standards.5.2. Reference Model ObjectivesThe objectives o
27、f this Repository Context Reference Model are:1. Identify the services, facilities, interfaces, and technologies that are integrated usinga repository within an information systems environment. The role of a repositorysystem cannot be defined in isolation from the information resources it integrates
28、 andmanages. An objective of this report is to characterize not only the repository system,but the components of the information environment within which the repositoryoperates.2. Provide a context for the development of a repository services architecture. Theinternal architecture of repository serv
29、ices and facilities needs to be defined within aknown usage context. An objective of this report is to enable these aspects ofinternal architecture to be defined within a defined context.143. Locate impact of standards (existing, emerging and needed) in relation to repositoryservices and interfaces
30、to facilitate the incorporation of existing standards. Thestandards that are needed to support a repository system cover a broad range ofstandardization domains. Another objective of this report is to provide an overview ofrelated standards that are needed to supplement the emerging repository stand
31、ards.4. Introduce terms and concepts of repository functionality. Existing terminology is notalways adequate to convey new concepts that support repository standardization.The term “repository“ has a general meaning, “a place where something is stored,“that is consistent with the terms usage in this
32、 report. This generic definition, however,fails to capture the growing, active role envisioned for repository systems within aninformation system environment. An objective of this report is to help educate abroad audience about repository concepts and the role envisioned for a repositorysystem withi
33、n an enterprise.5. Position the use of repository services and interfaces in terms of the total informationsystems environment. A repository can only approach its goals within an enterprise ifit encompasses the total information environment. Partial management solutions arehelpful, but fail to deliv
34、er many enterprise integration benefits that are sought. Anobjective of this report is to establish a broad definition of the environment served bya repository system.6. Identify interface and binding boundaries associated with repository services. A basicprinciple for repository systems is the spec
35、ification of well formed interfaces. Theseinterfaces include both those that enable repository using application to obtainservices and those that enable the repository to actively interact with support systemsto manage enterprise information. An objective of this report is to identify thoseinterface
36、 boundaries.156. Reference Model RequirementsThe requirements for the Repository Context Reference Model are as follows: The Repository Context Reference Model shall be in harmony with related referencemodels and frameworks such as the Information Technology - Reference Model ofData Management and R
37、eference Model for Frameworks of Software EngineeringEnvironments (Second Edition). The full harmonization of the repository perspectivewith these references will involve not only this document, but also the RepositoryServices Architecture (see Figure 1 - Framework for the Evolution of RepositorySta
38、ndards). The reference model shall adapt to developments in technology. The reference model shall hold to the principles of layering for reference modeldevelopment as described in the ISO Open Systems Interconnection (OSI) referencemodel.The principles of layering which have been considered in this
39、report are summarizedbelow:P1: keep the total structure simple;P2: create boundaries only at points where interactions across theboundaries are minimized;P3: separate into different layers those functions that are very differentin nature and purpose;P4: Collect within a layer those functions that ar
40、e similar or highly inter-related;P5: select boundaries at points that experience has shown to besuccessful;P6: create layers such that the internal mechanization of such layerscan be made independently from the functionality that it provides;P7: create boundaries where it may be useful at some time
41、 to have areal physical boundary;P8: create a layer where there is a need for a different level ofabstraction in the handling of data;P9: create layers such that changes of functions and protocols can bemade within a layer without affecting other layers;P10: create for each layer boundaries with its
42、 upper and lower layer only.167. AudienceThis technical report is intended for these audiences : Individuals responsible for the development of repository related standards. Implementors responsible for the development of repository products and productsthat interface with repositories. Professional
43、s responsible for supporting the engineering, operations, andmanagement of the information environment.Standards developers will find the Repository Context Reference Model useful for positioningstandards in relation to one another. Locating an existing or proposed standard within thedefined layers
44、of this model will help identify related standards that may offer opportunitiesfor harmonization. Redundant standards, conflicting standards and gaps in standardizationcan thus be minimized.Implementors developing repository products need to differentiate their repository productfrom the application
45、s that use repository services and from the underlying systems thatprovide basic services used by the repository. A well-defined boundary between therepository and the using application is needed to ensure generality in the repositoryimplementation. Application developers may encourage repository de
46、velopers to buildapplication specific services that cannot benefit other repository users. Similarly, anunderstanding of the value the repository adds to more general underlying support systemswill help the implementor differentiate their product from support systems such as object-oriented database
47、 management systems.A large audience of professional information workers responsible for a myriad ofmanagement, development, maintenance and operations support tasks will need tounderstand how a repository capability fits into their known environment. This referencemodel will provide a tool to help
48、educate this audience about the role the repository will playin their future.178. Service LayersA repository manages “objects.“ An object is a concept, abstraction or thing that has uniqueidentity, state, and a set of operations that can be used to influence the objects behavior.Examples of objects
49、are: an employee, an organization, the number “9,“ or the color “blue.”Such “real-world“ objects may be represented by corresponding objects manifested withininformation systems. The term “object management“ includes the description, creation,modification, use and control of objects with an information system environment. Thoseobjects may actually represent enterprise information that is not itself managed in acomputerized form. Objects flow into and out of repository systems. Interactions may be witheither humans or other computing systems and may oc
