AusercentriccompositionmodelfortheInternetofServices

A.Corradi,E.Lodolo,S.Monti,S.Pasini
DEIS,UniversityofBologna
VialeRisorgimento2,40135Bologna(BO),Italy
{acorradi,elodolo,smonti,spasini}@deis.unibo.it
AbstractInthemodernInternetofServicesscenarios,users
need to create, share and access contents and services in
extremelypersonalizedwaysandbymeansofheterogeneous
devices and interaction channels. The most promising
architecturalsolutionstocopewithsuchdynamicandever
growing scenario adopt a service oriented approach and
leverageservicecompositionplatformstoflexiblyarrangenew
valueadded services made up of basic offtheshelf
components.
Though, current solutions for service composition target
ratherstaticscenariosandscarcelysupport today'sdynamic
Web, where new services and contents continually become
availabletosatisfynoveluserneedsandservicecompositions
maybecomeobsoleteandneedreconfiguration.
We propose a novel composition model that aims at being
extremelyflexibleandextensible,yetremainingeasilyusable
byhidingcomplexitytousers.

1Introduction
Today, the Web paradigm is undergoing a dramatic
revolution,shiftingfromatraditionalcontentrepositoryto
a collaborative space where users create and share
contents and services and access them in the most
pervasiveandubiquitousway[1].Usersmoreandmore
need to participate in service and content creation and
exploitation: weblog and folksonomies such as
del.icio.us have been the forefront of these new
scenarios,withuserscollaborativelycreatingandsharing
theirowncontents.However,userneedshaveevolvedone
stepfurther:usersrequirenowtodynamicallyaggregate
and compose thirdparty contents/services to realize
personalizedmashups.IntelMashMakerandYahooPipes
are interesting platform prototypes that enable complex
contentaggregationinauserfriendlyway.
Moreover,theseInternetofServices(IoS)scenarios
[2]aimatdisclosingtraditionalservicesandcontentstoa
newecosystemofdevices,topervasivelyreachusersno
matter when, where and with which device they are
connected. The rapid emergence of different wireless
networks and of heterogeneous devices calls for more
versatile and customized ways to access services and
contents.
In these extremely dynamical and everchanging
scenarios, serviceoriented architectural models are
rapidly gaining momentum as a way to tame the
increasing complexity and heterogeneity. Service
abstraction promotes modularity and reuse of software
components, and adoption of wellknown interfaces
enables to compose and orchestrate services into more
complexandvalueaddedserviceaggregations.
Research in the service composition field aims at
proposingstandards,architecturesandtoolstoeasilybuild

978-1-4244-2703-1/08/$25.00 2008 IEEE

composite applications from basic building blocks

(services). Even though interesting results have been
alreadyachievedandstandardsarearising,currentservice
compositionsolutionstoooftenmisstherightabstraction
level. They tend to have either vertical approaches, by
focusing only on specific application domains, or too
generic approaches, by imposing unnecessary overhead
andresultingoverwhelminglycomplex.Moreover,sofar
these platforms have often been limited to businessto
business integration and therefore can hardly cope with
novel dynamic useroriented scenarios suggested by the
IoSlandscape.
Our system UCIS (Usercentric Composer for the
Internet of Services) promotes a novel, open, dynamic,
anduserorientedservicecompositionmodelthatallows
users to easily and dynamically describe, arrange, and
enforcecomplexpreferences.Newservicesandcontents
canbepluggedinatanytimewithlittleornoeffortonthe
service/contentprovideranduserscanimmediatelyexploit
them, arranging and enforcing complex aggregations.
Besides, our platform assists users in easily expressing
requirements and hides all the burden that comes from
mapping almost natural language user statements into
strictandsolidlyconfiguredservicecompositions.
Section2presentscurrentstateoftheartinservice
composition,whileSection3describesprinciplesofour
proposal.Section4deepensdescription ofourplatform
andSection5presentsconcreteusecasesourproposalis
able to cope with. Section 6 provides implementation
details.Finally,Section7reportsconclusionsanddepicts
futureworktoextendtheproposedplatform.
2Servicecompositionenabling
Serviceoriented architectures (SOA) promote the
encapsulationofapplicationlogicwithinservicesandthe
adoption of welldefined interfaces that act as service
contractsandspecifytheirbehaviorandinteractiondetails
[3].Inrecentyears,SOAapproacheshaveemergedasa
means to model large distributed systems, by hiding
implementation detail complexity and promoting
applicationlogicmodularityandreuse.
Servicecompositionpushesfurthertheseprinciples,
byaggregatingbasicservicesintomorecomplexones,to
obtainvalueaddedcompositions[4].Servicecomposition
platforms typically offer abstractions and tools both to
define composite services (by means of composition
models,languagesanddevelopmenttools)andtoexecute
composite services (through runtime execution
environments).Thoseplatformswereprimarilytargetedat
composingservicesforratherstaticscenarios,wherenew
servicesbecameavailablerarely.Insuchstaticscenarios,
110

service composition platforms generally led to build

