A LooselyCoupledFederationof DistributedManagementServices

— ExtendedVersion—

GerdAschemannandPeerHasselmeyerDarmstadtUniversityof Technology

Departmentof ComputerScience{aschemann,peer}@informatik.tu-darmstadt.de

ITO TR-00-09

October, 17th2000

Abstract

Thispaperdescribesanarchitecturefor managementservices.Thearchitectureconsistsof a numberof small components,eachperforminga highly specializedtask.Together, they form adynamic,highly automated,yetintegratedmanagementsystem.Thecomponentsareplug-and-playservicesthatuseJini to dynamicallyestablishcommunicationlinks amongthemselvesandform transientmanagementfederations.Our architectureis built arounda configurationservicewhich pro-videsfor consistentconfigurationof managedresources.We identify a numberofcommonmanagementscenariosanddemonstratehow they canbe supportedbyour system.

Keywords: Event-basedmanagement,CORBA-basedmanagement,Jini-basedman-agement,Java, Web-basedmanagement,distributed-systemsmanagement,distributedmanagement

1 INTRODUCTION

For many years,managementof networksanddistributedsystemshasbeenshapedononehandby dedicatedmanagementarchitectures,suchasOSI-MF/TMN andSNMP,andon theotherhandby monolithicmanagementplatformsandframeworks,suchasHPOpenview, IBM Netview, or CA Unicenter. SNMP’s restrictedinformationmodel-ing techniquesmakedesigningmanagementapplicationscomplex andawkward.BothSNMPandTMN arethereforecomplex technologiesandmanagementplatformssup-portingoneor evenbothof themarejust ascomplex. Not only do suchplatformsre-quireappropriatehardwareandexpensivesoftware,they alsoneeda complex analysis

1 INTRODUCTION 2

process,a matchingorganizationalframework andconstantcustomization,configura-tion, anddevelopment.Therefore,only largeorganizationscanafford to investin thisprocessandthehighly specializedhumanresourcesto run thesystems.

Currentandwidely usedtechnologieslikeCORBA, theWorld WideWeb(WWW),andJavahaveled to astrongtrendof replacingthespecial-purposemanagementarchi-tecturesby multi-purposemiddlewareinfrastructures.Theseinfrastructuresallow forcheapoff-the-shelfcomponents,suchastheCORBA CommonObjectServices(Nam-ing, Transaction,Life-Cycle, etc.), andareavailableto a broadrangeof developers,programmers,andoperators.However, wehaveto distinguishbetweentwo basictypesof approaches:

� The WWW andrelatedtechnologiesrely on a documentorientedinformationmodelanda streamorientedcommunicationmodel. That is, they arebasicallyusedto sendsemi-structured(HTML) information with a simple file transferprotocol(HTTP) to humanusers(browsers).Severalenhancements,e.g.,XML,CGI scripts/servlets,andECMA script/Java applets,enablepowerful front endandbackendapplications.EventhoughtheWWW providesa well-known andwidely availableuserinterface,theoverallarchitectureis essentiallyrestrictedtoa two-tieredclient/serverapproach.

� The other importantkind of middleware is representedby CORBA, DCOM,DCE,EJB,etc.Thesetechnologiesusuallyprovideanobject-orientedor at leastobject-basedinformationmodelanda synchronous,task-oriented(RPC)com-municationmechanism. This allows for arbitrary distribution of componentsandtheconstructionof two-tier, three-tierandevenn-tier applications.Objectstransparentlycall well-known methodsof otherobjectsbasedon strongtypingandefficientdispatching.

Both approacheshave particularstrengthsandweaknesses.Distributed applica-tionsin general,andmanagementapplicationsin particular, oftenneedfeaturesof bothworldsandstrongintegrationmechanismsarerequired.

We believe thatthegeneraltrendtowardstheuseof multi-purposemiddlewarein-frastructureswill ultimately leadto an openarchitectureof small, highly specializedmanagementcomponents.The architecturemustallow for the formationof arbitrarymanagementfederationsand managementapplicationson demandin an automaticfashion,or with only little additionalassemblywork. It alsohasto enableeasyex-tensibility by integratingnew servicesas well as legacy managementprotocolsandapplications.Administrationof resources,services,andmanagementservicesshouldbeperformedmostlyautomaticto freeadministratorsfrom tasksbetterperformedbymachines.

To investigatethepossibilitiesandchallengesof suchan architecture,we definedandimplementeda setof componentswhich enablea numberof examplescenariosandrepresenta basefor further managementapplications.Sinceconfigurationman-agement,i.e., deploymentandmanagementof managementservicesandrelationshipsamongthem,is aprerequisitefor enablinga managementfederation,wehavegroupedourcomponentsarounda configurationfacility.

2 SCENARIOS 3

Dueto our incorporationof new aswell asexisting managementservices,we didnot restrictourselvesto a singlecommunicationprotocol. ComponentsarecurrentlyintegratedusingCORBA, Java RemoteMethodInvocation(RMI), andthe HypertextTransferProtocol(HTTP). User interfacesare built using Java’s Swing packageaswell astheHypertext MarkupLanguage(HTML) andtheExtensibleMarkupLanguage(XML). To reachourgoalof dynamic,automatic,andad-hocformationof managementfederationswe employ theJini connectiontechnology[24] asourserviceframework.

The paperhasthe following structure.Section2 discussessomespecificscenar-ios whereour architecturecan be successfullyapplied,while the following sectioninvestigatessomerequirementsresultingfrom thesecasestudies.We thengive a briefintroductionto Jini in Section4. Section5 presentsthedesignof thearchitecture,andSection6 goesinto somedetailsof the implementation.Beforewe concludein Sec-tion 8 we provide a comparisonwith relatedwork in Section7. A shortenedversionof this paper[4] will appearin a specialissueof theJournalof Network andSystemsManagement(JNSM).

2 SCENARIOS

To introduceour architecture,we startby describinga few scenarioswhich we thinkare typical network managementtasks. By analyzingthesescenarios,we can iden-tify the componentsthatareneededto supportthesetasks.Thescenariosarenot fo-cusedonanadministrator’swork but describetasksperformedby differentpeoplein amedium-to large-sizedcompany. All scenariosarecenteredaroundtheadministrationof a work-group’s printer. As thesescenariosshow, humanintervention is requiredonly in abnormalcases.

First, let usassumethatsomebodyis printinga largedocument.After a few pages,theprinterrunsoutof paper. Usually, thepersonprinting thedocumentfindsoutaboutthe missingpaperwhen trying to pick up the printout. The userhas to add somepaperandwait somemoretime for the job to be completed.A bettersolution is tobe notified by the printer assoonasthe problemoccurs.To supportthis, the out-of-papernotificationhasto bedynamicallyroutedto thepersonthatsubmittedthecurrentprint job. Thereis no needto forward the messageto a centraladministratorasthisproblemcanbebetterfixedlocally.

A similar problemoccurringon a regularbasisis missingtoner. Here,too, theno-tificationshouldbedynamicallyrouted,in this caseto thepersonin chargeof refillingthe toner, who is probablynot the onewho submittedthe currentprint job. Instead,the messagecould be forwardedto the supply room who can automaticallysendanew tonercartridgeto theappropriatedepartment.If they areout of stock,moretonercouldautomaticallybeorderedfrom their supplier. As thesetwo examplesshow, it isimportantto sendnotificationsto differentdestinationsdependingon their type.

