INFORMATION TECHNOLOGY STANDARDS GUIDANCE

(ITSG)

(Part 4 of 14 parts)

DATA MANAGEMENT SERVICES

 

 

 

 

 

 

 

 

Version 3.1 - April 7, 1997

 

 

AREA IPSC

DISTRIBUTION STATEMENT A: Approved for public release; distribution unlimited

TABLE OF CONTENTS

3.4 Data management services 3.4-

3.4.1 Data management system 3.4-

3.4.1.1 Basic database services 3.4-

3.4.1.2 Indexed sequential access 3.4-

3.4.1.3 Electronic forms 3.4-

3.4.1.4 Report writer 3.4-

3.4.1.5 Database administration 3.4-

3.4.1.6 Menu-driven database access 3.4-

3.4.1.7 Data storage and archiving 3.4-

3.4.1.8 Multidatabase Application Program Interfaces 3.4-

3.4.1.9 Models/Process/Workflow 3.4-

3.4.2 Data management security 3.4-

3.4.2.1 Database security 3.4-

3.4.2.2 System access control 3.4-

3.4.2.3 Data management security labeling 3.4-

3.4.2.4 Systems integrity 3.4-

3.4.2.5 Data integrity techniques 3.4-

3.4.3 Data dictionary/directory services 3.4-

3.4.3.1 Data dictionary 3.4-

3.4.3.2 Distributed directory services 3.4-

3.4.3.3 Universal syntax 3.4-

3.4.3.4 Data repository 3.4-

3.4.4 Distributed data 3.4-

3.4.4.1 Remote data access 3.4-

3.4.4.2 Database recovery 3.4-

3.4.4.3 Distributed database 3.4-

3.4.5 Object database 3.4-

3.4.5.1 Object-oriented database management 3.4-

3.4.6 Transaction processing 3.4-

3.4.6.1 Protocol for interoperability in heterogeneous transaction processing systems 3.4-

3.4.6.2 Transaction manager-to-resource manager interface 3.4-

3.4.6.3 Transaction manager-to-communications manager interface 3.4-

3.4.6.4 Application-to-communications resource manager interface 3.4-

3.4.6.5 Communications manager-to-protocol stack interface 3.4-

3.4.6.6 Transaction demarcation 3.4-

3.4.6.7 Transaction monitoring services and interfaces 3.4-

3.4.6.8 Terminal communications 3.4-

3.4.6.9 Transaction program scheduling 3.4-

3.4.6.10 Transaction message queuing 3.4-

3.4.6.11 Recovery and restart services for long running transactions 3.4-

3.4.6.12 Interface to resource manager device drivers 3.4-

3.4.6.13 Distributed queuing 3.4-

3.4.6.14 Modeling services 3.4-

LIST OF TABLES

3.4-1 Basic database services standards 3.4-

3.4-2 Indexed sequential access standards 3.4-

3.4-3 Electronic forms standards 3.4-

3.4-4 Report writer standards 3.4-

3.4-5 Database administration standards 3.4-

3.4-6 Menu-driven database access standards 3.4-

3.4-7 Data storage and archiving standards 3.4-

3.4-8 Multidatabase Application Program Interfaces standards 3.4-

3.4-9 Models/Process/Workflow standards 3.4-

3.4-10 Database security standards 3.4-

3.4-11 System access control standards 3.4-

3.4-12 Data management security labeling standards 3.4-

3.4-13 Systems integrity standards 3.4-

3.4-14 Data integrity techniques standards 3.4-

3.4-15 Data dictionary standards 3.4-

3.4-16 Distributed directory services standards 3.4-

3.4-17 Universal syntax standards 3.4-

3.4-18 Data repository standards 3.4-

3.4-19 Remote data access standards 3.4-

3.4-20 Database recovery standards 3.4-

3.4-21 Distributed database standards 3.4-

3.4-22 Object-oriented database management standards 3.4-

3.4-23 Protocol for interoperability in heterogeneous transaction processing systems

standards 3.4-

3.4-24 Transaction manager-to-resource manager interface standards 3.4-

3.4-25 Transaction manager-to-communications manager interface standards 3.4-

3.4-26 Application-to-communications resource manager interface standards 3.4-

3.4-27 Communications manager-to-protocol stack interface standards 3.4-

3.4-28 Transaction demarcation standards 3.4-

3.4-29 Transaction monitoring services and interfaces standards 3.4-

3.4-30 Terminal communications standards 3.4-

3.4-31 Transaction program scheduling standards 3.4-

3.4-32 Transaction message queuing standards 3.4-

3.4-33 Recovery and restart services for long running transactions standards 3.4-

3.4-34 Interface to resource manager device drivers standards 3.4-

3.4-35 Distributed queuing standards 3.4-

3.4-36 Modeling services standards 3.4-

3.4 Data management services. Data management service standards provide (1) data dictionary/directory services for accessing and modifying data about data (i.e., metadata), (2) the database management services for accessing and modifying structured data, and (3) the distributed data service for accessing and modifying data from a remote database.

NOTE: Throughout Part 4, all tables shall have abbreviations listed under the column (Standard Type) as follows:

a. National Public Consensus = NPC
b. International Public Consensus = IPC
c. Government Public Consensus = GPC
d. Consortia Public Consensus = CPC
e. Consortia Private Non-Consensus = CPN-C
f. National Public Non-Consensus = NPN-C

3.4.1 Data management system. These standards provide the basic database services needed by an application using a database. A Database Management System (DBMS) is an application used to create, store, retrieve, change, manipulate, sort, format, and print the information in a database.

3.4.1.1 Basic database services. Basic database services include data definition, manipulation, query, and integrity, embedded Structured Query Language (SQL), and dynamic facilities. Data definition includes create, alter, and delete tables, views, records, fields, classes, objects, instances, attributes, and data. Data manipulation includes insert, select, update, and delete tables, views, records, fields, classes, objects, instances, attributes, and data. Data query includes the ability to specify search conditions consisting of a combination of select lists, predicates, and comparison operators. Data integrity includes data locking (to some degree of granularity), consistency, transaction control (to specify commit and rollback commands and guarantee the ability to serialize database transactions), referential constraints (to help ensure data consistency), and synchronous writing of data. Embedded SQL consists of SQL statements embedded in a high-level language source program. In a separate compiling phase, the SQL may be optimized and converted into special function calls. Dynamic SQL is SQL interpreted by the SQL database at runtime. Dynamic SQL may be generated by programs or entered interactively by the user. Facilities embedded in application programs generate executable SQL statements during program execution so control of a database can be turned over temporarily to the end user for interactive access and manipulation of data.

3.4.1.1.1 Standards. Table 3.4-1 presents standards for basic database services.

TABLE 3.4-1 Basic database services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Database Language SQL (Adopts ANSI X3.135-1992 (same as ISO 9075:1992))

FIPS PUB 127-2:1993

Mandated

(Approved)

GPC

NIST

SQL Environments

FIPS PUB 193:1995

Informational

(Approved)

GPC

NIST

Guidelines for Functional Specifications for Database Management Systems

FIPS PUB 124:1986

Informational

(Approved)

CPC

X/Open

Embedded SQL (Cobol and C)

SQL Developers Specification

Informational

(Approved)

IPC

ISO

Database Language - Network (NDL)

8907:1987

Informational

(Approved)

GPC

NIST

Database Language - NDL (adopts ANSI X3.133-1986)

FIPS PUB 126:1987

Informational

(Approved)

NPC

ANSI

Database Language - (NDL)

X3.133-1986

Informational

(Approved)

CPC

X/Open

Data Management: Reference Model

G505 (10/95)

Informational

(Approved)

IPC

ISO/IEC

Database Language SQL3 (will replace SQL2)

9075

Emerging

(Draft)

GPC

NIST

SQL3-Based FIPS

FIPS PUB 127-3

Emerging

(Formative)

NPC

ANSI

Database Language SQL3 (will replace SQL2)

X3H2 Project 0525-R

Informational

(Draft)

CPC

X/Open

Structured Query Language (SQL)

C201 (9/92)

Informational

(Superseded)

3.4.1.1.2 Alternative specifications. The following alternative specifications are available:

a. For data definition, manipulation, query, data integrity, embedded SQL, and dynamic facilities standards: Integrated Database Application Programming Interface (IDAPI), a specification, published by Borland, IBM, Novell, and Word Perfect Corporation, will allow DOS, OS/2, and Windows applications to access a variety of SQL and non-SQL databases transparently.

b. No applicable consortia or de facto SQL integrity constraint specifications are available.

c. For X/Open SQL and the IBM Systems Application Architecture (SAA) SQL support Embedded C.

d. For dynamic facilities the only other available specifications are proprietary.

3.4.1.1.3 Standards deficiencies. The following deficiencies in the standards have been identified:

a. or data definition, manipulation, query, data integrity, embedded SQL, and dynamic facilities standards:

(1) No standardized way exists to specify logical database access control, which is important to database security.

(2) Hashing methods to access data are neither standardized nor in progress.

(3) SQL1 is inadequate and has failed to be transportable or standardized to be very useful. The upcoming SQL-3 provides an opportunity for DOD requirements to be inserted.

b. For data integrity standards, SQL Integrity Enhancement is a simple capability with no constructs to help programmers maintain data consistency.

c. For Embedded SQL standards, SQL2 supports Embedded SQL in C and Ada. However, products will not be available for some time. International Organization for Standardization (ISO)/American National Standards Institute (ANSI) Embedded SQL does not support the C programming language. The use of embedded SQL requires a precompiler for each language in which SQL is embedded.

d. For dynamic facilities standards, deficiencies in the existing formal standards are unknown.

e. For SQL environments, the emphasis in this first FIPS for SQL Environments is on profiles for limited SQL interfaces to non-SQL data repositories. Subsequent versions of this FIPS may specify more complete profiles for other products in an SQL environment. The profiles defined by this standard are not complete in and of themselves. The user is required to add information before this standard can be successfully used in a procurement.

3.4.1.1.4 Portability caveats. The following portability caveats apply:

a. For data definition, manipulation, query, data integrity, embedded SQL, and dynamic facilities standards,

(1) SQL 2's segmentation into multiple levels increases the likelihood of incompatibility between different vendors' SQLs, because different vendors will implement entry level SQL 2, then choose options from other levels.

(2) The ISO, ANSI, and Federal Information Processing Standard (FIPS) versions of SQL specify state exception code values (called SQLCODE parameters) such as 0 for successful execution, 100 for nonexistent data, and implementation defined code values for particular exception conditions. Different products that conform with SQL have different SQLCODE values for exception conditions. The set of SQL character values for the character data type and collating sequence of characters is defined by the implementor, and therefore, nonstandard in products.

b. For data integrity the following portability caveats apply:

(1) Most vendors' products contain extensions. To maximize portability, reduce the use of extensions as much as possible.

(2) Different vendors provide locking to different degrees of granularity. Portability and/or interoperability of applications result in locking to the largest degree of granularity.

c. For dynamic facilities the following portability caveat applies: Although the X/Open and SAA SQLs support dynamic SQL, X/Open SQL is an X/Open-enhanced specification of the 1986 version of Level 1 SQL, while SAA SQL is not fully ISO/ANSI SQL compatible, although it will be. Also, X/Open and SAA dynamic SQL facilities are not fully compatible with each other.

d. For SQL environments, conformance testing for products claiming conformance to one of the profiles specified by FIPS 193 will be achieved by a suitable modification of the existing NIST SQL test suite. This FIPS requires the customer to choose from among the different binding styles already defined by the SQL standards. Two of these styles (CLI and RDA) are expected to be more popular than the others. If a programming language binding style is chosen, then FIPS SQL specifies the parameter passing requirements for each of seven different programming languages.

 

