1
Next Generation Service
Engineering
Making the most of service models
Rolv Bræk,
Norwegian University of Science and Technology – NTNU,
Department of Telematics
NTNU, April 2008
Getting Service Engineering Right
2
Overview
•
•
•
•
•
•
Current Best Practice
Trends and challenges
Services and service models
Semantic connectors
Dynamic adaptation
Next Generation Service Engineering
Getting Service Engineering Right
3
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
• Distribution transparency and
scalablility
• Platform layering with edges
Getting Service Engineering Right
4
The SE Context
Methods
Users and
user communities
Terminals
Terminals
Appliances
Appliances
soap
http
RMI,
…
How to support
Tools
Rapid,
Service Creation Environments
Compositional,
and
Correct development
with
Services
Dynamic deployment
Application Servers (Service
of
Execution Environments)
Innovative Convergent
Services?
Parlay, OSA, JAIN, ...
Service Enablers
Service
engineering
Service
deployment
and
execution
Service
platforms
Access
and
transport
network
Access
and
transport
network
Getting Service Engineering Right
5
Trends
• Unification of underlying network technologies
and computing platforms enabling network and
service convergence.
• Diversification of services as well as equipments
at the network edges.
• Shifting the business focus from connectivity and
traffic to services and content
• Shifting the development focus from system
design to service engineering and end user value
Getting Service Engineering Right
6
Service engineering challenges
• From object orientation to service orientation:
precise service modeling and service
composition
• From network and platform focus to end-user
focus
• From design time to run time composition and
adaptation
• Supporting situation, personalization and policy
Getting Service Engineering Right
7
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
Getting Service Engineering Right
8
The nature of services
“Vertical” composition (within an actor)
Service 1
Service 2
Service 3
Actor 1
•
•
•
•
•
Actor 2
Actor 3
Actor 4
Actor 5
“Horizontal”
composition
(within a service)
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.
Getting Service Engineering Right
9
Active and passive services:
• Passive Services (Client-server)
– One-way initiatives
– A service as an interface
– Synchronous communication
– Restricted structure
• Active Services (Peer-to-peer)
– Multi-way initiatives
– A service as a collaboration
– Asynchronous communication
– General structure
Getting Service Engineering Right
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
Getting Service Engineering Right
11
Service orientation:
Introduce:
• service models
• service composition
• design synthesis
and gain more:
• dynamics
• adaptability
• correctness
S1
S2
S1.1
S2.1
Services
S3
S3.1
S2.2
Design
synthezis
Designs
Program
generation
Realizations
Getting Service Engineering Right
12
Introducing UML 2 collaborations
Vertical composition (within an actor)
service 1
service 2
r2
r1
r3
Service 1
Service 2
Horizontal
composition
(within a service)
Service 3
Actor1
Actor2
Actor3
Actor4
Actor5
• 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.
• Notion of compatibility between roles and classes
• Enabler for service composition, semantic connectors with modular
validation and dynamic actor composition
• Method for service modelling and composition
Getting Service Engineering Right
13
Collaboration diagrams
A collaboration with two roles:
•may define a semantic connector
Session
roleX:TypeX
A collaboration with three roles and
three collaboration uses:
• may define a service structure
roleY:TypeY
Service
roleA:TypeA
•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
roleY
roleX
session1:
Session
roleX
roleB:TypeB
roleY
session2:
Session
session3:
Session
roleY
roleC:TypeC
roleX
Getting Service Engineering Right
14
TaxiCentral Example (Exam 2007)
TaxiCentral
operator
Interface
op[n]
op
line
Interface
acdOp
acdLi
ACD
li
Ii[m]
acdTd
taxi
Dispatch
td
TaxiDispatch
td
taxi
Interface
taxi
taxi[l]
• Decomposition into interfaces and initiatives (features)
Getting Service Engineering Right
15
taxiInterface defined using MSC or activity
diagram
• Complete definition of intended
behavior
• Coordination with other interfaces
undefined
• Initiative choice (mixed initiative) to
be resolved
taxiInterface
td
taxi
msc taxiInterface
taxi
td
available
loop
available
alt
tourOrder(TourInfo)
tourOrder
pickup
confirm
pickup(tourInfo)
finished
finished(tourInfo)
unavailable
unavailable
Getting Service Engineering Right
16
TaxiInterface
defined using
role state process taxi
machines
taxiInterface
taxi
1
DCL ti TourInfo;
DCL ti TourInfo;
1
available
available
tourOrder(ti
)
confirm
3
3
process td
none
2
2
tourOrder(ti
)
pickup
td
none
pickup
confirm
finished
5
unavailabl
e
1
tourOrder(ti)
pickup
4
3
3
none
none
none
none
available
2
pickup
4
pickup
finished
4
5
unavailable
1
available
2
Getting Service Engineering Right
17
TeleConsultation
•
•
•
Collaborative; Cross-cutting; Partial; Functionality
Decomposition into interfaces and initiatives (features)
Models one service individual
pr
Patient
pc
TeleConsultation
rr
rw Recepcionist
r:registration
rd ras ra ru
pw w:waiting
pd
consultation
d:disconnect
pc
as:assignment
callee
c:call
caller
dc
u:unavailable
av:available
sc testee
t:test
tester
c:consultation
sc
Sensor
das
dc
da
du
Doctor
Getting Service Engineering Right
18
Activity diagram for the global service
behavior
Patient
Doctor
r: registration
av: available
unavailable
available
Consultation
u: unavailable
hangup
w: waiting
t: test
d: disconnect
v: voice
as: assignment
c: consultation
•
•
•
Activities correspond to collaboration uses
Two users taking independent initiatives
Roles not identified
Getting Service Engineering Right
19
Choreography:
•
•
•
Identifies roles and collaboration uses
Complete definition of service behavior, not just use-cases and scenarios
Finding realization problems by analyzing the composition and initiatives
P
r:registration
unavailable
pr
Patient
pc
TeleConsultation
rr
rw Recepcionist
r:registration
«external»
ru
hangup
rd ras ra
w:waiting
pw
pd
P
w:waiting
d:disconnect
R
u:unavailable
caller
c:call
R
sc testee
as:assignment
dc
t:test
P
dc
da
u:unavailable
D
consultation
callee
c:consultation
das
D
R
av:available
sc
Sensor
a:available
available
pc
P
R
R
d:disconnect
as:assignment
R
D
tester
c:consultation
D
S
du
Doctor
Consultation
S
t:test
D
P
v:voice
D
Getting Service Engineering Right
20
Analysing realizability
• Weak and strong sequencing:
– Races
– Coordination messages
• Choice and merge
– Local choice
– Non-local choice
– Initiative choice
P
r:registration
unavailable
R
R
a:available
D
available
R
«external»
hangup
P
P
w:waiting
u:unavailable
D
R
d:disconnect
R
• Parallel fork and join
• Interruption
R
as:assignment
P
c:consultation
D
D
S
Consultation
S
t:test
D
P
v:voice
D
Getting Service Engineering Right
21
Design issues
• Automatic synthesis of correct component design
• Composing actors having different role portfolios
• Coordinating multiple service and role instances
S1
S2
S1.1
S2.1
Services
S3
S3.1
S2.2
Design
synthezis
Designs
Getting Service Engineering Right
22
System design
• Defining the actor structure
• Binding service roles
• Coordinating service and role invocation
RemoteHealthcareSystem
Patient[*]
Receptionist
Patient
Nurse
Tele
Consultation
Sensor
Instrument[*]
Doctor
Doctor[*]
Getting Service Engineering Right
23
Coordination issues
•
•
•
•
•
•
•
•
Multiple actor instances
Multiple service types
Multiple service instances
Horizontal and vertical composition
Coordination point: dynamic role binding
Policies for flexibility and adaptation
Utilizing semantic connectors for compatibility
Lookup
Getting Service Engineering Right
24
Service providers/agents:
• Have portfolio of provided services and roles
• Manages role invocation in response to Role request/Invite
• Enforces policies concerning:
– situation
– user preferences
• Ensures role compatibility
Provider/agent
preferences
policies
local situation
context situation
b
Rb1
Rc2
Service role portfolio
a
<<provides>>
c
...
b
d
Rb2
c
Rc1
Rd2
d
Rd1
Getting Service Engineering Right
25
Semantic connectors (Basic services)
Two roles with
• Goals
• Static interface definitions
• Dynamic interface behavior
modelchecked to ensure
compatibility
publishable using WSDL
Getting Service Engineering Right
26
Semantic connectors in use
• Typing component interfaces with semantic connector roles
• Providing lean and strong compatibility assurance
• And meaningful lookup
Getting Service Engineering Right
27
Ensuring compatibility
• Typing with semantic connector/basic service roles
• Formally verified and modelchecked
• Safe substitution
Getting Service Engineering Right
28
Meaningful lookup
• Modelchecked
collaborations
• Verified relationships
• Simple search
• Strong compatibility
• Run-time efficiency
Registry
Getting Service Engineering Right
29
tradeoff analysis and runtime decisions using GRL
• Goals, means and situation:
Getting Service Engineering Right
30
Compositional adaptation by replacement
and insertion
MMoIP
using policy rules
evaluated by agents
upon role requests
Request
MMoIP
Service
Provider
User
MMoIP Use
END MMoIP
{when threat level = 0
or
location = secure}
<<replaces>>
SecureMMoIP (Userpull)
Au
the
ca
nti
User
or
n
tio
Access
Control
Server
ute s
trib ation
s
i
D riz
tho
Au
Request
MMoIP
{when threat level > 0
or
location not secure}
Authorization
Service
Provider
MMoIP Use
Server Pull {when ...}
END MMoIP
User Pull {when ...}
or
UoPA
UTPA
{when ...}
{when ...}
Getting Service Engineering Right
31
New architectural opportunities
• Using semantic connectors (basic services) for:
–
–
–
–
Typing components
Ensuring compatibility
Meaningful lookup
Safe substitution
SecureMMoIP (Userpull)
th
Au
en
• Compositional adaptation to
tica
n
tio
Access
Control
Server
ute s
trib ation
s
i
D riz
tho
Au
Request
MMoIP
User
– Situation
– User preferences
Authorization
Service
Provider
MMoIP Use
• using policy to direct:
END MMoIP
– Choreography choices
– replacement
– collaboration insertion
Authentication
<<Actor>>
UserAgent
Terminal
Session
Terminal
Call
Distribute
Auths
Request
MMoIP
Request
MMoIP
Authorization
Authorization
MMoIP
Use
MMoIP
Use
END
MMoIP
END
MMoIP
<<Actor>>
ServiceProvider
MMCall
Getting Service Engineering Right
32
Next Generation Service Engineering
•
•
•
•
•
•
”bits in the SE puzzle coming
together”
Service Models
Goals and
strategies
Roles and
interfaces
Use cases
and scenarios
UCM
GRL
Library
•
Analysing goals and
strategies using GRL.
Use cases and scenarios
using UCM or AD
Defining collaborations
and analysing realizability
Synthesizing designs
Semantic connectors for
lean, strong compatibility
and meaningful lookup
Collaboration
replacement and insertion
for compositional
adaptation
Situation, profile and
policy for decisionmaking
(Automatic composition
for the future)
Collaborations
Design Models
Goals and
strategies
GRL
Components
Systems
Library
•
SDL, UML
SDL, UML
Implementations
Execution
Monitoring
Enablers
Platform2
Platform1
GRL
NGN
Getting Service Engineering Right
33
Our approach in a nutshell
1. Specify and validate
services separately using
UML 2.0 collaborations
2. Design components using
UML 2.0 state machines
and semantic interfaces
3. Automatically generate
Java code with metadata
4. Dynamically deploy,
discover and compose
terminals, appliances
network nodes
Getting Service Engineering Right