1 Getting Service Engineering Right Global behaviours, services and sessions Rolv Bræk, Norwegian...

1

Getting Service Engineering Right

Global behaviours, services and sessions

Rolv Bræk, Norwegian University of Science and Technology – NTNU,Department of Telematics

NTNU, March 2011

2


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: Agents, State machines, messaging, timers, …

• Distribution transparency and scalablility

• Platform layering with edges

3


• A design model defines a system as a structure of components with associated behaviour.

• This allows a complete and precise definition of behaviour.

• But the global behaviour is fragmented• And the behaviour of different services is often

combined

4


For global behaviors it is common to use interaction diagrams: ITU-T: MSC, HMSCUML: SD, IOD

But there are problems:

1. Behaviors tend to be incomplete because too many orderings are possible

2. Distributed realizations may cause implied scenarios and other emergent behavior that must be resolved

5


Weak sequencing case

• Consider a direct realization of Z• What problem may occur?• How can it be fixed?

ab

ZYX

MSC A

c

6


we ask ourselves:

• How to best organize global behavior models?• Are there alternatives to interaction diagrams?• How to define services separately in a precise way so

that they may be composed?• How to derive design models from service models?

7


Answer: organize global behavior according to services and interfaces:

Service models for: • service specification• service composition• service analysis• interface contracts• design synthesis

With added bonuses:• Increased reuse• Design correctness • Interface validation• Adaptability• Modularity

S1

S3

S2

Design synthezis

S1.1 S2.1

S3.1 S2.2

Program generation

Services

Designs

Realizations

8


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

9


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.

Service 1

Actor 1Actor 2

Actor 3Actor 4

Actor 5

Service 3

Service 2

“Vertical” composition (within an actor)

“Horizontal”composition(within a service)

Service 1

Actor 1Actor 2

Actor 3Actor 4

Actor 5

Service 3

Service 2

“Vertical” composition (within an actor)

“Horizontal”composition(within a service)

10


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


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.

• Container for re-usable global behaviour • Notion of compatibility between roles and classes• Enabler for service composition, semantic connectors with modular

validation and dynamic actor composition

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

12


12

Collaboration diagrams

Service

roleA:TypeA

roleC:TypeC

roleB:TypeBsession1:Session

session2: Session

session3: Session

roleX roleY

roleX

roleY roleX

roleY

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

13


13

Behaviour can be in three places:– The collaboration itself

– The roles

– The context (scope) of the collaboration:

Service

roleA:typeA

roleC:typeC

roleB:typeBsession1:Session

session2: Session

session3: Session

roleX roleY

roleX

roleYroleX

roleY

sd

1

3 2

sd

1

3 2

14


14

How to model the service behaviour?A service is an identified (partial) functionality, provided by a system, component, or facility, to serve a purpose (or achieve a goal) for its (usage) environment.

Languages:• Interaction diagrams• Activity diagrams• Role state machines

op[n] Ii[m]ACD

TaxiDispatch

taxi[l]

TaxiCentral

15


What about this?

acdOp

available

seize(caller)

answer(op)

end

tourOrder(TourInfo)confirm

acdLi

Request

answer(op)

end

queue(no)

msc acd

allocator

alert(caller)

queue(no)loop

answer(op)

available

call(caller)grant(op)

end

alerting

16


Good global overview, ... but :

• It is bound to the system, not reusable• It is incomplete• It is hard to define all possible scenarios

• What can we do?

17


Solutions:

• It is bound to the system, not reusable

Bind to a collaboration in stead!

• It is incomplete, just one scenario• It is hard to define all possible scenarios

Decompose into collaborations corresponding to:• Interfaces• Sub-services• Initiatives

18


The taxi central with interface collaborations

op[n] Ii[m]ACD

TaxiDispatch

taxi[l]

TaxiCentral

lineInterface

taxiInterface

taxiDispatch

operatorInterface

acdTd

acdLiacdOp

td

li

td

taxi

op

19


AcdInterfaces

op acdOp

operatorInterface

ref msc operatorInterface

op acdOp

available

call(caller)

answer

end

loop

tourOrder(TourInfo)

confirm

msc operatorInterface

acdLi li

lineInterface

ref msc lineInterface

acdLi li

alert(caller)

alerting

answer(op)

loop

alt

answer(op)

end

