Apparatus and method for on-line replacement of a running script

Apparatus and method are provided for accomplishing on-line replacement of a script running in a process. The apparatus and method utilize a script registry that keeps track of the most current script for a particular service. The request for service is presented to the script registry to identify the location of the most current script that provides the requested service. Because this script registry is an internal data structure, it is therefore lightly portable between different operating system machine types. A superscript is further utilized to transfer script state information between execution of the service-providing scripts. This ensures that data information (i.e., execution mode, environment information, and variable data) is passed from a terminating service script to an initializing service script.

BACKGROUND OF THE INVENTION
 1. Field of the Invention
 The present invention is generally related to a system of processing
 software scripts directed to computer operations and, more particularly,
 is related to a system and method for online replacement of a running
 script within the same process in software.
 2. Description of Related Art
 As known in the computer and software arts, software scripts undergo many
 changes during their product life. The changes either enhance the script's
 functionality through updates or remove problems (i.e., bugs) from the
 script steps. In either circumstance, the script is usually replaced with
 a new version of the script.
 Typically, when a script is replaced with a new version, the old version of
 the script is terminated, and the new version is started. This procedure,
 however, creates a problem where the script operation is interrupted for
 some time period.
 Generally, a script is a sequence of shell commands contained in a text
 file. There are various ways scripts are executed. Some shells read a line
 of script, parse it, execute it, and then read the next line. Other
 shells, such as the well known Perl shell program, parse and compile the
 entire script into object code before beginning execution. One type of
 script is a common gateway interface (cgi) script. Generally, a cgi script
 is invoked when a user clicks on an element in a web page, such as a link
 or image. Cgi scripts are used to provide interactivity in a Web page. Cgi
 scripts can be written in many different computer software languages,
 including C, C++ and Perl. A cgi-bin is a library of cgi scripts
 applications that can be executed by a processor.
 Heretofore, software users have lacked the ability to allow a running
 script to be replaced with a new version of a script without loss of
 service or state.
 SUMMARY OF THE INVENTION
 The present invention provides a system and method for on-line replacement
 of a running script within the same environment. In accordance with one
 aspect of the invention, the apparatus and method utilize a script
 registry that keeps track of the most current script for a particular
 service. The request for service is presented to the script registry to
 identify the location of the most current script that provides the
 requested service.
 In accordance with another embodiment of the apparatus and method of the
 present invention, a script registry is utilized to maintain an index to
 the service scripts to be performed and the path for that service script
 to be found. This feature provides additional robust and reliable
 operation for a user to ensure that all service-providing script locations
 can be determined from a single reference point and that the most current
 service script is accessed by the user.
 In accordance with yet another embodiment of the apparatus and method of
 the present invention, the script registry supports service requests from
 a plurality of service requesters across a network. This feature provides
 reliable operation for multiple users and ensures that all the users in
 the network access the same and most current service script from a
 particular location as opposed to multiple versions of service scripts on
 a single user system.
 In accordance with another embodiment of the apparatus and method of the
 present invention, a superscript is utilized to transfer script state
 information between execution of service-providing scripts. This feature
 provides additional robust and reliable operation to the user to ensure
 that data information (i.e., execution mode, environment information, and
 variable data) is passed from a terminating service script to a
 initializing service script. The state information made available to the
 newly started service script allows continuity between service script
 execution.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
 Reference will now be made in detail to the description of the invention as
 illustrated in the drawings. While the invention will be described in
 connection with these drawings, there is no intent to limit it to the
 embodiment or embodiments disclosed herein. On the contrary, the intent is
 to cover all alternatives, modifications, and equivalents included within
 the spirit and scope of the invention as defined by the appended claims.
 As illustrated in FIG. 1, shown is a computer systems 12 generally
 comprising a processor 21, and a memory 31 with an operating system 32.
 The processor 21 accepts data from memory 31 over a local interface 23,
 such as a bus(es). The memory 31 can be either one or a combination of the
 common types of memory, for example, but not limited to, erasable
 programmable read only memory (EPROM), electronically erasable is
 programmable read only memory (EEPROM), flash memory, programmable read
 only memory (PROM), random access memory (RAM), read only memory (ROM),
 flash memory, Dynamic random access memory (DRAM), Static random access
 memory (SRAM), system memory, or the like. The memory 31 may also include
 either one or a combination of nonvolatile memory, such as disk drives,
 tape drives, CDROM drives, cartridges, cassettes, or memory located on a
 network server. Direction from the user can be signaled by using the input
 devices, for example, but not limited to, a mouse 24 and a keyboard 25.
 The action input and result output may be displayed on a display terminal
 26.
 Stored on the memory 31 is a shell 51, which is a program that interprets
 scripts, a superscript 61, and a script registry 68 of the present
 invention. The shell 51 can be implemented in hardware, software,
 firmware, or a combination thereof. In the preferred embodiment(s), the
 shell 51, superscript 61, and script registry 68 are implemented in
 software or firmware that is stored in a memory and that is executed by a
 suitable instruction execution system.
 Illustrated in FIG. 2 is the well known method of executing a script
 routine. In the environment of the prior art, there is no ability to
 seamlessly replace an existing script with an updated version without
 temporarily interrupting the service being performed by the script and
 undesirable loss of state information. The prior art also lacks the
 ability to seamlessly update existing scripts. Normally, when a script 42
 (script A in FIG. 2) is executing, the script 42 performs its program task
 until done or terminated. To continue with the service the starting of the
 script 45 (script B in FIG. 2) is needed to continue processing as shown.
 The system requests the execution of a script 42 which then needs to be
 invoked by a shell 41. Upon termination of the script 42, the shell 41
 needs to be terminated as well. Either the user or the computer system 12
 must then start shell 44 to continue processing with script 45. This
 termination of script 42 and shell 41 and the start of shell 44 to run
 script 45 causes a run time delay. Also, if script 42 is terminated with a
 status of "not done," then the state of execution of script 42 is unknown
 to script 45 and could cause potential service failures.
 Illustrated in FIG. 3 is a block diagram of the online replacement of a
 running script system in accordance with the present invention showing a
 transition of data state between the old script 63 within the shell 51 to
 the new script 65 that is also run within the shell 51, utilizing the
 superscript 61 to save and transition data (including state) variables.
 The transition between the old script 63 to the new script 65 is
 determined by utilizing the script registry 68 to ascertain the script
 path to the newest available script for a particular service.
 An advantage of the present invention is that the scripts are initialized,
 perform the predefined script task, and then terminate, whereas the
 ongoing service scripts of the prior art repeat themselves by utilizing
 some kind of a looping structure. In the present invention, the
 superscript 61 provides the looping structure and continuously executes
 scripts that provide the requested service and then terminate. Upon the
 termination of old script 63, the shell 51 need not be terminated to
 restart new script 65. Since the superscript 61 initiates the execution of
 the scripts and retains state information regarding the prior script's
 termination state, the new script may obtain and utilize the state
 information during execution.
 Illustrated in FIG. 3 is shell 51, which is the program that interprets a
 script. Within the shell 51 is the online replacement of a running script
 superscript 61 of the present invention. The superscript 61, after
 initialization, which includes determining what service is being
 requested, calls the script registry service 68 utilizing the check script
 registry 71. The script registry service 68 provides a logic 81 for
 searching a service index 80, herein defined in further detail with regard
 to FIG. 4
 The script registry service 68, in the current embodiment, performs an
 index table lookup of the service by utilizing the service index 80 to
 determine the path to the most current service script. The check script
 registry 71 provides communication of the service name from superscript 61
 to the script version service 68. Upon finding the most current path name
 for a particular service name, the script registry 68 returns the service
 path name 86 to the most current service script to perform the service via
 check script registry 71. The superscript 61 receives the script path and
 executes the old script 63 using the script path. Upon termination of old
 script 63, the superscript 61 receives any output generated and loops,
 while not done to repeat the call to script registry service 68 for the
 most current service script. Upon a change or update to a script, the
 service index 80 is updated within the script registry service 68. Upon
 the repeat of the call to script registry 68 for the current service
 script via check script registry 71, the script registry 68 will return a
 new service path name 86 for the requested service on check script 71. The
 superscript 61 receives the script path and executes the new script using
 the updated script path as shown on execute new script 75 which executes
 new script 65. After execution of new script 65, any output is returned
 via the execute new script 75 to t he superscript 61, and the super script
 repeats the call to script registry 68 for the current service script
 ongoing request for service is done.
 In an alternative embodiment, the superscript 61 can continue the loop
 processing after the executing script to further minimize the time
 interruption of service from the script operation. The superscript 61 need
 not wait for any output to be returned from the executing script and can
 repeat the call to script registry service 68 for the most current service
 script.
 Illustrated in FIG. 4 is a block diagram of the script registry 68,
 including the service index 80, of the preferred embodiment. When the
 superscript 61 (FIG. 3) performs a check script registry 71, the
 superscript 61 transmits the service name to the script registry 68. The
 service index 80 receives the service name and performs a search of the
 service name in the service index 80. This search is performed using the
 search logic 81, which searches the service index 80 for a service name 85
 matching the requested service name. If a matching service name 85 is
 found, then the service index 80 retrieves the service path name 86 and
 transmits the requested service path name 86 to the superscript 61 via the
 check script registry 71 path. If a requested service input from
 superscript 61 via the check script registry 71 connection is not found
 within the service index 80 in the service name table 85 utilizing the
 search logic 81, then the service index will return a "path not found"
 message to the superscript 61.
 Illustrated in FIG. 5 is the flow diagram for the superscript 61. The flow
 diagrams of FIGS. 5-7 shows the architecture, functionality, and operation
 of a possible implementation of the superscript 61 and service scripts 63
 (FIG. 3) and 65 (FIG. 3). In this regard, each block in FIG. 5-7
 represents a module, segment, or portion of code, which comprises one or
 more executable instructions for implementing the specified logical
 function(s). It should also be noted that in some alternative
 implementations, the functions noted in the blocks may occur out of the
 order in which they appear in FIG. 5. For example, blocks shown in
 succession may in fact be executed substantially concurrently or the
 blocks may sometimes be executed in the reverse order, depending upon the
 functionality involved.
 With reference to FIG. 5, first, the superscript 61 is initialized in a
 shell 51 at step 91. In the preferred embodiment, the superscript
 initialized is a specialized superscript to provide the requested service.
 In an alternative embodiment, the superscript 61 is a general function
 superscript that is herein defined with regard to FIG. 7. Referring back
 to FIG. 5, the superscript 61 initializes the data variables, environment
 parameters, and the like, at step 92. The superscript 61 transmits a
 request to the script registry 68 to retrieve the most current service
 script path 86 at step 93. The most current service script path 86 is
 identified by the superscript 61 providing the requested service name. The
 superscript 61 waits to receive the current service script path 86
 returned from the script registry 68 at step 94.
 Upon return of the current service script path 86, the superscript 61
 executes the current service script in the shell 51 using the script
 service path name 86 to perform the requested service at step 95. The
 process of the script procedure is herein defined with regard to FIG. 6.
 Upon complete execution of the script at step 96 in FIG. 5, the superscript
 61 then determines if the requested service is done at step 97. If the
 requested service is not done, the superscript 61 returns to step 93 to
 call the script registry 68 to request the current script path using the
 service requested at step 93. If the superscript 80 is done at step 97,
 then the superscript 80 terminates and exits at step 99.
 Illustrated in FIG. 6 is the flow diagram for the script 63 or 65. The
 script 63/65 is initialized at step 101. The script 63/65 has access to
 saved script state information which is available from the data memory
 areas of superscript 61. This saved script state information can be
 utilized during the initialization process of the script at step 101.
 After initialization at step 101, the script 63/65 is executed at step
 102. This execution provides the requested service. In the present
 invention, the scripts 63/65 do not contain any continuous loops in order
 to allow ordered transition between successive executing scripts. Any
 output of either data or message as a result of the script 63/65 execution
 is returned to the superscript 61 at step 103. The script 63/65 then
 terminates at step 109.
 In an alternative embodiment, the superscript 61 may be a general purpose
 service superscript as is illustrated in FIG. 7. First, the general
 service superscript 61 is initialized in a shell 51 at step 111. The
 general superscript 61 initializes the data variables and sets the
 environment and the like at step 112. The general service superscript 61
 then receives requests for service at step 113. The general service
 superscript 61 calls the script registry 68 requesting the most current
 service script path 86 at step 114. This call to the script registry 68
 includes the requested service name provided to the general service
 superscript 61 at step 113. The general service superscript 61 then waits
 to receive the current service script path at step 115. Upon receiving the
 current service script path, the general service superscript 61 executes
 the current service script in the shell 51 utilizing the service path name
 received at step 115 to find the most current script to perform the
 requested service at step 117. The process of the script that performs the
 requested service is herein defined above with regard to FIG. 6. The
 general service superscript 61 then determines if additional requests for
 service are to be accepted at step 118. If additional requests for service
 are to be accepted and processed, the general service superscript 61
 returns to step 113 to receive a request for service. If the general
 service superscript 61 determines that no more requests for service are to
 be processed at step 118, the general service superscript 80 then
 terminates at step 119.
 The on-line replacement of a running script, which comprises an ordered
 listing of executable instructions for implementing logical functions, can
 be embodied in any computer-readable medium for use by or in connection
 with an instruction execution system, apparatus, or device, such as a
 computer-based system, processor-containing system, or other system that
 can fetch the instructions from the instruction execution system,
 apparatus, or device and execute the instructions. In the context of this
 document, a "computer-readable medium" can be any means that can contain,
 store, communicate, propagate, or transport the script for use by or in
 connection with the instruction execution system, apparatus, or device.
 The computer readable medium can be, for example but not limited to, an
 electronic, magnetic, optical, electromagnetic, infrared, or semiconductor
 system, apparatus, device, or propagation medium. More specific examples
 (a nonexhaustive list) of the computer-readable medium would include the
 following: an electrical connection (electronic) having one or more wires,
 a portable computer diskette (magnetic), a random access memory (RAM)
 (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable
 read-only memory (EPROM or Flash memory) (magnetic), an optical fiber
 (optical), and a portable compact disc read-only memory (CDROM) (optical).
 Note that the computer-readable medium could even be paper or another
 suitable medium upon which the script is printed, as the script can be
 electronically captured via, for instance, optical scanning of the paper
 or other medium, then compiled, interpreted or otherwise processed in a
 suitable manner if necessary, and then stored in a computer memory.
 The foregoing description has been presented for purposes of illustration
 and description. It is not intended to be exhaustive or to limit the
 invention to the precise forms disclosed. Obvious modifications or
 variations are possible in light of the above teachings.
 The embodiments discussed were chosen and described to provide the best
 illustration of the principles of the invention and its practical
 application to thereby enable one of ordinary skill in the art to utilize
 the invention in various embodiments and with various modifications as are
 suited to the particular use contemplated. All such modifications and
 variations are within the scope of the invention as determined by the
 appended claims when interpreted in accordance with the breadth to which
 they are fairly and legally entitled.