stract object (AO). The model below shows such an interface between AM1 and AM2, based on three abstract objects. Object relation AOs exist conceptually inside an abstract machine in order to not reveal any- thing about their implementation (an AM that defines no AOs in a user-provider relation is equivalent to a single AO). AOs are only visible to a using AM through the interface that the providing AM offers. As an example, let's assume that AM2 is an abstract machine that can create connections (actually: connection endpoints). A created connection endpoint can be modeled as an AO on which operations such as send, receive and reset could be ordered. These operations are uniquely defined for the AO type "connection endpoint." The use of AOs affect the way an interface between AMs will look like and the way ASPs will be defined. Objects in general can be volatile, which means that the providing AM may have to offer special operations for object handling (such as createObject and deleteObject). Furthermore, the user of specific object operations must refer the identity of the object. A send event on a connection endpoint object will therefore be defined as connld-sendRequest(data), for example. In AMLs we say that an AM that knows the identity of an AO has an object relation to that AO. For volatile objects the object relation is an object identifier (the connid is such an identifier). For permanent AOs, the object identifier is replaced by the name of an object. The object relation concept allows us to create models of systems of communicating AOs, called (abstract) object structure, as exemplified in the model below. Provider interface interface 3 In Muth (2001) the terms "service object," "service relation" and "service network" are used instead of "abstract object," "object relation" and "object structure". We use the latter here in order to be more in line with current terminology. The notation used for AOs differ from AMs SO that an abstract machine system model and an object structure model will not be mixe