In caseof a serioushardwaredefectin the printer, the fault notificationhasto besentto yet anotherperson—thecompany’s systemadministrator, who canthencall aservicetechnicianto fix the problem. If the failure occurswhile the systemadmin-istratoris not at her desk,the failure notificationshouldbe forwardedto her PDA orcellularphone.Of course,everyeventshouldalsobeloggedin a database.Theselec-

3 ANALYSIS 4

tion of anotification’sdestinationshouldusuallyhappenautomaticallywithouthumanintervention.

To find out aboutthe printer’s problems,the servicetechnicianwould connecttothecompany’s network andcollect requiredstatusinformationfrom theprinter. Thisshouldideally happenbeforethe technicianleaveshis office, ensuringthat he takesalongtherequiredparts.If theproblemcannotbefixedon site,anew printermight beinstalled(eitherasatemporaryor permanentreplacement).Theinitial configurationofsucha new printershouldbemostlyautomatic,gettingtherequiredinformationfromservicesin thenetwork. For example,InternetProtocol(IP) addressescanbeacquiredfrom a DynamicHost ConfigurationProtocol(DHCP) server, printer driverscanbedownloadedfrom the vendor’s web site, andusersarenotified of the new printer bysomekind of servicebroker.

Installinga new printer is alsoneededif theold oneis commonlyoverloaded.Anintelligentinfrastructureshouldconstantlymonitorthequeuesizeof theprinterspoolerandnotify theadministratorif excessive loadis regularlydetected.

If anadministratordiscoversthatnew toneris requiredeveryotherweek,shemightwant to introduceaccountingto monitorusagebehavior. In our component-basedar-chitecturethis would only requirestartingan accountingservicesomewherein thenetwork. The new componentwould automaticallyfind all printersandaskthemtosendaccountingrecordsto it. Dependingon the dataformat usedby the accountingservice,it is easyto make thecollecteddataaccessiblevia theWeb,sothatemployeescanlook at their printinghistory.

3 ANALYSIS

By analyzingthe above use-cases,we can identify a numberof propertiesthat ourcommunicationinfrastructureneedsto offer, aswell asa numberof servicesthatneedto bepresentsomewherein thenetwork.

3.1 Infrastructur e Requirements

Our architectureconsistsof a large numberof small componentswhich have to dis-cover andinteractwith eachotherat run time. As this is a recurringproblemthatallcomponentsface,the communicationinfrastructureshouldsupportthis functionalityandeaseits usage.For bothproblems—communicationacrossa network andfindingservices—anumberof solutionsexist. Communicationcanbeperformedvia CORBA,Java RMI, plain sockets,etc. Locatingservicesis possiblevia COSnamingservices,RMI registries,andsoon. However, thesetechnologiesdo not completelysatisfyouraim. They all requireclientsandservicesto know thelocation(usuallyanIP address)of thenamingserviceand,asour ultimategoal is to minimizepre-configuration,thisis not acceptable.Clientsshouldconfigurethemselvesasautonomouslyandautomati-cally aspossible.Jini wasfoundto supportthis requirement.

3 ANALYSIS 5

3.2 Required Services

From the scenariosdescribedabove, we candeducethe componentsneededto solvetherespectivemanagementtasks.It is assumedthatwearedealingwith a“traditional”networkprinterwhichisnotJini-enabled,but hasothermeans,liketheSimpleNetworkManagementProtocol(SNMP),to communicatewith theoutsideworld. We considersucha device an“inherited” device,andconsequentlycall mechanismsto accesssucha device “inherited” protocolsor “inherited” interfaces.All othercomponentsareas-sumedto beJini-enabled.This is of coursetrue for all componentsthatwe introducein our architecture,but currentlynot for userapplicationslikea word processor.

To integratea particularinheriteddevice into a network we have introducedtheconceptof aso-calledNanny[3], avirtually uniqueentity for eachdevice,which takescareof it. A Nanny canbeseenassomesortof extendedJini devicebay which com-binesspecificknowledgeaboutits protege with context specificknowledgeaboutthesurroundingnetwork. Henceit doesnot only integratethe inheriteddevice into a Jiniframework but into arbitrarynetworksof services.SincetheNanny is thedriving forcebehindthe integrationof the device it requiresa numberof supportingmanagementservicesaccordingto theinheritedinterfacesof thedevice. Thesearedescribedin thefollowing paragraphs.

SNMP trap service. Our first scenariouseseventnotifications.To beableto handlethemthey mustfirst becapturedandmadeavailableto interestedparties.Wethereforeneeda servicethat acceptsSNMP traps, transformsthem to Jini eventsand passesthemon to registeredlisteners. For our printer, its Nanny is sucha listener. SincetheNanny knowsaboutthedevice it caresfor, it is ableto derive specificinformationfrom the genericevent objectandforward it to appropriateparties,e.g., the printingservice. Dependingon the type of the event, the receiving servicemay forward theeventto anothereventlistener, e.g.,to theuserwhosubmittedtheprint jobor theprinteradministrator. During theintegrationphaseof theprinter, theNanny is responsibleforconfiguringtheIP addressof theSNMPtrapservicewithin theprinter.

SNMP gatewayservice. Not only needSNMP trapsbe captured,further manage-ment via SNMP must be possible,e.g., when a servicetechnicianwantsto accessstatusinformationof a printer. An SNMPgateway servicemustthereforeexist whichcanbeusedby clientsto issueSNMPcommandsandreturntheresults.

Protocol services. Sincethelow level andinitial configurationof theprinter is usu-ally provided throughinheritedprotocols,appropriateJini-enabledvariantsof theseservicesmustbeprovidedby thearchitecture,e.g.,a DHCPserviceanda Trivial FileTransferProtocol(TFTP)service.TheJini-enabledvariantsdo not only make themapartof aJini federation,they alsooffer appropriateinterfacesto allow for configurationandeventregistration.

Printing service. Becausetheprinteris usedby applications,theNanny shouldpro-videaJini wrapperofferingtheserviceof theprinterthroughappropriateinterfacesand

4 THE JINI INFRASTRUCTURE 6

attributes.In thiscase,theprinterwill bediscoveredby thealreadymentionedprintingservice. However the printing serviceitself may make useof moregenericbaseser-vicesto split up its task,suchasa queueingserviceanda userserviceto authenticateusersandkeeptrackof theissuedprint jobs.

Accounting service. Enablingaccountingrequiresthestartof anaccountingservice.It collectsaccountingdatafrom all accounting-enabledservicesandallows other(au-thenticated)entitiesto accessthe collecteddata. The accountingserviceregisterswith otherserviceswhen it starts; theseservicesthensendit accountingrecordsasnecessary. Thus,servicessupportingaccountingmustexposemethodstheaccountingservicecanuseto registerwith themandmustsendtherequireddatato theaccountingservice.

Configuration service. Finally, we canforeseethat somesort of configurationser-vice is necessaryto take careof consistentconfigurationmanagement.This is de-scribedin moredetail in section5.