compositionswhosevaliditywastypicallylonglasting.
Theevolutiontowardubiquitouscomputingscenarios
goes beyond these assumptions and calls for more
dynamicservicecompositionmodelsandplatformsthat
cancopewithservicesappearinganddisappearingoften
andatanytime[5].Indeed,changesinuserrequirements
(e.g., features of the device in use) as well as service
availability variations often can make existing
compositionslessadequateorevenuselessandthelackof
support for dynamic reconfiguration can become an
unbearableburden.
Researchtriedtotackletheseissuesbyfocusingona
semanticapproachandbyarguingthat,forcomposition
platformstobeabletodynamicallyarrangeandcompose
services,theyshouldspecifyhowservicescanbeaccessed
byotherservices,frombothasyntacticandasemantic
standpoint. This entailed coupling the typical WSDL
based service syntax description with solutions for
semanticdescriptionofservices. Researchinthisfield
proposed a wide range of solutions, from custom
applicationdriven formalizations to widely adopted
ontologydefinitionstandards[6,7].Theseapproachesalso
leveragedcompositionmodelsbaseduponrulestocheck
forservicecomposability(determiningifgivenservices
areabletointeractwitheachother)andtorankservice
compositions (specifying how well composable services
areabletointeract).
These approachessometimes tend tomiss the right
abstractionlevel.Someadoptatooverticalanddomain
specific semantic description, and thus limit support to
dynamic service extension and/or addition. On the
contrary, others [8] choose a too generic semantic
definition, becoming extremely ineffective, poorly user
transparent and practically unusable for dynamic
scenarios.
Other solutions [9] substitute the rulebased
composition model with a graphbased one and thus
leverageservicesemantictodynamicallygeneratepaths
amongavailableservicestofulfilluserrequests.Themain
drawbackoftheseapproachesreliesinlesspredictability
ofthefinalcomposition:userscanspecifyrequirements
oncompositionstages(typicallytheinitialandfinalones)
but can hardly express requirements the overall
compositionshouldcomplywith(e.g.,QoSboundaries).
3.Composabilitymodel
Inouropinion,toovercomecurrentissuesinservice
compositionfortheIoSscenarios,acompositionmodel
shouldsupportaflexibleanddynamicallyextensibleway
toevaluateservicecomposability.
Servicesconstitute thebasic building blocks ofour
model and embody generic pieces of application logic
whosefeaturesaredescribedbyasetofmetadata.Service
providersshouldbeabletospecifyservicemetadatainan
intuitiveandeasilyextensibleway,thuseasilyallowingto
dynamically plug in new services and possibly offthe
shelf components. Also users should beable tospecify
complexaggregationsofcurrentlyavailableservicesinthe

mostintuitiveandnaturalway.
Tofacetheseissues,ourmodelneedsatranslucent
approachtoservicecompositiondefinition,bothtoguide
users in service composition creation, by hiding
complexity and composition detail, and to still remain
extremely (re)configurable, flexible and reusable,
unveilingcompositionmechanismdetails.Weproposeto
achieve this with a templatebased approach, with
templates that act as models of possible service
compositions and typically embody common underlying
featuresofdifferentapplicativescenarios.
Inourmodel,noveltemplatescanbepluggedinatany
timetofacenovelscenarios,aswellasnewservicescan
beaddedtoprovideneworalternativefunctionalities.To
achieve decoupling, we propose a dynamic rulebased
approach,whererulesandmetadatadictionariesarenot
predefined,butdependonuserrequirements,composition
templates and actual services. Different kinds of rules
govern both the choice of currently available templates
andservicestoexploitandhowservicesandtemplatescan
actuallybearrangedinacorrectandsafeway.
3.1Designprinciples
We strongly believe that service composition is the
keytoprovidecustomizedandvalueaddedserviceswhile
mastering complexity anddependenciesamongsoftware
components. By composing heterogeneous services into
complexbusinessprocessesitispossibletosupportusers
intheirownIoSexperience.
In our vision, outlining a service provisioning
scenario by means of service composition must be as
simpleasshapingacorrespondingtemplateandindicating
thefeaturesoftheservicesthatwilltakepartinit.Weuse
metadata'attributes'todescribetheservicefeaturesand
'rules'toexpressconstraintsontheacceptablevaluesof
thesefeatures.
Every'compositiontemplate'definesthecomposition
schemathatrealizesitscorrespondingscenario,the'roles'
that services playinit,andrulesonthefeaturesofthe
servicesplayingthoseroles.
'Services'arenomorethanpiecesofbusinesslogic
that have tofit a particular role in the overalltemplate
schema, in order to realize the desired composition.
Besides composition templates, also services can
introduce constraints (by means of rules) on the other
services they have to collaborate with, to enforce
interoperability.
The choice of the desired composition template
obviouslydependsonthefinaluserandherneeds.Wecall
'userrequirements'thesetofalluserrelatedinformation
thatcandrivethisprocess.Forinstance,ausercanchoose
togetasynchronousnotificationsofnewsonsports(e.g.,
bymailorMMSmessages)aswellasdecidetoreceive
them ondemand (e.g., by sending an SMS request
messageorbybrowsingtoacertainURL).Furthermore,
userrequirementstoocaninfluencetheservicestochoose:
asanexample,userpreferencescanindicateherfavourite
news service, while profile information can drive the
choice ofthe cheapest MMS gatewaybybasingonher

111

