1. 1 Getting Service Engineering Right Global behaviours, services and sessions Rolv Bræk, Norwegian University of Science and Technology – NTNU, Department of Telematics NTNU, March 2011

2. 2 Getting Service Engineering Right Current Best Practice: Model Driven, Agent Oriented Design Architecture Active objects: UML, SDL State machines Asynchronous communication Agents reflecting the domain and the environment Focus on individuals Application generation by model transformations Realization Architecture Runtime support for the Design Architecture: Agents, State machines, messaging, timers, … Distribution transparency and scalablility Platform layering with edges

3. 3 Getting Service Engineering Right A design model defines a system as a structure of components with associated behaviour. This allows a complete and precise definition of behaviour. But the global behaviour is fragmented And the behaviour of different services is often combined

4. 4 Getting Service Engineering Right For global behaviors it is common to use interaction diagrams: ITU-T: MSC, HMSC UML: SD, IOD But there are problems: 1.Behaviors tend to be incomplete because too many orderings are possible 2.Distributed realizations may cause implied scenarios and other emergent behavior that must be resolved

5. 5 Getting Service Engineering Right Weak sequencing case Consider a direct realization of Z What problem may occur? How can it be fixed? a b ZYX MSC A c

6. 6 Getting Service Engineering Right we ask ourselves: How to best organize global behavior models? Are there alternatives to interaction diagrams? How to define services separately in a precise way so that they may be composed? How to derive design models from service models?

7. 7 Getting Service Engineering Right Answer: organize global behavior according to services and interfaces: Service models for: service specification service composition service analysis interface contracts design synthesis With added bonuses: Increased reuse Design correctness Interface validation Adaptability Modularity S1 S3 S2 Design synthezis S1.1S2.1 S3.1S2.2 Program generation Services Designs Realizations

8. 8 Getting Service Engineering Right What is a service? A service is: an identified functionality aiming to establish some goals/effects among collaborating entities. This definition is quite general and captures: active and passive services end user services service as layered functionality (ISO OSI) service as component interface (WS, CORBA, JINI, …) Service essentials: Service is functionality; it is behavior performed by entities. Service imply collaboration; it makes no sense to talk about service unless at least two entities collaborate. Service behavior is cross-cutting; it imply coordination of two or more entity behaviors Service behavior is partial; it is to be composed with other services

9. 9 Getting Service Engineering Right The nature of services A service is provided by several actors in collaboration: e.g. the agents representing users and terminals participating in a call. Actors may be involved in several services: e.g. a terminal may be engaged in a voice call and receiving SMS at the same time. A role is the part an actor plays in a service: e.g. the roles of caller and callee in a voice call. Roles are often bound dynamically: e.g. the callee role is dynamically bound to agents representing the called party. Neither services nor roles are simple components. Services are partial system behaviours involving one or more components, while roles are partial component behaviors.

10. 10 Getting Service Engineering Right Service engineering: is contemporary SOA or WS the solution? Only if passive services are all you need there is little need for stateful sessions you are not too worried about interoperability and performance you are happy to live in a concrete architecture Because these ”services” are essentially invocation interfaces bound to concrete components used for integration and distribution not for engineering end user and community services

11. 11 Getting Service Engineering Right Introducing UML 2 collaborations Matches the concept of services: Collaborative; Cross-cutting; Partial; Functionality Enable services to be defined separately in terms of role structures and behaviours. Enable flexible binding of roles to classes and allow classes to play several roles. Container for re-usable global behaviour Notion of compatibility between roles and classes Enabler for service composition, semantic connectors with modular validation and dynamic actor composition r2 r3 r1 service 2 service 1

12. 12 Getting Service Engineering Right 12 Collaboration diagrams Service roleA:TypeA roleC:TypeC roleB:TypeB session1: Session session2: Session session3: Session roleX roleY roleX roleY roleX roleY A collaboration with three roles and three collaboration uses: may define a service structure Session roleX:TypeX roleY:TypeY A collaboration with two roles: may define a semantic connector TypeA must be compatible with (the semantic interface) TypeX Compatibility means that the role behaviours must be contained in the total behaviour of the actor – how is a semantic variation point in UML2

13. 13 Getting Service Engineering Right 13 Behaviour can be in three places: –The collaboration itself –The roles –The context (scope) of the collaboration: Service roleA:typeA roleC:typeC roleB:typeB session1: Session session2: Session session3: Session roleXroleY roleX roleY roleX roleY sd 1 3 2 1 3 2

14. 14 Getting Service Engineering Right 14 How to model the service behaviour? A service is an identified (partial) functionality, provided by a system, component, or facility, to serve a purpose (or achieve a goal) for its (usage) environment. Languages: Interaction diagrams Activity diagrams Role state machines op[n] Ii[m]ACD TaxiDispatch taxi[l] TaxiCentral