Further components. Findingoutaboutfrequentoverloadsis aclassicalmonitoringproblem.Two partiesareinvolved—onethatmonitorsandonebeingmonitored.Be-causethe monitoringcomponentaccessesservicesbut doesnot offer a serviceto theJini federation,it is not registeredasa Jini service. Monitoredservicesmustexposemethodsfor supplyingmonitoringdata. Dependingon the frequency of events,datatransfercan follow a pushor a pull model. A descriptionof thesetwo modelscanbe found in [14]. If the monitoringcomponentdiscoveredthe frequentoverloadof aprinter, it cansendanappropriatemessage,e.g.,to thesystemadministrator.

4 THE JINI INFRASTRUCTURE

Forabetterunderstandingof thereasonswhywechoseJini asourserviceinfrastructurewepresentanoverview of therelevantfeaturesof Jini in thissection.

Servicesin a Jini systemannouncetheir availability by registeringwith the sys-tem’sservicerepository, theso-called“lookup service”(LUS). Thelocationof lookupservicesdoesnot needto be known in advanceas they canbe found at run time byusing Jini’s multicastdiscovery protocol. Clients can get referencesto servicesbyqueryinglookupservices.A Jini federationis formedby all servicesandclientscur-rently participatingin thesystem.Theboundariesof onefederationaredefinedby thereachabilityof oneparticularlookup serviceinstance.Throughoutthis paperwe usethe terms“service” and“component”. Thereis a slight differencebetweenthesetwoterms.Componentsareall entitiesthatarepartof a Jini managementfederation,i.e.,servicesaswell asclients. Only componentsthat areservicesin the Jini sense,i.e.,entitiesthatregisterwith lookupservices,arecalledservices.

Anotherfeatureof Jini thatwe make frequentuseof is its protocolindependence.Servicescanuseany protocolto communicatewith their clients. This functionality isenabledby Java’s codemigrationfacilities. Servicessendprotocolenginesin form of

5 ARCHITECTUREAND MAIN COMPONENTS 7

proxiesto their clients. Clientsonly needto know the (Java) interfaceof a service,not theactualimplementationof theserviceor its proxy. This protocolindependenceallows for theeasyintegrationof inheritedservicesastheseonly needto bewrappedin a thin Jini layer. Communicationprotocolsdo not needto bemediated,converted,or changed.

5 ARCHITECTURE AND MAIN COMPONENTS

Fromthemanagementpoint of view a distributedsystemconsistsof a setof managedresourceswhich aremonitoredandcontrolledby a setof managementapplications.Due to the very natureof beingdistributed,eachcomponenthasits own partial viewof the overall configuration,i.e., its own relationshipsto othercomponents.Hence,this configurationwill not necessarilybeconsistent,that is, arbitrarypairsof compo-nentsmay have differentnotionsof their mutual relationships.This is true even forcentrallymanagedsystemsor if only onemanagementapplicationexists.Wethereforebelieve that the major challengefor a framework or platform for the managementofdistributedsystemsis to preserve theconsistency of theconfiguration,in particularifthemanagementsystemitself is distributed.

Figure1 depictsanabstractview of ourarchitecture:Themanagementapplications(MA) managetheresources(MR) througha configurationlayerwhichensuresconsis-tent relationshipsamongcomponents.Of course,mostmanagementactions(suchasperformancemanagementor fault detection)do not primarily changethe configura-tion. It is neverthelessuseful—atleaston thearchitecturallevel—to let all eventspassthroughthe configurationlayer, asmostfunctionalmanagementareasuseconfigura-tion information,e.g.,by routing or correlatingalarmmessagesbasedon the servicetopology. Consequently, thecentralor at leastvirtually centralcomponentof ourman-agementarchitectureis theconfigurationservice.

Configuration

MA MA MA MA

MR MR MR MR MR MR

Figure1: Abstractarchitecture

5.1 Configuration Service

Theconfigurationservicedoesnotonly storeconfigurationdatabut alsotakesanactivepart in configurationmanagement.Mechanismsthat allow managementapplications

5 ARCHITECTUREAND MAIN COMPONENTS 8

to changeand retrieve (pull) configurationinformation are thereforerequired. Fur-thermore,facilities to actively pushinformationchangesandnotificationsaboutsuchchangesto interestedpartiesare needed. Pushinginformation changesto managedresourcesmeansto reconfigurethem; pushinginformation changesto managementapplicationsmakesthemawareof configurationchanges,suchasnotifying anadmin-istratoraboutchangesin the servicetopology. To keepthe configurationserviceassimpleaspossible,we conceptuallysplit it up into severalsub-services:

1. A repositorywhich persistentlystoresconfigurationdata,andprovidesaninter-faceto changeandretrievedataaswell asto subscribeto changeevents;

2. A rule basewhichcontainsrulesandpolicies[15] to preservetheconsistency oftheconfiguration;

3. A scheduling(time)servicewhichmaytriggeractionsin therepositoryatcertaintimes,suchasto checkfor subscriptionexpirations;

4. Protocoladaptorsto convert configurationinformationaccordingto therespec-tive informationmodeland/orcommunicationmodelof themanagementappli-cationsandmanagedresources.

Dueto its implementationhistoryourconfigurationserviceis notstrictly separatedinto theseparts(cf. section6.1).

5.2 Observation and Controlling Services

We will not go into the detailsof all managementservices. Insteadwe will try todistinguishbetweenmanagementservicesthatmostly monitor the distributedsystemandservicesthatchangeits behavior. Of course,someservicesactin bothroles.

Monitoring . Monitoring is theclassicaltaskof mostmanagementsystems.For thesake of simplicity, monitoringis often performedby managementservicesandman-agementapplicationsthroughpolling theappropriatedatafrom themanagedresources(SNMP).Only critical eventsareforwardedactively by themanagedresources.How-ever, only few statechangesof the managedresourceshave a direct impact on thebehavior of the systemin termsof reconfiguration.Nevertheless,managementsys-temsmustkeeptrack of the global picturenot only to reactto emergency situationsbut alsoto allow for proactive managementto avoid critical situations.Therefore,weenablemanagementservicesin anobserver role to reactto changesin a dynamicwayaccordingto theneedsof the organizationrunningthedistributedsystem.For exam-ple,a printerrunningout of tonermaybeignoredby themanagementsystemin mostorganizationsbut maybecritical to others,suchasin a stockexchange.We thereforestronglyencouragetheuseof eventsin managementto allow for appropriatereactionsaccordingto anorganization’sneedsandpolicies.

Jini helpsusprovide management-relevantnotificationsasoneof its corefeaturesaredistributedevents.Every servicein our systemis requiredto provide notificationsandappropriatesubscriptioninterfaces.As eventsourcesdo not distinguishbetweendifferentlisteners,flexibility in reactingto eventsin arbitrarywaysis ensured.

5 ARCHITECTUREAND MAIN COMPONENTS 9

Control. Eventpropagationis not only usedfor monitoringpurposesbut alsoto for-ward configurationstatechangesto arbitrarytargets. Targetsaremanagedresourceswhich maybedirectly reconfigured,aswell asmanagementapplicationswhich mighttakefurtheraction,suchasperformingcomplex reconfigurationtasksor notifying ahu-mansystemadministrator. Statechangesmight bedueto spontaneouseventsin man-agedresourcesor reconfigurationactionsby managementapplicationsandby humansystemadministrators(seeFigure2). Our managementarchitectureallows manage-mentapplicationsto establisharbitraryandcomplex controlloopsthroughourmanage-mentservices,therebyimplementingany desiredmanagementwork flow. Of course,all entitiesmayalsooffer conventionalqueryandchangeinterfaces.

