system composition and reconfiguration in ubiquitous ... · system composition and reconfiguration...

System Composition and Reconfiguration in Ubiquitous Computing scenarios

Stefano Monti, [email protected]

Bologna, September 17th, 2009

September 17th, 2009

System Composition and Reconfiguration in Ubiquitous Computing scenarios 2

AgendaIntroduction

Ubiquitous Computing issuesDisappearing Middleware approach

Service Compositionrationalestate of the art and current trendsservice composition in Ubiquitous Scenarios

System Reconfigurationrationalestate of the art and current trendsreconfiguration in Ubiquitous Scenarios

Conclusions



Ubiquitous Computing scenarioUbiquitous computing:

services and contents anytime,

anywhere, by means of any device

at hand



Driving forcesDynamic

extension

& heterogeneity

novel contents and servicesnovel communication channelsnovel interaction modes and media

→ Service composition

Dynamic

tailoring→ need

to

adaptcontents/servicescommunication patterns andinteraction modesuser needscontext...

→ System reconfiguration



Disappearing middleware approachA very

basic kernel

layer

with

service composition featuressystem reconfiguration features

Application

layer: ubiquity- related

logic

e.g., content

retrieving, adaptation, delivery

Non-functional

layer: application support

logic

e.g., service coordination, naming, persistence

Both

application

non-functional

layer

need

to

beExtensibleReconfigurable

Middleware

Kernel layerNon-functional layer

Application layerService

composition

System reconfiguration

SERVICE COMPOSITION



RationaleService-oriented

Architecture

(SOA) promotes

software modularization and reusestandardization

Web Services

are the most

widespread implementation

of SOA

Service composition

allows

to

aggregate and coordinate services

(software modules) to

build

larger

and more complex

features



Static service compositionStatic

composition

immutable specification of how servicescooperatedirect human intervention: users need to know

which services are availablewhat they do (and how): application domain knowledge

Workflows

as

a preeminent

approach

in the field (BPEL)

services as “blocks” of an execution flowcontrol blocks: forks/joins, conditional branches, loops



Workflow Management SystemsWorkflow Management Systems

(WFMS)

describe complex workflows of services (eg., BPEL standard)execute and monitor workflows (eg., JBPM engine)



Static composition limitationsAvailable services need to be known in advanceUsers need to have a full and solidunderstanding of service business logic and implementation

On the contrary, in Ubiquitous Computing:dynamic extension: services/contents maybecome available or disappearuser transparency: end-users are interested in high level business goals instead of how toachieve them

Dynamic

service composition



Dynamic service compositionService compositions

built runtime (on demand): no a-priori knowledge of available servicesno a-priori configuration

automated fashion (little or no human intervention)high level requirements or business goals“intelligent” service selectioncorrect composition of services

open: virtually, no limit on the kind of services involvednovel services can be involved into novel compositions



Dynamic composition tendenciesSemantic

service composition

Semantics

as

a mean

toconvey high level metadataabout services (differentstandards, e.g. ,OWL-S...)infer novel compositions fromhigh-level business goals

opennessreason on compositioncorrectness

completenessHowever, current

proposals

are

non user-friendly

and thus lack

concrete adoption

input=text; output=audio/x-wav

billing=0€

pool-size=1;blocking=true

behavior=transcoding



Dynamic composition tendenciesWeb mashupsUser-based

content

and

services

arrangement

via rich

and usable

Web 2.0

interfaces

(e.g., Google Maps

Mashups, Yahoo

Pipes...)+

Extremely

usable

and

user-friendly-

Nearly

static

approaches

-

Vertical solution

(web- based

services

&

contents)



Service composition in Ubiquitous scenariosRequirements

in Ubiquitous Computing

novel services, contents, communicationchannels novel services

openness/extendibilityusers are the main target of service and content delivery

user friendlinessscalability: reasonable number of solutions in a limited time

no exhaustive/inferential approaches



Key principles of our proposal

semantics to convey metadatastrutturazione a layer, per gradi di astrazioneutenti vedono solo i livelli a maggior astrazionenessun formato semantico specifico

modello formale del meccanismo

approccio algoritmico e non inferenziale



Ubiquitous service composition modelOur

approach

translucent and semantics-basedto

contemporarilyhide complexity and heterogeneity to users via a layered approach

keep a SOA-based flexible and extendible approach forautomated semantics-basedservice composition

formal composition model

algorithmic and non-inferentialapproach Business logic

layer

Semantics

fusion

layer

User

semantics

layer

Service metadata Templates Interaction

patterns

Rules Roles

Semanticdomains

Services Workflows



Business logic layer

Servicesbasic application logicunitse.g.: content retrieval, trasformation, adaptation, dispatch

