Docstoc

Framework for Identifying Requirements for Standards for the

Document Sample
Framework for Identifying Requirements for Standards for the Powered By Docstoc
					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
[1], [2], [3], and [4]. 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) [5], Remot e Data Access (RDA) [6], and the Z39.50
        standard for retrieval of text information [7].

       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 [8], Electronic Data Interchange (EDI) [9], Hypertext Trans fer Protocol
        (HTTP ) [10], and SQL [11]. 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 [8] 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 [11].

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 [11] for content and format is closely associated with the use of Remot e Data Access [6] 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 [12]. 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 [1], XIWT [2], JTC1 OSE
[3], and NIS T Services Framework [4] 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 [1], [2], and [3], different types of interfaces are suggested for NII services. In addition, references [3]
and [13] 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)[1] 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)[2] 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 [1], [2], [3], and [4] have been discussed above. Other
valuable sources include [14], [15], [16], [17], [18], and [19].

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

[1] Computer Systems Policy Project, Perspectives on the National Information Infrastructure: Ensuring
Interoperability, February 1994.
[2] Cross Industry Working Team, An Architectural Framework for the National Information
Infrastructure, Reston, VA, August 1994.
[3] 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
[4] 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.
[5] Transmission Control Protocol, Request for Comments 793, DDN Network Information Center, SRI
International, September 1981.
[6] 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.
[7] ANSI/NISO, Z39. 50-1992, Information Retrieval Application Service Definition and Prot ocol
Specification for Open S ystems Interconnection, NISO Press, Gaithersburg, MD, 1992.
[8] 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.
[9] Electronic Data Interchange, FIPS PUB 161, National Institute of Standards and Technology.
[10] Hypertext Mark up Language (HTML) Version 3.0, CE RN, URL= HTTP//:info.cern.ch/httpd_3.0,
October 1994.
[11] 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.
[12] 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.
[13] Open System Environment Architectural Framework for NII Services and Standards; 5 August
1994, NIS T Draft.
[14] "Information Technology Standards Guidance", DISA, Version 2. 0, September 30, 1994.
[15] Object Services Architecture, Issue 6.0. Framingham, MA:Object Management Group (document #
92-8-4), Revised version to be published in late 1994.
[16] Common Facilities Architecture, Draft 3.0, Framingham, MA: Object Management Group
(document # 94-11-9). This doc ument is still under active revision.
[17] 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.
[18] 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.
[19] 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 [2], and [4] and as application platforms in [3].

2. See Footnote 1.