Section Six - OSI Realization 25. Overview This section describes how the MHS is realized by means of OSI. This section covers the following topics: a) Application service elements b) Application contexts 26. Application Service Elements This clause identifies the application service elements (.I.ab:ASEs;) that figure in the OSI realization of Message Handling. In OSI the communication capabilities of open systems are organized into groups of related capabilities called ASEs. The present clause reviews this concept from the OSI Reference Model, draws a distinction between symmetric and asymmetric ASEs, and introduces the ASEs defined for or supportive of Message Handling. Note Besides the ASEs discussed, the MHS relies upon the Directory Access Service Element defined in Recommendation X.519. However, since that ASE does not figure in the ACs for Message Handling (see Recommendation X.419), it is not discussed here. 26.1 The ASE Concept The ASE concept is illustrated in Figure 12/X.402, which depicts two communicating open systems. Only the OSI-related portions of the open systems, called AEs, are shown. Each AE comprises a UE and one or more ASEs. A UE represents the controlling or organizing portion of an AE which defines the open system's role (e.g., that of an MTA). An ASE represents one of the communication capability sets, or services (e.g., for message submission or transfer), that the UE requires to play its role. The relationship between two AEs in different open systems is called an application association. The ASEs in each open system communicate with their peer ASEs in the other open system via a presentation connection between them. That communication is what creates and sustains the relationship embodied in the application association. For several ASEs to be successfully combined in a single AE, they must be designed to coordinate their use of the application association. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ Figure .F.:12/X.402 The ASE Concept An ASE plays the largely mechanical role of translating requests and responses made by its UE to and from the form dictated by the application protocol that governs the ASE's interaction with its peer ASE in the open system to which the association connects it. The ASE realizes an abstract service, or a part thereof, for purposes of OSI communication (see Recommendation X.407). Note Strictly speaking, an open system's role is determined by the behavior of its application processes. In the Message Handling context an application process realizes a functional object of one of the types defined in clause 7. A UE in turn is one part of an application process. 26.2 Symmetric and Asymmetric ASEs The following two kinds of ASE, illustrated in Figure 13/X.402, can be distinguished: a) .I.gl:symmetric;: Said of an ASE by means of which a UE both supplies and consumes a service. The ASE for message transfer, e.g., is symmetric because both open systems, each of which embodies an MTA, offer and may consume the service of message transfer by means of it. b) .I.gl:asymmetric;: Said of an ASE by means of which a UE supplies or consumes a service, but not both, depending upon how the ASE is configured. The ASE for message delivery, e.g., is asymmetric because only the open system embodying an MTA offers the associated service and only the other open system, which embodies a UA or MS, consumes it. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ Figure .F.:13/X.402 Symmetric and Asymmetric ASEs With respect to a particular asymmetric ASE, one UE supplies a service which the other consumes. The ASEs co-located with the UEs assist in the service's supply and consumption. The resulting four roles are captured in Figure 14/X.402 and in the following terminology: a) x-.I.gl:supplying UE;: An application process that supplies the service represented by asymmetric ASE x. b) x-.I.gl:supplying ASE;: An asymmetric ASE x configured for co-location with an x-supplying-UE. c) x-.I.gl:consuming UE;: An application process that consumes the service represented by asymmetric ASE x. d) x-.I.gl:consuming ASE;: An asymmetric ASE x configured for co-location with an x-consuming-UE. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ Figure .F.:14/X.402 Terminology for Asymmetric ASEs As indicated, the four roles described above are defined relative to a particular ASE. When an AE comprises several asymmetric ASEs, these roles are assigned independently for each ASE. Thus, as shown in Figure 15/X.402, a single UE might serve as the consumer with respect to one ASE and as the supplier with respect to another. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ Figure .F.:15/X.402 Multiple Asymmetric ASEs 26.3 Message Handling ASEs The ASEs that provide the various Message Handling services are listed in the first column of Table 11/X.402. For each ASE listed, the second column indicates whether it is symmetric or asymmetric. The third column identifies the functional objects--UAs, MSs, MTAs, and AUs--that are associated with the ASE, either as consumer or as supplier. Table .T.:11/X.402 Message Handling ASEs +------+------+--------------------+ | | | Functional Objects | | | +--------------------+ | ASE | Form | UA MS MTA AU | +------+------+--------------------+ | MTSE | SY | - - CS - | +------+------+--------- ------------+ | MSSE | ASY | C CS S - | | MDSE | ASY | C C S - | | MRSE | ASY | C S - - | | MASE | ASY | C CS S - | +-- -----+------+--------------------+ +- Legend -------------------+ | SY symmetric C consumer | | ASY asymmetric S supplier | +----------------------------+ The Message Handling ASEs, summarized in the table, are individually introduced in the clauses below. Each is defined in Recommendation X.419. 26.3.1 Message Transfer The Message Transfer Service Element (.I.ab:MTSE;) is the means by which the transfer transmittal step is effected. 26.3.2 Message Submission The Message Submission Service Element (.I.ab:MSSE;) is the means by which the submission transmittal step is effected. 26.3.3 Message Delivery The Message Delivery Service Element (.I.ab:MDSE;) is the means by which the delivery transmittal step is effected. 26.3.4 Message Retrieval The Message Retrieval Service Element (.I.ab:MRSE;) is the means by which the retrieval transmittal step is effected. 26.3.5 Message Administration The Message Administration Service Element (.I.ab:MASE;) is the means by which a UA, MS, or MTA places on file with one another information that enables and controls their subsequent interaction by means of the MSSE, MDSE, MRSE, and MASE. 26.4 Supporting ASEs The general-purpose ASEs upon which Message Handling ASEs depend are listed in the first column of Table 12/X.402. For each listed ASE, the second column indicates whether it is symmetric or asymmetric. Table .T.:12/X.402 Supporting ASEs +------+------+ | ASE | Form | +------+------+ | ROSE | SY | | RTSE | SY | | ACSE | SY | +------+------+ +- Legend -------+ | SY symmetric | | ASY asymmetric | +----------------+ The supporting ASEs, summarized in the table, are individually introduced in the clauses below. 26.4.1 Remote Operations The Remote Operations Service Element (.I.ab:ROSE;) is the means by which the asymmetric Message Handling ASEs structure their request-response interactions between consuming and supplying open systems. The ROSE is defined in Recommendation X.219. 26.4.2 Reliable Transfer The Reliable Transfer Service Element (.I.ab:RTSE;) is the means by which various symmetri and asymmetric Message Handling ASEs convey information objects-- -especially large ones (e.g., facsimile messages)--between open systems so as to ensure their safe-storage at their destinations. The RTSE is defined in Recommendation X.218. 26.4.3 Association Control The Association Control Service Element (.I.ab:ACSE;) is the means by which all application associations between open systems are established, released, and in other respects managed. The ACSE is defined in Recommendation X.217. 27. Application Contexts In OSI the communication capabilities (i.e., ASEs) of two open systems are marshalled for a particular purpose by means of application contexts (.I.ab:ACs;). An AC is a detailed specification of the use of an association between two open systems, i.e., a protocol. An AC specifies how the association is to be established (e.g., what initialization parameters are to be exchanged), what ASEs are to engage in peer-to-peer communication over the association, what constraints (if any) are to be imposed upon their individual use of the association, whether the initiator or responder is the consumer of each asymmetric ASE, and how the association is to be released (e.g., what finalization parameters are to be exchanged). Every AC is named (by an ASN.1 Object Identifier). The initiator of an association indicates to the responder the AC that will govern the association's use by conveying the AC's name to it by means of the ACSE. An AC also identifies by name (an ASN.1 Object Identifier) the abstract syntaxes of the APDUs that an association may carry as a result of its use by the AC's ASEs. Conventionally one assigns a name to the set of APDUs associated either with each individual ASE or with the AC as a whole. The initiator of an association indicates to the responder the one or more abstract syntaxes associated with the AC by conveying their names to it via the ACSE. The abstract syntax of an APDU is its structure as an information object (e.g., an ASN.1 Set comprising an Integer command code and an IA5 String command argument). It is distinguished from the APDU's transfer syntax which is how the information object is represented for transmission between two open systems (e.g., one octet denoting an ASN.1 Set, followed by one octet giving the length of the Set, etc.). The ACs by means of which the various Message Handling services are provided are specified in Recommendation X.419. These protocols are known as .I.ab:P1;, .I.ab:P3;, and .I.ab:P7;. Note The nature of a message's content does not enter into the definition of Message Handling ACs because the content is encapsulated (as an Octet String) in the protocols by means of which it is conveyed.