a general way. When service objects become integrated in abstract machines, port objects become an integrated part of the operation handler (OPH) function of an abstract machine, see Sect. 5.4.2. A port object has access to all information that is specified as part of an opera- tion specification, i.e. the ASPs, operation type information and timing properties. In service networks we can also assume that all events that a port object detects (and generates) are valid events. This is because the message-handling function of the protocol network in which the service object exists ensures that only valid oper- ations, primitive types and parameter values are referred. The functions of a port object are: 7.6 The General State Machine Model Both provider an user port objects detect external events and, if correct and if a modifier operation, send all information to the event object in the primitive devRepCnf. They also generate external events that are ordered by the event object through gevOrd. Provider port objects are responsible for the execution of operations of type selector, i.e. operations that cannot change the state of the object, even if the operation succeeds. These operations need not concern the event object. The port object uses the operation queryREQ (provided by the state object) to per- form selector operations. Provider port objects also provide existence control on those parameters of events that are defined as entity identifiers (#) in the resource model (see the scenario for existence control at the end of this section). For this it uses the oper- ation existsREQ, also offered by the state object. Both provider and user port objects may supervise time constraints and activity time, if relevant for the operation. The state object stores the compiled state vector. Its functions are: To change state when a postOrder(<postcondition>) is detected from the event object. To respond to a preRequest(<precondition>) from the event object by verifying that the actual state lies within the subset of states t