Science and Technology Norwegian University of NTNU Rolv Bræk, April Compositional and Model Driven Service Engineering using semantic interfaces Rolv Bræk, with friends The Norwegian University of Science and Technology – NTNU Department of Telematics

Science and Technology Norwegian University of NTNU Rolv Bræk, April The challenge How to support Rapid, Compositional, and Correct development with Dynamic deployment of Innovative Convergent Services?

Science and Technology Norwegian University of NTNU Rolv Bræk, April The nature of services: Client-server (traditional O-O and IS) One-way initiatives A service as an interface Synchronous communication Restricted structure Peer-to-peer (telecom and real-time) Multi-way initiatives A service as a collaboration Asynchronous communication General structure We focus on P2P and consider CS a special case

Science and Technology Norwegian University of NTNU Rolv Bræk, April Services, Roles and Actors A service is a collaboration among several actors: e.g. call Actors may be involved in several services: e.g. call1, call2, … A role is the part an actor plays in a service: e.g. caller, callee Roles are often bound dynamically: e.g. callee Neither services nor roles are simple components Need to: 1. model services separately using roles; 2. design actor classes by composing roles; 3. dynamically deploy and compose actors Service 1 Actor 1 Actor 2 Actor 3 Actor 4 Actor 5 Service 3 Service 2 “Vertical” composition (within an actor) “Horizontal” composition (within a service)

Science and Technology Norwegian University of NTNU Rolv Bræk, April Introducing UML 2 collaborations Matches the concept of Peer-to-Peer services (P2P). 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 is ”semantic variation” point. Enabler for service composition, semantic interfaces with modular validation and dynamic actor composition Method for service modelling and composition is under way. r2 r3 r1 service 2 service 1

Science and Technology Norwegian University of NTNU Rolv Bræk, April Sixth principle: services as collaborations with: goal expressions for liveness behaviour specified using MSC and state machines features represented by collaboration uses role behaviour designed as actor state machines a:Callerb:Callee invite:Role Request c:Calling b:Busy u:Unavailable b:Called Agent requester requested invoked ab b b a a UserCall {goal: VoiceCnt(a,b) = a.VoiceCntTo(b) AND b.VoiceCntTo(a)}

Science and Technology Norwegian University of NTNU Rolv Bræk, April FullCall at:Term Caller bt:Term Callee au:User Caller bu:User Callee uc:UserCall o:TermCall t:TermCall P1 P2 P3 P4P5P6P7P8 bt:Term Callee at:Term Caller au:User Caller bu:User Callee uc:UserCall o:TermCall t:TermCall fcx:FullCall P1’+P2’+P3’...+P8’ at:Term Agent au:User Agent bu:User Agent bt:Term Agent P12 P11 P10 P13 collaborations agents... and roles/actors bound to agents Actors as service components (provide roles) Actors for separate services and sessions

Science and Technology Norwegian University of NTNU Rolv Bræk, April Fifth principle: component based framework with loose coupling - Actors and Agents Agent identity: credentials: profile:

Science and Technology Norwegian University of NTNU Rolv Bræk, April with platform adaptors and edges AmigosFramework Kari: UserAgent Ola: UserAgent Mp1: MeetingPlace t1: TermAgent t2: TermAgent Mp2: MeetingPlace tlogonulogontchat mpcalluchat mpchat tcall ucall OSA FW OSA CallC call Service Platform Specific Computing Platform Specific Platform indenpendent Edge

Science and Technology Norwegian University of NTNU Rolv Bræk, April and distribution transparency Freedom to deploy actors on small devices and servers Global address space and transparent messaging Simple configuration, but not yet self-configuring Application Server edge Terminal/appliance edge Application Server edge Terminal/appliance edge

Science and Technology Norwegian University of NTNU Rolv Bræk, April Composition aspects: Actor implementation with metadata Service models: Collaborations with behaviour r2 r3 r1 > Service ececution environment design composition dynamic deployment Actor design with semantic interfaces (Automatic) code generation dynamic structure with dynamic discovery and composition collaboration (service feature) composition design composition - synthesising behaviours and defining actor types w. semantic interfaces managing dynamic role invocation metadata and ontology for dynamic systems dynamic deployment discovery, selection and negotiation

