only as a result of a connection request from TEPC. The effect on the ORMs of these operations lasts only as long as a connec- tion exists. The other operations can be used at any time when either the master or the slave detects faulty resources, or resources coming into operation again. How long the effect of these operations lasts is completely independent of how long a connection exists. This indicates that a single state space for both sets of operations will result in an unnecessarily complex state diagram. It is therefore wise to sepa- rate the handling of these two sets of operations, by defining two service objects in 6.2 A Service Network Modelling Case the interface between master and slave, one for each set of operations, see Fig. 6.31. Operations: cnuConnREQ cnuDiscORD CNPC, master CNPC, slave Proxy Proxy Event- object object Event- handling handling object object master slave State object State object Operations: devStateC_REP AccRoute CoreRoute blockDevORD AccRoute Manager Manager deblockDevORD Manager Controller AR1..AR3 SR1,IR1 AR4..AR6. Fig. 6.31 The AML state machine model, used for simplifying behaviour specifications This decision requires that a substructure is assigned to each distributed agent as well. The substructures suggested in Fig. 6.31 are basically the same for both agents, both based on the general state machine model defined by AML (this model is described in detail in Sect. 7.6). This model defines a standard object, the state object, that records every change in the object's state space. The remaining parts of the agent can thereby be separated into one part that handles the operations caused by TEPC request, and another part that handles the remaining operations. The former part consists of an event handling object and a proxy object; the latter is the ORM manager. An ORM manager records certain types of state changes that are reported by its peer object in its own state object. It can also detect such state changes in its own state object and report them to its peer ORM manage