3.4.1.1.5 Related standards. The following standards are related to basic database services or basic database service standards:

(1) ISO 9579-1: Remote Database Access (RDA) (Generic Model, Service and Protocol)(supports remote database access in client-server environments)

(2) ISO 9579-2: RDA: (SQL Specialization)

(3) SQL Access Group's (SAG's) SQL Access Formats and Protocols (FAP) (1991)

(4) SAG's Call Level Interface (CLI)

(5) X/Open RDA Preliminary Specification (Identical to the SAG's RDA Specification

(6) X/Open's CLI Snapshot Specification (Identical to the SAG's CLI Specification)

(7) Open Systems Interconnection (OSI) CCR (Commitment, Concurrency, and Recovery): ISO/International Electrotechnical Commission (IEC) 9804-3/9805-3

(8) OSI Distributed Transaction Processing (DTP) Protocol: ISO/IEC 10026 Parts 1, 2, and 3.

(9) ISO 1989:1985: COBOL

(10) ANSI X3.9-1978: FORTRAN-77

(11) ANSI X3.159-1989: C

(12) National Institute for Standards and Technology (NIST) FIPS 021-3: COBOL

(13) NIST FIPS 069-1: FORTRAN

(14) NIST FIPS 119, DOD MIL-STD 1815A:1983, ISO 8652: Ada

(15) NIST FIPS 160: C

(16) ISO/IEC Draft International Standard (DIS) 10032: Reference Model of Data Management

(17) ISO 12227 SQL/Ada Models Description Language, 1994

(18) X3 SQLIB-1 SQL Information Bulletin Number 1 Interpretation of ANSI X.3.135 - 1989

3.4.1.1.6 Recommendations. The following are related to data definition, manipulation, query, data integrity, embedded SQL, and dynamic facilities standards:

(1) Consult the wording suggested in the October 1991 General Services Agency (GSA) publication for proposed language for requiring that a database conform to SQL, and consult FIPS 127-2 for guidance on how to structure a Request for Proposal (RFP). The FIPS "flagger" (to flag nonconforming extensions) is optional and must be specified explicitly.

(2) If interactive SQL is required, a procurement must indicate explicitly whether or not "direct invocation of SQL statements" is required and, if required, which SQL statements are to be directly invocable. If not specified, the default is "CREATE TABLE," "CREATE VIEW," "GRANT privilege," "SELECT" with "ORDER BY" option, "INSERT," "UPDATE:searched," "DELETE:searched," "COMMIT WORK," and "ROLLBACK WORK."

(3) Explicitly specify sizing constraints for database constructs. The FIPS 127-2 sizing specifications are reasonable to expect vendors to deliver, but are fairly minimal. Since database construct sizing specifications depend on the procurement, a procurement can override them.

(4) Require the use of NIST conformance tests and/or services to validate conformance to the SQL-based FIPS for required and optional FIPS 127-2 features. Testing applies only to a specific platform, so call for conformance tests for each platform bid. Use the quarterly list of processors validated against FIPS 127-2 by NIST to help evaluate bids.

(5) Specify the NIST's Transition Level SQL 2 and the SAG's CLI and RDA interfaces and protocols for the following reasons. Most DBMS vendors have no intention of conforming to the Full Level SQL 2:1992 because it is very large and complex. As a result, the time it will take to add the necessary features will probably exceed the time before the SQL 3 standard is completed. To ensure portability as well as functionality, users are encouraged to include the following two specifications in their procurement:

(a) NIST's Transition Level SQL 2 (specified in FIPS 127-2), which is a hybrid of Entry Level and higher levels of SQL 2:1992.

(b) SAG's and X/Open's CLI and RDA standards. The SAG specifications are not segmented like SQL '92 and offer a nice balance between the Full Level SQL '92 feature set and what users need now. The SAG specifications include connection management capabilities (which are part of the SQL '93 Full Level), schema manipulation and the CHARACTER VARYING data type (both of which are part of SQL '93 Intermediate Level), and features not included in any level of SQL '92 conformance, including the CREATE INDEX and DROP INDEX statements. SAG's specifications are published jointly with X/Open as X/Open specifications.

(6) Specify SQL2 (and later SQL3) as soon as possible because SQL2/3 contains greater standardized functionality than SQL1. This will reduce the use of nonstandard extensions. SQL2 also standardizes more than 60 SQLCODE exception code values.

(7) Carefully specify and check all sizing constraints for a procurement to meet functionality requirements and avoid portability problems.

(8) Avoid the Network Data Language (NDL), if possible, because it is little used and will not be upgraded.

(9) Specify the ISO RDA standard, and also the X/Open or SAG's RDA and CLI specifications in conjunction with SQL/SQL2 to obtain remote data access capabilities in a distributed environment.

The Integrity Constraint feature is optional in SQL and must be specified explicitly for a procurement. Failure to do so means the Integrity Constraint feature is not required. Specify FIPS 127-2, especially if any of the services unique to FIPS 127-2 are needed.

In SQL2, the integrity enhancement feature is mandatory, not optional. Also, SQL2 has better integrity constraints, such as "cascade delete on referential integrity" (in the intermediate SQL Level) and "deferrable integrity constraints" (in full SQL2).

For embedded SQL:

(1) Specify embedded SQL in an RFP, although it is optional in the standard. Indicate which programming language is to be supported in references to embedded SQL in a procurement. Failure to do so means that support for any one FIPS language satisfies the FIPS SQL requirement. Indicate whether the language interface is to support the Module Language interface style, the embedded language interface style, or both. Failure to do so means that vendors supporting any one interface style satisfy the FIPS SQL requirement.

(2) Require the use of NIST conformance tests and/or services to validate conformance to every one of the embedded interfaces and module interfaces, and to validate the compilers that will be used with the embedded SQL because SQL testing is independent of the host programming language testing. Testing applies only to a specific platform, so call for conformance tests for each platform bid. Specify FIPS 127-2 if any of the services unique to FIPS 127-2 are needed.
Specify that the character data values and collating sequences coincide with the character values and collating sequence of the specific programming languages to be used. Failure to indicate specific character set requirements means that support for representation of the 95-character graphic subset of American Standard Code for Information Interchange (ASCII) (FIPS 1-2) in an implementor specified collating sequence defaults to the minimum requirement, and may not be portable across other procured systems.

For dynamic facilities, SQL2 is preferred. Dynamic SQL is an intermediate level SQL2 capability. Either SQL2's dynamic SQL facilities or the SQL2 intermediate level must be specified explicitly in a procurement.

For SQL Environments, the FIPS is applicable in any situation where it is desirable to integrate user productivity tools and heterogeneous data repositories into an SQL environment. It is particularly suitable for specifying limited SQL interfaces to legacy databases or to specialized data repositories such as geographic information systems, full-text document management systems, or object database management systems.

3.4.1.2 Indexed sequential access. The Indexed Sequential Access Method (ISAM) is a procedure for storing and retrieving data from a disk file. When the programmer designs the file format, a set of indices is created describing where the records of the file are located on the disk. This provides a quick method of retrieving the data and eliminates the need to read all data from the beginning to find the desired information. The indexes can be stored as part of the data file or in a separate index file. The sequential order will be the one most commonly used for batch processing and printing (e.g., account number, name).

3.4.1.2.1 Standards. Table 3.4-2 presents standards for indexed sequential access.

TABLE 3.4-2 Indexed sequential access standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Data Management, Issue 3

C215 (3/92)

Adopted

(Approved)

CPC

X/Open

Indexed Sequential Access Method (ISAM): Developers' Specification

D010 (8/90)

Adopted

(Approved)

3.4.1.2.2 Alternative specifications. Another specification option is Informix Software Inc.'s C-ISAM, on which X/Open's ISAM is based.

3.4.1.2.3 Standards deficiencies. The greatest deficiency in ISAM standards is the lack of any formal ISAM specifications or functionality.

3.4.1.2.4 Portability caveats. Consider the use of ISAM carefully as risks are involved in using an informal standard.

3.4.1.2.5 Related standards. The following standards are related to ISAM or ISAM standards:

