ding the ACSE standard: the rationale for handling process instances is explained as a mat- ter of being able to recover previous processes after an association breakdown. This is a matter of how to realize network reliability requirements in the software implementation domain, but it does not explain why AE instances must be referred as well. Thus, addressing and naming in ACSE is a complex matter and affected by the software engineering approach to the OSI upper layers. ACSE also reveals that the session and presentation layers represent an artificial division of a layer since the general transparency requirement for layers is completely abandoned in the OSI upper-layer architecture. A user element that uses ACSE must also deliver all pres- entation and session layer parameters as parameters of ACSE primitives. This approach not only excludes the possibility of replacing the presentation and session layers with other layers, it also increases the complexity of the ACSE interface considerably. 6.2.3 ROSE, the Remote Operation Service Element Besides ACSE, ROSE is the only general application service element (ASE) of interest in an application entity (AE). ROSE was later reused, extended, and modi- fied in the TCAP standard (see Sect. 6.3). ROSE is the OSI RM approach to remote operation handling, which in AMLn is defined through the meta-primitives I-invok- eReport and r-invokeOrder in SAGs, as described in Appendix B. If we would use ROSE in AMLn, a ROSE-ASE becomes a functional part of an agent in the AMLn common agent layer model. In Fig. 6.3 we have replaced the AMLn invokes with primitives defined by ROSE, in order to show the difference between ROSE primi- tives and AMLn meta-primitives. 6 Applying AMLn Common agent Remote op. remote operation protocol handling ROSE primitive names: AMLn meta-primitive names: RO-INVOKErequest r-invokeOrder(ex.: LSM request-event) RO-RESULTrequest r-invokeOrder(ex.: LSM confirm-event) RO-ERRORrequest r-invokeOrder(ex.: LSM refuse-event) RO-REJECT-Urequest r-invokeOrder(LSM 