ocol describes all aspects of the dialogue between the enti- ties, which comprises three things: It defines the messages of the dialogue. It describes the sequences of messages that are allowed, i.e. the dialogue struc- ture. It describes how instances of messages shall be encoded into bits of the data flow. However, it is always advantageous to further refine the properties of messages into their form and meaning. The form is given by its information structure and encoding, the meaning by how a message is interpreted by the party who creates it and the party who reacts to it. The distinction between form and meaning is built into the architectural principles of SM as the distinction between message protocol and abstract protocol. Figure 2.17 shows this distinction. message protocol abstract protocol message handling protocol Fig. 2.17 Refinement of a message protocol into an abstract protocol and message handling proto- Logically, the form of messages is handled by a generic unit called MEH (mes- sage handler), and the meaning by the generic unit EVH (event handler); more about these units in Sect. 2.3.7. The model in Fig. 2.17 says that EVHs need not deal with formatting and encoding issues for message handling. Communication between EVHs can be described in a much simpler way than for message proto- cols. We therefore give the description of the dialogue between EVHs another 2.3 Architectural Principles name: abstract protocol. The interaction elements of an abstract protocol are com- munication events that refer operations (communication events are instances of ASPs). Figure 2.18 provides an example of the distinction between a communica- tion event and a corresponding message. connectRequest(a),(b)) {{OPid connect},{PrimType Request}, {SAPI a}, {SAPI b},Ovh}} Fig. 2.18 Events and messages The event connectRequest({a},{ {b}) might be an event in a resource control (abstract) protocol. The event is initiated by the EVH to the left and detected by the EVH to the right. The event description reflects the meaning