Workflowsactivity flow descriptionaggregation and coordination of services Business logic

layer

Semantics

fusion

layer

User

semantics

layer


patterns

Rules Roles

Semanticdomains

Services Workflows



User semantics layerService metadata

semantic data about the nature of application serviceshigh-level description of service features

service selection logic

Templatesservice aggregation modelsabstract workflows

service coordination logic

Interaction patternsinteraction with templates

service interaction logic Business logic

layer

Semantics

fusion

layer

User

semantics

layer


patterns

Rules Roles

Semanticdomains

Services Workflows



Semantics fusion layer

Semantic

domainsgroup features of a certain service description area (e.g., syntax, behavior,…)dynamically extensible

Rulesdrive translations from templatesto concrete workflows

Rolesreuse of rules for

different templatesdifferent nodes within a template Business logic

layer

Semantics

fusion

layer

User

semantics

layer


patterns

Rules Roles

Semanticdomains

Services Workflows



Service composition in actionUser

requirements

which (kind of) services/contents →semantic service metadatahow to arrange them →composition templateshow to interact with them→ interaction patterns

Service compositiontranslates userrequirements intoconcrete workflowsrelies on currentlyavailable services

Rules Roles

Semanticdomains

UserUser requirementsrequirements--templatestemplates--service service metadatametadata--interaction patterninteraction pattern

ServicesServicesWorkflowsWorkflows



A typical example – user perspective

p2

p3

p4

p1 p5

1

Choice

of anAggregation

template

from

a template catalogue

FOR

K p6

Rp2

={ generator

}generator.behavior.typology

== “generation”

Rp5