mobilephonecompanyandusercontextcansetthesizeof
theimagestoembedintheresponsemessage,givenher
currentdisplayresolution.Justlikeconstraintsfromthe
compositiontemplateandtheservices,theseconstraints
toocanbeexpressedbyrulesonservicemetadatavalues.
Available rules are not provided as an 'a priori'
knowledge,butareintroducedbycompositiontemplates,
services and user requirements themselves. Anyway,
candidatesforcompatibilityevaluationobviouslyhaveto
refertocommonsetsofrules.Weenablethisbymodeling
eachsetasadomainofrulesandbyreferringtodomains
via their name, resembling the namespacelike idea of
shared knowledge base. For instance, the 'datatype'
domain could group rules about data compatibility
between interacting services. Similarly,the 'aggregation'
domain could group rules for content aggregation
templates to indicate the services that generate suitable
content.
3.1.1Compositiontemplates

Composition templates represent the abstract

definitionofbusinessprocesses.Theirgoalistoindicate
thecompositionschemaandtheexpectedfeaturesforthe
servicesthatwilltakepartinit.Figure1showsapossible
compositionasasetofemptyblocks,representingservice
instancesandcontrollogic.

Of course, in order to enforce reuse of existing

templates (and, possibly, of their alreadycomputed
actualizations),atemplatecanbedefinedintermsofother
ones.Toclarifythis,figure3illustratestwocomplexkinds
ofcompositiontemplatethatthefinalusercanexploit.

Figure3Reuseofcompositiontemplates

3.1.2Services

Serviceinstancesprovidetheactualimplementations
of ubiquity support features like content transcoding,
generation,delivery,enrichment,aggregation,adaptation,
filteringandsoon.
AccordingtoUCISattitude,indeed,noframeworkto
support ubiquity should aim at providing this kind of
facilities on its own, as this approach leads to limited
flexibility and to overwhelming complexity in API
definitionandusage.Rather,ubiquitysupportframeworks
shouldenablethirdpartyproviderstoregistertheirown
products,todescribethemandtoindicatehowtointegrate
themwithbothframeworkcapabilities(e.g.,messaging,
persistence,naming,...)andwithotherservices(i.e.,in
UCIS,withincompositiontemplates).
To enforce this possibility we leverage metadata
attributes. Services can provide metadata to describe
almostanyoftheiraspects,withoutaffectingtheiractual
implementation. Figure 4 briefly reports some of the
attributesforatexttospeechsynthesizerthatcanreceive
requestsandsourcetextonatelnetportandexposesits
results,inwaveformat,viaFTPprotocol.

Figure1Compositiontemplates

Theactualizationofacompositiontemplatewithreal
servicesistheresultoffillingemptyblocksbysatisfying
Figure4Servicemetadatasample
all templaterequired features and all service
composabilityissues.Figure2givesasnippetoftheresult
Atthesametime,byprovidingadditionalrules,every
ofsuchactualization.
servicecanmandateparticularfeaturestotheservicesit
interoperates with, helping UCIS to discard impossible
compositions.
Thesetofpossiblemetadataisnotpredefined,butcan
be enlarged at any time. For instance, a service can
introduce a new type of metadata in the system just
presentingvaluesforit.Asanalternative,itcandefineit
implicitly,byimposingrulesonthepossiblevaluesfrom
interactingservices.
3.1.3Userrequirements

Figure2Actualizationsofcompositiontemplates

Userrequirementsaremadeupofanyavailablepiece
of userrelated information such as context (e.g., her
currentlocation,connectivitytype,screenresolution,...),
profile(e.g.,mailaddresses,phonenumbers,gender,...),
andpreferences(e.g.,favouritenewsservices,...).
112

Besides we also adopt the concept of user

requirements asameans toconveythe selectionof the
particularIoSscenariothattheuserdesires,intermsof
oneofherpreferences.Finally,availableoptionsforthat
scenarioareexpressedasadditionalrulesonthefeatures
oftheservicetocompose.
By providing to UCIS information about the user
herself and rules on the services to compose, user
requirements determine the composition template to
realizeandinfluencetheserviceselectionprocess.
3.1.4Rulesandroles

Templates, services and requirements do not know

abouteachotherdirectly,butjustteachthesystemwhat
theyneedbymeansofrules onattributesfromservices
and/ortherequiringuser.
Aruleisasetofstatementsentailingattributesfrom
userand/ormetadataofservices.Onerulecaneitherlead
toabooleanresult(satisfiedmandatorycondition),ascore
(enablingranking)orafailurecondition(impossiblerule
evaluation). Leveraging the rules that requirements,
templatesandservicesentail,UCISchoosestheservices
to compose to provide the composition that user
requirementsindicate.Thenitjustverifiesthatallrules
aresatisfiedwiththem.Ifaservicedoesnotprovidea
suitablevalueforevaluation,itissimplydiscardedfrom
thesetofcandidateones.
Rulesarejustlikemathematicalformulas;attributes
withinrulesarethevariablesandtheyeitherrefertouser
characteristicsorareresolvedtoactualvaluesofservice
metadata.Oneproblemstillstands:whotellsserviceA
hastoprovidetheattributetoplaythepartofvariable'x'
andserviceBtheoneforvariable'y'?Arethecomposition
templatestodrivethechoice,byenablingruleevaluation
throughthenotionofroles.Rolespermitexpressingrules
intermsofpropertywithnameP1fromtheservicewilling
toplayroleR1hastosatisfyrulerwithrespecttoproperty
with name P2 from the service willing to play role R2.
Thus,service attributesarereadfromtheservicesbeing
respectively considered to play the roles that the
compositiontemplateexpects.Forinstance,toguarantee
datatype compatibility between two services, we could
formulatetheruleinlisting1:
producer.datatype == consumer.datatype

