e satisfied with a regu- latory function that allows the temperature to be changed occasionally, and that could be used for different types of fluids (having different heating characteristics). The model in Fig. 7.5 does not allow any of these properties to be changed, since they are recorded in the resource model and are not accessible from the outside. The solution to that problem is to make part of the resource model for the actor available to an outside user, as in Fig. 7.6. setTempORD setFluidCharORD Actor intEventC_REP Temp. Heater Sensor Heater sensor model model Fig. 7.6 An actor is normally a part of a virtual object or an agent The actor now becomes part of a substructure of a virtual object instead. When- ever a user requests change of temperature or fluid characteristics, the object that manages the resource model reports that to the actor by the operation intEventC_REP. The model in Fig. 7.6 is almost equivalent to the AML general state machine model, see Sect. 7.5.4. This model is based on separating the object's behaviour- 7.2 Concepts and Notations in Service Networks controlling logic from the data that defines the state of the object. An actor is there- fore also a natural specification element for the algorithmic part of a software unit. 7.2.2 Specialized Ports and Service Objects In order to simplify service network modelling, AML notation distinguishes between user-defined ports and AML-defined ports. AML provides generic solu- tions to the primitive services (service resource model, operation set and service behaviour) of AML-defined ports. For user-defined ports, the AML user must pro- vide the primitive service specification. To make models more expressive, AML also defines a few specialized port notations, see Fig. 7.7. User-defined ports AML-defined ports: user-defined connectivity encoding other service service service service services Specialized service objects: -integrator -connection endpoint -association handler data- object -connection controller handling -SAP-handler -association