Configuration �

Management Applications �

Managed Resources

Console

Legend: Events Query/Change �

Event Correlation, Accounting, Logging, ...

Figure2: Extendedabstractarchitecturewith arbitrarycontrolloops

5.3 Inter nal Service Ar chitecture and UsedTechnologies

Figure3 shows our architecture.We have replacedsomeof the genericcomponentswith their concreteimplementationsand refer to the technologiesused. The figuredoesnot containall relationshipsbetweenthemanagementcomponentsandtheman-agedresources.Instead,it is restrictedto themostimportantrelationshipsandtypicalexamples.

Thevariousparts,thatis, theconfigurationservice,theNanny sub-architecture,theCORBA/SNMP-gateway, andgenericJini, CORBA andWeb services(e.g., the Jini-LUS) areseparateentitiesbut arecloselycooperatingdespitebeinglooselycoupled.

As outlinedin section1, internalcommunicationandcommunicationbasedondis-tinct methodcalls to certainobjectsmake stronguseof CORBA. If the participatingcomponentsarenativeJavaobjectswealsomakeuseof RMI whereappropriate,in par-ticular in conjunctionwith Jini. Externalrepresentation,desired(Java)codemigration,eventdistribution,andself-configurationrely on appropriateWebtechnologies:

� Java andHTML (canbereplacedandextendedby XML) for representation,. . .

� HTTP for codemigration,stream-basedanddocument-basedinformationstruc-tures,file transfer, . . .

6 IMPLEMENTATION 10

Management Applications and Services

Managed Resources

Nanny Services

Management- GUI based on Jini/

�

ServiceUI Jini-Proxy

�

Jini Lookup Service

Other management services �

(Accounting, Performance, Event Correlation, Security, Scripting, ...)

CORBA Services

(Event, Time, Naming, ...)

CORBA/ SNMP

Gateway

Jini- �

wrap- per �

Configuration Service(s)

Jini- �

wrap- per �

Web-Browser

HTML Java- �

Applet

Legend: Other (SNMP, TFTP, DHCP, HTTP, ...) �

Jini/RMI �

IIOP

Figure3: Detailedarchitectureandmostimportantcommunicationrelationships

� RMI for configuration-freeintegrationthroughJini, Jini eventdistribution,com-municationwith Jini-enabledservices,. . .

6 IMPLEMENT ATION

Thecomponent-basedarchitectureof our framework wasveryhelpful in implementingthe requiredservices. It allowed us to implementindividual componentsseparatelyoncetheserviceinterfaceshadbeendesigned.We wereevenableto integrateexistingcomponentswhich hadbeenimplementedprior to the final definition of the overallarchitecture.In thissectionwefocusonsomedetailswhichweconsiderto beof majorinterest,in particulartheintegrationof existing components.

6.1 Integration of the Configuration Service

With the SystemConfigurationTool (SCOT) [5] we haddefinedandimplementedarepositoryfor configurationinformation. SCOT provides both a Web interfaceforhumanusersanda CORBA interfaceto accessconfigurationdataby managementap-plications[7] andenhanceduserinterfaces,i.e.,Java applets.

SCOT hasbeenintegratedwith theJini-basedarchitecture(cf. Figure4), in partic-ular

� the repositoryreactsto externalchanges,that is statechangesin managedre-sourcesand/ormanagementapplications,and

� therepositorysendseventsif thestateof anobjectin theconfigurationrepositoryis changed,suchasthroughexternaleventsor regularchanges.

We realizedthis by addingtwo optionalfunctionsto eachobjectin therepository,which areemptyby default andare thereforenot evaluated. Sincethe repositoryis

6 IMPLEMENTATION 11

SCOT

SCOT �

repository

Web-

Server � Socket

IIOP Jini-Wrapper

(<-> CORBA)

"CGI": Servlets/

Perl

Jini/Jar- �

files HTML files

Figure4: SCOT integrationinto Jini-basedfederation

implementedin Lisp thesefunctionscanactuallybearbitraryLisp operations.Oneofthefunctionsis calledwhenanexternaleventoccurs.It implementsa pushconsumerinterfaceof theCORBA EventServicespecification[16] andgetstheeventdataasaCORBA.Any object. If the stateof the object is changedthe other function is auto-matically calledwith the addressof a CORBA pushconsumerasparameter, i.e., anassociatedCORBA eventchannel(seebelow). This functionshouldcall theconsumerwith anappropriateCORBA.Any objectasaparameterthatcontainsinformationaboutthestatechange.Therepositoryallows to storearbitraryconfigurationdataby meansof extendedLisp objects. Therefore,it is not possibleto provide morespecific,i.e.,strongertyped,interfacesfor eventdatain a genericway. Furthereventhandling,i.e.,queueingof events,is performedthroughtwo standardCORBA eventchannelsasso-ciatedwith eachobject,onechannelfor incomingeventmessagesandonechannelforoutgoingevents.Theintegrationwith Jini is doneoutsideof theconfigurationservice,within thewrapper. Thewrapperis aneventconsumerfor eachrepositoryobject. In-terestedpartiescanregisterwith thewrapperfor statechangeeventsandthewrapperperformslease[26] handling,multiplexing, anddeliveryof theeventsasJini events.

As mentionedin Section5.1, our SCOT repositorycontainsthe configurationin-formationtogetherwith associatedrules(consistency rulesandpolicies).Thus,it doesnot separatesub-services,but allows for theencapsulationof dataandcodeasis usualin object-orientedsystems.

6.2 SNMP Service

We alreadyhad a CORBA/SNMP gateway [7] that works similar to the Joint InterDomain Management(JIDM) approach[27]. It is implementedin C++ andallowsto accessSNMP-enableddevices throughCORBA and to forward SNMP trapsandnotificationsasCORBA events.As onecanimagine,sucha gateway is muchslowerthandirect SNMP messaging.For simplevariableaccessdirect SNMP is around40timesfasterthanthroughthegateway, for tablesthis factoris reducedto 4. [7] containsexactnumbers.

The integrationinto our componentarchitectureaddsa wrappercomponentto theexistinggatewaycomponents(seeFigure5). Thewrapperhastwo tasks:

SNMP gateway. As a “proper” Jini service,the Jini wrapperjoins the Jini manage-ment federationby registeringwith Jini lookup services. Clientscanfind the

6 IMPLEMENTATION 12

CORBA/SNMP gateway

Event Service

�SNMP Trap

�

Daemon

CORBA �

Halfbridge SNMP

�

Halfbridge

CORBA

Interface Repository

Gateway �

Information Center

IIOP

IIOP

IIOP

IIOP

IIOP

IIOP

Jini-Wrapper

(<-> CORBA)

Figure5: Integrationof theSNMPService

CORBA/SNMP gateway via a Jini lookupserviceandregisterfor eventsor ac-cessotherfunctionsof the gateway, suchasgettingsomeinformationfrom anSNMPdevice.