Listing1Asimplerule

Role concept does not tie to any particular

composition template; rather, roles represent shared
semantic notions composition templates and rules can
referto.Toclarify,whetherthecompositiontoachieveisa
pushprovisioningoneoracontentaggregationone,
'producer' and 'consumer' roles apply every time one
serviceworksontheresultfromanotherone;thus,rules
canrefertothesamerolename.
Asaconsequenceofthereuseofrolenames,rulestoo
become valid across different templates (so that one
service can candidate for several actualizations just by
exposinglimitedsetsofmetadata)andtheydonottieto
anyoneofthem.Weenabledgroupingrulesintodomains
andreferringtoaparticulardomainjustbyindicatingits

correspondingname.Requirementsaswellastemplatesas
well as services do not explicitly require one particular
ruletobeevaluated;rather,eachoneofthemjustdeclares
thenamesoftheruledomainsitdependson.Everyrule
domain, hence, applies as a whole to the composition
actualization,requiringallofitsrulestobesuccessfully
evaluated.
3.2Advancedfeatures
Rulesevaluationcanproducenotonlybooleanresults
(meaning that composition actualization is acceptable),
but any kind of value type. By leveraging nonboolean
results as composition 'scores' it is possible to enable
compositionrankingandautomaticchoiceamongseveral
possiblecompositionactualizations.
Bybasingonscores,userrequirementscanstatethe
particularkindofrankingtoperform,perhapsdepending
on userspecific preferences. Indeed, a composition will
typically show more than just one score value (e.g.,
numberofservices,computationalload,billingcosts,...)
and there is no 'a priori' way to tell which one should
prevail. User requirements, hence, are in charge of
indicating weights for each score type and the relative
orderofimportance;scoresthatarenotentailedbyuser
requirements are simply ignored. Thus, UCIS can
autonomouslycalculatethemostsuitablecompositionthat
satisfiesthecompositionrequestfromaparticularsetof
userrequirements,giventheservicescurrentlyregistered
tothesystem.
Dealing with modern IoS scenarios, where user
conditionscanvaryinextremelydynamicways,automatic
and efficient composition (re)calculation can become
really effective if the system can monitor relevant user
characteristicstolearnwhenandhowtoperformit.UCIS
enablesthisbymeansofaparticularkindofrules,called
'monitoring rules'. Monitoring rules not only evaluate
whenUCIScalculatesthecomposition,butalsoregisterto
the system the properties to monitor andtherules they
must satisfy. When a monitored property changes, the
compositionsthatdependonitmaybecomenomorevalid
andsotheyareforcedtochecktheirownvalidityandto
recalculate in case of failure. Besides, this can happen
asynchronously, every time a change arises, and not
synchronously, when the user demands results from a
servicecomposition.Hence,reconfigurationcanbepro
activeandbringlittleornoimpactonuserexperience.
4Platformdetails
As described in the previous section, UCIS model
requires:
serviceimplementationstoprovidemetadata;
compositiontemplatestodeclareroles;
userrequirements,compositiontemplatesandservice
implementationstoindicaterules;
candidateservicestoenterruleevaluationbyplaying
theroletheyarebeingconsideredfor.
Figure5illustratestheschemaofthecompositionproblem
actors.

113

Figure5Actorsofthecompositionproblem

namesreferringtherulesthattellaboutservicesuitability
and composability with the other services in the
composition.Inourcurrentimplementation,adomainof
rulesisdefinedas:
auniquename;
asetofrules;
asetofrolesthatitsrulesbaseon;
asetofattributesthatitsrulesexpect.
For implementation simplicity, every domain is also
associated to the URL where its XML definition is
published.Assoonasanentitybeitaservice,template
or user requirement entails a new rule domain, the
systemcanachieveknowledgeofthatparticulardomain
simply by downloading its definition from the
correspondingURL.
Toprovideabriefexample,listing3reportsanexcerpt
ofrulesfromthe'datatype'domain.Asthetextsuggests,
these rules can be used by UCIS to assert serviceto
servicecomposabilitywithinacompositiontemplatethat
expectstherolesof'consumer'and'producer':

