IEEE P1003.0 Draft 14 - November 1991 Copyright (c) 1991 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved as an unpublished work. This is an unapproved and unpublished IEEE Standards Draft, subject to change. The publication, distribution, or copying of this draft, as well as all derivative works based on this draft, is expressly prohibited except as set forth below. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only, and subject to the restrictions contained herein. Permission is hereby also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position, subject to the restrictions contained herein. Permission is hereby also granted to the preceding entities to make limited copies of this document in an electronic form only for the stated activities. The following restrictions apply to reproducing or transmitting the document in any form: 1) all copies or portions thereof must identify the document's IEEE project number and draft number, and must be accompanied by this entire notice in a prominent location; 2) no portion of this document may be redistributed in any modified or abridged form without the prior approval of the IEEE Standards Department. Other entities seeking permission to reproduce this document, or any portion thereof, for standardization or other activities, must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA +1 (908) 562-3800 +1 (908) 562-1571 [FAX] ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 _________________________________________________________________________ _________________________________________________________________________ Figure 4-11 - POSIX Database Reference Model The model depicted in Figure 4-11. is sufficient to describe an application developer's view of the POSIX OSE API in general, and the database API specifically. The four lines labeled ``Database API'' represent the Database Applications Program Interface services, which are discussed in 4.4.4.1. 4.4.3.2 Implementation Aspects Some real world considerations of the POSIX Reference Model were discussed in 3.6. One of the real-world approaches described is ``layering.'' Note that in the marketplace, Database Managers are often independently purchasable components that are effectively implemented as layers. Another consideration is Database Manager portability. It is not a requirement that a a database manager sit on top of a POSIX OSE API, but there is very important value to the user in terms of portability if the database manager implementation does indeed sit on a POSIX API. This means that the database manager itself is portable. It should be noted that there will probably be implementations available of database managers that do not, in fact, sit on top of a POSIX API (or sit only partially on top of a POSIX API), that nonetheless provide the user the same database API. Such an implementation, using both POSIX API services and non-POSIX API services was described as ``expansion'' (see Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 101 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 3.6.1). Note that even though the model is drawn with only a single database manager, that does not imply that there may only be a single database manager available to an application. In fact, the coexistence of several database managers on the same system is consistent with this model, as is the ability of a single application to access two or more different database managers. The following extensions to the above model are specifically accommodated: - There may be more than one database API. For example, there may be an ``SQL'' API and an ``ISAM'' API. - There may be more than one database manager implementation for each different API. (For example, by two competing database vendors.) - Applications may access more than one database manager. This document has not described how a database manager is implemented in a POSIX Open System Environment, nor is it within the scope of this document to do so. It should be noted, though, that this model is very general and does not constrain the implementor. This model supports a number of varying real world implementation techniques, including: - Application and database manager linked into a single process. - Database manager consisting of more than one process. - Database manager consisting of a client part linked into the application process and a server part running as a process on the same or another system. 4.4.4 Service Requirements The Database Manager described in the previous subclause provides services to the Application Program via the Database API, and the Database Utility Programs provide other services (e.g., to human users such as a ``Database Administrator''). This subclause describes the service requirements of all service users of the system. It is intended to be a complete list of service requirements rather than examples. Database Services are the specialized data services required to create, access, and manage databases located on a processor node. Users of these e services include end users and those charged with the ongoing management of the information processing and database infrastructure. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 102 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.4.4.1 Application Program Interface Services This subclause describes the major categories of database services available at the POSIX Application Program Interface (API). These services include: - Data Definition and Manipulation Services - Data Access Services - Data Integrity Services - Miscellaneous Services The following paragraphs clarify that these services should be provided for a large class of objects, access methods, and types of database systems. Types of Data Objects Ability to perform the above operations on a variety of types of data objects, such as text, graphics, image, documents, and voice. Types of Access Methods Ability to perform the above operations using a variety of access methods, such as indexed sequential access, nonindexed sequential access, and direct access. Types of Database Management Systems Ability to perform the above operations on a variety of types of file and database management systems, and database management systems, such as relational, network, semantic, and object oriented databases, and heterogeneous combinations of these database management systems. 4.4.4.1.1 Data Definition and Manipulation Services These services relate to the ability of application programs to define and manipulate data. These services are: - Data definition -- ability to create, alter, or drop tables, views, records, fields, and/or data - Data Manipulation -- ability to insert, select, update, and delete tables, views, records, fields, and data Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 103 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4.4.4.1.2 Data Access Services These services relate to the ability of application programs to interrogate databases. These services are: - Data Query Facilities -- ability to specify search conditions, consisting of a combination of select lists, predicates, and comparison operators - Data Transparency -- ability to transparently access data regardless of the location of that data. - Remote Data Access -- ability to access and update remote data 4.4.4.1.3 Data Integrity Services These services relate to the ability of database management systems to protect the databases from hardware and software malfunctions. - Locking -- ability to specify locking of data to some degree of granularity - Consistency -- ability to specify and execute check and referential constraints that help ensure data correctness - Transaction Control -- ability to specify commit and rollback commands and guarantee serializability for database transactions e - Synchronous Writes (Durability?) -- ability to force the writing of data to nonvolatile storage 4.4.4.1.4 Miscellaneous Database Services e Miscellaneous database services include: e - Privilege Administration -- ability to grant and revoke privileges for accessing and administering data - Exception Handling -- ability to have applications that are interrupted and notified of exception conditions, to receive control of the machine and take action in response to these exception conditions--even if the action is to ``continue'' - Screen Definitions -- ability to create screen definitions, and define, display, and/or paint screens to communicate information e about databases e - Reporting -- ability to create formatted reports. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 104 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 - Dynamic Facilities -- ability to temporarily turn control of a database to the end user for interactive access and manipulation of data, and then return control to the application. - Data Dictionary Services -- ability to get data about the data (i.e., metadata) stored in the database. This allows users and applications to use the database contents in a much more flexible way. These services allow a user to create, access, and manage this metadata much in the same way as other databases are maintained. 4.4.4.2 External Environment Interface Services External Environment Interface services are required for distributed database management systems. Also, to enable two or more databases to communicate with each other, a common interchange format is required. See 4.5. 4.4.4.3 Database Resource Management Services These services are not visible to the application programmer at the Database API. These services are usually provided by Database Utility Programs. These services include: - Database Administration Services - Database Recovery Services - Distributed Database Management Services - Heterogeneous Environment Support Services 4.4.4.3.1 Database Administration Services Database administration services refer to the ability for a designated e data administrator to structure and configuration manage a database as a whole. The administrator allocates resources and monitors utilization to assure that authorized users receive the proper services. Archive functions, journaling, and logging services are available to the user and administrator on a selective basis. 4.4.4.3.2 Database Recovery Services Database recovery services refer to the ability to decide that there has e been a failure, allow recovery from failure, and permit a slave copy to become a master copy. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 105 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4.4.4.3.3 Distributed Database Management Services Distributed database management services support the partitioning and e partial replication of the databases. 4.4.4.3.4 Heterogeneous Environment Support Services Heterogeneous environment support services permit local database systems e to be of different types (e.g., inverted list, hierarchical, network, relational) by providing translators between the local database form and a general ``network language.'' 4.4.4.3.5 Flagger A flagger is software that alerts programmers about any code that does e not conform to the standard in question, such as the Structured Query e Language standard. e 4.4.5 Standards, Specifications, and Gaps There are currently four database standards, either completed or under development. These are the relational data language SQL, a network data language called NDL, the Information Resource Dictionary System (IRDS) for data dictionary work, and a Remote Data Access (RDA) protocol. Table 4-5 summarizes the service requirements provided by the various standards. 4.4.5.1 Current Standards This subclause describes the current accepted standards that apply to this area. _S_Q_L__S_t_a_n_d_a_r_d__D_a_t_a_b_a_s_e__L_a_n_g_u_a_g_e ISO 9075 (FIPS 127) e ANSI X3.168 e ISO 9075 provides for many of the services described in 4.4.4, including e Data Definition, Manipulation, and Integrity. It provides for two levels of compliance: the weaker Level 1 and the more capable Level 2. While e ISO 9075 deals with SQL independently of programming language, X3.168 e binds, or embeds, SQL within the programming languages COBOL, FORTRAN, Pascal, PL/1, C, and Ada. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 106 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Table 4-5 - Database Standards __________________________________________________________________________________________________________________________________________________ Service Type Specification Subclause _________________________________________________________________________ Data Definition and S SQL: ISO 9075 4.4.5.1 eeee Manipulation Services ANSI X3.168 ee Data Access Services e Data Integrity Services e Data Definition and S NDL: ISO 8907 4.4.5.1 eeee Manipulation Services e Data Access Services e Data Integrity Services e Miscellaneous Services E IRDS: ISO DP 10027 N2642 4.4.5.2 eeee (Data Security and (IRDS Framework), ee Integrity, Exception ISO DP 8800 N2132 ee Handling, Screen (IRDS Interfaces), ee Definitions, Reporting, ANSI X3.138 ee Dynamic Facilities, Data e Dictionary Services) e Database Resource e Management Services e (Database Administration, e Recovery From Failure) e External Environment E RDA: ISO/IEC DP 9759 4.4.5.1 eeee Interface Services e __________________________________________________________________________________________________________________________________________________ Work is currently planned by ANSI and ISO to include ``generalized triggers,'' ``generalized assertions,'' ``recursive expressions,'' ``escape from SQL,'' subtables, and support tools for object oriented and knowledge-based systems. _N_D_L__S_t_a_n_d_a_r_d__D_a_t_a_b_a_s_e__L_a_n_g_u_a_g_e ISO 8907 ANSI X3.133 This standard, developed in 1981-1986 by the ANSI X3H2 Database Committee, specifies a data definition language (DDL) and data manipulation language (DML) for network model databases. This work is an outgrowth of the 1978 CODASYL specifications. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 107 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS This standard provides for many of the services described in 4.4.4, including Data Definition, Manipulation, Access, and Integrity. The above services apply only to network databases (i.e., not to relational or semantic databases.) No follow-on NDL activities are being conducted by ISO or ANSI. 4.4.5.2 Emerging Standards This subclause describes the activities currently in progress to further standardize this area. _R_e_m_o_t_e__D_a_t_a__A_c_c_e_s_s__(_R_D_A_)__P_r_o_t_o_c_o_l ISO DP 9579-1 _G_e_n_e_r_i_c _R_e_m_o_t_e _D_a_t_a_b_a_s_e _A_c_c_e_s_s -- DP 2 e ISO DP 9579-2 _S_Q_L _S_p_e_c_i_a_l_i_z_a_t_i_o_n -- DP 1 e This standard, developed by the ECMA Technical Committee on Database Standards, TC22, submitted to ISO in 1985, specifies a protocol that allows remote access and updating, via OSI communications protocols, of relational databases or of database systems that support SQL. This standard provides for the Data Transparency, Remote Data Access, and Support for Heterogeneous Environment requirements described in 4.4. This protocol is aimed at relational databases and other database types that provide access via relational interfaces such as SQL. Much work is planned on in this area by the ISO committee ISO TC97/SC21/WG3. A specific area of current interest is a generic RDA that uses a nonspecific database language (i.e., not SQL.) _I_n_f_o_r_m_a_t_i_o_n__R_e_s_o_u_r_c_e__D_i_c_t_i_o_n_a_r_y__S_y_s_t_e_m__(_I_R_D_S_) ANSI X3.138 FIPS Pub 156, April 5, 1989 ANSI X3H4/90-28 (draft, 4 Apr 90) IRDS Export/Import File Format ISO DP 10027 N2642 (1988) IRDS Framework ISO DP 8800 N2132 (1988) IRDS Services Interfaces These standards are being developed by the ANSI X3H4 Database Group and the ISO/IEC /JTC 1/SC21 Working Group 3. Both groups are addressing the general area of data dictionaries, but, as described below, the emphases of the activities differ. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 108 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 The ANSI group primarily addresses the user interface area; that is, how a human user can access the Data Dictionary Services described in 4.4.4. The ISO groups concentrate more on the service interfaces (APIs) among lower level components and utilities of the database model. Differences in scope and incompatibilities exist between the model being developed by ISO and the model approved by ANSI. They are independently developing the Services Interface, and an export/import facility. 4.4.5.3 Gaps in Available Standards There are two significant areas described in 4.4.4 as requirements that are not addressed by standards: - Methods to access data such as hashing and indexed sequential access to data is not currently standardized. There is no consensus in the standards community as to whether such standardization would be beneficial. - Standardization of semantic and object oriented models have also not taken place, though groups like the ANSI Database system study group (DBSSG) are currently investigating the feasibility of standardization in these areas. - I/O Services such as screen generation. - Management and control of database services. Also include all gaps (all services without standards). 4.4.6 OSE Cross-Category Services 4.4.6.1 Security The ability to specify logical database access control mechanisms is e important to database security. e 4.4.7 Related Standards The standards and activities described in this subclause are related to the above and may also be relevant to your activities. There are several areas closely related to the Database area that are worth considering with respect to standardization. The first area to consider is the communications and networking area. Interoperability for distributed applications or the use of distributed Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 109 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS databases may indicate the use of communications software adhering to networking standards. See 4.3 for further discussion of that area. (Specifically consider the following standards described in that subclause: ISO/IEC 9804.3 (OSI CCR services) ISO/IEC 9805.3 (OSI CCR protocol) ISO 8824 _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_y_s_t_e_m_s--_O_S_I-- _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e (_A_S_N._1) ISO 8825 _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_y_s_t_e_m_s--_O_S_I-- _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _B_a_s_i_c _E_n_c_o_d_i_n_g _R_u_l_e_s _f_o_r _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e (_A_S_N._1) The second area to consider is transaction processing. That area goes further in addressing the total requirements for distributed applications. See 4.6. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 110 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.5 Data Interchange Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _R_i_c_h_a_r_d _S_c_o_t_t 4.5.1 Overview and Rationale The Data Interchange/Information Exchange components of the POSIX Open System Environment provide specialized support for the exchange of data between applications or components of applications. Without support for data interchange, problems can arise when attempts are made to move data between different operational environments or between two related applications. More specifically, data interchange problems arise in each of the five following situations: - Movement of a single application program and its associated data between operational environments, - Movement of data between cooperating application software within the same operational environment, - Movement of data between cooperating application software operating in differing operational environments, - Movement of data between related, but not cooperating, application software within a single operational environment, and across differing operational environments. From the global view, the data interchange components can provide the means to satisfy the needs in each of these situations. These standards need to define physical formats, data formats, code sets, and data descriptions that are consistent across all implementations of the POSIX Open System Environment. 4.5.2 Scope The data interchange component of the POSIX Open System Environment includes standard services, protocols, and data formats required to ensure that data can be interchanged between related application software. Physical media formats are beyond the scope of the POSIX Open System Environment. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.5 Data Interchange Services 111 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4.5.3 Reference Model _________________________________________________________________________ _________________________________________________________________________ Figure 4-12 - Data Interchange Reference Model The Data Interchange Services relate directly to the POSIX Open System Environment reference model that was presented in Figure 3-1. Figure 4- 12 shows the components of the reference model that are significant for data interchange. The reference model defines the conceptual relationships required to provide these facilities. It should not be viewed as a description of an implementation. The key entities within the figure are the Application Software, the Application Platform, and the External Environment. To satisfy the data interchange service requirements, the POSIX Open System Environment must permit application software to transfer data to and from the external environment. The application software requests this transfer through the Application Program Interface. In response to those requests, the data interchange components of the Application Platform handle conversions to and from standard formats and the transfer of the information across the External Environment Interface (EEI). The EEI, which defines the format specifications required to support data interchange, can be divided into Data Description Protocols and Data Format Protocols. Data Description Protocols provide a means to identify the data that is present. Data Format Protocols provide the storage representation of the actual data. Today, this model is only partially supported by standards. Physical formats are fairly well standardized. Some work is beginning on data Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 112 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 format protocols standards, particularly in the networking area. At this time, no general standards exist to support Data description protocols. 4.5.4 Service Requirements This subclause details the Data Interchange Services and protocols that are required to support application portability and interoperability. Subclause 4.5.4.1 describes the API service requirements. 4.5.4.2 describes the EEI service (i.e., protocol) requirements. Data interchange is one of the components of the POSIX Open System Environment that is now just beginning to evolve. At this time, the general requirements for services are understood, but there is little general existing practice that can be pointed to as showing that current service requirements are both necessary and complete. Most existing practice is limited to a specific application domain. As a developing area, data interchange represents gaps in both the definition of service requirements and standards. The data interchange component is, none the less, critical for supporting application portability and interoperability. The data interchange service requirements are currently described to the extent possible at this time in their evolution. More detail will be added in future revisions of this guide. 4.5.4.1 Application Program Interface Services The API services to support data interchange need to provide the ability to store and retrieve data using the formats and protocols provided at the data interchange EEI. At this time little work has been directed at defining API-level service requirements for data interchange. Data interchange API services need to provide a means to request that specific data be represented using the EEI services defined below. Progress in this area is similar to the development of the networking area. Initial standards defined protocols and only after those were in use has attention shifted to providing a standard mechanism for requesting those networking services. 4.5.4.2 External Environment Interface Services This section identifies the EEI services required to support data interchange. These services are all in the form of protocol and format definitions. As shown in Figure 4-12, these protocols include: - Character Sets and Data Representation - Data Format Protocols Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.5 Data Interchange Services 113 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - Data Description Protocols These protocols are required to support the exchange of information between application software entities, both within a single application platform and between application platforms. 4.5.4.2.1 Character Sets and Data Representation The ability to support Character Sets and Data Representation is crucial to providing effective data interchange between application software operating under differing language and cultural conventions. These services add facilities to the POSIX Open System Environment to identify the character set and data representations associated with textual data. A detailed description of the requirements in this area can be found in 5.1. 4.5.4.2.2 Data Format Protocols The data format protocols need to provide the ability to identify the representation of the data in a manner that is independent of the specific execution environment. The data format protocol layer adds attributes that describe the physical characteristics of the data that must be known to properly retrieve the data value, given the storage formats that are native on the hardware/software environment where the data is used. The complete attribute information required to decipher that data value includes: - Detailed storage format for the value - The data value in an environment-neutral format The data format protocols protect applications from hardware/software differences between environments. Specifically, the protocols ensure that data remains stable when moving between environments where the character set, word size, or byte ordering may differ. 4.5.4.2.3 Data Description Protocols Data description protocols provide the ability to share data between related application software entities, even if they were not specifically written to cooperate. Building upon the facilities provided by the previous two Data Interchange EEI Services, data description protocols provide a means of associating a name or other identifier with the individual data elements in a standard manner. This permits an application program to correctly identify data that was created by an unrelated application. To date, most standards in this area have limited themselves to specific application areas and no general solution has been provided. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 114 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.5.5 Standards, Specifications, and Gaps See Table 4-6. Table 4-6 - Data Interchange Standards __________________________________________________________________________________________________________________________________________________ Service Type Specification Subclause e ______________________________________________________________________________e Data Description Protocols ODA/ODIF S ISO 8613 Parts 1-8 4.5.5.1 e ee SGML S ISO 8879 4.5.5.1 e ee EDIFACT S ISO 9735 4.5.5.1 e ee STEP E ISO DP 10303 4.5.5.2 e ee EDIFACT S ANSI X.12 4.5.5.1 e ee IGES G NBSIR 86 4.5.5.3 e ee VHDL VHSIC G IEEE P1076 4.5.5.3 e ee Data Format Protocols ODA/ODIF S ISO 8613 Parts 1-8 4.5.5.1 e ee SGML S ISO 8879 4.5.5.1 e ee CGM S ISO 8632 4.5.5.1 e ee CGM S ANSI X3.122-1986 4.5.5.1 e ee STEP E ISO DP 10303 4.5.5.2 e ee EDIFACT S ISO 9735 4.5.5.1 e ee EDIFACT S ANSI X.12 4.5.5.1 e ee IGES G NBSIR 86-3359 4.5.5.3 e ee VHDL VHSIC G IEEE P1076 4.5.5.3 e ee CDIF G 4.5.5.3 e ee __________________________________________________________________________________________________________________________________________________ 4.5.5.1 Current Standards _O_p_e_n__D_o_c_u_m_e_n_t__A_r_c_h_i_t_e_c_t_u_r_e__(_O_D_A_)_/_O_p_e_n__D_o_c_u_m_e_n_t__I_n_t_e_r_c_h_a_n_g_e__F_o_r_m_a_t__(_O_D_I_F_) The ODA/ODIF standard (ISO 8613 Parts 1-8) provides a standard for the structures used to represent documents. The ODA model defines a comprehensive description of a documents format. It supports both reproduction of the original document and also editing and formatting of the document. Part 5 of the ISO ODA standard specifies the interchange format for ODA documents; specifically ODIF. ODIF is an ASN.1 (ISO 8825) based presentation of the ODA document. _S_t_a_n_d_a_r_d__G_e_n_e_r_a_l_i_z_e_d__M_a_r_k_u_p__L_a_n_g_u_a_g_e__(_S_G_M_L_) SGML (ISO 8879) is a language that allows users to precisely define the structure of a document. The key difference between SGML and ODA/ODIF is that the former provides the flexibility to define custom document types. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.5 Data Interchange Services 115 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS _C_o_m_p_u_t_e_r__G_r_a_p_h_i_c_s__M_e_t_a_f_i_l_e__(_C_G_M_) CGM (ISO 8632, ANSI X3.122-1986) provides a standard means for the storage and exchange of computer graphics. Graphic information is stored in a device- and resolution-independent fashion that can support both the display and the manipulation of the data. _E_l_e_c_t_r_o_n_i_c__D_a_t_a__I_n_t_e_r_c_h_a_n_g_e__(_E_D_I_) The EDI standards [ISO 9735 (EDIFACT), ANSI X.12] provide support for the exchange of structured business data. EDI is typically used to transfer business documents such as purchase orders, invoices, promotional announcements, and electronic funds transfer information. e 4.5.5.2 Emerging Standards _S_t_a_n_d_a_r_d__f_o_r__t_h_e__E_x_c_h_a_n_g_e__o_f__P_r_o_d_u_c_t__M_o_d_e_l__D_a_t_a__(_S_T_E_P_) STEP (ISO DP 10303) is a neutral mechanism capable of completely representing product data throughout the life cycle of a product. The completeness of this representation makes it suitable not only for file exchange, but also as a basis for implementing and sharing databases of archiving. e 4.5.5.3 Gaps in Available Standards 4.5.5.3.1 Public Specifications Most standards activity in the data interchange area has been isolated to specialized application areas. These activities have attempted to support data interchange by limiting the scope of the effort to a specific type of data. These industry standards include: e _I_n_i_t_i_a_l__G_r_a_p_h_i_c_s__E_x_c_h_a_n_g_e__S_p_e_c_i_f_i_c_a_t_i_o_n__(_N_B_S_I_R__8_6_-_3_3_5_9_) IGES is used heavily in the exchange of graphical information between applications. e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 116 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 _C_A_S_E__D_a_t_a__I_n_t_e_r_c_h_a_n_g_e__F_o_r_m_a_t__(_C_D_I_F_) The CDIF Technical Committee is developing a data interchange format to serve as an industry standard for exchanging information between Computer-Aided Software Engineering (CASE) tools. CDIF is an EIA- endorsed initiative. It assumes that two or more tools may interface asynchronously with each other and will transfer information from one to another via ``CDIF files.'' The types of information that may be contained in these files is defined by the CDIF Conceptual Models. e _H_a_r_d_w_a_r_e__D_e_s_c_r_i_p_t_i_o_n__L_a_n_g_u_a_g_e__(_V_H_D_L__V_H_S_I_C_) The VHDL standard (IEEE P1076) defines a representation for the exchange of CAD representations of electronic circuits. 4.5.5.3.2 Unsatisfied Service Requirements None of these standards addresses a general means to handle application data in a manner to ensure portability between environments. The closest attempt is the effort just beginning in POSIX.8 to define a means within the network interface to provide data portability. However, even this effort is not attempting to solve the broader issue of interoperability of multiple applications. The existing standards have all evolved to support the interchange of specific types of data between separate applications. Support for general data portability is not addressed by existing standard, except for ISIS, which does not appear to have caught on. 4.5.6 OSE Cross-Category Services Not applicable. 4.5.7 Related Standards The following standards are related to the services covered in this clause as they address some of the services described in section 4.6.4 at some level. Each of these related standards are addressed fully as part of another service category. ASN.1 ISO 8824 Abstract Syntax Notation (Clause 4.3) ISO 8825 ASN.1 Basic Encoding Rules (Clause 4.3) MHS ISO/CCITT X.400-1984 Message Handling System (Clause 4.3) Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.5 Data Interchange Services 117 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS ISO/CCITT X.400-1988 Message Handling System (Clause 4.3) 4.5.8 Open Issues Data interchange support must address hardware/software differences between environments. The key concerns in transporting data that must be addressed will include the character set, word size, and byte ordering for the operating environment along with a accurate identification of the data value. The data portability standards adopted within POSIX Open System Environment need to define data formats that will enable applications to create data that can be used read and properly interpreted on differing operating environments and by other application software. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 118 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.6 Transaction Processing Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _B_o_b _G_a_m_b_r_e_l 4.6.1 Overview and Rationale The database management clause (see 4.4) described some transaction processing (TP) service requirements (specific to databases). This e clause describes the complete set of transaction processing services from the application software point of view. Note that transaction processing services have long been been regarded, variously, to be within the domain of databases or within the domain of operating systems and more recently within the domain of interconnect. These services are more broadly applicable than just both of these areas, and so are treated here as a e separate clause. Transactions (``units of work'') have boundaries (start points and end points) that are determined by the action of the transaction application program. The transaction application program can request to either commit or rollback the work done in the transaction when it identifies the end point. The system will complete a commit operation only if all operations performed during the transaction can complete successfully. Otherwise the system will abort the transaction (rollback the work done by it) and notify the transaction application program of this action. The following is quoted with a few editorial changes from ISO/IEC DP 10026-1, the ISO Distributed Transaction Processing standard draft: A transaction is characterized by four properties: atomicity, consistency, isolation, and durability. These are the _A_C_I_D properties. Atomicity implies that the operations of a unit of work are either all performed, or none of them are performed. Consistency implies that the operations of a unit of work, if performed at all, are performed accurately, correctly, and with validity, with respect to application semantics. Isolation implies that the partial results of a unit of work are not accessible, except by operations which are part of the unit of work. Isolation also implies that units of work which share bound data are serializable. Durability implies that all the effects of a completed unit of work are not altered by any sort of failure. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Transaction Processing Services 119 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4.6.2 Scope This clause deals with the transaction processing services needed for a large number of styles of transaction processing including the following: - Transactional access to a single database manager on a single machine - Transaction access to nondatabase ``resource managers'' (such as the software managing the cash in an automatic teller machine) - Distributed Databases--databases spanning multiple machines, but accessed by application programs as if just a single database - Online Transaction Processing (OLTP)--the scheduling of ``transaction programs'' based on terminal input with consolidated recovery of the database updates and the terminal messages - Distributed Transaction Processing (DTP)--different machines running multiple application programs with multiple databases, using a client/server or conversational application-to-application communications paradigm Note that Transaction Processing Services are used in all of the above situations, and others too. Finally, it should be noted that ``transactions'' are not really ``messages,'' but rather ``units of work'' that may encompass multiple messages. Furthermore, while traditionally ``transaction processing'' has usually been synonymous with ``OLTP'' where so-called ``immediate transactions'' are the norm, other types of transactions are also covered: ``batch transactions'' (where the work is done in the ``background'') and ``deferred transactions'' where there may be a time dependence on the transaction, such as a fixed start time. This clause addresses the current work in progress in groups such as ISO and others. 4.6.3 Reference Model This subclause addresses the conventional Transaction Processing Reference Model, the POSIX OSE Reference Model (incorporating transaction processing considerations), and other important real world considerations introduced by Transaction Processing. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 120 4 POSIX Open System Environment Services