a. ISO 9075: SQL
b. ISO 9579-1: RDA (Generic Model, Service and Protocol
c. ISO 9579-2: RDA (SQL Specialization)
d. ANSI X3.135-1992: SQL
e. NIST FIPS 127-2: SQL
f. NIST FIPS 193: SQL Environments

3.4.1.2.6 Recommendations. When specifying ISAM services, all ISAM systems offered as a result of a procurement's requirements should be integrated with the SQL database language set forth in FIPS PUB 127-2, and should implement all of the features specified elsewhere in this document. All ISAM systems offered as a result of a procurement's requirements should be integrated with ISO 9579-1: RDA (Generic Model, Service and Protocol). If SQL is used, it also should be integrated with ISO 9579-2: RDA (SQL Specialization). Carefully weigh the portability risks in specifying ISAM, because only consortia ISAM standards exist.

3.4.1.3 Electronic forms. (This BSA appears in part 3, User Interface, part 4, Data Management, and part 5, Data Interchange.) These standards specify the functional interface requirements, transfer of various fields and the interface between programming languages and form filling applications for use on a terminal display.

3.4.1.3.1 Standards. Table 3.4-3 presents standards for electronic forms.

TABLE 3.4-3 Electronic forms standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

DOD Standardized Electronic Forms Requirements

JIEO-E-2300

Adopted

(Approved)

IPC

ISO/IEC

Forms Interface Management System (FIMS)

11730:1994

Informational

(Approved)

GPC

NIST

Government Open System Interconnection Profile (GOSIP 2): Virtual Terminal Forms Class Profile

FIPS PUB 146-1:1991

Informational

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Emerging

(Approved)

CPC

X/Open

Single Unix Specification: X/Open Curses, Issue 4 (part of XPG4)

C437 (2/95)

Emerging

(Approved)

GPC

DOD

DOD Forms Management Program Procedures Manual

DOD 7750.7-M

Informational

(Approved)

CPN-C

Numerous vendors

Query by Forms

Query by Forms

Informational

(Approved)

IPC

ISO/IEC

OSI Virtual Terminal Basic Class Service, Amendment 2: Additional Functional Units (forms capability)

9040:1990 DAM 2

Informational

(Draft)

IPC

ISO/IEC

OSI Virtual Terminal (VT) Basic Class Protocol, Part 1, Amendment 2: Additional Functional Units (Forms Capability)

9041-1:1990 DAM 2

Informational

(Draft)

CPC

X/Open

Internationalized Terminal Interfaces (XCURSES), Issue 4

S422 (4/94)

Informational

(Superseded)

3.4.1.3.2 Alternative specifications. The Berkeley Software Distribution (BSD) 4.2/4.3 UUNIX Curses are also available.

3.4.1.3.3 Standards deficiencies. The X/Open Portability Guide 4 (XPG4) Curses is based on the System V Interface Definition (SVID) Issue 2 Curses version, which does not include the SVID's forms and menu libraries.

Forms Class Virtual Terminal has bindings in C only.

DOD has developed a specification for electronic forms (Joint Interoperability and Engineering Organization (JIEO)-E-2300). It defines the minimum operational requirements for electronic forms software and mandates an interchange file format based on Forms Interface Management System (FIMS).

3.4.1.3.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.4.1.3.5 Related standards. The Forms Class Virtual Terminal requires the Synchronous mode (S-mode) of operation and specifies simple delivery control. The following standards are related to forms query and management:

a. ISO 9075: SQL
b. ANSI X3.135-1992: SQL2
c. NIST FIPS 127-2: SQL
d. NIST FIPS 193: SQL Environments

3.4.1.3.6 Recommendations. The recommended standard is JIEO-E-2300. For User Interface, FIMS should be considered. For Data Management, make sure the forms management systems are compatible with FIPS 127-2 SQL. Database forms management systems should be integrated with the SQL database language and formats set forth in FIPS PUB 127-2.

3.4.1.4 Report writer. A report writer is an application that prints a report based on a description of the layout. As a stand-alone program or part of a DBMS, it retrieves selected records from a file and may sort them into a new sequence before printing. Once created, it is stored in a report file for future use.

Nonprocedural forms management includes forms creation, modification, and management, including screen painting. Procedural forms management includes forms creation, modification, and management, using procedural methods. A nonprocedural report writer includes nonprocedural formatted database report definition, modification, and management. A procedural report writer includes formatted database report definition, modification, and management using procedural techniques.

3.4.1.4.1 Standards. Table 3.4-4 presents report writer standards.

TABLE 3.4-4 Report writer standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.1.4.2 Alternative specifications. The only available specifications are proprietary, such as IBM's SAA RPG: Common Programming Interface: Database Reference (SC09-1286-01).

3.4.1.4.3 Standards deficiencies. The lack of procedural or nonprocedural capabilities for database report writing is the deficiency in open standards for report writers.

3.4.1.4.4 Portability caveats. This is a high portability risk area because no standards exist.

3.4.1.4.5 Related standards. The following standards are related to report writers or report writer standards:

a. ISO 9075: 1992 - Database Languages - SQL, Third Edition

b. ANSI X3.135-1992: SQL

c. NIST FIPS 127-2: SQL

d. NIST FIPS 193: SQL Environments

e. (see also Fourth Generation Language under Software Engineering Services)

3.4.1.4.6 Recommendations. All database report writing systems should be integrated with the SQL database language set forth in FIPS PUB 127-2 and the SQL Environments of FIPS 193. The lack of procedural or nonprocedural capabilities for database report writing is a deficiency in open database standards.

3.4.1.5 Database administration. (This BSA appears in part 4 and part 9.) Data administration is the process of the analysis, classification, and maintenance of an organization's data and data relationships. It includes the development of data models, data warehousing, and data dictionaries, which combined with transaction processing, are the raw materials for database design.

3.4.1.5.1 Standards. Table 3.4-5 presents standards for database administration.

TABLE 3.4-5 Database administration standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Data Element Standardization Procedures, January 1993

Manual 8320.1-M-1

Mandated

(Approved)

GPC

NIST

Guide to Data Entity Naming Conventions

NBS SP 500-149 of Oct. 1987

Informational

(Approved)

GPC

DOD

Defense Data Repository System

End User Manual ver. 2.0 of 10 August 1993

Informational

(Approved)

IPC

ISO/IEC

Specification and Standardization of Data Elements, Part 3: Basic Attributes of Data Elements

11179-3:1994

Informational

(Approved)

IPC

ISO/IEC

Specification and Standardization of Data Elements, Part 4: Rules and Guidelines for the Formulation of Data Definitions

11179-4:1995

Informational

(Approved)

IPC

ISO/IEC

Specification and Standardization of Data Elements, Part 5: Naming and Identification Principles for Data Elements

11179-5:1995

Informational

(Approved)

IPC

ISO/IEC

Specification and Standardization of Data Elements, Part 6: Registration of Data Elements

11179-6

Informational

(Draft)

GPC

DOD

DOD Data Administration

DODD 8320.1 of 9/26/1991

Informational

(Superseded)

3.4.1.5.2 Alternative specifications. The only other available specifications are proprietary database utilities.

3.4.1.5.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard.

3.4.1.5.4 Portability caveats. This is a high portability risk area because no standards exist.

3.4.1.5.5 Related standards. The following standards are related to database administration or database administration standards:

a. ISO 7498-4:1989: Management Framework

b. ISO 9075: SQL

c. ISO 9579-1: RDA (Generic Model, Service and Protocols)

d. ISO 9579-2: RDA (SQL Specialization)

e. ISO 9595:1991: CMIS.

f. ISO 9596-1:1991: CMIP.

g. ISO/IEC 9945-1: (IEEE P1003.1)

h. ISO 10164-1:1993: Object Management Function

i. ISO 10165-1:1991: SMI - Part 1 Management Information Model

j. ISO 10165-2:1991: SSMI - Part 2 DMI

k. ISO 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO)

l. ANSI X3.135-1992: SQL

m. ANSI X3.168-1989: Embedded SQL

n. NIST FIPS 127-2: Database Language SQL

o. NIST FIPS 146-1: Government Open Systems Interconnection Profile (GOSIP)

p. NIST FIPS 156: IIRDS

q. NIST FIPS 193: SQL Environments

3.4.1.5.6 Recommendations. DODD 8320.1 is recommended for data administration. Database administration systems should be compatible with and integrated with the SQL database language set forth in FIPS PUB 127-2. Furthermore, all database administration systems offered as a result of this procurement's requirements shall be integrated with ISO 9579-1 RDA (Generic Model, Service and Protocol), ISO 9579-2 Remote Database Access (SQL Specialization) of December 1993, and NIST FIPS PUB 193, SQL Environments.

3.4.1.6 Menu-driven database access. These standards provide access to a database through a menu-driven or form-filling interface.

3.4.1.6.1 Standards. Table 3.4-6 presents standards for menu-driven database access.

TABLE 3.4-6 Menu-driven database access standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

DOD Standardized Electronic Forms Requirements

JIEO-E-2300

Informational

(Approved)

IPC

ISO/IEC

Forms Interface Management System (FIMS)

11730:1994

Informational

(Approved)

3.4.1.6.2 Alternative specifications. The only other available specifications are proprietary.

3.4.1.6.3 Standards deficiencies. The FIMS is not specific to database management systems. Instead, it is a generic programming language for building generic forms. No menu-driven database access standard either exists or is emerging.

3.4.1.6.4 Portability caveats. When completed, FIMS will apply to many types of applications, and is related only generically to database forms and menus. Consequently, programs built using FIMS have a high probability of not being compatible with a particular database, or with interconnected databases.

3.4.1.6.5 Related standards. The only standard related to menu-driven database access or menu-driven database access standards is Open Software Foundation (OSF): Motif.

3.4.1.6.6 Recommendations. JIEO-E-2300 is recommended.

3.4.1.7 Data storage and archiving. Data storage and archiving services provide a database application with the facilities for temporary storage and long-term data archiving. Archiving files is a process in which the information contained in an active computer file is made ready for storing in a nonactive file, perhaps in off-line or near-line storage. Typically when files are archived, they are compressed to reduce their size. To restore the file to its original size requires a process known as unarchiving.

3.4.1.7.1 Standards. Table 3.4-7 presents standards for data storage and archiving.

TABLE 3.4-7 Data storage and archiving standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.1.7.2 Alternative specifications. The only available specifications are proprietary specifications and database utilities.

3.4.1.7.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard.

3.4.1.7.4 Tailoring guidance. No tailoring guidance is available because no standards exist.

3.4.1.7.5 Related standards. The following standards are related to data storage and archiving or data storage and archiving standards:

a. ISO 9595:1991: CMIS

b. ISO 9596:1991: CMIP

c. Forthcoming UNIX International specification for backup and archive

3.4.1.7.6 Recommendations. There are no standards to recommend.

3.4.1.8 Multidatabase Application Program Interfaces. Multidatabase Application Program Interface (APIs) specify the interaction among several heterogeneous databases.

3.4.1.8.1 Standards. Table 3.4-8 presents standards for multidatabase application program interfaces.

TABLE 3.4-8 Multidatabase Application Program Interfaces standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPN-C

Microsoft

Open Database Connectivity (ODBC) 2.0

ODBC

Mandated

(Approved)

CPN-C

Microsoft

Open Database Connectivity(ODBC) 3.0

ODBC

Emerging

(Draft)

CPN-C

Sun

Java Database Connectivity(JDBC)

JDBC

Informational

(Formative)

3.4.1.8.2 Alternative specifications. The only other available specifications are proprietary database utilities.

3.4.1.8.3 Standards deficiencies. Deficiencies in the standards are unknown.

3.4.1.8.4 Portability caveats. Portability caveats in the standards are unknown.

3.4.1.8.5 Related standards. All standards for a single database are related to multidatabase API standards.

3.4.1.8.6 Recommendations. ODBC is recommended for this Base Service Area.

3.4.1.9 Models/Process/Workflow. Information standards in this BSA address activity models, data models and workflow. The information requirements identified in the activity model is used as the basis for developing a fully attributed data model. The data model identifies the logical information requirements and metadata, which forms a basis for physical database schema and data elements. Workflow defines the functionality required to support interoperabilty between workflow products.

3.4.1.9.1 Standards. Table 3.4-9 presents standards for models/process/workflow.

TABLE 3.4-9 Models/Process/Workflow standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Integration Definition for Information Modeling (IDEF1X)

FIPS PUB 184

Mandated

(Approved)

GPC

NIST

Integration Definition for Function Modeling(IDEF0)

FIPS PUB 183

Mandated

(Approved)

CPC

WFMC

Interoperability Abstract Specification

WFMC-TC-1012:1996

Informational

(Approved)

NPC

IEEE

Conceptual Schema Modeling for Object Oriented

IDEF1X97

Informational

(Draft)

CPC

WFMC

Interface 5 Audit Specification

TC1015

Informational

(Draft)

CPC

WFMC

Application Program Interface

WFMC-TC-1009

Informational

(Draft)

3.4.1.9.2 Alternative specification. The only other available specifications are proprietary.

3.4.1.9.3 Standard deficiencies. Deficiencies in the standards are unknown.

3.4.1.9.4 Portability caveats. Portability problems with the standards are unknown.

3.4.1.9.5 Related standards. No related standards are known at this time.

3.4.1.9.6 Recommendations. The mandated specifications are recommended.

3.4.2 Data management security. Security for data management services encompasses access control mechanisms for data that is either stored or manipulated in a database management system. In addition to access control, labeling and integrity concerns must be addressed. Programs and data can be secured by issuing identification numbers and passwords to authorized users of a computer. Passwords can be checked in the DBMS software, where each user can be assigned an individual view (subschema) of the database. Although precautions can be taken to detect an unauthorized user, determining whether a valid user is performing unauthorized tasks is extremely difficult.

3.4.2.1 Database security. (This BSA appears in part 4, part 9, and part 10.) Database security standards provide protection for stored data from unauthorized access, modification, and denial of service.

3.4.2.1.1 Standards. Table 3.4-10 presents standards for database security.

TABLE 3.4-10 Database security standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Trusted Database Management System Interpretation of the Trusted Computer Systems Evaluation Criteria

NCSC-TG-021, Version 1: 1991

Mandated

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

GPC

NIST

Database Language SQL (Adopts ANSI X3.135-1992 (same as ISO 9075:1992))

FIPS PUB 127-2:1993

Informational

(Approved)

GPC

NIST

Information Resource Dictionary System (IRDS) (adopts ANSI X3.138-1988 and X3.138A-1991)

FIPS PUB 156:1989

Informational

(Approved)

NPC

ANSI

Database Language SQL

X3.135-1992

Informational

(Approved)

IPC

ISO

Database Language SQL (same as ANSI X3.135-1992)

9075:1992

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Framework

