STANDARDS PROJECT
Draft Guide to the POSIX Open System Environment

Portable Applications Standards Committee of the IEEE Computer Society

P1003.0 / D18 February 1995

The Institute of Electrical and Electronics Engineers, New York, USA

ABSTRACT

This Guide presents an overview of open system concepts and their application. Information is provided to persons evaluating systems on the existence of, and interrelationships among, application software standards, with the objective of enabling application portability and system interoperability. A framework is presented that identifies key information system interfaces involved in application portability and system interoperability and describes the services offered across these interfaces. Standards or standards activities associated with the services are identified where they exist, or are in progress. Gaps are identified where POSIX Open System Environment services are not currently being addressed by formal standards. Finally, the concept of a profile is discussed with examples from several application domains.

Keywords: application portability, application interoperability, open system environments, profiles, POSIX

P1003.0/D18 Feb 95

27      2.2 Definitions

28      2.2.1 Terminology

29     For the purposes of this guide, the following definitions apply:

30     2.2.1.1 implementation defined: An indication that the implementation shall

31     define and document the requirements for correct program constructs and correct

32     data of a value or behavior.

33     2.2.1.2 informative: Providing or disclosing information; instructive.

34     Used in standards to indicate a portion of the text that poses no requirements; the

36     opposite of normative.

36     2.2.1.3 may: An indication of an optional feature.

37     With respect to implementations, the word may is to be interpreted as an optional

38     feature that is not required in this guide, but can be provided.

39     2.2.1.4 normative: Of, pertaining to, or prescribing a norm or standard.

40     Used in standards to indicate a portion of the text that poses requirements.

41     2.2.1.5 should: With respect to implementations, an indication of an implemen-

42     tation recommendation, but not a requirement.

43     2.2.1.6 POSIX: The term "POSIX" has been evolving into a term with, unfor-      F

44     tunately, a number of different meanings. This subclause attempts to define the       F

45     word and some related terms. The intent is to ensure that the term POSIX is used

46     in a useful and predictable manner in this guide.

47     As background, note that POSIX is sometimes used to denote the formal standard

48     ISO/IEC 9945-1 (64), sometimes to denote that standard plus related standards      F

49     and drafts emerging from IEEE PASC working groups (such as P1 003, P1 201,     1

50     P1224, P12278, P1387, etc.), and sometimes to denote the groups themselves. In   1

51     all those cases, POSIX is used as a noun.

52     This guide uses the term "POSIX" only as an adjective, and uses it-only in well

53     defined ways. This subclause serves as a preview of the usages in this guide of

54     POSIX terms. (These terms are defined, formally, or informally in subsequent

55     clauses, and the reader will be referred to those clauses as appropriate.)

56     This guide refers to the original POSIX standard by its standard designation,

57     ISO/EEC 9945-1 (64), and not by the term POSIX

58     The IEEE groups developing standards related to IEEE 1003 are called, in this         1

69     guide, IEEEPP1003.n working groups. Examples are the IEEE working groups     F

60     P1003.2, P1003., etc. The names of the groups are sometimes abbreviated              F

61    POSIX.2, POSIX.3, etc., but this convention is not used by this guide; confusion       F

62     could result when the PI 003 decimal number does not match the ISO/IEC 9945       F

63     Part number. Furthermore, there are other IEEE working groups, such as PI224, 2

64     that do not use the POSIX prefix. Therefore, aLL IEEE projects and working groups  F

66     are referred to uniformly as IEEE Pnnnn.                                                                    F

66     The standards emerging out of the POSix working groups are referred to by their

67     formal names (e.g., IEEE Std 1003.2-1992 OR p1003.2/D9) and_are..calLeJd .either  F

  1. POSIX base standards or POSIX SPs.
  2. 2.2.2 General Terms

70     For the purposes of this guide, the following definitions apply:                                         0

71     2.2.2.1 accredited standards development organization: An organization                 0

72     recognized as a standards development organization by ISO, EEC, ITU-T, or recog-     0

73     nized as a standards development organization by one of the member bodies of               0

74     one of these three organizations.                                                                                     0

75     2.2.2.2 application: The use of capabilities provided by an information system  
             1
76     specific to the satisfaction of a set of user requirements.

77     NOTE: These capabilities include hardware, software, and data.

78     2.2.2.3 application environment profile (AEP): A profile, specifying a com-                 0

79     plete and coherent specification of the Open System Environment (OSE), in which            0

80     the standards, options, and parameters chosen are necessary to support a class of             F

81     applications.

82     2.2.2.4 application platform: A set of resources, including hardware and                             0

83     software, that support the services on which application software will run.                           F

84    The application platform provides services at its interfaces that, as much as possi-

85    ble, make the specific characteristics of the platform transparent to the applica-                    0

86    tion software,                                                                                                                      0

87         2.2.2.5 application program interface (API): The interface between the

88     application software and the application platform, across which all services are                     2

89     provided.                                                                                                                            2

