a functional part of an agent in the AMLn common agent layer model. In Fig. 6.2 we have replaced the AMLn associ- ation-handling function (as described in Sect. 2.3.2.3) with an ACSE to show the similarities between association primitives defined in a specified agent interface (SAG), with association primitives that ACSE defines. 6 Applying AMLn Common agent Association association protocol handling Actor that belongs to ACSE primitive names: AMLn primitive names: actor layer 1 (ALi=1) and A-ASSOCIATErequest has the identity 2 (As=2) acAssRequest in that layer A-ASSOCIATEconfirmation acAssConfirm A-ASSOCIATEconfirmation acAssRefuse A-ASSOCIATEindication agAssOffer A-ASSOCIATEresponse agAssAccept A-ASSOCIATEresponse agAssReject A-RELEASErequest acRelOrder A-RELEASEindication agRelReport A-RELEASEresponse A-RELEASEconfirmation A-P-ABORTindication agRelReport Fig. 6.2 ACSE primitives, compared to AMLn association primitives ACSE and AMLn association operations have similar purposes. The difference in number of primitives and primitive names lies primarily in the way AMLs and OSI looks at the operation concept: 1. In OSI, operations are always some kind of global functions. For example, the operation A-ASSOCIATE extends between two remote actor-agent interfaces and is defined through four primitive types (request, indication, response, and confirmation). AMLs operations, on the other hand, are always bound to a single interface type. Therefore the ACSE operation A-ASSOCIATE is broken up in two operations in AMLn: acAss (request, confirm and refuse) and agAss (offer, accept and reject). 2. The difference in names of primitive types indicate the difference in operation classes in AMLs and OSI RM. An important difference is that AMLs always makes a distinction between positive and negative outcomes of a request, in order to provide better semantics for behavior descriptions. OSI does not, which is a typical software language approach to remote operations. An example is the ACSE primitive A-ASSOCIATEconfirmation in Fig. 