10027:1990

Informational

(Approved)

IPC

ISO/IEC

OSI Service Definition for the Commitment, Concurrency, and Recovery (CCR) Service Element

9804:1990

Informational

(Approved)

IPC

ISO/IEC

OSI Protocol Specification for the Commitment, Concurrency, and Recovery (CCR) Service Element

9805:1990

Informational

(Approved)

NPC

ANSI

Information Resource Dictionary System (IRDS)

X3.138-1988

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface Amendment 1: C Language Binding

10728 AMD 1:1994

Informational

(Draft)

3.4.2.1.2 Alternate specifications. No alternate specifications are known.

There are no alternative specifications.

3.4.2.1.3 Standards deficiencies. Deficiencies in the existing standard are unknown.

3.4.2.1.4 Portability caveats. Portability problems with the existing standards are unknown.

3.4.2.1.5 Related standards. DOD 5200.28-STD, 26 December 1995, DOD Trusted Computer Systems Evaluation Criteria, is related to NCSC-TG-021. The following specifications are related to DOD 5200.28-STD:

a. NCSC-TG-018, Version 1, July 1992, A Guide to Understanding Object Reuse in Trusted Systems

b. NCSC-TG-025, Version 2, September 1991, A Guide to Understanding Data Remnants in Automated Information Systems

3.4.2.1.6 Recommendations. The mandated standard is recommended.

3.4.2.2 System access control. (This BSA appears in part 4, part 9, part 10, and part 11.) System access control standards provide high-level guidance on access control frameworks and implementation.

3.4.2.2.1 Standards. Table 3.4-11 presents standards for system access control.

TABLE 3.4-11 System access control standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

IPC

ISO/IEC

OSI Common Management Information Services (CMIS) Definition, with Amendment 4: Access Control

9595:1991/ AM4:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 9: Objects and Attributes for Access Control

10164-9:1995

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

IPC

ISO/IEC

OSI Security Frameworks in Open Systems, Part 3: Access Control

10181-3

Informational

(Draft)

3.4.2.2.2 Alternate specifications. No alternate specifications are known.

There are no alternative specifications.

3.4.2.2.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.4.2.2.4 Portability caveats. Portability problems with the existing standards are unknown.

3.4.2.2.5 Related standards. The following guidelines support the TCSEC standard:

a. NCSC-TG-003, Version 1, September 1987, A Guide to Understanding Discretionary Access Control in Trusted Systems

b. NCSC-TG-028, Version 1, May 1992, Assessing Controlled Access Protection

c. NCSC-TG-020-A, August 1989, Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX System

3.4.2.2.6 Recommendations. The mandated standards are recommended.

3.4.2.3 Data management security labeling. (This BSA appears in part 4 and part 10.) Data management security labeling provides a security service for ensuring that data includes labeling information in support of mandatory access control security services, marking security services, handling security services, aggregation security services, sanitization security services, and release security services. Security labeling services produce and maintain the integrity of the security label and its binding to the data with which it is associated.

3.4.2.3.1 Standards. Table 3.4-12 presents standards for data management security labeling.

TABLE 3.4-12 Data management security labeling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

DOD

CMW Labeling: Encoding Format

DDS-2600-6216-91

Informational

(Approved)

GPC

DOD

CMW Labeling: Source Code and User Interface Guidelines, Revision 1

DDS-2600-6243-91

Informational

(Approved)

GPC

DOD

Compartmented Mode Workstation (CMW) Evaluation Criteria

DDS-2600-6243-92

Informational

(Approved)

3.4.2.3.2 Alternate specifications. There are no alternative standards.

3.4.2.3.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.4.2.3.4 Portability caveats. Portability problems with the existing standards are unknown.

3.4.2.3.5 Related standards. Data management security labeling should be compatible with MIL-STD-2045-48501, Common Security Label, for any system with a communications interface.

DOD 5200.1-R, "Information Security Program Regulation," June 1986, establishes DOD policy for security classification, declassification, and marking of DOD information. It also contains DOD policy for safeguarding of classified information, including accountability, storage, transmission, and destruction of the information.

3.4.2.3.6 Recommendations. The mandated standard is recommended. Data management security labeling should be based of the operating system security label standards. Data management security labeling should employ binding of strength equal to or greater than that of the operating system. Compatible security labeling standards include the ability to perform a one-for-one mapping or translation between security labeling standards.

3.4.2.4 Systems integrity. (This BSA appears in part 4 and part 10.) Systems integrity objectives ensure the integrity of information and resources by providing a level of protection in response to the threats of unauthorized modification, manipulation, and destruction which is commensurate with the importance and priority of the content. These standards provide the high-level framework with which to view the security service of integrity in open systems.

3.4.2.4.1 Standards. Table 3.4-13 presents standards for system integrity.

TABLE 3.4-13 Systems integrity standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

DOD

Trusted Database Management System Interpretation of the Trusted Computer Systems Evaluation Criteria

NCSC-TG-021, Version 1: 1991

Mandated

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

IPC

ISO/IEC

OSI Security Frameworks in Open Systems, Part 6: Integrity (same as ITU-TS X.815)

10181-6

Informational

(Draft)

IPC

ITU-T

Security Frameworks in Open Systems: Integrity Framework (same as ISO 10181-6)

X.815: 1993

Informational

(Draft)

3.4.2.4.2 Alternate specifications. No alternate specifications are known.

There are no alternative specifications.

3.4.2.4.3 Standards deficiencies. Deficiencies in the existing standard are unknown.

3.4.2.4.4 Portability caveats. Portability problems with the existing standards are unknown.

3.4.2.4.5 Related standards. The following NSA documents supplement the information on integrity found in the TCSEC:

a. C Technical Report 79-91, September 1991, "Integrity in Automated Information Systems:

b. C Technical Report 111-91, October 1991, "Integrity-Oriented Control Objectives: Proposed Revisions to the Trusted Computer System Evaluation (TCSEC), DOD 5200.28-STD."

3.4.2.4.6 Recommendations. The mandated standards are recommended.

3.4.2.5 Data integrity techniques. (This BSA appears in part 4 and part 10.) Data integrity techniques provide services that allow data integrity between communicating applications to be confirmed by means of a cryptographic check function using a block cipher algorithm, by electronic signature, electronic hashing, and encryption.

3.4.2.5.1 Standards. Table 3.4-14 presents standards for data integrity techniques.

TABLE 3.4-14 Data integrity techniques standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Secure Hash Standard (SHS)

FIPS PUB 180-1:1995

Mandated

(Approved)

GPC

NIST

Digital Signature Standard (DSS)

FIPS PUB 186:1994

Mandated

(Approved)

IPC

ISO

Data Cryptographic Techniques - Data Integrity Mechanism Using a Cryptographic Check Function Employing a Block Cipher Algorithm

9797:1989

Informational

(Approved)

CPC

IETF

IP Authentication Header (AH)

RFC 1826: 1995

Emerging

(Draft)

CPC

IETF

IP Encapsulating Security Payload (ESP)

RFC 1827: 1995

Emerging

(Draft)

CPC

IETF

Domain Name System (DNS) Security Extensions

RFC 2065:1997

Emerging

(Draft)

GPC

NIST

Secure Hash Standard (SHS)

FIPS PUB 180:1993

Informational

(Superseded)

3.4.2.5.2 Alternate specifications. Alternative de facto specifications include RSA and MD-5.

3.4.2.5.3 Standards deficiencies. Deficiencies in the existing specifications are unknown.

3.4.2.5.4 Portability caveats. Portability problems with the existing specifications are unknown.

3.4.2.5.5 Related standards. There are no related standards.

3.4.2.5.6 Recommendations. The mandated standards are recommended.

FIPS PUB 180-1, which supersedes FIPS PUB 180, specifies a Secure Hash Algorithm (SHA-1) which can be used to generate a message digest. The SHA-1 is required for use with the Digital Signature Algorithm (DSA) as specified in FIPS PUB 186 and whenever an SHA is required in federal applications.

3.4.3 Data dictionary/directory services. Data dictionary/directory services are key computer software tools that manage data and information resources. Such services provide extensive facilities for recording, storing, and processing descriptions of an organization's significant data and data processing resources, and often provide facilities to use metadata (information about data).

3.4.3.1 Data dictionary. (This BSA appears in part 4 and part 9.) A data dictionary is a part of a database management system that transparently provides a centralized meaning, relationship to other data, origin, usage, and format. It also indicates which application programs use that data, so that when a change in a data structure is contemplated, a list of affected programs can be generated. The data dictionary a stand-alone system or may be an integral part of the DBMS and used to control it. Data integrity and accuracy is better ensured in the latter case.

3.4.3.1.1 Standards. Table 3.4-15 presents data dictionary standards.

TABLE 3.4-15 Data dictionary standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Information Resource Dictionary System (IRDS) (adopts ANSI X3.138-1988 and X3.138A-1991)

FIPS PUB 156:1989

Adopted

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Framework

10027:1990

Informational

(Approved)

GPC

NIST

Guide for the Development, Implementation, and Maintenance of Standards for the Representation of Computer Processed Data Elements

FIPS PUB 45:1976

Informational

(Approved)

GPC

NIST

Guidelines for Planning and Using a Data Dictionary System

FIPS PUB 76:1980

Informational

(Approved)

NPC

ANSI

Information Resource Dictionary System (IRDS)

X3.138-1988

Informational

(Approved)

NPC

ANSI

Information Resource Dictionary System (IRDS) Services Interface

X3.185-1992

Informational

(Approved)

NPC

ANSI

Information Resource Dictionary System (IRDS) Export/Import File Format

X3.195-1991

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface

10728:1993

Informational

(Approved)

CPC

Metadata Coalition

Metadata Interchange Specification (MDIS)

MDIS 1.0:1996

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface Amendment 1: C Language Binding

10728 AMD 1:1994

Informational

(Draft)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Export/Import Support for SQL:1989 with Integrity Enhancement

JTC1/SC21/WG03 Nxxx

Informational

(Formative)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Design Support for SQL Applications

JTC1/SC21/WG03 Nxxx

Informational

(Draft)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface Amendment 2: Ada bindings (binding for Ada-83)

10728 WDAM 2:1993(E)

Informational

(Draft)

3.4.3.1.2 Alternative specifications. No applicable consortia or de facto specifications for the data dictionary are available.

3.4.3.1.3 Standards deficiencies. The following deficiencies have been identified in the available standards:

a. APIs with the IRDS are not currently defined.

b. There are no IRDS bindings to Ada.

c. IRDS does not support the development of active functionality.

d. IRDS does not support object-oriented data structures. An upcoming major IRDS revision is expected to add support for object-oriented data structures and communications between data management tools. Computer Aided Software Engineering (CASE) tool proponents are lobbying for this revision.

e. IRDS does not support information communications among data management tools.

f. IRDS conformance tests do not exist, although they are being developed.

g. While DOD 8320.1-M-1 Data Element Standardization Procedures, January 1993, provides procedures for the approval and maintenance of data elements. The standard governing the design, definition, and naming rules for data elements comes from Integration Definition for Information Modeling (IDEF1X), Corporate Information Management Process Improvement Methodology for DOD Functional Managers (1992). This has been adopted as FIPS 184.

h. There are no implementations.

3.4.3.1.4 Portability caveats. The ANSI and ISO services interface standards have diverged and are not compatible. All attempts to converge these standards have failed because the ANSI and ISO IRDS specifiers have different data dictionary interests. As a result, the ISO model is geared toward developing an underlying interface between the dictionary and the DBMS. U.S. Federal agencies, the NIST, and ANSI focus on user interfaces.

