HAL Id: hal-00675439
https://hal.archives-ouvertes.fr/hal-00675439
Submitted on 1 Mar 2012
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
DRAAS: Dynamically Reconfigurable Architecture for Autonomic Services
Emna Mezghani, Riadh Ben Halima, Khalil Drira
To cite this version:
Emna Mezghani, Riadh Ben Halima, Khalil Drira. DRAAS: Dynamically Reconfigurable Architec-
ture for Autonomic Services. A. Bouguettaya and Q.Z. Sheng and F. Daniel (Eds). Web Services
Foundations, Springer, pp. 483-505, 2014, 978-1-4614-7517-0. �hal-00675439�
EmnaMezghani
1,2,3
,Riadh BenHalima
1,2,3
andKhalilDrira
1,2 1
CNRS,LAAS, 7avenueduolonelRohe, F-31400Toulouse,Frane
2
Univ deToulouse,LAAS,F-31400Toulouse,Frane
3
UniversityofSfax, ReDCAD,B.P.W,3038Sfax, Tunisia
{emna.mezghani,khalil.drira}laas.fr,riadh.benhalimaenis.rnu.tn
Abstrat. The development and the provisioning of autonomi net-
workedservies areessentialfor enterprisesand fatoriesof thefuture.
Endowingservieswithautonomipropertiesallows onetomaintainat
runtimetheQualityofServie(QoS)inluding dierentparametersre-
latedtoperformane,availabilityandreputationsuhasresponsetime
and suessful exeution rate. Handling the autonomi properties re-
quirestheabilitytodealwithpermanentrequirementevolvingandon-
straint hanges. For instane, managing QoS degradation requires the
apaity of identifying its possible or atual soures and the apaity
ofreongurationplanning and exeution. Dealingwiththese issuesis
espeiallyhallengingfor webserviessinetheautonomisolutionhas
tobeseamlessfortheservierequesters,ensuringthatWebServiesare
alwaysusableunderthedierentdeploymentonstraints.Toimplement
suh autonomi systems, the literature provides dierent approahes,
varyingfromthedesignto thefullimplementationofautonomiprimi-
tives.Inthishapter,wepresentDRAAS:aDynamiallyReongurable
ArhitetureforAutonomiServiesable toprovideautonomiproper-
tiesfor QoSmanagementinwebservie-baseddistributedappliations.
DRAAShasbeenimplementedandexperimentedsuessfullywithdif-
ferent use ases. It overs the whole yle of autonomi management
inludingmonitoringandanalysisofQoSparameters,planningandex-
eution.
1 Introdution
The importantdata ows, the frequent interativity,the inreasing number of
onneteddevies, andthe networkunpreditabilitymakeritialthemanage-
mentofthenewdistributedsoftwaresystems.Inonehand,althoughthereform
ofveriationandvalidation ofsoftwaremodelshasn't easedimproving,om-
ponentsof the systemsmaystill hide designfaults resulting in systemfailures
or ome aross deadlokthat freezes thesystem. In theother hand, user
′
sre-
quirementsareevolvingfollowingtheend-usertehnologiesevolutionas mobile
phone emergene (Multimedia mobile and group-enabled appliation). In the
sametime,systemsonstraintsarevariableasunstablebandwidthanddereas-
ing energy. As a result, autonomi omputing paradigm is ruial for urrent
Morespeially,self-ontrolsystemssuhaselevatorontrolsystemsorrit-
ial systemssuh as spaeraftnavigationalsystemsneed robustnessto detet
anomaliesandavoidthembyreonguringthesystemsatruntime[1℄.Forthese
reasons,researh ators areaeleratingthework onautonomisystems. Suh
systemsareapabletodetettheproblemsand ontinuetooperatebymanag-
ingmalfuntionswithouthumanintervention.Autonomiomputingtehnology
doesnotonlyreduepotentialatastrophierrors,in ritialsystemsforexam-
ple,but italsominimizesthehumanintervention.Itisapplied whenreliability
and QoSare required. An autonomi system inspets and hanges itsown ar-
hitetureandbehaviorwhentheevaluationindiatesthattheintendedQoSis
notahieved,orwhenabetterfuntionalityorperformaneisrequired.
The autonomi omputing arhiteture is omposed of four modules and
a knowledge omponent that onstitute a ontrol loop namely MAPE-K [2℄.
Monitoring whihmonitorsthedataexhangedbetweenthemanagedelements,
AnalysiswhihdetetspossibleQoSorperformanedegradations,Planning that
implementsalgorithms for seletingand shedulingappropriateelementaryre-
ongurationationsandExeution whihperformsthem.
1
DA
F
W B
B B
2
Ia a
r ! r ra "# # o
t rs r$
M% Ͳb&%
M % % Ͳb&%
P'Ͳb&%
( ##s! r
Fig.1.Autonomiomputingsope
This autonomi omputing paradigm inludes the design and implementa-
tion of omputer systems, as shown in Figure 1. The rst step fouses on es-
tablishingadetailed designfromwhihresultsaframework oranarhiteture.
Frameworks present the skeleton of an appliation that an be ustomized by
thedeveloper.Wedistinguishtwotypesofframework[3,4℄:blakboxthatdoes
notneed adeep understanding of the framework's implementationin order to
useitandwhiteboxthatrequirestheinternalunderstandingof theframework
touseiteetively.Arhiteturesprovidehigh-levelabstrationofsystemom-
ponents, while enablingeasier understanding and interpretation. Furthermore,
step onentrateson implementing the arhiteture or the framework through
varioustehniques.Theimplementationmaybelassiedintothree ategories:
model-based,middleware-basedandplatform-based(seeFigure1).Model-based
solutions[57℄provideexpliitimplementationofallneessaryationsformoni-
toring,analysis,planningandexeution.Inthisategory(model-based),wefous
partiularly onarhiteturalapproahes.Monitoringandanalysis are madeby
testing iftherunning systemonformsto agiven arhitetural styleor model.
Middlewares,likeBionet[8℄,AgFlow[9℄, andOpenORB [10℄,support dynami
reonguration proess by oering primitives (like intereption) for all auto-
nomi omputing modules. Platforms [1113℄ provide developers with already
developedautonomi entities.
Inthispaper,weevaluateandlassifyasetofautonomisolutionsaording
to riteria suh as provided funtionalities, managed autonomi steps, applied
tehniques,programminglanguages,et.Weaimtoprovidefeatureswhihhelp
andguideuserstoseletasuitablesolutionforimplementingautonomiservies.
However,itisusuallydiultto selettheappropriateapproahtoimplement
an appliation. We think that this hoie depends on the size of the problem
to solve,the arhiteturetype(deentralized or entralized),the programming
language, the appliation area (Server or Client, et.), et. Then, wepropose
ourDRAASarhitetureimplementingtheautonomiomputingto ensurethe
dynamireongurationofwebservie-basedappliations.
Thispaperis organizedas follows.Setion 2givesanoverviewof theauto-
nomi omputing bakground. Setion 3 details dierentways to design auto-
nomisystem.Setion4desribesataxonomyofdynamireongurationimple-
mentation approahesfousing on the "model", "middleware" and "platform"
ategories.Setion5presentsourDRAASarhitetureillustratedbyausease.
Finally,setion6onludes thispaperandpresentsourfuture works.
2 Autonomi Computing Bakground
Autonomiomputing onstitutesanativeresearhareain omputersystems
[14℄. This paradigm, inspired from the human autonomi nervous system [2℄,
hasa mehanismthat an triggerhangesin theomputing systemstrutures
andbehaviorsinordertobypassororretthem.Furthermore,itisaolletion
of autonomi omponents that the overarhing goal is to manage themselves,
so that systems will be dynamially reongured at run time, with minimum
humanintervention.
2.1 Self-* Capabilities
Thepriniplesthatgovernallautonomiomputingsystems,aordingtoIBM,
havebeensummarizedineightaspets[15℄:
Self-Conguring:theabilityto dynamiallyongureomponentsfollowing
thedeployment,theinstallationofnewomponentsortheremovalofexisting
ones[1618℄.
Self-Healing: the ability of the system to pereive if it doesn't work or-
retly. It ensuresthe neessaryadjustmentsto restitute ittowardsitsnor-
malstate withouthumanintervention[19℄.By knowingabout thesystem,
itanalyzesinformation,detetssystemdegradationsandinitiatesorretive
ationswithoutdisruptingthesystemexeution.
Self-Optimizing:theabilityofthesystemto ontinuallyenhane itsperfor-
mane. It is a proative mehanism that detets performane degradation
andatsintelligentlysuhas inrealloatingresoureswithminimalhuman
intervention[16℄.
Self-Proteting:theabilityofthesystemtodetetandprotetitsresoures
frominternalandexternalattaksandmaintainitsseurity[2℄.
Self-Awareness: theabilityof the systemto knowitself and to be aware of
itsstateandbehaviors[15℄.
ContextAwareness:theabilityofthesystemtoknowitsexeutionenviron-
mentandbeabletoreattoitshanges[15℄.
Open:theabilityofthesystemtoworkinaheterogeneousworldandimple-
mentopenstandards. It should be portable arossmultiply hardware and
softwarearhitetures[15℄.
Antiipatory:theabilityofthesystemtoantiipateitsneedsandbehaviors
andtomanageitselfproatively[15℄.
2.2 Autonomi ComputingTehniques
Autonomi omputing is based on four main steps [2℄: Monitoring, Analysis,
Plan andExeution.
Monitoring tehniques Analysistehniques Plan&Exeution teh-
niques
Intereption[20,21℄ Arhitetural differ-
entiation[22,23℄
Substitution[24,10℄
Assertion[25,26℄ Behavioral differentia-
tion[27℄
Wrapping[28,29℄
AOP[3032℄ QoS-ontrat(SLA)[33℄ LoadBalaning[34℄
Refletion[10,35℄ QoS-aware (QoS his-
tori)[36,37℄
Rollbak[38℄
Redundany & Duplia-
tion[3941℄
Table 1.MAPE-klooptehniques.
Monitoring is usually dened as the at of listening, arrying out supervi-
sion on, and/or reording the ativity of a software entity for the purpose of
maintaining system reliability and QoS. Monitoring an be ensured using the
Intereption whih representsahook into exhangeddatabetween alient
andaserverallowingrequests/responsessupervision.
Assertion is aset ofode lines,introdued in aprogram,whih enablesto
ontrolandtoonstrainaprogram.
AOP(AspetOrientedProgramming)whihaimstoverifysystemproperties
andalsotoonguresope/onstraintsofeahfuntionanddisoverevena
tinyabnormalstate.
Reetion whih enablesto disoverand to operateon elds and methods
ofanobjetat runtime.
Analysisistheproessofdetetingpossibledegradationofthesystemthrough
theevaluationand theexaminationof monitoreddata. Analysisomparesur-
rent system behavior and arhiteture with a referene model. The following
tehniquesareusedbytheAnalysis (seetable1):
Arhitetural Dierentiation refers to ompare the obtained arhitetural
modeltothearhiteturalstyleofthesysteminordertodetetnon-ompliane.
Behavioral Dierentiation referstomapthebehaviorofanimplementation
tomodelbehavior.
QoS Contrat whih represents expliitly the system requirements under
ontratbetweenlientsandproviders.
QoSAware whih isbasedonthe historiofthe systemstate. Itompares
theurrentstatewithprevioussystemstates.
Plan&Exeution areomplementary.Infat,theplanpresentsasetofalgo-
rithmswhihrefertoonretereongurationationsenforedintheExeution
module. While,the Exeution refersto the at/theproessof repairing or the
onditionofbeingrepaired.Also,itmaybedenedashangesappliedtoasoft-
wareentity so that itreahesadesirablestate. Indistributed systems, several
tehniquesareusedto ahievetherepairproess(seetable 1):
Substitutionwhihreplaesasystemomponentbyanother.
Wrappingwhihsubstitutesasystemomponentbyanotherenvelopedwhih
presentsthesamebusinesslogi.
Load Balaning onsistsondistributing loadonavailableomponents.
Rollbak allowsthesystemtoomebaktothelaststablestate.
Redundanywhihrepeatsanationmorethanonetimeinordertoahieve
it.
Dupliation(repliation)whihinvolvesadditionofomponentsrepresenting
similarfuntionalities.
3 Autonomi Design and ImplementationApproahes
Software design is dened in IEEE610.12-90 as both "the proess of dening
thearhiteture,omponents,interfaes,and otherharateristisofasystem"
translation of requirementsinto anished system.The designof arhitetures
andframeworksisderivedfromthesystemspeiation.
From the implementation point of view, three main ategories of solutions
ouldbeused toimplementautonomi systems:themodel-basedategory,the
middleware-based ategory and the platform-based ategory. For the model-
basedimplementations[7,50℄,developersstartfromthesrathandshouldim-
plementallationsrelatedtoautonomiomputingmodules.Forthemiddleware-
basedimplementations[8,9,51℄,developersbuildtheirsolutionsbyadaptingba-
siprimitivestotheirappliationontext.TheprovidedAPIsinludeprimitives
formonitoring,analysis,planningandpossiblereongurationations.Theplat-
formategoryprovidesreusableomponentstoimplementautonomiomputing
strategies[1113℄.
Inthefollowing,wepresentindetailthedierentapproahesrelatedtothe
designandthethreeategoriesimplementingtheautonomiomputing.Wealso
study thedierentfatorsthat anguideto hooseaspeiedapproahrather
thananother.
3.1 Arhiteture design
Thearhiteturemodelsthestrutureofthesystem.Itprovidestheglobalper-
spetivesandahigh-levelabstrationenablingeasierunderstandingofsystems.
The work in [43℄ denes the arhitetural design as the high hierarhial
strutureofasystem.Itdesribestheoveralldesignofthesystemthat inludes
global ontrol struture, ommuniation protool, data aess,system ompo-
nentsandtheirbehaviors.
Theauthorsof [44℄ deneaderivativeofthearhiteture, namelydynami
arhiteture.Thistypeofarhitetureevolvesandhangesitselfduringruntime
asthesystemhanges.Itaimstodesignanautonomisysteminordertoensure
thedynamireongurationofsystem.
3.2 Framework design
Work in [45℄ denes a framework as a reusable design of all or partof asys-
temthat isrepresentedbyaset ofabstratlassesand thewaytheirinstanes
interat. Thesameauthor desribesthe framework in [46℄as aombination of
omponentsanddesignpattern.CEYLON[47℄,SAFDID[48℄andCatus[49℄are
examplesofframeworksimplementingautonomiomputinginordertodynam-
iallyreongurethesystem.Thepurposeofframeworksistoensurereusability
andextensibility,twomaintypesofframeworksaredistinguished[3℄:
White Box Framework: In a white box framework, we usually extend
behavior by reating sublasses, taking advantageof inheritane. A white
boxframeworkoftenomeswith soureode.
Blak Box Framework: In a blak box framework, the behavior is ex-
tendedbyomposingobjetstogether,anddelegatingbehaviorbetweenob-
jets.Wehavenoideaabouttehnialimplementationonlythefuntionality
Table2reapitulatesthedierenebetweenblakandwhiteframeworks.
WhiteBox Framework BlakBox Framework
Usesublassing UseCompositionanddelegation
Inheritane Polymorphism
Mustknowtheinternalstruture Mustknowinterfaes
Simpler,easiertodesign Complex,hardertodesign
Hardertoprogram Easiertoprogram
Table2.ComparisonbetweenWhiteandBlakBoxFrameworks
3.3 Model-basedimplementationapproahes
Model-basedsolutionsimplementallationsstartingfromthesrath.Noprim-
itives are oered. In this ategory, we fous partiularly on arhitetural ap-
proahesinwhihonstraintsanbeexpressedexpliitly.Managementmodules
are generally proposed to ensure the dynami reonguration proess. These
entitiesenablemonitoring,implementanalysisandplanning,andenforereon-
gurationations.
Thework desribed in [7℄ provides "Kinesthetis eXtreme" (KX),whih is
a generi framework for self-healing based on lightweight middleware. It is a
deentralized arhitetureusing event-basedsystem.It an beimplemented at
the middleware level or at the appliation level. The analysis is basedon spe-
i rules for error detetions. KX approah follows the funtional properties
of an appliation in order (i) to semantially analyze exhanged messages; it
playstheroleofproxyforapturingmessageontents(soureaddress,subjet,
message-ID)fordetetingSPAMmessages(ii)andtomonitorthebeginningand
theendofmethod allsin ordertodetetservieswhihrun inorretly.KXis
salableandanbeappliedtoaomposedsystem.However,ithaslimits:First,
thesenariosisimplementedwithmanually-writtenglueodeforattahingthe
external autonomi infrastrutureto the target system. Seond,the probe de-
ployment, the gauge derivation, and the onstrution of reonguration plans
areperformedmanually.
Rainbow[6,50℄ is aframeworkfor self-adaptivesystems.It isomposed of
two layers. First, the system layer, whih ollets information about the sys-
tem and enfores reonguration plans. Seond, the arhiteture layer, whih
reets the urrent arhiteture model, heks onstraint violations, and de-
termines the requiredadaptation. The arhiteture and systemlayers interat
throughatranslationinfrastruture.However,experimentalwork[52℄hasshown
thatthisexternalizedapproahforself-adaptationausesasigniantslowdown
ofthesystembehavior.Also,thisapproahsupposesthatthetargetsystemon-
tainshooks formonitoringand management.The reonguration planis built
manuallyandintegratedintheode.Noevaluationorvalidation ofthisplanis
Other model-based approahes use arhitetural styles designed to enable
autonomi omputing. In fat, an arhitetural stylerepresents aolletion of
designdeisionsthat havealreadybeenmade andan bereused.It onsistsin
afew keyfeatures andrules for ombiningthese features so that arhitetural
integrityispreserved.Fromthis ategory,weanmentionPrism[22,53℄whih
isanautonomiapproahbasedonomponentorientedarhitetures.Itisom-
posedof twolayers.Therstis theappliationlayerwhih inludes funtional
omponentsandexhanges messagesbetweenthem.The seondrepresentsthe
autonomilayer.Atthislayer,omponentsataseetors.Theyfailitatemon-
itoring,enating hanges, planning and deployment. These eetors areaware
of appliation-layer omponents and may initiate interations with them, but
notvieversa.Theproposed style,evenitisabstrat,seemsto beomplete as
it oversmostrequirementsfor autonomi system like adaptability, dynamis,
awarenessandrobustness.Itisoneofthefewapproaheswhihonsidersmobil-
ity. However,this framework doesnottarget asolutionforspei appliation
ontext, but itis ageneralapproahfor designingautonomisystems. Spei
funtionalities,likeoordinationandpoliiesarenotonsideredinthisapproah.
Theappliabilityofthestylehasbeendemonstrated.
Taylorandallpresentanarhiteturalapproahforautonomiomputing.In
[25℄,TaylorandOreizyproposeanapproahforself-adaptivearhiteture.This
approahisneitherimplementednorappliedtoaspeiappliationontext.It
fousesonsystemintegritywhihrequiresthemanagementofonsisteny,or-
retnessandoordinationofreongurationations.In[54℄,TaylorandDashofy
renethearhitetureproposedin [25℄.Theyexhibitastyle-basedapproahfor
autonomi systems.Theyprovideaninfrastrutureabletosupport thedesign,
validation andexeutionofreongurationplans.Thearhitetureisdesribed
using xADL 2.0 (XML-based Arhiteture DesriptionLanguage). The infras-
trutureis mainlydesignedforevent-basedsystems.However,thisarhiteture
isentralizedforsingleproesssystemsandnomehanismisonsideredforerror
detetions.
3.4 Middleware-based implementationapproahes
Themiddleware-basedapproahesprovideprimitiveshelping developerstoim-
plementautonomiomputingsystem.Inthefollowing,wepresentmiddleware-
basedimplementations.Detailsabouteahmiddlewarearepresentedintable3.
OpenORB middleware [10℄isbuiltonthebasisofreetivetehnology.Its
reetive arhiteture uses meta-objetprotools to perform integrations that
support dynami adaptation at runtime. The meta-models allow monitoring
and reongurationof misbehaviorsin order to preservethe arhiteturestyle.
Throughtheintereptionmeta-model,itanalyzesexhangedmessagesbetween
omponents and lient requests. The interfae meta-model provides aess to
theomponentimplementationwhilethearhiteturemeta-modelprovidesa-
ess to the objetgraph. Theillustration prototypedealswith the ontinuous
mediaowstransmissionqualitywhileintrospetingandreonguringavailable
demonstratesthat OpenORB providessuient support for small-salemulti-
mediaappliations.Toseuretheommuniationbetweenpeers,authorsof[10℄
saidthatitmaybedonewhileusingintereptors.
DynamiTAO [56℄isareetiveORB(anextensionoftheTAOORB).It
enablesdetetinghangesin environmentandreloadingnewomponentimple-
mentations whih maybebound to the systemat runtime. These features are
ahievedbytheuseofaolletionofentitiesknownasomponentongurators.
These onguratorsmaintain informationaboutthedependeniesbetweenthe
omponentstheymanage.TheDynamiCongurator inspetsomponentimple-
mentations (list_ategories,list_omponents,domain_omponent, impl_info,
omp_info, et.) andreonguressystemon they whileloadingor removing
implementationsstoredin aRepository. ThesalabilityofDynamiTAOisnot
improved.However,itisonlytestedwithasimpleexample(getHello()).TheDy-
namiTAOinfrastrutureinludes twomanagementseurity servies.Therst
isusedtorypt/deryptmessageontentsandtheseondauthentiatesommu-
niationpeerstoontrolaess.Theseuritystrategyanbeloadedandbound
dynamially to the system at runtime. This allowsthe use of a largerange of
seuritymodels.
Eternal[57℄isaomponent-basedmiddlewarewhihprovidesfaulttolerane
toCORBA-basedappliationsbyrepliatingomponents.Theautonomiom-
putingaspetisdevelopedasanexternallayerunderneaththeORBlayer.The
monitoring is based on the middleware intereption approah whih is trans-
parent to all ORB. Eternal intereptslient requests and transfersthem to a
repliationmangerintheaseofmisbehaviors.Asimpletestappliationisdone
in order to measure the performane of Eternal when a fail happen. It shows
thereoverytimerequiredfor reongurationwhile varyingthe sizeof theap-
pliationstateto transferarossthenetwork.Thedrawnurvepointsoutthat
thereoverytimeinreaseswhilethetransferreddatasizegoesup.Eternaluses
CORBAseurityservie(SeIOP)andintegratesSSLtoseureexhangedmes-
sages.Also,itimplementsarewallin ordertolterrequestsand aeptsonly
authentiatedlients.
