. 7.9 Using the complex port symbol to simplify service network models To define complex objects and ports is purely a modelling option, with the sole purpose of simplifying service network models. Except that complex ports may be annotated with primitive service names and complex objects can be given names, no properties can be associated with complex objects, ports and relations. The unambiguous structure of a service network can only be visualized in terms of 7.2 Concepts and Notations in Service Networks primitive service objects and relations, which implies that complex entities in the model must first be expanded, see Fig. 7.9. In service network modelling, there are three cases where complex ports should always be defined, see Fig. 7.10. Relations between distributed agents: Master Slave Multiple primitive objects of the same type: Multiple access of a single primitive object: Fig. 7.10 Recommended use of complex relations The reason is that a complex relation in these cases also represent a natural boundary between abstract machines, i.e. indicates how the service network has to be mapped on the next integration level in the integration hierarchy. In relations between distributed agents, as was shown in Sect. 6.2.7 (see Fig. 6.32), the master and slave objects must be allocated in different abstract machines (and event handlers), since the complex relation will be part of a pro- tocol. When a service network comprises many primitive objects of the same type, all objects will most likely be implemented by the same abstract machine, which has a common object handling function When there are many users of a single primitive service object, the object may have to be placed in an abstract machine that has multiple access functions (e.g. atomic transaction features). 7.2.4 Substructure Relations A substructure relation associates two service ports that must be of the same type, i.e. either both provider ports or both user ports, see Fig. 7.11 Note that while serv- ice relations associate ports of different type