Source: https://patents.google.com/patent/US20030204579?oq=5083039
Timestamp: 2018-04-23 16:03:52
Document Index: 464837118

Matched Legal Cases: ['art 14', 'art 15', 'art 14', 'art 14', 'art 14', 'art 14', 'art 14', 'art 4', 'art 14', 'art 14', 'art 14']

US20030204579A1 - Methods and applets for providing and contributing to an it network management service - Google Patents
Methods and applets for providing and contributing to an it network management service Download PDF
US20030204579A1
US20030204579A1 US10132418 US13241802A US2003204579A1 US 20030204579 A1 US20030204579 A1 US 20030204579A1 US 10132418 US10132418 US 10132418 US 13241802 A US13241802 A US 13241802A US 2003204579 A1 US2003204579 A1 US 2003204579A1
US10132418
US7603450B2 (en )
Another standard for, network management is what is called the “Desktop Management Interface” (DMI). It has been defined by the Distributed Management Task Force (DMTF). DMI is a standard framework for managing and tracking components in a desktop personal computer, notebook or server (see http://www.dmtf.org/spec/dmis.html).
An emerging standard for the management of operating systems and applications is the Web-Based Enterprise Management (WBEM). WBEM is a set of management tools using emerging technologies such as CIM and XML. In particular, WBEM is a set of the following technologies: “CIM Schema v 2.2”, “CIM Operations over http”, and “XML encodings for CIM” (see http://www.dmtf.org/wbem.html). CIM stands for Common Information Model and is a data model for describing information for the management of enterprise computing environments. XML stands for Extensible Mark up Language and is a standard which can be used for exchanging messages between different applications (see http://www.w3.org/tr/rec-xml).
Online support services for desktop computers across the Internet boundary are offered by support service providers, such as Support.com, Inc. and Motive Communications, Inc.. A customer has to install and run a special computer program on his desktop computer in order to get the support. The communication with the support provider is carried out via the Internet using HTTP (see e.g. http://www.motive.com/company/press_releases/news_press_verizon.html, press release of Dec. 18, 2001 and “Support for eBusiness Support.com 10 Rules of eSupport”, White Paper-1001 11/2000). These known systems for desktop computer support do not enable a management of networks.
[0018]FIG. 1 shows a high-level architecture diagram of a system for providing a network management service over the Internet, including a user's IT network to be managed;
[0019]FIG. 2 illustrates a first part of the processing of an exemplary network management request using the Telnet protocol;
[0020]FIG. 3 illustrates the second part of the processing of the network management request of FIG. 2;
[0021]FIG. 4 illustrates the processing of another exemplary network management request using the SNMP protocol;
[0022]FIG. 5 shows an applet window output generated during the processing of FIG. 4;
[0023]FIG. 6 is a state diagram of an applet;
[0024]FIG. 7 is an example of a report page received as the result of the network management processing illustrated in FIG. 4;
[0025]FIG. 8 is a timing diagram of a network-management-service HTTP session.
[0026]FIG. 1 shows a high-level architecture diagram of a preferred embodiment of a system for providing a network management service, including a user's IT network to be managed. Before proceeding further with the description, however, a few items of the preferred embodiments will be discussed.
The term “mobile code” does not mean that the code actually moves while it is executing. Rather, the code is replicated, communicated to the user in the form of traveling signals over the Internet, and then executed there. An obstacle to the idea of mobile code is the differing representations and the interfaces between a program and the infrastructure across computing platforms. This obstacle is addressed by the Java technology in the form of Java programs called applets. Applets are programs that run inside a web browser. The code for an applet is stored on a web server and downloaded into the browser whenever a web page that contains the applet is accessed (see, for example, C. Horstmann, Computing Concepts with JAVA 2 Essentials, second edition, 1998, pages 139 to 142). Alternatively, but less preferred, it is also possible to keep the applet at the user's site after its first use and to reload the stored code rather than transmitting it each time the user sends a corresponding request. In alternative embodiments, the service provider's web page can enable the user to either download the applet from the service provider and execute it, or, when the required applet is already stored at the user's side, to cause the stored applet to be executed in the user's web browser. Web browser programs with Java applets are able to execute on multiple platforms, such as on PCs, Mackintoshes, UNIX workstations, and special web devices. Although the term “applet” was created in the context of the JAVA programming language, it is herein not used in the limited meaning of a JAVA applet, but rather stands for any mobile code embedded in or referenced by a web page, such that the mobile code is executed in the web browser when the web page is downloaded. For example, the C# programming language by Microsoft also provides such an applet functionality. In the future, there may be further suitable programming languages which enable the definition of applets.
In the preferred embodiments, the analyzer is grouped in two different functional parts, an application logic part and a presentation part. The two parts may be physically assigned to different hosts or only logically to different tasks. In the most preferred embodiments, the application logic part is assigned to an application host, and the presentation part to a presentation host which is the or one of the service provider's web servers. The representation part can be realized by any software system which can actively generate web pages, such as a servlet (using Java Server Pages by Sun Microsystems) or a corresponding Active Server Pages Program (Microsoft). The application logic part on the application host is responsible for the generation of the network management requests and the analysis of the network management results. On the other hand, the presentation part (the servlet) transforms a network management request received from the application logic part in a concrete request with regard to the particular network device to be addressed and the particular network-management-protocol to be used. The network management results received by the servlet are, in turn, translated in a protocol-independent representation and forwarded to the application logic part. Thus, in the preferred embodiments, the communication between the application logic part and the presentation part is carried out on a more abstract level than the communication between the presentation part and the user's applet over the Internet. Preferably, the data exchange between the application logic part and the presentation part is also based on XML. However, due to the different levels of abstraction, the two communication “layers” use different XML Document Type Definitions (DTDs) (see http://www.w3.org/tr/rec-xml) or XML Schemas (see www.w3.org/XML/Schema).
The service provider system 1 comprises a web server host 10 and an application logic host 11. A web server program called “web server” 12 is installed on the web server host 10. The web server 12 receives HTTP requests from users from the Internet 3 and returns corresponding responses to the respective users via the Internet 3. An analyzer application, called “analyzer” 13 has two parts and is shared between the application logic host 11 and the web server host 10: An application logic part 14 is installed on the application logic host 11, and a presentation part 15 which runs as a servlet, implemented by Java Server Pages, within the web server 12 on the web server host 10. The application logic part 14 is responsible for the generation of network management requests and the analysis of network management results. It is implemented as a Java program, although any other (preferably object-oriented) suitable programming language can be used. The communication between the application logic part 14 and the servlet 15 will be explained in detail below. A user interface 16 enables an operator to communicate with the application logic part 14 if network management steps are to be carried out manually or any other manual intervention is required.
[0057]FIGS. 2 and 3 illustrate the processing of an exemplary network management request using the Telnet protocol. In a first step S1, the application logic part 14 generates a network management request and forwards it to the servlet 15 in the form of an XML document, called abstract request document 21. In XML, every start tag, such as <request>, must have a corresponding end tag, such as </request>. Otherwise, a tag must be an empty tag, a tag that has an explicit slash at the end of it, as in <systeminfo/>. In the disclosed embodiments, the start and end tags are used to indicate “metacontent”. Metacontent is information about the contents bracketed between a start and an end tag. For example, the <request> tag indicates that the contents between its start and end tags is a network management request. Likewise, the <command> tag indicates that the content between its start and end tags is a network management command. In contrast, empty tags provide content rather than metacontent. For example, the <systeminfo> tag indicates itself that the network management command to be carried out is “systeminfo”. The systeminfo command is a command by which a network device shall return its system information. The XML document 21 is a logical (or abstract) representation of the systeminfo management command, since it does not specify concrete details required for the actual execution of the command (this will become clear in the next step where these details are added). The set of tags which can be used in the abstract communication between the application logic part 14 and the servlet 15 are defined in an XML DTD or Schema, which is called here an abstract DTD or Schema.
In step S2, the servlet 15 receives the abstract XML request 21 and transforms it in a different, more concrete XML representation, which is called concrete XML document 22. In this transformation process, on the one hand, content is added and, on the other hand, content received from the application logic part 4 is transformed. The added content is, for example, information regarding the management protocol to be used (here: Telnet, indicated by the <http TelnetIn> tag as well as network-device-specific information, indicated by the <LoginInfoIn> tag. The translated content is here the logical systeminfo command which is translated in the corresponding Telnet command “sh version”. The XML DTD or Schema on which the concrete XML request is based, called concrete XML DTD or Schema, is different from the abstract DTD or Schema. On the one hand, it comprises additional metacontent tags, for example the above-mentioned tags indicating protocol-related and device-related contents. On the other hand, tags with the same meaning preferably have a different representation in the two DTDs or Schemas. For example, the <command> tag of the abstract DTD corresponds to the <CommandIn> tag of the concrete DTD. Furthermore, empty tags of the abstract DTD may be transformed in a pair of start and end tags for bracketing specific contents in the concrete representation. For example, the <systeminfo/> tag of the abstract XML document 21 is transformed in the sh version content bracketed between the <CommandLineIn> start and end tags. The concrete XML document 22 is then sent as an HTTP response to the user's gateway computer 4 via the Internet 3.
In step S5, the applet 7 translates the device's Telnet response in an XML document, called concrete XML response 23. The concrete XML response 23 corresponds to the original concrete XML request 22 apart from the following: (i) In order to differentiate input from output instead of the < . . . In> start and end tags, < . . . Out> tags are used; (ii) The response received from the network device 9 is added, it is bracketed between output start and end tags, here named <OutputLine>. Then, the applet 7 sends an HTTP POST request with the concrete XML response 23 in the body of the HTTP POST request to the web server 12 over the Internet 3.
In step S6, the servlet 15 (which is part of the web server 12) transforms the concrete XML response 23 into a logical representation of the system information provided by the network device 9, called abstract XML response 24. The abstract XML response 24 corresponds to the abstract XML request 21, apart from a replacement of the original empty tag, which indicated the network management command, by corresponding metacontent start and end tags bracketing the content of the response to the command. In the example of FIG. 3, the empty tag <systeminfo/> has been replaced by <systeminfo> bracketing Cisco 12.0.7(T) . The servlet 15 forwards the abstract XML response 24 to the application logic part 14 running on the application logic host 11. Finally, the application logic part 14 analyzes the abstract XML response 24 and provides the user with a report (not shown in FIG. 3).
[0063]FIG. 4 illustrates the processing of another exemplary management request based on the SNMP protocol. In FIG. 4 the steps corresponding to steps S1 and S6 of FIGS. 2 and 3 are not shown.
In step T1 (which corresponds to step S2), a concrete XML management request 22′ is sent to the applet 7′. In the example of FIG. 4, the concrete XML request 22′ indicates that the request is to be carried out using the SNMP protocol. Correspondingly, the tags comprised in the concrete XML request 22′ are SNMP-specific, in contrast to the tags of the concrete XML request 22 of FIG. 3 which are Telnet-specific. In particular, the fact that the SNMP protocol shall be used is indicated by the <SnmpoverHttp> tag. The name of the network device and the port number to be addressed as well as the password required to access the network device are bracketed between <HostName>, <Port> and <RoCommunity> start and end tags. The <GetIn> start and end tags indicate that an SNMP GET command shall be carried out with an object identifier (Oid), as specified in the <OidWanted Code= . . . /> tag.
In step T4 (which corresponds to step S5), the applet 7′ translates the SNMP response from the network device 9 in a concrete XML management response 23′. Between an <GetOut> start and end tag the <OidWanted Code . . . > tag is repeated and the returned Oid value is included between <OidValue> start and end tags.
[0069]FIG. 5 shows an applet window 8 output generated during the processing of FIG. 4. The applet window 8 has two panes, a command pane 25 and an output pane 26. In the command pane 25, the network-management-protocol command sent to the network device 9 is displayed. In the output pane 26 the network-management-protocol-response received from the network device 9 is displayed. The display of the management requests and the corresponding responses takes place in “real time” (i.e. simultaneously) with the processing carried out by the applet 7. It enables the user to monitor the network management activities carried out in the user's network.
[0070]FIG. 6 is a state diagram of the applet 7. After having been loaded and initialized, the applet 7 waits in state U1 for a network management request from the analyzer 13. When it receives such a request in the form of an HTTP response to a previous HTTP request, together with a session identifier, it reads the concrete XML request 22 in step U2 so as to arrive in a “request received” state U3. Then, in step U4, the applet 7 sends a network-management-protocol request (e.g. an SNMP request) to the network device 9. In state U5, the applet 7 waits for a network-management-protocol response (e.g. SNMP) response from the network device 9. Upon receipt of the response from the device 9, the applet 7 generates in step U6 the concrete XML response 23 so as to arrive in a “XML response generated” state, named U7. Then, in step U8, the applet 7 sends the concrete XML response 23 to the web server 12 as an HTTP POST request. Together with the HTTP POST request, it also returns the session identifier (ID). Then, the applet 8 arrives again in the waiting state U1, where it waits for another request from the analyzer 13.
[0072]FIG. 7 shows an example of such a result page displayed in the user's web browser 6 after the network management processing illustrated in FIGS. 4 and 5 has been performed. In this exemplary result page, it is indicated that the IOS version, which has been found in the processing according to the examples of FIGS. 4 and 5 is “no general deployment release”, and that the general deployment release version is another version (“IOS Version 11.3, Release 11”). Thus, as a result of this exemplary network management service, it has been found that the user uses a “wrong” IOS version, and the user is informed about that: As a next step, the user could, for example, have the correct IOS version installed.
[0073]FIG. 8 is a timing diagram of a network-management-service HTTP session. The provider's server 12 with the analyzer 13, the user's browser 6 with the applet 7 and the user's network device 9 are drafted on the left-hand side, in the middle and on the right-hand side of FIG. 8, respectively. The communication within the analyzer 13, i.e. between the servlet 15 and the application logic part 14 is not represented in FIG. 8 for simplicity.
1. A method for providing a network management service for a user's IT network by a network management service provider over the Internet, comprising:
sending mobile code to the user via the Internet, said mobile code, when running at the user's side, acts as a network management gateway between the user's network and the service provider connectable to the user's network via the Internet;
sending at least one request for the execution of a network management step to the network management gateway at the user's side via the Internet, whereupon the network management step is carried out in the user's network;
receiving result data obtained in the network management step from the network management gateway via the Internet.
2. The method of claim 1, wherein the mobile code is an applet for running in a user's web browser.
3. The method of claim 2, wherein, when the user sends a corresponding web request to the service provider, the service provider returns a web response including the applet or a reference to the applet to be loaded in the user's web browser.
4. The method of claim 2, wherein, when the user sends a corresponding web request to the service provider, the service provider returns a web response which enables the user to either fetch and load the applet or, when the applet is already stored at the user's side, to cause the stored applet to be loaded in the user's web browser.
5. The method of claim 1, wherein the request for the execution of a network management step is sent to the network management gateway at the user's side as a web response to a corresponding previous web request from the network management gateway.
6. The method of claim 5, wherein the web response includes the request for the execution of a network management step in the form of an encapsulated network-management-protocol command.
7. The method of claim 6, wherein the network-management-protocol command is one of an SNMP, Telnet, DMI and WBEM command.
8. The method of claim 6, wherein the encapsulated network-management-protocol command is comprised in an XML document contained in or referenced by the web response.
9. The method of claim 6, wherein the network management gateway is programmed for decapsulating the received network-management-protocol command and executing it in the user's IT network.
10. The method of claim 1, wherein the network management gateway is programmed such that, when it receives result data of the execution of the network management step in the user's IT network, it sends them to the service provider in response to the execution request.
11. The method of claim 10, wherein the result data are sent to the service provider contained in a web request.
12. The method of claim 10, wherein the result data are analyzed by the service provider and a report comprising results of the analysis is provided to the user.
13. The method of claim 12, wherein the report is provided by a web response comprising a report document or a reference to a report document.
16. The method of claim 15, wherein the communication between the application-logic part and the presentation part is performed on a more abstract level than the communication between the presentation part and the network management gateway.
17. The method of claim 1, wherein all data sent from the user to the service provider or from the service provider to the user have to pass a firewall gateway between the user's IT network and the Internet.
18. A method for contributing to a network management service for a user's IT network at a user's side, said management service being provided by a network management service provider over the Internet, comprising:
receiving mobile code via the Internet, said mobile code, when running at the user's side, acts as a network management gateway between the user's network and the service provider connectable to the user's network via the Internet;
receiving at least one request for a network management step from the service provider via the Internet and executing the request by the network management gateway;
returning result data obtained in the network management step to the service provider via the Internet.
19. An applet including program code, which when executed in a user's Internet browser, acts as a network management gateway between a user's network and a network-management service provider;
said applet, when receiving a request for a network management step from the service provider via the Internet, executes the request in the user's network and returns result data obtained in the execution of the network management step to the service provider via the Internet.
20. A method for providing a network management service for a user's IT network by a network management service provider over the Internet, comprising:
sending at least one network management command in an encapsulated form to the user's side over the Internet for decapsulation into a network-management-protocol command at the user's side and execution in the user's IT network;
21. The method of claim 20, wherein mobile code is sent to the user via the Internet before or simultaneously with the sending of at least one network management command, said mobile code, when running at the user's site performs the decapsulation and execution of the network management command and sends the result data to the service provider.
22. The method of claim 21, wherein the mobile code is an applet for running in a user's web browser.
23. The method of claim 22, wherein, when the user sends a corresponding web request to the service provider, the service provider returns a web response including the applet or a reference to the applet to be loaded in the user's web browser.
24. The method of claim 23, wherein, when the user sends an corresponding web request to the service provider, the service provider returns a web response which enables the user to either download and execute the applet or, when the applet is already stored at the user's side, to cause the stored applet to be executed in the user's web browser.
25. The method of claim 20, wherein the network management command is sent to the user as a web response to a corresponding previous web request from the user.
26. The method of claim 20, wherein the network-management-protocol command is one of an SNMP, Telnet, DMI and WBEM command.
27. The method of claim 20, wherein the encapsulated network-management-protocol command is comprised in an XML document contained in or referenced by the web response.
28. The method of claim 21, wherein the result data is sent to the service provider contained in a web request.
29. The method of claim 20, wherein the result data is analyzed by the service provider and a report comprising results of the analysis is provided to the user.
30. The method of claim 29, wherein the report is provided by a web response comprising a report document or a reference to a report document.
31. The method of claim 20, wherein an operator executes at least one network management step in the user's network from the service provider's side by sending at least one network management command in an encapsulated form to the user's side.
32. The method of claim 20, wherein an application for carrying out the network management service at the service provider's side is divided in at least two parts, an application-logic part and a presentation part, wherein the application-logic part controls the network management service provided and the presentation part acts as an interface between the application-logic part and the user.
33. The method of claim 32, wherein the communication between the application-logic part and the presentation part is performed on a more abstract level than the communication between the presentation part and the user.
34. The method of claim 20, wherein all data sent from the user to the service provider or from the service provider to the user have to pass a firewall gateway between the user's IT network and the Internet.
35. A method for contributing to a network management service for a user's IT network at a user's side, said management service being provided by a network management service provider over the Internet, comprising:
decapsulating the command and thereby obtaining a corresponding network-management-protocol command;
executing the network-management-protocol command in the user's IT network;
36. An applet including program code, when executed in a user's Internet browser, for carrying out a method for contributing to a network management service for a user's IT network, said management service being provided by a network management service provider over the Internet, comprising:
decapsulating the network management command received in an encapsulated form from the service provider over the Internet and thereby obtaining a corresponding network-management-protocol command;
US10132418 2002-04-26 2002-04-26 Methods and applets for providing and contributing to an IT network management service Active 2026-03-05 US7603450B2 (en)
US10132418 US7603450B2 (en) 2002-04-26 2002-04-26 Methods and applets for providing and contributing to an IT network management service
US20030204579A1 true true US20030204579A1 (en) 2003-10-30
US7603450B2 US7603450B2 (en) 2009-10-13
ID=29248759
US10132418 Active 2026-03-05 US7603450B2 (en) 2002-04-26 2002-04-26 Methods and applets for providing and contributing to an IT network management service
US (1) US7603450B2 (en)
EP2573998A3 (en) * 2011-09-21 2013-08-28 The Boeing Company Method and devices for smart agent download
US9401897B2 (en) * 2002-07-24 2016-07-26 The Nielsen Company (Us), Llc. System and method for monitoring secure data on a network
US20150019861A1 (en) * 2002-07-24 2015-01-15 The Nielsen Company (Us), Llc. System and Method for Monitoring Secure Data on a Network
US20150170174A1 (en) * 2010-09-30 2015-06-18 The Nielsen Company (Us), Llc Methods and apparatus to measure mobile broadband market share
US7603450B2 (en) 2009-10-13 grant
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LUTZ, MANFRED;REEL/FRAME:012847/0538