There are beneficial network applications that are less effective because of rudimentary user interfaces. Furthermore, there is an advantage to leveraging existing user interfaces for use with new applications rather then spend valuable engineering resources creating new ones. An example of a network application that benefits from leveraging an existing user interface is a CNS Performance Engine network application by Cisco Systems, Inc. used in conjunction with Cisco routers. With specific reference to
While the network application 100 provides valuable information and functions, use of the network application 100 is limited because of the less than intuitive user interface for configuration and status reporting of the devices 100. Submission and retrieval of text based XML information to perform configuration and to read device measurements and status must be done using a specific format and is, therefore, prone to error. There is a need, therefore, for an improved user interface for the network application. It is further beneficial to leverage an existing user interface for use with the network application.
U.S. Pat. No. 6,336,138 B1 to Caswell et al. entitled “Template Driven Approach For Generating Models on Network Services” filed Aug. 25, 1998 (herein “the Caswell patent”) and U.S. Pat. No. 6,182,136 B1 to Ramanathan et al. entitled “Automated Service Elements Discovery Using Core Service Specific Discovery Templates” filed Sep. 8, 1998 (herein “the Ramanathan patent”) disclose a service model and discovery methods for use in network applications that has an intuitive user interface for network applications. In addition, the information available from the Cisco routers is useful in the service model application. The process of modeling a service within a network environment includes forming a service model template that is not specific to the network environment, but identifies anticipated network elements and network services that cooperate to enable the selected service. The service model, however, is implemented in service model specific language and configuration methods.
It is desirable, therefore, for the user interface used in the template driven service model disclosed in the patents to Caswell and Ramanathan to be adaptable to other network applications. It is further desirable to integrate other network applications into the service model for use of information from the network application within the service model.
An understanding of the present invention can be gained from the following detailed description of the invention, taken in conjunction with the accompanying drawings of which:
With specific reference to
The user interface uses a discovery engine 200 portion of the conventional service model as part of the integration between the service model and the network application 100. The discovery engine 200 performs initialization of the user interface for the network application 100 by requesting a current status of the network application 100 and updating the user interface to reflect the current status. The discovery engine 200 runs on a conventional computer or other processing element that communicates with the network application 100 and reads XML data 202 that is created by the network application 100 in response to the status request. The discovery engine 200 utilizes a portion of the active service model 208, which is a discovery template 352. The discovery template 352 is applicable to the network application 100, is written using conventional SmartFrog syntax, and is consistent with the conventional discovery template format. The discovery template 352 provides information to the discovery engine 200 as to which discovery engine to execute. During the discovery process, the network application 100 returns a subset of the available attributes in an XML format 202 over the network using a proprietary syntax in response to the status request.
With specific reference to
In the present embodiment, the PerfEDisco class 302 is implemented in JAVA. The PerfEDisco class 302 is a utility used by the script file wrapper engine 350 to communicate with the network application 100. The PerfEDisco class 302 sends 402 a status request 306 in the form of an XML string over the TIBCO messaging bus to the network application 100. The network application 100 receives the status request 306 and interprets it as requesting a configuration status update. The network application 100 responds 404 with a responsive XML message 202 that contains text representing the current configuration of the network application 100 and the devices 106 to which the network application 100 communicates. The PerfEDisco class 302 reads 406 the responsive XML message 202 and translates 406 the configuration status data into file based discovery syntax, which in a specific embodiment is a subset of the SmartFrog language. The translation by the PerfEDisco class 302 is performed in conjunction with a component discovery XSLT file 308. The resulting translation is stored as a file based discovery file 204 using a conventional file based discovery format used for file based discovery of network components. The script file wrapper engine 350 recognizes a presence of the file based discovery file 204. The script file wrapper engine 350, which is an extension of the file based discovery engine 300 and uses the same interface, reads and interprets 408 the file based discovery file 204 and uses the file based discovery file 204 in conjunction with the service model templates 210 to generate one or more discovered instances 304. As each discovered instance 304 is generated, it is available to the service model manager 206 for insertion into the active service model 208. As each instance is added, the service model manager 208 processes the next discovered instance 204. When all discovered instances 204 from the file based discovery file 204 are processed by the service model manager 206, the initial network application configuration is available as the active service model 208 to the administrative console 212.
A further adaptation made to the conventional service model as part of the discovery process of the network application status is establishment of a hidden node 218 of a PerfEDiscoNodeImpl class. There is one instance of the PerfEDiscoNodeImpl class 218 in the active service model 208. It is instantiated at start up of the administrative console 212, it is always present and it is unique to the network application 100. The PerfEDiscoNodeImpl class 218 extends a HealthNodeImpl class that is part of the conventional service model. The HealthNodeImpl class is chosen because it propagates node health status through the active service model tree in the conventional service model. Because it is desirable to maintain the propagation characteristic in a context of the network application 100, it is efficient to use the conventionally defined HealthNodeImpl class. The PerfEDiscoNodeImpl class 218 overrides an sfdeploy( ) method as defined in the HealthNodeImpl class with a new method that communicates with the network application 100. Upon start up of the administrative console 212, the service model manager 206 reads a service model store 354 and instantiates all of the nodes found therein to create the active service model 208. Each instantiated node is represented as a HealthNodeImpl instance 356 in the active service model 208.
Prior to system start-up, the current configuration of the service model is stored on external media in a service model store 254. The service model store 354 contains a SmartFrog description of the nodes in the active service model 208. When reading a service model store 354 into the administrative console 212, an sfClass SmartFrog attribute in the service model template 210 is used to determine which JAVA class should be instantiated for every node in the active service model 208. Instantiation of all nodes in the active service model 208 includes instantiation of the PerfEDiscoNodeImpl class 218 hidden node. Within the PerfEDiscoNodeImpl SmartFrog description in the service model store 354, the sfClass SmartFrog attribute is found who's associated value is a dotted JAVA path to the PerfEDiscoNodeImpl class 218. As a result, a PerfEDiscoNodeImpl node 218 is instantiated as a child node of domain node 512 and, while hidden from a user's view in the administrative console user interface 216, can affect all other nodes in the active service model 208. When the PerfEDiscoNodeImpl class is instantiated by the service model manager 206, the service model manager 206 calls an sfDeploy( ) method defined within the PerfEDiscoNodeImpl class 218. Within the sfDeploy( ) method, a new thread is created that is responsible for running the script file wrapper engine 350. The new sfDeploy( ) thread blocks until the administrative console 216 has completely read the entire active service model 208 into memory. At this point, the thread responsible for running the script file wrapper engine 350 is released and the responsive XML file 202 is read from the network application 100.
The sfDeploy( ) method as redefined in the PerfEDiscoNodeImpl class, first establishes a connection to the network application 100. In the specific embodiment where the network application 100 is the Cisco CNS Performance Engine, the established connection is over the TIBCO bus. The active service model 208 is cleared and the PerfEDisco class 302 is instantiated. The PerfEDisco class 302 queries the network application 100 requesting its current status and receives the responsive XML message 202 from the network application 100. In the specific embodiment of the Cisco CNS Performance Engine network application 100, the PerfEDisco class makes the query by sending an appropriate XML message requesting a current configuration status over the TIBCO bus. Similarly, the PerfEDisco class 302 receives the responsive XML message 202 from the CNS Performance Engine network application 100. The PerfEDisco class 302 then uses the responsive XML string message 202 together with the component discovery XSLT file 308—to translate the XML string 202 sent in response to a configuration status query to a format suitable for use by the discovery engine 200. The suitable format is the file based discovery format, which is a subset of the SmartFrog format. The component discovery XSLT file 308 uses an XPath query language available as a library for the JAVA language to define a set of rules for parsing the XML string 202. The XSLT rules identify attributes within the XML string 202 that assists the PerfEDisco class 302 in parsing the XML file 202 and building the SmartFrog equivalent of the XML responsive message 202 from the network application 100. The resulting translation of the responsive XML string 202 is written in a subset of the file based discovery format and stored as the file based discovery file 204. The script file wrapper engine 350 reads the file based discovery file 204, and with the service model templates 210 creates the one or more discovered instances 304. As each discovered instance 304 is created, the service model manager 206 accesses the discovered instance 304 and creates one HealthNodeImpl instance 356 for storage in the active service model 208 as one or more nodes that describe the related network application component. The service model manager 206 process each discovered instance 304 until all of them are part of the active service model 208 as HealthNodeImpl instances 356.
With reference to
The administrative console 212 runs on a JAVA Virtual Machine. It reads the service model template 210 stored in the SmartFrog syntax for the network application 100 and provides to a user, a display of configurable components of the network application 100 in a hierarchical representation as defined in the service model templates 210. With specific reference to
The visible HealthNodeImpl instances 356 of the active service model 208 are represented to the user as one or more related nodes in the services pane 504 of the administrative console 502. A node is instantiated in the services pane 504 under one or more container nodes 510. The container nodes 510 are also defined in the services model template 210. They comprise node classes into which a specific instance of a node from the templates pane 502 may be created. In this way, the container nodes control where certain types of nodes may be placed in the active service model hierarchy and provide an error message if a user attempts to place a node of an improper type in one of the container nodes 510. The container nodes 510 define certain functions that are performed for that particular class of node. A user configures a network application component by instantiating a node in the services pane 504. From a user point of view, node instantiation is performed using a conventional “drag&drop” type of operation from the templates pane 502 to the services pane 504.
With specific reference to
The administrative console 212 defines an SMExporter interface. The SMExporter interface defines the following methods for use within the service model manager 206:
The SMExporter interface is used by the service model manager 206 to alert registered SMExporter instances of different events, including node add and node remove events. Updating a node in the active service model 208 involves a node remove event followed by a node add event. Advantageously, in a specific embodiment, the SMExporter interface already defined in the conventional service model is sufficient for add and remove events as well as an update event. A class called CNSExporter, which is not part of the conventional service model, implements the SMExporter interface, which is part of the conventional service model. The CNSExporter class specifically defines the actions taken when any of the calls defined in the SMExporter interface are invoked for the CNSExporter class. The CNSExporter class is defined specifically for the network application 100 and, therefore, provides a hook into the conventional service model that permits use of the service model user interface to a new network application 100. The add( ) and remove( ) methods defined in the CNSExporter class, therefore, contain specific process steps that include writing XML streams using a TIBCO messaging bus with appropriate syntax for configuration of the CNS Performance Engine network application 100. Use of the TIBCO bus is a conventional communication process for communicating with the CNS Performance Engine network application 100. In addition, the CNS Performance Engine network application 100 also responds with an acknowledgment message over the TIBCO bus validating that the configuration request was successful. The add( ) and remove( ) methods are also written to receive the responsive XML stream from the CNS Performance Engine and report back if an error was seen as a result of performance of the add( ) or remove( ) methods.
The handles( ) method is called by the service model manager 206 to determine whether or not the CNSExporter instance is applicable to the HealthNodeImpl instance 356 that generates the requested event. If the handles( ) method reports that the CNSExporter instance is applicable to the HealthNodeImpl instance 356, then the method associated with the event is called. If the handles( ) method reports that the CNSExporter interface is not applicable to the HealthNodeImpl instance 356, then the event is ignored with respect to the CNSExporter.
Within the administrative console 212, there is a SMExporterFactory thread instantiated at start-up and available to the service model manager 206. Within the HealthNodeImpl class, there is an attribute with a value of the class that handles this type of node. The value indicates the JAVA package name and the class name. In the specific example, the JAVA package and class name points to the CNSExporter class. The service model manager 206 calls 605 the SMExporterFactory passing to it, the HealthNodeImpl instance 356. The SMExporterFactory reads the attribute value within the HealthNodeImpl instance 356 and creates a CNSExporter instance based upon the data found in the HealthNodeImpl instance 356. After the SMExporterFactory instantiates 606 the CNSExporter instance the SMExporterFactory sends it to the service model manager 206. The service model manager 206 calls handles( ) on the CNSExporter instance to see if the requested event is applicable to the HealthNodeImpl class and if so, calls add( ) 607 passing the HealthNodeImpl instance 356 as an argument.
With specific reference to
The remove( ) method behaves in a similar manner when a node is deleted from the active service model 208. The difference is in the add( ) and remove( ) methods and the processes defined in the respective methods for the CNSExporter. The handles( ) method is used to determine if the HealthNodeImpl instance 356 is applicable to the requested event. If so, the remove( ) method is called and if not, it is ignored.
In addition to configuring CNS Performance Engine configuration components, the user can also configure CNS Performance Engine data collector components. The data collector components access those CNS Performance Engine functions that collect and report data. As part of the drag&drop instantiation process, the data collector is configured to collect and report data, but a user must choose to activate or deactivate the data collector before data collection is initiated. In a specific embodiment of the CNS Performance Engine network application 100, the activate and deactivate actions are implemented by using the “monitor” and “unmonitor” operations that have interfaces already defined in the conventional service model. The CNSExporter node re-maps the monitor/unmonitor operation for specific application to the CNS Performance Engine network application 100. The monitor/unmonitor operation is available from a right click pop-up menu in the administrative console GUI 216. The monitor/unmonitor operation is supported only on a subset of all defined CNS Performance Engine components that are defined as data collectors. The monitor/unmonitor operation serves to activate or deactivate, respectively, the referenced node in the system. The monitor/unmonitor operation is implemented in an SMTreeListener interface. The SMTreeListener interface defines the following methods:
In the specific embodiment of the CNS Performance Engine, the SMTreeListener interface is also implemented in the CNSExporter class. Accordingly, additional methods are further defined with the CNSExporter class. Specifically, the nodeChanged( ) method is remapped for purposes of the CNSExporter class and is implemented such that when a node is Monitored or Unmonitored an appropriate XML message is created and is sent to the CNS Performance Engine network application 100. For purposes of the CNS Performance Engine, the monitor/unmonitor operation performs a toggle. That is to say that if the nodeChanged( ) method is called, it acts to change the current state of the node and deactivate an active node and activate a deactive node. The SMTreeListener interface is implemented by the CNSExporter class to contain all of the information required to start and stop the CNS Performance Engine application components. The nodeAdded( ), nodeRemoved( ), and guiAttrChange( ) methods are also defined in the SMTreeListner interface, but are not used in the CNSExporter class. In the specific example, this is because SMExporter's add( ) and remove( ) methods are already defined in the SMExporter interface and the other methods that are part of the SMTreeListner interface are not used. Accordingly, for purposes of the CNSExporter class, all methods except the nodeChanged( ) method are defined as an empty implementation.
The teachings thus far disclosed describe an implementation wherein only a single application configures the network application 100. It is possible, however, to have an administrative console 212 communicating with the network application 100 and also to have the conventional XML message based user interface communicating with the same network application simultaneously. Such a scenario creates a synchronization issue where the user interface may not accurately reflect the state of the network application. The teachings that follow are for adaptations to the service model when the network application 100 may be configured by more that one external application, but the user interface can still accurately reflect a configured state of the network application.
Conventionally, the CNS Performance Engine network application 100 does not provide notice that an update to the network application 100 is made. If the conventional GUI and the service model GUI according to the present teachings are operating simultaneously, it is possible that the services pane portion 502 of the administrative console GUI 216 does not accurately reflect a configuration status of the network application 100 at all times. It is desirable, to provide a user interface to the network application 100 that is able to accurately reflect a status of the network application at all times without modification to the network application 100, and so a further adaptation of the service model is appropriate. It is only appropriate, however, to provide such a capability when the network application 100 can be configured through a means other than a single administrative console 212.
It is possible to update the administrative console with the current network application 100 status using a “Begin Discovery . . . ” command. “Begin Discovery . . . ” is available in the conventional service model interface as a right click from the services pane of the administrative console GUI 216 and may be applied to either a CNSPerfE-Configuration node 514 or a CNSPerfE-Datacollections node 516 within the active service model.
The children nodes of the CNSPerfE-Configuration node 514 represent nodes that configure the network application 100, but do not report data from the network application 100. A “Begin Discovery . . . ” event on a CNSPerfE-Configuration node 514, therefore, operates only to update a configuration status in the event that another tool with access to the network application 100 has changed the configuration of network application 100 and the user desires that the services pane 502 of the administrative console GUI 216 accurately reflects the current status of the network application 100. The process for updating the active service model is similar in function to the initialization of the administrative console 212 at start up. When a user initiates “Begin Discovery . . . ” on the CNSPerfE-Configuration node 514, the PerfEDisco class 302 is called on that node and thereby, operates on all children nodes of the CNSPerfE-Configuration node 514. The PerfEDisco class 302 sends an XML message 306 requesting the configuration status from the network application and receives the responsive XML file 202 containing the requested information. Using the component discovery XSLT file 308 and the service model templates 210, the PerfEDisco class 302 parses the responsive XML message 202 and creates the file based discovery file 204. The script file wrapper engine 350 reads the file based discovery file 204 and creates one or more discovered instances 304. The service model manager 206 receives the discovered instances 304 and updates the active service model 208 with a new HealthNodeImpl instances 356. At this point, the active service model 208 is accurate and the administrative console GUI 216 accurately reflects the network application configuration as of the time of the “Begin Discovery . . . ” event.
The CNSPerfE-Configuration node 514 represents a network application configuration portion of the active service model 208. All child nodes to the CNSPerfE-Configuration node 514 represent a fixed configuration state for the CNS performance engine network application 100. Accordingly, the “Begin Discovery . . . ” sufficiently updates the configuration nodes so that the administrative console GUI 216 reflects an accurate current status of the network application unless and until something other than the administrative console GUI 216 reconfigures that portion of the CNS Performance Engine network application 100. Selecting “Begin Discovery . . . ” initiates the PerfEDisco class 302 that acts on the node selected. The PerfEDisco class 302 is the same method regardless of how it is instantiated, but the node that initiates the event dictates a unique XSLT file used in the process. In all cases, a result of the PerfEDisco class 302 is a SmartFrog discovered instance 304 that is read by the service model manager 206 to populate the active service model 208 with the current network application configuration. The discovered instance 304, therefore, is no different from the conventional discovered instance 304 except that it is built using information from a network application 100 that is external to the service model environment.
In a specific embodiment of the network application 100, there is a capability to make network measurements. As such, it is desirable for data from the network application 100 to be displayed to the user in a format that is integrated with the user interface of the conventional service model. The configuration of network application components as described herein only configures the network application 100. As such, only the administrative console 212 portion of the conventional service model is adapted for the purposes of integrating an external network application 100. In order to integrate measurements made by the network application 100 into the service model, and with specific reference to
The administrative console 212, DMS 900, one or more agents 902 and operations GUI 904 are separate and independent programs that may or may not run on the same host processor. It is only necessary that each program is able to communicate with the other programs as disclosed herein. If they run on the same host processor, each program may or may not access the same physical storage media. One of ordinary skill in the art appreciates that even if the storage media is the same, the data store is kept as a separate entity in different files or different portions of files.
A data collection portion of the service model includes additional functions for retrieval and display of measurements made by the network application 100. Functions that are part of the network application that make measurements and report the data are referred to as “collectors” 101. With specific reference to
When the DataCollections node 516 is fully populated with all of the discovered started collector instances, the user deploys 1014 the collectors instances to the agent(s) 902 by selecting “Commit Changes” from the File menu in the administrative console 212. When the “Commit Changes” selection is made, the service model manager 206 operates in conjunction with the DMS service model manager 906 to update 1016 the DMS active service model 908, so that all nodes, including the new collector instances represented in the active service model 208, are instantiated in the DMS active service model 908. Upon identification of updates in the DMS active service model 908, the DMS service model manager 906 then creates new repositories in the solid database 910 that are able to receive data for each collector instance identified in the DMS active service model 908. The DMS 900, then deploys 1018 CollectorTest instances for each collector instance represented in the DMS active service model 908 to an appropriate agent 902. When it deploys each CollectorTest instance, the DMS 900 accesses the dms active eservice model 908 and sends a CollectorTest TestType and CollectorTest target for each collector instance to the agent 902. The agent(s) 902 uses the CollectorTest TestTypeattribute and CollectorTest target to look up whichTestto create. The agent(s) 902 references an agent copy of the active service model templates 920 and retrieves the test description associated with the CollectorTest TestType. The agent(s) 902 examines the CollectorTest description and accesses an sfClass attribute. In the specific example of the collector instance, the sfClass attribute indicates to the agent(s) 902 that a new CollectorTest class 924 is to be instantiated. If the collector instance target already exists, no action is taken. If the collector instance target does not exist, a new CollectorTest is instantiated for that collector instance target.
A BaseTest class is part of the conventional service model within each agent 902. The CollectorTest class extends the BaseTest class and is used for purposes of creating measurements from the data that is generated by the collectors 101 running on the network application 100. Base functionality of the CollectorTest class is maintenance of information as to where the collector data is stored, initiation of a BaseDataProcessor class, and delivery of test results to the DMS 900, specifically the solid database 910. All test classes within the agent(s) 902 that are not CollectorTests also extend the BaseTest class, but are different from the CollectorTest class. Accordingly, in a specific embodiment, only collectors 101 in the network application 100 have corresponding instances of the CollectorTest class in the agent(s) 902.
Within the CollectorTest instance Target is a reference to a BaseDataProcessor variable that refers to the instance of the BaseDataProcessor class. The BaseDataProcessor class includes intelligence as to how to create measurements from data returned by a specific type of collector 101 that is available within the network application 100. It is the BaseDataProcessor variable, therefore, that indicates the specific type of collector data that the CollectorTest instance can process. Examples of available BaseDataProcessors comprise measurements of jitter, udp echo, MIB, and icmp echo. The agent(s) 902 schedules the new instance of the CollectorTest 924 when the test begins. The CollectorTEst 924 instance accesses the CollectorTest Target and identifies an fhCollector Name attribute value. The CollectorTest 924 instance instantiates an instance of the class specified by the fhCollector Name and assigns it to the BaseDataProcessor variable contained within the CollectorTest 924 instance. The BaseDataProcessor extracts the appropriate data from a file on agent media store 922 and returns the data to the CollectorTest 924 instance in a format that is understood by the dms 900.
As a started collector 101 generate data, The Collector 101 it delivers the data directly to the agent media store 922 using file transfer protocol (“ftp”). The CollectorTest instance 924 on the agent 902 contains information that identifies where the new data is stored on the agent local disk 922 for its respective collector 101. The CollectorTest instance formats measurement data for the dms 900 from the new data located on the agent local disk 922, using the BaseDataProcessor that was specified in the CollectorTest target. The formatted measurement data is then sent 1022 to the dms 900. The dms 900 stores 1024 the measurement data in the solid database on the dms local disk 910. All measurements reported by the collectors 101 through the one or more agent(s) are, therefore, collected within the solid database on the dms local disk 910. To view the measurement data 1026, a user initiates the operations GUI 904. The operations GUI 904 first retrieves the measurement data stored on the dms local disk 910, formats it for presentation, and then reports it to the user.
In one embodiment, the active service model 208 is updated only when the user initiates the “Begin Discovery . . . ” command. In another embodiment, the PerfEDisco class 302 may be scheduled to occur at regular intervals that may be established by a user. The selection of when and how the PerfEDisco class 302 is initiated may also be available as a selectable option within the network application 100 or as part of the network application configuration use interface.
Embodiments of a method according to the present teachings are herein disclosed for purposes of illustration and are not meant to limit that which is claimed. Many alternatives not specifically illustrated will occur to one of ordinary skill in the art with benefit of the present teachings. Those many alternatives remain within the scope of the appended claims. As a specific example, when receiving the responsive XML string 202 from the network application and rather than using the XSLT files, the XML data may be parsed with JAVA classes specifically implemented to translate the XML data to the file based discovery file.