One example of how ANSI and ISO IRDS diverge is concerned with whether or not relationships are permitted to have attributes. ISO says no, on the grounds that its simpler model, without attributes, is more easily integrated with SQL tables. ANSI says yes, claiming that even though a model permitting attributes is more complex and difficult to use, it provides greater flexibility for more IRDS users. People using IRDS for system planning processes, for example, might need to store certain items in the dictionary that would not necessarily be applicable for interfacing with DBMSs.

3.4.3.1.5 Related standards. The following standards are related to data dictionaries or data dictionary standards:

a. International Telecommunications Union - Telecommunications Standards Sector (ITU-T) (formerly International Telegraph and Telephone Consultative Committee (CCITT))/ISO X.500: Directory Services

b. Standard Textual Language (STL): IEEE 1175 (particularly for use with CASE tools)

c. Many CASE tools, because the IRDS acts as a focus for sharing data and metadata and can be applied to them.

d. NIST FIPS 183: IDEF0

e. NIST FIPS 184: IDEF1X

f. Data element standards in the data dictionary BSA, above.

3.4.3.1.6 Recommendations. IRDS, FIPS 156, is recommended. Most computer vendors claim that they are committed to IRDS, but few have it now. If specific IRDS documents are not specified explicitly in a procurement, vendors most likely will propose products that are not compatible with IRDS.

If a procurement is targeted at a traditional database environment and a simpler-to-use IRDS is desirable, consider the ISO specification. If other environments are at stake and attributes on relationships, or many-to-many relationships are needed to represent the relationships between hardware and programs, as well as between programs and data, then choose FIPS 156 IRDS and use ANSI IRDS wherever FIPS 156 has not specified certain capabilities. Whether the choice is for ISO, ANSI, or FIPS IRDS, be prepared to lock yourself in for other procurement, rather than mixing ISO and ANSI IRDS because of the incompatibilities.

3.4.3.2 Distributed directory services. (This BSA appears in part 4, part 9, and part 11.) A directory or naming service provides a standardized naming scheme, a standardized interface with the naming facilities, and the ability for the interface to provide transparent access to a variety of naming schemes and mechanisms (e.g., DCE).

Directory service applications convert a name into a physical address on a network, providing logical to physical conversion. Names can be user names, computers, printers, servers, or files. This enables users to find these resources without knowing their locations. The transmitting station sends a name to the server containing the naming service software, which sends back the actual address of the user or resource.

3.4.3.2.1 Standard. Table 3.4-16 presents standards for distributed directory services.

TABLE 3.4-16 Distributed directory services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Directory (Global and Cell) Service

DCE 1.1 Directory:1994

Mandated

(Approved)

IPC

ISO

Open Systems Interconnection-Session Service Definition

8326:1987

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Session Protocol

8327:1987

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Basic Connection Oriented Presentation Service Definition

8822:1988

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Presentation Protocol

8823:1988

Informational

(Approved)

IPC

ITU-T

The Directory: Models (X-ref: ISO 9594-2)

X.501 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Authentication Framework (X-ref: ISO 9594-8)

X.509, Version 3: 1993

Informational

(Approved)

IPC

ITU-T

The Directory: Abstract Service Definition (X-ref: ISO 9594-3)

X.511 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Procedures for Distributed Operation (X-ref: ISO 9594-4)

X.518: 1993

Informational

(Approved)

IPC

ITU-T

The Directory: Protocol Specification (X-ref: ISO 9594-5)

X.519 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Selected Attributes Types (X-ref: ISO 9594-6)

X.520 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Selected Object Classes (X-ref: ISO 9594-7)

X.521 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Replication (X-ref: ISO 9594-9)

X.525 (1993)

Informational

(Approved)

CPC

X/Open

Federated Naming: The XFN Specification

C403 (7/95)

Informational

(Approved)

NPC

IEEE

Directory services/Name space API

1224.2:1993

Informational

(Approved)

GPC

DOD

Domain Name Service Profile (References IAB STD 13 (RFC 1034, 1035))

MIL-STD-2045-17505:1994

Informational

(Approved)

3.4.3.2.2 Alternative specification. There are no alternative specifications available.

3.4.3.2.3 Standard deficiencies. Deficiencies in the existing specifications are unknown.

3.4.3.2.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.4.3.2.5 Related standards. There are no related standards.

3.4.3.2.6 Recommendations. OSF DCE directory services are recommended for DCE applications. For more information on non-DCE directory services, see the Host Application Support BSA in part 7, Communication Services.

3.4.3.3 Universal syntax. With the creation of a DOD Data Element Dictionary, an opportunity exists to create a universal syntax for the exchange of those data elements. This syntax will address the entire set of DOD information exchange requirements without regard to its current form. It would meld such diverse formatting approaches as the Tactical Digital Information Link (TADIL), United States Message Text Format (USMTF), and Electronic Document Interchange (EDI).

3.4.3.3.1 Standards. Table 3.4-17 presents universal syntax standards.

TABLE 3.4-17 Universal syntax standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.3.3.2 Alternative specifications. No other consortia or de facto specifications are available.

3.4.3.3.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard.

3.4.3.3.4 Portability caveats. This is a high portability risk area because no standards exist.

3.4.3.3.5 Related standards. No standards are related to universal syntax standards.

3.4.3.3.6 Recommendations. There are no standards to recommend.

3.4.3.4 Data repository. A repository provides a place and method to store metadata. It generally is broader and supports more kinds of data than a data dictionary.

3.4.3.4.1 Standards. Table 3.4-18 presents data repository standards.

TABLE 3.4-18 Data repository standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC/IPC

ANSI/ISO

Information Resources Dictionary System 2 (IRDS2) (Repository standard revision will include an interface with CASE tools)

JTC1/21.06.04,5; ANSI X3H4 Project 0754-D (or DT?)

Informational

(Formative)

CPC

Various

Various groups of contractors working in cooperation with the US Navy and Air Force

ProSLCSE, STARS

Informational

(Formative)

3.4.3.4.2 Alternative specifications. The only other available specifications are proprietary.

3.4.3.4.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard.

3.4.3.4.4 Portability caveats. The following portability problems have been identified:

a. There is a substantial overlap, and possible conflict, between the Portable Common Tool Environment (PCTE) and the ISO 10728 (IRDS) for data dictionary interfaces.

b. There is a high portability risk associated with repositories because no standards exist.

3.4.3.4.5 Related standards. The following standards are related to data repositories or data repository standards:

a. ISO 10027:1990: IRDS Framework. Current IRDS standards are covered only in the data dictionary sections because they are limited in their ability to handle metadata. However, IRDS work is underway to change the IRDS standards into a full fledged repository that can handle a variety of types of metadata.

b. ANSI X3.138-1988: IRDS Command Language and Panel Interface

c. ANSI X3.195-1991: IRDS Export/Import File Format

d. ANSI X3.185-1992: IRDS Services Interface

e. NIST FIPS 156: IRDS Base Document: Requirements, and Command Language and Panel Interface

f. ISO Draft Proposed (DP) 8800-1: IRDS Command Language and Panel Interface

g. ISO DIS 10728-X: IRDS Services Interface Module for C Language Binding

h. All the SQL standards (e.g., ISO 9075:1992 SQL; ANSI X3.135-1989 SQL; ANSI X3.168-1989: Embedded SQL; FIPS 127-2; FIPS 193)

i. Emerging standards for PCTE

j. Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) specification

3.4.3.4.6 Recommendations. There are no standards to recommend.

3.4.4 Distributed data. These services support applications that use a partitioned database acting like a single coherent database.

3.4.4.1 Remote data access. (This BSA appears in part 4 and part 11.) RDA specifications are extensions of a data access (RDA) language to allow remote access to a database in a client-server environment. RDA refers to the interfaces, protocols, and formats needed to allow remote database access in a client-server environment, where the databases may be heterogeneous and from multiple vendors.

3.4.4.1.1 Standards. Table 3.4-19 presents standards for remote data access.

TABLE 3.4-19 Remote data access standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

OSI Remote Database Access (RDA), Part 1: Generic Model, Service and Protocol

9579-1:1993

Adopted

(Approved)

IPC

ISO/IEC

OSI Remote Database Access, Part 2: SQL Specialization

9579-2:1993

Adopted

(Approved)

CPC

X/Open

Data Management: SQL Remote Database Access

C307 (8/93)

Informational

(Approved)

CPC

X/Open

Data Management: SQL Call Level Interface (CLI)

C451 (4/95) (Supersedes P303)

Informational

(Approved)

CPC

SAG

Database Language SQL, Access Formats & Protocols (FAP) Specification:1991 (Based on SQL)

SQL Access FAP Specs:1991

Informational

(Approved)

CPC

SAG

Database Language SQL Call Level Interface (CLI)

SQL-89

Informational

(Approved)

3.4.4.1.2 Alternative specifications. The only other available specifications are proprietary.

3.4.4.1.3 Standards deficiencies. RDA specifies the service and protocol between only a single client and server. This is one reason that caused the formation of the SAG to put more distributed functionality into RDA. RDA does not consider multiple connections and, therefore, does not specify distributed database access. APIs and Ada bindings to the RDA standards are not defined.

RDA is aligned closely with the SQL-2 Entry Level. However, the integrity enhancement is optional. Also, RDA is not aligned currently with the FIPS 127-2 Transition Level, which the NIST considers very important for SQL use.

The ISO RDA and CLI are only a subset of the SAG's RDA and CLI.

3.4.4.1.4 Portability caveats. RDA's use of ISO Remote Operations Service Elements (ROSE) hinders precision, adds needlessly to the text and Abstract Syntax Notation (ASN).1, and incorporates assumptions that limit the usefulness of RDA. Furthermore, an implementation conforming to ISO 9545 (the OSI standard that refines the basic OSI Reference Model to provide a framework for coordinating the development of existing and future application layer standards) could not use ROSE, since they both claim to be application service elements.

RDA's optional integrity enhancement and the lack of alignment with the FIPS 127-2 Transition Level can result in differences among systems compliant with RDA that impede portability and interoperability.

3.4.4.1.5 Related standards. The following standards are related to remote data access or remote data access standards:

a. ISO 9072: ROSE
b. ISO 9075:1992: SQL Third Edition (same as NIST FIPS PUB 127-2:1993)
c. ISO 10026-1..3: Distributed Transaction Processing Model, Service, & Protocol
d. ANSI X3.135-1989: SQL
e. ANSI X3.168-1989: Embedded SQL
f. X/Open C193: Distributed TP: The XA Specification

3.4.4.1.6 Recommendations. The first choice for a standard would be RDA, ISO 9579, and RDA: SQL Specialization, ISO 9579-2, unless the additional functionalities provided by the SAG are needed.

Where RDA lacks desired capabilities for a procurement, consider SQL Access Formats and Protocols Specifications or the X/Open RDA. The SAG and X/Open are tracking the RDA standard and both support RDA extensions that are being adopted by the emerging RDA standard. Consider the X/Open specified ASN.1 replacement module that eliminates the use of ROSE.

3.4.4.2 Database recovery. (This BSA appears in both part 4 and part 9.) Database recovery refers to the ability to detect a failure in a system, recover from failure, and permit a slave copy to become a master copy, assuring data integrity and consistency.

3.4.4.2.1 Standards. Table 3.4-20 presents standards for database recovery.

TABLE 3.4-20 Database recovery standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

OSI Service Definition for the Commitment, Concurrency, and Recovery (CCR) Service Element

9804:1990

Informational

