VIEWS: 5 PAGES: 10 POSTED ON: 4/10/2011
Framework for Identifying Requirements for Standards for the National Information Infrastructure April 11, 1995 The Information Infrastructure Standards Panel (IISP) was created by ANSI and tasked with identifying requirements for standards that will be needed to develop the National Information Infrastructure (NII). This doc ument provides a conceptual framework to guide this process of identific ation. It is intended to serve as a mechanism for standards developers, Standards Development Organizations (SDOs), and others to identify areas where standards will be required. Where requirements for standards have been identified, the framework can be used to pinpoint existing and emerging standards that are candidates for satisfying those requirements. Identified requirements that cannot be matched to existing standards represent "gaps" that may need to be filled. It is expected that in the coming years, SDOs will fill "gaps" by creating new standards, evolving existing standards, or introducing mec hanisms to take the place of standards. These standards will be needed to ensure that the creation and provision of new technologies and services by commercial vendors can be easily integrated with existing technology. The results of the standards identification work will be recorded in a Standards Development and Tracking System maintained by the IISP. In recent years, a number of archit ectures for the NII have been proposed including , , , and . This framework is not intended as an NII architecture, nor does it subscribe to any proposed architecture. Such an NII architecture can only emerge as a result of long-term technology, economic, and social drivers. Instead, the framework is intended as a guide to facilitate the identification and development of standards that will be needed to realize the NII. TABLE OF CONTENTS Acknowledgements 1. Intended Audience 2. Framework Components: Applications, Services, and Interfaces 3. Using the Framework to Identify Standardization Needs for the NII 3.1 Suggested Attributes for Identifying Standards Needs 3.2 An Example of the Use of Attributes to Identify Standards Needs 4. Explanation of the Axis 4.1 Application Area Axis 4.2 Services Axis 4.2.1 Key Enabling Services 4.2.2 Supporting Services 4.3 Int erfaces Axis 5. Use of the Framework by Standards Development Organiz ations 5.1 Guidance in the Use of the Framework 5.2 Issues and Problems in the Us e of the Framework 6. References 1. Intended Audience The principal audience for the framework is standards developers and technology vendors. These groups are not always distinguishable. Both groups encompass comput er manufacturers, commercial software product developers, communications service providers, university researchers, and government pers onnel. Often technology vendors serve as standards developers when they participate in standards committees. However, standards developers and technology vendors have different points of view of the NII. Technology vendors may emphasize the development and implementation of services and applications as hardware and software systems on the NII. As standards developers they may concentrat e on interfaces at which standards need to be developed to facilitate interoperability between these systems. Ultimately, both groups must consider the NII from the point of view of end users who use application systems created by technology vendors. The framework is designe d to reflect the perspective of all three groups: users and NII applications, technology vendors and NII services, and standards developers and interfaces--with the ultimat e goal being the identific ation of requirements for standards for the NII to support the development of flexible and evolvable technology that will be usable in a wide variety of applications. The rest of this document is organized as follows. Section 2 provides an overview of major concepts underlying the framework. Section 3 describes the basic approach for using the framework to identify standards needs. Section 4 further defines the major components of the framework. Section 5 provides a guide to Standards Development Organizations for using the framework to identify standards requirements and identifies potential problems and issues. It is anticipated that SDOs will modify the basic approach suggested by the framework to suit their specific needs. 2. Framework Components: Applications, Service s, and Interfaces The identification of standards requirements is based on consideration of three fundamental factors: NII services, application areas, and interfaces: Application Areas represent commonly understood spheres of activity in which human users will use of the NII. Examples of such application areas include manufacturing, educ ation, healthcare, and entert ainment. Within application areas, application systems, consisting of both hardware and soft ware, are created by technology vendors and users. Services represent well-defined capabilities provided through the NII that can support activities within different application areas. Services are implemented by technology vendors as hardware and software systems that can be integrated into many different application systems. Examples of such services include collaboration (the ability for multiple users to work together on various tasks), electronic publishing, and commercial transactions. Services may also include multimedia support services, security services, and data interchange services. Services will be elaborated upon in section 4. Interfaces exist between the hardware and software systems that make up NII applications and/or services and the various external systems with which these applications and services must interact. The concept of interfaces provides a means for organizing the discussion of int eroperability between systems; NII applications and services will int eroperate across specific interfaces. Examples of such interfaces include interfaces between different application syst ems (and component servic es), interfaces bet ween application systems and information systems (databases ), and between application systems (and services) and the underlying communications network. Using the framework, requirements for standards are identified by (1) considering the use of services in different application areas, and (2) considering needs for interoperability at critical interfaces. Each of these three components will be elaborated in greater detail in section 4. Figure 1 illustrates the bas ic idea, showing a potential area of standardization at one point of intersection of the three axis. Click here for Picture Figure 1 Each point of intersection of the three axis represents a mapping of a particular enabling service to a particular application area and the requirement for achieving interoperability at a particular interface. For instance, it is necessary to consider what information systems interface standards might be appropriate for collaboration (cooperative activity) services in support of manufacturing applications. Each point in the model can thus be associated with a potential area for standardization. The elements listed along each axis are subjective. SDOs using the frame work will have to select elements and to customize and specialize them. 3. Using the Framework to Identify Standardization Needs for the NII The identification of requirements for standards within potential areas for standardization can be facilitated by considering attributes that particular services may have at specific interfaces. Attributes are aspects of the use of particular services for applications that need to be defined to allow services to interoperate at particular interfaces. They point directly to needs for standards. Examples of attributes include the data format transmitted and the protocol required for systems associated with a specific interface to establish, maintain, and terminate communications. For two application systems to interoperate, they must have compatible attribute values (For example, two applications must have a common format for exchanging information). 3.1 Suggested Attribute s for Identifying Standards Needs The attributes described below can be considered for each potential area for standardization--to determine what kind of standards may need to be developed to provide a particular service to a particular application area. No standard set of attributes can be defined that would be universally applicable. It will be largely up to SDOs to define attributes that meet their needs. Different attribut es are likely to be required for using different services in different application areas. A starter set of attributes to consider include: Protocol This attribute addresses issues of basic communications, including the need for a set of conventions to establish, conduct, and terminate communications between two parties across an interface that may be either multipoint or peer-t o-peer. Examples of prot ocol standards are Transmission Cont rol Prot ocol (TCP) , Remot e Data Access (RDA) , and the Z39.50 standard for retrieval of text information . Format This attribute is concerned with specifying the structure for encoding information to allow its exchange bet ween two parties (usually application systems). Examples of particular encodings include P DES/STEP , Electronic Data Interchange (EDI) , Hypertext Trans fer Protocol (HTTP ) , and SQL . Other encodings for image, video, and speech are also critical to consider. Content The specification of the type of information needed to support a service at an int erface. Di stributed Control This attribute addresses requirements for functions associated with access, replication, migration, concurrency, and synchronization that are needed to support a particular service. Security The process of cont rolling access to and/or maintaining the integrity of a service or the data used by the service. An example of a security standard is RSA. In addition to suggesting new attributes, users of the framework may specialize existing attributes into more precise forms that are useful in their areas of endeavor. 3.2 An Example of the Use of Attribute s to Identify Standards Needs The use of attributes to identify standards needs may be illustrat ed by means of an example. To understand what standards (or equivalent mechanisms) will be needed at the information system interface to enable the provision of collaboration services in support of concurrent engineering activity in manufacturing, the format attribute should be examined. In other words, it is necessary to consider the requirements for standardizing format in order to provide collaboration services in support of concurrent engineering in manufacturing. The P DES/STEP standard  may be used to fulfill the requirement for standardizing format of manufacturing product data. This same attribute may also point to the use of object-based SQL3 for manipulation of product dat a . Similarly, the attribute for protocol may also have to be considered. In a concurrent engineering environment, multiple DBMS products may be involved in a distributed long -duration updat e operation. These products will have to use a common protocol for communicating during the update operation (corresponding to the protocol attribute at the information systems interface). As yet a standard does not exist that fulfills this need. Protocol thus represents a "gap" that may need to be filled by evolving an existing standards or creating a new one. Figure 2 provides great er elaboration of the potential area of standardization identified in figure 1 and provides a graphical illustration of this example. Not every service attribute will be applicable in every pot ential area for standardization. In this example, the attribute distributed control may be irrelevant. Click here for Picture Figure 2 Where multiple standards exist to meet a requirement associated wit h an attribute, it is appropriat e to evaluate and compare the different standards to determine their usefulness. In addition, dependencies may exist between standards that fulfill requirements associated wit h different attributes associated with a potential area of standardization. For instance, in general data proc essing the use of the SQL standard  for content and format is closely associated with the use of Remot e Data Access  to fulfill protocol requirements. The standards requirements associated with particular attributes at particular int erfaces may be the same or different for the use of services within different application areas. By identifying standards requirements common to multiple services and application areas, the overall size and complexity of the framework can be significantly reduced. By identifying standards requirements that are unique to points of interface, an understanding of the interoperability needs of the NII can be achieved that will encompass a broader range of services and applications. 4. Explanation of the Axis This section provides an explanation of the elements listed along eac h of the three axis introduced in section 2. The list of elements is a suggested list. It is expected that standards developers, SDOs, and others using the framework will add, delete, and modify as appropriate. 4.1 Application Area Axis The application areas listed in figure 1 would require lengt hy descriptions to fully define and are to a certain extent subjective. Different persons may have a different understanding of each term, therefore definitions of application areas would be less useful in fulfilling the purposes of the framework. Interested persons wanting furt her explanation may refer to the NIS T publication Putting the Information Infrastructure to Work . These include manufacturing, healt hcare, education, government services, and environmental monitoring. In addition, other application areas have been suggested by members of the IISP working group. These include entertainment, defense systems, and business activities including support for telecommuting and the development of virtual organizations. 4.2 Services Axi s Two types of servic es may be distinguished: key enabling servic es and supporting services. Key enabling services represent broad categories of services applicable in multiple application areas. Supporting services are lower-level component services that serve as building blocks for the enabling services. Supporting services include multimedia services, security services, and data interchange services that can be integrated into many different enabling services. In some cases supporting services may be used directly by end users. Both enabling and supporting services may be considered along the Services Axis. Either enabling services or supporting services can be used along the services axis. Users of the framework will have to decide whic h type of service is more appropriate to their area of endeavor. 4.2.1 Key Enabling Services Enabling services constitute broad categories of capabilities that will be usable in more than one area across the applications axis. When used within different application areas, these services are often specialized. A list of suggested key enabling services is provided below. It is expected that users of the Framework will modify and specialize thes e services and add new services to the list. Collaboration This capability enables the coordination of interactions among groups of individuals who may be remote from each other. Examples of collaboration include electronic conferencing, cooperative engineering, collaborative document editing, and remote medical consultations. Commercial Transactions This is a set of integrat ed capabilities for supporting traditional commercial activities, including but not limited to, procurement (transmission of requests for quotations, transmission of bids and quotes, placement of orders, etc.), electronic funds exchange, currency translation, and others. Electronic Publi shing This capability enables the creation and distribution of electronic publicatio ns across the NII, including electronic books, periodicals, music, film, and others. Monitoring This is the capability of controlling and transferring data from external sensors that gather measurements of some environmental phenomena. Monit oring can be used to develop application systems that can be used in support of home security, fire protection, environmental regulation, and hospital patient care. Remote Process Simulation This is the capability of modeling real, imagined, or theoretical environments using sophisticated computing platforms and display units. Remote Process Simulation assumes that the computing plat forms may perform specialized tasks and that they and display units are distributed and possibly remote from each other. 4.2.2 Supporting Services Supporting services are intended to be general in the sense that they are utilized within more than one enabling service. The set of supporting services suggested below may be utilized within each of the enabling services presented in the previo us section. It is appropriate to substitute these and other supporting services along the services axis in order to identify standards needs. Multimedia Support Services These services include creating, updating, manipulating multimedia information. Security Services These include encryption, secure transmission, authentication, and authorization. Data Interchange Services These services provide the ability to translate dat a stored in different formats. Directory Services These services store data on information resourc es that can be accessed through the NII, including addresses. 4.3 Interfaces Axis The classes or types of interfaces identified below were taken from the CSSP , XIWT , JTC1 OSE , and NIS T Services Framework  architecture documents. Both the list of interfac es types and their definitions are preliminary and subject to change. An import ant goal of the NII is develop a coherent infrastructure into which a servic e provider may introduce new services and be confident that they will interoperate with existing services and application systems. This infrastructure will have to ensure that NII services and the applications they are incorporated into can interoperate with human users, other application systems and servic es, information systems, communications (bitway) service providers, and perhaps others. To fles h out the infrastructure, it is useful to consider a set of interfaces that can be defined across whic h interoperability between services must be established. In , , and , different types of interfaces are suggested for NII services. In addition, references  and  proposes a classification of services across these interfaces, based on analysis of many other references. The problem of identifying a complete, agreed upon set of interfaces for the NII remains a topic for negotiation and research. An initial set of proposed interface types is provided below and may be expanded by new submissions from SDOs. Application Program Interface This is an interface bet ween the application system and the supporting hardware and software systems(s) upon which the application system runs. This interface is used by an application system (or by a service provided directly to the user) to access enabling and supporting NII services (eit her services maintained locally or those accessed remotely through the Communications Servic es Interface described below). Communication Services Interface This is a boundary between an application system (together with its component software entities and supporting and enabling service incorporated into an application system) and the provider of data transport services across a net work or bitway. Human Technology Interface This is a boundary for physical interaction takes between a human being and the hardware and software computer systems(s) that provide access by the human to the NII. This interface involves all aspects of graphic user interfaces, keyboards, hand-held mice, and other services and systems that support interactions between humans and computer systems. Information System s Interface This is a boundary across which external, persistent storage service is provided. Thi s interface allows exchange of data between an application system (or an enabling or supporting service that is either incorporated into an application system or provided directly to the user) and an information system (such as a database) which may be either remote or loc al. Application-to-Application Interface This is a boundary across which an application system communicates with another application system and possibly receives services. The application systems may be remote or local with respect to each other. If that service is provided directly to the user, this interface may occur between that service and an application or bet ween two services. Network-to-Network Interface A boundary across which two or more communication networks exchange information. The services provided enable connectivity to and from populations of information appliances and people that directly access other communications networks. This interface may be a boundary between two dissimilar underlying communications networks or d ata transport bitways created by different industries. It is anticipated that these networks or bit ways will be dissimilar, wit h the differenc es stemming from the fact that individual "bitways" were developed within different industries, such as the comput er industry, the telecommunications industry, entertainment industry, and the "wireless" communications industry. To enable int eroperability at these interfaces requires considering attributes for the interfaces, including format, protocol, basic transmission requirements, and others. Identifying attributes that are relevant to particular interfaces and giving these attributes values is the key to identifying standards needs and standards that fulfill those needs. 5. Use of the Framework by Standards Development Organizations The framework present ed in this document is intended for us e by standards development organizations (SDOs) to identify standards requirements together with existing standards that fulfill those requirements and "gaps" where standards development efforts will be needed. 5.1 Guidance in the Use of the Framework The use of the framework by SDOs rests on a set of key assumptions. These include: The applicability of the Framework to different arc hitectural views of the NII wit h no partic ular NII architecture being dominant. Maximum flexibility in the definition of the items along each axis, with specific items being defined according to the needs of individual SDOs. The applicability to particular SDOs of only a subset of the three dime nsional space with members of each SDO essentially defining its own space as they see fit. It is expected that SDOs will rely on many existing works that identify standards needs and existing standards that fulfill those needs. Sources , , , and  have been discussed above. Other valuable sources include , , , , , and . Based on these assumptions, a guideline for SDOs to use the framework may consist of the following: 1. Consider what application areas are relevant to the standards activity of the SDO. This has the effect of defining the Applications Area relevant to the particular S DO and its members. 2. Consider what services are relevant to the standards activity of the SDO. Either key enabling services or supporting services may be appropriate. It is up to the members of the SDO to select the type(s) of services as well as the individual services that are most relevant to their needs. This has the effect of defining the Services Axis. 3. Identify interfaces that will be rele vant and must be addressed to allow interoperability between the selected services and existing systems. This has the effect of identifying potential areas of standardization. 4. For each potential area of standardization, identify attributes that are releva nt. The attributes provided in section 2 are a start er set. Each SDO may develop its own customized set that is relevant to the use of servic es, applications, and interfaces identified in steps 1 and 2. The selection of attributes has the effect of identifying standards requirements. 5. Having identified standards requirements, identify existing standards that fulfill those requirements--if appropriat e, using sources identified above and listed in the References section. This includes both standards that alre ady exist as well as those for which standards development projects are ongoing. Where multiple standards exist, they may be listed, evaluated, and compared for usefulness. Dependencies must be identified between standards that fulfill requirements associated with different attributes. Where requirements are not matched by existing or developing standards, it may be necessary to consider additional standards development efforts. 6. Using results of steps 1 through 4, provide rec ommendations on new standards t o be developed. Such recommendations should take into consideration the necessity of developing traditional monolithic standards as well as alternative means of achieving the int eroperability intended by the standard. The recommendations made by the SDO should contain the information needed to catalog standards requirements and the standards that meet these requirements. This information will be placed in a Standards Development and Tracking System to be created and maintained by the IISP. The information to be maintained in the Tracking System will be defined by the IISP. 5.2 Issue s and Problems in the Use of the Framework This document would not be complete without some discussion of issues and potential problems that may arise in the use of the Framework doc ument by SDOs to identify standards needs and standards that fulfill those needs. Thes e include the following: Defining Terms of the Individual Axis The terms found along the axis in figures 1 and 2 are suggested terms, not standardized terms that must be adopted by SDOs utilizing the Framework. It is expected that SDOs will choose and/or creat e those terms relevant to the task at hand. Scaling the use of the Framework and the Potentially Large Number of Cells A cursory examination of Figure 1 raises the concern that there are a large number of potential "cells" representing areas where standards needs can be identified. This large number may make the use of the Framework seem like a daunting task. SDOs that employ the Framework are likely to focus on a small subset of possible "cells," thus greatly reducing the number of identified "cells." It is expected that the use of the Framework by multiple SDOs will result in the identification of a finite set of cells that lead to the identification of key standards needs. Correlation of Terms Across Di fferent Industries The use of the Framework by different SDOs who are associated with different industries will probably result in the use of disparate terminologies to identify standards needs and standards that fulfill those needs. This will include terms for application areas, services, interfaces, and attributes. Once identified standards needs begin to be provided it will be necessary to correlate terms across industries and identify synonyms. This will likely be a task that will be initiated by IISP committee members. Identification of Standards Not Directly Relevant to the NII Users of the Framework must ensure that the standards needs being focussed on are those that are most relevant to the NII. The number of new standards development projects that can be undertaken in support of the NII is limited by the available human res ourc es. Not all standards will have he same level of relevance. Interfaces Between Standards Identified in Different Cells It is possible that services associated with one cell in the three-dimensional space will be related to servic es associated with another cell. This leads to the question of whether or not specific interfaces need to be defined between particular cells --an undesirable development that points to a need for "stovepipes." The answer to this question, in part, depends on whet her or not the set of interfac es defined in section 4.3 (or suggested by SDOs using the Framework) is sufficiently generic to cover the interoperability needs of application systems or services. This set of issues is not complete. Subsequent use of the Framework will lead to the identification of a new issues and refinement of those discussed above. 6. References  Computer Systems Policy Project, Perspectives on the National Information Infrastructure: Ensuring Interoperability, February 1994.  Cross Industry Working Team, An Architectural Framework for the National Information Infrastructure, Reston, VA, August 1994.  International Organization for Standardization, ISO/ IEC JTC1 Draft Technical Report 10000-3 "Framework and Taxonomy of International Standards Profiles - Part 3: Principles and Taxonomy for Open Systems Environment Profiles," ISO/IEC SGFS  Farah, O. ed., N1249, March 1995. Framework for National Information Infrastructure S ervices , NIS T Internal Report 5478, National Institute of Standards and Technology, Gaithersburg, MD, July 1994.  Transmission Control Protocol, Request for Comments 793, DDN Network Information Center, SRI International, September 1981.  International Organization for Standardization/Joint Technical Committee 1, Open Systems Interconnection - Remote Database Access (RDA), Part 1: Generic Model and Part 2: SQL Specification, ANSI BSR X3.217-199x, Global Engineering Documents, Irvine, CA 92714, November 1991.  ANSI/NISO, Z39. 50-1992, Information Retrieval Application Service Definition and Prot ocol Specification for Open S ystems Interconnection, NISO Press, Gaithersburg, MD, 1992.  International Organization for Standardization, ISO 10303 Industrial Automation Systems and Integration -- Product Data Representation and E xchange -- Overview and Fundamental Principles, ISO TC184/SC4, 1992.  Electronic Data Interchange, FIPS PUB 161, National Institute of Standards and Technology.  Hypertext Mark up Language (HTML) Version 3.0, CE RN, URL= HTTP//:info.cern.ch/httpd_3.0, October 1994.  International Organization for Standardization, Database Language SQL, IS O/IE C 9075:1992, American National Standards Institute, ANSI X3. 135 -1992, New York, NY 10036, November 1992.  Information Infrastructure Task Force (IITF): Committee on Applications and Technology, Putting the Information Infrastructure to Work , NIS T Special Publication 868, National Institute of Standards and Technology, Gaithersburg, MD, September 1994.  Open System Environment Architectural Framework for NII Services and Standards; 5 August 1994, NIS T Draft.  "Information Technology Standards Guidance", DISA, Version 2. 0, September 30, 1994.  Object Services Architecture, Issue 6.0. Framingham, MA:Object Management Group (document # 92-8-4), Revised version to be published in late 1994.  Common Facilities Architecture, Draft 3.0, Framingham, MA: Object Management Group (document # 94-11-9). This doc ument is still under active revision.  Application Portability Profile - The Government 's Open System Environment Profile OSE/1 Version 2.0, NIS T Special Publication 500-210, National Institute of Standards and Technology, Gaithersburg, MD.  DoD Technical Arc hitecture Framework for Information Management, Vol. 2: "Technical Reference Model and Standards," DISA Center for Standards, Version 2. 0, June 30 1994.  DoD Technical Arc hitecture Framework for Information Management Vol. 7: "Adopted Information Technology Standards", DISA, Center for Standards, Version 2.0. Footnotes 1. These supporting hardware and software systems are known as information appliances in , and  and as application platforms in . 2. See Footnote 1.
Pages to are hidden for
"Framework for Identifying Requirements for Standards for the "Please download to view full document