Compositional and Model Driven Service Engineering using semantic interfaces

1
Compositional and Model Driven Service
Engineeringusing semantic interfaces

• Rolv Bræk, with friends
• The Norwegian University of Science and
  Technology NTNU
• Department of Telematics

2
The challenge
How to supportRapid, Compositional, and Correct
development with Dynamic deployment of
Innovative Convergent Services?
3
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
4
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

5
Introducing UML 2 collaborations
service 1
service 2
r2
r1
r3

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

6
Sixth principleservices as collaborations
UserCall
inviteRoleRequest
requested
bCalled Agent
cCalling
requester
invoked
a
b
bBusy
b
a
aCaller
bCallee
b
a
uUnavailable

• with
• goal expressions for liveness
• behaviour specified using MSC and state machines
• features represented by collaboration uses
• role behaviour designed as actor state machines

7
... and roles/actors bound to agents
FullCall
P1
atTermCaller
auUserCaller
btTermCallee
buUserCallee
ucUserCall
oTermCall
tTermCall
P2
P3
P4
P5
P6
P7
P8
collaborations
agents
P11
P13
P12
P10
btTermCallee
auUserCaller
atTermCaller
buUserCallee
ucUserCall
oTermCall
tTermCall
fcxFullCall
P1P2P3...P8

• Actors as service components (provide roles)
• Actors for separate services and sessions

8
Fifth principlecomponent based framework with
loose coupling- Actors and Agents
9
... with platform adaptors and edges
AmigosFramework
Mp1MeetingPlace
KariUserAgent
t1TermAgent
Platformindenpendent
t2TermAgent
OlaUserAgent
Mp2MeetingPlace
Service Platform Specific
ComputingPlatform Specific
10
... 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

11
Composition aspects

• 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

Service models Collaborations with behaviour
design composition
Actor design with semantic interfaces
(Automatic) code generation
Service ececution environment
Actor implementation with metadata
dynamic deployment
dynamic structure with dynamic discovery and
composition
12
Compatibility and interface roles
3
1
B
1
A
1a
1b
2
2

• Interface roles are projected and distilled
  behaviours visible on interfaces, or
  associations. Given two state machines A and B
• Derive the interface role behaviours
• Project hide and transform
• Distill gather, minimize and merge
• Detect inconsistencies
• Correct inconsistencies and repeat from 1
• Validate role compatibility

13
Dual roles are fully compatible a-roles

• iff the original state machine is consistent,
  then the dual a-role may be constructed,
• and used to discover, compare and select
  compatible services,
• and to partially synthesise state machines.

14
Compatibility in collaboration occurrences
Class_B1
Class_A1
S-roleA
S-roleB
1
1
B1
A1
2
2
3
3
a
b
B
A
Class_B2
Class_A2
3
3
S-roleB
S-roleA
1
1
B2
A2
2
2

• Assume a collaboration with dual roles A and B.
  For each potential participant class
• Derive a-role
• Ensure s-role consistency
• Compare a-roles, select Ai, Bj such that
• Ai gt A and Bj gt 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.

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

a
b
B
A
XClass_A
yClass_B
1
1

• 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

16
Interface Typing by Semantic Interfaces
Y UserAgent
X UserAgent
UserCall
UserCall
Callee
Caller
A
B
yi
xi
W UserAgent
Z UserAgent
CalleeW
CallerW
B
A
wi
zi
UserCallW
UserCallW

• to enable
• compositional validation
• dynamic service discovery and selection

17
... defining a semantic interfacewithout waiting
18
... and one with waiting
19
Validating compatibility (full or restricted)
Y UserAgent
X UserAgent
UserCall
UserCall
Callee
Caller
B
A
Compatible UserCall.goal
yi
xi
Compatible UserCall.goal
Incompatible
W UserAgent
Z UserAgent
CallerW
CalleeW
Compatible UserCallW.goal
B
A
wi
zi
UserCallW
UserCallW

• Compatibility in collaboration occurrences
• Compatibility in composition