SNMP trap service. TheCORBA/SNMP gateway acceptsSNMPtrapsandnotifica-tions,transformstheminto CORBA objectsandsendsthemto a CORBA eventchannel.TheCORBA-to-Jini wrapperregisterswith this eventchannelandre-lays the event objectsto all interestedJini listeners(seeFigure6). The eventobjectssentto listenerscontainall relevant dataof incomingSNMP trapsandnotifications. Due to limitations of the CORBA/SNMP-gateway implementa-tion the encapsulatednotificationsare actually plain CORBA datastructures(CORBA.Any-objects).They aremappedto a genericTrap class,determinedby thetranslationspecificationof theCORBA/SNMP-gateway. Thiscouldbeex-tendedbymappingtheSNMPnotificationsto specificCORBA typesandmakinguseof CORBA typedeventchannels.

SNMP/ �

CORBA �

gateway

CORBA/ �

Jini �

wrapper �Listener

Listener Listener

CORBA �

Event Channel

�

Jini �

distri- �

buted �

Events

Managed Resource

SNMP �

Trap / �

Notif.

Figure6: SNMPto CORBA to Jini Eventflow

6.3 The Nanny sub-architecture

Our alreadymentionedNanny architecture[3] is a small federationof Jini servicesenablingthe integrationof inheriteddevices,e.g.,printers,X-terminals,laptopsandothermobile devicesinto an environmentof otherservices[6], andfor managementpurposes(cf. Figure6.3). Sinceit wasbasedon Jini servicesfrom the beginning itcouldeasilyparticipatein ouroverallarchitecture.

TheCORBA/SNMP gatewayencapsulatesmanagementof devicesthroughSNMP

6 IMPLEMENTATION 13

Nanny Services

Nanny Factory Service/Cache

�

Nanny Meta Factory

Nanny Factory

Nanny Factory

Nanny Factory

Nanny Factory

Nanny Factory

Nanny Nanny

Jini/RMI �

Jini �

Lookup Service

�

TFTP �

Service �

DHCP Service �

Jini/RMI (register)

Jini/RMI (register)

Jini/RMI: (register/

lookup)

Jini/RMI (register)

Jini/RMI: config./ events

Jini/RMI: config./ events

arbitrary printing protocol �

DHCP

TFTP �

Devices

Management Applications and Services/ Configuration Service

�

Legend: Other (SNMP, TFTP, DHCP, HTTP, ...)

Jini/RMI IIOP

Figure7: TheNanny sub-architecture

asa Jini service. A Nanny that takescareof a device managedthroughSNMP inte-gratesthedevice into themanagementenvironmentin variousways,e.g.:

� TheNanniesannouncetheir serviceasaneventsupplierthroughtheJini LUS.Interestedparties,suchasa managementGUI or an event correlationservice,register with the Nanny as event consumer. The “Hen-and-Egg”-problem issolved by the Jini LUS in a smartway. If the Nanny hasalreadyregisteredwith the LUS an interestedconsumerdetectsit by looking up serviceswith anevent supplierinterface. Additionally the consumerregisterswith the LUS asbeinginterestedin servicesproviding aneventsupplierinterface.If sucha ser-vice registerswith theLUS in the future theconsumeris informedby theLUSaboutthe new supplierandcanregisterwith it for events. Hence,to bring theservicestogether, it finally doesnotmatterwho comesfirst.

� A performancemanagementservicemay frequently requestappropriatedatafrom the availabledevices. It thereforeasksthe LUS for a list of Jini serviceswhich provide such information. Although representedas Jini services,per-formancedataalwaysoriginatesfrom a physicaldevice like a PC or a router.Someof thesedeviceswill be Jini-enabledandprovide the requiredinforma-tion directly. Otherswill be inheriteddevices which are not Jini-enabledbutcanbe managedvia SNMP by a Nanny. The Nanny will performthe requeston behalfof the inheriteddevice by calling the SNMP/CORBA gateway. TheSNMP/CORBA gateway finally forwardsthe requestto the real device as an

6 IMPLEMENTATION 14

SNMPrequest.The resultingSNMPreply is receivedby thegateway andsentbackto the Nanny asCORBA resultmessage.From the viewpoint of the per-formancemanagementtool thereis no differencebetweena native Jini-enableddeviceandaninheriteddevice.

Someof the containedservicesdo not only serve aspart of this sub-architecture,i.e., throughtheNannies,but aredirectly usedby otherpartsof themanagementfed-eration.TheconfigurationserviceandsomemanagementGUIs, for example,directlyregisterwith the DHCP andTFTP sensorsto detectnew devices,even if thereis noNanny finally takingovercontrol.

6.4 Revisiting the SampleScenarios

Comingbackto thescenariosof Section2,weshow how typicalmanagementproblemsaresolvedby ourmanagementfederation.

6.4.1 Forwarding temporary problemsto the appropriate person

During theinitializationphaseof a network printeranappropriateNanny hasacceptedtheresponsibilityfor thedevice. TheNanny retrievesrequiredconfigurationinforma-tion for theunit itself andits environment,e.g.,theclosestprinting serviceandSNMPtrapdaemonof a CORBA/SNMP gateway. It registerstheprinterwith theprint serverasnew workerandforwardssomeof theconfigurationinformationto thedevice in anappropriatemanner, e.g.,by DHCP or TFTP. It thenregistersfor event notificationswith the Jini backendbelongingto the CORBA/SNMP gateway. In casethe printersendsanSNMPtrapaboutanexceptionalsituation,theNanny is ableto interpretthetrapandto constructtheappropriatecontext. For example,if theprinteris runningoutof paper, theNanny canasktheprintingserviceabouttheownerof thecurrentjob andforwardthemessageto her. If theproblemweremissingtoner, theNanny would asktheconfigurationservicefor theadministratoron duty andpropagatetheeventto thatperson.

6.4.2 Helping to solveseriousproblems

If amoreseriousproblemoccurs,e.g.,if somemechanicalpartof theprinterbreaks,ad-ditional actionmaybeactively aidedby themanagementenvironment.In themomentit becomesclearthat thereis a problemwhich cannotbe solved locally, all informa-tion aboutthe problemis enteredinto a troubleticketing system—atleasta problemdescriptionandauniqueidentifierfor thebrokendevice like its mediumaccesscontrol(MAC)address.Throughtheuniqueidentifieradditionalinformationcanbeassociatedwith thetroubleticket,e.g.,

� thetypeof device,

� theresponsiblehardwaresupportcompany,

� thelocationof thedevice,

7 RELATED WORK 15

� theresponsiblelocal systemadministrator.

Openingthetroubleticketusuallyinitiatesfurtheraction:

� The device is disabledin the configurationrepository. This actiontriggersre-configurationof the printing facilities in the workgroupcontainingthe brokenprinter. Currentprint jobsarereroutedandfutureprint jobswill bedirectly sentto anotherprinter—maybebelongingto a neighboringworkgroup. Usersarenotifiedby e-mailthatthey have to fetchtheir printoutsatanotherlocation.

