US9049044B1 - Method of management and distribution of device adapters for element management systems - Google Patents
Method of management and distribution of device adapters for element management systems Download PDFInfo
- Publication number
- US9049044B1 US9049044B1 US11/393,409 US39340906A US9049044B1 US 9049044 B1 US9049044 B1 US 9049044B1 US 39340906 A US39340906 A US 39340906A US 9049044 B1 US9049044 B1 US 9049044B1
- Authority
- US
- United States
- Prior art keywords
- data
- network element
- cartridge
- generic framework
- engine
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 238000004891 communication Methods 0.000 claims abstract description 9
- 238000007726 management method Methods 0.000 claims description 57
- 238000013499 data model Methods 0.000 claims description 37
- 238000004422 calculation algorithm Methods 0.000 claims description 9
- 238000004590 computer program Methods 0.000 claims description 5
- 230000008878 coupling Effects 0.000 claims description 4
- 238000010168 coupling process Methods 0.000 claims description 4
- 238000005859 coupling reaction Methods 0.000 claims description 4
- 238000012545 processing Methods 0.000 claims description 4
- 238000013459 approach Methods 0.000 description 9
- 230000007246 mechanism Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 230000008676 import Effects 0.000 description 7
- 238000012986 modification Methods 0.000 description 7
- 230000004048 modification Effects 0.000 description 7
- 230000001419 dependent effect Effects 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000014509 gene expression Effects 0.000 description 4
- 239000000243 solution Substances 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000002708 enhancing effect Effects 0.000 description 3
- 230000002688 persistence Effects 0.000 description 3
- 238000010200 validation analysis Methods 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000000007 visual effect Effects 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000000051 modifying effect Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000004806 packaging method and process Methods 0.000 description 2
- 239000012086 standard solution Substances 0.000 description 2
- 230000001131 transforming effect Effects 0.000 description 2
- 230000007723 transport mechanism Effects 0.000 description 2
- KKIMDKMETPPURN-UHFFFAOYSA-N 1-(3-(trifluoromethyl)phenyl)piperazine Chemical compound FC(F)(F)C1=CC=CC(N2CCNCC2)=C1 KKIMDKMETPPURN-UHFFFAOYSA-N 0.000 description 1
- 235000006719 Cassia obtusifolia Nutrition 0.000 description 1
- 235000014552 Cassia tora Nutrition 0.000 description 1
- 244000201986 Cassia tora Species 0.000 description 1
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000012854 evaluation process Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000004807 localization Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
- H04L12/427—Loop networks with decentralised control
- H04L12/433—Loop networks with decentralised control with asynchronous transmission, e.g. token ring, register insertion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/022—Multivendor or multi-standard integration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0859—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
Definitions
- the present invention relates to the field of network equipment management, and more particularly to a method and apparatus for managing network elements.
- the thick client approach involves the creation of a custom piece of software (Element Manager) for the management of a particular device.
- Element Manager contains all of the knowledge of what data items are accessible for a particular type and version of the network element, how to present them to the user, and how to access them via a selected protocol.
- a problem that may arise with the thick client approach is that a separate thick client is required for each type of device, and potentially for each version of each type of device.
- a multitude of separate clients becomes difficult for the user to manage.
- a unified client can be created which supports all versions of all devices, but this will require frequent releases of upgraded Element Managers to the customers, which they must install regardless of whether they have the type of network element for which the upgrade was issued. It also requires the coordination of Element Manager releases between multiple network element projects and teams.
- the thick client approach makes it difficult to track and manage the element management software which is required for a given customer's network, and increases the likelihood of mistakes such as attempting to manage a device with the wrong Element Manager.
- the thin client approach involves having a very generic front end client (such as a web browser), and having all of the element specific knowledge embedded on the network element itself (for example in CGI scripts or Java Servlets running behind a web server).
- This approach offloads the issue of dealing with different device types and versions from the client; however, it introduces problems of its own. It places an increased burden on the network element's resources such as processing power, memory usage, etc.
- this approach requires greater client to network element messaging traffic, which increases latency at the user interface, particularly if the management is occurring across a slow connection such as a modem. It also makes it very difficult to enforce a standardized look-and-feel across different network elements.
- the present invention describes an apparatus and method which advantageously allows the content, presentation, and protocol necessary to manage a network element to vary over different types and versions of network elements, without requiring different clients to be used.
- the method and apparatus disclosed herein simplifies the distribution of network element specific element management software by making that software intrinsic to the element itself, but without requiring a separate Element Manager for each network element type. This eliminates the need to track and manage the versions of element management software which are required by different customers for their networks.
- the invention also simplifies the information flow between network element and element management client to the minimum necessary to convey the actual management data by offloading presentation functionality to the client, thereby enhancing the responsiveness of the user interface when compared with a thin client solution.
- the present invention makes it easier to install, maintain, and manage a variety of network elements (or versions of the same network element), which may come from a single supplier or be provided by multiple different suppliers.
- the present invention simplifies the distribution of Element Manager enhancements, essentially making it transparent to the network administrator, thus reducing the time spent managing versions of software.
- the present invention additionally eliminates the need to track, manage, and distribute the versions of element management software which are required by a particular customer for their network and eliminates network administrator mistakes such as attempting to manage a network element using the wrong version of Element Manager.
- the methods described herein may be performed by software in machine readable form which may be stored on a storage medium.
- the software which runs on or controls “dumb” or standard hardware, carries out the desired functions via use of a processor and therefore, essentially defines the functions of the register, and can therefore be termed a register, even before it is combined with its standard hardware.
- HDL Hardware Description Language
- a network element management system for managing network elements in a communication network.
- the system includes a storage unit for storing one or more cartridges, where the cartridges contain network element-specific information, and a generic framework for managing the one or more network elements via use of the one or more cartridges.
- the storage unit also includes a processor for using the one or more cartridges and the generic framework to manage the one or more network elements.
- the present invention provides a method of managing network elements in a communication network.
- the method includes the steps of coupling a generic framework to a selected network element, and querying the network element to determine the identity of an element-specific cartridge, the cartridge containing network element-specific information.
- the framework connects to and manages the selected network element via use of the installed cartridge.
- the present invention provides a storage medium storing a computer program which, when executed by a processing unit, performs a method for managing network elements in a communication network.
- the method includes the steps of coupling a generic framework to a selected network element, and querying the network element to determine the identity of an element-specific cartridge, the cartridge containing network element-specific information, and determining if the generic framework contains the cartridge.
- the framework connects to and manages the selected network element via use of the installed cartridge.
- FIG. 1 is a schematic diagram of the element management apparatus of the present invention
- FIG. 2 is a simple flow diagram of the element management method of the present invention
- FIG. 3 is a high-level view of the framework architecture of the element management method of the present invention.
- FIG. 4 shows a more detailed level view of the framework architecture shown in FIG. 3 ;
- FIG. 5 is a schematic diagram of the data engine interactions of the present invention.
- FIG. 6 is a schematic diagram that represents relations between components of the presentation layer, the data engine and the transport adaptor.
- FIG. 7 is a screen shot of an exemplary graphical user interface incorporating the present invention.
- Embodiments of the present invention are described in the figures by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the Applicant, although they are not the only ways in which this could be achieved.
- the invention disclosed herein provides a means for allowing a single generic thick client to be used as an Element Manager for a variety of heterogeneous network elements. It does this by encapsulating all of the network element specific presentation and messaging functionality into a single bundle called a “cartridge”. The contents of the cartridge vary from one type of network element to another, and across different versions of the same network element.
- FIG. 1 shows a simple schematic diagram of an element management apparatus according to the present invention.
- the client which is also referred to as the Framework 101 , is generic, i.e., it can be used to manage any network element and is not specific to any type of element.
- Framework 101 is defined as a set of software components that are used to build element management systems.
- Framework 101 may contain several functional blocks, such as the GUI (Graphical User Interface) Engine 102 , which manages all components responsible for user interaction and presents a unified graphical user interface across different element types, the Data Engine 103 , which maintains a “data model”, i.e., a temporary representation of the managed network elements and which manages the retrieval and update of management data with the network elements, and the Transport Engine 104 , which provides a consistent API (Application Program Interface) for the storage and retrieval of data, independent of the protocol or other means used to perform the operation.
- “Data model” is defined as a temporary storage of a device's configuration data within the management system.
- the Framework 101 also includes the software (not shown in FIG. 1 ) for managing the network element-specific Cartridge 105 .
- the Element Manager Framework 101 has the ability to connect to and manage a variety of network element types with the aid of the device specific cartridge.
- “Cartridge” is defined herein as a software module containing all device specific functionality.
- Cartridge 105 is dynamically or statically loaded by the Framework 101 to enable configuration of a specific platform or version.
- the Cartridge 105 provides the Framework 101 with the element specific information and comprises all aspects of element management which are specific to a particular network element.
- Cartridge 105 may contain several elements, such as the View Specification 106 , which describes the look and behavior of the GUI.
- View Specification 106 is a description of the user-facing components of the model (also referred to as the UI model).
- Cartridge 105 may also contain a Data Model Definition 107 , which is a specification of the nature and the structure of that data.
- Data Model Definition 107 describes the device components, the relationship between these components, and a specification of the data which may be viewed or modified on the network element. “Device” shall be defined herein as a network element, or physical entity being provisioned, monitored or configured.
- Cartridge 105 may also include a Protocol Choice 108 , which details the protocol which should be used to communicate with the network element and is capable of converting a generic request to retrieve or modify specific data items on the device into network element-specific protocol interactions with the device.
- Protocol Choice 108 may either be an indication of what protocol to use, or an actual implementation of the protocol.
- This implementation of Cartridge 105 allows the protocol, Data Model Definition 107 , and presentation to vary as required between different types of network elements.
- Cartridge 105 may comprise code or, alternatively, Cartridge 105 may comprise a high level description rather than code. The use of high level description rather than code is beneficial because it makes Cartridge 105 more compact.
- Framework 101 can be shipped with or without Cartridges 105 as described below.
- Cartridge 105 is a “read-only” source of information for Framework 101 .
- Framework 101 and Cartridge 105 are each described in greater detail below.
- FIG. 2 shows a simple flow diagram of an element management method according to the present invention.
- the first step is to query the network element to determine the identity of the Cartridge 105 which is needed to manage the device (step 202 ).
- the identity of the Cartridge 105 may be specified, for example, by an identifier or by the combination of a cartridge identifier and a version identifier.
- the client determines whether it already has this Cartridge 105 (step 203 ) in which case it merely uses it (step 204 ), e.g., it automatically starts running the required Cartridge 105 , without requiring any user interaction.
- Cartridge 105 in the case where Cartridge 105 is not already present in the client, it will proactively obtain and install the necessary Cartridge 105 (step 205 ). This may again be without requiring any user interaction, or it may require a simple confirmation (e.g. OK/Cancel dialog boxes) by the user.
- Cartridge 105 may be obtained, for example, by downloading it from the network element in question, or from a web server or from any other suitable source. Cartridge 105 could alternatively be provided with the equipment on a computer readable medium.
- the element management Framework 101 may contain cartridge management software which performs the checks as to whether it has that Cartridge 105 .
- Cartridge 105 The method described above guarantees that the correct version of Cartridge 105 is always used to manage a particular network element. It also means that there is no need to manually, or by any other process, track the version of element management software which is required by different customers for their networks. Customers will automatically have the correct version of software to manage the equipment which is installed in their networks.
- that client may be used to manage multiple different device types and/or device versions without requiring Cartridge 105 to be downloaded each time the device type or version is switched. This minimizes the time required to switch between network element types and versions.
- Framework 101 can be designed to contain most (e.g. about 90%) of the software required for the Element Manager, with only a small proportion being network element specific and provided in the Cartridge 105 . This results in a quick download time when the Framework 101 accesses the Cartridge 105 for the first time.
- FIG. 3 contains high-level view of the framework architecture. Note that a system built from Framework 101 may exist as a single process or as a client/server application.
- a Presentation Layer 301 manages all components responsible for user interaction. It creates and maintains control widgets in the menu and toolbars, and creates context switching panels, tree views, table views and tabbed details views. Presentation Layer 301 provides for creating and supporting multiple views for the same data. Presentation Layer 301 consists of the modules provided by Framework 101 , but can be extended with elements defined in device specific Cartridges 105 . Presentation Layer 301 is driven, in part, by the View Specification 106 from the device-specific Cartridge 105 .
- Data Engine 302 maintains a “data model”, i.e., a temporary representation of the managed network elements.
- Data Engine 302 creates the data model based on the information provided via configuration protocol or retrieved from off-line database.
- Data Engine 302 manages the modification of the data model, which involves creating new objects, deleting existing objects, modifying properties of the objects, and invoking operations on the objects.
- Objects are defined herein as an instance of a particular class in the data model, containing values for each of the fields of that class. Each class may have zero or more instances.
- Data Engine 302 handles initial verification and validation of user actions. Data Engine 302 is driven, in part, by the Data Model Definition 107 from Cartridge 105 .
- Services registry 304 is a software bus allowing for registering services extending Framework 101 .
- the services registry interface provides a mechanism for naming services and also provides a mechanism for looking up services and obtaining handles to services in a location-independent way. This provides an abstraction that allows clients to look up services and obtain handles to services for both in-process (local) and out-of-process (remote) cases. Such an abstraction is useful for systems built as client/server applications.
- Application Loader 305 is the component that assembles the management application when it is launched.
- Application Loader 305 uses application description provided by developers to select and initialize the data engine and establish the Presentation Layer 301 . It connects additional services by locating them and registering them with service registry.
- FIG. 4 shows a more detailed level view of the architecture shown in FIG. 3 and is described below with additional reference to FIG. 7 , which shows a screen shot of an example GUI.
- the arrows in FIG. 4 represent the control flow in the user Interface (UI). Selecting “Context” determines the structure of the tree, and selecting “Tree Node” determines what is displayed in the data panel.
- Menu 401 and Toolbar 402 contain both framework-related elements displayed in all context and context-specific elements that are only displayed if their context is selected.
- Context Selector 403 is the highest level of application control. Selecting the context influences the appearance all other elements of the UI.
- On-line configuration, off-line configuration and configuration wizards are possible examples of different contexts.
- an “on-line configuration” designates an application that provides immediate usage model. User modifications to the UI are applied to the device either immediately or on demand. WEB-based solutions are usually examples of on-line configuration. The on-line system cannot function without live connection to configured device.
- An “off-line configuration” designates an application that operates in import, modify, export modes. The user operates on a copy of a configuration data, and changes are applied as a part of a scheduled action. Configuration data is verified without real device participating in the process. An off-line system is useful for large-scale configuration modification. It does not provide monitoring capabilities since it does not require live connection to configured devices.
- Hierarchy Panel 404 provides a basic navigation mechanism that allows for the selection of functional areas or specific configuration objects. The structure of Hierarchy Panel 404 depends on the network element currently being managed
- Data Panel 701 displays configurable data.
- a small number of standard layouts are provided, such as a list browser.
- the number of standard layouts may be intentionally kept small in order to promote a uniform look and feel.
- the standard layouts can be customized and extended by code included in a device-specific Cartridge 408 .
- the Details Panel 405 is a subset of the Data Panel 701 which, in the example shown in FIG. 7 , shows the information pertaining to the Row 702 selected in the table shown in the top half of Data Panel 701 .
- some panels may not be displayed.
- the context panel may not be displayed if only one context is registered.
- the menu/toolbar, Data Panel 701 and status bar are likely to be displayed all or most of the time.
- the GUI Engine 406 interprets View Specification 407 (from Cartridge 408 ) and builds models and views for all the visual elements.
- the GUI Engine 406 is responsible for maintaining all main window panels and GUI widgets.
- the GUI Engine 406 instantiates Data Panels 701 , menu bar elements and status bar elements.
- the general working of GUI Engine 406 follows the model-view-controller pattern.
- GUI Engine 406 provides a view and a controller part. It creates model elements based on data model references contained in View Specification 407 .
- GUI Engine 406 is extensible. More specifically, pluggable services provide contexts that take control of the menu bar, status bar and Hierarchy Panel 404 .
- GUI Engine 406 offers built-in support for a small number of standard Data Panel 701 layouts including a simple panel and a list browser.
- a simple panel displays data contained in multiple tabbed panes. Each tab can have a different layout that can be selected from layouts provided by GUI Engine 406 or defined explicitly by Cartridge 408 .
- a List Browser includes a table in the top half (with optional tabs) and an optional details panel in the lower half of the Data Panel 701 . It also includes an optional “Filter” area that allows the user to choose which objects to display in the table. The selection in the table determines the contents of the details panel below it.
- GUI Engine 406 provides an extension mechanism that allows View Specification 407 writers to modify a standard layout or to define custom layouts.
- View Specification 407 contains references to a Data Model Definition 409 . These references enable the GUI Engine 406 to interact with the Data Engine 302 in order to retrieve and update the configuration data that is displayed on the screen.
- GUI Engine 406 can display multiple Data Panels 701 concurrently. Multiple windows can be displayed, presenting data in the same or different data objects.
- the View Specification 407 language fulfills two tasks: describing navigation patterns, and describing the layout of Data Panels 701 .
- Navigation parts of the language describe what elements are represented as tree nodes in Hierarchy Panel 404 and what are placed in the Data Panel 701 . They also describe the navigation hierarchy. Each level of the hierarchy is defined by providing a way of constructing it; i.e., class of components visible on this level or the description of the operation that needs to be called to retrieve the components from the Data Engine 302 . Purely navigational components that do not have to be retrieved from Data Engine 302 are also defined in the hierarchy view.
- the invention allows for specifying if components on that level are displayed in Hierarchy Panel 404 or in the Data Panel 701 .
- Each component can be conditionally hidden. Conditions for visibility of components are based on information received from the Data Engine 302 .
- Panel description parts of the language specify which fields are displayed on which panel, and what layout should be used to display these fields.
- a “field” is defined herein as the smallest configurable data item provided by a device and accessible through the configuration protocol.
- Each component can have a set of panels. Each panel has a title and panel description that contains a set of operations that are available when the panel is displayed, for example, Refresh (all panels) or Apply (for panels that do not have auto-submit functionality).
- Each panel is composed of sections. Sections roughly correspond to Group GUI widget, however, they do not have to be visible for the end user. By default, sections are laid out vertically, but other arrangements can be specified. Every section may, optionally, include a title. There are several types of sections including, for example, but not limited to, a section that displays fields in multi-column fashion or in a grid. Additionally, new types of sections can be defined by Cartridges 408 .
- Data Engine 302 Every section or the entire panel can also be hidden. Conditions for visibility of sections and panels are based on information received from Data Engine 302 .
- Data Engine 302 is at the center of the architecture. It provides transport, presentation, localization and an independent way of accessing, modifying, retrieving and storing of device data. Because the exact structure of the data is device specific, Data Engine 302 provides just the strategies and algorithms for handling the data, leaving the description of the data schema, its visual elements and transport adaptors to be specified by device dependent Cartridges 408 .
- Data Engine 302 communicates with the external world by allowing the presentation layer and the transport layer to create adaptor components. In the case of GUI access, these translators reside in the presentation layer and constitute data models in a sense of model-view-controller patterns. All presentation layer adaptors access the data through the Data Engine API 410 . All transport adaptors support Transport Adaptor API 414 , which Data Engine 302 uses to interface with the device (or database). Each data object in Data Engine 302 can have multiple presentation models. However, only one transport adaptor is connected to it at any given moment. The specific implementation may allow for switching transport adaptors on the fly and thus allowing Data Engine 302 to transport configuration data, for example, between a database and the real device. A single Data Engine 302 may be used in all contexts; however, different cartridges used in different contexts would usually result in a different data kept by the engine.
- Rules Engine 411 includes description that should be viewed as a functionality description only; designers of Data Engine 302 may choose to incorporate this functionality directly in data object or choose yet another solution.
- the data cache or Data Model 412 is a store for all objects and associations representing a configured device. It is created based on the information retrieved by transport adaptors directly from the device or from the database. Data Cache 412 provides a querying mechanism allowing other services to obtain the list of all objects, the list of objects of a specific class, or a specific object if a unique identifier of this object is provided.
- the data engine implementation does not have to keep all data objects active and instantiated in memory at all times.
- the object or associations can be instantiated when requested by other modules or services.
- the Model Builder 413 is the module that externalizes the algorithm of building a data object in the data cache. It contains the factories for all data objects and executes algorithms for querying the device or database. Model Builder 413 is driven by the data model definitions provided in the device cartridge.
- Navigation and Data Panel Builders 501 , 502 are modules that are responsible for creating models for visual representation of the data.
- the Navigation Builder 501 creates hierarchy models that are later displayed as trees or browsing tables.
- the Panel Builder 502 creates models for panels and fields. Both builders are driven by the GUI description language.
- Rules Engine 411 is used to evaluate rules, expressions and conditions defined in the data model. During the evaluation process, Rules Engine 411 may require some additional information that is retrieved from the device or from the database. One of the applications of Rules Engine 411 is ensuring data consistency.
- Data Engine 302 receives requests to change data values, it requests the Rules Engine 411 to verify if the change is acceptable.
- Rules Engine 411 invokes the set of rules specified in Cartridge 408 , for example, in either model definition language or Java. Only if none of the rules vetoes the change is a new value accepted by the engine.
- the Transport Adaptor 414 (in Cartridge 408 ) mediates between the Data Engine 303 and the transport protocol. Again, this could be merely an identifier for a protocol, or an actual implementation of a protocol. Separate transport adaptors can be provided for each transport protocol. Transport Adaptor 414 encapsulates all transport-related dependencies between data. It retrieves transport dependent identifiers from the object and fields, re-orders parameters, translates between internal and “wire” representation of values if necessary, handles transaction and error notification making all protocols appear in the same way to the data engine. Transport Adaptor 414 is extensible in the same way as Navigation Builder 501 or Model Builder 413 .
- Transport Adaptor 414 There is a continuum of how much of the implementation of Transport Adaptor 414 needs to be in Cartridge 408 ; anything from a mere identifier to a complete implementation. If a Transport Adaptor 414 is identified (rather than implemented) in Cartridge 408 , and Transport Protocol Manager 419 does not have it, it can be retrieved in a similar manner to the way that the cartridge management works.
- the data objects and associations contained in the engine are instances of objects and associations described in the device model.
- the data objects represent physical or logical entities of the managed device. Interface, routing protocol, user, and tunnel are just few examples of concepts that can be represented by a data object in the Data Engine 303 . Associations represent relations between such entities. Associations always contain references to two or more data objects. Containment (as a relation between physical interface and logical sub interfaces or between users and group of users) is an example of association.
- Data objects contain fields and operations. Values of the fields can be set and retrieved and operations can be invoked. Operations fall into two categories, local and remote. Local operations are specified in the data model and are executed by the data engine. Remote operations are executed by sending invoke commands to the device.
- the Data Engine 302 is isolated from the details of the transport protocol through Transport Adaptor 414 . In most cases, the same Transport Adaptor 414 will be used for all data objects but, if necessary, each data object can have its own distinct Transport Adaptor 414 .
- a data object is referenced by one or more GUI models that exist in Presentation Layer 301 .
- FIG. 6 shows a diagram which represents relations between components of the Presentation Layer 301 , the Data Engine 302 , and the Transport Adaptor 414 . It does not imply any specific implementation of the data object and its fields.
- the Data Engine API 410 provides for setting and retrieving information in the Data Engine 303 . Pluggable services are able to set and get the field values, invoke operation, trace association between data objects, and create and destroy data objects and associations. Operations that retrieve collections of data objects are also provided. They support capabilities of querying Data Engine 302 for all objects of specific class.
- Data Engine API 410 also provides capabilities of observing the specific data object and notifying whenever its status changes. Data Engine API 410 follows observer pattern, i.e., clients register to be notified when an interesting piece of data changes. Data Engine API 410 is specifically designed to be optimal and efficient for pluggable services and for the UI layer.
- the purpose of the data modeling language is to describe the managed device configuration and monitoring capabilities in such a way that this knowledge becomes accessible to Data Engine 302 .
- the data modeling language role is similar to that of SMI/MIB (Structure of Management Information/Management Information Database) in SNMP (Simple Network Management Protocol) and MOF (Managed Object Format) in CIM (Common Information Module).
- the data modeling language should not be dependent on any transport protocol used for device configuration, though it needs to provide information that will be used by such protocol to access and modify device configuration.
- Concepts that may be expressed in this language include components of the managed device such as types and associations, fields for each of the components such as string, integer, and enumeration, constraints such as range for integers, length or regular expression for strings, the operation available for each component (including parameters and return values for each operation), access-level for each field (i.e., not-accessible, read-write, read-only, write-only, write-once), identifiers or other information required by configuration protocol, keys and their format for non-scalar components and other qualifiers such as the add-ability for object and associations, delete-ability, enumeration constraints, instance list filters and instance list labels.
- the preceding items can be static or dynamic. Dynamic items are expressed as a result of invoking local or remote operation.
- the modeling language provides for inheritance to allow for easier enhancing of existing descriptions.
- the modeling language allows for specifying dependencies between the components and between the fields. For example, it may provide for expressing the notion that access-level of the field may depend on the value of some other field. It is left to the language designer to determine which dependencies are directly supported in a modeling language and which are expressed as extensions written in a programming language such as Java.
- the Pluggable Service Registry 304 provides a mechanism for registering services with a central directory. Registering a service makes it accessible from external and internal customers. Specifically, it makes a service accessible to other services. Service declarations are specified via an XML (Extensible Markup Language) descriptor file. The name-service binding, the service type and other service parameters are specified in the service descriptor. Service customers can connect to the service by identifying it with a name and obtaining a handle to a specific instance of a particular service.
- XML Extensible Markup Language
- the Presentation Layer 301 and the Data Engine 302 described above may be implemented as pluggable services but this is not required. Achieving the most efficient implementation of both GUI Engine 406 and Data Engine 302 is the deciding factor.
- pluggable services There are two types of pluggable services, namely, Application-Level Services 415 and Session-Level Services 416 . This classification is described in more detail below. Pluggable services can also be classified as Core services and Optional services, and this distinction is also described below.
- Application-Level Services 415 are created at start-up by the application loader and remain resident until explicitly closed.
- One instance of an Application-Level Services 415 is shared by all consumers.
- Application-Level Services 415 are re-entrant, however, they do not have to be, and generally are not accessible remotely (out-of-process).
- Application-Level Services 415 do not provide for storing customer state or session state data. Examples of application-level services include Access List Service 418 , Naming and Directory Service 417 , Cartridge Manager 421 , Scheduling Service 424 , Logging Service 422 , Transport Protocol Manager 419 , Database Service, Application Service 423 and Recognition Service 420 .
- Session-Level Services 416 are services that contain information specific to the consumer that is using the service. Each service instance is created by the client that will use the service, and may contain specific information relevant to the particular client request. For instance, an element management service (session) may be instantiated for a particular device, given the IP address of that device. This session would be different to an element management session on another device, and thus, a separate instance for each “client” using the service is necessary. Examples of Session-Dependent (or session-level) Services 416 are Element Management Session, File Management Service 426 , Export/Import Service 427 , and Comparison Service.
- Small management applications and full management applications are constructed by packaging the Framework 101 and a set of pluggable services. Some services are common to both the small and the full product. Some of the services can be optionally distributed. There is a core set of services that has to be part of all products, and there are some optional services that can be provided only if the product requires additional functionality. Examples of core services may include Naming and Directory service 417 . Pluggable Service Registry 304 uses the naming service to locate the service handle based on a registered name. This service is used to isolate the task of locating other services and thus reduces the dependencies between services and allows for location and execution transparency. Another example of core services may include the Naming and Directory Service, which implement one of the industry APIs, such as Java Naming and Directory Interface (JNDI).
- JNDI Java Naming and Directory Interface
- Access Point List Service 418 provides storage for the access point lists. It allows other services to list, create and delete access points. Only one access point list service is present and active at any given moment. Several different implementations of this service are possible. At least one lightweight implementation should not require the database (DB) management system to provide storage capabilities.
- DB database
- Transport Protocol Manager 419 is another exemplary core service. At the minimum, a single configuration protocol (which may also be called a transport protocol), needs to be available for transporting communication information to and from the device. This protocol is actually an application protocol from the OSI model. However, it is used to “transport” the data to the device (hence it sometimes referred to as a transport protocol). Legacy support protocols such as SNMP or CLI are also supported with the use of pluggable transport protocol modules. The transport protocol manager facilitates the discovery and use of these protocols.
- Recognition Service 420 is yet another core service example.
- Cartridge Manager 421 requires certain information about device type, installed software and supported configuration protocol before it can choose which cartridge should be used to manage the device. All devices supported by Framework 101 need to be able to provide basic information about device hardware and software version, or some other information which will enable identification of the correct cartridge to be used. The task of the recognition service is to obtain this information from the device.
- Recognition Service 420 may be enhanced using modules that support specific boot-strap protocols.
- the first step requires gathering information about the device type and version of the software installed on the device. This information can be provided by the user or retrieved from the device with the help of the recognition service (see above).
- the second step involves downloading the cartridge from the device itself, or from externally available on-line repository. The cartridge that is the best match for a device is subsequently chosen and used to manage the device. Matching the cartridge to the device, loading the cartridge, and distributing its parts to the services that are extended by the specific cartridge are the most important functions of cartridge manager.
- Logging Service 422 is still another exemplary core service. Logging Service 422 is used by all remaining services to provide a configurable logging functionality. Services register with Logging Service 422 as either producers or consumers of logging entries. Each entry contains the specification of severity, category and event description. Logging Service 422 can be configured to provide permanent storage only for entries with a specific category or severity. Log consumers can request Logging Service 422 to filter the entries based on a similar set of criteria. Consumers of Logging Service 422 are offered both access to historic log data, as well as on demand notification mechanism for current events. The functionality of Logging Service 422 is used by other services in Framework 101 and not by the device. It should not be mistaken with functionality provided by SYSLOG and similar services. The Logging Service 422 may follow industry standard solutions such as the Java Logging API introduced in JDK 1.4.
- the Application Service (“Element Manager”) 423 provides the main thread of control. It displays the main window, instantiates context plug-ins. and binds together other services that comprise the management application.
- Application Service 423 determines the personality of management application. One service implementation is required for light weight, one context, on-line application, and another service implementation for the full client-server application that also supports off-line configuration.
- the Application Service 423 is a module that takes control after the application loader registers and initializes all services enumerated in the application descriptor.
- Examples of optional services may include a Persistence Service 425 .
- the Database Management Service is offered to provide support for off-line storage of configuration information. Persistence Service 425 is not directly accessed by the data engine. Instead, the database adaptor that implements the same interface as other transport adaptors handles the details of transforming the on-line configuration data into the off-line database representation.
- the Database service interface may follow industry standard solutions such as Java Data Base Connectivity (JDBC).
- Import/Export Service 427 is another example of an optional service. Bulk data transfer between Persistence Service 425 and network elements is handled by Import/Export (or Export/Import) Service 427 . This service may be extended by the cartridge to allow for variations between different device types. The Import/Export Service 427 should use the device's on-line Transport Adaptor 414 to exchange data with the device.
- File Management Service 426 allows for transferring all types of files between a local file system and the device file system.
- File Management Service 426 offers several transfer protocols that might include TFTP, FTP or a Network File System. Service customers need to specify the location and the destination of the file—only protocol dependent operations are handled by the service.
- File Management Service 426 is used for configuration backup, image and configuration update, log files transfer, and others requiring transfer of data files.
- Scripting Service 428 exports the public interfaces of other services in the form of command line scripting language similar to Bourne shell. Scripting Service 428 should not be mistaken with CLI that may be offered by network element. Scripting Service 428 is used for controlling (e.g., automation of) applications. It can be used internally for testing automation and externally for the purpose of extending and automating configuration capabilities. This service provides the command line interface to the management application.
- Scheduling Service 424 provides other services with a capability of executing specified operations periodically or once at a specified point in time. Customers register schedules (a sequence of points in time) and details of the operation that should be performed. Scheduling Service 424 can be used for both one time events (such as a software upgrade) and periodic events (such as a weekly configuration backup).
- FIG. 4 also shows a Cartridge 408 .
- elements which may be included in a cartridge include View Specification 407 , Data Model Description 409 , Transport Adaptors 414 , and Algorithms for Optional Services 429 .
- View Specification 407 is expressed in the view specification language with optional extensions in Java. This describes navigation and contents of the Hierarchy Panel 404 and Data Panel 701 .
- Data Model Description 409 is expressed in the data modeling language with optional extensions in Java.
- the Data Model Description 409 describes the device components and relationships between these components.
- the data model part of the cartridge is used to drive data engine.
- Transport Adaptors 414 are classes that encapsulate transport specific properties of data object models. Transport Adaptors 414 allow for transformation of object representation from the internal data engine format into the format accepted by the transport mechanism. However, the cartridge does not necessarily contain the transport protocol implementation. By providing transport adaptors it allows the data engine to bind each object to the required transport protocol, i.e., it can contain the transport protocol implementation or alternatively a reference to the transport protocol to be used. This is more efficient as many elements may use the same transport protocol. Where Transport Adaptor 414 includes a reference to the protocol, Framework 101 may check whether it already has the required protocol implementation information and, if not, Framework 101 can obtain the information from a web site, central server or other suitable source.
- Algorithms for Optional Services 429 contain algorithms for transferring data between the data base and real device.
- the behavior of the management application is determined by the set of device-specific cartridges.
- Cartridge developers employ mostly declarative approach, i.e., describing the properties of the managed device (such a supported configuration parameters and their dependencies). Only selected cases (extensions) are separately coded in imperative.
- the role of Framework 101 is to interpret this description and provide management support for the device.
- the modeling stage includes describing the management capabilities of the device, describing all the device components, such as the configuration and statistics fields, describing the verification rules and the relationships between components and fields, and grouping fields and defining views.
- the stage of model enhancement includes the rules, views and dependencies that cannot be expressed in declarative way and are expressed in Java.
- the cartridge generation stage involves applying a tool that parses, compiles and packages model description and model enhancement into cartridge software module.
- the deployment stage includes packaging the set of cartridges, pluggable components and Framework 101 into element management application or, alternatively, installing cartridges on devices for automatic deployment or installing them at a central resource for access by Framework 101 when required.
- a first scenario involves starting the management application, for an on-line scenario.
- Application Loader 305 instantiates Pluggable Service Registry 304 and Naming and Directory Service 417 .
- Application Loader 305 locates, instantiates and initializes all application level services specified in the application description files.
- Application Loader 305 instantiates Application Service 423 and passes control to it.
- Application Service 423 locates GUI Engine 406 and the presentation engine.
- Application Service 423 creates an application main window, locates all context services and request adding context based UI elements. The default context is also requested to provide hierarchy panel GUI.
- Application Service 423 then starts an UI user thread.
- Application Service 423 retrieves the list of configuration protocols from Transport Protocol Manager 419 , in which each protocol may have a different set of required access information.
- Application Service 423 then solicits protocol-dependent access information (for example IP Address, user name password, certificate etc.) from the user.
- Recognition Service 420 communicates with newly added device and retrieves device type, software and hardware version and other hints that facilitate selection of proper cartridge.
- Optional Recognition Service 429 then downloads the cartridge from the device.
- Cartridge Manager 421 selects the cartridge that will be used to manage the device from the set of cartridges statically distributed with Framework 101 or downloaded from the device or from well-known network location.
- GUI Engine 406 processes the GUI navigation description from the cartridge and creates navigation models.
- Cartridge Manager 421 then initializes GUI model builders provided by the cartridge, and the GUI model builders request information from Data Engine 302 .
- Data Engine 302 initializes the model builder provided by the cartridge.
- the model builder instantiates Transport Adaptor 414 for each data object that it needs to create.
- the “model builder” refers to the mapping between data object type and Transport Adaptor 414 in order to instantiate a proper transport adaptor.
- the model builder attaches Transport Adaptor 414 to newly created data objects and initiates configuration data retrieval. Once data objects are initialized, information is returned to GUI Engine 406 . GUI Engine 406 then creates UI models and displays data panels based on the selected hierarchy components.
- a new device can be added in an off-line setting.
- Application Service 423 retrieves the list of supported devices types and presents users with an option to select a specific device type.
- GUI Engine 406 processes a GUI navigation description from the cartridge and creates navigation models for a newly selected device
- Application Service 423 GUI Engine 406 then initializes GUI model builders provided by the cartridge and the GUI model builders then request information from Data Engine 302 .
- Data Engine 302 initializes a model builder provided by the cartridge where the model builder instantiates a database transport adaptor for each data object that it needs to create. Once data objects are initialized, information is returned to GUI Engine 406 .
- GUI Engine 406 creates UI models and displays data panels based on the selected hierarchy components.
- Presentation Layer 301 Another scenario involves the modification of a parameter in an on-line context.
- the user changes the field value and GUI Engine 406 controls the Presentation Layer 301 , which performs basic field level validation (enumeration field, regular expression or range checking). This validation is limited to the capabilities of the UI widget.
- Presentation Layer 301 translates between UI representation and data-engine representation of the data (this step involves, among other things, resolving localized names), calls a data engine function, and passes new field values.
- Data Engine 302 then validates the data by executing all rules associated with the modified data item. If new data item cannot be approved, GUI layer is notified, and data is not sent to the device. Data Engine 302 then calls Transport Adaptor 414 to send the new value to the device. If necessary, Transport Adaptor 414 calls a transport protocol after translating the values to protocol-dependent format. The device accepts or rejects the change. In case of errors, Data Engine 302 is notified through Transport Adaptor 414 . GUI Engine 406 provides feedback about the success or failure of the operation based on information received from Data Engine 302 .
- Another scenario addresses the modification of a parameter in an off-line context. Modification of the value in an off-line context is similar to an on-line context. The difference lies in special transport adaptors that are connected to the database and not to the transport protocols. Transferring data between a database and devices may use an export/import mechanism that does not have to involve Transport Adaptors 414 or Data Engine 302 .
- Java due to the wide availability of libraries and tools, especially in the realm of network-related applications and the requirements of support for diverse set of operating system, including Unix-based systems.
- Other Java-related technologies and specifications may also be used in designing Framework 101 including, but not limited to, JDBC, JNDI and Enterprise Java Beans (EJB).
- a suitable data description language is XML and it is possible to use a domain-specific syntax.
- XML is an appropriate language because of its extensibility, good support in Java environment, abundance of parsing and transforming tools, and industry support for XML-based standards. Its self-documenting features, i.e., support for schemas describing syntax and context relationships, are also a useful aspect.
- Framework 101 is preferably protocol independent. The architecture provides for pluggable protocol stacks and protocol adaptors that encapsulate protocol-specific code, and hide the differences between protocols from the rest of Framework 101 .
- RPC-based, lightweight protocol is a suitable solution for element configuration.
- An example of a data schema (part of a Data Model) and an example of a view specification for an exemplary managed element is provided in U.S. Provisional Patent Application Ser. No. 60/679,896, filed May 11, 2006 entitled M ETHOD OF M ANAGEMENT AND D ISTRIBUTION OF D EVICE A DAPTERS FOR E LEMENT M ANAGEMENT S YSTEMS , the entirety of which is incorporated herein by reference.
- the present invention can be realized in hardware, software, or a combination of hardware and software.
- An implementation of the method and system of the present invention can be realized in a centralized fashion in one computing system, or in a distributed fashion where different elements are spread across several interconnected computing systems. Any kind of computing system, or other apparatus adapted for carrying out the methods described herein, is suited to perform the functions described herein.
- a typical combination of hardware and software could be a specialized or general purpose computer system having one or more processing elements and a computer program stored on a storage medium that, when loaded and executed, controls the computer system such that it carries out the methods described herein.
- the present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein and which, when loaded in a computing system, is able to carry out these methods.
- Storage medium refers to any volatile or non-volatile storage device.
- Computer program or application in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function, either directly or after either or both of the following (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form.
- all of the accompanying drawings are not to scale.
- this invention can be embodied in other specific forms without departing from the spirit or essential attributes thereof and accordingly, reference should be had to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Stored Programmes (AREA)
Abstract
Description
Claims (15)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/393,409 US9049044B1 (en) | 2005-05-11 | 2006-03-30 | Method of management and distribution of device adapters for element management systems |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US67989605P | 2005-05-11 | 2005-05-11 | |
US11/393,409 US9049044B1 (en) | 2005-05-11 | 2006-03-30 | Method of management and distribution of device adapters for element management systems |
Publications (1)
Publication Number | Publication Date |
---|---|
US9049044B1 true US9049044B1 (en) | 2015-06-02 |
Family
ID=53190775
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/393,409 Active 2031-12-06 US9049044B1 (en) | 2005-05-11 | 2006-03-30 | Method of management and distribution of device adapters for element management systems |
Country Status (1)
Country | Link |
---|---|
US (1) | US9049044B1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140359258A1 (en) * | 2013-06-02 | 2014-12-04 | Microsoft Corporation | Declarative Configuration Elements |
US20150019199A1 (en) * | 2013-07-09 | 2015-01-15 | Allied Telesis Holdings Kabushiki Kaisha | Command line interface |
CN105389253A (en) * | 2015-10-19 | 2016-03-09 | 烽火通信科技股份有限公司 | Method and system for simulating client to execute network element management based on multithreading technology |
US10565705B2 (en) | 2011-09-25 | 2020-02-18 | Theranos Ip Company, Llc | Systems and methods for collecting and transmitting assay results |
US11582098B1 (en) * | 2021-11-09 | 2023-02-14 | At&T Intellectual Property I, L.P. | Mechanized modify/add/create/delete for network configuration |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030065755A1 (en) * | 2000-05-29 | 2003-04-03 | Seiko Epson Corporation | System of automatically fetching contents present on network |
US20030120822A1 (en) * | 2001-04-19 | 2003-06-26 | Langrind Nicholas A. | Isolated control plane addressing |
US20060101456A1 (en) * | 2004-10-18 | 2006-05-11 | Microsoft Corporation | Method and system for configuring an electronic device |
US7685257B2 (en) * | 2003-11-10 | 2010-03-23 | Sun Microsystems, Inc. | Portable thin client for the enterprise workspace |
-
2006
- 2006-03-30 US US11/393,409 patent/US9049044B1/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030065755A1 (en) * | 2000-05-29 | 2003-04-03 | Seiko Epson Corporation | System of automatically fetching contents present on network |
US20030120822A1 (en) * | 2001-04-19 | 2003-06-26 | Langrind Nicholas A. | Isolated control plane addressing |
US7685257B2 (en) * | 2003-11-10 | 2010-03-23 | Sun Microsystems, Inc. | Portable thin client for the enterprise workspace |
US20060101456A1 (en) * | 2004-10-18 | 2006-05-11 | Microsoft Corporation | Method and system for configuring an electronic device |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10565705B2 (en) | 2011-09-25 | 2020-02-18 | Theranos Ip Company, Llc | Systems and methods for collecting and transmitting assay results |
US11257215B2 (en) | 2011-09-25 | 2022-02-22 | Labrador Diagnostics Llc | Systems and methods for collecting and transmitting assay results |
US20140359258A1 (en) * | 2013-06-02 | 2014-12-04 | Microsoft Corporation | Declarative Configuration Elements |
US10606569B2 (en) * | 2013-06-02 | 2020-03-31 | Microsoft Technology Licensing, Llc | Declarative configuration elements |
US20150019199A1 (en) * | 2013-07-09 | 2015-01-15 | Allied Telesis Holdings Kabushiki Kaisha | Command line interface |
US11216293B2 (en) * | 2013-07-09 | 2022-01-04 | Allied Telesis Holdings Kabushiki Kaisha | Command line interface |
CN105389253A (en) * | 2015-10-19 | 2016-03-09 | 烽火通信科技股份有限公司 | Method and system for simulating client to execute network element management based on multithreading technology |
CN105389253B (en) * | 2015-10-19 | 2017-12-08 | 烽火通信科技股份有限公司 | The method and system of NE management are performed based on multithreading simulant-client |
US11582098B1 (en) * | 2021-11-09 | 2023-02-14 | At&T Intellectual Property I, L.P. | Mechanized modify/add/create/delete for network configuration |
US12034594B2 (en) | 2021-11-09 | 2024-07-09 | At&T Intellectual Property I, L.P. | Mechanized modify/add/create/delete for network configuration |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7069553B2 (en) | Universal deployment tool | |
EP0909057B1 (en) | Bean-based management system | |
US5893106A (en) | Object oriented server process framework with interdependent-object creation | |
US6505228B1 (en) | Dynamic determination of execution sequence | |
US7941784B2 (en) | System and method for generating component based applications | |
US6954930B2 (en) | Remote validation of installation input data | |
US7467372B2 (en) | Device configuration and management development system | |
US6226788B1 (en) | Extensible network management system | |
US6356931B2 (en) | Method and system for remotely browsing objects | |
US8006224B2 (en) | System and method for unified visualization of two-tiered applications | |
US7493594B2 (en) | System and method for designing component based applications | |
US6205465B1 (en) | Component extensible parallel execution of multiple threads assembled from program components specified with partial inter-component sequence information | |
EP0909058B1 (en) | Network management framework | |
EP1061446A2 (en) | Web-based enterprise management with multiple repository capability | |
US20030163807A1 (en) | Weighted selection of target systems for distributed software installation | |
US20030078949A1 (en) | Automatic generation of forms with input validation | |
US20080141139A1 (en) | Architecture and Process for Presenting Application Content to Clients | |
CA2604935A1 (en) | System and method for creating a mapping document for binding messages between an application and an associated backend server | |
US20080229274A1 (en) | Automating Construction of a Data-Source Interface For Component Applications | |
US9049044B1 (en) | Method of management and distribution of device adapters for element management systems | |
CA2539134C (en) | System and method for designing component based applications | |
CA2539047C (en) | System and method for generating component based applications | |
US20080088877A1 (en) | System and Method for Updating Reference to a Data-Source In a Component-Based Application | |
CA2543898C (en) | System and method for unified visualization of two-tiered applications | |
EP1712995B1 (en) | System and method for supporting packaging, publishing and republishing of wireless component applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NORTEL NETWORKS LIMITED, CANADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MARSHALL, BRENT;MEIJER, FRANK;MOSSMAN, PAUL;AND OTHERS;SIGNING DATES FROM 20060326 TO 20060327;REEL/FRAME:017756/0004 |
|
AS | Assignment |
Owner name: CITIBANK, N.A., AS ADMINISTRATIVE AGENT, NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA INC.;REEL/FRAME:023892/0500 Effective date: 20100129 |
|
AS | Assignment |
Owner name: CITICORP USA, INC., AS ADMINISTRATIVE AGENT, NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA INC.;REEL/FRAME:023905/0001 Effective date: 20100129 Owner name: CITICORP USA, INC., AS ADMINISTRATIVE AGENT, NEW Y Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA INC.;REEL/FRAME:023905/0001 Effective date: 20100129 |
|
AS | Assignment |
Owner name: AVAYA INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:023998/0878 Effective date: 20091218 |
|
AS | Assignment |
Owner name: BANK OF NEW YORK MELLON TRUST, NA, AS NOTES COLLATERAL AGENT, THE, PENNSYLVANIA Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA INC., A DELAWARE CORPORATION;REEL/FRAME:025863/0535 Effective date: 20110211 Owner name: BANK OF NEW YORK MELLON TRUST, NA, AS NOTES COLLAT Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA INC., A DELAWARE CORPORATION;REEL/FRAME:025863/0535 Effective date: 20110211 |
|
AS | Assignment |
Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., PENNSYLVANIA Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA, INC.;REEL/FRAME:029608/0256 Effective date: 20121221 Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., P Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA, INC.;REEL/FRAME:029608/0256 Effective date: 20121221 |
|
AS | Assignment |
Owner name: BANK OF NEW YORK MELLON TRUST COMPANY, N.A., THE, PENNSYLVANIA Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA, INC.;REEL/FRAME:030083/0639 Effective date: 20130307 Owner name: BANK OF NEW YORK MELLON TRUST COMPANY, N.A., THE, Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA, INC.;REEL/FRAME:030083/0639 Effective date: 20130307 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: CITIBANK, N.A., AS ADMINISTRATIVE AGENT, NEW YORK Free format text: SECURITY INTEREST;ASSIGNORS:AVAYA INC.;AVAYA INTEGRATED CABINET SOLUTIONS INC.;OCTEL COMMUNICATIONS CORPORATION;AND OTHERS;REEL/FRAME:041576/0001 Effective date: 20170124 |
|
AS | Assignment |
Owner name: AVAYA INTEGRATED CABINET SOLUTIONS INC., CALIFORNIA Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531 Effective date: 20171128 Owner name: OCTEL COMMUNICATIONS LLC (FORMERLY KNOWN AS OCTEL COMMUNICATIONS CORPORATION), CALIFORNIA Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531 Effective date: 20171128 Owner name: AVAYA INC., CALIFORNIA Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 029608/0256;ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A.;REEL/FRAME:044891/0801 Effective date: 20171128 Owner name: AVAYA INC., CALIFORNIA Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 025863/0535;ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST, NA;REEL/FRAME:044892/0001 Effective date: 20171128 Owner name: AVAYA INC., CALIFORNIA Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 023892/0500;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044891/0564 Effective date: 20171128 Owner name: OCTEL COMMUNICATIONS LLC (FORMERLY KNOWN AS OCTEL Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531 Effective date: 20171128 Owner name: AVAYA INTEGRATED CABINET SOLUTIONS INC., CALIFORNI Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531 Effective date: 20171128 Owner name: AVAYA INC., CALIFORNIA Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531 Effective date: 20171128 Owner name: VPNET TECHNOLOGIES, INC., CALIFORNIA Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531 Effective date: 20171128 Owner name: AVAYA INC., CALIFORNIA Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 030083/0639;ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A.;REEL/FRAME:045012/0666 Effective date: 20171128 |
|
AS | Assignment |
Owner name: GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT, NEW YORK Free format text: SECURITY INTEREST;ASSIGNORS:AVAYA INC.;AVAYA INTEGRATED CABINET SOLUTIONS LLC;OCTEL COMMUNICATIONS LLC;AND OTHERS;REEL/FRAME:045034/0001 Effective date: 20171215 Owner name: GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT, NEW Y Free format text: SECURITY INTEREST;ASSIGNORS:AVAYA INC.;AVAYA INTEGRATED CABINET SOLUTIONS LLC;OCTEL COMMUNICATIONS LLC;AND OTHERS;REEL/FRAME:045034/0001 Effective date: 20171215 |
|
AS | Assignment |
Owner name: AVAYA, INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITICORP USA, INC.;REEL/FRAME:045045/0564 Effective date: 20171215 Owner name: SIERRA HOLDINGS CORP., NEW JERSEY Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITICORP USA, INC.;REEL/FRAME:045045/0564 Effective date: 20171215 |
|
AS | Assignment |
Owner name: CITIBANK, N.A., AS COLLATERAL AGENT, NEW YORK Free format text: SECURITY INTEREST;ASSIGNORS:AVAYA INC.;AVAYA INTEGRATED CABINET SOLUTIONS LLC;OCTEL COMMUNICATIONS LLC;AND OTHERS;REEL/FRAME:045124/0026 Effective date: 20171215 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
AS | Assignment |
Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, MINNESOTA Free format text: SECURITY INTEREST;ASSIGNORS:AVAYA INC.;AVAYA MANAGEMENT L.P.;INTELLISIST, INC.;AND OTHERS;REEL/FRAME:053955/0436 Effective date: 20200925 |
|
AS | Assignment |
Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT, DELAWARE Free format text: INTELLECTUAL PROPERTY SECURITY AGREEMENT;ASSIGNORS:AVAYA INC.;INTELLISIST, INC.;AVAYA MANAGEMENT L.P.;AND OTHERS;REEL/FRAME:061087/0386 Effective date: 20220712 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |
|
AS | Assignment |
Owner name: AVAYA INTEGRATED CABINET SOLUTIONS LLC, NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 45124/FRAME 0026;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:063457/0001 Effective date: 20230403 Owner name: AVAYA MANAGEMENT L.P., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 45124/FRAME 0026;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:063457/0001 Effective date: 20230403 Owner name: AVAYA INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 45124/FRAME 0026;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:063457/0001 Effective date: 20230403 Owner name: AVAYA HOLDINGS CORP., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 45124/FRAME 0026;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:063457/0001 Effective date: 20230403 |
|
AS | Assignment |
Owner name: WILMINGTON SAVINGS FUND SOCIETY, FSB (COLLATERAL AGENT), DELAWARE Free format text: INTELLECTUAL PROPERTY SECURITY AGREEMENT;ASSIGNORS:AVAYA MANAGEMENT L.P.;AVAYA INC.;INTELLISIST, INC.;AND OTHERS;REEL/FRAME:063742/0001 Effective date: 20230501 |
|
AS | Assignment |
Owner name: CITIBANK, N.A., AS COLLATERAL AGENT, NEW YORK Free format text: INTELLECTUAL PROPERTY SECURITY AGREEMENT;ASSIGNORS:AVAYA INC.;AVAYA MANAGEMENT L.P.;INTELLISIST, INC.;REEL/FRAME:063542/0662 Effective date: 20230501 |
|
AS | Assignment |
Owner name: AVAYA MANAGEMENT L.P., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: CAAS TECHNOLOGIES, LLC, NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: HYPERQUALITY II, LLC, NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: HYPERQUALITY, INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: ZANG, INC. (FORMER NAME OF AVAYA CLOUD INC.), NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: VPNET TECHNOLOGIES, INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: OCTEL COMMUNICATIONS LLC, NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: AVAYA INTEGRATED CABINET SOLUTIONS LLC, NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: INTELLISIST, INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: AVAYA INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 045034/0001);ASSIGNOR:GOLDMAN SACHS BANK USA., AS COLLATERAL AGENT;REEL/FRAME:063779/0622 Effective date: 20230501 Owner name: AVAYA INTEGRATED CABINET SOLUTIONS LLC, NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 53955/0436);ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT;REEL/FRAME:063705/0023 Effective date: 20230501 Owner name: INTELLISIST, INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 53955/0436);ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT;REEL/FRAME:063705/0023 Effective date: 20230501 Owner name: AVAYA INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 53955/0436);ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT;REEL/FRAME:063705/0023 Effective date: 20230501 Owner name: AVAYA MANAGEMENT L.P., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 53955/0436);ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT;REEL/FRAME:063705/0023 Effective date: 20230501 Owner name: AVAYA INTEGRATED CABINET SOLUTIONS LLC, NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 61087/0386);ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT;REEL/FRAME:063690/0359 Effective date: 20230501 Owner name: INTELLISIST, INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 61087/0386);ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT;REEL/FRAME:063690/0359 Effective date: 20230501 Owner name: AVAYA INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 61087/0386);ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT;REEL/FRAME:063690/0359 Effective date: 20230501 Owner name: AVAYA MANAGEMENT L.P., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST IN PATENTS (REEL/FRAME 61087/0386);ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT;REEL/FRAME:063690/0359 Effective date: 20230501 |
|
AS | Assignment |
Owner name: AVAYA LLC, DELAWARE Free format text: (SECURITY INTEREST) GRANTOR'S NAME CHANGE;ASSIGNOR:AVAYA INC.;REEL/FRAME:065019/0231 Effective date: 20230501 |