Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 1
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 TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 2
The challenge
Access and transport network
Service Enablers
Tools Service Creation Environments
Methods
Terminals
Appliances
Parlay, OSA, JAIN, ...
Application Servers (Service Execution Environments)
Services
Access and transport network
Service Enablers
Tools Service Creation Environments
Methods
Terminals
Appliances
soap http RMI, …
Parlay, OSA, JAIN, ...
Application Servers (Service Execution Environments)
Users and user communities
Services
Service engineering
Service deployment and execution
Service platforms
How to supportRapid,
Compositional,and
Correct developmentwith
Dynamic deploymentof
Innovative Convergent Services?
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 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
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 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
Service 1
Actor 1Actor 2
Actor 3Actor 4
Actor 5
Service 3
Service 2
“Vertical” composition (within an actor)
“Horizontal” composition(within a service)
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 5
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.
Actor1 Actor2 Actor3 Actor4 Actor5Actor1 Actor2 Actor3 Actor4 Actor5
Service 3Service 3
Service 2Service 2
Service 1Service 1
Horizontal composition(within a service)
Vertical composition (within an actor)
r2
r3
r1
service 2service 1
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 6
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:Caller b:Callee
invite:RoleRequest
c:Calling
b:Busy
u:Unavailable
b:CalledAgent
requester
requested
invokeda bbb
aa
UserCall
{goal: VoiceCnt(a,b) = a.VoiceCntTo(b) AND b.VoiceCntTo(a)}
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 7
FullCall
at:TermCaller
bt:TermCallee
au:UserCaller
bu:UserCallee
uc:UserCallo:TermCall t:TermCall
P1
P2 P3 P4 P5 P6 P7 P8
bt:TermCallee
at:TermCaller
au:UserCaller
bu:UserCallee
uc:UserCallo:TermCall t:TermCall
fcx:FullCall
P1’+P2’+P3’...+P8’
at:TermAgent
au:UserAgent
bu:UserAgent
bt:TermAgent
P12P11P10 P13
collaborations
agents
... and roles/actors bound to agents
• Actors as service components (provide roles)• Actors for separate services and sessions
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 8
Fifth principle:component based framework with loose coupling- Actors and Agents
<<stereotype>>actor
actor : ActorAddress
<<metaclass>>Class
<<stereotype>>ActorAddress
actorId : StringactorType : String
<<profile>> ActorFrame
<<stereotype>>actorMsg
sender : ActorAdddressReceiver : ActorAddress
<<metaclass>>Signal
<<stereotype>>actor
actor : ActorAddress
<<stereotype>>actor
actor : ActorAddress
<<metaclass>>Class
<<metaclass>>Class
<<stereotype>>ActorAddress
actorId : StringactorType : String
<<stereotype>>ActorAddress
actorId : StringactorType : String
<<profile>> ActorFrame
<<stereotype>>actorMsg
sender : ActorAdddressReceiver : ActorAddress
<<stereotype>>actorMsg
sender : ActorAdddressReceiver : ActorAddress
<<metaclass>>Signal
<<metaclass>>Signal
<<actor>>
Actor
innerActor:Actor[*]
in
out
out
in
<<actor>>
Actor
innerActor:Actor[*]innerActor:Actor[*]
in
out
out
in
Agent
identity:credentials:profile:
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 9
... with platform adaptors and edges
AmigosFramework
Kari:UserAgent
Ola:UserAgent
Mp1:MeetingPlace
t1:TermAgent
t2:TermAgent
Mp2:MeetingPlace
tlogon ulogon
tchat mpcalluchat
mpchat
tcall ucall
OSA FW OSA CallC
call
Service Platform SpecificComputing
Platform Specific
PlatformindenpendentEdge
Edge
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 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
Application Server
edge
edgeTerminal/appliance
edge
Application Server
edge
edge
Terminal/appliance
edge
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 11
Composition aspects:
Actor implementationwith metadata
Service models: Collaborations with behaviour
r2
r3
r1
<<Actor>><<Actor>>
<<Actor>>
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 TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 12
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 B1a 1b1
3
1
2 2session
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 13
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
B1c
C1d
1
2
D1b
2b
3b
1
1
1
3
3
3
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 14
Compatibility in collaboration occurrences
Assume a collaboration with dual roles A and B. For each potential participant class:1. Derive a-role2. Ensure s-role consistency3. 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 BAa
Class_A2
S-roleA
Class_B1
S-roleB
b
1
2
1
2
1
2
1
2A2
A1 B1
B2
3
3
3
3
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 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.
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 BCalla b
Class_A
S-roleACall BA
1
a
Class_B
Call
S-roleBBA
1
b
X:Class_A1
y:Class_B1
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 16
Interface Typing by Semantic Interfaces
to enable:• compositional validation• dynamic service discovery and selection
Y: UserAgent
CalleeB
yi
X: UserAgent
CallerA
xi
W: UserAgent
CalleeWwiB
Z: UserAgent
CallerW ziA
UserCallW UserCallW
UserCall UserCall
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 17
... defining a semantic interfacewithout waiting
Inviting
?Alerting ?Busy(BusyOptions)
Alerting
?Reply
?EndCnf
!EndReq
!Invite(a, Role)
Connected{goal:
VoiceCntTo(B)}
disconnectForward
!EndReq?EndReq
!EndCnf
endForward
SelectBusyAction
disconnectBackward
Idle
Idle
!EndReq
?EndCnf
Inviting
!Alerting !Busy(BusyOptions)
Alerting
!Reply
!EndCnf
?EndReq
?Invite(a, Role)
Connected{goal:
VoiceCntTo(A)}
disconnectForward
?EndReq!EndReq
?EndCnf
endForward
SelectBusyAction
disconnectBackward
Idle
Idle
?EndReq
!EndCnf
UserCall::Caller UserCall::Callee
a:Caller b:Callee
UserCall
{goal: VoiceCnt(a,b) = a.VoiceCntTo(b) AND b.VoiceCntTo(a)}
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 18
... and one with waiting
Inviting
?Alerting ?Busy(BusyOptions)
Alerting
?Reply
?EndCnf
!EndReq
!Invite(a, Role)
Connected{goal:
VoiceCntTo(B)}
disconnectForward
!EndReq?EndReq
!EndCnf
endForward
SelectBusyAction
Waiting{goal:WaitForFr
ee(b)}
?Alerting
!wait
disconnectBackward
Idle
Alerting
Idle
!EndReq
!EndReq
?EndCnf
endForward
Inviting
!Alerting !Busy(BusyOptions)
Alerting
!Reply
!EndCnf
?EndReq
?Invite(a, Role)
Connected{goal:
VoiceCntTo(A)}
disconnectForward
?EndReq!EndReq
?EndCnf
endForward
SelectBusyAction
Waiting{goal:CallInQ
ueue(a)}
!Alerting
?wait
disconnectBackward
Idle
Alerting
Idle
?EndReq
?EndReq
!EndCnf
endForward
UserCallW::CallerW UserCallW::CalleeW
{goal: VoiceCnt(a,b) OR WaitOnBusy(a,b)}{WaitiOnBusy(a,b) = a.WaitForFree(b) AND b.CallInQueue(a)}
a:CallerW b:CalleeW
UserCallW
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 19
Incompatible
Validating compatibility (full or restricted)
Y: UserAgent
CalleeB
yi
X: UserAgent
CallerA
xi
W: UserAgent
CalleeWwiB
Z: UserAgent
CallerW ziA Compatible
{UserCallW.goal}
UserCallW UserCallW
UserCall UserCall
Compatible {UserCall.goal}
Compatible {UserCall.goal}
• Compatibility in collaboration occurrences• Compatibility in composition
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 20
Caller CalleeUserCall
CallerW CalleeWUserCallW
ext
extensionreductionred
Role relationships
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 21
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
a2 a3 a4
a6 a7 a8
a5
a9
!m1 !m2 ?m3 ?m4
?m5 ?m6 !m7 !m8
b1
b2 b3 b4
b6 b7 b8
b5
b9
?m1 ?m2 !m3 !m4
!m5 !m6 ?m7 ?m8
a’1
a’2 a’3 a’4
a’6 a’7 a’8
a’5
a’9
!m1 !m2 ?m3 ?m4
?m5 ?m6 !m7 !m8
b’1
b’2 b’3 b’4
b’6 b’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 TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 22
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
a2 a3 a4
a6 a7 a8
a5
a9
!m1 !m2 ?m3 ?m4
?m5 ?m6 !m7 !m8
b1
b2 b3 b4
b6 b7 b8
b5
b9
?m1 ?m2 !m3 !m4
!m5 !m6 ?m7 ?m8
a’1
a’2 a’3 a’4
a’6 a’7 a’8
a’5
a’9
!m1 !m2 ?m3 ?m4
?m5 ?m6 !m7 !m8
b’1
b’2 b’3 b’4
b’6 b’7 b’8
b’5
b’9
?m1 ?m2 !m3 !m4
!m5 !m6 ?m7 ?m8
a b
a’ b’
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 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.
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 24
Role substitution examples
• Basic a-roles provide safety properties • Progress labels provide (some) liveness
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 25
Collaboration goals
a1
a2 a3 a4
a6 a7 a8
a5
a9
!m1 !m2 ?m3 ?m4
?m6 !m7 !m8
b1
b2 b3 b4
b6 b7 b8
b5
b9
?m1 ?m2 !m3 !m4
!m5 !m6 ?m7 ?m8:b_eg1
a_sg2 b_sg2
?m5:a_eg1
a b
?m9
a_sg1 b_sg1
!m9
c1
c2 c3 c4
c6 c7 c8
c5
c9
m1 m2 m3 m4
m6 m7
a_sg2 and b_sg2
m5:a_eg1
a-b
m9
a_sg1 b_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 ba-b collaboration
goals: c_eg1= a_eg1, c_sg1=a_sg1, c_sg2=a_sg2 and b_sg2;
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 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.
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 27
Compatibility in collaboration occurrences
Assume a collaboration with dual roles A and B. For each potential participant class:1. Derive a-role2. Ensure s-role consistency3. 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 BAa
Class_A2
S-roleA
Class_B1
S-roleB
b
1
2
1
2
1
2
1
2A2
A1 B1
B2
3
3
3
3
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 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!?
Actor
S-role
C D
ServiceX BATerminal UT
3
21
ServiceY
goalT1, goalT2, ...progressT1, progressT2,... goalX1, goalX2, ...
progressX1, progressX2,...
goalY1, goalY2, ...progressY1, progressY2,...
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 29
Actor
S-role
C D
ServiceX
BA
321
ServiceY
goalX1, goalX2, ...progressX1, progressX2,...
goalY1, goalY2, ...progressY1, progressY2,...
Terminal
UT
goalT1, goalT2, ...progressT1, progressT2,...
Static structure composition - ”horizontal”
ProviderX
X1
ServiceX
BA
goalX1, goalX2, ...progressX1, progressX2,...
ProviderY
Y1
ServiceX
DC
goalY1, goalY2, ...progressX1, progressX2,...
Terminal
UT
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 TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 30
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
CallB A
Call BAa
b
Terminal UTTerminalAgent
POT 1
Terminal UT
Ta: TerminalAgent
Tb: TerminalAgent
ua:UserAgent ub:UserAgent
3
21
1 1 2
3
2
31 1POT Caller callee POT
Callee
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 31
RAM.M – Service Engineering overview
Actor implementationwith metadata
Service models: Collaborations with behaviour
r2
r3
r1
<<Actor>><<Actor>>
<<Actor>>
Service ececution environment
design composition
dynamic deployment
Actor design with semantic interfaces
(Automatic) code generation
Deployment
Simulation
TranslatorValidation
Editor
dynamic structure with dynamic discovery and composition
methods and tools
Science and TechnologyNorwegian University ofNTNU
Rolv Bræk, April 2005 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