 "notification" in CMIP and the "event channel" in CORBA. A primary purpose of the operation classification system is to support modelling process control systems. The operation classes are therefore designed SO that they represent different levels of operation control. A designer of a process control system can for every operation choose if the user alone shall be in con- trol of when the operation is to be performed (choose REQUEST or ORDER), or if the provider alone takes the decision (choose C REPORT or U_REPORT) or if the responsibility is shared (choose INVITE or OFFER). In the last case the provider is responsible for detecting the need for performing an operation, but the user takes the final decision. This classification system is also designed SO that not only the sequence of events, but also the direction of events is given by the service network model and the operation class name. This improves the semantic information given by a serv- ice network and facilitates modelling. Provider callnfoReq callnfoCnf or callnfoRef setDateReq implies setDateCnf or setDateRef Provider applnfolnv Operations in CAS are: calinfoREQ, appInfoReq or appInfoRej setDateREQ, appInfoCnf or applnfoRef appInfoINV, sellWatchORD sellWatchOrd Fig. 7.30 Operation classes facilitate service network modelling 7 Concepts and Notations for Process Control Systems Modelling Figure 7.30 exemplifies this for the calendar service CAS. The model to the left is annotated with operation names and operation classes that imply the sequences shown to the right. 7.4.5 Operation Properties According to Fig. 7.22, an operation can be qualified with four types of properties, called EFFECT, SYNCH(-ronism), ATOM(-city) and DESTRUCT(-iveness). The table in Fig. 7.31 shows the applicability of these properties. Property Values Applicable on Remark Suggested operation class default modifier Changes service state initiator REQ, ORD Forces state change EFFECT modifier selector Provides service state info transformer Not state related synch REQ, OFF, INV SY