Method and apparatus for using a command design pattern to access and configure network elements
0 likes57 views
The document describes a patent for a method and apparatus that utilize a command design pattern to access and configure network devices using XML. It outlines a network data transfer service capable of processing XML encoded requests and executing services on network devices, thus allowing for more efficient device management. The invention aims to improve network management by leveraging XML for clearer communication and interaction with various network devices.
Method and apparatus for using a command design pattern to access and configure network elements
- 1. US008782230B1 (12) United States Patent (10) Patent No.: US 8,782,230 B1 Swedor et al. (45) Date of Patent: Jul. 15, 2014 (54) METHOD AND APPARATUS FOR USINGA 6,292.489 B1* 9/2001 Fukushima etal. .......... 370/401 COMMAND DESIGN PATTERN TO ACCESS 6.463,528 B1 * 10/2002 Rajakarunanayake et al. ... 713/1 6,546,419 B1 * 4/2003 Humpleman et al. ........ 709,223 AND CONFIGURE NETWORKELEMENTS 6,662.342 B1* 12/2003 Marcy ........................... 715,513 6,880,005 B1 * 4/2005 Bell et al. ...................... 709,225 (75) Inventors: is: K.Sweety's ErieTa 6,973,488 B1* 12/2005 Yavatkaretal. TO9,223 . Lavian, Sunnyvale, CA(US); Robert 7,054,901 B2* 5/2006 Shafer ............ TO9,203 J. Duncan, San Francisco, CA (US) 2002fOO32768 A1* 3,2002 Voskuil ... TO9,224 2004/O13377.6 A1* 7/2004 Putzolu ......................... T13,153 (73) Assignee: Rockstar Consortium US LP, Plano, TX (US) * cited by examiner (*) Notice: Subject to any disclaimer, the term ofthis patent is extended or adjusted under 35 Primary Examiner—TamaraT Kyle U.S.C. 154(b) by 1162 days. (74) Attorney, Agent, or Firm — David A. Dagg (21) Appl. No.: 09/726,758 (57) ABSTRACT (22) Filed: Nov. 29, 2000 O O An XML accessible network device is capableofperforming Related U.S. Application Data functionsinresponsetoanXMLencodedrequesttransmitted (60) Provisional application No. 60/213,107, filed on Jun. over a network. It includes a network data transfer service, 21, 2000. coupled to a network, that is capable of receiving XML encodedrequests from aclientalsoconnectedtothe network. (51) Int. Cl. A serviceengine is capable ofunderstandingand parsingthe G06F 15/16 (2006.01) XML encoded requests according to a corresponding DTD. (52) U.S. Cl. Theserviceenginefurtherinstantiates aserviceusingparam USPC .......................................................... 709/226 eters providedin the XML encoded requestand launches the (58) Field ofClassification Search service for execution on the network device in accordance USPC ............ 71.5/513; 709/229, 223, 224; 370/401 with a command design parameter. A set of device APIs See application file for complete search history. interacts with hardware and software on the network device forexecuting the requested service on the network device. If (56) References Cited necessary,aresponseis furthercollected from thedeviceand U.S. PATENT DOCUMENTS 5,848,233 A * 12/1998 Radia etal. ..................... T26.13 6,167,448 A * 12/2000 Hemphill etal. ............. TO9,224 ReceiveXML encodedrequest SF2 ParsexM. requestwith DTD St04. x7 Instantiateservice withparsedvalues SF6 InvokeOperate method ofservice SFO8 Interactwith Device W &SW to ExecuteService S10 provided to the client in a response message. 21 Claims, 4 Drawing Sheets
- 2. U.S. Patent Jul. 15, 2014 Sheet 1 of4 US 8,782.230 B1 Response Client 100 FIG. 1 (PriorArt) DTD 202 DTD 202 ?ease 1 -Response Response Client 100' FIG. 2 Command Design Pattern
- 3. U.S. Patent Jul. 15, 2014 Sheet 2 of4 US 8,782,230 B1 Network Data Transfer Service 302 Response Packets containing XML Device documents Software and Hardware ---------------D CD 306 Packets Services containing 308 response (if s NetworkDevice 104 any) FIG. 3 Services 308 Service Engine 304 Service Launcher 404 Response Response Formatter Retriever 410 4.08 FIG. 4
- 5. U.S. Patent Jul. 15, 2014 Sheet 4 of4 US 8,782,230 B1 Receive XML encoded request S702 FIG. 7ParSeXML request with DTD S704 Instantiate service with parsed values S706 Invoke Operate method ofservice S708 Interact with Device HW & SW to Execute Service S710 Response Required? S712 Retrieve Response Info S714 Format and Forward Response Message
- 6. US 8,782,230 B1 1. METHOD AND APPARATUS FOR USINGA COMMAND DESIGN PATTERN TO ACCESS AND CONFIGURE NETWORKELEMENTS CROSS-REFERENCE TO RELATED APPLICATIONS The present application is based on, and claims priority from U.S. Provisional Applin. No. 60/213,107, filed Jun. 21, 2000. Thepresentapplication is also related to U.S. applica tion Ser. No. 09/692,949 (NOR-12520BA) and U.S. Appln. Ser. No. 09/727,341 (NOR-12675HU), both commonly owned by the assignee ofthe present application. FIELD OF THE INVENTION Thepresent invention relates to networkdevice configura tion and monitoring, and more particularly, to a method and apparatus foraccessing, configuringandcontrollinga device stationed on a network using a command design pattern and documents written in a markup language such as XML. BACKGROUND OF THE INVENTION Computer networks continueto proliferate. As they do so, they become increasingly complex and difficult to manage. This problem is exacerbated when a variety of network devices, computers, and Software are combined together to integrate large intranets with the Internet. As shown in FIG. 1, when a client 100 wants to learn information regardinga remotenetworkdevice104Stationed on a network 102, code executing on client 100 formats a message requesting Such information and sends it to the net work device 104. Network device 104 must be prepro grammedwith functionality forcommunicating in theproto col requiredby client 100's messageandforknowingexactly how to get the information requested. Ifso, network device 104 can then respond with the requested information. Simple network management protocol (SNMP) is one example ofa network protocol that allows clients to learn information about remote network devices. SNMP allows network devices 104 to send alerts to a manager 102, or to send statistical informationabouttraffic,butitlimits thekind ofinformation thatcan besent to thatwhich ispre-definedin the management information blocks (MIBs) coded into the network device. Accordingly, a new MIB needs to be rede fined each time a new type ofinformation is maintained oris needed about the device, thus making network management and performance even more problematic. SUMMARY OF THE INVENTION The present invention relates to an apparatus and method for more efficiently accessing, configuring and controlling a network device using a common design pattern and docu ments written in a markup language such as the Extensible Markup Language (XML). In accordance with one aspect ofthe invention, an XML accessible networkdeviceis capableofperforming functions in response to an XML encoded request transmitted over a network. It includes a network datatransferservice, coupled to a network, that is capable of receiving XML encoded requests from a client also connected to the network. A ser Viceengine is capableofunderstandingandparsingtheXML encoded requests according to a corresponding document typedefinition (DTD).Theserviceenginefurtherinstantiates a service using parameters provided in the XML encoded 10 15 25 30 35 40 45 50 55 60 65 2 requestandlaunchestheserviceforexecution onthenetwork device using a command design parameter. A set of device APIs interacts with hardware and software on the network device for executing the requested service on the network device. Ifnecessary ordesired,a responseis furthercollected from the device and provided to the client in a response message. In accordance with another aspect of the invention, a method for causing a network device to locally perform a servicecomprisesthestepsofreceivingatthenetworkdevice a document written in accordance with a markup language anda corresponding document definition, parsingby the net work device the received document in accordance with the correspondingdocumentdefinition,andexecutingtheservice on the network device in accordance with the parsed docu ment and a command design parameter. In accordance with a further aspect of the invention, a networkdeviceforlocallyperformingaserviceinresponseto a remote request comprises means for receiving at the net workdeviceadocumentwritten inaccordancewith a markup language and a corresponding document definition, means forparsing by the network device the received document in accordancewith the corresponding document definition, and means for executing the service on the network device in accordancewith theparseddocumentand acommanddesign parameter. In accordance with a further aspect of the invention, a networkdeviceforlocallyperformingaserviceinaccordance with a received document written in a document markup language comprises a parser that is adapted to parse the receiveddocumentinaccordancewithadocumentdefinition, a service engine coupled to the parser that is adapted to instantiate an object corresponding to the service in accor dance with theparsed received document, and to executethe service in accordance withtheinstantiatedobjectandacom mand design parameter. BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other features, aspects, and advantages ofthe present invention will become moreapparentfrom the following detaileddescription when read in conjunction with the following drawings, wherein: FIG. 1 illustratesaconventionalarchitectureforaccessing, configuring and controlling a network device using standard network protocols; FIG. 2 is a functional overview ofan apparatus foraccess ing,configuringandcontrollinganetworkdeviceusingXML encodeddataandacommanddesignparameterin accordance with the present invention; FIG. 3 further illustrates an example ofa network device that is configured in accordance with the present invention; FIG. 4 further illustrates a service engine that can be included in a network device accordingto the invention Such as that illustrated in FIG. 3; FIG. 5 is an architectural view ofa network device that is configured in accordance with the present invention; FIG. 6 is an example implementation ofa network device inaccordancewiththeinventionandthearchitecturedepicted in FIG. 5; and FIG. 7 illustrates a process for accessing, configuring and controlling a network device using XML encoded data in accordance with the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will now be described in detail with referencetotheaccompanying drawings, whichareprovided
- 7. US 8,782,230 B1 3 as illustrative examples of preferred embodiments of the present invention. Notably, the implementation of certain elements ofthepresentinvention maybeaccomplishedusing software, hardware or any combination thereof, as would be apparent to those ofordinary skill in the art, and the figures and examples below are not meant to limit the scope ofthe present invention. Moreover, where certain elements ofthe presentinvention canbepartially orfully implementedusing known components, only thoseportions ofSuch known com ponentsthatarenecessaryforanunderstandingofthepresent inventionwillbedescribed,anddetailed descriptionsofother portions ofsuch known components willbe omitted so as not to obscure the invention. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way ofillustration. FIG. 2 is a functional overview ofone embodiment ofthe presentinvention.As shown, a client 100' is connected in the conventional manner to a network Such as the Internet or an intranet (i.e. LAN/WAN/MAN) 102, which in turn is con nected to a network device 104" (e.g. router, switch, hub or similardevicecapableofprocessing fixed-lengthorvariable length packets ina network). It shouldbe noted thatalthough the features and advantages ofthe present invention are par ticularly well suitedto routers,switchesandhubs,andwillbe describedinmoredetailbelow withreferencetosuch devices, other network-aware devices can be adapted for use in the present invention, and so the invention is notto be limited to these particular illustrative devices. For example, network device 104" may also include gateways, multiplexers and other known or future equivalents, including those having a packet forwarding architecture. Asisapparentfrom FIG.2,incontrastwiththepriorart, the presentinventionprovidescommunicationsforaccessingand configuring network elements using XML documents and a common design pattern. As is known, XML is a metalan guagebuiltupontheStandardGeneralizedMarkup Language (SGML), and is a tool for defining text markup languages, defined by the World Wide Web Consortium (W3C). An XML-defined language comprises a set of tags, attributes, and constraints on how to use them. XML is a simple, open, portable, extensible means of representing data. Unlike HTML, XML tags tell what the data means, instead ofjust how to displayit. Furtherinformation regardingXMLcan be foundfrom theW3Cweb pages at http://www.w3.org/XML. Those skilled in the art, after being taught by the present disclosure,willappreciatethattherearemanyflavorsofXML andSGMLandthatmany markup languagesareequivalentto XML for adaptation and implementation according to the presentinvention. XML is describedin detail in this applica tion because ofits wide acceptance and adoption. However, equivalents toXML thatare within thescopeofthe invention can include, for example, XSL, XSLT, XPath, XLink, XPointer, HyTime, DSSSL,CSS,SPDL, CGM, ISO-HTML, and others. As is further known, the format ofan XML document is definedbya DocumentType Definition (DTD).Accordingly, thepresentinvention includes localcopies ofDTD202 atthe sendingandreceivingends oftheXML document.Therecan bejust one DTD 202 that defines all communications forall applications,ortheremaybedifferent DTDs202fordifferent types ofapplications, and those skilled in the art will under stand the possible variations. Further, there are many ways known in the art that such local copies of DTD 202 can be retrievedandobtainedby networkdevice 104",andthedetails thereofwill not be presented so as not to obscure the inven tion. 10 15 25 30 35 40 45 50 55 60 65 4 Generally, when the client computer 100' wants to access orconfigure network device 104" (i.e., cause network device 104 toperform a servicelocally on the networkdevice 104"), it creates an XML request identifying the service to be per formed, which XML document is encoded in the format defined by DTD 202 but with parameters specific to the desired access or configuration. Client 100' sends the docu ment over the network 102, which document is received by the network device 104' in the form of data packets as is conventionally done. In contrastto theconventional network device 104, the network device 104" has been adapted to include functionality necessary to decode the XMLencoded request and to identify the service to be performed. Using a common design pattern, the network device 104 allows the service to perform tasks necessary to complete the request, including, ifrequired, interactingwith thehardwareandsoft wareofthedevicetoperformaservicelocally on thenetwork device 104. Iffurther needed or desired by the client com puter, networkdevice 104" may create and formata response to client computer 100', which may or may not also be an XML encoded document. FIG.3 illustrates a network device 104' in accordance with the present invention in further detail. As shown in FIG. 3, networkdevice 104" comprises, in part, a network data trans fer service 302, a service engine 304 that accesses local copiesofDTD202andservices308,anddevicesoftwareand hardware306. Itshould be apparent that networkdevice 104 can contain orincludeothercomponents forperformingcon ventionalSwitchingandroutingfunctions,forexample. How ever, the details ofSuch additional components are not pre sentedheresoas nottoobscurethepresentinvention. Further, although DTD 202 and services 308 are shown as local stor ages, it should be apparent that such storage need not be permanent.Forexample,DTDsandservicesmaybe retrieved from a remote server via a URL, andjusta temporary repre sentation can be residenton device 104"as needed by service engine304according totechniques well understoodbythose ofskill in the art. Devicehardwareandsoftware306 representsconventional switchorrouter functionality thathasbeen adapted forusein thepresentinvention. In onepossible implementation, where network device 104' is an Accelar/Passport family router switch from Nortel Networks, devicehardwareand software 306 includes an ASIC-based forwarding architecture, with switch ASICs comprising most ofthe device's switch fabric and handling most forwarding tasks among Switch ports in accordancewith residentforwarding rules. ForSuch a device 104", device hardware and software 306 further includes a CPUandassociated memorycoupledtotheswitch fabricthat runs the VxWorks real-time OS, and existing applications stored in memory and executed by the CPU that run as VxWorks “tasks for monitoringandcontrolling and config uring the ASIC forwarding hardware via a switch-specific API. It should be apparent that other types ofswitches and routers maybeusedinaccordancewiththeinvention,andthat other operating systems such as Linux, PSOS, Vertex and RMX may comprise the device's operating system. Servicesinstorage308preferablyincludeapplicationsthat enhance the network management capabilities ofthe device 104" aboveand beyond that which is possible with a conven tional network device 104. Such applications may include means forsetting and reporting system variables that are not limited by pre-configured MIBs. Such applications may fur ther include means for configuring the forwarding architec ture so as to enable the device to filter network traffic con taining packets generated from activities not essential to a company's business. Such as browsing the Internet. Other
- 8. US 8,782,230 B1 5 examples ofservices can includeeventloggers and monitors, means forestablishingdifferent levelsofquality ofservicein packet forwarding decisions, and the like. Although the dis cussionbelow will center on services thatarelaunchedusing a command design parameter in accordance with the inven tion, it should be noted that device 104 may also include functionality for executing similar remotely downloaded, installedand managedservices, which additional similarser vices may also be stored in storage 308. In one example of the invention, device hardware and software 306 also includes an Oplet Runtime Environment (ORETM, a trademark of Nortel Networks), which is a plat form forsecure downloading,installation,andsafeexecution ofservices ona networkdevicesuch asaSwitch orrouter, the downloaded services (i.e. Oplets)being locally stored in ser vices storage 308. In such an example ofthe invention, the networkdata transferservice302andserviceengine304may actually beimplementedas oneormore services (i.e. Oplets) managed by the ORETM (not necessarily having a command design parameter). The ORETM is described in more detail in otherpublications, including publications posted atthe web site www.openetlab.org,and so will notbe describedin detail here so as not to obscure the invention. Although use ofthe invention in network devices equipped with an ORETM is consideredonepreferredimplementation,theinventionisnot so limited. Further, the functionalities provided by the ORETMthatareusefulforthepresentinvention will beappar ent to thoseskilled in theartafterbeingtaughtby thepresent specification and can be separately provided. Network data transfer service 302 is, for example, an HTTP server such as one provided by Apache. This is because, in one example ofthe invention, theXML encoded requests and device responses (ifany) are exchanged using the HTTP protocol. As is known, HTTP is an application level protocol that is generic, stateless, and can be used for manytasksotherthantransferringhypertext,whichis its most widelyknownuse. Inoneexampleoftheinvention,the HTTP communications take place over TCP/IP connections. The most widely used HTTP methods for handling communica tions are GET, HEAD and POST. The service engine 304 is registered with the HTTP server (by port number, for example) so that when XML encoded requests according to the invention are receivedby service302, serviceengine304 canbeactivatedandprovidedwiththeXMLencoded request. The HTTP server keeps handles for all received requests pointing to the requesting client’s address (perhaps with a timeout), and when responses from service engine 304 are receivedalongwith thehandle, theHTTPserverprovides the response back to the requesting client using HTTP methods. It should be apparent that other techniques for sending XML files through the HTTP protocol could be used. More over,inanotheralternativeofthe invention,responsesmaybe forwarded back to the requesting client in various presenta tion alternatives such as providing HTMLpages forbrowser aCCCSS, Device hardware and software 306 is adapted in accor dance with the invention to forward packets using the HTTP protocol andaddressedto networkdevice 104 to the network data transfer service 302, ifan HTTP server is not already providedinthedevice.Thiscanbedonein manywaysknown to those skilled in the art, and may depend on the particular packet forwarding architecture of the device. For example, where packets addressed to the device areautomatically for warded to the device's CPU, the device's kernel packet han dling need only be aware of, and be able to communicate packets with, the HTTP server. 10 15 25 30 35 40 45 50 55 60 65 6 Service engine 304 is generally responsible for receiving XMLencoded documents,forparsingthedocumentstoiden tify the requested service and any specific run-time param eters, for causing the device 104 to perform the requested service inaccordance with the common design patternand,if appropriate, obtaining and formatting a response to the requesting client. Service engine 304 is further illustrated in FIG. 4. As shown,itincludesaparser402,aservicelauncher404, device APIs 406, response retriever408and responseformatter410. Although shown separately for clarity of the invention, the different blocks shown in FIG. 4 can be implemented in variouscombinationseithertogetherorseparately. Moreover, some or all of the functionalities may be partially or fully includedas functionalitiesoftheORETMintheexampleofthe invention where theORETM is included in the networkdevice 104". Parser 402 receives the XML document from the network data transfer service 302 (preferably along with a handle for the individual request), and retrieves the necessary DTD based on the requiredidentifierin theXML document. Using the appropriate DTD, parser 402 performs processing based on the XML tags defined in the DTD and extracts out the values for each included in the XML document. These parsed-out values are provided to the service launcher 404. There are several different conventionally available XML parsers that can be used to implement parser 402. Such as Document Object Model (DOM), Simple API for XML (SAX) and Java Document Object Model (JDOM). In one example of the invention, parser 402 is implemented by an AelfredXMLparserfromOpenText.TheAelfredparsergen erates SAX events for each parsed XML tag. These parsed out values and SAX events are supplied to service launcher 404. Ata minimum, the DTDand theXML documentshouldat least specify one of the services 308 to be performed. For example, the DTD may includea definition such as: <ELEMENT Serviced <ATTLIST Service class CDATA HIMPLIED Source CDATA HIMPLIED id ID #IMPLIEDs This allows an XML document to specify a “service' having “class,” “source' and “id' parameters. Accordingly, a client wishing to launch a service on a remote device would create an XML document specifying a “service' with at least a desired “class. Such a corresponding XML document may includethefollowingtext (as well asan identifierofthe DTD that defines its structure): <service class="Address’ id=ID 2'> </service> This XML document requests the network device 104" to launch a “service' havinga class of“Address.” Accordingly, in this example of the invention, when the network device 104 receives theXMLdocument,parser402 will retrievethe DTD indicated by the identifier in the document. Using this DTD, it will understand that a “service' having a class of “Address' should be launched. Accordingly, it will send a message to service launcher 404 to launch a service defined by the class Address, which can, for example, cause the physical address ofthe device to be set or reported. Itshouldbe noted that thesourceorbytecodecorrespond ing to the service “class” may be originally available locally onthedevice104"oritmaybe remotely locatedandspecified by a URL or other path descriptor to a class file containing Such source or byte code. In one example ofthe invention where the Java programming language is used, the “class'
- 9. US 8,782,230 B1 7 identifierisa class whosebytecode canbe includedin a Java Archive (JAR) file. If the byte code corresponding to the specified “class” is located with a URL, the service engine 304(perhaps incooperation with transferservice302)down loads the file for local access in storage 308. Additionally or alternatively, the service engine 304 may check whether an object corresponding to the requested service has already been instantiated using the “id' parameter. Ifthe service includes any runtime parameters, the DTD and XML documents should specify those as well, although the service should be able to execute using default param eters. Depending on the service requested, there may or may not bea requested response to be sent back to the client. For example, one requested service may be to provide traffic statistics of the device, for which a response would be col lected from the devicehardware and software and returned to the client. Meanwhile, another requested service may be to adjustpriorities ofcertain traffic flows, forwhich a response from thedevicehardwareand softwarewould not necessarily be requested. As an example of a requested service with runtime parameters, a requested service may be to report on device throughput, collected a variable number of seconds apart, with the report repeatedly provided back to the client once per variable number ofminutes. Usingthe aboveexampleoftheserviceofclass Address.” the DTD may further include a definition such as: <!ELEMENT property (valuelinull)*> <!ATTLISTproperty name CDATA #REQUIREDD <!ELEMENT value (#PCDATA)*> <ATTLIST value class CDATA HIMPLIED id ID #IMPLIED Source IDREF HIMPLIEDs This allows a “property” with a “name to be assigned a “value.’ A corresponding XML document may then be cre ated by the requesting clientthat contains the followingtext: <property name="city'> <value id=ID 3'>San Francisco-/valued </propertyd <property name="country'> <value id=ID 4>USA</valued </propertyd When these definitions and this text are combined with the previously-described XML-encoded request, the combined XML text could, for example, cause a service of class “Address' to set a city field and a country field in the device address system variables to San Francisco and USA, respec tively. In one example of the invention where the source code correspondingtoaserviceisprovidedasJavaclasses,service launcher 404 includes a Java Virtual Machine (JVM) that is ported to the device 104 and operates as a taskon the device CPU underan operating system such as VxWorks. The JVM receives the byte code corresponding to the Java class from storage 308 and instantiates an object corresponding to the service using a no arguments constructor. Alternatively, ser vice launcher 404 identifies an already-instantiated object corresponding to the service using an “id' parameter or the like. Further, duringorbeforeinstantiatingtheobject, service engine404may detectthatcertain otherclassfilesareneeded and operate to download oraccess them as well. Once instantiated, serviceengine404 setspropertiesin the object usingany parameters also provided in the XML docu ment and parsed out by parser 402. For example, for each property “name' there may bea corresponding “set method (e.g. for the “city’ property, there is a “setCity' method), 10 15 25 30 35 40 45 50 55 60 65 8 which method the serviceengine 404 calls using theJVM to set the property to the “value' parsed from the XML docu ment. Accordingto an aspectoftheinvention, all services do not continuallyrunonthedevice104". Rather, individualservices are launched as requested by clients so as to perform func tionality when needed. Moreover, services according to the invention are designed to be executed using a command design parameter so that the service engine 404 need not be aware ofthe internal code used to implement the service. Therefore, all services designed in accordance with the invention include an “operate' method which serves as the command design parameter. In the example ofthe invention whereservicesareimplementedusingtheJavaprogramming language, this can be done by requiring all services to be based on, or to “implement a standard interface class. For example,each serviceclass mayimplementaninterfaceclass defined as: public interface Operation public Object operate(); } Each service class thus provides its own implementation of the“operate' methodoftheOperation interface.Afterinstan tiating the service class (perhaps also after “setting various properties of the service object using parameters from the parsed document), service launcher 404 calls this specific “operate' method. Accordingly, service launcher 404 can cause various typesofservicestobeperformed without need ing to know their implementation. This is akin to puttingthe code needed to process the requested service in the request itself. Device APIs 406 includes functionality to interact with device hardware and software 306 to perform the requested serviceandto receiveany responses from thedevice's device hardware and software. For example, where a service requests a network parameter of the device such as the device's name, the device APIs 406 will interact with the device hardware and Software to retrieve the name (e.g. a string) from the device's system variables (e.g. MIB) and provideit to response retriever408,alongwithan identifierof the service that requested the parameter. It should be appreciated that theactual implementation of device APIs 406 depends on the code used to implement services 308,as well as the device hardwareand software. In one exampleoftheinvention,all services 308 use a common code language such as C/C++. In Such an example, device APIs406comprisesAPIsthatprovideacommoninterfacefor all Such services to the existing code running on the device 104".Accordingly,services308can bedesignedtoexecuteon various platforms, with a known set of APIs providing a common interfaceto the services, while providing a variable interfacewiththeexistingcode,dependingonthedevice.The designandimplementationofsuchAPIsarewithintheskillof those in the art given the existing code, the device operating system and the design ofservices 308. In another example, device APIs 406 communicate with existing conventional applications of network device 104 through a loopback address ofthe device. For example, the service requested by the received XIVIL document may request access to network parameters ofthe device. Specifi cally, the requested service launched by the service engine canaccessthenetworkparametersofthedevicebyspecifying the loopback address, which can then access the parameters through a networkprotocol stack such as an SNMP stack. It should be apparent that theabove two examples are not necessarily mutually exclusive. Further, other example
- 10. US 8,782,230 B1 9 implementations ofdeviceAPIs 406 arepossible. Moreover, it shouldbeapparentthat some services 308 need not require APIs to fully operate. Response retriever 408 keeps track of the services that require responses fromthedevicehardware andSoftwareand initiates response messages to the requesting client when responses are received. It receives from servicelauncher404 identifiers ofthe services thathave been launched, as well as handles to the XML encoded request thatcaused the service to be launched. When responses are received from device APIs 406, they arepreferably received alongwith theidenti fierofthe service. Response retriever 408 can then correlate the response to the XML encoded request to whom the response belongs and forward the response to response for matter 410 along with the handle to the XML encoded request. Response formatter 410 formats response messages to be sent back to the requesting client. It receives from response retriever408 a response along with an identifierofthe XML encoded request, formats a response message for transmis sion back to the requesting client, and forwards the response message to the network data transfer service 302. Network data transfer service 302 can then send the message back to therequestingclientbyusingthehandleoftheXMLencoded request to retrieve the header information contained in the packets carrying the XML encoded request. In one example oftheinvention, responsesarealso XMLencodeddocuments that will instantiate a response object on the client. In this example, responseformatter410 mayalso access DTDs such as DTD 202 for formattinga response. However, itshouldbe apparent that many other variations offormatting a response otherthan using XML documents are possible. It should be furtherapparent that there are many possible ways ofimplementing response retriever 408 and response formatter 410, and that they may be omitted altogether. For example, response retriever 408 and/or response formatter 410maybepartiallyorfullyimplementedbyeitherorboth of Services 308 and device APIs 406. FIG. 5 is an architectural view ofan example ofnetwork device 104' in accordance with the principles ofthe present invention. Asshowninthisexample,interaction withthedevicehard ware 514 (e.g. Switch fabric, ports, memory, etc.) is per formed through the device operating system 512 (e.g. VxWorks). The device code (e.g. routing software, etc.) 502 interacts with the device operating system 512. Application programming interfaces (API's) 504 (e.g. Java, C/C++, etc.) interact directly with the device hardware 514 and/or via device operating system 512. API's 504 may furtherinteract with device hardware and operating system through device drivers (notshown). JavaVirtual Machine (JVM)508prefer ably includes all functionality provided by a conventional JVM and is ported to the device 104 and operating system 512.OpletRuntimeEnvironmentTM(ORE)506interactswith the JVM to coordinate the downloading, management and execution ofservices 308. Service engine 304 interacts with ORE 506 for execution ofservices 308. Service engine 304 and transfer service 302, during operation, may also interact withAPI's 504, which furtherinteract with devicecode502. FIG. 6 illustrates anexample implementationofa network device 104 having the architecture illustrated in FIG. 5. Asshown, networkdevice104'includesaCPU 602,Switch fabric 604, storage608, networkport610and memory 612all communicatingviaabus 614. Switch fabric 604furthercom municates with switch ports 606. Storage 608 can comprise memory for storing program and device data. Network port 610canprovidealoopbackaddressforaccessby servicesand 10 15 25 30 35 40 45 50 55 60 65 10 other network management applications as described above. Memory 612 includes code for execution by CPU 602. It should be apparent that components corresponding to CPU 602, switch fabric 604, switch ports 606, storage 608, networkport 610, memory 612 andbus 614 arealso provided inaconventional networkdevice 104.Accordingly,as should be further apparent from FIG. 6, adapting a conventional network device 104 in accordancewith the invention merely requiresupdatingmemory 612toincludeexecutableSoftware corresponding to the above-described functionality of the invention. FIG. 7 illustrates an example of a process by which an XML encoded request receivedbythe network device 104' is fulfilled in accordance with the present invention. As shown in FIG. 7, when interaction with the network device 104' is desired, the client computer 100" encodes the request by constructing an XML encoded document corre spondingto the requestand inaccordance with acorrespond ingDTD.ThisXMLdocumentissentacross thenetwork102 usingastandardnetworkprotocolsuchasHTTPand received by networkdevice 104" (blockS702).TheXML documentis received by the networkdata transferservice 302 runningon the network device 104 and provided to the service engine 304.Theserviceengine304 parses theXML document using the corresponding DTD identified in the document (block S704). The parsed document corresponds to one ofthe ser vices provided or retrieved for local access in storage 308. Accordingly, service engine 304 instantiates a copy (oriden tifies an already-instantiated copy) of the service with the properties specified in in the parsed document (block S706). The instantiated service is then launched for execution by invokingthe“operate” methodofthe serviceorsimilarcom mand design parameter (block S708). The requested service may require interaction with the device software and hard ware for execution, as indicated in block S710. Ifa response message back to the requesting client 100' is required by the service (determined in block S712), the response from the device hardware and/or software is retrieved (block S714), and a response message is formatted and forwarded to net workdata transfer service 302 fortransmission back to client 100' (block S716). Although the present invention has been particularly described with reference to the preferred embodiments, it should be readilyapparentto those ofordinary skill in the art thatchangesandmodifications intheformanddetails maybe made without departing from the spirit and scope of the invention. ItisintendedthattheappendedclaimsincludeSuch changes and modifications. What is claimed is: 1. A networkdevice forlocally performingaservice, com prising: a parser for receiving a service request from a requesting client, the service request being in a first format and including a markup language document and a request identifier, forretrievingadocumenttype definitioniden tifiedbythemarkuplanguagedocument,andforextract ing parameter values from and generating events for eachtaginthemarkuplanguagedocumentdefinedinthe documenttypedefinition,wherein the markup language document and document type definition specify a requested service using class, Source, and identifier parametervalues,whereintheidentifierparametervalue indicates the document type definition and wherein the class parameter value indicates a service class; a service launcher for receiving the parameter values and events from the parser, determining whether an object corresponding to the requested servicehas already been
- 11. US 8,782,230 B1 11 instantiated, receiving the service class from storage, and, in response to determining that the requested Ser Vice has not already been instantiated, instantiating an object correspondingto the servicebasedon the service class, and for calling an operate method ofthe instanti atedobject to launch the requested service, wherein the operate methodisalso implementedby each ofaplural ity ofother service classes; a response retriever for keeping track of services that require responses, receiving at least one response, and forcorrelatingtheatleastoneresponsetotherequesting client; and aresponse formatterforreceivingtheatleastone response from the response retriever and formatting a response messagebasedon the atleast oneresponsefortransmis sionbackto the requestingclient, the response message being ina second format,differentfrom thefirstformat. 2. The network device according to claim 1, wherein the requested service comprises an HTTP server. 3. The network device according to claim 1, wherein the markup language comprises XML. 4. The network device according to claim 3, wherein the document type definition comprises an XML DTD. 5. The network device according to claim 1, wherein the service launcher identifies the byte code for the requested service from a plurality of classes responsive to the class parameter value. 6. The network device according to claim 1, wherein the requestedserviceconfiguresapacketforwardingarchitecture in the network device to filter network traffic. 7. The network device according to claim 6, wherein the packet forwarding architecture comprises a packet forward ing Switch fabric. 8. The network device according to claim 7, wherein the requested service causes changes in how packets are for warded through the packet forwarding switch fabric. 9. The network device according to claim 7, wherein the requested service monitors performance indicators of how packets are forwarded through the packet forwarding Switch fabric. 10. The network device according to claim 1, wherein the requested service accesses a MIB on the network device. 11. A method forcausing a network device to locally per form a service, comprising: receiving, by a parser from a requesting client, a service request being in a first format and including a markup language document and a request identifier, retrieving, by the parser, a document type definition iden tified by the markup language document; extracting, by the parser, parameter values from and gen eratingeventsforeachtagin the markup languagedocu ment defined in the document type definition, wherein the markuplanguagedocumentand documenttype defi nition specify a requested service using class, source, and identifier parameter values, wherein the identifier parameter value indicates the document type definition andwhereintheclassparametervalueindicatesaservice class; receiving,byaservicelauncherfrom theparser,parameter values and events; determining, by the service launcher, whether an object corresponding to the requested servicehas already been instantiated; receiving,bytheservicelauncherfrom storage, theservice class; 10 15 25 30 35 40 45 50 55 60 65 12 instantiating, by the service launcher in response to deter mining that the requested service has not already been instantiated, an object corresponding to the service based on the service class; calling, by the service launcher, an operate method ofthe instantiated object to launch the requested service, whereintheoperate methodisalsoimplementedbyeach ofa plurality ofother service classes; keeping track, by a response retriever, of Services that require responses; receiving, by the response retriever, at least one response; correlating, by the response retriever, the at least one response to the requesting client; receiving,byaresponseformatter,theatleastoneresponse from the response retriever; and formatting, by the response formatter, a response message basedonthe atleastoneresponse,fortransmissionback totherequestingclient, the response messagebeing ina second format, different from the first format. 12.The methodofclaim 11, wherein the requestedservice comprises an HTTP server. 13.The methodofclaim 11, wherein the markup language comprises XML. 14. The method ofclaim 13, wherein the document type definition comprises an XML DTD. 15. The method ofclaim 11, further comprising identify ing, by the service launcher, the byte code for the requested service from a plurality of classes responsive to the class parameter value. 16.The methodofclaim 11, whereintherequestedservice configures a packet forwarding architecture in the network device to filter network traffic. 17.Themethodofclaim 16,whereinthepacketforwarding architecture comprises a packet forwarding Switch fabric. 18.The methodofclaim 17, wherein the requestedservice causes changes in how packets are forwarded through the packet forwarding switch fabric. 19.The methodofclaim 17, wherein the requestedservice monitors performance indicators of how packets are for warded through the packet forwarding switch fabric. 20.The methodofclaim 11, wherein the requestedservice accesses a MIB on the network device. 21. A network device for locally performing a service, comprising: a parser for receiving a service request from a requesting client, the service request including a markup language documentand a requestidentifier, forretrievinga docu ment type definition identified by the markup language document, andforextractingparametervaluesfromand generating events for each tag in the markup language document defined in the document type definition, wherein the markup language document and document type definition specify a requested service using class, Source, and identifier parameter values, wherein the identifier parameter value indicates the document type definition and wherein the class parameter value indi cates a service class; a service launcher for receiving the parameter values and events from the parser, determining whether an object corresponding to the requested servicehas already been instantiated, receiving the service class from storage, and, in response to determining that the requested Ser vice has not already been instantiated, instantiating an object correspondingto the servicebasedon the service class, and for calling an operate method ofthe instanti
- 12. US 8,782,230 B1 13 atedobject to launch the requested service, wherein the operate methodisalso implementedby each ofaplural ity ofother service classes; a response retriever for keeping track of services that require responses, wherein, fora service requiring mul- 5 tipleresponses,receiving multiple responses fortheser Vice and for correlating the multiple responses to the requesting client; and aresponse formatterforreceivingtheatleastone response from the response retriever and formatting a response 10 messagebasedon the atleast oneresponsefortransmis sion back to the requesting client. k k k k k