Professional Documents
Culture Documents
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
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
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
Listing1Asimplerule
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
Listing4Simplifieduserrequirementsdescription
list_of_services2roles_maps.add(
<?xml version="1.0" encoding="UTF-8"?>
<score name="billing">
<format type="java.lang.Double"/>
<compare>></compare>
<aggregate>+</compare>
</score>
Listing5Exampleofscoredefinition
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
map in allowed_services2roles_maps )
Listing7Compositionalgorithm
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
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