15. 15 Getting Service Engineering Right What about this? acdOp available seize(caller) answer(op) end tourOrder(TourInfo) confirm acdLi Request answer(op) end queue(no) msc acd allocator alert(caller) queue(no)loop answer(op) available call(caller) grant(op) end alerting

16. 16 Getting Service Engineering Right Good global overview,... but : It is bound to the system, not reusable It is incomplete It is hard to define all possible scenarios What can we do?

17. 17 Getting Service Engineering Right Solutions: It is bound to the system, not reusable Bind to a collaboration in stead! It is incomplete, just one scenario It is hard to define all possible scenarios Decompose into collaborations corresponding to: Interfaces Sub-services Initiatives

18. 18 Getting Service Engineering Right The taxi central with interface collaborations op[n] Ii[m]ACD TaxiDispatch taxi[l] TaxiCentral line Interface taxi Interface taxi Dispatch operator Interface acdTd acdLiacdOp td li td taxi op

19. 19 Getting Service Engineering Right AcdInterfaces op acdOp operatorInterface ref msc operatorInterface opacdOp available call(caller) answer end loop tourOrder(TourInfo) confirm msc operatorInterface acdLi li lineInterface ref msc lineInterface acdLili alert(caller) alerting answer(op) loop alt answer(op) end queue(no) loop msc lineInterface

20. 20 Getting Service Engineering Right TaxiDispatch td acdTd taxiDispatch ref msc taxiDispatch tdacdTd tourOrder(TourInfo) confirm deny loop alt msc taxiDispatch TourInfo customer: String taxi: String pickup: Location start: Location drop: Location start: Time end: Time distance: Integer Location street: String number: Integer

21. 21 Getting Service Engineering Right taxiInterface: find-bind taxi to tour Here there is an initiative choice (mixed initiative) to be resolved taxi td taxiInterface taxitd available tourOrder(TourInfo) confirm unavailable loop finished(tourInfo) alt pickup(tourInfo) msc taxiInterface

22. 22 Getting Service Engineering Right The result: More complete behaviors Reusable building blocks Interface contracts for validation as a bonus But now we need a way to link the interface behaviors. How?

23. 23 Getting Service Engineering Right How to design and compose the roles? op[n] Ii[m] line Interface taxi Dispatch operator Interface acdTd acdLi acdOp td li op ACD TaxiDispatch acdTd acdOpacdLi ??

24. 24 Getting Service Engineering Right Role design Consider which roles should be active objects and which should just be partial behavior of other objects State-full roles imply a session and normally map to active objects Dynamic links imply dynamic role binding and normally requires an additional allocator Stateless roles do not imply a session and can map to operations performed by existing objects

25. 25 Getting Service Engineering Right The resulting ACD Operator sessions by op(1,m):OperatorAgt Line sessions by li(1,n):LineAgt Dynamic linking by Allocator Taxi dispatch operation by OperatorAgt

26. 26 Getting Service Engineering Right Completing the picture opacdOp available call(caller) answer en d loop confirm msc operatorInterface tourOrder(TourInfo) acdLili alert(caller) alerting answer(op) loop alt answer(op) end queue(no) loop msc lineInterface External interface to be respected Internal interactions to be added State machines to be designed External interface to be respected

27. 27 Getting Service Engineering Right What about Activity diagrams? 27

28. 28 Getting Service Engineering Right 28 The Access Control Activity Global activity flow Flows crossing partitions imply communication Exceptions not yet treated here An alternative to interaction diagrams Are they better or worse?

29. 29 Getting Service Engineering Right 29 Activity concepts Partition Action Flow Fork Choice Token flow semantics Flows may be control flows or object flows Only local actions in this diagram Partitions may represent roles

30. 30 Getting Service Engineering Right What if we use interface collaborations? 30

31. 31 Getting Service Engineering Right 31 Activity diagram with collaborations as actions Card Entry Authorize Validate Open Deny Accept PIN Entry panel userAgt Authenticator Authorizer Door 1.Can you add the flows and local actions? 2.Can you define each collaboration as an activity? 3.Where do we have sessions?

32. 32 Getting Service Engineering Right 32 Connecting roles using flows and local actions Card Entry Open panel userAgt Authenticator Authorizer Door 1.NB! pins have been omitted 2.What kind of pins are needed? StoreCID PIN Entry Deny Accept Validate Authorize Authent- icate Authorize Enter Card Enter PIN Deny- eject Pass- eject Open- close