90     2.2.2.6 application software: Software that is specific to an application and is composed

91     of programs, data, and documentation.

92     2.2.2.7 base standard: An approved International Standard, Technical Report,                 0

93     ITU-T Recommendation, or National Standard,                                                                  1

94     2.2.2.8 communication interface: That part of the API devoted to communica-                F

95     tions with other application software, external data transport facilities, and                            F                        

96     devices.

97     2.2.2.9 communication services interface (CSI): The boundary across which                 1

98     access to services for interaction between internal application software entities                      l

99     and application platform external entities is provided,                                                           1  

100    2.2.2.10 component profile: A profile that is made up of a formally defined                      0

101     subset of a single standard.

102     2.2.2.11 cross-category services: A set of tools or features or both that has a                 l

103     direct effect on the operation of one or more components of the OSE, but is not in 

104     and of itself a stand-alone component.

105     2.2.2.12 emerging standard: A specification that is under consideration by a

106     accredited standards development organization, but that has not completed the                     0

107     process of approval by the sponsoring body.                                                                       F

107     Emerging standards are often subject to significant change prior to approval,                         F

108     2.2.2.13 external environment: A set of entities external to the application                        0

110     platform with which services are provided,                                                                            l

111     External entities include people, exchangeable media that is not mounted in the                      F

112     platform, communication wiring, and other platforms."                                                           0

113     2.2.2.14 external environment interface (EEI): The interface between the

114     application platform and the external environment across which services are pro-                  1

115     vided.                                                                                                                                 1

116     The EEI is defined primarily in support of system and application interoperability.

117     The primary services present at the EEI comprise

118     - Human/Computer Interaction Services

119     - Information Services 

120     - Communication Services

121     2.2.2.15 hardware: Physical equipment used in data processing as opposed to

122     programs, procedures, rules, and associated documentation.

123     2.2.2.16 harmonization: The process of ensuring that profiles do not overlap or                   1

124     conflict.                                                                                                                                1

125     2.2.2.17 human/computer mterface(HCI): The boundary across which physi-                   1

126     cal interaction between a human being and the application platform takes place.

127    2.2.2.18 information services interface. (ISI): The boundary across which                         1

128    external, persistent storage service is provided.                                                                       1

129    2.2.2.19 interface: A shared boundary between_twoJunctional entities.                                 1

130    A standard specifies the services^ in terms of the functional characteristics and                        0

131    behavior observed at the interface. The standard is a contract in the sense that it                      0

132    documents a mutual obligation between the service user and provider and assures                   0

133    stable definition of that obligation,                                                                                           0

134    2.2.2.20 intemationalization: The process of designing and developing an                                 0

135    implementation with a set of features, functions, and options intended to satisfy a                     1

136    variety of cultural environments. 

137    (See also localization in 2.2.2.26.)                                                                                        0        

138    2.2.2.21 interoperability: The ability of two or more systems to exchange infor-

139    mation and to mutually use the information that has been exchanged.

140    2.2.2.22 language-binding API specification: A specification that documents                     2

141    the source code method, consistent with a specific programming language, used by                 2

142    an application to access services provided by an application platform.                                     2

143    2.2.2.23 language-independent service specification: A specification that                         0

144    defines a set of required functional semantics independent of the syntax and                             0

145    semantics of a programming language,                                                                                     0

146    2.2.2.24 local adaptation: The process of modifying a product that is specific to                    0

147     one culture to make it specific to another culture, o

148     2.2.2.25 locale: The definition of the user environment that depends on 2

149     language and cultural conventions.

150     2.2.2.26 localization: The process of utilizing the intemationalization features

151     to adapt an internationalized product to a specific cultural environment, i

152     (See also intemationalization. in 2.2.2.20.) o

153    2.2.2.27 open_specifications: Specifications that are maintained by an organi-                        0

154    zation that uses an open, public consensus process to accommodate new technolo-                   0

155    166 2.2.2.28 open system; A system that implements sufficient open specifications                    0

157     or standards for interfaces, services, and supporting formats to enable properly                        0

158     engineered application software

159     To be ported with minima  changes across a wide range of systems from                                 1

160     one or more suppliers                                                                                                             1

161     - To interoperate with other applications on local and remote systems

162     - To interact with people in a style that facilitates "user portability                                             0

163     2.2.2.29 open system API: A combination of standards-based interfaces specify-

164     ing a complete interface between an application program and the underlying

165     application platform.

166     2.2.2.30 open system environment_(OSE); A comprehensive set of interfaces,                     0

167     services, and supporting formats, plus user aspects for interoperability or for por-

168     tability of applications, data, or people, as specified by information technology

169     standards and profiles.

170     2.2.2.31 operating system software: Application-independent software that                           0

171     supports "the running of application software and manages the resources of the                            F

172     application platform.                                                                                                                   F

173     2.2.2.32 performance: A measure of a computer system or subsystem to per-

