|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.cplire.ru/rus/os/3_2/1.htm
Дата изменения: Tue Dec 21 21:30:46 1999 Дата индексирования: Tue Oct 2 05:30:31 2012 Кодировка: Windows-1251 |
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
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
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
ТЕКСТ:
находится в библиотеке Секции открытых
систем Совета РАН "Научные
телекоммуникации и
информационная инфраструктура"