Science and Technology Norwegian University of NTNU Rolv Bræk, April 2005 1 Compositional and Model...

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



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?



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



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)



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



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)}



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



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


<<stereotype>>actor


<<metaclass>>Class

<<metaclass>>Class





<<profile>> ActorFrame





<<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:



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



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



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



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



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



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



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



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



... 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)}



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



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



Caller CalleeUserCall

CallerW CalleeWUserCallW

ext

extensionreductionred

Role relationships



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.



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’



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.



Role substitution examples

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



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;



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.



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



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



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



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



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



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

Science and Technology Norwegian University of NTNU Rolv Bræk, April 2005 1 Compositional and Model...

Documents

Transcript of Science and Technology Norwegian University of NTNU Rolv Bræk, April 2005 1 Compositional and Model...