(Approved)

IPC

ISO/IEC

OSI Protocol Specification for the Commitment, Concurrency, and Recovery (CCR) Service Element

9805:1990

Informational

(Approved)

3.4.4.2.2 Alternative specifications. No other consortia or de facto specifications are available.

3.4.4.2.3 Standards deficiencies. Deficiencies in database recovery standards are unknown.

3.4.4.2.4 Portability caveats. At present, CCR is not widely implemented, although most vendors intend to implement it. Therefore, one should make no assumptions about the degree of portability and interoperability existing for any database recovery utilities.

3.4.4.2.5 Related standards. The following standards are related to database recovery or database recovery standards:

a. ISO/IEC 10026 Parts 1, 2, and 3: Distributed Transaction Processing (DTP) protocol

b. X/Open XA Interface specification, which includes CCR's two-phase commitment

3.4.4.2.6 Recommendations. If CCR is desired (and it is necessary for multivendor, distributed database and distributed transaction processing), it must be referenced specifically in procurement specifications. Otherwise, vendors probably will propose products that do not meet this specification.

For the greatest portability, design applications as if CCR were not present.

3.4.4.3 Distributed database. Distributed database services allow partitioning (including physical partitioning) and, possibly, partial replication of a database so that the partitioned database, which is distributed at different sites, still behaves like a single, coherent database. If redundant data are stored in separate databases to meet performance requirements, updates to one set of data will update the additional sets automatically in a timely and controlled manner. A Client-Server Data Management Model for Distributed Processing, such as the Distributed Computing Environment (DCE), also is required.

3.4.4.3.1 Standards. Table 3.4-21 presents standards for distributed databases.

TABLE 3.4-21 Distributed database standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

OSI Remote Database Access (RDA): Some distributed database capabilities in future RDA revisions

9579 (future)

Informational

(Formative)

NPC/IPC

ANSI/ISO

Information Resources Dictionary System 2 (IRDS2) (Repository standard revision will include an interface with CASE tools)

JTC1/21.06.04,5; ANSI X3H4 Project 0754-D (or DT?)

Informational

(Formative)

3.4.4.3.2 Alternative specifications. The only other available specifications are proprietary.

3.4.4.3.3 Standards deficiencies. No standards exist to ensure data integrity across data residing at multiple locations. The term distributed databases does not have a standard definition. Databases ranging from traditional databases that are accessed from distributed locations to databases that support distributed query and distributed query and update, are called distributed databases.

3.4.4.3.4 Portability caveats. Vendors' SQLs are not exactly the same. Distributing such not-quite-the-same databases can cause portability problems. If the meaning and identity of the data administered at different sites and on different systems are different, users will lose portability. Worse, they will receive wrong answers to their queries and will not be able to recognize that the answers are wrong.

3.4.4.3.5 Related standards. The following standards are related to distributed databases or distributed database standards:

a. ISO 9075:1992: SQL Third Edition (same as NIST FIPS PUB 127-2:1993)

b. ISO 9804/9805: CCR

c. ISO 10026-1,2,3: Distributed Transaction Processing Model, Service, and Protocol

d. X/Open C193 (1992): Distributed TP: The XA Specification

3.4.4.3.6 Recommendations. There are no standards to recommend. Distributed database products must support ISO 9804/9805 CCR (for the two-phase commit specification).

3.4.5 Object database. An object-oriented database is one that holds abstract data types (objects). It can store objects directly from an object-oriented programming language. Because any type of data can be stored (the rules for processing the data are part of an object), the object database promises fully integrated databases that will hold data, text, pictures and voice, essentially an endless variety of ever-changing formats. It is capable of handling complex queries about objects that would be difficult in relational database programs.

3.4.5.1 Object-oriented database management. (This BSA appears in both Part 4 and Part 9.) Standards for object-oriented database management provide facilities and interfaces to manage object databases (databases that store, manipulate, and retrieve data represented as objects).

3.4.5.1.1 Standards. Table 3.4-22 presents standards for object-oriented database management.

TABLE 3.4-22 Object-oriented database management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

ODMG

Object Database Management Group (ODMG) - 93

ODMG-93, Release 1.1

Informational

(Approved)

CPC

ODMG

Object Database Management Group (ODMG) 9x

ODMG-9x

Emerging

(Formative)

NPC

ANSI

X3 Database System Study Group (DBSSG)

X3 Study

Informational

(Formative)

CPC

OMG

Preliminary work on object-oriented database management

TBD-Preliminary work on object-oriented database management

Informational

(Formative)

3.4.5.1.2 Alternative specifications. Microsoft's Object Database Connectivity (OBDC) API specification for MS-Windows applications is also available.

3.4.5.1.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard, but the Microsoft specification has insufficient drivers available.

3.4.5.1.4 Portability caveats. This is a high portability risk area because no standards exist, and many Microsoft PC products do not comply with most Unix- and Portable Operating System Interfaces for Computers (POSIX)-based systems.

3.4.5.1.5 Related standards. No standards are related to object-oriented database management standards.

3.4.5.1.6 Recommendations. There is no recommendation at this time.

3.4.6 Transaction processing. Orders, purchases, changes, additions, and deletions are examples of transactions recorded in a business information environment. Queries and other requests are also transactions to the computer, but usually are just acted upon and not recorded in the system. A transaction is a completed event that can be assembled in chronological sequence for an audit trail. Transaction processing systems, also called on-line or real time systems, update master files as soon as they are entered at terminals or arrive over communications lines. Contrast this with batch processing, which stores transactions and updates the necessary files at a later date.

3.4.6.1 Protocol for interoperability in heterogeneous transaction processing systems. These specifications support Transaction Processing (TP) systems containing components from diverse sources and between dissimilar transaction processing systems.

3.4.6.1.1 Standards. Table 3.4-23 presents standards for protocols for interoperability in heterogeneous transaction processing systems.

TABLE 3.4-23 Protocol for interoperability in heterogeneous transaction processing systems standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP) - Part 1: OSI TP Model

10026-1:1992

Adopted

(Approved)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP) - Part 2: OSI TP Service

10026-2:1996

Adopted

(Approved)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP) - Part 3: Protocol Specification

10026-3:1996

Adopted

(Approved)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP), Part 4: Protocol Implementation Conformance Statement (PICS) Proforma

10026-4:1995

Informational

(Approved)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP), Part 6: Unstructured Data Transfer

10026-6:1995

Informational

(Approved)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP), Part 5: Application Context Proforma and Guidelines When Using OSI TP

10026-5

Informational

(Draft)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP), Part 7: Message Queueing

10026-7

Informational

(Draft)

3.4.6.1.2 Alternative specifications. No other consortia or de facto specifications are available.

3.4.6.1.3 Standards deficiencies. The following deficiencies have been identified in the available standards:

a. No standardized API to the ISO DTP protocol.
b. No Ada binding to the ISO 10026 services or protocol.
c. The ISO 10026 DTP model does not address the overall environment.

3.4.6.1.4 Portability caveats. Portability problems for the ISO TP protocol are unknown. The IEEE P1003.11 Group is disbanded. P1003.11 draft documents and current work are being transferred to the P1003.0 Group.

3.4.6.1.5 Related standards. The following standards are related to interoperability in heterogeneous TP systems:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9075:1992: SQL Third Edition (same as NIST FIPS PUB 127-2:1993)

c. ISO 9579-1: RDA (Generic Model, Service and Protocol)

d. ISO 9579-2: RDA (SQL Specialization)

e. ISO 9594 Parts 1-8: Directory Services

f. ISO 9804/9805: CCR

g. ISO DIS 10148: RPC

h. ISO Working Draft (WD) 10181-1: Security Frameworks in Open Systems: Part 1:Overview

i. ISO DIS 10181-2: Security Frameworks in Open Systems: Part 2: Authentication Framework

j. ISO DIS 10181-3: Security Frameworks in Open Systems: Part 3: Access Control Framework

k. ISO 11578: RPC

l. ITU-T Recommendation X.500: Directory Services

m. IEEE P1003.1b: Real-Time Extension to POSIX

n. IEEE P1003.1c: Threads Extension to POSIX

o. IEEE P1003.17: Directory Services API

p. European Computer Manufacturers' Association (ECMA) 127: RPC

q. ECMA Technical Report: Support Environment for Open Distributed Processing (SE-ODP)

r. OSF: DCE RPC

s. X/Open C193, S423: XA and XA+ Interfaces

3.4.6.1.6 Recommendations. ISO 10026, parts 1, 2, and 3, is recommended.

3.4.6.2 Transaction manager-to-resource manager interface. These standards specify the interface from the transaction manager to the resource manager. In some models, only transaction managers can communicate.

3.4.6.2.1 Standards. Table 3.4-24 presents standards for the transaction manager to resource manager interface.

TABLE 3.4-24 Transaction manager-to-resource manager interface standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Distributed TP: The XA Specification

C193 (2/92)

Adopted

(Approved)

CPC

X/Open

Distributed TP: Reference Model, Version 2

G307 (11/93)

Informational

(Approved)

CPC

X/Open

Distributed TP: Reference Model, Version 3

G504 (2/96)

Informational

(Approved)

3.4.6.2.2 Alternative specifications. The following specifications are also available:

a. USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.4.6.2.3 Standards deficiencies. No Ada binding to the X/Open XA Specification exists. The XA interfaces do not address, or directly accept hash values for global transaction identifiers. (Hash value handling capabilities were addressed in the preliminary specification, but were dropped in the final specification.) The comparison of global IDs is indirect and convoluted, rather than explicit.

3.4.6.2.4 Portability caveats. In the X/Open distributed transaction processing model, the major and most accepted model to date, the transaction manager is bundled with the communications manager. Although this can enhance transaction communications efficiency, it also makes it more difficult to define a portable and interoperable interface with a multitude of communications systems, including legacy systems.

3.4.6.2.5 Related standards. The following standards are related to transaction manager-to-resource manager interface standards:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9075:1992: SQL Third Edition (same as NIST FIPS PUB 127-2:1993)

c. ISO 9579-1: RDA (Generic Model, Service and Protocol)

d. ISO 9579-2: RDA (SQL Specialization)

e. ISO 9594 Parts 1-8: Directory Services

f. ISO 9804/9805: CCR

g. ISO 10026: DTP Model, Services, and Protocol

h. ISO DIS 10148: RPC

i. ISO WD 10181-1: Security Frameworks in Open Systems: Part 1: Overview

j. ISO DIS 10181-2: Security Frameworks in Open Systems: Part 2: Authentication Framework

k. ISO DIS 10181-3: Security Frameworks in Open Systems: Part 3: Access Control Framework

l. ISO DP 11578: RPC

m. ITU-T Recommendation X.500: Directory Services

n. IEEE P1003.1b: Real-Time Extension to POSIX

o. IEEE P1003.1c: Threads Extension to POSIX

p. IEEE P1003.17: Directory Services API

q. ECMA 127: RPC

r. ECMA Technical Report: SE-ODP

s. OSF: DCE RPC

3.4.6.2.6 Recommendations. Open distributed TP systems must support X/Open XA interfaces, because no other specification exists for transaction manager-to-resource manager interfaces.

Unless the communications manager is decoupled from the transaction manager, be very careful about any distributed transaction processing systems that claim to provide portability with legacy communications systems.

3.4.6.3 Transaction manager-to-communications manager interface. These standards specify the interface from the transaction manager to the communications manager. In some specifications the communications manager was part of the transaction manager. These specifications cover the case in which the communications manager has been extracted and decoupled from the transaction manager.