Forsakeofintegrationwiththeframework,candidate
servicestypicallyprovideadditionalinformationsuchas:
name,provider,version;
lookup and invocation mechanism (e.g, EJB3,
WebServices,CORBA,...);
expectedparametersandhowtheymaptoframework
entities(e.g.,argument#1insignaturecorrespondsto
XXX/YYY/zzzpartoftheuserprofiledescription);
To enable servicetoservice composability, instead,
serviceshavenottoadheretoanyparticularinformation
format,buttheysimplyhavetoindicate:
asetofattributenamesandvalues;
<rule domainName="datatype" type="boolean">
the rule domains that express conditions to
producer.outputformat == consumer.inputformat
</rule>
successfullycomposewithotherservices,giventhose
<rule domainName="datatype" type="boolean">
consumer.inputmime isSupersetOf producer.outputmime
attributes;
</rule>
theruledomainsthatexpressconditionsuponwhich
Listing3Samplesyntaxrulesforproducerandconsumerroles
serviceexecutioncanbeperformed.
Listing 2 shows the values of metadata from a typical
Asforuserrequirements,theyaresimplyrealizedby
contentgenerationservice,capableofextractingweather
anobjectthat:
forecastsfromMETARmessages[10].
indicatestherequiredcompositiontemplate;
<?xml version="1.0" encoding="UTF-8"?>
can impose required features to the services to
<properties>
<comment>Service for reading location-aware METAR messages
compose;
published at a given url</comment>
<!-- Framework-integration metadata-->
definestherankingcriteriathatgoverntheelectionof
<entry type="fwk" name="general">
thebesttemplateactualization,incasemultipleones
name=MetarReader;provider=Swimm;version=1.0.0</entry>
<entry type="fwk" name="deployment">
arepossible.
mechanism=EJB3;jndihost=137.204.58.65;
jndiport=1099;jndiname=metar-app/ReaderBean/remote;
Listing
4 provides a brief XML example of user
interface=it.swimm.impl.generation.METAR.ReaderRemote;
clientlib=MetarAPP-client-lib.jar;method=read</entry>
requirements description, where the requesting user is
<entry type="fwk" name="mapping">
simply identified by her unique identifier within the
args=request/url,user/context/location/coordinates</entry>
<!-- Service-composability metadata-->
hostingframework.
<entry type="cmp" name="typology">type=generation</entry>
<entry type="cmp" name="load">avg=low</entry>
<entry type="cmp" name="billing">fee=0.001c</entry>
<entry type="cmp" name="datatype">
outputmime=text/plain;outputformat=METAR</entry>
<entry type="cmp" name="semantics">
pull=true;push=false;before=none;after=one</entry>
...
</properties>

Listing2Sampleofservicemetadata

Metadataaresimplynamevaluepairsandtheyobeyno
particularformat.Thefirstthreeentriesinthelistingare
frameworkspecificandlettheservicedeclare,forsakeof
invocation,thatitrunsasanEJB3onhost'137.204.58.65'
withtheJNDInameof'metar-app/ReaderBean/remote'
[11].Besides,itexpectstwoarguments:theURL(coming
fromtheuserrequest)wheretoreadMETARmessages
andthecurrentusergeographicalposition(asmappedto
the '/user/context/location/coordinates' element of
her context). Composability metadata, instead, just
representthefactthatasfarasacertainruledomainis
considered,theserviceprovidesacertainsetofattributes.
Forinstance,accordingto'datatype',theserviceformats
itsresultsas'METAR'andtheirmimetypeis'text/plain'.
Keys'datatype'and'arguments'arejustthedomain

<?xml version="1.0" encoding="UTF-8"?>

<user fwk="swimm">31231</user>
<template name="pushAggregation"/>
<properties>
<entry type="cmp" name="delivery">channel=MMS</entry>
</properties>
<ranking>
<score weight="1.5">billing</score>
<score weight="1">performance</score>
</ranking>

Listing4Simplifieduserrequirementsdescription

Likeroles andruledomains, scorestoorepresenta

knowledgethatisnotprovidedbyUCIS'apriori'andthat
systementitiescanshare.Indeed,scoresdonottietoa
particular domain, but can be the result of rules from
several different domains. Hence, every kind of score
defines:
adatamodelforitsrepresentation;
afunctiontoaggregatevaluesforthatkindofscore,
comingfromdifferentdomainsofrules;
a comparison function for the relative ranking of
compositions that show different values for a same
kindofscoring.
Listing5reportsasamplescoredefinition.
114