end

queue(no)loop

msc lineInterface

20


TaxiDispatch

td acdTd

taxiDispatch

ref msc taxiDispatch

td acdTd

tourOrder(TourInfo)

confirm

deny

loop

alt

msc taxiDispatch

TourInfocustomer: String

taxi: Stringpickup: Locationstart: Locationdrop: Location

start: Timeend: Time

distance: Integer

Locationstreet: String

number: Integer

21


taxiInterface: find-bind taxi to tour

• Here there is an initiative choice (mixed initiative) to be resolved

taxi td

taxiInterface

taxi td

available

tourOrder(TourInfo)

confirm

unavailable

loop

finished(tourInfo)

alt

pickup(tourInfo)

msc taxiInterface

22


The result:

• More complete behaviors• Reusable building blocks• Interface contracts for validation as a bonus

• But now we need a way to link the interface behaviors.

• How?

23


How to design and compose the roles?

op[n] Ii[m]

lineInterface

taxiDispatch

operatorInterface

acdTd

acdLiacdOp

td

liop

ACD

TaxiDispatch

acdTd

acdOp acdLi

????

24


Role design

Consider which roles should be active objects and which should just be partial behavior of other objects

• State-full roles imply a session and normally map to active objects

• Dynamic links imply dynamic role binding and normally requires an additional allocator

• Stateless roles do not imply a session and can map to operations performed by existing objects

25


The resulting ACD

Operator sessions by op(1,m):OperatorAgtLine sessions by li(1,n):LineAgtDynamic linking by AllocatorTaxi dispatch operation by OperatorAgt

26


Completing the picture

op acdOp

available

call(caller)

answer

end

loop

confirm

msc operatorInterface

tourOrder(TourInfo)

acdLi li

alert(caller)

alerting

answer(op)

loop

alt

answer(op)

end

end

queue(no)loop

msc lineInterface

External interface to be respected

Internal interactions to be added

State machines to be designed

External interface to be respected

27


What about Activity diagrams?

27

28


28

The Access Control Activity

•Global activity flow•Flows crossing partitions imply communication•Exceptions not yet treated here•An alternative to interaction diagrams•Are they better or worse?

29


29

Activity concepts

PartitionPartition

ActionAction

FlowFlow

ForkFork

ChoiceChoice

•Token flow semantics•Flows may be control flows or object flows•Only local actions in this diagram•Partitions may represent roles

30


What if we use interface collaborations?

30

31


31

Activity diagram with collaborations as actions Card EntryCard Entry

AuthorizeAuthorizeValidateValidate

Op

en

Op

en

DenyDeny

AcceptAccept

PIN EntryPIN Entry

panel userAgt

Authenticator Authorizer

Door 1. Can you add the flows and local actions?

2. Can you define each collaboration as an activity?

3. Where do we have sessions?

32


32

Connecting roles using flows and local actions

Card EntryCard Entry

Open

Open

panel userAgt


Door1. NB! pins have been omitted2. What kind of pins are needed?

StoreCIDStoreCID

PIN EntryPIN Entry

DenyDeny

AcceptAccept

ValidateValidate AuthorizeAuthorize

Authent-icateAuthent-icate

AuthorizeAuthorize

EnterCardEnterCard

EnterPINEnterPIN

Deny-ejectDeny-eject

Pass-ejectPass-eject

Open-closeOpen-close

33


33

Streaming pins


Open

Open

panel userAgt


Door

1. Use streaming when actions shall not be stopped

StoreCIDStoreCID

PIN EntryPIN Entry

DenyDeny

AcceptAccept



AuthorizeAuthorize

EnterCardEnterCard

EnterPINEnterPIN




34


34

Sessions


Open

Open

panel userAgt


Door

1. Each access point holds one session

2. Static binding – no allocators3. Do we need sessions in AA?

StoreCIDStoreCID

PIN EntryPIN Entry

DenyDeny

AcceptAccept



AuthorizeAuthorize

EnterCardEnterCard

EnterPINEnterPIN




35


1. AA combined to one component2. Roles not shown here3. Some external flows are missing in components

Splitting/combining to components


panel

userAgtAA-combined

StoreCIDStoreCID

PIN EntryPIN Entry

DenyDeny

AcceptAccept

ValidateValidate Authent-icateAuthent-icate

