), repRef(9)} Opid ::= INTEGER{callnfo(0),setDate(1),applnfo(2),selWatch(3),spare(4..63) Operation specification for setDate: Operation specification for callnfo: OPERATION callnfo Request (INTEGER{time(0), day(1), date(2)} DEFAULT 0) Confirm (CHOICE{[0]Time, [1]DayInWeek, [2]Date}) Time::=SEQUENCE{hour INTEGER SIZE (0..24), ".", minute INTEGER SIZE (0..60) OPTIONAL) DayInWeek::=IA5String{"Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"} Date::=SEQUENCE{Month, "/", DayInMonth} Month::=IA5String{"January", "February" "December"} DaylnMonth::=INTEGER SIZE (1..31) Refuse (cause INTEGER{watchBroken(0), noWatch(1)) Fig. 7.27 Primitive service specifications comprise operation specifications; operation specifica- tions define ASPs 7.4 Elements of Interactions 7.4.3 Operation and Activity The operation name calInfo in the communication event calInfoRequest(time) tells the CAS provider what is expected of him. Obviously, there are numerous ways in which the provider could fulfil this request (which is to return the actual time). The actions of the provider in order to provide the answer is an activity. An intuitive picture of how a provider works is given in Fig. 7.28. Operations in CAS are: calinfo, setDate, applnfo, sellWatch Activities for callnfo: activity for applnfo (otherMethod activity for askSomebody setDate activity for lookAtWatch sellWatch Service Operation Resource Handler Model Fig. 7.28 An intuitive model of a virtual object The model in Fig. 7.28 says that the function of any object should be separated between an operation handler and a number of activities. There exists an activity for most operations. For some operations there might also exist alternative activi- ties. The relation between operations and activities is held by the operation handler (OPH). This has the effect that the user need not to know what the activities are, and an activity need not know how it is referred to by users. One possible activity which will satisfy the calInfoRequest(time) is to read a watch (a