Better to know some
... than all
Common Application Service Elements
The Association Control Service Element (ACSE) is used by every application entity. It provides a set of functions for managing the association between peer application entities. Since managing an association is independent of the activities the association is used for, ACSE serves as an appropriate and highly useful standard.
An association is established using the A-ASSOCIATE service primitive. This maps to the P-CONNECT primitive and hence also establishes a corresponding presentation connection. The application context and the abstract syntaxes are also conveyed during this process. The A-RELEASE primitive maps to P-RELEASE and handles the orderly release of an association as well as the release of the corresponding presentation connection after ensuring that all data in transit has been delivered. Error-initiated releases are managed by A-ABORT and A-P-ABORT which, respectively, map to and are similar to P-U-ABORT and P-P-ABORT . The ACSE service primitives are implemented as Application Protocol Data Units (APDUs). Each of these represents a unique application-wide type and is tagged accordingly.
The Reliable Transfer Service Element (RTSE) hides much of the underlying complexity of the session dialogue management services by providing high-level error handling capabilities to other ASEs for data transfer. RTSE segments a data transfer APDU into smaller PDUs, each of which is marked by a confirmed minor synchronization point. The transfer of an APDU is managed as one session activity. RTSE uses the ACSE to establish an association: its RT-OPEN service primitive maps to the A-ASSOCIATE primitive. RT-TRANSFER is a confirmed primitive and manages the transfer of an APDU as segments. It maps to a sequence of PACTIVITY, P-DATA and P-SYNC-MINOR primitives. RT-CLOSE maps to ARELEASE and gracefully terminates the transfer. In case of errors, RTSE provides appropriate recovery procedures. When possible, a transfer activity which has been disrupted by an error is restarted; otherwise, it is entirely repeated.
The Remote Operations Service Element (ROSE) serves the needs of distributed applications in invoking remote operations. An example is an application which requires access to a remote database. ROSE enables a requester AE to submit an operation to a replier AE, then waits for a response, and finally delivers the response to the application. The response may indicate the result of successful completion of the operation, an error condition, or complete rejection of the operation. ROSE supports two modes of operation:
(i) synchronous, whereby the requester AE waits for a result before submitting the next operation.
(ii) asynchronous, whereby the requester may submit further operations before waiting for earlier ones to be completed.
ROSE provides a remote operation notation which other ASEs may use to define their operation interface. The ROSE protocol specifies how its four APDUs are transferred using the presentation service (which maps them to P-DATA primitives) or the RTSE service (which maps them to RT-TRANSFER primitives).