� Theproblemis forwardedto thesupportcompany which assignsa techniciantoit. The techniciangainsfurther informationaboutthe device throughan man-agementaccesspointwhich is openfor externalaccessaccordingto thesecuritypoliciesof theclientcompany. It could,for example,allow to requestthenumberof printedpagesandotherstateinformationdirectly from theprinterthroughtheNanny andtheothercomponentsasoutlinedin Section6.3.Whenthetechnicianvisits the company he bringsthe necessarypartswith him to repairtheprinter.If theprintercannotbefixedlocally hehasa replacementunit with him andhasprovidedthenecessaryinformationfor theintegrationof thereplacementdeviceto the responsiblesystemadministratorbeforehand.If that personhasenteredtheinformationinto theconfigurationrepository, thetechniciancansimplyplugthenew device into thenetwork, power it up, andtheworkgroupcanalmostin-stantlyusethe new printer. Reconfigurationof the printing facilities to usethereplacedprinteris triggeredby thedetectionof thedevice throughits Nanny.

7 RELATED WORK

Java-basedmanagement. Overthelastyears,SunMicrosystemshasstartedseveralefforts to makeJava anenablingtechnologyfor distributedsystemsmanagement.Thefirstone,theJavaManagementAPI (JMAPI, [17]) wassuddenlygivenupin 1998with-outany obviousreasonknown to us.However, it containssomeinterestingapproaches,in particulara hierarchicaleventmodel,wheresubscriberscanspecifyin variousde-greeswhich eventsthey want to see.Suntook up someof the ideasof JMAPI in thenewer approachesanddroppedothers. The newer approachesarethe Java DynamicManagementKit (JDMK, [22]) and the Java ManagementExtensions(JMX, [23]).Althoughbothhave beendevelopedindependentlyin thebeginning,the latter is con-sideredanabstractarchitecturefor managementin generalwhile theformeris seenasanimplementationof thisarchitecture,at leastontheagentandinstrumentationlevels.

JDMK providesa framework for composingmanagementagentsfrom genericandspecificmanagementcomponentsusingJavaBeans[18], Java’snativecomponenttech-nology. It enablesdeploymentof managementcomponentswithin theagentatruntime,therebymigratingpart of the managementintelligenceto the agent. The frameworkabstractsfrom particularcommunicationprotocolsandallows agentsto communicatewith its managerthrougharbitraryprotocoladapters(SNMP, HTTP, RMI, ...). It fur-thermoreallows for thecascadingof agentswhich serveasmanagersto otheragents.

7 RELATED WORK 16

While JDMK is a productwhich canactuallybe purchased,JMX is an abstractarchitecture,which hasa referenceimplementationbut is intendedto have multipleimplementationsby differentvendors.It splitsupmanagementinto threedifferentlev-els: a) an instrumentationlevel, b) an agentlevel, andc) a managerlevel. On a) wefindmanagementinstrumentation,i.e.,managementinterfacesof arbitraryJavaobjects.Managementof non-Javaresourcescanbeachievedvia theJavaNative Interface(JNI,[20]). Instrumentationis encapsulatedby so-calledmanagementbeans(MBeans).Ontheagentlevel (b), JMX proposesMBeanserversthatarecontainerobjectsprovidingacertainruntimeenvironmentfor MBeans.MBeanserversuseprotocoladaptersto al-low manipulationof MBeansby variousmanagercomponents,e.g.,Webbrowsers,andvia proprietaryandstandardizedmanagementprotocols,suchasSNMP, CMIP/TMN,CIM/WBEM, etc. In addition to MBeansusedfor instrumentation,MBeanscanbedynamicallyloadedfrom a managerto performcertainmanagementactionsinsidetheagent.Themanagerlevel (c) is not yet specified.

Comparedto our approach,JMX andJDMK aremorecomplementarythancom-petitive technologies.They currentlysupportthe implementionof agentswhile ourarchitecturetendstowardsthemanagerside. In particular, we do not addressthe im-plementationof agentsfor Java-enableddevices. JMX/JDMK, on the otherhand,donot directly addressconfiguringdeviceson a low level andmakingthempartof a Jinicommunity. Both approachesdealwith non-Java-enabledinheriteddevices, though.Here,our goal is to automaticallyconfigurethesedevicesandintegratetheminto Jinifederations.JMX would only allow thesedevicesto beadministeredvia a numberofprotocols.Additional managementsoftware,e.g.,our Nanny infrastructure,would beneededto configurethe devicesandmake themJini citizens. Sincewe areopentoexisting andnew managementprotocols,it shouldbepossibleto integrateJMX-basedmanagedresourcesjust like othermanagementagents.

On the architecturallevel JMX andour architecturehave a numberof significantdifferences.Our useof Jini allows for arbitraryanddynamicdistribution of compo-nents.MBeansaremorerestrictedasthey canonly easilyaccessMBeansthat residein thesameMBeanserver. InteractionbetweenMBeansof differentMBeanserversisnot spontaneousandneedsto beconfigured.Thequestionhow managersfind agentsto beadministeredis notaddressedby JMX. Jini solvesthisprobleminherently. In thesamevein, JMX only supportslocal event propagation.Jini offers distributedeventswhichallow for morefreedomin componentdistribution.

Jini-basedmanagement. Sunhasshown thatJini andJDMK canbe usedtogetherto manageJini-enabledservicesanddevicesthroughJDMK agents[19]. ManageableJini-enabledentitiesregistertheir proxy objects,which implementa managementin-terface,with the Jini lookup service. Theseproxiesarediscoveredanddownloadedby theJDMK-basedmanagementagent.Jini devicesor servicescannow bemanagedthroughthe managementprotocolsenabledby the managementagent. Thus,the de-viceor serviceis a management-instrumentedJava resourceto theagent.This work isaimedat the integrationof Jini-enabledentitiesinto management,while our approachcoversthe integrationof inheriteddevices. Furthermore,it is importantto notethatthereis a conceptualdifferenceto our architecture.We do managementwith Jini, not

7 RELATED WORK 17

of Jini.Additionally, Sunproposesa new architectureon themanagerlevel (accordingto

the JMX terminology), the so-called“FederatedManagementArchitecture” (FMA,[21]). As of 2000,thereareno practicalexperiencesknown to theauthors,althoughareferenceimplementationbecameavailablerecently. Despitebeingspecificallyaimedat distributedmanagement,FMA actuallyonly introducesa numberof Jini-basedbutgeneraldistributed-systemsservices,e.g.,securityservices,persistency, concurrencycontrol,logging,etc.,whicharewell-known from othermiddlewarearchitectures.

As a mainfeature,FMA introducesso-called“stations”thathostmanagementser-vicesandoffer themawell-knownoperatingenvironment.Stationsarethereforeanalo-gousto EnterpriseJavaBeans(EJB)containers.In additionto hostingservices,stationsplay a key role in FMA’s fault-tolerance,security, concurrency control,andremotein-stantiationmechanisms.All thesemechanismsrequirecommunicationto bemediatedby thestationhostingthetargetservice.Thisis achievedby addinganappropriatelayeron top of RMI. RMI is thereforetheonly usableprotocolin anFMA system.Empha-sizing FMA beinga generalmiddlewareplatform, an informationmodel—whichisgenerallyconsideredimportantfor managementarchitectures—isnot specified.Theother Java-basedmanagementarchitectures(JDMK/JMX) are basedon Java-centricinformationmodelsandcouldbeusedin conjunctionwith FMA.