={ aggregator


== “aggregation”



A typical example – user perspective1

Choice

of anAggregation

templatefrom


2

Choice

of an

interaction pattern

Rp2

={ generator


== “generation”

Rp5

={ aggregator



Rp1

={ userInput} Rp6

={ userOutput}

p2

p3

p4

p1 p5

FOR

K p6



A typical example – user perspective3

Choice

of kinds

of services

by

means

of semantic metadata

p2

p3

p4

p1 p5

FOR

K p6

2

Choice

of an

interaction pattern

Rp2

={ generator


== “generation”

p2.generationDomain.contentType = RSS

Rp5

={ aggregator



Rp1

={ userInput}userInput.interactionDomain.inputChannel = SMS

Rp6

={ userOutput}userOutput.interactionDomain.outputChannel = phoneCall

Rp4

={ generator


== “generation”

p4.generationDomain.contentType = HTML

1

Choice

of anAggregation

templatefrom




A typical example – system perspective

FOR

K Σ

Aggregator

output ==XMLPhone

call

service input == audio/wav

NO MATCH!

X

Middleware

Kernel

layer

Non-functional

layer

Application

layer

Service composition


Σ

…



A typical example – system perspective

FOR

K Σ

Aggregator

output ==XMLXML-2-Voice input ==XML

XML-2-Voice output == audio/wavPhone

call

input == audio/wavMATCH!

Middleware

Kernel

layer

Non-functional

layer

Application

layer

Service composition


Σ

…

SYSTEM RECONFIGURATION



RationaleIn Ubiquitous scenarios, frequent

changes

in

user requirementsservice availabilityoperating conditions

Systems

not

only

need

to

dynamically

compose business logic

Need

to

support

reconfiguration of non-functional (support) logic

application logic



State of the artReflective

middleware

first approaches in system reconfigurationreflective middleware as a set of support componentsthat hide heterogeneityin addition, applications built on top can runtimeinspect and reconfigure middleware components

Main

issues:application-driven reconfigurationhow

to

deal with

conflicts

(e.g., different

applications

that

require

incompatible

reconfiguration actions)no really structured approach to reconfigurationreflection comes at a price…



State of the artAutonomic

computing

Systems

able

to

provide

self-managing

properties:self configuration: automatic system configuration according to high-level goals

self optimization: automatic system/resourcesoptimization

self healing: problem detection and reaction

self protecting: protection against malicious attacksor human errors



State of the art

Autonomic

computingIBM MAPE-K reference

model

stages:MonitoringAnalysisPlanningExecution

Common reference Knowledge base

Sensors/effectors

concretely

act

on managed

resources

resources



ExampleRSS-to-VoIP: service coordination

RSS content retrievalvoice synthesis (e.g., RSS to Wav)phone call (eg. Asterisk gateway)

Non-functionallayer

Servicecoordination

Serviceregistry

Naming Persistence

…Workflow execution

Application

layer

Kernel

layer

Service composition


Service composition

In case of network congestion

/ high load Bottlenecks!voice synthesis serviceWorkflow execution non-functionalfeature



Current limitations

In Ubiquitous Computing, heterogeneity

and dynamic

adaptation

impact both

onapplication logicnon-functional support logic

Current

autonomic

solutionspartially cope withapplication logicreconfigurationdo not face non-functionallogic reconfigurationlack clear distinctionbetween logic types

Need

for

a middleware platform that

supports

reconfiguration of

• application

logic• non-functional

logic

Middleware

Kernel

layer

Non-functional

layer

Application

layer Service composition




Reconfiguration - Main featuresMonitoring features

keep track of system current status

Reconfiguration policy management featuresdetermine when and how to reconfigure the system

Reconfiguration enactment

features

take actions toconcretely reconfigurethe system

Kernel

layer


Service composition

monitoring policies

enactment



Reconfiguration policiesPolicies

determine

what to reconfigureservice/component propertieswhole service/componententire service composition (workflow)

when to reconfigureproactively vs. reactively

how to reconfigure: different strategiesdepending on what to reconfigure; e.g.:

service/component substitution vs. multiple instance poolingworkflow invalidation and rebuild vs. runtimereconfiguration



System monitoringMonitoring features

crosscut main logic and span over differentservices/componentsneed not be bound to a specific componentmodularity

Aspect-oriented

approachmonitoring facilities “decorate” main logicmodular approach

Service monitoringpluggable aspects to monitor differentcharacteristics (e.g., QoS, availability,…)collects monitoring data from distributedcomponents



Reconfiguration enactment

Reconfiguration enactmentmanages both

Application-level servicesNon-functional services

triggers service reconfigurationservice composition allows to runtime determinenovel suitable compositions



Case study - runtimeTraffic

news

over SMS channelover PSTN network

Realization

scenariodifferent workflows realizeportions of the scenarioworkflows can communicate via asynchronous messages

Monitoring keeps

track of non- functional

component

status

Enactment

keeps

track of application

service status

Workflowexecution

AsynchMessaging

(JMS-based)

…

Kernel

layer

HTML2Txt

QoS


Txt2SMS

enactment

servicecomposition

policymgmt monitoring

QoS

QoS

QoS



Case study - reconfigurationNovel

workflow

instances

Performance loss

Bottlenecksvoice synthesis service(WAV)asynch messaging (JMS-based)

Reconfiguration enginesubstitutes the Asynch Messagingcomponent with an RTI-basedimplementation

Service

composition

enginereconfigures workflowssubstitutes WAV synthesisservice with MP3 synthesis

Workflowexecution

AsynchMessaging

(JMS-based)

…HTML2Txt Txt2

SMS

QoS

AsynchMessaging

(RTI-based)

Kernel

layerSystem reconfiguration

policymgmt monitoring

enactment

servicecomposition

CONCLUSIONS



Ubiquitous Computing scenarios

Ubiquitous Computing stresses

the need

for:dynamic extension and heterogeneity

need to cope with novel contents/services, devices, user interaction styles, …

dynamic tailoring and adaptationservices/contents and the middleware itself need toadapt to ever-changing operating conditions & userrequirements



Disappearing Middleware

Middleware as

a solution

for

Ubiquitous supporthides heterogeneitydisappearing approach

minimal kernel layercomposition featuresreconfiguration features

novel features plugged in by need



Research directions

Reconfigurable

and Composable

Middleware will

be

the basis

for

modern

distributed

applications, to

let

themextend (and also shrink) when in needadapt to changing conditions

Disappearing

approach

as

the only

viable solution

when

complexity, uncertainty, and

flexibility

rule

the target scenarios.

Questions?

[email protected]



ReferencesService Composition

M. ter Beek, A. Bucchiarone, S. Gnesi, “A Survey on Service Composition Approaches: From Industrial Standards to Formal Methods”, CNRTechnical Report 2006.N. Milanovic and M. Malek, “Current Solutions for Web Service Composition” IEEE Internet Computing, November 2004.D. Benslimane, S. Dustdar,A. Sheth “Services Mashups The New Generation of Web Applications”, IEEE Computer, September 2008.B. Medjahed, A. Bouguettaya “A Multilevel Composability Model for Semantic Web Services”, IEEE Transactions on Knowledge and Data Engineering, July 2005.

System reconfigurationM.C. Huebscher, J.A. McCann “A survey of Autonomic Computing—Degrees, Models, and Applications”, ACM Computing Surveys, August 2008.F. Kon, F. Costa, G. Blair, R.H. Campbell “The Case for Reflective Middleware”, Communications of the ACM, June 2002.J. Floch, S. Hallsteinsen, E. Stav, F. Eliassen, K. Lund, E. Gjørven “Using Architecture Models for Runtime Adaptability”, IEEE Software, March 2006.

system composition and reconfiguration in ubiquitous ... · system composition and reconfiguration...

Documents