3.4.6.3.1 Standards. Table 3.4-25 presents standards for the transaction manager to communications manager interface.

TABLE 3.4-25 Transaction manager-to-communications manager interface standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Distributed TP: The TxRPC Specification

C505 (11/95)

Adopted

(Approved)

CPC

X/Open

Distributed TP: The XATMI Specification

C506 (11/95)

Adopted

(Approved)

CPC

X/Open

Distributed TP: The XA+ Specification, Version 2 (Based on CPI-C, Version 2)

S423 (7/94)

Adopted

(Approved)

CPC

X/Open

Distributed TP: TxRPC Specification (Based on X/Open DCE RPC paradigm)

P305 (7/93)

Informational

(Superseded)

CPC

X/Open

Distributed TP: XATMI Specification (Based on Tuxedo ATMI Interface)

P306 (7/93)

Informational

(Superseded)

3.4.6.3.2 Alternative specifications. The following specification is also available:

a. Transarc: Encina

3.4.6.3.3 Standards deficiencies. No Ada binding is being developed for the XA+ Interface.

3.4.6.3.4 Portability caveats. The XA+ Interface is highly controversial because although decoupling the communications manager from the transaction manager makes it easier to integrate different communications systems and paradigms, such decoupling can result in a loss of communications efficiency and performance. Consequently with good reason, various vendors may bundle the communications and transaction managers together with the resulting loss of portability because of the need to write different communications interfaces.

3.4.6.3.5 Related standards. The following standards are related to transaction manager-to-communications manager interface:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9594 Parts 1-8: Directory Services

c. ISO 9804/9805: CCR

d. ISO 10026: DTP Model, Services, and Protocol

e. ISO DIS 10148: RPC

f. ISO WD 10181-1: Security Frameworks in Open Systems: Part 1: Overview

g. ISO DIS 10181-2: Security Frameworks in Open Systems: Part 2: Authentication Framework

h. ISO DIS 10181-3: Security Frameworks in Open Systems: Part 3: Access Control Framework

i. ISO DP 11578: RPC

j. ITU-T Recommendation X.500: Directory Services

k. IEEE P1003.1b: Real-Time Extension to POSIX

l. IEEE P1003.1c: Threads Extension to POSIX

m. IEEE P1003.17: Directory Services API

n. ECMA 127: RPC

o. OSF: DCE RPC

p. X/Open C193: XA Interface

3.4.6.3.6 Recommendations. If it is desirable to decouple the transaction manager from the communications manager, such decoupling, as well as the XA+ specification, must be specified explicitly in procurement specifications. Otherwise, vendors probably will propose products that do not meet this specification. X/Open S423, P306, and P305 are recommended.

For ease of integration with legacy communications and transaction processing systems, be sure the communications manager is decoupled from the transaction manager. If performance is an issue, at least for the near term, require the communications and transaction manager to be bundled together.

3.4.6.4 Application-to-communications resource manager interface. These specifications define the interface between the application and the communications manager, which is a type of resource manager.

3.4.6.4.1 Standards. Table 3.4-26 presents standards for application to communications resource manager interfaces.

TABLE 3.4-26 Application-to-communications resource manager interface standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPN-C

UI

CM Reference Specification

TP Standards Strategy White Paper, Rev. 4.0

Informational

(Approved)

CPC

X/Open

CM Specification

Working Papers

Informational

(Formative)

3.4.6.4.2 Alternative specifications. The following specifications are also available:

a. Transarc: Encina
b. NCR: Top End

3.4.6.4.3 Standards deficiencies. Neither an Ada nor a Cobol binding is being developed for the Communications Manager (CM) interface, although the architecture of the CM interface is easily adaptable to the Ada language.

3.4.6.4.4 Portability caveats. The CM Interface is controversial because it implies that the communications manager is decoupled from the transaction manager. This is controversial as explained further in the section on the XA+ interface. For example, AT&T/USL's Tuxedo bundles the transaction manager with the communications manager. Thus, Tuxedo is not likely to be compatible with the CM interface.
The number of vendors committed to implementing the CM interface probably will make it a de facto standard once it is adopted by X/Open. This may create portability problems with Tuxedo, which is currently the most widely used transaction manager.

3.4.6.4.5 Related standards. The following standards are related to application-to-communications resource manager interface:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9594 Parts 1-8: Directory Services

c. ISO 9804/9805: CCR

d. ISO 10026: DTP Model, Services, and Protocol

e. ISO DIS 10148: RPC

f. ISO WD 10181-1: Security Frameworks in Open Systems: Part 1: Overview

g. ISO DIS 10181-2: Security Frameworks in Open Systems: Part 2: Authentication Framework

h. ISO DIS 10181-3: Security Frameworks in Open Systems: Part 3: Access Control Framework

i. ISO DP 11578: RPC

j. ITU-T Recommendation X.500: Directory Services

k. IEEE P1003.1b: Real-Time Extension to POSIX

l. IEEE P1003.1c: Threads Extension to POSIX

m. IEEE P1003.17: Directory Services API

n. ECMA 127: RPC

o. OSF: DCE RPC

p. X/Open C193: XA Interface

q. X/Open S423: XA+ Specification

3.4.6.4.6 Recommendations. If it is desirable to decouple the transaction manager from the communications manager, such decoupling, as well as the emerging CM specification, must be specified explicitly in procurement specifications. Otherwise, vendors probably will propose products that do not meet this specification.

For ease of integration with legacy communications and transaction processing systems, be sure the communications manager is decoupled from the transaction manager. If performance is an issue at least for the near term, require the communications and transaction manager to be bundled together.

3.4.6.5 Communications manager-to-protocol stack interface. These specifications define the interface between the communications manager and the underlying protocol stacks. They allow a single communications manager to interface with multiple, independently provided protocol stack implementations, and multiple CMs to be integrated with a single protocol stack implementation.

3.4.6.5.1 Standards. Table 3.4-27 presents standards for the communications manager to protocol stack interface.

TABLE 3.4-27 Communications manager-to-protocol stack interface standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

ACSE/Presentation: Transaction Processing API (XAP-TP)

C409 (4/95)

Informational

(Approved)

NPC

IEEE