list_of_services2roles_maps.add(
<?xml version="1.0" encoding="UTF-8"?>
<score name="billing">
<format type="java.lang.Double"/>
<compare>&gt;</compare>
<aggregate>+</compare>
</score>

Listing5Exampleofscoredefinition

Finally, monitored properties come in the form of

particular attributes that map to wellknown framework
properties (e.g., user context parts, system properties,
etc..). For instance, listing 6 completes the METAR
servicemetadatabyarguingonnotnullablevalues,data
format constraints and allowed ranges (i.e., Bologna
metropolitanarea).Whethertheuserhasnovalidposition
orsheisoutsidetheservicescope,theservicemustbe
substitutedbyanotherone(maybenotlocationdriven
e.g.,forecastsforthewholeuser'scountryorrelatedto
anothergeographicalareaandperhapsatanotherbilling
cost). If substitution is not possible, the composition
becomes unavailable until UCIS succeeds again in
calculatingit(e.g.,newavailableservicesorchangesin
usercoordinatesarise).
<?xml version="1.0" encoding="UTF-8"?>
<properties>
<comment>Service for reading location-aware METAR messages
published at a given url</comment>
...
<!-- Monitoring metadata-->
<entry type="mon" name="notnullable">
props=user/context/location/coordinates</entry>
<entry type="mon" name="allowedformat">
props=user/context/location/coordinates,LatLong</entry>
<entry type="mon" name="allowedrange">
props=user/context/location/coordinates,[44.55,11.17]/[44.
44,11.42]</entry>
</properties>

Listing6Metadataformonitoringproperties

4.1Rulesevaluation
Thesolutiontothecompositionproblemissimplya
mapofrolesandcorrespondingserviceswhere:
everyroleofthecompositiontemplateisplayedbya
service;
all rules from user requirements, composition
templateandservicesaresatisfied.
To accept a service in a composition role, it is
necessary that all indicated rules successfully evaluate
against all the rest: the services already in the
composition, the composition template, and the user
requirements.Thesameappliestotherulesfromtheother
servicesthathavealreadyproposedascandidatesforthe
other roles in that composition. Finally, also the rules
specified by the composition template and the user
requirementsmustofcourseremainvalidasnewservices
areacceptedascandidates.
To demonstrate a possible implementation of the
solutiontothecompositionproblem,listing7 reportsan
almostselfexplanatoryandimperativeformulationofthe
algorithm that, given the above actors, leads to the
election of the most suitable composition to meet user
requirements.
Composition compute(UserReq req, Service[] available_services) {
// Step 1.1 Rules from requisites and templates, individually
List< Set< Map<Service,Role> > > list_of_services2roles_maps;
foreach domain in domain_union(req.domains,req.template.domains)
foreach rule in domain.mandatory_rules

/* applies rule to the possible role-service pairs,

saving every allowed combination as services2roles map,
returning the set of the possible maps */
evaluate(rule, req.template.roles, available_services)
);
// Step 1.2 Intersection of results from individual rules
Set< Map<Service,Role> > services2roles_maps =
/* keeps only the maps that are present in all list items
(i.e., that are allowed by all rules) */
intersection( list_of_services2roles_maps.entries );
// Step 2 Rules from the candidate-to-roles services
/* note: a cloned structure is used to avoid removing
entries from a data structure that is being iterated */
Set< Map<Service,Role> > allowed_services2roles_maps =
clone( services2roles_maps );
/* requirements- and template- allowed maps of services to
roles associations are validated against rules from service */
foreach map in services2roles_maps
foreach domain in domain_union( map.keyset )
foreach rule in domain.manadatory_rules
/* evaluation is skipped if current map
has already been discarded */
if (

map in allowed_services2roles_maps )

/* same behavior and result type as

evaluate( rule, req.template.roles, candidates )
but with already-known services-to-roles associations */
if (

evaluate( rule, services2roles_map ) == null )

/* failure leads to discarding the current map */

allowed_services2roles_maps.remove( map );
// Step 3.1 Scoring
List<Composition> allowed_comps;
foreach map in allowed_services2roles_maps {
Composition comp = new Composition( req, map );
/* domains of an actual composition are the union of
those from services in the map, requisites and template */
foreach domain in comp.domains
foreach rule in domain.scoring_rules
comp.assign( score( rule, comp.map ) );
allowed_comps.add( comp );
}
// Step 3.2 Ranking
Composition best_comp = rank( req.criteria, allowed_comps );
// Step 4 Monitoring
foreach property in comp.monitored_properties
Framework.monitor( property.value, property.rule );
// Step 5 Resource allocation
Framework.register( best_comp );
return best_comp;
}

Listing7Compositionalgorithm

Every candidate service that plays a role in the

compositionbringsitsownrulesofevaluation.Thisleads
toatreeofpossiblechoiceswherenodescorrespondtothe
available roles. The first service being considered for a
roleinthecompositiontemplateistherootofonepossible
tree. At any depth, to accept a service in the tree as a
player for a vacant role, the rules it entails must be
satisfied, as well as the rules from the rest of services
alreadyinthetree.
Actual implementation of the evaluate() function
exploresservicetreesdepthfirstandstopsuponfindinga
given (but configurable) number of acceptable
composition actualizations to rank and choose from.
Optimizationstrategies,forinstance,startfillingtherole
that probably has the lowest number of available
candidates (we called it perrole early pruning) and
consider candidates in the order they bring the lowest
numberofnewrulestothesystem(namedasinformation
basegreediness).
Whenallrolesarefilled,allentailedrulesneedtobe
satisfied.Theoretically,thereisnoconceptualdistinction

115

