Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
6769124
Schoening , ; et al.
July 27, 2004
Title
Persistent storage of information objects
Abstract
A method and apparatus for persistently storing information objects in a secondary store is provided. Each object to be stored persistently is made a subclass of a persistent object class. The persistent object declares metadata that defines parameters of a table in the secondary store in which instances of the object are stored, and external requirements of the object. When a persistent object inherits attributes from one or more parent object classes, instances of each parent class are represented in separate tables. When a persistent object is read or written by an application program, methods in the persistent object class automatically retrieve or store information for each field of the persistent object by recursively calling a read method or a write method for each class from which the persistent object inherits, and the object's own class. The read method and write methods automatically create and submit commands to the secondary store.
Inventors:
Schoening; Charles B.
(Guttenberg,
NJ
)
, Smith, Jr.; Richard J.
(Danville,
CA
)
, Schleimer; Stephen I.
(San Jose,
CA
)
Assignee:
Cisco Technology, Inc.
(San Jose,
CA
)
Appl. No.:
121009
Filed:
July 22, 1998
Current U.S. Class:
719/316
707/100
707/102
707/103R
711/105
711/111
711/112
Current International Class:
G06F 9/46 (20060101)
Field of Search:
709/100-108,201-253,310-332 707/4,100-103Z 711/100-146
U.S. Patent Documents
5161225
November 1992
Abraham et al.
5247669
September 1993
Abraham et al.
5572673
November 1996
Shurts
5615362
March 1997
Jensen et al.
5627979
May 1997
Chang et al.
5706506
January 1998
Jensen et al.
5870753
February 1999
Chang et al.
5878411
March 1999
Burroughs et al.
5937409
August 1999
Wetherbee
6076090
June 2000
Burroughs et al.
6122639
September 2000
Babu et al.
Other References
Persistence Software, "Home Page", persistence.com/content.html, "last revision date" Nov. 5, 1998, retrieval dated Nov. 10, 1998. .
Persistence Software, "Products-PowerTier for C++", persistence.com/products/PTcpp.html, "last revision date" Oct. 13, 1998, retrieval date Nov. 10, 1998. .
Persistence Software, "Products-PowerTier for C++_The Persistence PowerTier Server", "last revision date" Aug. 10, 1998, retrieval date Nov. 10, 1998, Persistence.com/Products/pt_ds.html. .
Persistence Software, "Products-PowerTier for C++_The PowerTier Server (A Technical Overview)", persistence.com/products/tech_overview.html, "last revision date" Aug. 17, 1998, retrieval date Nov. 11, 1998. .
Persistence Software, "News-Press Releases" persistence.com/news/releases.html, "last revision date" Oct. 27, 1998, retrieval date Nov. 10, 1998. .
Persistence Software, "News-Press Releases: Persistence Ships First Production Enterprise Javabeans (EJB 1.0) Application Server", persistence.com/news/releases/ejb_0817.html, "last revision date" Sep. 1, 1998, retrieval date Nov. 10, 1998. .
Persistence Software, "News-Press Releases: Persistence Announces One of Industry's First Open Java Application Servers with Full Enterprise JavaBean Support", persistence.com/news/releases/ptejb_0324.html, "last revision date" Aug. 7, 1998, retrieval date Nov. 10, 1998. .
Persistence Software, "Products-White Papers", persistence.com/products/whitepapers.html, "last revision date" Aug. 12, 1998, retrieval date Nov. 10, 1998. .
Rymer John, Persistence Software, "Products-White Papers: Business Process Engines, A New Category of Server Software, Will Burst the Barriers in Distributed Application Performance", persistence.com/products/wp_rymer.html, "last revision date" Aug. 12, 1998, retrieval date Nov. 11, 1998. .
Dick, Kevin, Persistence Software, "Products-White Papers: Sophisticated, Scalable Web Applications: Taming the Beast ", persistence.com/products/wp_white.html, "last revision date" Aug. 12, 1998, retrieval date Nov. 11, 1998. .
Agarwal, Shailesh, Ph.D, et al., Persistence Software, "Products-White Papers: Architecting Object Applications for High Performance with Relational Databases", persistence.com/products/wp_architect.html, "last revision date" Aug. 12, 1998, retrieval date Nov. 10, 1998. .
Sun Microsystems, Java Technologies: Java Product Index, "Java.TM. Software Solutions", http://www.sun.com/java/products/software.jhtml, retrieval date Nov. 10, 1998. .
Java Technologies, "Java Blend.TM.--An Enterprise -Level Development Tool", java.sun.com/products/java-blend/, retrieval date Nov. 10, 1998. .
Java Technologies, "Sun Simplifies Database Programming with Java Blend", java.sun.com/pr/1997/August/pr970821-01.html, retrieval date Nov. 10, 1998. .
Java Technologies, "Java Blend.TM.: Integrating Java.TM. Objects with Enterprise Data", java.sun.com/marketing/collateral/javablend.html, retrieval date Nov. 10, 1998. .
Java Technologies, "Java.TM. Blend.TM.", java.sun.com/marketing/collateral/javablenddata.html, retrieval date Nov. 10, 1998. .
Java Technologies, "Java Technology Preview: Java Blend.TM. Software", java.sun.com/products/java-blend/overview.html/, retrieval date Nov. 10, 1998. .
Java Technologies, "Java Blend.TM.-FAQ", java.sun.com/products/java-blend/java-blendFAQ.html, retrieval date Nov. 10, 1998. .
The Object People, "Bringing Object Technology to Your World", objectpeople.on.ca/, retrieval date Nov. 10, 1998. .
The Object People, "TopLink", objectpeople.on.ca/toplink/index.htm, retrieval date Nov. 10, 1998. .
The Object People, "TopLink for Smalltalk Features", objectpeople.on.ca/toplink/smalltalk/features.htm, retrieval date Nov. 10, 1998. .
The Object People, "TopLink for Smalltalk", objectpeople.on.ca/toplink/smalltalk/smalltalk.htm, retrieval date Nov. 10, 1998. .
The Object People, "TopLink.TM. Version 4.0-A White Paper", 1997, pp. 1-9. .
The Object People, "The Object People News", objectpeople.on.ca/news/toplink50.htm, retrieval date Nov. 10, 1998. .
Keller, Arthur M., et al., "Penguin: Objects for Programs, Relations for Persistence", Jul. 1998. .
Basu, Julie, et al., "Centralized versus Distributed Index Schemes in OODBMS--A Performance Analysis", ADBIS '97, Aug., 1997. .
Wiederhold, Gio, Ph.D., et al., "Integrating Data Into Objects Using Structural Knowledge", Third International Symposium on Command and Control Research and Technology (3ICCRTS), National Defense University, Jun. 1997. .
Basu, Julie, et al., "Performance Evaluation of Centralized and Distributed Index Schemes for a Page Server OODBMS", Technical Note CS-TN-97-55, Stanford University, Computer Science Department, Mar., 1997. .
Agarwal, Shailesh, et al., "Architecting Object Applications for High Performance with Relational Databases", OOPSLA Workshop on Object Database Behavior, Benchmarks, and Performance, Austin, Texas, Oct., 1995. .
Keller, Arthur, M., et al., "Migrating to Object Data Management", OOPSLA Workshop on Legacy Systems and Object Technology, Austin, Texas, Oct., 1995. .
Turner, Paul, et al., "Reflections on Object-Relational Applications", OOPSLA Workshop on Object and Relational Databases, Austin, Texas, Oct., 1995. .
Takahashi, Tetsuya, "Implementation of Object View Query on a Relational Database", Data and Knowledge Systems for Manufacturing and Engineering, Hong Kong, May, 1994. .
Keller, Arthur, M., "A C++ Binding for Penguin: A System for Data Sharing Among Heterogeneous Object Models", Foundations on Data Organization (FODO) 93, Chicago, Oct., 1993. .
Takahashi, Tetsuya, "Querying Heterogeneous Object Views of Relational Database", Int. Symp. on Next Generation Database Systems and Their Applications (NDA) 93, Fukuoka, Japan, Sep., 1993. .
Keller, Arthur, M., "Persistence Software: Bridging Object-Oriented Programming and Relational Databases", SIGMOD, May, 1993. .
Barsalou, Thierry, et al., "Updating Relational Databases Through Object-Based Views", ACM SIGMOD, Denver, CO, May, 1991. .
Sessions, Roger, Table of Contents, Object Persistence: Beyond Object-Oriented Databases, 1996, pp. v-ix. .
Sessions, Roger, "The Interfaces of Persistence", Object Persistence: Beyond Object-Oriented Databases, 1996, pp. 121-145. .
Sessions, Roger, "The Application Developer Perspective", Object Persistence: Beyond Object-Oriented Databases, 1996, pp. 171-202. .
Sessions, Roger, "The Datastore Vendor Perspective", Object Persistence: Beyond Object-Oriented Databases, 1996. pp. 203-233. .
Orfali, Robert, et al., "CORBA Services: Persistence and Object Databases", The Essential Distributed Objects Survival Guide, 1996, pp. 139-164. .
GemStone Systems, Inc., "Product Page", gemstone.com/products/products.sub.- main.html, retrieval date Nov. 10, 1998. .
GemStone Systems, Inc., "GemStone/S Product Page", gemstone.com/products/s/main.html, retrieval date Nov. 10, 1998. .
GemStone Systems, Inc., "Data Sheet: GemConnect", gemstone.com/products/s/gemconnect.html, retrieval date Nov. 10, 1998. .
GemStone Systems, Inc., "White Paper: Integrating Objects with RDBMs", gemstone.com/products/s/papers.sub.- integrate.html, retrieval date Nov. 11, 1998. .
GemStone Systems, Inc., "White Paper: Partitioning", gemstone.com/products/s/paper.sub.- partition.html, retrieval date Nov. 11, 1998. .
GemStone Systems, Inc., "White Paper: Reduced Conflict Objects", gemstone.com/products/s/papers.sub.- reduced.html, retrieval date Nov. 11, 1998..~
Primary Examiner:
An; Meng-Al T.
Assistant Examiner:
Anya; Charles
Attorney, Agent or Firm:
Hickman Palermo Truong & Becker LLP
Claims
What is claimed is:
1. A computer implemented method of persistently storing an information object, having a plurality of data storage fields, from a primary store to a secondary store, the method comprising the steps of: associating metadata with the information object, in which the metadata defines attributes of the secondary store specific to a class of the information object; receiving a request to read the information object from the secondary store; when the class of the information object is recognized, retrieving values for the data storage fields from the secondary store and storing the values in a first mapping of the secondary store to the data storage fields; instantiating the information object, in which the information object inherits from a first class and the information object is defined by a second class subclassed from the first class; associating a first table of the secondary store with the first class, and associating a second table of the secondary store with the second class; associating first and second read methods with the first class and the second class, respectively; invoking the second class in response to receiving a request to read the information object from the secondary store; and in the second read method, retrieving values for the data storage fields from the second table and storing the values in the information object, recognizing that the values relate only to the second class, and invoking the first read method.
2. The method recited in claim 1, further comprising the steps of marking the information object as modified when the information object is modified.
3. The method recited in claim 2, further comprising the steps of: declaring the information object and a plurality of other information objects as part of a program component; and detecting that the information object is marked as modified, and in response thereto, storing the information object and the plurality of other information objects in the secondary store.
4. The method recited in claim 1, further comprising the steps of: retrieving values for the data storage fields from the second table; storing each of the values in the first mapping; detecting when at least one of the values is a reference to a second information object; and storing, in a second mapping, information that can be used to later resolve the reference to the second information object into second values from the second information object.
5. The method recited in claim 4, further comprising the steps of resolving the reference to the second information object into second values from the second information object.
6. The method recited in claim 4, further comprising the steps of: storing the information object, and a plurality of other information objects that are associated with a functional component of a program, in the secondary store.
7. The method recited in claim 6, in which the step of storing further comprises the steps of: storing values of data storage fields of the information objects in the first mapping; adding at least one referential constraint, defined in the metadata, to the first mapping; and executing a storage function of the secondary store based on the first mapping.
8. The method recited in claim 7, in which the first mapping comprises a hash mapping of values of the data storage fields and names of columns of a table in the secondary store.
9. The method recited in claim 6, in which the step of storing further comprises the steps of: receiving a request to write the information object to the secondary store, wherein values of the data storage fields that are to be written to the secondary store are provided in the first mapping; when the class of the information object is recognized, storing the values into the secondary store based on the first mapping.
10. A computer implemented method of persistently storing an information object, having a plurality of data storage fields, from a primary store to a secondary store, the method comprising the steps of: associating metadata with the information object, in which the metadata defines attributes of the secondary store specific to a class of the information object; receiving a request to read the information object from the secondary store; when the class of the information object is recognized, retrieving values for the data storage fields from the secondary store and storing the values in a first mapping of the secondary store to the data storage fields; and storing the information object, and a plurality of other information objects that are associated with a functional component of a program, in the secondary store; in which the step of storing further comprises the steps of: receiving a request to write the information object to the secondary store, wherein values of the data storage fields that are to be written to the secondary store are provided in the first mapping; when the class of the information object is recognized, storing the values into the secondary store based on the first mapping; and when the class of the information object is not recognized, passing execution control to a superclass of the information object that can handle the request to write the information object.
11. A computer implemented method of persistently storing an information object, having a plurality of data storage fields, from a primary store to a secondary store, the method comprising the steps of: associating metadata with the information object, in which the metadata defines attributes of the secondary store specific to a class of the information object; receiving a request to read the information object from the secondary store; when the class of the information object is recognized, retrieving values for the data storage fields from the secondary store and storing the values in a first mapping of the secondary store to the data storage fields; and when the class of the information object is not recognized, passing execution control to a superclass of the information object that can handle the request to read the information object.
12. The method recited in claim 11, in which the step of associating metadata with the information object includes the steps of associating with the information object one or more subclass sub-table mappings of the secondary store to the data storage fields.
13. A computer-readable medium carrying one or more sequences of instructions for persistently storing an information object, having a plurality of data storage fields, from a primary store to a secondary store, wherein execution of the one or more sequences of instructions by one or more processors causes the one or more processors to perform the steps of: associating metadata with the information object, in which the metadata defines attributes of the secondary store specific to a class of the information object, in which the step of associating metadata with the information object includes the steps of associating with the information object a stored procedure executable in the secondary store; receiving a request to read the information object from the secondary store; when the class of the information object is recognized, retrieving values for the data storage fields from the secondary store and storing the values in a first mapping of the secondary store to the data storage fields; instantiating the information object, in which the information object inherits from a first class and the information object is defined by a second class subclassed from the first class; associating a first table of the secondary store with the first class, and associating a second table of the secondary store with the second class; associating first and second read methods with the first class and the second class, respectively; invoking the second class in response to receiving a request to read the information object from the secondary store; in the second read method, retrieving values for the data storage fields from the second table and storing the values in the information object, recognizing that the values relate only to the second class, and invoking the first read method.
14. The computer-readable medium recited in claim 13, further comprising the steps of marking the information object as modified when the information object is modified.
Description
FIELD OF THE INVENTION
The present invention generally relates to data processing. The invention relates more specifically to a mechanism that enables and manages persistence properties of objects. A computer program listing appendix was submitted on computer disk. A computer program listing appendix was submitted on compact disk.
BACKGROUND OF THE INVENTION
Computer networks have become ubiquitous in the home, office, and industrial environment. As computer networks have grown ever more complex, automated mechanisms for organizing and managing the networks have emerged. These mechanisms are generally implemented in the form of one or more computer programs, and are generically known as network management systems or applications.
FIG. 1 is a simplified diagram of a network 100 that is managed by a network management station 10. The network 100 comprises one or more network devices 102, such as switches, routers, bridges, gateways, and other devices. Each network device
102 is coupled to another network device 102, or to one or more end stations 120. Each end station 120 is a terminal node of the network 100 at which some type of work is carried out. For example, an end station 120 is a workstation, a printer, a server, or similar device.
Each network device 102 executes a network-oriented operating system 110. An example of a network-oriented operating system is the Internetworking Operating System (IOS) commercially available from Cisco Systems, Inc. Each network device 102
also executes one or more applications 112 under control of the operating system 102. The operating system 102 supervises operation of the applications 112 and communicates over network connections 104 using an agreed-upon network communication protocol, such as Simplified Network Management Protocol (SNMP).
Each device 102 stores information about its current configuration, and other information, in a Management Information Base (MIB) 114. Information in the MIB 114 is organized in one or more MIB variables. The network management station 10 can send fetch and set commands to the device 102 in order to retrieve or set values of MIB variables. Examples of MIB variables include SysObjectID or SysOID.
Preferably the network management station 10 is a general-purpose computer system of the type shown and described further herein in connection with FIG. 10. The network management station 10 executes one or more software components that carry out the functions shown in block diagram form in FIG. 1. For example, the network management station 10 executes a basic input/output system (BIOS) 20 that controls and governs interaction of upper logical layers of the software components with hardware of the network management station. An example of a suitable BIOS is the Phoenix ROM BIOS. The network management station 10 also executes an operating system 30 that supervises and controls operation of upper-level application programs. An example of a suitable operating system is the Microsoft Windows NT.RTM. operating system.
The network management station 10 executes an asynchronous network interface 50 or ANI under control of the operating system 30. The ANI 50 provides an interface to the network 100 and communicates with the network using SNMP or another agreed-upon protocol. The ANI 50 provides numerous low-level services and functions for use by higher-level applications.
The network management station 10 executes a network management system 40 that interacts with a database 60 containing information about the managed network 100. The network management system 40 is an example of a network management application. Using a network management application, a manager can monitor and control network components. For example, a network management application enables a manager to interrogate devices such as host computers, routers, switches, and bridges to determine their status, and to obtain statistics about the networks to which they attach. The network management application also enables a manager to control such devices by changing routes and configuring network interfaces. Examples network management applications are CiscoWorks, CiscoWorks for Switched Internetworks (CWSI), and CiscoView, each of which is commercially available from Cisco Systems, Inc.
In these and a variety of other information-processing contexts, it is useful to have a persistent record of the state of a particular physical object. For example, in a computer program that manages devices in a computer network, it is useful to have persistent records of the state of managed objects in the network. In this context, "managed object" means a switch, router, user comment, etc. "Persistent" means recorded in consistent copies in a primary store and a non-volatile secondary store, such that the copy in the secondary store is recoverable after a failure of the primary store or a failure of the power supply of the secondary store. The persistent records enable the network management system to be restored after a failure, and make information about the network available externally.
Generally, the state of a particular physical object is stored in a data structure that is created and used by an application program. Object-oriented programming languages have become increasingly popular recently and are now the dominant mechanism used for professional software development and deployment. Java.RTM. is an example of an object-oriented programming language.
In a network management system that is implemented as an object-oriented application program, information about managed objects is stored in one or more programmatic objects. An example of an element of a network management system is the Asynchronous Network Interface (ANI) system that forms a part of the CiscoWorks for Switched Internetworks (CWSI) system commercially offered by Cisco Systems, Inc. ANI queries a computer network, discovers a device in the network such as a router or switch, loads information from the device and retains the information in its store. If there is a failure of ANI or its host computer, it is desirable upon restarting ANI to have a record of the information that has been discovered, changes that have been made, and other information. To retain such a record, the programmatic objects that form ANI must be stored externally in some manner.
In past approaches, the persistent records have been stored in some kind of standard database that is capable of organizing the information for both storage and retrieval. Traditionally, such storage is defined using a declarative database language, a procedural language that maps program objects representing managed objects to definitions of corresponding database objects, and a procedural language to perform actual storage and retrieval of database objects. Generally, the storage and retrieval operations are explicitly scheduled by the writer of the program that uses the database.
This approach has several disadvantages. In particular, there is a need to coordinate the external definitions of the data store with the internal program definitions that map to the external definitions.
Further, there is a need to create new external definitions when the program changes.
There is also a need to create upgrade mechanisms when the external representation changes.
There is a need to coordinate the release of new application program functions with code that updates the database definitions.
Another disadvantage is that prior approaches do not accommodate Java.RTM. language programs. Thus, there is also a need to provide an object persistence mechanism that is compatible with the Java.RTM. language.
Still another disadvantage of prior approaches is that they store objects themselves in an object-oriented store such as an object-oriented database. Examples for object-oriented databases are Gemstone, Versant, and ObjectStore. Also, current object-relational databases are unfamiliar to many end users and application programmers. Further, many object-oriented stores are not considered stable or reliable. Therefore it is desirable to provide a way to store programmatic objects in a table-oriented relational database.
SUMMARY OF THE INVENTION
The foregoing needs, and other needs and objects that will become apparent in the following description, are fulfilled in the present invention, which comprises, in one aspect, a method of persistently storing an information object, having a plurality of data storage fields, from a primary store to a secondary store, the method comprising the steps of associating metadata with the information object, in which the metadata defines attributes of the secondary store specific to a class of the information object; receiving a request to read the information object from the secondary store; when the class of the information object is recognized, retrieving values for the data storage fields from the secondary store and storing the values in a first mapping of the secondary store to the data storage fields.
One feature of the method is that the step of associating metadata with the information object includes the steps of associating with the information object a second mapping of the secondary store to the data storage fields. According to another feature, the step of associating metadata with the information object includes the steps of associating with the information object a stored procedure executable in the secondary store.
Another feature involves the steps of instantiating the information object, in which the information object inherits from a first class and the information object is defined by a second class subclassed from the first class; associating a first table of the secondary store with the first class, and associating a second table of the secondary store with the second class; associating first and second read methods with the first class and the second class, respectively; invoking the second class in response to receiving a request to read the information object from the secondary store; in the second read method, retrieving values for the data storage fields from the second table and storing the values in the information object, recognizing that the values relate only to the second class, and invoking the first read method.
A related feature involves the steps of marking the information object as modified when the information object is modified. Another related feature involves the steps of declaring the information object and a plurality of other information objects as part of a program component; and detecting that the information object is marked as modified, and in response thereto, storing the information object and the plurality of other information objects in the secondary store.
Still another related feature involves the steps of retrieving values for the data storage fields from the second table; storing each of the values in the first mapping; detecting when at least one of the values is a reference to a second information object; and storing, in a second mapping, information that can be used to later resolve the reference to the second information object into second values from the second information object.
According to another feature, the method further has the steps of resolving the reference to the second information object into second values from the second information object. In another feature, the method further has the steps of storing the information object, and a plurality of other information objects that are associated with a functional component of a program, in the secondary store.
In yet another feature, the step of storing further comprises the steps of storing values of data storage fields of the information objects in the first mapping; adding at least one referential constraint, defined in the metadata, to the first mapping; and executing a storage function of the secondary store based on the first mapping. In still another feature, the first mapping comprises a hash mapping of values of the data storage fields and names of columns of a table in the secondary store. In another feature, the first mapping comprises a hash mapping of values of the data storage fields and names of columns of a table in the secondary store.
According to another feature, the step of storing further comprises the steps of receiving a request to write the information object to the secondary store, wherein values of the data storage fields that are to be written to the secondary store are provided in the first mapping; when the class of the information object is recognized, storing the values into the secondary store based on the first mapping.
In another feature, the storing step further comprises the steps of: when the class of the information object is not recognized, passing execution control to a superclass of the information object that can handle the request to write the information object. According to another feature, when the class of the information object is not recognized, passing execution control to a superclass of the information object that can handle the request to read the information object.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 is a block diagram of a managed network and a network management station.
FIG. 2A is a block diagram of an asynchronous network interface (ANI).
FIG. 2B is a block diagram of a Service Module of the ANI of FIG. 2A.
FIG. 2C is a block diagram of a Service Module Function.
FIG. 2D is a diagram of an acyclic graph of Service Module Functions.
FIG. 2E is a flow diagram of a preferred method of partial order evaluation.
FIG. 2F is a diagram of an Initialize method and related methods.
FIG. 3A is a diagram of data structures involved in device mapping.
FIG. 3B is a flow diagram of a Discover All Devices method.
FIG. 3C is a flow diagram of an Absorb Device method.
FIG. 3D is a flow diagram of a Get Device Type method.
FIG. 3E is a flow diagram of a Get Mapper For ID method.
FIG. 3F is a flow diagram of a device extensibility method.
FIG. 3G is a flow diagram of a service module execution method.
FIG. 3H is a flow diagram of a method of building mapping information.
FIG. 3I is a flow diagram of a Get Function method.
FIG. 4A is a flow diagram of an initialization method.
FIG. 4B is a flow diagram of a message confirmation method.
FIG. 5A is a block diagram of data structures involved in a method of parallel processing.
FIG. 5B is a flow diagram of a method of parallel processing.
FIG. 5C is a diagram of processing threads executing in parallel.
FIG. 6A is a flow diagram of a method of initializing and executing service modules.
FIG. 6B is a flow diagram of a method of initialization.
FIG. 6C is a flow diagram of a method of acquiring service module information.
FIG. 6D is a flow diagram of a method of executing service module functions.
FIG. 7A is a block diagram of relationships among a persistent object and related objects.
FIG. 7B is a diagram of a metadata object for use in conjunction with a persistent object.
FIG. 7C is a diagram of load and store operations.
FIG. 7D is a flow diagram of a Write To SQL method.
FIG. 7E is a flow diagram of a Read From SQL method.
FIG. 8A is a block diagram of objects with an inheritance relationship.
FIG. 8B is a block diagram of a database schema.
FIG. 9 is a flow diagram of an information setting protocol.
FIG. 10 is a block diagram of a computer system on which aspects of the invention may be implemented.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
A method and apparatus for parallel processing is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
1. OVERVIEW OF IMPROVED ASYNCHRONOUS NETWORK INTERFACE
An embodiment of the invention is implemented in the context of an asynchronous network interface.
1.1 DEFINITIONS
As used in this document, the following words, acronyms, and actions have the meanings set forth below. The reader is assumed to be familiar with general terminology and technical information pertaining to contemporary computer networks and internetworking. A general introduction is provided in D. Comer, "Computer Networks and Internets" (Prentice-Hall, 1997).
"ANI" means an Asynchronous Network Interface that forms a part of a network management system.
"Network management system" means a system that manages switched and routed networks and internetworks. An example of a network management system is Cisco Works For Switched Internetworks (CWSI).
"Discovery" means periodic acquisition of sets of network data from sets of network devices in the network that is managed by the network management system.
"FrameWork" means the set of classes, in an object-oriented computer programming language, and services from which the organization and structure of a Service module is derived. In particular, a FrameWork defines the structure of an API and internal dispatch mechanisms.
"FrontEnd" means that component of the ANI that implements the server side components necessary to support a client/server processing model.
"Managed Object" means an abstract data storage object that holds specific information about things being managed including the specific device mappings (if necessary), an identity, and references to Service Module Function instances appropriate to the managed thing.
"Polling" means periodic acquisition of network data from network devices. Generally, polling is carried out with a shorter period of time, with a more restrictive set of network data possible, and with fewer devices than "discovery."
"Service Module" means a set of classes derived from the FrameWork and FrontEnd packages that define the API, data model, database, and abstract functions that implement network device services.
"Service Module Function" or "SMF" means overridden functions of a service module.
"SMFContainer" or "Container object" means an object that implements the behavior of a managed object. SMFContainer objects provide for mapping of Service Module Functions, collecting service module functions comprising a collected object, and handling aliases of the object.
1.2 ARCHITECTURE
An embodiment is directed to an improved ANI 50. The ANI 50 offers extensibility, so that it can be updated and revised without distribution of a new version of the network management system 40. The ANI 50 is robust and offers efficiency and high performance.
The ANI 50 has extensibility in three aspects: device type and version; data model; service provision. In the first aspect, the ANI 50 can be modified in the field to accommodate newly developed device types and device versions. Device type and version extensibility is accomplished by encapsulating device-specific behavior into subclasses of the functional components of the ANI 50. Device-specific behavior is then performed when a function is performed, through the selection of the appropriate device and version specific subclass of the function being performed.
In the second aspect, data storage, data modeling, and data acquisition processes can be updated from time to time. Data model extensibility is accomplished by embedding the knowledge of the data model into the functions which need the data model for data storage. Data model embedding includes schema verification and installation per function, and abstracted store and load mechanisms that move data model instances to and from the database.
In the third aspect, new services can be added to the ANI 50 without requiring a major revision of the network management system.
Robustness is another aspect of the ANI 50. In the preferred embodiment, the ANI 50 operates 24 hours per day, 7 days per week, in the form of a software daemon that constantly monitors the state of the managed network 100. It is not acceptable to require rebooting of the ANI 50 to recover resources, synchronize with the database, or carry out other tasks. Further, the extensible nature of the ANI 50 requires that it is tolerant of failures of subsystems, failure of clients, and failure of devices that are managed or supported. Tracing of failures, recording of recovery, and explanation of recovery actions are necessary to maintain robustness of the system.
Efficiency and high performance are other characteristics of the ANI. Preferably, the ANI 50 and the network management system 40 support and manage a network 100 of over one thousand devices 102. To successfully manage networks of this size, in the absence of substantial distribution of services, efficient services are required. In particular, it is necessary to perform discovery, polling, and configuration in parallel operations.
In the preferred embodiment, ANI 50 functions as a server to clients, such as processes or functions of the network management system 40. Clients request services, the ANI 50 provides them, and returns replies containing status and results. A single request may have a number of replies.
FIG. 2A is a block diagram of major subsystems of a preferred embodiment of an asynchronous network interface, and their components. In the preferred embodiment, the ANI 50 comprises two major parts, a framework 201 and a set of service modules
54a-54n. Framework 201 is preferably implemented as a set of classes in an object-oriented programming language, such as the JAVA.RTM. language, and provides libraries and superclasses to carry out supervisory functions and support services. Service modules 54a-54n implement device and data functions required by clients of ANI 50.
Preferably, framework 201 comprises a FrontEnd subsystem 200, Service Module framework 210, Data model management subsystem 230, and SNMP framework 240. Each of the foregoing subsystems is preferably implemented as one or more classes in an object-oriented programming language, such as JAVA.RTM.. However, such implementation is not required, and any other implementation that provides the functions described herein may be used.
The FrontEnd subsystem 200 acts as a server and includes a multi-threaded user service 202 and scheduled "Daemon" services 204. The FrontEnd subsystem 200 provides overall management of the ANI 50, providing a multi-threaded user service, the management of client/server request/response processing, and the scheduling of actual time based or Daemon services.
The Service Module framework 210 includes mechanisms that provide Service Module Function management 212 and Request/Reply processing 214. The Data model management subsystem 230 includes an automatic schema verification mechanism 232, an automatic schema installation mechanism 234, an automatic data storage mechanism 236, an automatic data retrieval mechanism 238, and a mechanism 239 providing automatic object gathering during a transaction. The SNMP framework 240 includes a multi-threaded SNMP device access mechanism 242, a simple application level access mechanism 244, and a set of specialized per function SNMP session parameters 246. The simple application level access mechanism 244 provides, to an application program, the illusion of synchronous SNMP data getting and setting.
In the preferred embodiment, the foregoing mechanisms use definitions that ensure that evaluation order dependencies are automatically handled. The definitions enable the ANI 50 to operate as a self-organizing system that can manage itself by operating on metadata provided by each of its components. For example, components of the ANI provide metadata permitting ANI to automatically manage loading from and storing to the database 60, automatically manage creation of a schema for the database by creating tables, columns, stored procedures, triggers, and indexing, automatically create various time bases, automatically associate daemon partially ordered functions according to their data requirements, and automatically organizes data objects for function data storage. The organizational components are managed during system initialization by a Load Configuration function.
1.3 MULTI-THREADING
Preferably, the ANI 50 is implemented using coordinating independent threads of control. There are four classes of threads: the Login Service; Service Module Object Creation; Parallel service provision; and Parallel SNMP processing.
1.3.1 LOGIN SERVICE. FIG. 4A is a flow diagram of a preferred embodiment of a Login Service. Clients acquire ANI services establishing connectivity to an AniCoreService object. Connectivity between Clients and ANI is handled by an object request broker (ORB) that is preferably compliant with Common Object Request Broker Architecture (CORBA). In general, connectivity is established by creating a CORBA object for the client, and using a "Login Helper" method to bind the client to the ANI
50. The result of these steps is a handle to the AniCoreService module. In the preferred embodiment, all interfaces to the ANI 50 (and to service modules of the ANI) are defined using Interface Definition Language (IDL).
As indicated by block 402, the steps of blocks 404-406 generally involve preparation of the client process for subsequent steps. For example, in block 404, the client implements an AniClient interface. The AniClient interface provides the call back services required to implement the client side of the ANI. In particular, AniClient provides the services of Confirmation, Progress reporting, Asynchronous completion notification, and Event handling. In block 406, the client process is bound to the server. As indicated in block 410, the steps of blocks 412-414 generally involve attachment to ANI. In block 412, a CORBA object for the client is created. In block 414, the object is bound to the appropriate server using the CORBA mechanisms. In response, as shown by block 416, an object reference to the CoreServiceModule is returned.
1.3.2 SERVICE MODULE OBJECT CREATION. As indicated by block 418, the steps of blocks 422 to 424 generally relate to acquiring access to a Service Module. In block 422, the client uses a CoreServiceModule reference to invoke an aniServiceLogin method. The latter method returns an object reference to the desired service module. In particular, whenever a logged in client wants to use the services of a Service Module, it must first acquire (or have acquired) a handle to an instance of the desired service module. In the preferred embodiment, the handle is obtained by a call from the client to the aniServiceLogin method. The client passes the name of the desired service, a reference to its own CORBA service object and a login profile. If the call is successful, it returns a handle or reference to the instantiated Service Module. The handle is then used to send methods to the instantiated service module.
1.3.3. PARALLEL SERVICE PROVISION. Use of parallel processing in Service Modules is described in detail below in the section entitled "Parallel Processing."
1.3.4. PARALLEL SNMP PROCESSING. Parallel SNMP processing is also carried out in the preferred embodiment. Independently of other services of ANI, the SNMP framework 240 organizes requests for parallel execution. No single device may have more than a single request outstanding regardless of the number of requesters. However, there may be many devices for which there are outstanding requests. The outstanding requests on multiple devices can be simultaneously sent to the devices 102 of the network 100.
b 1.4 DATA MODEL SUPPORT
The data model management mechanism 230 preferably includes functional elements that provide data support functions. For example, in the preferred embodiment, automatic schema verification 232 is provided by the Persistent Object subsystem. There is an automatic schema installation mechanism 234 that ensures the current database definitions are consistent with the current requirements of the Persistent Object metadata corresponding to the elements of the Database. Further, an automatic data storage mechanism 236 provides a way to ensure that the database image of the data model is kept up to date. An automatic data retrieval mechanism 238 is available for initial loading of the data model at ANI startup time and access to data during ANI's normal execution.
2. OVERVIEW OF USER INTERACTION AND TOP-LEVEL CONTROL FLOW
FIG. 6A is a flow diagram of the general logical flow of execution of the asynchronous network interface. In general, operation of the ANI comprises initialization, as indicated by block 602, service module acquisition as shown by block 604, and execution of service module functional components, as shown by block 606. In the preferred embodiment, block 606 involves a resource assurance step in which resources needed by a service module are gathered, and an evaluation cycle in which the order of execution of service module functions is evaluated. The foregoing general steps will now be described in detail.
FIG. 6B is a flow diagram of steps involved in initialization as shown by block 602 of FIG. 6A.
In block 612, one or more stored properties files 56 are read, and the properties in the properties files are integrated. In the preferred embodiment, each properties file identifies one or more Service Modules. The properties files 56 comprise an initial program configuration file 56a, a user profile configuration file 56b, and an installed parameters configuration file 56c.
Preferably, the Initial Program Configuration File 56a stores the following types of information: a) the set of service modules which the current instance of the ANI supports; b) information identifying where the device mappings are found (for example, a root of a directory tree); c) full mappings to class structure defining each service module; d) parameters defining the parallel evaluation model; e) parameters supporting access to the database; and f) other parameters as required.
The User Profile Configuration File 56b stores a profile of each user of the ANI 50. In particular, it contains a list of users permitted access to the services of ANI and, by extension, the clients that make use of ANI. The specific contents of the user profile configuration file 56b are not critical and can be configured in several different ways. For example, the file can have no contents so that any user is able to log in.
In an alternative embodiment, security privileges are defined using a matrix that maps each user to ANI Service Module IDL definitions and objects of the managed network indicating which the user (or class of user) is permitted access to and what kind of access is permitted. For example, an entry in the file has the form
jeff:VLAD/Core/Logon ok; VLAD/Core/Discover no in which "jeff" is a user name, "VLAD/Core/Logon" is the name of a Service Module IDL definition and "ok" indicates that "jeff" is authorized to use that service module IDL definition. "VLAD/Core/Discover" is another Service Module IDL Definition and "no" indicates that "jeff" is not authorized to use that service module IDL Definition.
As described below in the section entitled End User Interface, in the preferred embodiment the ANI examines the command lines 616. In block 614, parameters contained in the command line are processed. In the preferred embodiment, the steps of blocks 610, 612, and 614 are implemented in the form of a JAVA.RTM. class called AniMain.
FIG. 6C is a flow diagram of a preferred method of carrying out service module acquisition as shown in block 604. FIG. 2B is a block diagram of an exemplary service module. One or more Service Modules 54 are the basic units of service provision and extension of ANI. The service modules are introduced into ANI via properties files 56, as stated above in connection with block 612. The process of introducing one or more service modules into the ANI is described in more detail below in the section entitled Extensibility Components.
At system start-up, the current configuration of ANI is determined through the definitions provided in properties files 56, the function lists provided by the Service Modules and the metadata contained in each Service Module function. As shown in block 612, during an initialization phase, properties files 56 are read and values identifying service modules are retrieved. Further, as shown in block 620, the step of acquiring service modules shown in block 604 of FIG. 6A involves reading each service module based on properties files 56. In block 622, a function list is read from each service module 54a-54n. In one embodiment, block 622 involves reading a list stored in a service module 54a that identifies all functions provided by the service module. In an alternate embodiment, block 622 involves reading each function 76a-76n and building a list of the functions.
In block 624, the ANI reads metadata 78 from each service module function 76a-76n of a service module 54a. The metadata 78 of each service module 54a includes a mapping of service module tokens 72 to service module function identifiers. The mapping is used by the FrontEnd subsystem 200 to correlate a request generated by a client with a particular service module. This function is described further in the section entitled Extensibility Components.
As shown in block 626, ANI then carries out resource assurance, which is the process of verifying that all resources required by components of a service module exist and are available. In the preferred embodiment, block 626 involves determining that a TimeBase object exists for the current service module, determining that a PreCondition object exists. For each resource in the foregoing list, ANI determines whether all required components of the resource exist. For database resources, if the needed resource does not exist, the ANI 50 creates it. Further description of these functions is provided elsewhere herein.
The ANI 50 acts as a server that interacts with human end users through clients that connect to the ANI. Examples of clients are the VLANDirector ("VLAD") application of CWSI, VMPSAdmin, both of which are commercially available from Cisco Systems, Inc., and other network management applications or processes. In the preferred embodiment, all client connection and communication services are provided by the CORBA-compliant ORB commercially available from Visigenic, for example.
Dispatching to service modules is accomplished by CORBA. Preferably, OrbxxxService modules are constructed to implement CORBA-defined interfaces. The OrbxxxService modules perform the Registry.request functions for security. If security fails, the function immediately returns. Otherwise, an instance of the Service Module is created and the appropriate function as requested by the client is invoked.
Synchronous Reply Processing is provided using the following mechanism. When an instance of a Service Module created to service a user request completes executing, though processing of the request may not be complete, a synchronous reply is created. A client must invoke a service module function in an object-oriented manner, by sending the function to the instance of the Service Module that the client received from the Login Service. This method invocation returns the value that the service returns as its Synchronous Reply. Asynchronous Reply Processing is provided in the preferred embodiment. Preferably, four asynchronous reply messages are defined. A groupConfirmation message provides a confirmation of intended changes. A progressReport message provides the state of the current (identified) asynchronous process. An operationCompleted message provides a final state of the requested asynchronous process. An aniDisconnected message indicates that ANI is disconnected.
FIG. 6D is a flow diagram that shows preferred steps involved in carrying out block 606 of FIG. 6A. As indicated in FIG. 6D, block 630, execution of service module functions involves invoking an IDL defined interface. The method invoked determines which function 76a-76n of the service module is needed. Command execution is handled by each of the IDL function implementations using standard registration code followed by dispatch to the implementation of a particular function. In block
632, the registration code is executed. In block 634, a particular function is invoked.
3. END USER INTERFACE
In the preferred embodiment, the ANI 50 interacts with end users through the service modules 54a-54n. The ANI 50 does not generate a graphical user interface or other user-oriented display interface; preferably, any such GUI is provided by the network management system 40. In the preferred embodiment, the ANI 50 has an Interface Definition Language interface. A user or client sends an IDL defined method to the Service Module object that was obtained via a call to CoreServiceModule.aniServiceLogin. The OrbxxxService then selects one of a plurality of mechanisms that respond to the commands.
In addition to the CORBA IDL defined interface, there is a command line interface to ANI, which provides a number of services and initial state controls. For Example, a trace interface permits the user to specify a file and a set of functional traces. An analyze interface presents a report on the organization of the current version of ANI, including the Service Modules, the Service Module functions, the dependence relationships among the Service Module functions, the defined time bases, the defined data objects (SMFUnits), and other elements. This report is useful in the field for debugging problems adding new service modules. A test interface provides a unit test support mechanism.
In the preferred embodiment, the ANI responds to the commands and parameters in the manner set forth below in Table 1:
TABLE 1 COMMAND LINE FUNCTIONS OF ANI PARA- COMMAND METERS MEANING OF COMMAND -trace ani Enable tracing for the named package. For package example, the command -trace framework enables tracing for all classes contained in the FrameWork package -debug ani enable debugging for the named package. For package example, the command -debug framework enables debugging for all classes contained in the FrameWork package. Debugging provides more detailed information than tracing. All tracing for a package is enabled when debugging is enabled for a package. -analyze none Puts the ANI in analysis mode. In this mode, the ANI examines and loads its environment as it does during normal initiation, prints a configuration report and terminates.
4. EXTENSIBILITY MECHANISMS
The ANI 50 can adapt, when installed in a live managed network 100, to changes in the devices 102 managed by the ANI. In the preferred embodiment, services of the ANI are defined in abstract data structures called Service Modules. The service module framework 210 of ANI 50 includes a mechanism providing automatic determination of currently supported devices 102 at start-up time, and automatic integration of device-specific overrides of Service Module Functions 76a-76n at system start-up time. Further, there is automatic selection of device/version specific Service Module Functions 76a-76n at instantiation time. The mechanism comprises, in one embodiment, an identification mechanism, a mapping mechanism, an inheritance mechanism, and an activation mechanism.
The identification mechanism generally involves obtaining the system variables (as defined in RFC 1213) including sysObjectID of a device 102, acquiring a Service Module Function 76a-76n that is specific to the sysObjectID, computing an identifier of a mapping mechanism, and selecting the mapping mechanism.
The mapping mechanism selects which Service Module Function 76a-76n to particularize for the device 102 being managed. The selection is carried out using a mapper associated with the type of the device 102. Each type of device has an associated mapper stored in a directory of a file system of the operating system 30.
The directory structure in which the mappers are stored defines the sequence of inheritance of classes taken from Service Module Functions 76a-76n. For example, device families have common directory roots. Members of a family, that is, specific device types, may be commonly treated in the family directory, or there may be more specialized directories contained in the family directories. Versions of devices usually lie within a family directory. The directory structure is traversed when the ANI 50 is launched. Accordingly, new device types and new device families can be added to management when the network management system 40 is installed, merely by installing a mapper and the Service Module Functions 76a-76n applicable to the new family or device type. Using these mechanisms, the ANI 50 is said to be extensible to handle previously not specifically supported device types.
FIG. 2B is a block diagram of a preferred embodiment of a Service Module 54a. The functions provided by a Service Module 54a are implemented in one or more Service Module Functions 76a-76n. Each Service module 54a declares the Service Module Functions 76a-76n that it implements. Preferably, each Service Module Function 76a-76n 0is a JAVA.RTM. class.
FIG. 2C is a block diagram of a preferred embodiment of a Service Module Function 76a. An application programmer decides how to partition functions provided by a Service Module 54a into one or more Service Module Functions 76a-76n based upon various criteria, such as attributes of the service. The programmer isolates abstract processing concepts into Service Module Functions 76a-76n so that when the Service Module Functions are adapted to a particular device, less effort is required to construct the adaptation. For example, a Service Module 54a implements the abstract service of initial discovery of devices 102 in the managed network 100. Initial discovery may comprise component operations such as finding device identity information, device type information, and device module information. The Service Module 54a declares a Service Module Function 76a-76n for each component operation.
In the preferred embodiment, extensibility is managed by configuring each service module to extend the definitions of pre-defined JAVA.RTM. classes. For example, in the preferred embodiment, Service Modules 54a-54n extend classes in the FrameWork 210, which is named com.cisco.nm.ani.framework. The classes that are extended are com.cisco.nm.ani.framework.ServiceModule and com.cisco.nm.ani.framework.SMFunction. Similarly, all device definitions are rooted in the package structure in the package com.cisco.nm.ani.devices.
As shown in FIG. 2C, a Device Mapper 1214 is associated with each device 102 or device type. Each Device Mapper 1214 is associated with a list 216 of overridden functions. Each entry in the list 216 identifies a Service Module Function 76a-76n that is overridden by the Device Mapper 1214 for its associated device or device type. Each Device Mapper 1214 is also associated with a list 1218 of identifiers of devices that are managed by the Device Mapper. In the preferred embodiment, the list
1218 is a list of sysObjectIDs, each of which references a unique type of device 102. In a preferred implementation, each Device Mapper 1214 is a class in an object-oriented programming language that extends a "devicemapper" class.
Since there may be many Device Mappers 1214, naming conventions are used to organize Mappers and express their relationship. In one embodiment, Mappers are named and stored in a directory structure of an operating system. For example, in the preferred embodiment, the operating system 30 is the Microsoft Windows.RTM. NT operating system, and Mappers are stored in the Windows directory tree structure. In other embodiments, Mappers are stored in the directory tree structure of the Solaris operating system, or other operating systems derived from UNIX, such as AIX, and HPUX.
Preferably, adaptation of the ANI 50 to new devices 102 is handled in an initialization phase of the ANI. FIG. 2F is a diagram of an Initialize method 250 and methods included in it. The Initialize method 250 includes a Discover All Devices method 252, a Load Configuration method 254, an Integrate Device Versions method 256, and a Device Mapping method 258. During execution of the Initialize method 250, in a startup or initialization load phase of the ANI 50, the Discover All Devices method 258 is invoked, which establishes certain data structures used in device mapping. Thereafter, the instantiation of one or more device-specific Service Module Function classes is carried out when an application program requests a service of a Service Module.
Specifically, ANI handles a particular device 102 in response to a client request or an internal request, such as the discovery of a new object in the network, by creating a Container Object 219, associating default mapping code with that container, instantiating certain Service Module Functions that carry an initial state for that Container object. ANI then initiates discovery of that device 102. In the course of discovery of that device 102, Service Module Functions particularize the handling of the device as the various attributes of the device are acquired. Specifically, as the sysObjectID of the device is acquired, a particular class of Device Mapper is associated with the Container object. If necessary, further refinement of the Device Mapper is done when version information describing the device is acquired.
FIG. 3A is a block diagram of exemplary data structures of the mechanism. A directory 300, managed by the operating system 30 of the network management station 10, stores subdirectory entries 302a-302n. Each entry 302a-302n is a subdirectory name identifying a subdirectory that contains a Device Mapper 1214. Each entry 302a-302n is associated with a type of a device 102. For example, in FIG. 3A, the directory 300 contains subdirectory entries associated with the Cisco 1000 router, 2000
router, Catalyst.RTM. 1200 switch ("C1200"), Catalyst 1900 switch ("C1900"), and Catalyst 5000 ("C5000") switch. Each subdirectory entry contains a single device mapper, which is preferably a JAVA class file. Each subdirectory entry generally also contains the class of the overriding Service Module Functions. It may also contain other directories containing device mappers.
The Cisco C5000 is presently commercially available in approximately a dozen versions or more. Accordingly, a mapping 310 is associated with the C5000 entry 302n. of directory 300. The mapping 310 has a device type column 312 that stores device type identifiers. Each device type identifier names a device type. The mapping 310 also has an OID column 314 that stores SysObjectID values associated with C5000 class devices. The mapping 310 also has a device mapper name column 316. Each entry in the device mapper name column 316 is a name of a Device Mapper 1214. Thus, the mapping 310 associates a device type and its sysObjectID value with a Device Mapper 1214. When a device has more than one version, the versions are handled by subclasses of the parent class with implicit application to the sysObjectIDs of the parent class. As a result, the mapping can automatically distribute software version sensitive mappings across a complete line of derived types. For example, the C55XX line of systems derive from the C5000 line of systems. Software versions that apply to C5000 systems generally also apply to C55XX systems. The automatic mechanism described herein applies the version sensitive mappers of the C5000 to the C55XX.
Each Device Mapper 1214 comprises a list, for all Service Module Functions 76a-76n defined in the ANI 50, of classes of the Service Module Functions that are overridden for the device associated with the Device Mapper. In an embodiment, the Device Mapper 1214 stores a plurality of entries, each entry comprising a value in a Service Module Function name column 318 and a class column 320 indicating the class of that function that is overridden. Using the list in the Device Mapper 1214, the ANI 50 can determine, when a particular device matching the OID is encountered, that a particular Service Module Function class should be overridden by a class listed in the Device Mapper list. Thus, the Device Mapper 1214 enables an application programmer to declare classes, the behavior and data of which are to be used when dealing with a particular service abstraction for a particular kind of device.
In the preferred embodiment, the Device Mapper 1214 associated with a particular device type need only contain overrides for the specific behavior of the device type that differs from other device types to which the particular device type is related in a hierarchy. For example, consider a device 102 of type C5500.2.2 that is related to earlier devices of type C5500.2.1, C5500, and C5000, as shown by the hierarchy of device type identifiers in column 312 of the mapping 310. The Device Mapper 1214 that is associated with device type C5500.2.2 need not include overrides for behavior that is overridden in the Device Mapper 1214 associated with device types C5500.2.1, C5500, or C5000. In the preferred embodiment, an automated mechanism incorporates the overrides of such related devices into classes that are instantiated for Service Module Functions applicable to the C5500.2.2 device.
FIG. 3B is a flow diagram of a portion of the Discover All Devices method 252 shown in FIG. 2F that is executed in the Initialize method 250 of the ANI 50. The portion of the Discover All Devices method 252 shown in FIG. 3B constructs the mapping 310.
In block 330, the ANI 50 starts at the root of the device mapper directory tree by reading the root path from the properties file 56. In block 334, the ANI 50 locates a Device Mapper 1214 in the next available directory after the root. Blocks
336-344, inclusive, involve a recursive walk of the directory tree. Thus, blocks 336-344 may be implemented as a separate method that is recursively called. In block 336, the next entry in the directory 300 is read and examined. If the entry is another directory or subdirectory, as tested in block 338, then in block 344 a recursive call is made to block 334 so as to continue the search of the directory tree.
If the entry is not another directory or subdirectory, then the ANI 50 tests whether the entry is a device mapper, as shown by block 340. If the entry is a device mapper, then the device mapper is absorbed in an Absorb Device process, as shown by block 341. Generally, blocks 338-340 involve looking for directory entries named <something>DeviceMapper.class, in which <something> is a directory name and "DeviceMapper.class" identifies a Device Mapper 1214. For example, in the directory named "C1200," a Device Mapper is stored in the file "com.cisco.nm.ani.devices.C1200.C1200DeviceMapper".
As shown in block 344, if the entry is not a device mapper, then the search continues in any other entries of the directory. The steps of block 336, block 338, block 340, and block 344 are repeated for each device type supported by the ANI 50.
FIG. 3C is a flow diagram of a preferred method of absorbing a device as indicated in block 341. In block 350, an instance of the Device Mapper found in block 334 is created, using its long class, e.g., "com.cisco.ani.devices.C1200. C1200DeviceMapper." In block 352, data stored in association with the Device Mapper is obtained. In particular, block 352 involves obtaining the information stored in the list 216 and the list 1218 associated with the Device Mapper. In block 354, the list 1218 is read in order to determine the device OlDs that are handled by the Device Mapper. In block 356, a determination is made as to whether the Device Mapper deals with a particular device software version. If so, then a special handling method is called in block 358, as described in more detail herein. Otherwise, in block 360, the OlDs in the list 216 and the name of the Device Mapper are added to the mapping 310. Preferably, the mapping 310 is a database table or a global variable that is accessible throughout the ANI 50.
INDIVIDUAL DEVICE MAPPING
FIG. 3D is a flow diagram of a preferred process for a GetDeviceType method 362. In block 364, the method acquires a value of a sysObjectID MIB variable from a device 102 that is of interest, by calling appropriate SNMP functions to obtain the value over the network 100. In block 366, the sysObjectID value is subjected to a validation process. If the sysObjectID is a new identifier not currently in the data model, as tested in block 367, then in block 368, a Device Mapper 1214 is obtained for the current sysObjectID value. In the preferred embodiment, block 368 involves invoking a GetMapperForID method, from a master Device Mapper class, and passing it the current sysObjectID value.
In block 370, a determination is made as to whether the GetMapperForID method returned a Device Mapper object. If not, in block 372 an error is thrown, and the Device Mapper base class or default class is returned in block 374. If a Device Mapper is returned, then in block 376, an identifier or name of the returned class is stored in the current Container object.
FIG. 3E is a block diagram of a preferred implementation of the GetMapperForID method 368. Generally, the GetMapperForID method 368 receives an OID, maps the OID to a device-specific Device Mapper, and returns the Device Mapper class name. In block 380, the OID passed to the method is scanned to determine whether it is a version OID, as tested in block 382. In a preferred embodiment, the colon character (":") in an OID is a version separator, and block 380 involves scanning the OID for a colon character.
If the OID is not a version OID, then in block 384 a Device OID table is scanned and an entry corresponding to the OID is read. As a result, a mapper for the OID is obtained. In block 386, the name of the Device Mapper found in the Device OID table is returned to the calling method.
If the OID is a version OID, then in block 388 a portion of the OID that excludes the version information following the colon character is extracted, and used in subsequent blocks as the OID. In block 390, a Device Mapper is located that is appropriate to the OID portion. Preferably, the steps of block 390 involve the same steps as block 384; the same function call or subroutine can be used. In block 392, a Device Mapper is located for the version portion of the OID. If the version Device Mapper is found, as tested in block 394, then it is returned in block 398. If not an error message is issued, as shown in block 396, and the Device Mapper for the OID stored into the Container object. If no device mapper is found, either for the OID or for the Version OID, then the default DeviceMapper is stored in the Container object.
Thereafter, references to Service Module classes of the Container object will be appropriately mapped into the appropriate device-adapted class.
The Handle Versions method 358 provides a mechanism to locate a Device Mapper based not only on OID but also on a version identifier. In standard MIB variables, software version information is not included. Therefore, a separate mechanism is required to enable the ANI 50 to match a particular version of hardware, software, or firmware of a device 102 to a Device Mapper. Preferably, entries in a Device Mapper may include information that specifies a range of versions over to which the Device Mapper applies. For example, the entries may provide version brackets indicating that a particular Device Mapper is chosen only within a particular range of versions, or from a particular version and all subsequent versions, etc.
The format of a version range, as specified as part of an OID when registering a DeviceMapper, is as follows:
If there is a <lowerBound>, but no <upperBound> then:
1. if <openingBracket> is a left parenthesis ("("), then the entry applies to versions whose version string is greater than <lowerBound>.
2. If <openingBracket> is a left bracket ("["), then the entry applies to versions whose version string is greater or equal to <lowerBound>
If there is <lowerBound> and an <upperBound> then:
1. if <closingBracket> is a right parenthesis (")"), then the entry applies to versions whose version string is treated as above for the <lowerBound> but which is less than <upperBound>
2. if <closingBracket> is a right bracket ("]"), then the entry applies to versions whose version string is string is treated as above for the <lowerBound> but which is less than or equal to <upperBound>
If there is no <lowerBound>, but only an <upperBound>, the entry applies to versions with no lower bound but which is treated for <upperBound>as in the case for <lowerBound> and <upperBound>.
USING DEVICE MAPPINGS TO PARTICULARIZE FOR A SPECIFIC DEVICE
Using the data structures and mappings established by the foregoing mechanisms, Service Module Functions may be instantiated in a device-specific manner at runtime when a service is needed by an application. Generally, the process resulting in such instantiation is called invocation. In operation, in general, an application such as network management system 40 requests a service of a Service Module 54a by sending a message to the Service Module requesting the service. The Service Module may gather a collection of Containers representing devices, for example. When a particular service is requested of a particular device in a particular Container, by using a Service Module Function, the Device Mapper object associated with the Container object mediates the reference to the method, finds the appropriate method, instantiates it, and makes it available as the code to be used for the current managed device 102 for the current Container object.
FIG. 3F is a top-level flow diagram of one embodiment of an invocation process. In block 1302, one or more devices are discovered in the network 100. Block 1302 is executed, for example, in response to a request by an application program to carry out some function relating to devices 102 in the network 100. When a device is encountered in the network 100 for the first time, as tested in block 1304, then in block 1306 an identifier of the device indicating its type is obtained. For example, a unique value called a sysObjectID is obtained from the device.
When the ANI 50 is initialized, it constructs a list 1308 of sysObjectIDs that it recognizes and can manage. In block 1310, the ANI tests whether the acquired sysObjectID matches one of those loaded by ANI at start-up time. If so, then in block
1314 a Container object is created for the device, and in block 1316 an appropriate device type handler (a device mapper 1214) can be instantiated. If the sysObjectID is not recognized in the test of block 1310, then in block 1312 the device is treated as unknown, and UnknownDeviceMapper is used.
In block 1318, the version of the device is determined. The determination of block 1318 is done in a device type specific manner. In block 1320, the device specific information is integrated into the Container object. Preferably, as a consequence of ANI 50 determining a device's type and version, an instance of a Device Mapper is stored in the Container object. Thereafter, the Service Module Functions used to perform services for that Container are selected to be appropriate to the selected device and version.
FIG. 3G is a flow diagram of another embodiment of an invocation process. In block 1330, an application such as network management system 40 is executed. In block 1332, the application calls a method of a Service Module passing it some kind of device identifier, for example, an IP address. In block 1334, the Service Module method is executed. Part of the execution of the Service Module method is the translation of the device identifier into a reference to a Container object.
Box 1336 shows invocation processes. In block 1338, a Device Mapper 1214 associated with the Container object is invoked. In block 1340, a version of the Service Module Function called in block 1332 and that is appropriate for the current device type is located. In block 1342, the device-specific Service Module Function is instantiated or retrieved. In block 1344, the reference to the device-specific Service Module Function is returned to block 1338. In block 1346, methods of the device-specific Service Module Function are executed, and the application thereby is serviced. In block 1348, control returns to block 1334 or subsequent processes.
FIG. 3H is a flow diagram of a preferred process for finding and instantiating a device-specific Service Module Function as indicated in block 1340 and block 1342. Block 1350 generally refers to the initialization process that is shown in FIG.
3B, FIG. 3C, FIG. 3D, and FIG. 3E. Generally, the process of FIG. 3H involves receiving a device OID and a corresponding Device Mapper, and then instantiating device-specific classes that implement the requested Service Module Function.
Each Device Mapper 1214 includes an initialization method named InitializeLocalMappingTable and a Boolean instance variable _SMFMappings. The instance variable _SMFMappings is structured as a hash table that stores a mapping of classes that are needed for the current Service Module Function for the current device. Initially, _SMFMappings is set to a null value, and it is filled with mapping values the first time that a particular device invokes the current Device Mapper 1214. Accordingly, in block 1352, the value of _SMFMappings is tested, and if it is null, then an InitializeLocalMapping method 1354 is executed.
In the preferred embodiment, each Device Mapper 1214 includes a InitializeLocalMapping method that does mapping for the Device Mapper. However, this embodiment is used only due to certain inheritance restrictions of the JAVA.RTM. language. In an alternative embodiment, there is one InitializeLocalMapping method for all Device Mappers.
According to the InitializeLocalMapping method 1354, in block 1356 the _SMFMappings instance variable is initialized as a hash table. The InitializeLocalMapping method 1354 scans through all the Service Module Functions that are listed in the Service Module Function name column 318 of the current Device Mapper 1214, as indicated in block 1358. For each Service Module Function named in the Device Mapper 1214, in block 1360, a method is called to integrate overrides of that Service Module Function into the _SMFMappings hash table. Preferably, an Integrate Method is called in block 1360 and is passed the hash table and the Service Module Function name.
In the IntegrateMapping method, as shown in block 1362, in the override list 320 of the Device Mapper 1214, the ANI 50 finds the next Service Module Function name that matches the current class name. For example, consider a situation in which the current directory name associated with the device type is "C5000", and the Service Module Function named in column 318 of the current Device Mapper 1214 is "VLADSMFGetDeviceDetails". In block 1362, the Service Module Function name is concatenated with the current directory name to yield an overriding Service Module Function name. The overriding Service Module Function must be named <directoryname><genericname>. Thus, for device C5000 and Service Module Function VLADSMFGetDeviceDetails, the overriding Service Module Function name would be "C5000VLADSMFGetDeviceDetails." The foregoing implementation is known to be required due to limitations on class name duplication inherent in the JAVA.RTM. language. In an alternative embodiment, names of overriding classes are the same as overridden class names, but are located in a sub-directory named after the device. For example, an overriding class would be com.cisco.nm.ani.devices.c5000.VLADSMFGetDeviceDetails.
In block 1364, the device OID, overridden class name, and the corresponding overriding class name are stored in the hash table. In an embodiment, the values are stored in the _SMFMappings instance variable local to the current Device Mapper.
The designation of the hash table _SMFMappings as a local instance variable is an important aspect of this embodiment. Consider the foregoing example in which the method C5000.C5500DeviceMapper is the Device Mapper 1214 for a C5500 device. It is a subclass of the method C5000DeviceMapper, which is the Device Mapper for C5000 devices. Consequently, when the JAVA.RTM. operation super is executed in the C5500 DeviceMapper, it causes the C5000 device mapper to be executed in the current local context. Therefore, the _SMFMappings hash table of the C5500 device mapper is used by the C5000 device mapper. Accordingly, the C5500 hash table is populated with overrides associated with the C5000 device mapper. Then the C5500 Device Mapper executes and populates the hash table with its device-specific overrides.
As a result, if the C5500 Device Mapper overrides a class that the C5000 device mapper also overrides, the C5500 Device Mapper will predominate, because it will overwrite the conflicting entry previously stored in the hash table by the C5000
device mapper. In contrast, if the C5000 device mapper stores a hash table entry that the C5500 Device Mapper doesn't override, then the hash table contains only the C5000 override. If neither Device Mapper stores an override for a particular Service Module Function, then the default class is eventually instantiated.
Thus, using an instance variable in the Device Mapper, but invoking each superclass and letting it fill the local variable itself, results in a general inheritance model for device-specific class adaptation. Using inheritance mechanisms of an object-oriented programming language, classes that define Service Module Function behavior are incrementally added to an override mapping.
Once the hash table is initialized and filled, one or more device-specific Service Module Function classes may be instantiated, as shown in FIG. 3H, in block 1366. For example a device specific GetDeviceDetails Service Module Function class is instantiated during device discovery. The GetDeviceDetails SMF implements methods that carry out detailed device discovery functions such as fetching modules.
In block 1368 and subsequent blocks, overrides are handled. Preferably, in block 1368, the current Container object is passed to a GetData method, details of which are shown in FIG. 31 which is described elsewhere herein. A function is called in order to retrieve an index into the hash table that identifies the device-specific Service Module Function instance. As shown in block 1374, processing occurs to determine which instance is needed, and the result is an index value. The index value references an entry in an ordered sequence that is particular to the current device. The ordered sequence contains references to instantiated Service Module Functions, as shown in block 1376. In block 1377, the instance is returned.
Using the steps of block 1368, block 1374, and block 1376, and block 1377, a particular instantiated object that implements a Service Module Function is obtained based on a device mapper and the name of the generic Service Module Functions. Consider an example in which the generic Service Module Function name is VladSMFGetDeviceDetails. There may be dozens of such functions defined, each for a particular device type. Based on the device mapper in the current Container object, the GetData method computes the proper index and gets the particular instance from the ordered sequence of Service Module Functions contained in the Container object.
In block 1370, a determination is made as to whether an overriding Service Module Function is already instantiated. If the test of block 1370 indicates that the Service Module Function has been instantiated before, then in block 1372, a device identity is obtained.
If the test of block 1370 indicates that an instance has not been created, then control is passed to a Get Function method 1378 in order to create such an instance.
FIG. 3I is a flow diagram of a preferred embodiment of a GetFunction method 1378. Generally, the purpose of the GetFunction method 1378 is to create an instance of a Service Module Function, taking into account device-specific mapping. Based on a Container object and its device mapper, a device-specific class is retrieved. Preferably, a parameter to the GetFunction method 1378 is a generic instance of the Service Module Function that contains identification information. In the preferred embodiment, the identification information is an index into the Containers Service Module Function list 76.
In block 1379, a determination is made as to whether Container contains a device-specific service module function instance as defined by the passed generic instance. If so, then in block 1390 the Service Module Function instance is returned to the caller
If the test of block 1379 is negative, then control is passed to block 1381, in which a Service Module Function object is instantiated. In block 1380, the Device Mapper 1214 associated with current Container object is retrieved. In block 1382, the requested Service Module Function is looked up using the Device Mapper 1214. If an override exists, as tested in block 1384, then the overriding Service Module Function is instantiated in block 1388 and stored in the Container object in block 1389. As a result, in block 1390, the mapped Service Module Function version appropriate to the particular Device Mapper associated with the current device is returned.
If there is no override, then the generic version of the SMF is instantiated in block 1386 and processing continues in block 1389.
At this point, the device-specific Service Module Function is available for passing back in the GetData method.
Consider an example in which a Service Module defines a generic service module function class VLADSMFGetDeviceDetails that defines a particular abstract behavior. The directory 300 also contains a class C5000VLADSMFGetDeviceDetails that defines overriding behavior for a C5000 type device. Generally, there are far more methods in the generic class than the specific class; accordingly, the specific class for device C5000 only overrides specific behavior that is inappropriate for the C5000
device. Indeed, for a given device type, there may be only one overriding class and, perhaps, only one overriding method.
In this example, block 1380 involves identifying the class name of the generic function that was passed in, e.g., com.cisco.nm.cwsi.ani.VLADSMFGetDeviceDetails. A function name segment of the full class name is extracted, e.g., VLADSMFGetDeviceDetails. The Device Mapper known to the SMFContainer in which the properly overridden version instance of VLADSMFGetDeviceDetails is to be stored Device Mapper is consulted, and its mappings are examined to identify a function associated with the function name. If there is none, then in block 1390 an instance of the prototype function is returned. If there is a function found, an instance of it is returned in block 1390. Preferably, block 1388 involves getting the device-specific class and instantiating it. Block 1389 stores it in the Container object.
Thus, after the mappings shown in FIG. 3A are established, a reference to a generic Service Module Function will cause the function to instantiated in a form that is appropriate and customized for the current device. The customized class is selected based on the OID and version of the current device. Moreover, the mapping mechanism described herein is not dependent upon the content of the identifiers that are used in mapping. For example, the mapping need not use a SysObjectId or OID; it may use any other identifier.
Using the foregoing mechanisms, the ANI 50 integrates with itself, service modules and device definitions. As part of the foregoing mechanisms, information about a new device is integrated with the ANI 50 through simple steps. A programmer determines the operational differences between the new device and prior devices. A new directory 300 is created for the new device within the current directory structure, below the most closely related device. A Device Mapper 1214 is created. OlDs for the new device are declared in the Device Mapper. One or more Service Module Functions are written to implement those attributes of the new device that are different from its most closely related device. The Device Mapper and Service Module Functions are distributed, for example, by download to users of the ANI 50. A user of ANI 50 downloads classes for the Device Mapper and Service Module Functions into the user's directory tree. The user restarts the ANI 50 and the new information is automatically integrated.
This mechanism is highly advantageous. Some network devices vary in subtle ways from other devices, but also run the same software in general. For example, some new device types represent refinements of device hardware only, whereas some new device types represent new versions of software executed by the device. In prior approaches, an application programmer is required to hand replicate processing common to an existing device into a class that governs interaction with a related but slightly different device. In the preferred embodiment, such hand replication is eliminated, thereby greatly reducing application development time and lessening the likelihood that bugs are introduced.
5. EVALUATION OF THE ORDER OF EXECUTION OF SERVICE MODULE FUNCTIONS
In the preferred embodiment, the ANI has a mechanism providing dynamic determination of the execution sequence of processes. The mechanism comprises a set of executable components, a characterization mechanism, a partial order mechanism that depends on the characterization mechanism, and a partial order execution mechanism.
The set of executable components completely describes the processing to be performed for some component of, for example, the managed devices at a particular time. If a new requirement must be satisfied by additional executable components, the additional executable components are added to the set. In the preferred embodiment, the executable components are Service Module Functions, and the dynamic determination of execution sequence involves evaluation of partially ordered Service Module Functions. The characterization mechanism provides an annotation of each executable component, permitting reference to each component in other parts of the mechanism.
The partial order mechanism establishes order among a set of Service Module Functions 76a-76n. Each Service Module Function declares "pre-conditions" that represent one or more dependencies of the Service Module Function on another Service Module Function. During the startup phase of the ANI 50, all Service Modules and all Service Module Functions are subject to several types of evaluation. One evaluation determines execution order. Execution order is determined by grouping Service Module Functions into execution equivalence classes. An execution equivalence class is determined by the TimeBase of each Service Module Function. A Service Module Function may have several timebases and, thus, be a member of several equivalence classes. Within each equivalence class, each Service Module Function is placed in relation to each other Service Module Function of the equivalence class through an examination of the "pre-conditions" belonging to the Service Module Function in the equivalence class.
The partial order mechanism depends upon the characterization mechanism. The partial order mechanism enables a first executable component to declare which other components are "pre-conditions" to the first executable component. In this context, a component that is a "pre-condition" to a first executable component means that the other components must be executed before the first executable component. Each pre-condition comprises one or more characterizations.
The partial order execution mechanism schedules or orders the executable components into a final execution order, by evaluating the characterizations and pre-conditions. Newly introduced components are added to the execution order when the partial order execution mechanism runs. In the preferred embodiment, the executable components are Service Module Functions. FIG. 2C is a block diagram of a preferred structure of a Service Module Function 76a. Service Module Functions 76a-76n are self-describing using metadata that describes the needs and the services provided by the Service Module Function. The ANI 50 uses the metadata to determine when a Service Module Function must be invoked, the kind of data it requires, and whether resources it requires are available in the system. Preferably, the metadata comprises a TimeBase value 1202, a PreCondition value 1204, a Unit value 208, an isAllRequired value 1210, and an Apply method 1212.
Each TimeBase method 1202 returns a value indicating when the current Service Module Function is performed. In the preferred embodiment, each TimeBase method 1202 may return a value of Periodic, Fixed, or Demand. The Periodic value means that the Service Module Function is executed periodically when the system does, for example, device discovery. The Fixed value means that the Service Module Function is executed at a fixed time. The Demand value means that the Service Module Function is executed immediately, upon request by the user. Use of these values in partial order evaluation and execution is described below
The PreCondition value 1204 identifies preconditions for the current Service Module Function 76a, i.e., Service Module Functions that must be executed before the current Service Module Function module. In the preferred embodiment, a PreCondition value 1204 is a set of Category names 1206a, 1206b-1206n. In the preferred embodiment, each Category name 1206a-1206n of a precondition refers to a category name 203 in an SMFDescription 1201 of some Service Module Function. A category name 203 is unstructured. By convention, category names are a series of words separated by periods ("."). Generally, the words, in order, include the name of the TimeBase, the name of a phase of computation, and an abbreviation of the SMF name. For example, a Category name might be the following: "Discovery.Acquire.GetIdentity". Conventionally, this means that the named SMF is intended to run in the Discovery timebase during the Acquire phase and it is the GetIdentity Service Module Function.
The Category name 1206a-1206n may comprise either a set of names that explicitly correspond to names of SMF objects, or one name that contains a wildcard character. An example of a name having a wildcard character is "Discovery.Acquire.*". When a name containing a wildcard character is specified, the name signifies that all modules characterized by the wildcard must be executed before the current module. However, all the modules characterized by the wildcard may be executed in any order among themselves.
Preferably, each execution equivalence class is organized in a partial order graph with a linear execution order. For example, in the preferred embodiment, the ANI maintains one or more node objects, called SMFDefinitionPONode objects, in a data structure having the form of a directed acyclic graph. Each SMFDefinitionPONode object stores a name and a set of SMFDefinitionPONode objects. The name is the category of the node. Pre-conditions are category names and category name patterns. The set of SMFDefinitionPONode objects identifies successors of the SMFDefinitionPONode object. Each successor represents a module that must be executed after the module identified by the name.
Also preferably, the partial order mechanism provides methods by which SMFDefinitionPONode objects may be inserted into or removed from a tree of SMFDefinitionPONode objects.
Each Unit value 208 identifies an object type that is to be used by the current Service Module Function 76a when that module is to be executed. For example, a Unit method 208 may return the value "Topology", which indicates that current Service Module Function 76a operates on objects of type "Topology". Also, in the preferred embodiment, each Service Module Function 76a contains a isAllRequired value 1210 that is a Boolean value TRUE or FALSE depending on whether the Service Module Function operates on a single object of its Unit type or all objects of its Unit type. For example, if a Service Module Function operates with the information of a single device, then isAllRequired value 1210 for that Service Module Function would be FALSE.
Thus, each PreCondition method 1204 and TimeBase value 1202 defines a location in a partial order of execution of the Service Module Function. Before a Service Module Function can be executed, it must be placed in its proper position in the partial order and a complete ordering must be generated. A Service Module Function is then executed depending upon the schedule of its timeBase (on a periodic schedule, at fixed times, or on demand)
In the preferred embodiment, during system start-up, all Service Module Functions are examined by the partial order mechanism. Based on the partial order information provided in the TimeBase value 1202 and PreCondition value the partial order mechanism constructs a memory representation of the partial order of execution of all the Service Module Functions.
FIG. 2D is a diagram of a preferred memory representation, structured as a directed acyclic graph 1220. Each node 1222-230 of the graph 1220 is a SMFDefinitionPONode object. Each node 1222-230 represents a Service Module Function. The structure of the graph 1220 represents the pre-conditional relationships of the Service Module Functions. For example, node 1226 and node 1232 both have node 1234 as a pre-condition. Node 1234, node 1236, and node 1238 are all preconditions to execution of node 1230. Nodes 1240, 1238, and 1236 are all pre-conditions of node 1224. The graph 1220 is constructed by scanning each Service Module Function and examining each TimeBase value 1202 and PreCondition value. Based on these values, an SMFDefinitionPONode object is instantiated and inserted into graph 1220 using an appropriate insert method.
All graphs 1220 have a root node 1230. A root node is not a pre-condition of any node and has no preconditions. The root node serves as a starting point for the graph. A node "a" is at "layer n" just in case there are "n" nodes between the root of the partial order tree and node "a". A node "a" is "higher in the partial order tree than" a node "b" just in case "a" is on layer k and "b" is on layer "j" and "k" is less than "j" numerically. "layerSet n" in the partial order tree is the set of all nodes whose layer is n. The depth of a partial order tree is the value "n" which is the index of the layerSet none of whose nodes has successors.
FIG. 2G is a flow diagram of an exemplary method for building the graph. In block 262, a new node is created. In block 264, the graph into which the new node is to be inserted is selected, based on the TimeBase value. There are two phases of insertion: adding nodes to the partial order; and reducing the partial order, as indicated by block 266 and block 268, respectively.
FIG. 2H is a flow diagram of an exemplary method for adding a new node called "new-node" to the partial order tree. In block 268, the root node is made as the "current-node". In block 270, each of the successors of the current-node is examined in turn, making them "current-successor" in turn. When there are no more successors, control passes to the step of block 278 that is described below.
As indicated in block 272, if the new-node is a pre-condition of the current-successor node, then the current-successor node is removed from the set of successors of current-node, and current-successor is made a successor of new-node.
As shown by block 274, if the current-node is a pre-condition of the new-node, then the new-node is made a successor of the current-node.
As shown by block 276, the next step is to recursively make current-successor current-node and proceed with the step of block 270.
When all successors have been processed, the test of block 270 is false, and control passes to block 278. There, if the current-node is the root node, then new-node is made a successor of current-node. In block 280, the process is complete and a return occurs.
Cleaning up the tree proceeds as follows. First, all nodes of the partial order tree are unmarked. Next, the process proceeds through all layerSets of the partial order tree, one layer at a time, marking each node of the layerSet with the node of which it is a successor. For example, at the end of this phase node 1224 will be marked with node 1238 or node 1236. Since node 1238 and node 1236 are equivalent because they are in the same layerSet, it does not matter which has node 1224 as its successor. The process then proceeds through all layerSets of the partial order tree, one layer at a time, removing from each "current-node" successor set any "successor-node" of a "current-node" whose mark is not "current-node". For example, at the end of this phase, node 1240's successor set will no longer contain node 1224; node 1238's successor set will contain node 1224.
Then, if the root node has more than one successor, the tree is not well formed; otherwise it is well formed and cleaned.
After the partial order tree for a given timeBase has been cleaned, the linear order of execution of the Service Module Functions of the tree is computed. Because the structure of a partial order tree does not change after it has been initially built, it is permissible to construct the linear order as soon as the tree has been cleaned. The linear order preserves the pre-condition constraints but guarantees nothing about any other ordering of execution. For example, when the partial order graph 1220 is linearized, the following will be true: node 1238 will be earlier in the order than any of node 1222, node 1224, node 1226, or node 1232; nothing is said about the position of node 1238 with respect to nodes 1236 or 234--node 1238 could be before, between, or after nodes 1236 and 234.
Linearization is done as follows. First, the node-number is initialized to zero ("0"). Then, the process traverses each layerSet, starting with layerSet 0 and proceeding to layerSet n in which n is the depth of the partial order tree. For each node in the current layerSet, the current node-number is assigned, and the node number is incremented after each assignment. For example, if there are seven nodes in the current layerSet and the current value of the node-number is "11" then the first node is assigned number "11"; the next is assigned "12"; and so forth until the last node of this layer set is assigned the number "16".
Thereafter, the linearized order of the nodes of the partial order tree is the order that results from selecting the nodes in the order of their node numbers.
In the preferred embodiment, the timeBase execution mechanism is carried out at several different times during execution of ANI, as indicated by the TimeBase values. For example, ANI periodically carries out a general discovery of all devices in the managed network 100, and a linearized order evaluation is carried out upon such discovery. The name of the TimeBase that carries out discovery is Discovery and it is a periodic timeBase. Generally, the periodic general discovery is carried out every 30 minutes. Also, ANI periodically carries out a "major sweep" operation. For example, several times during a day at fixed times, ANI "sweeps" the managed network 100 to retrieve information that identifies users, hosts, and other networking information. Each time a "sweep" is performed, the Service Module Functions are invoked in linearized order. For example, in one embodiment, there are two timeBases which carry out "sweeps": MajorSweep which is a fixed time base typically set to run at
10:00 AM and 2:00 PM; MinorSweep which is a periodic time base typically set to run at an interval of 10 minutes. Further, ANI provides demand operations in response to unscheduled, non-periodic requests. For example, certain applications, such as the VLAN Director application commercially available from Cisco Systems, Inc., explicitly change the configuration of devices. When such explicit changes are performed, a Demand type timeBase is used and its linearized execution is performed as in block 636
of FIG. 6D. In the preferred embodiment, a separate graph 1220 is maintained for each of TimeBase.
At each of these times, the linearized execution mechanism is carried out. In an embodiment, a linearized evaluator is invoked and is passed a set of things to evaluate and a partial order tree of service module functions that are to be applied to the sets. In the preferred embodiment, a partial order execution method EvalGroup is executed and is passed an object representing a graph 1220.
6. PERSISTENT OBJECT STORAGE
In the following discussion, the use of persistent object storage mechanisms in various ANI 50 mechanisms is described, and then the internal operation of the persistent object mechanisms is described.
In the preferred embodiment, each programmatic object and its contents that are used in Service Modules 54 and the other mechanisms described herein may be stored persistently in the database 60. Also in the preferred embodiment, each programmatic object is a JAVA.RTM. language object A single declarative mechanism is provided that permits all definitions of internal to external mappings to be specified as part of the class to be stored itself. The mechanism automatically schedules the loading and storing of information to and from the external database without intervention by the programmer.
In a preferred embodiment, the mechanism has five (5) components:
1. A metadata definition that describes all aspects of the persistent data, including table definitions, constraint definitions, notification definitions and a revision history that defines upgrades from version to version.
2. A Write Object method that provides a mapping between the elements of program objects and the columns of the database table that are declared in the metadata definition.
3. A Read Object method that provides a mapping between the columns of the database table that are declared in the metadata definition and the elements of program objects.
4. A Resolve method that binds a first object to other objects of the system that are referenced as elements of the first object, or from which the first object inherits properties and behavior.
5. A set of state-setting methods that enable objects to be marked for deletion and updating.
Each component is defined using a semi-declarative mechanism. In this context, "semi-declarative mechanism" means that each component comprises program structures that consist almost exclusively of method calls that construct static or dynamic data structures.
Preferably, the mechanism operates in conjunction with a primary store and a secondary store. The secondary store is a direct mirror or backup of the primary store rather than an extension thereof. In this context, "extension" means that not all objects are in the primary store, and the secondary store is queried when an object is not available in the primary store. In contrast, in the preferred embodiment there are no requests for objects from the secondary after an initial load. When a request for an object is made, the primary store is accessed only. When primary store is changed, secondary store is automatically update to ensure that it is synchronized with primary store. A partial order is specified for updating the secondary store in which foreign key constraints of the secondary store are preserved. When the secondary store is to be updated, a closure operation is carried out before the secondary store is modified. In particular, all modified objects referenced by a first object must be included in any update to the first object. The identity of objects referenced by a first object is stored in the metadata definition.
Generally, it is preferred to use main memory of a computer system as the primary store and a database stored in a persistent storage device as the secondary store. The database is, for example, SQL Anywhere, the Sybase.RTM. SQL Server, or an Oracle.RTM. relational database system. However, a specific database is not required as the secondary store; any other data storage mechanism is suitable. The reader is presumed to be familiar with structures, functions, and terminology relating to relational database systems, such as tables, stored procedures, indexes, triggers, and referential constraints. The database 60 implements these structures and functions and responds to statements issued in the Structured Query Language (SQL).
6.1 PERSISTENT OBJECTS
In the preferred embodiment, a Persistent Object class is the root class of all persistently stored objects. In one embodiment, all classes in an application program that require persistent storage in the database must inherit from the class PersistentObject. The behavior of Persistent Objects is defined in the class PersistentObject. In particular, the class makes use of metadata definitions. Therefore, every persistent object must define metadata that is used to manage it. In an alternate embodiment, a class that uses persistent storage inherits persistence behavior from a plurality of classes that implement components of persistence behavior.
For example, to store an object persistently in the ANI 50, a programmer configures an object to inherit properties of the Persistent Object class. FIG. 7A is a diagram of a Persistent Object class 700 and its relationships to other elements of the ANI 50. The Persistent Object class 700 is a superclass of a Service Module Function (SMFunction) class 702 and of the Container class 704 and other support classes. The Persistent Object class 700 contains methods Dirty 706, markDirty 708, writeObject 712, and readObject 710.
Preferably, in the ANI 50, one or more Persistent Objects are integrated with the Service Module Functions 76a-76n. In particular, the writer of a Service Module Function 76a-76n configures the Service Module Function object or helper object to declare its metadata as a POMetaData object 715. When each Service Module Function 76a-76n sets values of persistent data objects, it invokes the mark Dirty method 708 to indicate that the values of the objects have changed. Each Persistent Object 80
has a metaData( ) method 714 that returns the POMetaData object 715, and implements a writeObject method 712 and readObject method 712 to write and read the persistent data.
In the preferred embodiment, the Dirty method 706 returns a Boolean value. The Boolean value is TRUE when the persistent data in the object has changed since the last load or store operation, and FALSE when persistent data in the object has not changed since the last load or store.
The Mark Dirty method 708 sets an object's "dirty" state to TRUE, i