mitive if the opera- tion was successfully executed, otherwise with a Refuse primitive. chAddrREQ Provider service service object object Event handler chAddrReq(person, addrPar) Concrete object chAddrCnf(person) chAddrRef(person, cause) addrMod(inout person PersType, gevOrd(locInvId, {chAddr}, {request}, person, addrPar) in addrPar AddrParType, devRepCnf(locInvid, {chAddr}, {confirm}, person) in value ValueType; devRepCnf(locInvId, {chAddr}, {refuse}, person, cause) out resp RespType) Fig. 5.23 Operation-handling scenario 1. The concrete object executes a procedure call in some concrete language: addr- Mod is a local name for the call; person, addrPar, etc. are local variable names. PersType, AddrParType, etc. are data types of the actual concrete language. 2. This call is taken care of by the OPH. OPH has access to a description of the remote operation, which is part of an abstract protocol. The operation name defined as chAddr in the protocol. In this protocol the abstract service primitives (ASP) of the operation chAddr are described. The parameters that are given in the procedure call are distributed to a Request ASP, a Confirm ASP and a Refuse ASP. Note that all the ASP names are constructed by the same operation name, concatenated with the primitive type. In the ASP specifications, the parameters are defined by the identifiers person, addrPar and cause. 5 Protocol Network Modelling 3. In the interface towards the format handler (FOH), OPH uses (conceptual) gev operations for sending ASP data, and dev operations for receiving. The parame- ters of these operations consists of a local invocation identifier (LocInvId) and a set of parameters. The LocInvId is needed by the OPH to connect a response to the corresponding invocation in the case of an abstract protocol that defines asynchronous operations. Remaining parameters of dev and gev are one value for operation identity, one for primitive type and one for each ASP parameter. For example, {chAddr} is the value that identifies the operation chAddr and per- son