174     form its functions; for example, response time, throughput, number of transac-

175     tions per second.

176     The efficiency of a system in accomplishing pieces of work is an attribute of per-                         0

177     formance.                                                                                                                                  0

178     2.2.2.33 performance requirement: A requirement that specifies a perfor-

179     mance characteristic that a system or system component must possess; for exam-

180     ple, speed, accuracy, frequency.

181     2.2.2.34 platform internal interface (PII): The interface between application                         0            

182     platform service components within that platform, o

183     2.2.2.35 platform profile: A profile whose focus is on functionality and inter-                          F

184     faces for a particular type of platform, which may be a single processor shared by                     0

185     a group of applications or a large distributed system with each application dedi-                         0

186     cated to a single processor,                                                                                                       0

187     2.2.2.36 portability (application software): The ease with which application                           l        

188     software and data can be transferred from one application platform to another.                          2

189     2.2.2.37 POSIX Standardized Profil PoSIX.Sp). A staridardized profile that

190     specifies the application of certain POSDC base standards in support of a class of

191     applications and need not require any departure from the structure defined by th                        0

192     reference model for POSDC systems in this guide,                                                                    0

193     2.2.2.38 process: An address space, anyone or more threas of control that exe-                      F 

194     cute within that address space, and their required system resources.                                          F

195     2.2.2.39 profile: A set of one or more base standards, and, where applicable, the                    l 

196     identification of chosen classes, subsets, options, and parameters of those base                         l

197     standards, necessary for accomplishing a particular function,                                                     l

198     2.2.2.40 programming language API specification: The interface between                         2

199     applications and application platforms traditionally associated with programming

200     language specifications, such as program control, math functions, string manipu-

201     lation, etc.

202     2.2.2.41 protocol: A set of semantic and syntactic rules that determine the                                F

203     behavior of entities that interact,                                                                                                 0

204     2.2.2.42 public specifications: Specifications that are available, without res-                               E

205     triction, to anyone for implementation, sublicensing, and distribution (i.e., sale) of                        0

206     that implementation,                                                                                                                  0

207     2.2.2.43 reference; model: A structured collection of concepts and their rela-                         0

208     tionships that scope a subject and enable the partitioning of the relationships into                         0

209     topics relevant to the overall subject and that can be expressed by a common                             0

210     means of description,                                                                                                                0

211     2.2.2.44 scalability: The ability to provide functionality up and down a gra-                             0

212     duated senei"of application platforms that differ in speed and capacity.                                        0

213     2.2.2.45 security: The protection of computer resources (e.g., hardware,                                    0

214     software, and data) from accidental, or .malicious access, use, modification, des-                        0

215     truction, or disclosure.

216     Tools for the maintenance of security are focused on availability, authentication,                          0

217     accountability, confidentiality, and integrity,                                                                                 0

218    2.2.2.46 service: A distinct part of the functionality that is provided by an                                  1

219     entity on one side of an interface to an entity on the other side of the interface,                             l

220     2.2.2.47 software: The programs, procedures, rules, and any associated docu-

221     mentation pertaining to the operation of an information processing system.                                   0

222     2.2.2.48 specification: A document that prescribes, in a complete, precise

223     verifiable manner, the requirements, design, behavior, or characteristics of a sys-

224     tern or system component.

225     2.2.2.49 standard:. A document, established by consensus and approved by an                         0

226     accredited standards development organization, that provides, for common and                           0

227     repeated use, rules, guidelines, or characteristics for activities or their results

228     aimed at the achievement of the optimum degree of order and consistency in a                             0 

229    given context                                                                                                                                0

230     2.2.2.50 standardized profile: A balloted, formal, harmonized document that 

231     specifies a profile.

232     2.2.2.51 standard development organization: An accredited organization                                 1

233     that formally develops and coordinates standards for use by a community,                                     1

234     2.2.2.52 thread: A single flow of control within a process.

235     2.2.2.53 transaction: A unit of work consisting of an arbitrary number of indivi-

236     dual operations all of which will either complete successfully or abort with no                                 F

237     effect on the intended resources.

238     A transaction has well defined boundaries. A transaction starts with a request

239     from the application program and either completes successfully (commits) or has

240     no effect (abort). Both the commit and abort signify a transaction completion.

241     2.2.2.54 validation: The process of testing an application or system to ensure                               0

242     that it conforms to its specification.

243     2.2.3 Abbreviations

244     For the purposes of this guide, the following abbreviations apply:

246     2.2.3.1 AEP: Application Environment Profile.                                                                              F

246     2.2.3.2 API: Application Program Interface.                                                                                 F

247     2.2.3.3 CSI: Communications Service Interface,                                                                            2

248     2.2.3.4 EEI: External Environment Interface.

249     2.2.3.5 HCI: Human/Computer Interface.                                                                                    2

ТЕКСТ:
находится в библиотеке Секции открытых систем Совета РАН "Научные телекоммуникации и
информационная инфраструктура"