AuthorizeAuthorize

EnterCardEnterCard

EnterPINEnterPIN



ValidateValidate

OpenOpen

Door


OpenOpen


PIN EntryPIN Entry

DenyDeny

AcceptAccept

36


1. Responding flows added to responding roles

2. Collaborations are kept as contracts

Roles and responding flowspanel userAgt

StoreCIDStoreCIDEnterCardEnterCard

EnterPINEnterPIN



Card EntryCard Entry ceuceu

AcceptAccept auau

DenyDeny dudu

PIN EntryPIN Entry peupeu

Card EntryCard Entrycepcep

PIN EntryPIN Entrypeppep

DenyDenydpdp

AcceptAcceptapap

ValidateValidatevuvu

OpenOpen ouou

37


1. Can you derive the state machines?

37

The two last components

AA-combined


AuthorizeAuthorize

Door

Open-closeOpen-close AuthenticateAuthenticate aaaaOpenOpenodod

38


38

Flow-global Activity diagram Useful for early analysisFocus on intended flowsCan be refined to flow-localized flowsCan be analyzed for implied scenarios

39


39

Service behaviourA-rule: Service separation (new)

Use layering to separate service behaviour from interface given behaviour

A-rule: Service Collaborations (new)

Use collaborations to structure service definitions.

a:Authenticator

b:Authorizer

u:User

d:Door

User Access

ua:UserAgent

•The system structure helps to identify service roles•Services may need roles provided by additional system objects – to be determined during design

40


40

Interface behaviour A-rule: Interface Collaborations (new)

Use collaborations to structure interface definitions.

A-rule: Message Sequence ChartsMake message sequence charts that describe the typical interaction sequences (protocols) at each layer of the interfaces.

p:Panelu:User

PanelInterface PanelUser

Code

OK

Push door

MSC User_accepted

41


41

Role behaviours and Semantic InterfacesA-rule: Role behaviour

Define the interface behaviour of each role in the system and in the environment. Use the roles as basis for behaviour synthesis and validation.

A-rule: Semantic Interfaces (new)Use collaborations to structure and define semantic interfaces.

!Insert your card

?Insert

!Take card, open door

?Remove

?Push door

!Take card, access denied

?Remove

!Take card, open door

?Remove

?Push door

!Enter personal code

?PIN

start

!Take card, access denied

?Remove

start

start

start

start

p:Panelu:User

PanelInterface

42


Role state machine for taxi interface

taxi td

taxiInterface

taxi td

available

tourOrder(TourInfo)

confirm

unavailable

loop

finished(tourInfo)

alt

pickup(tourInfo)

msc taxiInterface

tourOrder(ti)

available

1

pickup

4

3

2

none

confirm

finished

4

unavailable

1

5

available

2

process tdDCL ti TourInfo;

43


process taxi

confirm

none

1

none

33

2

tourOrder(ti)

none

none

1

5

none

2

DCL ti TourInfo;

finished

availableunavailable

available

pickup

tourOrder(ti)

3

pickup

tourOrder(ti)

available

1

pickup

4

3

2

none

confirm

finished

4

unavailable

1

5

available

2

process tdDCL ti TourInfo;

pickup

4

pickup

taxi td

taxiInterfaceA Semantic Interface:TaxiInterfacedefined using dual role state machineshere with resolution of mixed initiative

44


Dynamic sessions: Call handling

ua:UserAllo

us:UserServ

u(n):UserAgent

ua:UserAllo

us:UserServ

u(n):UserAgent

a:Terminal b:Terminal

• Sessions handled by session role objects• Dynamic linking handled by Allocators• Allocators trigger session role objects• Depending on state and context the allocator may trigger alternative role objects, e.g. call-waiting, forward, call-back when free

45


Dynamic sessions: ACD

Operator sessions by op(1,m):OperatorAgtLine sessions by li(1,n):LineAgtDynamic linking by AllocatorTaxi dispatch operation by OperatorAgt

46


Dynamic Sessions: The Treasure Hunt

47


Dynamic sessions: The Treasure Hunt system

48


User agents on Android phones

1 Getting Service Engineering Right Global behaviours, services and sessions Rolv Bræk, Norwegian...

Documents

Transcript of 1 Getting Service Engineering Right Global behaviours, services and sessions Rolv Bræk, Norwegian...