Science and Technology Norwegian University of NTNU Rolv Bræk, April Compatibility and interface roles Interface roles are ”projected and distilled” behaviours visible on interfaces, or associations. Given two state machines A and B: 1.Derive the interface role behaviours Project: hide and transform Distill: gather, minimize and merge Detect inconsistencies 2.Correct inconsistencies and repeat from 1 3.Validate role compatibility A B 1a 1b session

Science and Technology Norwegian University of NTNU Rolv Bræk, April Dual roles are fully compatible a-roles: 1.iff the original state machine is consistent, then the dual a-role may be constructed, 2.and used to discover, compare and select compatible services, 3.and to partially synthesise state machines. A 1a 1b 2 session B 1c C 1d 1 2 D 1b 2b 3b

Science and Technology Norwegian University of NTNU Rolv Bræk, April Compatibility in collaboration occurrences Assume a collaboration with dual roles A and B. For each potential participant class: 1.Derive a-role 2.Ensure s-role consistency 3.Compare a-roles, select Ai, Bj such that: Ai ~> A and Bj ~> B and if restriction has been applied that Ai-Bj satisfies obligation and collaboration goals. Subtyping can be checked once for each participant type. Goal reachability can be checked once for each pair Ai, Bj of participant types. Need not be repeated for each instance. Note that the collaboration will be restricted only if the subtypes are restricted. Class_A1 S-roleA Class_B2 S-roleB service-a B A a Class_A2 S-roleA Class_B1 S-roleB b A2 A1 B1 B

Science and Technology Norwegian University of NTNU Rolv Bræk, April A-roles and collaborations as semantic interface types... a basis for incremental and scalable compatibility checks... as well as for service discovery and service selection. If Class_A is typed with Call.a (alternatively by A alone) and Class_B is typed with Call.b (alternatively by B alone) Consistency of links can be checked statically and Service opportunities discovered and selected dynamically A B Call a b Class_A S-roleA Call B A 1 a Class_B Call S-roleB B A 1 b X:Class_A 1 y:Class_B 1

Science and Technology Norwegian University of NTNU Rolv Bræk, April Interface Typing by Semantic Interfaces to enable: compositional validation dynamic service discovery and selection Y: UserAgent Callee B yi X: UserAgent Caller A xi W: UserAgent CalleeW wi B Z: UserAgent CallerW zi A UserCallW UserCall

Science and Technology Norwegian University of NTNU Rolv Bræk, April defining a semantic interface without waiting

Science and Technology Norwegian University of NTNU Rolv Bræk, April and one with waiting

Science and Technology Norwegian University of NTNU Rolv Bræk, April Incompatible Validating compatibility (full or restricted) Y: UserAgent Callee B yi X: UserAgent Caller A xi W: UserAgent CalleeW wi B Z: UserAgent CallerW zi A Compatible {UserCallW.goal} UserCallW UserCall Compatible {UserCall.goal} Compatibility in collaboration occurrences Compatibility in composition

Science and Technology Norwegian University of NTNU Rolv Bræk, April Caller Callee UserCall CallerW CalleeW UserCallW ext extension reduction red Role relationships

Science and Technology Norwegian University of NTNU Rolv Bræk, April Substitution and subtyping Here a and b mirror each other with conflict resolution omitted. Substitution roles a’, b’ can have less outputs and more inputs, i.e. be subtypes of a,b (~>) Remove outputs a1 a2a3 a4 a6a7 a8 a5 a9 !m1!m2 ?m3?m4 ?m5 ?m6!m7!m8 b1 b2b3 b4 b6b7 b8 b5 b9 ?m1?m2 !m3!m4 !m5 !m6?m7?m8 a’1 a’2a’3 a’4 a’6a’7 a’8 a’5 a’9 !m1 !m2 ?m3?m4 ?m5 ?m6!m7!m8 b’1 b’2b’3 b’4 b’6b’7 b’8 b’5 b’9 ?m1?m2 !m3!m4 !m5 !m6?m7?m8 a’10 ?m9 b’10 ?m10 a’11 ?m11 b’11 ?m11 Add inputs a b a’ b’ Note that new inputs will never be explored in the a’ - b’ collaboration.