20
Role relationships
UserCall
Caller
Callee
ext
extension
reduction
red
UserCallW
CallerW
CalleeW
21
Substitution and subtyping
a
b
a1
b1
!m1
!m2
?m3
?m4
?m1
?m2
!m3
!m4
a2
a3
a4
a5
b2
b3
b4
b5
?m5
?m6
!m7
!m8
!m5
!m6
?m7
?m8
a6
a7
a8
a9
b6
b7
b8
b9

• 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 (gt)

a
b
a1
b1
?m9
!m1
?m10
!m2
?m3
?m4
?m1
?m2
!m3
!m4
a2
a3
a4
a5
b4
b5
a10
b2
b3
b10
?m11
?m11
?m5
?m6
!m7
!m8
!m5
!m6
?m7
?m8
a6
a7
a8
a9
a11
b11
b6
b7
b8
b9
Add inputs

• Remove outputs

Note that new inputs will never be explored in
the a - b collaboration.
22
Subtype anomaly - given two compatible (here
dual) roles a and b.
a
b
a1
b1
!m1
!m2
?m3
?m4
?m1
?m2
!m3
!m4
a2
a3
a4
a5
b2
b3
b4
b5
?m5
?m6
!m7
!m8
!m5
!m6
?m7
?m8
a6
a7
a8
a9
b6
b7
b8
b9

• Normally, subtypes a gta and bgtb will be
  compatible.
• However, if all outputs are removed, they will
  not be compatible!

a
b
a1
b1
!m1
!m2
?m3
?m4
?m1
?m2
!m3
!m4
a2
a3
a4
a5
b2
b3
b4
b5
?m5
?m6
!m7
!m8
!m5
!m6
?m7
?m8
a6
a7
a8
a9
b6
b7
b8
b9

• 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!

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

24
Role substitution examples

• Basic a-roles provide safety properties
• Progress labels provide (some) liveness

25
Collaboration goals
goals c_eg1 a_eg1, c_sg1a_sg1, c_sg2a_sg2
and b_sg2
a-b collaboration
b
a
a-b
a
b
a1
b1
c1
!m1
!m2
?m3
?m4
?m1
?m2
!m3
!m4
m1
m2
m3
m4
a2
a3
a4
a5
b2
b3
b4
b5
c2
c3
c4
c5
?m6
!m7
!m8
!m5
!m6
?m7
?m9
!m9
m6
m7
m9
?m8b_eg1
?m5a_eg1
m5a_eg1
m8b_eg1
a6
a7
a8
a9
b6
b7
b8
b9
c6
c7
c8
c9
a_sg2
b_sg2
a_sg1
b_sg1
a_sg2 and b_sg2
a_sg1
b_sg1

• 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 ab satisfy all collaboration
  goals
• checking that a-b satisfies all collaboration
  goals
• (The collaboration goals are satisfied in this
  example)

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

27
Compatibility in collaboration occurrences
Class_B1
Class_A1
S-roleA
S-roleB
1
1
B1
A1
2
2
3
3
a
b
B
A
Class_B2
Class_A2
3
3
S-roleB
S-roleA
1
1
B2
A2
2
2

• Assume a collaboration with dual roles A and B.
  For each potential participant class
• Derive a-role
• Ensure s-role consistency
• Compare a-roles, select Ai, Bj such that
• Ai gt A and Bj gt 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.

28
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!?

29
Static structure composition - horizontal

• 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???

30
Dynamic structure composition - horizontal
UserAgent
Caller
T
U
a
B
A
1
2
Callee
b
3
A
B
ubUserAgent
uaUserAgent
Tb TerminalAgent
Ta TerminalAgent
callee
Caller
POT
POT
2
2
1
1
1
1
3
3

• 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

31
RAM.M Service Engineering overview
Service models Collaborations with behaviour
methods and tools
design composition
Actor design with semantic interfaces
(Automatic) code generation
Service ececution environment
Actor implementation with metadata
dynamic deployment
dynamic structure with dynamic discovery and
composition
32
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