amongthosecomingfromuserrequirements,composition
template or candidate services. Nevertheless, the rules
fromtheuserrequirementsandthecompositiontemplate
arepresentinalltreesandpermittodiscardimmediately
theoneswithunfitservices.Thus,itissmarttoprocess
thoserulesfirst:aservicenotprovidingattributesforor
not satisfying a requirements or templatedriven rule
cannotbeacandidate.
5Actualusecases
To implement actual use cases of dynamic and
contextdriven ubiquitous computing support, UCIS has
beenexploitedasthebusinessprocesscompositionengine
of a real framework for user support in pervasive IoS
scenarios [12]. Acting as a middleware,this framework
wasabletodecouplefinalusersfromthetaskofcreating
andexecutingservicecompositions.Besides,bymanaging
userprofile,contextandsessionproperties,itsucceeded
in leveraging UCIS to arrange the most suitable
compositionsuponchangesinuserconditions.
Below, we present a particular scenario we
implemented,whereuserscan:
subscribeto'periodicalreport'communications(push
mode)orexplicitlyrequestthem(pullmode);
choosemultiplesourcesofinformationfromareally
heterogeneous set, ranging from simple RSS
channels, to blog entries, newsletters, readers of
METARmessages(i.e.,weatherforecasts)orlegacy
webpages(withadhoc'scraping'services);
select one or more interaction modes among all
available ones, such as VoIP calls, SMS messages,
Podcast channels, traditional web pages or email
messages;
associate different modes to different conditions of
theircontextandprofile.
Figure6representsoneparticularservicecomposition
thatthis scenario entails. Atimer servicepublishes the
eventthattriggerscompositionexecution.Areaderofuser
preferencessubscribesforthateventandletsanewsletter
and an RSS reader service retrieve the information the
userisinterestedin.Ifnecessary,informationisconverted
to a format that the aggregator service can understand.
Finally,aggregationresultisconvertedtoavoicesynthesis
andaVoIPserviceperformsautomaticphonecallstothe
usermobilenumber.

Metadataprovideforservicetoservicecomposability
both at datatype and semantic level. This allows, for
instance,toautomaticallychoosetheserviceforcontent
processingbeforeaggregationaswellastofittheselected
outputchannelwiththeresultsofadaptationservices.In
particular, semantics metadata is the key tolet services
expresstheircapabilitiesofproducingcontent(e.g.,news
reader),workingtotransformresultsofotherservices(e.g,
voicesynthesizer),subscribingtoevents(e.g.,scheduled
timeforreport),handlingaparticulartypeofrequest(e.g.,
HTTP)andproducingcertainresulttypes(e.g.,HTML)
fortheoverallcomposition.Allmetadatahavetosatisfy
rulesfromeachotherserviceandfromuserrequirements
and composition templatetoproduceactual andcorrect
servicecompositions.
UCIS simply permits to add new services to the
existingonesandletsthemparticipateinthecomposition
templatesitalreadyknows,assoonasfinalusersselect
them.Thus,toenablenewchannelsandinteractionmodes
whilethesystemwasalreadyrunningandservingusers,
we simply registered additional delivery and adaptation
services. For instance, to provide Podcast channels we
introducedanWAVtoMP3encoderservicetoadaptthose
files to the usual Podcast format and a web publishing
service to finally expose the XML description of the
Podcastchannel,linkingthefiles.
Associating each interaction mode with the
correspondingusercontextconditionispossiblebyadding
dedicatedmonitoringrulestotheuserrequirements.These
rules just let the composition validity depend on the
desiredusercharacteristic.Indeed,noservicedrivenrule
couldturntobeusefulintheconsideredscenario,where
not services but users govern the choice. User
requirements,instead,achievethegoalinanelegantway,
entailing the rule to associate the required composition
templatetothedesiredusercondition.
A typical user, hence, can select several sources of
informationandgatherthem,forinstance,inasectionof
her customized home page, perhaps triggering update
every3hours.Anyway,sincesheisabletoseethepage
onlywhenloggedontothemiddleware,whensheisnot
she can have a selectionof the most important sources
gatheredinaVoIPphonecallpushedbythemiddleware
towards her mobile. Figure 6 already reported the
actualizationofthissecondkindofservicecomposition.
Figure7illustratesnowthatofthefirstone.

Figure6Actual'push'scenario
Figure7Actual'pull'scenario
To syndicate information, we adopt an XML
document schema built ontop of 'item' elements,
resembling the format of traditional RSS messages. 6Implementationtechnologies
Aggregatorservicebasesonthisdocumentschema,but
Implementation details of UCIS platform can prove
newkindsofgenerationservicescanenterthesystemat
howitcaneasilyapplytoexistingSOAplatforms.
runtimethankstoadaptationservicesabletoconverttheir
UCISconsistsofthreemainparts:
specificdatatypetotheformatsuitableforaggregation.
aregistryformaintainingmetadataoftheavailable

116

services;
anengineforruleretrievalandevaluation;
adatabaseforstoringandretrievingservicemetadata
anddescriptionsofactualcompositions.
Besides, to enable UCIS usage within existing
frameworks, we also provided API specification to
implement:
monitoring;
userandsystempropertyreaders.
MetadataregistryhasbeendevelopedasaJEEEJB3
component,exposingmethodsforadding,removingand
reading service attributes. The choice is due to ease of
integrationwiththeIoSsupportmiddleware,runningon
the JBoss application server [13], that was used for
implementingthediscussedusecases.
To remain extremely flexible and extensible, our
modelposesnoconstraintsontheactualimplementation
of metadata information. Anyway, to implement the
described use cases, we investigated and adopted an
OWLSbasedmetadatarepresentation.Inparticular,we
providedbothasetofcustomserviceprofilestodescribe
categories of services (such as SMS delivery or RSS
reading) and a set of related ontologies to extend and
enrichserviceprofilestodescribenonfunctionalfeatures
(suchasbilling,QoS,...).
OurruleevaluationenginehasbeendevelopedinJava
too,resemblingtheimperativeformillustratedinsection
4. Also rules, retrieved from their domainassociated
URLs, are written in Java. Runtime interpretation is
possible thanks to the BeanShell lightweight scripting
interpreter[14].
DatabaseinformationreliesonMySQLfacilities[15];
distributionandoptimizationisoutofthescopeofUCIS.
Ontopoftheaforementionedelements,monitoring
serviceisinsteadaframeworkspecificfeature,asitdeeply
relates to the framework notions of user context and
profile. UCIS only exposes a callback interface to
perform rule evaluation when a monitored property
changes,triggeringcompositionreconfigurationincase.
Finally, dealing with user context and profile
attributes, as they depend on the underlying framework
too,UCISsimplymandatestheframeworktoimplementa
labelbasedAPItoletUCIScomposeraccesstheneeded
values.

