|Publication number||US7275251 B2|
|Application number||US 10/430,944|
|Publication date||Sep 25, 2007|
|Filing date||May 7, 2003|
|Priority date||May 7, 2003|
|Also published as||US20040226028, WO2004102381A1|
|Publication number||10430944, 430944, US 7275251 B2, US 7275251B2, US-B2-7275251, US7275251 B2, US7275251B2|
|Inventors||Gary Gitelson, Michael Boe, Prasannakumar Murugesan|
|Original Assignee||Cisco Technology, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (21), Referenced by (6), Classifications (14), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates to selective process restart based on application programming interface (API) changes. More specifically, the invention relates to storing process-to-API and process-to-container dependencies in order to determine the processes, and only those processes, that are affected by API changes.
In most software systems, a collection of software modules will provide an implementation of a service. This service will be accessed by the application through the use of an API. The API itself has a set of symbols (functions and data elements) that comprise the software state and the modifiers of that software state. A given implementation of a service, provided by a specific set of modules, and accessed through the specified API will be referred to as an API service implementation. Typically, both the API and the API service implementation will have versions (e.g., numbers or anything to uniquely identify the version) associated with them. The API has a version, which tracks modification to the definition of the API, such as which symbols are a part of it and what the signature of those symbols is. For data elements, the signature of the symbol is the data type description. For functions, the signature contains the data type descriptions of the return value and all of the parameter values of the function.
The API service implementation also has a version associated with it. This is the version assigned to the collection of modules and tracks the revisions of the modules in the implementation of the defined API.
A specific API service implementation will implement a particular version of the API. At the time that an application is started, it may require the use of an API service implementation that implements the specific version of the API that it makes use of.
There may be multiple versions of an API service implementation present on a system and the system should choose the appropriate version that will be loaded in the address space of the application when it is started. These versions come about as bugs are fixed or new functions are added to an API and new revisions of the software modules that comprise the API service implementation are released to customers.
In a software system where multiple versions of a particular API service implementation can exist simultaneously, one could restart all the processes so that any process that might be impacted by a change in an API service implementation would be restarted. However, it would be beneficial to have innovative technologies that allow a determination of the processes that are affected by changes in an API service implementation so that only those processes are restarted. Additionally, it would be beneficial to be able to determine when there are no processes that could ever utilize an API service implementation so the unused API service implementation can be deleted.
The present invention provides innovative techniques for the selective restart of processes based on API changes. In general, information is stored when processes begin executing that indicates the APIs that the processes are using and the code containers or software modules that are providing the API implementation. By storing this information, the processes that are executing can be analyzed when an API change occurs to determine those processes that are impacted by the change. The processes that are impacted can then be restarted to take advantage of the change in the API, whether it is a new implementation or the deletion of a previous implementation. Advantages of embodiments of the invention can include restarting only those processes that are affected by API changes and the removal of API implementations that will not be used by any of the processes. Some specific embodiments of the invention are described below.
In one embodiment, the invention provides a method for selectively restarting processes based on API changes. A new container is received that includes a new implementation of an API. Stored information is accessed to identify one or more processes that utilize an old implementation of the API. The one or more processes are restarted so that they can utilize the new implementation of the API in the new container. Additionally, the stored information can be modified to indicate the one or more processes utilized the new implementation of the API in the new container.
In another embodiment, the invention provides a method for selectively restarting processes based on API changes. A message is received that a specified container should no longer be utilized, where the container includes an implementation of an API. Stored information is accessed to identify one or more processes that utilize the implementation of the API in the specified container. The one or more processes are restarted so that the one or more processes can utilize a previous implementation of the API in an other container.
In another embodiment, the invention provides a method for selectively restarting processes based on a API changes. Executables are dynamically linked to run processes, where the processes utilize APIs from one or more containers. Process-to-API dependencies and process-to-container dependencies are stored. Upon receiving an API change, only those processes affected by the API change are restarted. Additionally, chronologies of APIs can be stored and the chronologies can include an API and a container that provided the API.
Other features and advantages of the invention will become readily apparent upon review of the following description in association with the accompanying drawings, where the same or similar structures are designated with the same reference numerals.
In the description that follows, the present invention will be described in reference to embodiments in network devices that perform selective process restart based on API changes. These network devices (e.g., routers) are typically embedded systems. However, embodiments of the invention are not limited to any particular environment, protocol, application or implementation. For example, the invention may be advantageously applied to non-embedded systems, such as computer systems. Therefore, the description of the embodiments that follows is for purposes of illustration and not limitation.
Router 103 provides communication between networks. A switch 105 is connected to router 103 and joins communication lines from computers 107.
Although a router and switch are shown in
A non-volatile storage 205 can store computer programs and data such that it is typically persistent and provides more storage when compared to memory 203. At present, a common non-volatile storage is one or more hard drives. A removable storage 207 provides mobility to computer programs and/or data that are stored thereon. Examples of removable storage are floppy disks, tape, CD/ROM, flash memory devices, and the like.
Memory 203, non-volatile storage 205 and removable storage 207 provide examples of computer readable storage media that can be utilized to store and retrieve computer programs incorporating computer codes that implement the invention, data for use with the invention, and the like. Additionally, a data signal embodied in a carrier wave (e.g., in a network including the Internet) can be the computer readable storage medium. An input 209 allows a user to interface with the system. Input can be done through the use of a keyboard, a mouse, buttons, dials, or any other input mechanism. An output 211 allows the system to provide output to the user. Output can be provided through a monitor, display screen, LEDs, printer or any other output mechanism.
A network interface 213 allows the system to interface with a network to which it is connected. The components shown in
The above has described exemplary network and hardware configurations, it may be beneficial now to discuss API implementations and how they are typically delivered.
An executable is a file that when executed by the system operates as a running process. More than one process can be running on a system that is from the same executable file. For the most part, a process is defined by the executable. However, there are functions and/or data that are part of a process yet are not specifically defined by the executable (e.g., API implementations and linked libraries).
For example, an executable can be designed to interface with functions and/or data from an API. Upon execution, the executable is typically dynamically linked to a container that provides the API implementation.
Getting back to
However, if a process only utilized API Z from container M, it would not be necessary to restart the process because of container N. Thus, when an API change occurs, only selective processes may need to be restarted.
As shown, a process can depend on an API implementation. However, any computer code can depend on an API implementation. Thus, one API implementation can depend on another. For simplicity,
One could restart all the processes that are currently executing whenever an API change occurs. However, this could result in many processes being restarted where the API change did not affect the process. As an alternative, a skilled engineer could analyze each process to determine whether the API change would affect the process. As one can imagine, this process would be time consuming and potentially error prone.
An API change can also be the removal or deletion of an API implementation. For example, a system could be informed that container N should no longer be utilized. Processes that utilize API implementations from container N should then be restarted. However, processes that do not utilize API implementations from container N could remain unchanged. With embodiments of the invention, information is stored that allows processes to be selectively restarted based on API changes. Thus, only those processes that are affected by an API change can be restarted while the processes that are unaffected can continue to run.
In one embodiment, the stored information includes process-to-container dependencies, process API dependencies and chronologies of APIs.
As shown a process-to-container table stores tuples that indicate a specified process is relying on an API implementation from the specified container. For example, the tuple (process A, container M) indicates that process A relies on an API implementation from container M. A process can rely on API implementations from multiple containers and the table can store information for multiple processes. In embodiments where all processes from the same executable file are identical, the same entries in the tables can be utilized for all identical processes for simplicity and/or to save storage space.
Also shown in
An API to container table as shown can be utilized to store chronologies of APIs. For example, the tuple (API X, container M) indicates that container M provides an implementation for API X. The subsequent tuple (API X, container N) indicates that container N provides a new implementation of API X. Although tables are shown, any other data structure including link lists can be utilized to store this information.
When an executable is dynamically linked and executed to run a process, symbols will be resolved and the resolution of the symbols can be stored in the table such as the ones shown in
At a step 405, the stored information is modified to indicate the one or more processes that utilize the new implementation of the API in the new container. For example, if the new container provided a new implementation of API X, this could result in a new tuple being added to the process-to-container table shown in
When a new API implementation is received, the API to container table can be updated to reflect the chronology of the API implementation. For example, a tuple can be added to the API to container to indicate that the new container provides a new implementation of the API.
The one or more processes that can utilize the new implementation of the API in the container are dynamically linked at a step 407. At a step 409, the one or more processes are restarted so that the one or more processes can utilize the new implementation of the API. Therefore, only those processes that are affected by an API change are restarted. Typically, a new container will include multiple new API implementations that may be processed together or individually. It should be noted that with all the flowcharts shown herein, steps can be added, deleted, reordered and combined without departing from the spirit and scope of the invention.
As mentioned above, numerous data structures can be utilized to store the information that allows selective restarting of processes based on API changes.
A process field stores identifiers for processes. As shown, the process field can include the name of the process. In other embodiments, a separate table can be utilized to associate a unique identifier (e.g., a number) to each process. In a similar manner, the container field identifies containers and the API field identifies APIs. As shown, a tuple (process A, container M, API X) indicates that process A utilizes container M for API X. The next field is utilized to chain rows of the table together in order to store dependencies of APIs. This field will be discussed in more detail in reference to
As mentioned above, process A utilizes container M for API X. If a new container, container O, provides a new implementation for API X, a new entry in the table can be added in
In a similar manner,
The above has described how a single table can be utilized to store the process-to-container dependencies, process-to-API dependencies and chronologies of APIs. In affect, the three tables shown in
The table shown in
The above has described processes that can be implemented when a new container with a new implementation of an API is received.
At a step 601, a message is received that a specified container should no longer be utilized where the container includes an implementation of an API. In some instances, it may be desirable to roll back a process to no longer utilize API implementations from a container. For example, if it is determined that a container is not compatible with other existing containers, it may be beneficial to essentially uninstall the problematic container.
Stored information is accessed at a step 603 to identify one or more processes that utilize the implementation of the API in the specified container. Typically, a container will include implementations for multiple APIs.
At a step 605, the stored information is modified to indicate the one or more processes utilize a previous implementation of the API in an other container. In other words, the system identifies another or previous container that provides an implementation of the API. For example, a previous entry in a linked list of API dependencies indicate a container to utilize (see, e.g.,
The one or more processes are dynamically linked with the API in the other container at a step 607. At a step 609, the one or more processes are restarted so that the one or more processes can utilize the previous implementation of the API in the other container.
The above has discussed how processes can be selectively restarted based on API changes, it may be beneficial to describe how the stored information can be initially generated. In one embodiment, the executable files indicate the APIs that are required. Additionally, the containers indicate the APIs that they provide and the APIs that are needed. By utilizing this information, one can readily determine the containers that should be dynamically linked with the executable to provide the specified APIs for the process.
At a step 707, chronologies of APIs are stored. Typically, the chronologies include an API and a container that provided the API. Steps 703, 705 and 707 can generate the tables shown in
Upon receiving an API change, only those processes affected by the API change are restarted at a step 709. The API change can be a new API implementation of deletion of an API implementation.
While the above is a complete description of preferred embodiments of the invention, various alternatives, modifications, and equivalents can be used. It should be evident that the invention is equally applicable by making appropriate modifications to the embodiments described above. Therefore, the above description should not be taken as limiting the scope of the invention as defined by the meets and bounds of the appended claims along with their full scope of equivalents.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5873097 *||Dec 17, 1996||Feb 16, 1999||Apple Computer, Inc.||Update mechanism for computer storage container manager|
|US6044461 *||Sep 16, 1997||Mar 28, 2000||International Business Machines Corporation||Computer system and method of selectively rebooting the same in response to a system program code update|
|US6256773||Aug 31, 1999||Jul 3, 2001||Accenture Llp||System, method and article of manufacture for configuration management in a development architecture framework|
|US6332198 *||Jun 9, 2000||Dec 18, 2001||Equipe Communications Corporation||Network device for supporting multiple redundancy schemes|
|US6370573||Aug 31, 1999||Apr 9, 2002||Accenture Llp||System, method and article of manufacture for managing an environment of a development architecture framework|
|US6470388||Jun 10, 1999||Oct 22, 2002||Cisco Technology, Inc.||Coordinated extendable system for logging information from distributed applications|
|US6519571||May 27, 1999||Feb 11, 2003||Accenture Llp||Dynamic customer profile management|
|US6539396||Aug 31, 1999||Mar 25, 2003||Accenture Llp||Multi-object identifier system and method for information service pattern environment|
|US6550057||Aug 31, 1999||Apr 15, 2003||Accenture Llp||Piecemeal retrieval in an information services patterns environment|
|US6601186 *||May 20, 2000||Jul 29, 2003||Equipe Communications Corporation||Independent restoration of control plane and data plane functions|
|US6604136 *||Jun 25, 1999||Aug 5, 2003||Intel Corporation||Application programming interfaces and methods enabling a host to interface with a network processor|
|US6651186 *||Sep 14, 2000||Nov 18, 2003||Sun Microsystems, Inc.||Remote incremental program verification using API definitions|
|US6671699 *||May 20, 2000||Dec 30, 2003||Equipe Communications Corporation||Shared database usage in network devices|
|US6678887 *||Jul 11, 2000||Jan 13, 2004||Networks Associates Technology, Inc.||Customizing business logic and data sources by modifying methods defined within an API|
|US6694450 *||May 20, 2000||Feb 17, 2004||Equipe Communications Corporation||Distributed process redundancy|
|US6708210 *||Mar 13, 2003||Mar 16, 2004||Intel Corporation||Application programming interfaces and methods enabling a host to interface with a network processor|
|US6934749 *||Sep 26, 2000||Aug 23, 2005||Ciena Corporation||Tracking distributed data retrieval in a network device|
|US6957237 *||Jun 2, 2000||Oct 18, 2005||Sun Microsystems, Inc.||Database store for a virtual heap|
|US7020696 *||Nov 1, 2000||Mar 28, 2006||Ciena Corp.||Distributed user management information in telecommunications networks|
|US20030149801 *||Dec 12, 2001||Aug 7, 2003||Kushnirskiy Igor Davidovich||Scriptable plug-in application programming interface|
|US20040010791 *||Dec 20, 2002||Jan 15, 2004||Vikas Jain||Supporting multiple application program interfaces|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7810105 *||Dec 29, 2004||Oct 5, 2010||Motorola, Inc.||Method and apparatus for running different types of applications on a wireless mobile device|
|US8028302 *||Oct 29, 2007||Sep 27, 2011||Whirlpool Corporation||Software architecture system with embedded virtual router|
|US8516508||Aug 2, 2012||Aug 20, 2013||Cisco Technology, Inc.||Automated application programming interface (API) generation|
|US8843945||Jul 31, 2013||Sep 23, 2014||Cisco Technology, Inc.||Automated application programming interface (API) generation|
|US20060143622 *||Dec 29, 2004||Jun 29, 2006||Motorola, Inc.||Method and apparatus for running different types of applications on a wireless mobile device|
|US20080109830 *||Oct 29, 2007||May 8, 2008||Whirlpool Corporation||Software Architecture System with Embedded Virtual Router|
|U.S. Classification||719/328, 718/102, 719/331|
|International Classification||G06F9/44, G06F3/00, G06F9/46, G06F9/00, G06F9/48, G06F9/445|
|Cooperative Classification||G06F9/44536, G06F9/4843, G06F9/44521|
|European Classification||G06F9/48C4, G06F9/445L|
|May 7, 2003||AS||Assignment|
Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GITELSON, GARY;BOE, MICHAEL;MURUGESAN, PRASANNAKUMAR;REEL/FRAME:014055/0937
Effective date: 20030505
|Mar 25, 2011||FPAY||Fee payment|
Year of fee payment: 4
|Mar 25, 2015||FPAY||Fee payment|
Year of fee payment: 8