Science and Technology Norwegian University of NTNU Rolv Bræk, April Subtype ”anomaly” - given two compatible (here dual) roles a and b. Normally, subtypes a’ ~>a and b’~>b will be compatible. However, if all outputs are removed, they will not be compatible! Compatibility requires that containment and obligation be satisfied. Removing all output transitions from a state may violate obligation and result in a deadlock. Hence restricted sub-types cannot allways safely replace their super-types. The problem is restriction! a1 a2a3 a4 a6a7 a8 a5 a9 !m1!m2 ?m3?m4 ?m5 ?m6!m7!m8 b1 b2b3 b4 b6b7 b8 b5 b9 ?m1?m2 !m3!m4 !m5 !m6?m7?m8 a’1 a’2a’3 a’4 a’6a’7 a’8 a’5 a’9 !m1 !m2 ?m3?m4 ?m5 ?m6!m7!m8 b’1 b’2b’3 b’4 b’6b’7 b’8 b’5 b’9 ?m1?m2 !m3!m4 !m5 !m6?m7?m8 a b a’ b’

Science and Technology Norwegian University of NTNU Rolv Bræk, April What about liveness? Liveness require additional information: Separate property expressions (e.g. using Temporal Logic). Event goals and state goals attached to role behaviours. Collaboration goal expressions. The first is the classical approach used in modelchecking. The second and third are novel approaches that we seek to illuminate in this presentation.

Science and Technology Norwegian University of NTNU Rolv Bræk, April Role substitution examples Basic a-roles provide safety properties Progress labels provide (some) liveness

Science and Technology Norwegian University of NTNU Rolv Bræk, April Collaboration goals a1 a2a3a4 a6a7a8 a5 a9 !m1!m2?m3?m4 ?m6!m7!m8 b1 b2b3b4 b6b7b8 b5 b9 ?m1?m2!m3!m4 !m5!m6?m7 ?m8:b_eg1 a_sg2b_sg2 ?m5:a_eg1 a b ?m9 a_sg1b_sg1 !m9 c1 c2c3c4 c6c7c8 c5 c9 m1m2m3m4 m6m7 a_sg2 and b_sg2 m5:a_eg1 a-b m9 a_sg1b_sg1 m8:b_eg1 Collaboration goals are expressed in terms of role goals, e.g. c_sg2 = a_sg2 and b_sg2, c_eg1 = a_eg1 Collaboration goals specify goal obligations (desired goals) that shall be satisfied by the roles of the collaboration. Goal validation alternatives: modelchecking that a||b satisfy all collaboration goals checking that a-b satisfies all collaboration goals (The collaboration goals are satisfied in this example) a b a-b collaboration goals: c_eg1= a_eg1, c_sg1=a_sg1, c_sg2=a_sg2 and b_sg2;

Science and Technology Norwegian University of NTNU Rolv Bræk, April Goal categories: State Goal: a state assertion that shall hold in one or more role/collaboration states, regardless of how the state is reached (thus allowing many paths to the goal). Event Goal: a desired event (such as sending a message) produced by an action or transition. Event goals may be expressed using progress labels. Both categories of goals are considered useful. Both categories may have subgoals. A state goal, may have event sub-goals and v.v.

