Publish/SubscribeinaMobileEnvironmentYongqiangHuang,HectorGarcia - PDF document

Publish/SubscribeinaMobileEnvironmentYongqiangHuang,HectorGarcia­MolinaDepartmentofComputerScienceStanford,CA94305yhuang,hector@cs.stanford.eduABSTRACTApublish/subscribesystemdynamicallyroutesanddeliverseventsfromsourcestointerestedusers,andisanextremelyusefulcommunicationservicewhenitisnotclearinadvancewhoneedswhatinformation.Inthispaperwediscusshowapublish/subscribesystemcanbeextendedtooperateinamobileenvironment,whereeventscanbegeneratedbymov-ingsensorsorusers,andsubscriberscanrequestdeliveryathandheldand/ormobiledevices.Wedescribehowthepub-lish/subscribesystemitselfcanbedistributedacrossmulti-ple(possiblymobile)computerstodistributeload,andhowthesystemcanbereplicatedtocopewithfailures,messageloss,anddisconnections.1.INTRODUCTIONpublish/subscribesystemconnectstogetherinformationprovidersandconsumersbydeliveringfromsourcestointerestedusers.Auserexpresseshis/herinterestinre-ceivingcertaintypesofeventsbysubmittingapredicatedenedontheeventcontents,calledtheuser'ssubscriptionWhenaneweventisgeneratedandpublishedtothesystem,thepublish/subscribeinfrastructureisresponsibleforcheck-ingtheeventagainstallcurrentsubscriptionsanddeliver-ingitecientlyandreliablytoalluserswhosesubscriptionsmatchtheevent.Thepublish/subscribecommunicationparadigmdiersfromtraditionalpoint-to-pointmodelsinanumberofways.Inpublish/subscribe,communicationisanonymous,inherentlyasynchronousandmulticastinginnature.Thesystemisabletoquicklyadaptinadynamicenvironment.Anonymitymeansthatthecommunicationpartnersarenotrequiredtoidentifythepartytheywanttotalkto.Forexample,insteadofnamingapublishertoreceiveeventsfrom,thesubscribersimplydescribesthecharacteristicsoftheeventsitwantstoreceive.Publish/subscribeisalsoinherentlyasynchronousbecausethesender(publisher)doesnothavetowaitforanacknowledgmentfromtherecipient(subscriber)beforemov-ingon.Thereliabletransmissionofeventstothesubscribersistakencareofbytheinfrastructure.Publish/subscribere-semblesmulticastbecauseitallowsapublishertosendthesameeventtomanysubscriberswithonlyonepublishop-eration.Finally,thesystemcancopewithadynamicallychangingoperationalenvironmentwherethepublishersandsubscribersfrequentlyconnectanddisconnect.Thiscombinationofuniquecharacteristicsmakesthepub-lish/subscribemodelwellsuitedtoavarietyofapplicationareas,suchasdistributedinformationdissemination,nan-cialanalysisandfactoryautomation.Inthepastdecademanyproblemsrelatedtopublish/subscribehavebeentack-ledandsolved,withsomesystemshavingreachedcommer-cialmaturity([19,20]).However,almostalloftheresearchonpublish/subscribesystemssofarhasconcentratedonpublish/subscribesys-temsinaxednetwork.Wearguethatpublish/subscribesystemsarealsoadvantageousinamobileand/orwirelessenvironment([9]).Theanonymityanddynamismofpub-lish/subscribeallowthesystemstoadaptquicklytofrequentconnectionsanddisconnectionsofmobilenodes,character-isticofamobilenetwork.Asynchronyishelpfulbecausemobiledevicesareoftenturnedoordisconnectedfromthenetworkforlongperiodsoftime.Wirelessdeviceshavelim-itedcapabilitiesandbandwidth.Themulticastingnatureofpublish/subscribehelpsasystemscaletomillionsofunits.Withincreasingpopularityofmobilehandhelddevices,thereisapressingneedtoextendpublish/subscribetoamobileenvironment.Asasampleapplication,inamilitarybat-tleeld,thousandsofwirelessandmobilesensorssuchassatellitesandequipmentsensorsreportallkindsofinforma-tionrangingfromthelocationofenemytroopstowhethertheengineofatankhasoverheated.Therearealsomanypartiesinterestedinreceivingcertaintypesofinformation.Anindividualsoldiermayneedtoknowthelocationofthenearestenemytroops,orwheneveramissilehasbeenred.Theabovescenariorequiresthedeploymentofahighlyscal-ableanddynamiccommunicationinfrastructure,forwhichamobilepublish/subscribesystemisanidealcandidate.Inthispaper,webrie yreviewafewpublish/subscribemod-elsanddiscusshowtheymightbeadaptedtoamobileen-vironment.Afterpresentingourframework(Section2),westartwiththesimplestmodel,namely,thecentralizedap-proach(Section3).Wethendiscussdistributedmodelsthataddressthescalabilityproblem(Section4).Finally,welook attheuseofreplicationanditsimpact(Section5).2.FRAMEWORKTherstgenerationofpublish/subscribesystemsuseeithergroup-based(alsoknownaschannel-based)orsubject-based(alsoknownastopic-based)addressing.Intheformer([4,10,14,18]),asetof\groups"(or\channels")aredesig-natedbythesystem.Eacheventispublishedtooneofthesegroupsbyitspublisher.Ausersubscribestooneormoregroups,andwillreceivealleventspublishedtothesubscribedgroups.Forexample,inIPmulticast([10]),eachgroupisidentiedbyaclassDIPaddress.Subject-basedsystems([15,13,19,20])areslightlymore exible.Eacheventistaggedwithashort\subject"(or\topic")thatde-scribesitscontent.Thesubjectiseitheranarbitrarystringorastringtakenfromanagreed-upondomain.Thesub-scriberdenesitssubscriptionintermsofthissubjectline.Inadditiontoanexactmatch,thesubscribercanalsoaskforallsubjectsbeginningwiththeword\jobs",forexample.Inrecentyearsamore exibleparadigmcalledcontent-basedaddressinghasemerged.Acontent-basedsystemgivesmore exibilityandcontroltothesubscriberbyallowinghim/hertoexpresshis/herinterestasan\arbitrary"queryoverthecontentsoftheevents.Therefore,insteadofrelyingonthepublishertoclassifytheeventsintogroupsorsubjects,thesubscriberisnowabletodenesophisticatedsubscriptionssuchas\givemeallstockquotesforstockXissuedbetweentimeAandtimeBifthepriceislargerthan35."Acontent-basedpublish/subscribesystemhasalsobeencalledcondi-tionmonitoringsystemsoreventnotication/distribution/-deliverysystemsinvariouscontexts.However,the exibilityofcontent-basedsystemscomesattheexpenseofaddedchallengesindesignandimplementa-tion([5]).Intuitively,becausethesubscriptionscanbecom-plex,guringoutmatchesbetweeneventsandsubscriptionsisalotharderthanintraditionalgroup-orsubject-basedsystems,whereusuallyasimpletablelookupissucient.Inthispaper,wewillassumeacontent-basedsysteminourdiscussions,becauseitisthemoregeneralandpowerfulmodel.Forinstance,group-andsubject-basedsystemscanberegardedasspecialcasesofcontent-basedsystemswherethesubscriptionsyntaxisrestrictedtosimpletestsonaspeciceldoftheevent.2.1BasicmodelFigure1illustratestheschematicofabasicpublish/subscribesystem.ItconsistsofoneormoreEventSources(ES),anEventBrokeringSystem(EBS),andoneormoreEventDisplayers(ED).AnEventSourcegeneratesinre-sponsetochangestoarealworldvariablethatitmonitors,suchasthelocationofanenemytank.Weassumethateacheventislabeledwithitssourceandaconsecutivese-quencenumbertofacilitateourdescription.Otherthanthat,wedonotmakeanyassumptionsaboutanevent'scontent.TheeventsarepublishedtotheEventBrokeringSystem,whichmatchesthemagainstasetofsubscriptionssubmittedbyusersinthesystem.Forexample,asoldiercouldsubscribetoreceivealleventsreportingthelocationofanytankwithinacertainrange.Notethat,asthecoreofthepublish/subscribesystem,theEBScouldbeimple- Figure1:Acontent-basedpublish/subscribesys-tem.Thebubblesrepresentlteringofevents,andarelabeledwiththerespectivelteringcriteria.mentedaseitherasingleserver(EventBroker)ormultipledistributedonesworkingtogether.Additionally,anEventBrokercanbereplicatedtoincreaseavailability.Sections4and5discussdistributedandreplicatedarchitecturesandtheirmobileadaptations.InFigure1,weusetodenotethesubscriptioncriterionofuser.Inotherwords,userwantsalleventsandonlythoseeventsthatsatisfy.Ifauser'ssubscriptionmatches,theeventisforwardedtotheEventDisplayerassociatedwiththatuser.ThepresenceofabubblelabeledinthelinkbetweentheEBSandanEDimpliesthatonlyeventssatis-fyingpassesthroughonthislink.TheEventDisplayerisresponsibleforalertingtheuser.Inourexample,thesoldierwillbenotiedbyamessageonhis/hermobilecommunica-tiondevice.Notethatsomeoftheeventservicessurveyedinthispaperprovideadditionalfunctionalitysuchaseventstreammanip-ulation.Forexample,somesystemscantriggeroneventstogeneratenewevents.Inthiscase,asubscriptionmightlooklike:\generateabuyorderwhenthepriceofstockXhasclimbedformorethan20percentforthreestraightquotes."Theabilitytogenerateneweventshasbeentermed\content-basedwithpatterns"([6]),\eventstreaminter-pretation"([3])and\historicalconditiontriggering"([12]),amongotherthings.Inthispaper,wedonottakeintoac-countanyofthespecicsystemextensionssuchasthis.In-stead,wewillfocusonthemostfundamentalfunctionality,namely,torouteeventsfromtheirsourcestotheirtargetsecientlyandreliably.3.CENTRALIZEDARCHITECTURESAcentralizedEventBrokeringSystemconsistsofonlyoneEventBroker(Figure2).ThecentralEBstoresallcurrentlyactivesubscriptionsinthesystem.Everyneweventispub-lishedtotheEB,whichisresponsibleformatchingitagainstallthesubscriptions.AfterwardstheeventisforwardedtoallEventDisplayerswhosesubscriptionsmatch.Represen-tativesystemsinthiscategoryincludetheSIFTInformationDisseminationSystem([21])andactivedatabases([7]).Animportantproblemthatanycentralizedsystemwould Figure2:Centralizedarchitecture:oneserverdoesallthematchingandltering.needtoaddressishowtoecientlymatchaneweventagainstalargesetofsubscriptionstogureoutwhichonesmatch.Althoughthematchingproblemischallengingandinterestingtostudy,itisbeyondthescopeofthispaper.Interestedreadersarereferredto[21,1,7]formoredetaileddiscussions.EventhoughthecentralEBmaybeaperformancebottle-neckandasinglepointoffailure,itisimportanttounder-standhowitcouldoperateinamobileenvironment.Inlatersections,wewilllookathowdistributionalleviatesthescal-abilityproblem,andhowreplicationhelpswithreliability.3.1MobileadaptationWhenadaptingacentralizedarchitecturetothemobileen-vironment,wearguethat,whiletheEventSourcesandtheEventDisplayerscanresideonamobiledevice,thecentralEventBrokerservershouldbeplacedonaseparatecom-puterinthexednetworkifpossible.TypicallyanEventSourceresidesneartherealworldvariableitmonitors,whileanEventDisplayerresidesneartheenduser(e.g.,onaPDA).Sinceinamobileenvironmentboththeinformationprovidersandtheconsumerstendtobemobile,theESandtheEDarelikelytobeplacedonamobiledevice.ThecentralEB,however,shouldresideonacomputersep-aratefromtheESsortheEDs.TherearethreereasonswhytheEBshouldnotingeneralbeplacedonthesamedeviceasanES.Firstly,theEBwilllikelyrequireafairamountofcomputingresourcefordataloggingandsub-scriptionmatching,whileanESisusuallyasimplesensordevice.Secondly,theEventSourcescanbeautonomousanddonotallowtheuserstostoretheirownsubscriptionsthere.Forexample,theEScanbeastocktradingcentergivingoutstockquotes.Individualinvestorsusuallycannotaskthesesourcestomonitorastockconditionforthem.Finally,theEBmayneedtostoreamatchedeventandrepeatedlyat-tempttoresendittoitstargetasthetargethasgoneoine.ItisunreasonabletorequireamobileEventSourcetopro-longitsconnectiontothexednetworkjustbecausetheeventrecipientisnotconnectedforthemoment.Likewise,theEBshouldbehostedonaseparatedevicefromanEDaswell.ThePDAcanbepoweredoordisconnectedfromthenetworkmostofthetimetoconservebattery,mak-ingitunsuitabletohosttheEB,whichneedstolistencon-stantlyfornewevents.Furthermore,thecomputerhostingtheEBshouldbeplacedinthexednetworkifpossible,becauseotherwisewhenthecentralEBisdisconnected,thewholesystemisparalyzed.Oncewegureoutwhereeachpartofthesystemresides,itwouldseemthatwecansimplyrelyonpreviousworkonmobilenetworking([16])toprovideuswithconnectivitybetweenthecomponentsandtohidetheidiosyncrasiesofmobilecommunication.However,aswewillillustratenext,thereareissuesuniquetopublish/subscribeinamobileen-vironmentthatwehavetoconsider.Mobile/wirelessdevicescanbefrequentlydisconnectedfromthexednetworkbecausetheyareo(runningoutofbat-teryorturnedotoconservebattery),ortheycannotbecontacted(transientwirelesscommunicationproblemsorwanderingintoanareawithoutradioreceptionetc.).Agoodmobilepublish/subscribesystemhastodealgracefullywithboththeES'sandtheED'sgoingoine.Forexample,whenauserisoutofreach,itisreasonabletoexpecttheEBStologandqueuetheuser'seventssothattheycanbedeliveredlaterwhentheusercomesbackonline.MoreissuesarisewhenanEventSourceisdisconnected.OneoptionofcourseistohavetheESqueuealltheeventsthataregeneratedwhenitisnotconnected.Suchanop-tionmaynotbefeasible,however,astheESisoftenalowcapabilitydevicewithouttoomuchstorage.Consequently,theESmayhavetodiscardoldereventsoncethebuerllsAd-hocnetworksposeadditionalchallenges.Anad-hocnet-workisformedbywirelessdeviceswantingtotalktoeachotherwithoutthebenetofaxednetworkinfrastructure.Ad-hocnetworksareextremelyusefulinscenarioswhereanaturaldisasterhaswipedouttheinfrastructure,orwhererapiddeploymentisrequiredandaninfrastructureisnotpossible,forexampleinthebattleeld.Thelackofaxednetworkinad-hocnetworksimpliesthatthecentralEBmustalsobemobile.Hencewecannolongerassumethatitisalwaysconnected.WhenanEventSourcewantstopublish,itmustrstsearchforanexistingEB.Ifonecannotbefound,anewEBmighthavetobeelected.Likewise,anEventDisplayermustperiodicallypolltheEBandrefreshitssubscriptioninformation.Otherwise,theoldEBcouldhavegoneoutofreachandanewEBelectedwith-outknowingaboutthisED'ssubscription.Finally,whenoneEBbecomesawareoftheexistenceofanotherEB(forexamplewhentwopreviouslypartitionedwirelesssubnetscomeintophysicalproximity),amergingprotocolmighthavetobeinvokedtocombinethemintoonecentralEB.Alternatively,bothcouldoperateinacoordinatedfashionasdiscussedinSection4.3.2CentralizedwithquenchingQuenchinghasbeenproposed([17])asanenhancementtothestraightforwardcentralizedapproachinxednetworks(Figure3).AnEventSourceisgivena\combinedactivesubscriptionexpression"(all),whichrepresentsthelogical Figure3:Centralizedarchitecturewithquenching.ORofallthecurrentlyactivesubscriptionsontheEventBroker.Essentially,wehaveall:::.Whenaneweventisgenerated,theESrstchecksitagainstallallfalse,thatmeansnosubscriptionwillmatchattheEB.Hencetheeventisdiscarded(quenched)atthesource.Ifmatchesall,thenatleastonesubscriptionwillmatch,andtheeventisforwardedtotheEBasusual.ThisquenchingbehaviorisrepresentedbythebubbleslabeledallinFigure3.Notethatinorderforquenchingtomakesenseitmustbemucheasiertogureoutwhetherornotaneventmatchesthecombinedallthantogureouttheexactsubsetofthatmatches,sothattheEventSourcedoesnothavetoduplicatealltheworkthatisbeingdoneatthe.QuenchinghasprovedtobeparticularlyeectiveinreducingnetworktracandtheloadofthecentralEBifasignicantportionoftheeventsgenerateddonotmatchanysubscriptions.However,theappropriatenessofusingquenchinginamo-bileenvironmentneedstobefurtherexamined.WehavesaidpreviouslythatanEScanbeawirelesslowcapabil-itysensordevice.ThusitmightnotbefeasiblefortheEStoevaluateacomplicatedconditionforeveryeventgener-ated.Moreover,informingthesensorofnewlyaddedordeletedsubscriptioncouldconsumevaluablewirelessband-width.Ontheotherhand,eectivequenchingcanalsosig-nicantlyreducethebandwidthneededtotransmitevents.Fundamentally,quenchingrepresentsatradeobetweenthebandwidthrequiredtosendalleventsandthecomputationpowerneededtomatchandlterevents.Sinceamobilede-viceisusuallylimitedinbothresources,theanswerisnotapparent.QuenchingcanbeaparticularlyattractiveoptionwhenanESisdisconnected,sinceitallowstheEStodiscardcertaineventsonthe y,thusreducingthepotentialsizeneededfortheeventqueue.However,quenchingisalsoproblematicsincethesystemcannotcontactanESaboutnewlyaddedsubscriptionswhentheESisdisconnected.Areasonable Atrivialexamplewherethisistrueisthefollowing.Sup-posee:value�10)ande:value�20).Togureoutwhetheraneventmatcheseither,itissucienttoonlytestwhetherits\value"islargerthan10. Figure4:Distributedbroadcast.Thedottedlinesarethepathofanexampleeventwhichsatisesstrategymightbetosavealleventsinthebueratthebe-ginningofadisconnectionincaseanewsubscriptionnotknowntotheESmatchesthem.Whenthebuerover ows,however,theEScanthenstarttodiscardoldereventsac-cordingtothequenchingcriteriaithas.4.DISTRIBUTIONAsexplainedinSection3,centralizedsystemsarelimitedbythecapabilityofasingleserver,beyondwhichdistributionhastobeused.Thissectionillustratestwotypicalwaysthatworkispartitionedamongmultipleservers,andtheirextensionstothemobileworld.4.1DistributedbroadcastIndistributedbroadcast(Figure4),theEBSconsistsofEventBrokers,eachresponsibleforaportionofthetotalsubscriptions.TheEBsareconnectedtoeachotherbythenetworkandformageneralconnectedgraph.AnEventSourcepublishesaneweventtoanyoneoftheEBs.(Inreality,theESprobablyconnectstothenearestEBinthenetwork.)ThatEBisthenresponsibleforforwardingtheeventtoallotherEBsinthesystem(hencethename\dis-tributedbroadcast").Theforwarding\broadcast"canbeimplementedwithnetworklayermulticasting([10]).Alter-natively,theeventcouldbesentalonga\forwardingtree"rootedattheoriginatingEB,usingunicastateachlegofthetrip.Whenaneweventarrives,eachEBmatchestheneweventagainstallsubscriptionsitisresponsiblefor,anddeliverstheeventasnecessary.NotethatthematchinganddeliveringworkloadateachEBisreducedcomparedtoacentralizedapproachbecause,althougheachEBstillprocessesalltheeventsgeneratedinthesystem,itonlyhastomatchthemagainstafractionofthetotalsubscriptions.ThedottedlinesinFigure4giveanexampleofthepathtraversedbyaneventwhichmatchesand.Anexampleofadistributedpublish/subscribesystemusingbroadcastistheSIFTGrid([21]). ActualsystemsmayconnecttheEBsinothertypologiessuchasahierarchicaltreeinsteadofapeer-to-peergraph.Tobemostgeneral,ourpaperassumesagraphstructure,althoughourdiscussionisequallyvalidforotherstructures. Figure5:Distributedmulticast.4.2DistributedmulticastDistributedbroadcastcancreatealotofnetworktracbe-causeeventsare oodedtoalltheEventBrokers.Anal-ternativeapproach,calleddistributedmulticast(Figure5),prunestheforwardingtree.Specically,whenaneventar-rivesateachEBintheforwardingtree,itisforwardedontooneoftheEB'soutgoingbranchesonlyiftheeventmightmatchasubscriptionatsomeEBleadingfromthisbranch.Inotherwords,theEBselectivelyforwardsaneventbasedontheresultof\partialmatching."Ineect,theeventismatchedagainstthelogicalORofallthesubscriptionsstoredatalltheEBsdownstreamfromaparticularbranch.Iftheresultisfalse,thatbranchis\pruned"forthisevent.ThebehaviorisverysimilartowhathappensattheroutersinIPmulticast,hencethename\distributedmulticast."Theneedforpartialmatchingimpliesthat,unlikeindis-tributedbroadcast,itisnolongersucientforeachEventBrokertoknowaboutonlyitsshareoftheactivesubscrip-tions.Intheworstcase,eachEventBrokermayneedtostoreallthecurrentlyactivesubscriptionsinthesystem.TheSienasystem([6])proposesasolutionwheremultiplesubscriptionscanbecollapsedintoonecondition,attheex-penseofrestrictedsubscriptionsyntax.Unlikedistributedbroadcast,distributedmulticastcannolongertakeadvantageofnetworklayermulticastdirectlytoforwardeventstoneededEBs,becausepotentiallycomplexpartialmatchingneedstobeperformedateachstep.AnecientimplementationoftheforwardingtreewithoutusingIPmulticastisgivenin[2].4.3MobileadaptationInadditiontothechallengesfacingamobilecentralizedsystem,therearemoreissuesassociatedwithadaptingadistributedpublish/subscribearchitecturetoamobileen-vironment.BecauseEDsoftenmovearound,anEDmaydisconnectandconnecttoadierentEBquiteoften.WhentheEDreconnectstoadierentEB,twothingsneedtohap-pen.First,thenewEBneedstobeinformedoftheED'ssubscriptionsothattheroutingtreecanbeadjustedtodi-rectrelevanteventsthisway.Second,thenewEBneedstoobtainalltheeventsqueuedonbehalfoftheEDwhiletheEDwasdisconnectedanddeliverthemtotheED.Forbothtasks,thenewEBmaycontacttheEBpreviouslyinchargeoftheuser'ssubscriptiontoobtaintheinformationaspartofa\hando"protocol([8]).Alternatively,however,anEDcancarryitsownsubscrip-tioninformation,anduploaditontothenewEBwhentheEDreconnects.TheadvantageofthisapproachisthattheEDcanstillreceiveneweventseveniftheoldEBistem-porarilydownorpartitionedfromthenewEB.(OfcoursethenewEBstillneedstoattemptcontactwiththeoldEBperiodicallytocanceltheoldsubscriptions.)ThepotentialdownsideisthattheEDmayendupwithmorethanoneEBsmonitoringthesamesubscriptionforit.Reference[11]proposesseveralschemesformobilehand-helddeviceswhichensurethattheEDreceivesthesamemessageexactlyonce.Forexample,onevariationrequirestheEDtokeepalogofitspastconnections,whichincludesatimestampandtheidoftheEBforeachconnection.When-evertheEDmakesanewconnection,thisinformationisuploadedtothenewEB,whichusesittocheckforanypotentialdangerofduplicatedelivery.Forinstance,eventsgeneratedaftertheED'slastpreviousconnectioncansafelybedelivered.Moreover,ifanotherEBcannotbecontactedatthemoment,butthelogshowsthatthelastconnectiontothatEBhappened\longenough"agointhepast,thenqueuedeventsmaystillbedeliveredwithoutworryingaboutduplication.Thesubscriptionhandoprotocolneedstobedesignedcare-fullysothat,asthenewroutinginformationslowlyperco-latesuptheforwardingtree,noeventfromanypotentialsourceislost.IdeallythesameeventshouldnotbedeliveredbothtotheoldandtothenewEBs(unlessthealternativeapproachaboveistaken).Ifthatisimpossibletoguarantee,however,mechanismstoeliminateduplicateswillbeneededagain.Becauseawirelessdevicecanbeturnedoordisconnectedforlongperiodsoftime,alotofmissedeventscanaccrueinthemeantime.EvenifstorageattheEBisnotaconcern(whichcanbeinanad-hocenvironment,forexample),thesheeramountoftimeandpreciouswirelessbandwidthre-quiredtotransmitallofthequeuedeventstotheEDwhenitreconnectsmightbeunreasonable.Again,knowledgeaboutthesemanticsofasubscriptionoftenhelps.Forexample,anEBcanpurgeoldeventsfromthequeueifitknowsthatthesubscriptionistime-sensitive.Oritmaykeeponlythemore\important"events(e.g.thecurrenthighwatermarkiftheclientisinterestedinonlymaximums).Inawirelesssystem,itissometimespossibletofurtherop-timizetheconnectionbehaviorbyusingan\integrated"ap-proach.Basestationsareusedasaccesspointsofwirelessdevicesintothexednetwork.Awirelessdeviceiscon-trolledbyoneandonlyonebasestationatanytimeitisconnected.Whenitmovesoutoftherangeofanoldbasestationandintotherangeofanewone,awirelesshandoprotocolisinvoked.Naturally,thebasestationsareidealcandidatesasEventBrokersinadistributedpub-lish/subscribesystem.Inthiscase,subscriptionhandocanbehandledasmerelyanadditionalstepinwirelessconnec-tivityhando,thussavingvaluabletimeandresources. Figure6:Replicatedpublish/subscribe.ThediscussionthusfarinthissectionhasassumedthattheEBsareplacedinthexednetworkforeciencyandrobustness.Inanad-hocnetworkwheretheEBshavetobemobile,additionalproblemsarisesimilartothosediscussedinSection3.1.Wedonotdiscusstheseissuesduetospacelimitations.5.REPLICATIONReplicationcanbeusedinapublish/subscribesystemtoin-creaseitsavailabilityandreliabilitywhenfacedwithserverfailuresornetworkpartitions.Inareplicatedpublish/-subscribesystem(Figure6),auser'ssubscriptionismon-itoredbymultipleEventBrokersindependently.Inpartic-ular,inFigure6weassumethattwoEBs,EB1andEB2,simultaneouslymonitorthesubscriptionsforeachuser.Ontheotherhand,weassumethatthereisstillonlyoneEventDisplayerassociatedwitheachuser,because,aswehavediscussedbefore,theEDisusuallyaprogramrunningonthePDAwhichtheusercarrieswithhim/her.Hence,thetwostreamsofeventsgeneratedbyEB1andEB2willmergeattheED.Notethatforsimplicityweuseacentralizedar-chitectureasthebasisforreplication.Althoughwedonotdiscussithere,replicationcanalsobeintroducedinadis-tributedsystemliketheonesinFigures4and5.Withreplication,auserislesslikelytomissevents.Forinstance,supposethatEB1missessomeeventsfromapar-ticularmobilesourcewhichcanonlycommunicatewithEB2duetotemporarynetworkproblems.ThentheeventscanstillbematchedbyEB2anddeliveredtotheappropriateEDs.However,withoutanysafeguards,replicationcancre-ate\consistency"problemsinapublish/subscribesystem.Specically,theusermayreceiveasequenceofeventsthatareconfusingorevencontradictory.Asasimpleexample,withoutamechanismtoeliminateduplicates,thesameeventmaygetdeliveredtotheusertwice,oncefromeachEB.Theuserwillgetconfusedifhe/shereliesontheeventstokeeptrackofanimportantcount,suchastheexactnumberofmissilesthathavebeenred.Asanotherexample,althoughitisnotdiculttomake WeassumethateventscanbelostwhentheyaresentfromtheirsourcetoanEB.However,sinceweassumethattheEBbuersandretransmitseventsasnecessary,thelinkbetweentheEBandtheEDisassumedtobelossless.asingleEBalwaysdelivereventsfromthesamesourceinorder,replicationcanoftenresultinanunorderedeventse-quencewheneventsfromthetwoEBsareinterleavedattheED.Forinstance,supposeeventnumber3ismissedbyEB1butreceivedbyEB2.ItisthereforeentirelypossibleforEB1todeliverthenextevent,saynumber4,totheuserbeforeEB2couldhaveachancetodeliverevent3.Out-of-ordereventstreamscanbeaproblemiftheorderofeventsissig-nicant,forexampletoestablishatrendinthemovementsofastock'sprice.Wecandenethreedesirablepropertiesforareplicatedpub-lish/subscribesystem:OrderednessConsistencyandCompleteness.Thegoalingeneralistoruleoutdeliv-eriesofeventstoauserthatcouldhaveoccurredwithanon-replicatedsystem.Intuitively,orderednessindicatesthateventsfromthesameESaredeliveredtotheuserintheordertheyaregeneratedattheES.Sinceanon-replicatedsystemdeliverseventsinthisorder,areplicatedsystemthatisorderedbehavessimilarlyinthisrespect.Forareplicatedsystemtobeconsistent,thesetofeventsitdisplaystoanenduserovertimemustbeasetthatcanpossiblybegeneratedbyanon-replicatedsystem(althoughperhapsinadierentorder).Inotherwords,ausershouldnotbeabletotell,fromobservingtheeventsthataredis-playedtohim/her,thatreplicationisbeingused(exceptforpossiblyincreasedreliabilityandresponsiveness).Forex-ample,areplicatedsystemthatdeliversduplicatestotheenduseristriviallynotconsistent.Lastly,completenessrequiresareplicatedsystemtodis-playalleventsthatwouldbedisplayedbyanequivalentnon-replicatedsystemhadthesingleEBinreceivedalleventsthatwerereceivedbyEB1orEB2in.Forexam-ple,ifaneventmatchingtheuser'ssubscriptionarrivesatEB1butismissedbyEB2duetonetworkpacketloss,thenacompletereplicatedsystemwillneedtoensurethattheeventisnotdiscarded(seenextonEventDisplayerlter-ing)andisultimatelydeliveredtotheuser.Completenessisameasurementofhoweectiveareplicatedsystemisatguardingagainstlossofeventsinthenetwork.Ourthreenotionsofcorrectnessaredenedmoreformallyin[12].Obviously,iftheEventDisplayersimplypassesalonganyeventitreceivestotheuser,theresultingreplicatedsystemwillbeneitherconsistent(duetoduplicates)norordered.Table1summarizespropertiessatisedbyareplicatedsys-temundervariouscongurations,withtherstrowbeingwhennospecialprocessingisdonebytheED.However,aswewillseenext,somesystempropertiescanbeenhancedorenforcediftheEDperformsanextrasteptolteroutsomeevents(e.g.,duplicates)beforepassingthemontotheuser.Inthesimplestexample,theEDcanimplementastraight-forward\exactduplicateelimination"algorithm,inwhichaneventisdiscardedbytheEDifan\identical"onehasalreadybeendisplayedpreviously.Theexactdenitionof\identical"isgivenin[12].ThemodiedsystempropertiesunderthisEDlteringalgorithmarelistedinthesecondrowofTable1.Asshowninthetable,thesystemhasgainedconsistencyasaresult. EDltering Comp. Noltering X X p Duplicateremoval p p Out-of-orderand duplicateremoval p X Table1:Propertiessatisedbyareplicatedpub-lish/subscribesystemundervariousEDlteringal-gorithms.Forsituationswhereanorderedeventstreamisimperative,anEDlteringalgorithmhasbeenproposedin[12]toen-forceorderednessofareplicatedsystem.Essentially,theEDrecordsthelastseensequencenumberfromeachEventSourceanddiscardsanyneweventthatarrivesoutofor-der.Thedisadvantageofthisalgorithm,however,isthatthesystemisnolongercomplete,sincesomeeventsmaybe\unnecessarily"lteredoutbasedontheirarrivalorderratherthantheircontent.Thetradeoofcompletenessver-susorderednessshouldbedecidedbytheindividualappli-cations.ThelastrowinTable1givesthesystempropertiesunderacombinedlteringalgorithmthatguaranteesbothorderednessandconsistency.Reference[12]oersanin-depthstudyofreplicationinpub-lish/subscribesystems.Forinstance,itdiscussessystemswiththeabilitytogenerateneweventsbasedonpatternsinastreamofevents.Itisshownthatsuchsystemsareusuallyinconsistent,becauseeventlosscanoftenleadtodivergentperceptionsbetweenthetwoEBsaboutwhatconstitutesatriggeringpattern.Consequently,moresophisticatedEDl-teringalgorithmsaredevelopedtoguaranteeconsistencyinsuchscenarios.Additionally,subscriptionsdenedonevent\joins"fromdierentstreamsarealsostudied.Thepa-peralsoinvestigatesmultiplesubscriptionssubmittedbythesameuserthatareinterrelatedandneedtobemonitoredinacoherentfashion.6.CONCLUSIONInthispaperwediscussedhowtoadaptapublish/subscribesystemtoamobileoperatingenvironment.Wedescribedseveralarchitecturesofapublish/subscribesystem,startingfromthesimplecentralizedapproach,todistributedoneswithimprovedscalability,andnallytoreplicationthatin-creasesreliabilitybutmaycauseconsistencyproblems.Wediscussedissuesandpossiblesolutionsspecictoadaptingthevariousarchitecturestoamobileand/orwirelessen-vironment.Wealsosketchedsolutionstothemorechal-lengingproblemsposedbyad-hocnetworks.Inpresentingourwork,wealsosurveyedsomeoftheimportantworkoncontent-basedpublish/subscribesystemsinxednetworks.7.REFERENCES[1]M.K.Aguilera,R.E.Strom,D.C.Sturman,M.Astley,andT.D.Chandra.Matchingeventsinacontent-basedsubscriptionsystem.InProceedingsofthe18thAnnualACMSymposiumonPrinciplesofDistributedComputing,pages53{61,1999.[2]G.Banavar,T.Chandra,B.Mukherjee,J.Nagarajarao,R.E.Strom,andD.C.Sturman.Anecientmulticastprotocolforcontent-basedpublish-subscribesystems.InProceedingsofthe19thInternationalConferenceonDistributedComputingSystems,pages262{272,1999.[3]G.Banavar,M.Kaplan,K.Shaw,R.E.Strom,D.C.Sturman,andW.Tao.Information owbasedeventdistributionmiddleware.InProceedingsoftheICDCSWorkshoponElectronicCommerceandWeb-BasedApplications,1999.[4]K.Birman.Theprocessgroupapproachtoreliabledistributedcomputing.CommunicationsoftheACM36.12:36{53,1993.[5]A.Carzaniga,E.Nitto,D.Rosenblum,andA.Wolf.Issuesinsupportingevent-basedarchitecturalstyles.3rdInternationalSoftwareArchitectureWorkshop[6]A.Carzaniga,D.S.Rosenblum,andA.L.Wolf.AchievingscalabilityandexpressivenessinanInternet-scaleeventnoticationservice.InProceedingsofthe19thAnnualACMSymposiumonPrinciplesofDistributedComputing,pages219{227,2000.[7]S.CeriandJ.Widow.ActiveDatabaseSystems:TriggersandRulesforAdvancedDatabaseProcessingMorganKaufmann,1996.[8]G.Cugola,E.D.Nitto,andA.Fuggetta.TheJEDIevent-basedinfrastructureanditsapplicationtothedevelopmentoftheOPSSWFMS.IEEETransactionsonSoftwareEngineering,toappear.[9]G.Cugola,E.D.Nitto,andG.P.Picco.Content-baseddispatchinginamobileenvironment.WorkshopsuSistemiDistribuiti:Algoritmi,ArchitettureeLinguaggi,2000.[10]S.E.Deering.MulticastRoutinginaDatagramInternetwork.PhDthesis,StanfordUniversity,1991.[11]Y.HuangandH.Garcia-Molina.Exactly-oncesemanticsinareplicatedmessagingsystem.InProceedingsofthe17thInternationalConferenceonDataEngineering,2001.[12]Y.HuangandH.Garcia-Molina.Replicatedconditionmonitoring.InProceedingsofthe20thACMSymposiumonPrinciplesofDistributedComputing2001.Toappear.[13]B.KantorandP.Lapsley.NetworkNewsTransferProtocol:Aproposedstandardforthestream-basedtransmissionofnews.RequestforComments:977,[14]ObjectManagementGroup.CORBAservices-eventservicespecication.Technicalreport,ObjectManagementGroup,1997.ftp://ftp.omg.org/pub/docs/formal/97-12-11.pdf[15]B.Oki,M.P uegl,A.Siegel,andD.Skeen.TheInformationBus-anarchitectureforextensibledistributedsystems.OperatingSystemsReview27.5:58{68,1993. [16]C.Perkins.IPmobilitysupport.RequestforComments:2002,1996.[17]B.SegallandD.Arnold.Elvinhasleftthebuilding:Apublish/subscribenoticationservicewithquenching.Proceedingsofthe1997AustralianUNIXUsersGroupTechnicalConference,pages243{255,1997.[18]SunMicrosystems,Inc.Jini(TM)technologycoreplatformspec-distributedevents.Technicalreport,SunMicrosystems,Inc.,2000.jini/specs/jini1.1html/event-spec.html[19]TIBCOInc.TIB/Rendezvous.http://www.tibco.com/products/rv/index.html[20]VitriaBusinessWare.//www.vitria.com/products/businessware.html[21]T.W.YanandH.Garcia-Molina.TheSIFTinformationdisseminationsystem.ACMTransactionsonDatabaseSystems,24.4:529{565,1999.