33. 33 Getting Service Engineering Right 33 Streaming pins Card Entry Open panel userAgt Authenticator Authorizer Door 1.Use streaming when actions shall not be stopped StoreCID PIN Entry Deny Accept Validate Authorize Authent- icate Authorize Enter Card Enter PIN Deny- eject Pass- eject Open- close

34. 34 Getting Service Engineering Right 34 Sessions Card Entry Open panel userAgt Authenticator Authorizer Door 1.Each access point holds one session 2.Static binding – no allocators 3.Do we need sessions in AA? StoreCID PIN Entry Deny Accept Validate Authorize Authent- icate Authorize Enter Card Enter PIN Deny- eject Pass- eject Open- close

35. 35 Getting Service Engineering Right 1.AA combined to one component 2.Roles not shown here 3.Some external flows are missing in components Splitting/combining to components Card Entry panel userAgt AA-combined StoreCID PIN Entry Deny Accept Validate Authent- icate Authorize Enter Card Enter PIN Deny- eject Pass- eject Validate Open Door Open- close Open Card Entry PIN Entry Deny Accept

36. 36 Getting Service Engineering Right 1.Responding flows added to responding roles 2.Collaborations are kept as contracts Roles and responding flows panel userAgt StoreCID Enter Card Enter PIN Deny- eject Pass- eject Card Entry ceu Accept au Deny du PIN Entry peu Card Entry cep PIN Entry pep Deny dp Accept ap Validate vu Open ou

37. 37 Getting Service Engineering Right 1.Can you derive the state machines? 37 The two last components AA-combined Authent- icate Authorize Door Open- close Authenticate aa Open od

38. 38 Getting Service Engineering Right 38 Flow-global Activity diagram Useful for early analysis Focus on intended flows Can be refined to flow-localized flows Can be analyzed for implied scenarios

39. 39 Getting Service Engineering Right 39 Service behaviour A-rule: Service separation (new) Use layering to separate service behaviour from interface given behaviour A-rule: Service Collaborations (new) Use collaborations to structure service definitions. a:Authenticator b:Authorizer u:User d:Door User Access ua:UserAgent The system structure helps to identify service roles Services may need roles provided by additional system objects – to be determined during design

40. 40 Getting Service Engineering Right 40 Interface behaviour A-rule: Interface Collaborations (new) Use collaborations to structure interface definitions. A-rule: Message Sequence Charts Make message sequence charts that describe the typical interaction sequences (protocols) at each layer of the interfaces. p:Panel u:User PanelInterface PanelUser Code OK Push door MSC User_accepted

41. 41 Getting Service Engineering Right 41 Role behaviours and Semantic Interfaces A-rule: Role behaviour Define the interface behaviour of each role in the system and in the environment. Use the roles as basis for behaviour synthesis and validation. A-rule: Semantic Interfaces (new) Use collaborations to structure and define semantic interfaces. p:Panel u:User PanelInterface

42. 42 Getting Service Engineering Right Role state machine for taxi interface taxi td taxiInterface taxitd available tourOrder(TourInfo) confirm unavailable loop finished(tourInfo) alt pickup(tourInfo) msc taxiInterface tourOrder(ti) available 1 pickup 432 none confirmfinished 4 unavailable 15 available 2 process td DCL ti TourInfo;

43. 43 Getting Service Engineering Right process taxi confirm none 1 33 2 tourOrder(ti ) none 1 5 2 DCL ti TourInfo; finished availableunavailabl e available pickup tourOrder(ti ) 3 pickup tourOrder(ti) available 1 pickup 4 3 2 none confirm finished 4 unavailable 1 5 available 2 process td DCL ti TourInfo; pickup 4 taxi td taxiInterface A Semantic Interface: TaxiInterface defined using dual role state machines here with resolution of mixed initiative

44. 44 Getting Service Engineering Right Dynamic sessions: Call handling ua:UserAllo us:UserServ u(n):UserAgent ua:UserAllo us:UserServ u(n):UserAgent a:Terminal b:Terminal Sessions handled by session role objects Dynamic linking handled by Allocators Allocators trigger session role objects Depending on state and context the allocator may trigger alternative role objects, e.g. call-waiting, forward, call-back when free

45. 45 Getting Service Engineering Right Dynamic sessions: ACD Operator sessions by op(1,m):OperatorAgt Line sessions by li(1,n):LineAgt Dynamic linking by Allocator Taxi dispatch operation by OperatorAgt

46. 46 Getting Service Engineering Right Dynamic Sessions: The Treasure Hunt

47. 47 Getting Service Engineering Right Dynamic sessions: The Treasure Hunt system

48. 48 Getting Service Engineering Right User agents on Android phones