ions io1 and io2 that are offered by C, io3 that is offered by D, etc. Thus, a transaction specification defines how an eo is mapped on internal serv- ice elements and operations. If, for some reason, the internal structure becomes modified, it will affect the algorithm but not the external OPH. If the external pro- tocol becomes modified, one knows exactly which algorithm in the internal OPH defines the mapping, and thereby also which internal service elements may be con- cerned. In conclusion: Isolating protocol conversion functions in a transaction han- 5.6 Relaying in Protocol Networks dler in the master is a productive architectural approach to functional requirement tracing and mapping. A transaction handler can be defined as a pure protocol converter between exter- nal and internal operations, or it can be defined as an agent that takes responsibility for the state of the transaction in the external interface. A master that operates between different physical network levels (as the case modelled in Fig. 5.43) may leave to the internal service elements to control the state of transactions, which means that state control is distributed amongst a number of internal elements. This is quite efficient with respect to response time in the external interface, but it also means that there is no single unit in the structure that has full control of the transaction state. If the mapping between the transaction state and the internal states of service elements is not well understood (often it is not), modifications of the external protocol may lead to implementation difficul- ties. An agent acts as a service object in the external interface, which means it main- tains state information regarding the transaction. If internal service elements are also defined as service objects, state translation between the transaction state and the state of internal objects can be formally defined, using the AML method for defining an abstraction hierarchy for service network (see Sect 6.2.2). This method is based on modelling the sta