1 Getting Service Engineering Right Next Generation Service Engineering Making the most of service models Rolv Bræk, Norwegian University of Science and Technology – NTNU, Department of Telematics NTNU, April 2008

2 Getting Service Engineering Right Overview Current Best Practice Trends and challenges Services and service models Semantic connectors Dynamic adaptation Next Generation Service Engineering

3 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 Distribution transparency and scalablility Platform layering with edges

4 Getting Service Engineering Right The SE Context How to support Rapid, Compositional, and Correct development with Dynamic deployment of Innovative Convergent Services?

5 Getting Service Engineering Right Trends Unification of underlying network technologies and computing platforms enabling network and service convergence. Diversification of services as well as equipments at the network edges. Shifting the business focus from connectivity and traffic to services and content Shifting the development focus from system design to service engineering and end user value

6 Getting Service Engineering Right Service engineering challenges From object orientation to service orientation: precise service modeling and service composition From network and platform focus to end-user focus From design time to run time composition and adaptation Supporting situation, personalization and policy

7 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

8 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.

9 Getting Service Engineering Right Active and passive services: Passive Services (Client-server) –One-way initiatives –A service as an interface –Synchronous communication –Restricted structure Active Services (Peer-to-peer) –Multi-way initiatives –A service as a collaboration –Asynchronous communication –General structure

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 Getting Service Engineering Right Service orientation: Introduce: service models service composition design synthesis and gain more: dynamics adaptability correctness S1 S3 S2 Design synthezis S1.1S2.1 S3.1S2.2 Program generation Services Designs Realizations

12 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. Notion of compatibility between roles and classes Enabler for service composition, semantic connectors with modular validation and dynamic actor composition Method for service modelling and composition r2 r3 r1 service 2 service 1

13 Getting Service Engineering Right Collaboration diagrams 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 Service roleA:TypeA roleC:TypeC roleB:TypeB session1: Session session2: Session session3: Session roleX roleY roleX roleY roleX roleY

14 Getting Service Engineering Right TaxiCentral Example (Exam 2007) Decomposition into interfaces and initiatives (features) op[n] Ii[m]ACD TaxiDispatch taxi[l] TaxiCentral line Interface taxi Interface taxi Dispatch operator Interface acdTd acdLiacdOp td li td taxi op

15 Getting Service Engineering Right taxiInterface defined using MSC or activity diagram Complete definition of intended behavior Coordination with other interfaces undefined Initiative choice (mixed initiative) to be resolved taxi td taxiInterface taxitd available tourOrder(TourInfo) confirm unavailable loop finished(tourInfo) alt pickup(tourInfo) msc taxiInterface available tourOrder pickup finished unavailable

16 Getting Service Engineering Right process taxi confirm none tourOrder(ti ) none DCL ti TourInfo; finished availableunavailabl e available pickup tourOrder(ti ) 3 pickup tourOrder(ti) available 1 pickup none confirm finished 4 unavailable 1 5 available 2 process td DCL ti TourInfo; pickup 4 taxi interface taxi td taxiInterface TaxiInterface defined using role state machines

17 Getting Service Engineering Right TeleConsultation Collaborative; Cross-cutting; Partial; Functionality Decomposition into interfaces and initiatives (features) Models one service individual

18 Getting Service Engineering Right Activity diagram for the global service behavior Activities correspond to collaboration uses Two users taking independent initiatives Roles not identified

19 Getting Service Engineering Right Choreography: Identifies roles and collaboration uses Complete definition of service behavior, not just use-cases and scenarios Finding realization problems by analyzing the composition and initiatives

20 Getting Service Engineering Right Analysing realizability Weak and strong sequencing: –Races –Coordination messages Choice and merge –Local choice –Non-local choice –Initiative choice Parallel fork and join Interruption

21 Getting Service Engineering Right Design issues Automatic synthesis of correct component design Composing actors having different role portfolios Coordinating multiple service and role instances S1 S3 S2 Design synthezis S1.1S2.1 S3.1S2.2 Services Designs

22 Getting Service Engineering Right System design Defining the actor structure Binding service roles Coordinating service and role invocation

23 Getting Service Engineering Right Coordination issues Multiple actor instances Multiple service types Multiple service instances Horizontal and vertical composition Coordination point: dynamic role binding Policies for flexibility and adaptation Utilizing semantic connectors for compatibility Lookup

24 Getting Service Engineering Right Service providers/agents: Have portfolio of provided services and roles Manages role invocation in response to Role request/Invite Enforces policies concerning: –situation –user preferences Ensures role compatibility a b c d... Service role portfolio Provider/agent preferences policies context situation local situation Rb2 Rc1 Rb1 Rc2 b c > Rd1Rd2 d

25 Getting Service Engineering Right Semantic connectors (Basic services) Two roles with Goals Static interface definitions Dynamic interface behavior modelchecked to ensure compatibility publishable using WSDL

26 Getting Service Engineering Right Semantic connectors in use Typing component interfaces with semantic connector roles Providing lean and strong compatibility assurance And meaningful lookup

27 Getting Service Engineering Right Ensuring compatibility Typing with semantic connector/basic service roles Formally verified and modelchecked Safe substitution

28 Getting Service Engineering Right Meaningful lookup Modelchecked collaborations Verified relationships Simple search Strong compatibility Run-time efficiency Registry

29 Getting Service Engineering Right tradeoff analysis and runtime decisions using GRL Goals, means and situation:

30 Getting Service Engineering Right Compositional adaptation by replacement and insertion > {when threat level = 0 or location = secure} or {when threat level > 0 or location not secure} Server Pull {when...} UTPA {when...} UoPA {when...} User Pull {when...} using policy rules evaluated by agents upon role requests

31 Getting Service Engineering Right New architectural opportunities Using semantic connectors (basic services) for: –Typing components –Ensuring compatibility –Meaningful lookup –Safe substitution Compositional adaptation to –Situation –User preferences using policy to direct: –Choreography choices –replacement –collaboration insertion

32 Getting Service Engineering Right Next Generation Service Engineering Analysing goals and strategies using GRL. Use cases and scenarios using UCM or AD Defining collaborations and analysing realizability Synthesizing designs Semantic connectors for lean, strong compatibility and meaningful lookup Collaboration replacement and insertion for compositional adaptation Situation, profile and policy for decisionmaking (Automatic composition for the future) ”bits in the SE puzzle coming together”

33 Getting Service Engineering Right Our approach in a nutshell terminals, appliances network nodes 1.Specify and validate services separately using UML 2.0 collaborations 2.Design components using UML 2.0 state machines and semantic interfaces 3.Automatically generate Java code with metadata 4.Dynamically deploy, discover and compose