ere is no need to refer to activities. However, when implementing the provider, the model in Fig. 7.28 applies. The intuitive model in Fig. 7.28 includes the service resource model on which the primitive service CAS is based. The decisions taken by the OPH are based on the service state when an operation request is detected. The OPH will check if the state is such that the operation request can be accepted. The OPH may also choose between alternative activities, depending on the service state and on the outcome of a previous activity. As an effect of executing activities, the OPH might change the service state. Thus, the model gives an intuitive picture of a state machine. A for- mal model, the AML general state machine model (expressed as a generic sub- structure of service objects) is presented in Sect. 7.6. 7.4.4 Operation Class The Request-Confirm-Refuse pattern of three communication events is a pat- tern that is not specific for the operation calInfo, but can apply to a large range of operations. As a matter of fact, it is the dominating pattern of communication events for all operations in object-oriented methods. We have however already noticed that, in process control systems, there exist other, very general patterns as well, e.g.: Operations that are requested but no response is delivered. These types of opera- tions comprise a single communication event. Operations that (from the user's point of view) execute spontaneously, only giv- ing a response (e.g. alarms). These types of responses are called "notifications" in other contexts, and comprise a single communication event. 7.4 Elements of Interactions In telecom systems (as well as in database systems) there exist quite common patterns consisting of sequences of three communication events. For example, a call server might "offer" a called user a call, which the called user might "accept". The server contacts the calling user, who, however, got tired of wait- ing and disconnected in the meantime. In that case the server must return to the called user 