Similar to ourapproach,FMA proposesamanagementframework wheretheman-agementitself is distributed. Someof the servicesintroducedby FMA, e.g.,logginganddeployment,arenot yet existentin our systemandwould enhanceit. Most of theproposedmechanismsdo not fit into our model,though,becausethey arerestrictedtothe augmentedversionof RMI. Oneof the main advantagesof Jini (andoneof themainreasonsfor ususingit)—protocolindependence—islost in FMA systems.Incor-poratinginheritedcomponentsin an FMA systemis thereforemorecomplex thanina plain Jini system.Looking at theeventmodel,we find thatFMA usestheJini/RMIcommunicationmodelandonly extendsit by aneventmultiplexer. We demonstrateda similar solutionby the integrationof a CORBA eventchannel.In contrastto FMA,our architectureprovidesan informationmodel[5] which is largely basedon the re-quirementsof configurationmanagementbut which is alsousablein otherfunctionalareasof distributed-systemsmanagementthroughits integrationwith CORBA andthemappingto HTML or XML.

However, it is importantto notethatFMA is backedby somevendorsin thefieldof StorageAreaNetworks(SAN), theJiro initiative [12].

Component architectures. Lewis et al [13] describea managementsystemcom-prisedof a setof interactingcomponents.Thesystemintroducesplug-and-playfunc-tionality by the use of a so-called“integrator”. This componentconnectsvariouscomponentsat runtime. Our architectureemploys Jini to achieve that functionality.Their systemusesthe event modelof the CORBA componentmodelwhich followsa publish/subscribe/distributeparadigmjust asthe Jini distributedeventsusedin ourarchitecture.An additionaladvantageof usingJini distributedeventsis the handlingof partial failure. All event registrationsareboundto a leaseandhave to berenewedregularlyby thelistener. If alistenerbecomesunreachableanddoesnotrenew its lease,

7 RELATED WORK 18

it is automaticallydiscardedassoonastheleaseexpires.Crashedlistenersdothereforenot consumeresourcesunnecessarilyoveranextendedperiodof time. CORBA eventsdo nothave this feature.

Feridunetal [8] describeanapproachto distributedmanagementusinglightweightmobile componentsthat canrun anywherein the managedsystem.Componentsarerun on participatingnodesin dedicatedenvironmentsandarelocatedvia a distributeddirectory. Most of the infrastructurefunctionality is providedby theVoyagermiddle-ware.It is thereforecomparableto ouruseof Jini, but it offersaslightly differentsetofservices,e.g.,Jini incorporateseventsfor changesin the setof availablecomponentsbut doesnot handlepersistency or migration. Their useof a dedicatedenvironmentallows for lifecycle management,i.e., installation,migration,andremoval, of compo-nents. A similar schemecould easily be integratedinto our architectureandwouldenhanceit. Our useof a configurationservicehelpskeepingthemanagedsystemin avalid state.This is notaddressedin their architecture.

Our Nanny architectureis anextensionto thedevice bay[25] conceptof Jini. TheJini SurrogateProject[11] alsodefinesanextendeddevicebayarchitecture.In particu-lar, it specifiesanadditionallightweightprotocol,theJini TechnologyIP Interconnectprotocol[10] basedonUDPto integratesmalldeviceswhicharenotableto incorporatea native Java virtual machine.This is the main differenceto our Nanny architecture,sincewe try to integrateinheriteddeviceswith their inheritedprotocols(DHCP, TFTP,SNMP)insteadof defininga new protocolto integratetheminto a Jini federation.

Web-basedapproaches. Marvel [2, 1] is anarchitecturefor managingresourcesattheservicelevel ratherthanat theelementlevel. It aggregatesinformationretrievedvialow-level protocolsinto higherlevel objects. It usesJava andits dynamiccodeload-ing functionalitiesfor extendingthesystemwhile operating.Although it allows arbi-trary clientsto accessaggregatedmanagementinformation,Marvel is mainly gearedtowardshumanaccessvia the World Wide Web using HTML and Java applets. Incomparison,our architecturetendsmoretowardsprogrammedserviceinteractionbutallows WWW accessvia specializeddisplaycomponents.Marvel mainly addressessupervisionwhile our approachdealswith configurationmanagement.Marvel, too,usesa publish/subscribe/distributeparadigmfor eventpropagation.

Other automatic service location facilities. The ServiceLocation Protocol(SLP[29]) allows finding the locationof arbitraryserviceswithin an IP network. Its boot-strappingandtradingfacilitiescanbecomparedto Jini but it only providesinformationin theform of name-valuelists insteadof objects.UniversalPlugandPlay(UPnP[28])is a recently announcedservicetrading infrastructurebuilt on top of HTTP-basedmulticast-protocols.Servicesregistertheir Uniform ResourceLocators(URLs) witha centralSimpleServiceDiscovery Server togetherwith a type descriptionstandard-izedby theInternetEngineeringTaskForce(IETF). Clientsquerythisserver to obtainURLs of the desiredtype. NeitherUPnPnor SLP have mobile proxies(for protocolindependenceandeasyintegrationof legacy systems)anddistributedevents(for moni-toring). For ourwork, they arethereforeno viablealternativesto Jini.

8 CONCLUSION 19

8 CONCLUSION

In this paperwe describedour architectureof smalldistributedmanagementservices.We showed how it supportsvariousnetwork managementscenariosandhow it com-paresto othermanagementarchitecturesandframeworks.

It shouldnot beneglectedthatthereis adownsideto thespontaneityintroducedbyour architecture.Everybodywho hasaccessto a computerconnectedto the networkcanstartandaccessmanagementservices.While thisis desiredin many circumstances,it opensthe door for misuseaswell. Network managementcanbe easilyandeffec-tively disabledby introducinga fakeservice,e.g.,a configurationservicethatsuppliesincorrectdata.This problemcouldbesolvedby theuseof authentication.Most man-agementcomponentsdo not keepseparateaccountsfor individualadministrators.It isusuallyenoughto provethepossessionof administrator’s rights,e.g.via passwordsorkeys. It thereforeappearsto beadequatelysecurefor mostpurposesto requireeverycomponentto identify itself to the infrastructure,i.e., the Jini lookupservice,andletthe infrastructureenforceaccessrestrictions.We describedsucha solutionin [9] butits applicabilityhasto befurtherinvestigated.

Figure8: Snapshotof theManagementConsole

Anotherchallengefor ourarchitectureis scalability. With agrowingnumberof ser-vicesthereis therisk thattheoverview of servicelocationandcomponentinteractionislost. Meansfor adequatemanagementof Jini servicesespeciallyaddressingthemen-tionedproblemshaveto beinvestigated.We partlyaddressedtheproblemof unknownservicelocationby addingappropriatemanagementdatato servicesandby allowinga genericWeb-enabledmanagementconsoleto displaythatdata.Service-specificad-ministrationcanbeperformedby displayinggraphicaluserinterfacesattachedto ser-vices. Figure8 showsa snapshotof this consoledisplayingsomeof our management

REFERENCES 20

services.

ACKNOWLEDGMENTS

We would like to thankRonBourret,AlejandroBuchmann,RogerKehr, FriedemannMattern,andAndreasZeidlerfor proof-readinganddiscussionof earlierdraftsof thispaper. We would alsolike to thankthereviewersandtheeditorsof theJNSMspecialissuein whichashortenedversionof thisarticlewill appear[4] for theirvaluablehelp.