7Conclusionsandfuturework
ThispaperhaspresentedUCIS,anovelapproachto
dynamic service composition in pervasive computing
scenarios. UCIS adopts a usercentric approach to
dynamically and automatically arrange offtheshelf
componentsintocomplexcompositiontemplates,driven
bybothexplicituserrequirementsanduserprofile/context
conditions.
Toincreaseperformanceandplatformscalability,we
are also investigating caching, load balancing and
replicationtechniques.Inparticular,wearefocusingon
distributingcompositionalgorithmandreplicatingservice
metadataacrossnetworknodes(possiblyuptotheuser
device) to provide for better load balancing and more

efficient reconfiguration of service compositions upon

changedcontextconditions.Moreover,weareconsidering
caching portions of service candidate trees to optimize
composition(re)configurationandexecutioninextremely
dynamicscenariossuchasuserandterminalmobility[16].
Future work on UCIS will focus on the issues of
defining new richer composition templates for more
complexscenariosandoninvestigatingloadbalancingand
replicationimprovements.
Asforcomplexscenariossupport,wearefocusingon
supporting additional use cases by providing
corresponding composition templates. In particular, we
willconcentrateoncomplexusertousermultimodaland
multichannel interactions, such as enhanced instant
messagingapplications,providingcontentadaptation(e.g.,
fromtexttovoice)andprotocoltransformation(e.g.,from
Jabber[17]toMSN[18]).
Acknowledgments
Work partially supported by the SWIMM project
withintheEmiliaRomagnaRegionalICTPlan.
References
[1] M. Weiser, Ubiquitous Computing, IEEE Computer Hot Topics,
October1993.
[2] C. Schroth, T. Janner, Web 2.0 and SOA: Converging Concepts
EnablingtheInternetofServices,IEEEITProfessional,Vol.9,No.3,
pp.3641,MayJune2007.
[3]E.Ort,ServiceOrientedArchitectureandWebServices:Concepts,
Technologies and Tools, Sun Microsystems Inc.,
http://java.sun.com/developer/technicalArticles/WebServices/soa2/, Apr.
2005.
[4]G.Alonso,F.Casati,H.Kuno,V.Machiraju,ServiceComposition,
inWebServices:Concepts,ArchitecturesandApplications,Springer
Verlag,June2003.
[5]M.Boari,E.Lodolo,S.Pasini,S.Monti,Middlewareforautomatic
dynamic reconfiguration of contextdriven services, 11th IEEE
SymposiumonComputersandCommunications,Pula,Italy,June2006.
[6]W3Consortium,OWLWebOntologyLanguageOverview,W3C
Recommendation,http://www.w3.org/TR/owlfeatures/,Dec.2007.
[7] W3 Consortium, OWLS: Semantic Markup for Web Services,
W3CMemberSubmission,http://www.w3.org/Submission/OWLS/,Dec.
2007.
[8]A.Bouguettaya,B.Medjahed,"Amultilevelcomposabilitymodelfor
semantic Web services", Knowledge and Data Engineering, IEEE
TransactionsonVolume17,Issue7,Page(s):954968,July2005.
[9] S. Kalasapur, M. Kumar; B. A. Shirazi, "Dynamic Service
CompositioninPervasiveComputing",ParallelandDistributedSystems,
IEEETransactionsonVolume18,Issue7,Page(s):907918,July2007.
[10]

METAR

Data

Access,
http://weather.noaa.gov/weather/metar.shtml,2007.
[11]JavaEEataGlance,http://java.sun.com/javaee/,2007.
[12]A.Corradi,E.Lodolo,S.Monti,S.Pasini,Usercentricemergency
management:adisappearingmiddlewareapproach,WirelessRuraland
EmergencyCommunicationsConference,IEEE,2007.
[13]Jboss.comJBossadivisionofRedHat,http://www.jboss.com/,
2007
[14] BeanShell Lightweight scripting for Java,
http://www.beanshell.org/,2007.
[15]MySQLABTheworld'smostpopularopensourcedatabase,
http://www.mysql.com/,2007.
[16] P. Bellavista, A. Corradi, R. Montanari, C. Stefanelli, Dynamic
bindinginmobileapplications,IEEEInternetComputing,Vol.7,No.2,
pp.3442,Mar.Apr.2003.
[17] Jabber: Open Instant Messaging and a Whole Lot More,
http://www.jabber.org/,2007.
[18]MSN.com,http://www.msn.com/,2007.

117