Science and Technology Norwegian University of NTNU Rolv Bræk, April Compatibility in collaboration occurrences Assume a collaboration with dual roles A and B. For each potential participant class: 1.Derive a-role 2.Ensure s-role consistency 3.Compare a-roles, select Ai, Bj such that: Ai ~> A and Bj ~> B and if restriction has been applied that Ai-Bj satisfies obligation and collaboration goals. Subtyping can be checked once for each participant type. Goal reachability can be checked once for each pair Ai, Bj of participant types. Need not be repeated for each instance. Note that the collaboration will be restricted only if the subtypes are restricted. Class_A1 S-roleA Class_B2 S-roleB service-a B A a Class_A2 S-roleA Class_B1 S-roleB b A2 A1 B1 B

Science and Technology Norwegian University of NTNU Rolv Bræk, April Static S-role composition Performed at design time, possibly by (partially) synthesising from a-roles. Services and features provided by the s-role should be reflected in goal and progress expressions and kept updated as the s-role evolves. The a-role consistency rules ensures that the s-role is internally consistent and that all goals and progresses are reachable! This avoids FI problems caused by ambiguous signals!? Dependecies among goals and progress on different a-roles (interfaces) are defined by the s-role behaviour. Can be explicitly expressed in state expressions and in larger collaborations!? Actor S-role C D ServiceX B A Terminal U T ServiceY goalT1, goalT2,... progressT1, progressT2,... goalX1, goalX2,... progressX1, progressX2,... goalY1, goalY2,... progressY1, progressY2,...

Science and Technology Norwegian University of NTNU Rolv Bræk, April Actor S-role C D Service X B A Service Y goalX1, goalX2,... progressX1, progressX2,... goalY1, goalY2,... progressY1, progressY2,... Termin al U T goalT1, goalT2,... progressT1, progressT2,... Static structure composition - ”horizontal” ProviderX X 1 Servic eX B A goalX1, goalX2,... progressX1, progressX2,... ProviderY Y 1 Servic eX D C goalY1, goalY2,... progressX1, progressX2,... Termi nal U T goalT1, goalT2,... progressT1, progressT2,... Term Trminal 1 a:Term b:Actor c:ProviderX d:ProviderY Note that a-role subtyping implies that all session goals and progress will be reachable! Feature interactions that violate safety and liveness rules are avoided!? Subtyping may result in goal and progress restrictions. Restrictions may directly reduce the reachable goals of the s-role and other collaborations of the same s-role. Restrictions may propagate through chains of a-roles linked by s- roles to indirectly restrict goals and progress on distant collaborations. This may unintentionally affect other features and is a kind of inverse FI. Information about the s-roles is required to analyse this – can it be provided in a distilled form? Using composite collaborations?? or s- role goal structures???

Science and Technology Norwegian University of NTNU Rolv Bræk, April Dynamic structure composition - ”horizontal” Dynamic links imply that roles are dynamically assigned to actors. This requires dynamic role management mechanisms for discovery, selection, adaptation and invocation. A large class of services are triggered in response to dynamic link requests (at least communication control services). There may be constraints on what actors are allowed to play given roles, e.g. B must be the individual identified by the called party identifier, B must have a given responsibility, B may be any object that can play the role. The state of an actor may determine what roles the actor is able to play at any given time, e.g. busy, free. Compatibility rules must be applied on dynamic liks to ensure goal and progress UserAgent Caller Call B A B A a b Terminal U T TerminalAgent POT 1 Terminal U T Ta: TerminalAgent Tb: TerminalAgent ua:UserAgent ub:UserAgent POT Caller callee POT Callee

Science and Technology Norwegian University of NTNU Rolv Bræk, April RAM.M – Service Engineering overview Actor implementation with metadata Service models: Collaborations with behaviour r2 r3 r1 > Service ececution environment design composition dynamic deployment Actor design with semantic interfaces (Automatic) code generation dynamic structure with dynamic discovery and composition methods and tools

Science and Technology Norwegian University of NTNU Rolv Bræk, April RAM.M Aspects Collaboration modelling: decomposing and composing collaborations collaboration goals collaboration behaviours semantic interfaces with goals and a-roles a-role composition synthesising s-role behaviours Designing Actors and Agents with semantic interfaces Dynamic discovery, selection, adaptation Formal foundation and tools