References

[1] NikolaosAnerousis. An Information Model for GeneratingComputedViewsof ManagementInformation. In Proceedingsof Ninth IFIP/IEEE InternationalWorkshopon Distributed Systems:Operations and Management(DSOM’98),pages169–180,October1998.

[2] NikolaosAnerousis. ScalableManagementServicesUsing Java andthe WorldWide Web. In Proceedingsof Ninth IFIP/IEEE InternationalWorkshopon Dis-tributedSystems:OperationsandManagement(DSOM’98), pages79–90,Octo-ber1998.

[3] Gerd Aschemann,SvetlanaDomnitcheva, PeerHasselmeyer, RogerKehr, andAndreasZeidler. A Framework for theIntegrationof Legacy Devicesinto a JiniManagementFederation.In Proceedingsof TenthIFIP/IEEE InternationalWork-shopon DistributedSystems:OperationsandManagement(DSOM’99), volume1700of LectureNotesin ComputerScience(LNCS), pages257–268,Heidelberg,October1999.Springer-Verlag.

[4] GerdAschemannandPeerHasselmeyer. A LooselyCoupledFederationof Dis-tributedManagementServices. Journal of Networkand SystemsManagement(JNSM), 9(1):51–65,March2001.

[5] GerdAschemannandRogerKehr. Towardsa Requirements-basedInformationModel for ConfigurationManagement.In Proceedingsof 4th InternationalCon-ferenceon ConfigurableDistributedSystems(ICCDS’98), pages181–189.IEEEComputerSocietyPress,May 1998.

[6] Gerd Aschemann,Roger Kehr, and AndreasZeidler. A Jini-basedGatewayArchitecturefor Mobile Devices. In ClemensH. Cap, editor, ProceedingsofJava-Informationstage(JIT’99), Informatikaktuell,pages203– 212,Heidelberg,September1999.Springer-Verlag.

[7] GerdAschemann,ThomasMohr, andMechthildRuppert. Integrationof SNMPinto a CORBA- andWeb-BasedManagementEnvironment. In ProceedingsofKommunikationin Verteilten Systemen, pages210–221,Heidelberg, February1999.Springer-Verlag.

REFERENCES 21

[8] M. Feridun,W. Kasteleijn,andJ.Krause.DistributedManagementwith MobileComponents.In Proceedingsof Sixth IFIP/IEEE InternationalSymposiumonIntegratedNetworkManagement(IM’99), pages857–870,May 1999.

[9] PeerHasselmeyer, RogerKehr, andMarcoVoß. Trade-offs in a SecureJini Ser-vice Architecture. In Trendstowards a Universal ServiceMarket (USM 2000),volume1890of LectureNotesin ComputerScience(LNCS), pages190–201,Hei-delberg, September2000.Springer-Verlag.

[10] Jini TechnologyIP InterconnectSpecification.http://developer.jini.org/exchange/projects/surrogate/IPInterconnect.pdf.

[11] Project Surrogate(Jini). http://developer.jini.org/exchange/projects/surrogate/.

[12] JiroTechnology.http://www.jiro.com/.

[13] David Lewis, ChrisMalbon,GeorgePavlou, CostasStathopoulos,andEnricJaenVilloldo. IntegratingServiceand Network ManagementComponentsfor Ser-vice Fulfilment. In Proceedingsof TenthIFIP/IEEE InternationalWorkshoponDistributedSystems:OperationsandManagement(DSOM’99), volume1700ofLecture Notesin ComputerScience(LNCS), pages49–62,Heidelberg, October1999.Springer-Verlag.

[14] Jean-PhilippeMartin-Flatin. Pushvs.Pull in Web-BasedNetwork Management.In Proceedingsof SixthIFIP/IEEE InternationalSymposiumon IntegratedNet-workManagement(IM’99), May 1999.

[15] JonathanD. Moffet. Specificationof ManagementPoliciesandDiscretionaryAc-cessControl. In Morris Sloman,editor, NetworkandDistributedSystemsMan-agement, pages455–480.Addison-Wesley PublishingCompany, 1994.

[16] ObjectManagementGroup,Inc. (OMG). CORBA EventServiceSpecification.December1997.

[17] SunMicrosystemsInc. Java ManagementAPI. http://java.sun.com/products/JavaManagement/index.html.

[18] SunMicrosystemsInc. JavaBeans.http://java.sun.com/beans/.

[19] SunMicrosystemsInc. Jini TechnologyandtheJava DynamicManagementKitDemonstration. http://www.sun.com/software/java-dynamic/wp-jdmk.kit/.

[20] Sun Microsystems Inc. Java Native Interface Specification. http://java.sun.com/products/jdk/1.2/docs/guide/jni/spec/jniTOC.doc.html, May 1997.

[21] SunMicrosystemsInc.,901SanAntonioRoad,PaloAlto, CA 94303,USA. Fed-eratedManagementArchitecture (FMA) – Version 1.0 – Revision 0.4, January2000.

REFERENCES 22

[22] SunMicrosystemsInc.,901SanAntonioRoad,PaloAlto, CA 94303,USA. JavaDynamicManagementKit WhitePaper, April 2000.

[23] Sun MicrosystemsInc., 901 SanAntonio Road,Palo Alto, CA 94303,USA.JavaManagementExtensionsInstrumentationandAgentSpecification,v1.0, July2000.

[24] SunMicrosystemsInc. Jini Architecture Specification– Version 1.1. http://www.sun.com/jini/specs/jini1_1.pdf, October2000.

[25] Sun MicrosystemsInc. Jini Device Architecture Specification– Version 1.1.http://www.sun.com/jini/specs/devicearch1_1.pdf, October2000.

[26] Sun MicrosystemsInc. Jini Technology Core Platform Specification– Ver-sion1.1. http://www.sun.com/jini/specs/core1_1.pdf, October2000.

[27] TheOpenGroup.Inter-DomainManagement:SpecificationTranslation& Inter-actionTranslation, January2000.

[28] UniversalPlugandPlayHomepage.http://www.upnp.org/, 1999.

[29] J. Veizades,E. Guttman,C. Perkins,andS. Kaplan. ServiceLocationProtocol(SLP). InternetRFC2165,June1997.

BIOGRAPHIES

Gerd AschemannreceivedhisDiplomadegreein ComputerScienceat theDarmstadtUniversityof Technologyin 1995. From 1995to 2000he hasbeenworking asa re-searchassistantin theDistributedSystemsResearchGroupof thesameUniversity. Heis writing aPhDthesisonconfigurationmanagementin distributedsystems.Currentlyhe is startinga new careerasan independentconsultantin systemsmanagementandInternettechnologies.His maininterestsbesidesnetwork managementanddistributedsystemsmanagementareopenmiddlewareinfrastructures.PeerHasselmeyer receivedaMasterof Sciencedegreein ComputerSciencefrom theUniversityof Colorado,Boulder, in 1995.In 1997,hegraduatedfrom DarmstadtUni-versityof Technology, Germany, andreceiveda diplomadegreein ComputerScience.Sincethen,hehasbeenaresearchassistantandPhDcandidatein theComputerSciencedepartmentof thatUniversity. His researchinterestsincludespontaneousnetworking,middleware,andnetwork andservicemanagementsystems.