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 4.6.3.1 Conventional Transaction Processing Reference Model A model for transaction processing is developed here to complement the POSIX system model. Current work in progress by the POSIX.11 Transaction Processing Working Group and other groups such as ISO/IEC JTC 1/SC21 Open Systems Interconnection--Distributed Transaction Processing may result in a Transaction Processing Reference Model more suitable than the one developed here. At that time, such a model will be referenced and incorporated into the POSIX OSE reference model. Until that time, the current model will be used as a convenient means for describing the services needed in this domain. While transaction processing services have usually been thought of as applying to databases, the applicability goes further. Nonetheless, the description given here of the transaction processing model shows how the transaction processing program can view the transaction services as an extension of the the Database view of the POSIX OSE reference model as shown in Figure 4-10. From the transaction application program point of view, a transaction processing system has additional capabilities that go beyond those provided by database systems. These services to the transaction application program are provided at an API that is called the _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r _A_P_I. (See Figure 4-13.) For convenience in discussing the model, the provider of those services is called the _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r (TM). _________________________________________________________________________ _________________________________________________________________________ Figure 4-13 - The Conventional Transaction Processing Model The transaction application program requests services provided by the _T_P _r_e_s_o_u_r_c_e _m_a_n_a_g_e_r2) (e.g., a database manager) via the _T_P _r_e_s_o_u_r_c_e _m_a_n_a_g_e_r Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Transaction Processing Services 121 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS _A_P_I. The transaction manager API and the TP resource manager API are called the _t_r_a_n_s_a_c_t_i_o_n _s_e_r_v_i_c_e_s _A_P_I and provide all the services needed by transaction application programs. The ACID properties are maintained for each managed resource by a _T_P _R_e_s_o_u_r_c_e _M_a_n_a_g_e_r (_T_P_R_M), coordinated by a _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r. The interface between the TP Resource Manager and the Transaction Manager will be called the _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r/_T_P _R_e_s_o_u_r_c_e _M_a_n_a_g_e_r _S_I_I (_T_M/_T_P_R_M _S_I_I). The ACID properties can be applied not only to resources such as databases, but also to other resources that might not be obvious. For instance, a transaction that dispenses cash may wait until the cash dispensing machine has signaled completion before considering the transaction complete and updating involved accounts. This illustration also shows the limits of transaction processing resource management. The machine could signal completion, but a mechanical problem could prevent the cash from being dispensed correctly, undetected by the system. Besides database TPRMs and miscellaneous nondatabase TPRMs, a third class of of TPRMs exist: Communications TPRMs (cTPRM). Services provided by cTPRMs are used when two cooperating transaction application programs need to communicate with each other in the context of the same transaction. At least two communications paradigms have been identified as beneficial to cooperating transaction applications programs: client/server (RPC, single request/response) and conversational (peer- to-peer, dialog). 4.6.3.2 POSIX OSE Reference Model (with Transaction Processing) The conventional transaction processing model is shown integrated into the POSIX OSE Reference Model in Figure 4-14. Because the POSIX OSE Reference Model does not address System Integration Interfaces (SIIs) per se, they are not shown in the integrated model. What is shown are the transaction processing services APIs and EEIs. __________ 2) The term ``TP resource manager'' should not be confused with a e different term, ``resource management services,'' which is a type of e service described in most service category classes in this section e (e.g., 4.6.4.3). e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 122 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 _________________________________________________________________________ _________________________________________________________________________ Figure 4-14 - POSIX OSE Transaction Processing Reference Model 4.6.3.3 Implementation Aspects e The POSIX OSE Reference Model does not provide for a way to expose the details of the Application Platform. System Internal Interfaces (SIIs) e are beyond the direct scope of this guide because they do not directly e affect application portability or system interoperability. In the e Transaction Processing world, as shown in the conventional Transaction Processing Reference Model (see 4.6.3.1), the existence of Transaction Managers and multiple TP Resource Managers connected by the TM/TPRM SII is important. One way to think about the real world implications of this is that TP Resource Managers and the Transaction Managers could both be implemented in the Application Platform as separate entities, connected to each other by the TM/TPRM SII. This does not, however, imply that the two must be implemented as separate entities, though there are advantages to the user if they are separate. NOTE: For application portability it is not required that the application platform actually consist of Transaction Managers and TP Resource Managers, but in the new age of Open Systems, there are clear advantages in doing so. Two advantages seem obvious: the ability to ``mix and match'' Transaction Managers and TP Resource Managers from different vendors; and the ability of a user to construct his/her own TP Resource Manager to manage particular critical resources. A market has Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Transaction Processing Services 123 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS already developed for ``plug compatible'' TMs and TPRMs. All TPRMs at this printing are Database type TPRMs. It is expected that a market will also develop for Communications type TPRMs. It is not at all clear that the industry will develop other types of widely applicable TPRMs, thus forcing users to develop their own. Users could use the interface described here to do such development work. This NOTE very briefly describes the services that should be provided at such an interface. The TM/TPRM interface must provide the ability of TMs and TPRMs to: register with each other; obtain recovery status information; pass along transaction identifier information; rollback, prepare to commit, and commit the transaction. The interface must provide for the needs of the full range of transaction processing including distributed transaction processing with multiple TPRMs. Finally it should be noted that the industry recognizes the need for standardization of components as well as the standardization of portability and interoperability. At least one industry group is standardizing and several vendors are implementing products utilizing an interface as described here. 4.6.4 Service Requirements Services provided via the Transaction Processing Services API are described in 4.6.4.1. Services to enable the distribution of transaction processing are described in 4.6.4.2. General services, mostly performing administrative functions, are described in 4.6.4.3. e 4.6.4.1 Application Program Interface Services e The Transaction Services API provides various services to the application programmer: Transaction Demarcation - Indicate the start of a transaction. - Indicate a transaction has ended successfully (commit) or unsuccessfully (rollback). - Indicate the beginning and ending of nested ``subtransactions'' whose commitment is independent of the ``parent transaction''. (Nested within a parent transaction can be multiple subtransactions. Subtransactions are independent of each other, Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 124 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 and whether subtransactions commit or not does not affect the commitment of the parent.) - Suspend and resume transaction mode (to do work which is not be committed or rolled back when the transaction is completed). This can be thought of as nesting nontransaction work within a transaction. e Communications Between Transaction Application Programs - Call another transaction application program (possibly remote) within the context of a transaction. - Open a dialog and send and receive ``messages'' to and from another transaction application program (possibly remote) within the context of a transaction. NOTE: The above services provide ``Distributed Transaction Processing.'' e Terminal Communications - Send and receive messages to and from terminals within the context of a transaction (i.e., messages sent to terminals are not to be actually delivered unless the transaction commits). Transaction Program Scheduling - Cause to be started another transaction application program outside of the context of this transaction. Involved here are two transactions: one starts the other. The actual scheduling of the second transaction can be dependent on the completion or not of the original transaction. Transaction Message Queuing - Define a ``message'' (based, possibly, on screen input from the end user) that, from the application point of view, precisely defines a unit of work to be done by this transaction or another transaction. - ``Send'' a message to another transaction application program. - Retrieve the next message (and then act upon it) - Prioritize and associate start times with messages Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Transaction Processing Services 125 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS NOTE: The actual handling of messages can be dependent on the completion or not of the original transaction. NOTE: Several of the above services are similar to but semantically different from similar sounding services in other clauses of this section. They are listed here because they are ``transactional''; i.e., the concept of a transaction and the ACID properties are provided by these services. TP Resource Managers provide services usable by the transaction application program and are made visible by the TP Resource Manager API. An example of this is the Database API services; see 4.4.4.1. e NOTE: TP Resource Managers, in general, ``protect'' a critical resource. e Databases are good examples of TP resource managers where the resource e actually being protected is the data, for example, of an enterprise. e Often the data of an enterprise reflects the amount of a real resource e such as cash holdings. In this case a tangible resource is indirectly e protected by a TP resource manager. The importance to the enterprise in e insuring that the data (quantifying money) is accurate should be obvious. e Other TP resource managers, on the other hand, could protect an actual, e tangible resource. An example of such a TP resource manager is the e program that controls the cash drawer of an automated teller machine. e The resource protected is the cash in the drawer. The actual application e program interface of the TP resource manager protecting that resource e could include the ability to reduce the amount of money in the drawer (by e pushing it out of the machine). A transaction application program using e two TP resource managers (a conventional database manager that keeps e track of the balance in accounts, and the teller machine's cash drawer TP e resource manager) would want to insure that the two TP resource managers e decrement both the cash and the balance of the correct account in the e context of a single transaction (i.e., with the ACID properties.) e The TP Resource Manager API, then, generally provides the following e services: e - Increment or decrement a valuable resource by a certain amount. e - Determine the amount of a valuable resource that remains. e Specific capabilities for the very wide variety of specific TP resource e managers, cannot, of course, be documented here. e 4.6.4.2 External Environment Interface Services e When two or more machines are involved in the same transaction, the e following service is required: e - The ability for two application platforms to interoperate with each e other (pass along global transaction identifiers, participate with e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 126 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 each other in commitment process, participate with each other in e recovery). e e 4.6.4.3 OLTP Resource Management Services The services listed in this subclause are not provided by application program interfaces or external environment interfaces. - Management Services -- Control the operation of the transaction processing services, including the ability to assign dispatching priorities to individual transaction application programs. - Monitoring Services -- Collect data on resource utilization for purposes such as performance analysis and accounting (data on utilization of the transaction processing services resources: processes, connection pools, ...). - Modeling Services -- Predict the system resources needed to process a given transaction processing workload. - Directory/Namespace Services -- Map names to addresses. - Recovery/Restart Services -- Recover and restart transactions involving one or more transaction application programs using one or more TP Resource Managers. - Test Services -- Automatically generate tests for workload simulation, etc. - System Configuration Services -- Replace or add transaction application programs without the need to shut down the execution environment. e 4.6.5 Standards, Specifications, and Gaps There are currently three transaction processing standards development activities, either completed or in the draft stage. Table 4-7 summarizes the service requirements provided by the various standards. Table 4-8 summarizes the applicability of the various standards to the various programming languages supported by the POSIX Open System Environment. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Transaction Processing Services 127 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS Table 4-7 - Transaction Processing Standards __________________________________________________________________________________________________________________________________________________ Service Type Specification Subclause e _________________________________________________________________________ e API Services E IEEE P1003.11 4.6.5.2 e ee EEI Services E ISO/IEC 10026-1, -2, -3 4.6.5.2 e ee Resource Management Services G - 4.6.5.3 e ee __________________________________________________________________________________________________________________________________________________ Table 4-8 - Transaction Processing Standards Language Bindings __________________________________________________________________________________________________________________________________________________ Standard LIS Ada APL BASIC C C++ e ________________________________________________________________________ e POSIX.11 E E e Standard COBOL C-LISP Fortran Pascal PL/1 Prolog e _________________________________________________________________________ e POSIX.11 e __________________________________________________________________________________________________________________________________________________ e NOTES: LIS -- Language-independent specification is available. e Ada, APL, BASIC, -- Language-dependent specifications exist. e S, E, G -- Standard, Emerging Standard, Gap e 4.6.5.1 Current Standards None. e 4.6.5.2 Emerging Standards _O_S_I__D_i_s_t_r_i_b_u_t_e_d__T_r_a_n_s_a_c_t_i_o_n__P_r_o_c_e_s_s_i_n_g__(_D_T_P_) ISO/IEC DIS 10026-1 ISO/IEC DIS 10026-2 ISO/IEC DIS 10026-3 These standards, developed by ISO/IEC JTC 1/SC21/WG5, deal expressly with the OSI services and protocols for transaction mode communications in an OSI environment. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 128 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 These standards provide for some of the communications services described in 4.6.4.1. _P_O_S_I_X_._1_1__P_O_S_I_X__T_r_a_n_s_a_c_t_i_o_n__P_r_o_c_e_s_s_i_n_g POSIX.11 The POSIX.11 working group, formed in 1989, is chartered to work on a profile for Transaction Processing within the POSIX OSE. In the process of developing that profile, it has identified a number of gaps in the standards coverage and is in the process of proposing base standardization activities to address those gaps. Specifically, P1003.11 is currently working on the following services identified earlier: - Transaction Manager (TM) Services provided at the Transaction API. - Services provided at the Transaction Manager/TP Resource Manager (TM/TPRM) SII. A typical TPRM is a database manager (e.g., SQL). POSIX.11 is working to assure that POSIX Transaction Processing work is consistent with the emerging work of OSI DTP (cited above), certain ongoing work of X/Open TP, several related POSIX activities (POSIX.1 {2}, POSIX.4, POSIX.8) and the work of ANSI X3T5.5 (RPC). 4.6.5.3 Gaps in Available Standards 4.6.5.3.1 Public Specifications Existing standards and emerging standards do not adequately address all the requirements identified earlier. While POSIX.11 is addressing some of the gaps, there are many other gaps still not being addressed by formal standards committees. Most notable is the work of X/Open TP. While not formally a standards making body, it is addressing most of the gaps, and its output will be potentially useful as the basis of a formal standard. _X_/_O_p_e_n__T_P This group published an ``Online Transaction Processing Reference Model'' in 1987 and in 1990 published ``Preliminary Specification--Distributed Transaction Processing: The XA Specification.'' The group is studying the use of OSI DTP, two-phase commit, and global transaction identifiers. The group is also actively exploring APIs in support of peer-to-peer distributed transactions. The work of this group addresses several of the services addressed in this clause, including transaction demarcation and conversation services. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Transaction Processing Services 129 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS Consideration is also being given to allowing alternative interoperability standards including proprietary mechanisms. Additional APIs are being defined by X/Open TP to facilitate this. 4.6.5.3.2 Unsatisfied Service Requirements Other than the work of X/Open TP, the following areas are not currently being addressed by standardization activities: communications, terminal communications, program scheduling, message queueing, management, monitoring, modeling, directory/namespace, recovery/restart, test, and system configuration. 4.6.6 POSIX OSE Cross-Category Services Not applicable. 4.6.7 Related Standards _C_C_R The following standards relating to commitment are related to the ISO/IEC DIS 10026 series and are referenced in DIS 10026: ISO/IEC DIS 9804-3 ISO/IEC DIS 9805-3 See 4.3 for more information. e _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 The following standards for SQL also provide transaction demarcation services for relational database access: ANSI X3.135.1 (ISO 9075, FIPS 127) ANSI X3.168 See 4.4 Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 130 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.7 Graphical Window System Services e _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _M_a_r_t_i _S_z_c_z_u_r _a_n_d _R_u_t_h _K_l_e_i_n _E_d_i_t_o_r'_s _N_o_t_e: _V_a_r_i_a_t_i_o_n_s _o_n _t_h_e _t_e_r_m ``_h_u_m_a_n _c_o_m_p_u_t_e_r _i_n_t_e_r_a_c_t_i_o_n'' _a_n_d _e _H_C_I _i_n _t_h_i_s _c_l_a_u_s_e _h_a_v_e _b_e_e_n _r_e_p_l_a_c_e_d _g_l_o_b_a_l_l_y _b_y ``_g_r_a_p_h_i_c_a_l _w_i_n_d_o_w _e _s_y_s_t_e_m_s'' _w_i_t_h_o_u_t _f_u_r_t_h_e_r _d_i_f_f _m_a_r_k_s. ``_H_u_m_a_n _u_s_e_r'' _h_a_s _a_l_s_o _b_e_e_n _e _r_e_p_l_a_c_e_d _b_y ``_u_s_e_r.'' _e 4.7.1 Overview and Rationale The graphical window system interface is a key component of computer e systems that support direct user-machine interaction. Until recently, e most computer operating systems interpreted commands that were typed in from the keyboard of an alphanumeric computer terminal. Special purpose applications, such as those for CAD/CAM, have always presented user interfaces based on series of menus or pointing at visual displays with tablets and lightpens. The availability of low-cost bitmapped graphic workstations and personal computers has led to the proliferation of graphical user interfaces (GUIs), windowing technologies, generic commands, and an assortment of selection techniques (e.g., mouse, track ball, tablets). In several of these technologies de facto standards are emerging and becoming informally accepted by the user community, and with more frequency, mandated for use in systems being developed within government agencies and private industry. The primary motivations for considering graphical window system standards and their relation to POSIX standards include: - The existence and popularity of windowing systems - The requirement for development of applications that take advantage of the windowing system environment - The requirement of many users and manufacturers for a basic consistency in the presentation and behavior of graphical window systems across multiple graphics platforms As the windowing system technology evolves within the graphics environment, the differences between windowing services and graphic services becomes less distinct. The distinction for purposes of this document is that graphic services are associated with providing general purpose interfaces for creating virtually any kind of two- and three- dimensional graphics (e.g., GKS for 2-D and PHIGS for 3-D). Graphical window system services certainly utilize graphic technologies, but are limited to providing graphics related to window-based user interfaces and specifications on how users may interact with an application within a window environment. The graphic services are addressed independently in 4.8. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 131 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS e 4.7.2 Scope Standards and standards initiatives in the graphical window system interface area cover a wide area, ranging from keyboard layout to screen management. In this clause, the following specific standards are considered: - Protocols for window management on a local or remote display device - Application Program Interfaces (API) for such protocols - Graphical window system drivability features that define a common subset of ``look and feel''; i.e., appearance, screen positioning, and behavior of graphical window system objects within windows on a graphic screen - Language-independent functional specifications and appropriate associated language bindings for the display, manipulation, and management of interaction objects within windows on a graphic screen - Command-language interfaces that may be entered interactively by the user or retrieved from a stored procedure. - Language-independent functional specifications and appropriate associated language bindings required to support character (non- bitmapped) terminals. - Language-independent functional specifications and appropriate associated language bindings for the translation, manipulation, and management of command statements (or messages). Standards relating to the following are not considered: - Graphics; see 4.8. - Keyboard layout (out of scope for graphical window system services) - Network transport protocols; see 4.3. - Hardware device interfaces (out of scope for graphical window system services) Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 132 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.7.3 Reference Model This subclause identifies the entities and interfaces specific to the construction of a graphical window system architecture. This architecture is consistent with, and extends the architecture of, Section 3. As illustrated in Figure 4-15, the interface components involved in the user interface process are divided into two groups, called the external environment interface (EEI) and the application program interface (API). _________________________________________________________________________ _________________________________________________________________________ Figure 4-15 - Windowing Reference Model The EEI is concerned with the communication with the user via the physical graphical window system devices (e.g., keyboard terminal, mouse, display screen). The applicable EEI standards are driven primarily in support of user and data portability across different application platforms. Standards and guidelines are intended to define a minimal set of commonality in graphical window systems, which will eliminate problem areas such as: Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 133 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - Error provoking inconsistencies - Misleading expectations about the results of user actions - Gross inconsistencies in the high level user model or metaphor - Incompatible motor control tendencies The drivability concept derives its name from the concept of ``driving'' an interface. A frequently cited analogy is the automobile. Having a standard location for the clutch, brake, accelerator pedals, ignition key, and steering wheel allows a driver to move between car models with relative ease (until he/she has to roll down the window, turn on the lights or windshield wipers!) Similarly, the EEI drivability guidelines will provide standards for graphical window systems that will ensure ease of moving between application platform models. For example, which mouse click causes an interaction object (e.g., radio button) to be selected or how a scroll bar should behave would be candidates for standard EEI specification. The API is concerned with the interface between the application semantics and the graphical window system services. It is the interface between the application software and the application platform and is defined primarily in support of application portability. These services provide functions for creation and manipulation of visual display objects such as menus, buttons, scrollbars, and dialog boxes. In addition, these functions allow information about user actions to flow back to the application software; for example, when the user has selected an item from a menu. This information about user actions is known as an event. Applications that require communication with the user are inherently event-driven. That is, associated with an application's dialog window (i.e., a window in which a user response is expected) is a main event loop waiting for the user to make a selection that will trigger an operation to be performed by the application. The API will support a specific user interface policy, which will define the application's ``look and feel.'' Although the specific look and feel need not be standard across application platforms (i.e., different implementations of the API may have unique styles) the API definition shall ensure that the application software can be ported across POSIX platforms; and the API shall support the EEI drivability guidelines, enabling users to easily operate the application across platforms. Elements of the graphical window system architecture are Application Software Elements, Application Program Interface (API) elements, and External Environment Interface (EEI) elements. These elements are linked by the use of common concepts and definitions associated with the graphical window system entities, interfaces, services, and standards. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 134 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.7.3.1 Application Software Elements Application Entity Elements include: (1) Window System Server The Window System Server provides a function that handles communication connections from clients, demultiplexes graphics requests onto the screens, and multiplexes input back to the appropriate client. Applications and other programs that use basic windowing services are called ``clients.'' Many clients may talk to the same server. All application requests to write to the screen must go through the server via the basic windowing services. The server is independent of operating system, programming languages, or network communication. (2) Window Manager A Window Manager provides a uniform method for manipulating windows, which includes a basic set of window management capabilities that allow for development of alternative and/or user-preferred window managers. Required graphical window system capabilities shall include, but are not limited to: - Resize window - Move window - Push/pop window to top/bottom - Shrink window to a reduced visual representation of window (i.e., frequently referred to as an icon of the window) (3) Local and Remote Applications These applications are clients that provide the functions required to perform the specific task(s) that the user needs to achieve (e.g., spreadsheets, scientific analysis systems, CASE tools, process and control tasks.) 4.7.3.2 Application Program Interface (API) Elements The API are language binding specifications that define the services available to the application programmer. API Elements are: basic window services, toolkit window services, and dialog services. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 135 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4.7.3.3 External Environment Interface (EEI) Elements The EEI elements are specifications (and in some cases, aspects of physical objects) that define how the application platform interacts with the external world. Note that application software, as defined here, interacts with the outside world only via the application platform. External Environment Interface Elements include: - Display Device Specifications - Data Protocol Format - User Drivability Guidelines (e.g., ``look and feel'' of window interface) - Keyboard Device Specification - Selection Device Specification (e.g., mouse, graphics tablet, touch screen) - Command-language Definition (syntax and semantics guidelines) 4.7.4 Service Requirements Graphical window system services provide a controlled interface between the application-specific software and the user-interface-specific software, allowing each to be designed and implemented separately. Users of these services include all POSIX system users and those charged with maintaining the processor and graphical window system communication. A common, standardized graphical window system for applications should be e available to users across all POSIX Open System Environments. Services shall support raster (i.e., bitmapped) graphics displays. Methods for supporting vector graphics displays can be addressed, but are not mandatory. 4.7.4.1 Application Program Interface Services Application services include those services made available to the application developer to separate the application functions from the graphical window system functions as much as possible. They include such areas as screen management, windowing, and user input device services. These standard services support requirements for application portability, software commonality, application interoperability and data communications transparency. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 136 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 A programmer may access the following services for an application via e language bindings. 4.7.4.1.1 Basic Window Services The basic window services, callable from client applications, support a window-based user interface. They should be based on a ``client-server'' model. The server is a program that handles communication connections from clients, demultiplexes graphics requests onto the screens, and multiplexes input back to the appropriate client. Many clients may talk to the same server. All application requests to write to the screen must go through the server via the basic windowing services. The major functional areas are: - Window Management - Presentation Management - Event Handling - Error Handling - Interclient Communications - Input Device Management: Keyboard, Pointing Device - Screen Management - User Preferences Management - Server Connection Management The following functions are available under each functional area. _W_i_n_d_o_w__M_a_n_a_g_e_m_e_n_t Functions available for Window Management are: - Create a window, map a window onto the screen, delete a window (includes support for character-based emulator window) - Manipulate a window (move, resize, change view precedence) - Manipulate window attributes (set, get, change; attributes may be related to appearance, redraw performance, event handling, or change authority) Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 137 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - Seize and relinquish control over the Server for display purposes (permits uninterrupted client output; output requests from other clients will be queued and displayed later) _P_r_e_s_e_n_t_a_t_i_o_n__M_a_n_a_g_e_m_e_n_t Functions available for Presentation Management are: - Associate data with a window (context manager functions and association table functions) - Manipulate the graphics context for a given object (create a graphics context, obtain current graphics context, change graphics context) e - Get and set fonts (load font, list fonts, unload font) e - Draw graphics primitives (draw arc, draw line, fill rectangle, clear rectangular window, clear entire window) e - Manipulate window cursors (create, destroy, assign, change) e - Draw text and obtain text metric information _E_v_e_n_t__H_a_n_d_l_i_n_g The basic window services support application requirements to respond to the user's actions, rather than forcing the user to respond to the application in a rigid, serialized manner. This requirement necessitates that a program either (1) be capable of handling any one of a number of events at any single point in time, or (2) attach a routine to each event to be called automatically when that event occurs. There is a separate set of events for each window used by the application. An application selects the events for a particular window, maps the selected events to the window, and reads events from the event queue as they occur. There are three major types of events: - Input device events (button press event, keypress event) e - Window management events (window exposure event, colormap event) e - Client message events (selection data transferred (by another application) event, private interclient communication event) e Functions available for Event Handling are: - Select events Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 138 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 - Map events to a window - Get information about events - Send events _E_r_r_o_r__H_a_n_d_l_i_n_g Functions available for Error Handling are: - Get error message - Get error description - Set error event handler routine _I_n_t_e_r_c_l_i_e_n_t__C_o_m_m_u_n_i_c_a_t_i_o_n The basic window services are required to be network transparent to an application or client. This means that an application on one host may write to the display screen connected to another host without being aware that networking is involved. The basic window services handle the network connections and follow the protocols necessary for the application to interact with the display. This convention allows redistribution of applications in a networked system with no effect on the application software. Therefore, an application client cannot assume that another client can open the same files or seize the same processing environment. Interclient communication via the server has three forms: - Properties Clients may associate arbitrary information with a window; generally used for communication between a client and the window manager. - Selections Selections are selected by the user out of one client's window, then ``sent'' to another client and displayed in the second client's window. - Cut Buffers Cut Buffers are a specialized form of communication. It is possible to receive notification when a cut buffer (property) is set. Functions available for Interclient Communication are: Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 139 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - Manipulate window properties (list, delete, change, get) e - Set and get selections - Manipulate cut buffers _I_n_p_u_t__D_e_v_i_c_e__M_a_n_a_g_e_m_e_n_t Functions available for Input Device Management are: - Receive keyboard input and pointing device button events - Gain exclusive control of keyboard or pointing cursor - Track the pointing cursor - Change Server-wide keyboard mappings - Set and get keyboard and pointing device preferences _S_c_r_e_e_n__M_a_n_a_g_e_m_e_n_t Functions available for Screen Management are: - Manipulate color using colormaps (copy, change, install, deinstall, get default) e - Get, display, and manipulate bitmapped screen images - Screen saver functions (blanking screen on idle) - Retrieve display information (default colormap, number of display planes, screen width and height) e _U_s_e_r__P_r_e_f_e_r_e_n_c_e_s__M_a_n_a_g_e_m_e_n_t The services and data structures used for managing user preferences are provided and collectively referred to as User Preferences Management. e There may be up to four sets of options that need to be read and merged: - The user's defaults stored in the root window's user resource manager property - The user's defaults stored in a user's defaults file - The application program's defaults - The command line arguments Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 140 4 POSIX Open System Environment Services