XAP-TP Specification (Based on X/Open's XAP-TP Specification)

Number not yet assigned

Informational

(Draft)

3.4.6.5.2 Alternative specifications. No other consortia or de facto specifications are available.

3.4.6.5.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard.

3.4.6.5.4 Portability caveats. This is a high portability risk area because no standards have been completed.

3.4.6.5.5 Related standards. The following standards are related to communications manager-to-protocol stack interface standards:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9594 Parts 1-8: Directory Services

c. ISO DIS 10148: RPC

d. ISO WD 10181-1: Security Frameworks in Open Systems: Part 1: Overview

e. ISO DIS 10181-2: Security Frameworks in Open Systems: Part 2: Authentication Framework

f. ISO DIS 10181-3: Security Frameworks in Open Systems: Part 3: Access Control Framework

g. ISO DP 11578: RPC

h. ITU-T Recommendation X.500: Directory Services

i. IEEE P1003.1b: Real-Time Extension to POSIX

j. IEEE P1003.1c: Threads Extension to POSIX

k. IEEE P1003.17: Directory Services API

l. ECMA 127: RPC

m. OSF: DCE RPC

3.4.6.5.6 Recommendations. The X/Open ACSE/Presentation - Transaction Processing API (XAP-TP) specification must be referenced specifically in procurement specifications, and a requirement to move to the XAP-TP specification as soon as it is adopted by X/Open also must be stated there specifically. Otherwise, vendors probably will propose products that do not meet this specification.

To maximize interoperability and portability, the emerging XAP-TP interface should be used when it is adopted by X/Open for the interface between the communications manager and the protocol stack(s) being used.

3.4.6.6 Transaction demarcation. These specifications define the interface between the transaction manager and the application, taking transaction demarcation information from the application and delimiting the transaction to the resource manager.

3.4.6.6.1 Standards. Table 3.4-29 presents standards for transaction demarcation.

TABLE 3.4-28 Transaction demarcation standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Distributed TP: The TX (Transaction Demarcation) Specification

C504 (4/95)

Adopted

(Approved)

CPC

X/Open

Distributed TP: The XA Specification

C193 (2/92)

Informational

(Approved)

CPC

X/Open

Structured Transaction Definition Language (STDL)

P536 (12/95)

Informational

(Approved)

CPC

MIA Consortia

Standardized Transaction Definition Language (STDL)

TBD-Standardized Transaction Definition Language (STDL)

Informational

(Approved)

CPN-C

UI

ATMI (Application to Transaction Manager Interface) Specification

Trans. Monitor I/F Spec. Ver. 1.0:1991

Informational

(Approved)

CPC

X/Open

Distributed TP: The TX (Transaction Demarcation) Specification

P209 (11/92)

Informational

(Superseded)

3.4.6.6.2 Alternative specifications. The following specifications are also available:

a. USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.4.6.6.3 Standards deficiencies. The TX specification does not support traditional transaction monitor functions such as screen management and terminal management.

3.4.6.6.4 Portability caveats. Unlike the XA interface, which had no installed base to displace, every transaction processing system has its own interface between the application and the transaction manager that delimits a transaction. Therefore gains in multivendor portability for new systems are offset by a decrease in portability across legacy TP systems.
Without a standard API between transaction processing applications and transaction managers, portable formal and de facto standardized Fourth Generation Languages (4GLs) are unlikely to be developed. Furthermore, vendors will develop and port their 4GLs only to the most popular, best-selling transaction processing platforms.

The IEEE P1003.11 group, which was developing a profile for transaction processing environments, has been disbanded. The P1003.11 draft documents and current work are being transferred to the P1003.0 group.

3.4.6.6.5 Related standards. The following standards are related to transaction demarcation or transaction demarcation standards:

a. ISO 9579-1: RDA (Generic, Model, Service and Protocol)

b. ISO 9579-2: RDA (SQL Specialization)

c. ISO 9594 Parts 1-8: Directory Services

d. ISO 10026-1, -2, -3: DTP Protocol

e. ISO DIS 10148: RPC

f. ISO WD 10181-1, -2, -3: Security Frameworks in Open Systems, Part 1: Overview, Part 2: Authentication Framework, Part 3: Access Control Framework

g. ISO 11578: RPC

h. IEEE P1003.1b: Real-Time Extension to POSIX

i. IEEE P1003.1c: Threads Extension to POSIX

j. IEEE P1003.17: Directory Services API

k. ECMA TR/SE-ODP

l. ECMA TR/29: Open Systems Interconnection - Distributed Interactive Processing Environment

m. ECMA 127: RPC

n. OSF: DCE RPC

o. X/Open S423: XA+ Interfaces

3.4.6.6.6 Recommendations. The TX specification is recommended and must be referenced specifically in procurement specifications. Otherwise, vendors probably will propose products that do not meet this specification.

Plan for at least two interfaces: the TX interface for new multivendor, distributed systems and the legacy TP interface for existing TP systems. The TX Specification and XA Specification are complementary specifications the MIA consortia's STDL (Standardized Transaction Definition Language) However, may provide great acceptance by certain large vendors.

3.4.6.7 Transaction monitoring services and interfaces. Transaction management systems monitor network transaction flow and workload balance.

3.4.6.7.1 Standards. Table 3.4-29 presents standards for transaction monitoring services and interfaces.

TABLE 3.4-29 Transaction monitoring services and interfaces standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.6.7.2 Alternative specifications. The following specifications are also available:

a. USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.4.6.7.3 Standards deficiencies. A requirement has been identified for a standardized transaction management system to manage network transaction flow and workload balancing.

3.4.6.7.4 Portability caveats. This is a high portability risk area because no standards exist.

3.4.6.7.5 Related standards. The following standards are related to transaction monitoring or transaction monitoring standards:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9075:1992: SQL Third Edition (same as NIST FIPS PUB 127-2:1993)

c. ISO 9579-1: RDA (Generic Model, Service and Protocol)

d. ISO 9579-2: RDA (SQL Specialization)

e. ISO 9804/9805: CCR

f. ISO DIS 10148: RPC

g. ISO WD 10181-1, -2, -3: Security Frameworks in Open Systems: Part 1: Overview; Part 2 Authentication Framework; Part 3: Access Control Framework

h. ISO 11578: RPC

i. IEEE P1003.1b: Real-Time Extension to POSIX

j. IEEE P1003.1c: Threads Extension to POSIX

k. ECMA 127: RPC

l. OSF: DCE RPC

m. X/Open C193: XA Interfaces

3.4.6.7.6 Recommendations. USL's Tuxedo and Transarc's Encina show signs of becoming de facto standards. Tuxedo is the only DTP system that is not beginning to emerge and has field experience (e.g., Version 4.X is offered, rather than Version 1.X). Tuxedo also formed the base document for X/Open's XA and TX interfaces. On the other hand, Encina is designed to be integrated more easily integrated with legacy TP systems. Therefore, Encina is central to the TP directions and strategies of several major TP vendors, however, there are no standards to recommend.

3.4.6.8 Terminal communications. These standards provide support for terminal communications in a transaction processing system.

3.4.6.8.1 Standards. Table 3.4-30 presents standards for terminal communications.

TABLE 3.4-30 Terminal communications standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.6.8.2 Alternative specifications. The following specifications are also available:

a. USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.4.6.8.3 Standards deficiencies. Deficiencies in the standards are unknown.

3.4.6.8.4 Portability caveats. This is a high portability risk area because no standards exist.
The IEEE P1003.11 group, which was developing a profile for transaction processing environments, has been disbanded. The P1003.11 draft documents and current work are being transferred to the P1003.0 group.

3.4.6.8.5 Related standards. The following standards are related to terminal communications or terminal communications standards:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9075:1992: SQL Third Edition (same as NIST FIPS PUB 127-2:1993)

c. ISO 9579-1: RDA (Generic Model, Service and Protocol)

d. ISO 9579-2: RDA (SQL Specialization)

e. ISO 9594 Parts 1-8: Directory Services

f. ISO 9804/9805: CCR

g. ISO DIS 10148: RPC

h. ISO WD 10181-1: Security Frameworks in Open Systems: Part 1: Overview

i. ISO DIS 10181-2: Security Frameworks in Open Systems: Part 2: Authentication Framework

j. ISO DIS 10181-3: Security Frameworks in Open Systems: Part 3: Access Control Framework

k. ISO 11578: RPC

l. ITU-T Recommendation X.500

m. IEEE P1003.1b: Real-Time Extension to POSIX

n. IEEE P1003.1c: Threads Extension to POSIX

o. IEEE P1003.17: Directory Services API

p. ECMA TR/SE-ODP

q. ECMA TR/29: Open Systems Interconnection - Distributed Interactive Processing Environment

r. ECMA 127: RPC

s. OSF: DCE RPC

t. X/Open C193: XA Interfaces

3.4.6.8.6 Recommendations. USL's Tuxedo and Transarc's Encina have interfaces in this area. Both show signs of becoming de facto standards. Tuxedo also formed the base document for X/Open's XA and TX interfaces. On the other hand, Encina is designed to be integrated more easily with legacy TP systems including IBM mainframes. Therefore, Encina is central to the TP directions and strategies of several major TP vendors. There are no standards to recommend.

3.4.6.9 Transaction program scheduling. These standards provide scheduling support for transaction processing.

3.4.6.9.1 Standards. Table 3.4-31 presents standards for transaction program scheduling.

TABLE 3.4-31 Transaction program scheduling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.6.9.2 Alternative specifications. The following specifications are also available:

a. USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.4.6.9.3 Standards deficiencies. Deficiencies in the emerging IEEE standard are unknown.

3.4.6.9.4 Portability caveats. This is a high portability risk area because no standards exist.
The IEEE P1003.11 group, which was developing a profile for transaction processing environments, has been disbanded. The P1003.11 draft documents and current work are being transferred to the P1003.0 group.

3.4.6.9.5 Related standards. The following standards are related to transaction program scheduling or transaction program scheduling standards:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9075: 1992: SQL Third Edition (same as NIST FIPS PUB 127-2: 1993)

c. IEEE P1003.1c: Threads Extension to POSIX

3.4.6.9.6 Recommendations. There are no standards to recommend.

3.4.6.10 Transaction message queuing. These standards provide specifications for a message queue in a transaction processing environment.

3.4.6.10.1 Standards. Table 3.4-32 presents standards for transaction message queuing.

TABLE 3.4-32 Transaction message queuing standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.6.10.2 Alternative specifications. The following specifications are also available:

a. USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.4.6.10.3 Standards deficiencies. Deficiencies in the emerging IEEE standard are unknown.

3.4.6.10.4 Portability caveats. This is a high portability risk area because no standards exist.
The IEEE P1003.11 group, which was developing a profile for transaction processing environments, has been disbanded. The P1003.11 draft documents and current work are being transferred to the P1003.0 group.

3.4.6.10.5 Related standards. The following standards are related to transaction message queuing or transaction message queuing standards:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9075:1992: SQL 3rd edition

c. IEEE P1003.1b: Real-Time Extension to POSIX

d. IEEE P1003.1c: Threads Extension to POSIX

3.4.6.10.6 Recommendations. There are no standards to recommend.

3.4.6.11 Recovery and restart services for long running transactions. (This BSA appears in both part 4 and part 9.) Checkpoint and restart is provided for interactive transactions on centralized systems via the SQL "commit" and "rollback" commands, and for short-running transactions on distributed systems via the 2-Phase Commit specified in the ISO CCR standard. However, long running transactions require standardized checkpointing, restarting, and migration services and interfaces to prevent the loss of the transaction if a system fails or shuts down. Two APIs must be standardized for this purpose. One will allow application control of the checkpoint. The other will allow the transaction manager to control the checkpointing and restart activity over a range of heterogeneous resource managers.

3.4.6.11.1 Standards. Table 3.4-33 presents standards for recovery and restart services for long running transactions.

TABLE 3.4-33 Recovery and restart services for long running transactions standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 2:Shell and Utilities - Amendment 1: Batch Environment

1003.2d:1994

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Informational

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment x: Checkpoint/Restart Interfaces (C Language)

P1003.1m

Informational

(Formative)

3.4.6.11.2 Alternative specifications. The following specifications are also available:

a. USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.4.6.11.3 Standards deficiencies. Based on a requirement from the P1003.15 Batch Queuing Extensions Standards Group, the POSIX.1 revision will specify application control of checkpointing. But this specification is geared to batch environments, and does not address the transaction manager's control of checkpoint, restart, or migration of services needed for a transaction processing environment. This need is not being addressed other than by de facto solutions.

P1003.2d specifies some capabilities needed for checkpointing and restart in batch environments, but as a standard geared to batch environments, it does not address the transaction manager's control of checkpoint, restart, or migration of services.

3.4.6.11.4 Portability caveats. Without standardized interfaces to allow application control of checkpointing and transaction manager's control of checkpointing and restart activity, portability and interoperability across heterogeneous resource managers are nonexistent, except for short-running transactions (which are controlled via SQL's "commit" and "rollback" commands and via ISO's CCR standard).

3.4.6.11.5 Related standards. The following standards are related to recovery and restart services or standards:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9075:1992: SQL 3rd edition

c. IEEE 1003.1b:1993: Real-Time Extension to POSIX

d. IEEE 1003.1c:1995: Threads Extension to POSIX

3.4.6.11.6 Recommendations. There is no recommendation for recovery and restart services.

3.4.6.12 Interface to resource manager device drivers. For on-line transaction processing (OLTP) environments, device driver interfaces are needed for devices commonly requiring transaction control (e.g., ticket dispensers, automated teller machines (ATMs)). This will require two types of APIs. One API type would be extensions to the XA and XA+ interfaces, so these interfaces can support device drivers as though they were resource managers. The other API is the interface between the application and the device driver-resource manager.

3.4.6.12.1 Standards. Table 3.4-34 presents standards for interfaces to resource manager device drivers.

TABLE 3.4-34 Interface to resource manager device drivers standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.6.12.2 Alternative specifications. The only other available specifications are proprietary.

3.4.6.12.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard.

3.4.6.12.4 Portability caveats. This is a high portability risk area because no standards exist.

3.4.6.12.5 Related standards. The following standards are related to resource manager device driver interfaces:

a. X/Open C193: Distributed TP: The XA Interface

b. X/Open S423: Distributed TP: The XA+ Specification, version 2

3.4.6.12.6 Recommendations. There are no standards to recommend.

3.4.6.13 Distributed queuing. Distributed queuing is the waiting for services in a distributed computing environment.

3.4.6.13.1 Standards. Table 3.4-35 presents standards for distributed queuing.

TABLE 3.4-35 Distributed queuing standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 2:Shell and Utilities - Amendment 1: Batch Environment

1003.2d:1994

Mandated

(Approved)

CPC

X/Open

Distributed TP: Reference Model, Version 3

G504 (2/96)

Informational

(Approved)

3.4.6.13.2 Alternative specifications. The following specifications are also available:

a. AT&T/USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.4.6.13.3 Standards deficiencies. The 1003.2d standard is geared to batch requests, not transactional requests with associated persistence and rollback capabilities.

3.4.6.13.4 Portability caveats. Most internally built recoverable messaging and queuing facilities depend upon the underlying transport mechanism.

3.4.6.13.5 Related standards. The IEEE P1003.1a: POSIX.1 Revision is essential to the use of IEEE P1003.2d.

3.4.6.13.6 Recommendations. Use the P1003.1a (POSIX.1 Revision) checkpoint and restart interface with IEEE 1003.2d.

At present, building a recoverable messaging and queuing facility on top of whatever transport scheme is used to perform peer-to-peer communications may be necessary. Where applicable, use the emerging P1003.1a (POSIX.1 Revision) checkpoint and restart interface. If possible, establish an internal standardized interface that is independent of the underlying transport mechanism.

3.4.6.14 Modeling services. Modeling service standards simulate a condition or activity in a transaction processing system by performing a set of equations on a set of data. A model is a mathematical representation of a device or process used for analysis and planning.

3.4.6.14.1 Standards. Table 3.4-36 presents standards for modeling services.

TABLE 3.4-36 Modeling services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.4.6.14.2 Alternative specifications. The only other available specifications are proprietary.

3.4.6.14.3 Standards deficiencies. Deficiencies in the modeling services standards are unknown.

3.4.6.14.4 Portability caveats. This is a high portability risk area because no standards exist.

3.4.6.14.5 Related standards. The following standards are related to modeling services or modeling services standards:

a. ISO 9075:1992: SQL 3rd edition

b. ISO 10027:1990 (IRDS Framework)

c. ISO DP 10728 (IRDS Services Interface)

d. ANSI X3.138-1988 (IRDS Requirements and Command Language & Panel Interface)

e. ANSI X3.185-1992 (IRDS Software Services Interface)

f. NIST FIPS 156 (IRDS)

3.4.6.14.6 Recommendations. There are no standards to recommend.