Apparatus and method for monitoring and routing status messages
An apparatus and method for monitoring and routing status messages to another process running on the same or a different computing system during the installation of one or more applications are provided. With the apparatus and method, one or more objects can monitor the progress, log events, status message, etc., generated during an installation, silent or otherwise, of one or more products. Monitoring includes a Status Listener object and a Status Producer object for the installation application. The Status Producer object obtains status messages, progress indications, and log events from a vendor supplied installation program. The Status Producer object then forwards these messages to registered Status Listeners that implement the Status Listener interface. The Status Listeners then forward these messages to their associated external processes which may be located on the same or a remotely located computing system.
Latest IBM Patents:
This application is a continuation of application Ser. No. 10/184,860, filed Jun. 28, 2002 now U.S. Pat. No. 7,296,266.BACKGROUND OF THE INVENTION
1. Technical Field
The present invention is generally directed to an improved computing system. More specifically, the present invention is directed to an apparatus and method for routing status messages to another process running on the same or a different computing system.
2. Description of Related Art
During the installation of middleware and suite products, the user is asked to input installation options. The installation program then takes this data and invokes the installation of one or more other products silently. This greatly simplifies the installation process for the user by asking for the information only once instead of showing the install dialogs from each product which may ask for the same information several times. Also, once all of the information is provided, a silent install hides the complexity of various install options from the user and makes a multiple-install look like a single product.
However, with silent installs, any status messages, event logs, or progress indicators, such as 0-100 percent, provided by the silently invoked installation program does not get fed back to the master install program. Thus, there is no ability to monitor the installation of these silently invoked installation programs. Moreover, any logs that may be generated by such silently invoked installation programs may be stored in different locations within a computing system and may not be easily accessible, rather than having a single log file that logs all events during the installation of all of the products.
Thus, it would be beneficial to have an apparatus and method of monitoring such silent installations of products and routing status messages, log events, progress indicators, etc. to a destination process for such monitoring and other processing, on the same or a different computing system on which the installation is being performed.SUMMARY OF THE INVENTION
The present invention provides an apparatus and method for monitoring and routing status messages to another process running on the same or a different computing system during the installation of one or more applications. With the apparatus and method of the present invention, one or more objects can monitor the progress, log events, status message, etc., generated during an installation, silent or otherwise, of one or more products.
Monitoring includes a Status Listener object and a Status Producer object for the installation application. The Status Producer object obtains status messages, progress indications, and log events from a vendor supplied installation program. The Status Producer object then forwards these messages to registered Status Listeners that implement the Status Listener interface. The Status Listeners then forward these messages to their associated external processes which may be located on the same or a remotely located computing system.
These and other features and advantages of the present invention will be described in, or will become apparent to those of ordinary skill in the art in view of the following detailed description of the preferred embodiments.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
The present invention provides an apparatus and method for monitoring and routing status messages of computer programs. The present invention may be implemented in a stand alone computing system or in any distributed or network based computing system. Thus,
With reference now to the figures,
In the depicted example, server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 are connected to network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Network data processing system 100 may include additional servers, clients, and other devices not shown.
In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
Alternatively, a single processor system may be employed. Also connected to system bus 206 is memory controller/cache 208, which provides an interface to local memory 209. I/O bus bridge 210 is connected to system bus 206 and provides an interface to I/O bus 212. Memory controller/cache 208 and I/O bus bridge 210 may be integrated as depicted.
Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI local bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to clients 108-112 in
Those of ordinary skill in the art will appreciate that the hardware depicted in
The data processing system depicted in
With reference now to
Processor 302 and main memory 304 are connected to PCI local bus 306 through PCI bridge 308. PCI bridge 308 also may include an integrated memory controller and cache memory for processor 302. Additional connections to PCI local bus 306 may be made through direct component interconnection or through add-in boards.
In the depicted example, local area network (LAN) adapter 310, SCSI host bus adapter 312, and expansion bus interface 314 are connected to PCI local bus 306 by direct component connection. In contrast, audio adapter 316, graphics adapter 318, and audio/video adapter 319 are connected to PCI local bus 306 by add-in boards inserted into expansion slots. Expansion bus interface 314 provides a connection for a keyboard and mouse adapter 320, modem 322, and additional memory 324. Small computer system interface (SCSI) host bus adapter 312 provides a connection for hard disk drive 326, tape drive 328, and CD-ROM drive 330. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.
An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in
Those of ordinary skill in the art will appreciate that the hardware in
As another example, data processing system 300 may be a stand-alone system configured to be bootable without relying on some type of network communication interfaces As a further example, data processing system 300 may be a personal digital assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.
The depicted example in
As mentioned above, the present invention provides a mechanism for monitoring and routing status messages of computer programs. With the present invention, a status listener and a status producer are implemented by a first process in order to provide status, progress and log messages to status listeners in the same or a different process running locally or remotely. The status listener obtains status messages, progress indications, and log events from the status producer included in the vendor supplied installation program. The status producer produces the status messages, log entries, etc. that are written to a designated file, provided to another running process, or output to an output device for review by a user.
With the present invention any process may register as a status listener with the progress class. The status producer interface implemented by the progress class adds the process as a new listener. In order to register as a status listener, the process calls a listener class which implements the status listener interface. The listener object registers as a status listener by calling the method on the producer object that is used to add listeners to a status listener data structure.
Thereafter, when an object being installed by an installation program calls the progress class in order to update the progress of the installation, the progress class which implements the status producer interface sends status update messages, progress indicators, log message, etc. to registered listeners that implement the status listener interface.
The progress class 430 of the present invention is a modified form of the known public Progress class. The known progress class can be called to display the progress of an operation in a dialog box or other graphical user interface object. An instance of the Progress class, i.e. a Progress object, has several methods which can be called by the install program. One of these methods is the progressInfo( ) method shown below:
This progressInfo( ) method simply displays the information passed to it in a dialog box. The limitation with this approach is that the progress and status is only displayed in a GUI object. However, by changing this progressInfo (method) to send its progress to any object that has asked for it, flexibility in sending progress messages is greatly increased. The present invention provides such flexibility by modifying the Progress class to make use of Status listener and Status Producer interfaces so that progress information may be sent to any object registered as a listener.
A status listener interface, according to one exemplary embodiment of the present invention, is as follows:
A status producer interface, according to one exemplary embodiment of the present invention, is as follows:
By modifying the known Progress class shown above to implement the Status Producer interface, any class that implements the Status Listener interface can easily obtain all status and progress messages. This is because the Status Producer interface relays any status messages it receives from the installation application to all registerd Status Listeners implementing the Status Listener interface.
The new Progress class according to an exemplary embodiment of the present invention is as follows:
The capability exists within this new Progress class to send progress messages to any registered listeners. There is one Progress class for an installation application. Each object being installed calls the same Progress instance. A class that implements Status Listener must register with the existing Progress instance to receive notifications. An exemplary class that implements the Status Listener interface and is used to register a new listener with the Progress class is as follows:
The processing done in the notify( ) methods in MyListener will vary between installation applications. Thus, a developer of the Status Listener class for the external process may configure these notify( ) methods to perform the necessary functions for the particular installation program and desired output of progress and status information.
In operation, when an installation application is initiated, the installation application creates an instance of the Progress class, i.e. a Progress object. An instance of the Listener class may then be created, i.e. a Listener object. When the Listener object is created, it registers with the Progress object.
During installation, another object, e.g., the object being installed, calls the ProgressInfo( ) method on the Progress object. This causes the status message generated by the installation application to be sent to the Listener object via the Progress object. That is, the Status Producer interface enables listeners to register so that when the ProgressInfo( ) method is invoked, the status message sent to the Progress object is relayed to all registered Listener objects.
The status and progress functionality of the present invention can be enhanced further by providing specific Status Listeners that forward these status and progress messages to any process including remotely located processes, such as processes running on different computing systems coupled to a network, e.g., the Internet. If the Status Listeners are enhanced so that they are capable of forwarding status and progress messages, for example, over TCP/IP connections, a local or remote web browser application may be used to receive the status and progress messages.
This enhanced embodiment of the present invention is illustrated in
A remotely located computing device 570 has an external process 560, such as a web browser application, running on it. This external process 560 sends a request message to the Network listener object via TCP/IP connections of the network. The Network Listener object is configured to use TCP/IP to communicate with the external process 560 such that status and progress messages provided via the Status Producer interface 532 are transmitted to the external process via the Status Listener interface 542 and Network Listener object as data packets over TCP/IP communication links of the network.
The new network listener class functions as a Hypertext Transfer Protocol (HTTP) server that listens for requests on a particular port. When a request is received from an external process and that request has the correct Uniform Resource Locator (URL), the connection between the external process 560 and the Network Listener object remains open for the life of the installation application or until the external process 560 closes the connection.
During installation, another object, e.g., the object being installed, calls the ProgressInfo( ) method on the Progress object. This causes the message to be sent to the Network Listener object. In addition to the Network Listener being a StatusListener, it is also is listening for connection requests on a network port. This is how a remote process, such as a web browser connects to the installation program to obtain status messages. When a remote connection is made, the Network Listener object forwards any new messages it receives to any remote connections currently open.
There may be simultaneous installations occurring on one system, thus any available port within a given range of ports may be used. A system can only have one process listening on any given port. To enable more than one Network Listener object on a system, additional ports must be used. Different ports can be accessed by a web browser by specifying the port in the URL such as http://www.myserver.com:8000/itj/myinstall, where 8000 is the port number.
To provide a level of security, the http server will only respond to a particular URL. This can be set by the Network Listener class, and becomes the password for that install program. For example, if the install status can be accessed by a browser using http://www.myserver.com: 8000/itj/myinstall/status, then the only way a user may monitor the installation application is to enter the entire URL. If “/myinstall/” is left out, then the installation application cannot be monitored. The “/itj/myinstall/” may be specified by the Network Listener class, so it can be set to any text string. Unless a user knows what this text string is, there is no way to connect to and monitor the installation application.
An exemplary implementation of the network status listener class is shown below:
Thus with a Network Listener such as that described above, the ability to send status and progress messages to any registered process may be enhanced to include external processes running on remotely located computing devices. Thus, not only is the problem of the prior art with regard to sending status and progress messages only to a GUI object or data file overcome by the present invention, but the present invention also provides for sending such status and progress messages to processes running on remotely located computing devices, such as web browsers or the like.
While the above embodiments of the present invention are described primarily with reference to status and progress messages, the present invention may further be extended to the sending of log messages to any registered processes. Logs, i.e. files containing log messages, are used by installation applications to indicate options selected and the successful or unsuccessful results of operations performed during the installation operation. When installation operations are silently invoked by another master installation application, the log information becomes critical to proper installation behavior. The master installation application must monitor the logging of messages to identify if the silent installation was successful or if it failed. Obviously, if there was a failure, then an error message should be reported back to the user and, if critical, installation should terminate.
Currently there are two ways to monitor the logging of a silent installation operation. The first is to wait until the installation is complete and then read in the log file and parse it for predefined messages that indicate a success or failure. A second way is to monitor the log file while it is being written. This second approach is much more complicated and requires the tracking of changes to the log file, however, it does provide immediate feedback to the master installation application.
The present invention may be used to enhance the monitoring of the log file as it is being written. The present invention improves upon the monitoring of the log file by providing a way for an external process to register as a log listener and then have log messages relayed to it either locally or remotely.
Similar to the Progress class, there exists a Logger class that can be called to add log messages to a log file. This Logger class has several methods which can be called by an installation program. One of these methods is the log ( ) method shown below:
The log ( ) method simply appends the message to the end of the log file if logging is enabled. The limitation with this approach is that the log message is only sent to the log file. However, by changing this log ( ) method to send its log message to any object that has asked for it, logging flexibility is greatly increased. Thus, for example, the log message may be both sent to the log file and also output to another process that has requested the log message be provided to it.
The present invention modifies the log ( ) method shown above so that it implements the Log Listener and Log Producer interfaces which are similar to the Status Listener and Status Producer interfaces discussed above. It should be appreciated that the Log Listener and Log Producer interfaces are only specific types of the Status Listener and Status Producer interfaces. Thus, when the term “status” is used in the present application, this term is intended to mean any status, progress or log messages that may be sent by an installation application.
An example of the Log Listener interface is shown below:
A Log Producer interface, according to one exemplary embodiment of the present invention, is as follows:
If the Logger class shown above is modified to implement the LogProducer interface, then any class that implements the Log Listener interface can obtain all logging messages. An example of such a new Logger class is as follows:
The capability exists within this new Logger class to send log messages to any registered log listeners. There is one Logger class for an installation application. Each object being installed calls the same Logger instance. A class that implements the Log Listener interface must register with the existing Logger instance to receive log messages. An exemplary class that implements the Log Listener interface and is used to register a new Log listener with the Logger class is as follows:
The processing done in the log ( ) method in MyListener will vary between installation applications.
A Network Log Listener, which is similar to the Network Listener and functions in a similar manner, may be provided to allow for monitoring of log messages generated by an installation application from a remote location. An example of such a Network Log Listener class is as follows:
In a similar manner as discussed above with the Network Listener, the Network Log Listener may be used as both a Log Listener and as a listener for requests from remotely located external processes received over certain predefined ports. In this way, a remotely located external process may open a connection to the Network Log Listener and the Network Log Listener sends log messages to any open connections. Thus, a user of a remotely located client device may monitor the installation application from his/her remote location whether or not this installation application performs a silent installation or a non-silent installation.
Thus, the present invention provides an apparatus and method for generating and routing status, progress and log messages to processes registered as listeners to the installation program. Such processes are not limited to GUI objects as in the prior art Progress class. Rather, any process may register as a listener to the installation program and obtain status, progress and log messages.
Furthermore, the present invention allows processes running on remotely located computing devices to connect to a registered listener and obtain these status, progress and log messages. In this way, a web browser application may be used to connect to a registered listener and status, progress, and log messages may be obtained via TCP/IP connections over a network.
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
1. A computer program product encoded in a computer readable medium and operable by a data processing system for providing log messages in an installation process, the computer program product comprising:
- first instructions for registering a process as an installation event listener with a logging process which logs installation events, wherein the logging process is a process within the installation process, wherein the logging process is called by each object being installed by the installation process, and wherein the logging process is an instance of a class object that is subclassed to listen for particular installation events;
- second instructions for starting the installation process to install a first object, wherein the installation process calls a secondary installation process to install a second object; and
- third instructions for logging installation events to a local log file as well as sending the installation event log messages to the registered process, as the installation process progresses, using the logging process, wherein the logging process sends the installation event log messages regarding installation of the first object and the second object.
2. The computer program product of claim 1, wherein the process is a process running on a computing device remotely located from a computing device on which the installation process is running.
3. The method of claim 1, wherein the third instructions for logging installation events include instructions for implementing a producer interface that sends the installation event log messages to a listener interface, the listener interface being implemented by the registered process.
4. The computer program product of claim 1, wherein the first instructions for registering the process as an installation event listener include instructions for receiving a call of a listener class from the process and instructions for creating a listener object which registers with an object associated with the installation process.
5. The computer program product of claim 1, wherein the logging process is an instance of a class that is subclassed to listen for installation event log messages sent to a particular port.
6. The computer program product of claim 4, wherein the installation event log messages include at least one of a directory of a file being installed, a name of the file being installed and a percentage of the installation of the file that is complete.
7. The computer program product of claim 4, wherein the object is a Logger object that is used by a monitor process to send log messages to registered listener objects.
8. The computer program product of claim 4, wherein the installation event log messages include at least one of a text string and event information.
9. The computer program product of claim 1, further comprising:
- fourth instructions for creating a network listener object, wherein the network listener object monitors one or more predefined ports for requests from registered installation event listeners.
10. The computer program product of claim 9, wherein the network listener object opens a connection with a registered installation event listener when a request is received from the registered installation event listener at one of the one or more predefined ports.
11. The computer program product of claim 10, wherein the third instructions for sending the installation event log message to the registered process include instructions for sending the information to any open communication connection monitored by the network listener object.
|5867713||February 2, 1999||Shrader et al.|
|6023507||February 8, 2000||Wookey|
|6044398||March 28, 2000||Marullo et al.|
|6067639||May 23, 2000||Rodrigues et al.|
|6079036||June 20, 2000||Moharram|
|6115680||September 5, 2000||Coffee et al.|
|6216173||April 10, 2001||Jones et al.|
|6263362||July 17, 2001||Donoho et al.|
|6314449||November 6, 2001||Gallagher et al.|
|6381742||April 30, 2002||Forbes et al.|
|6615091||September 2, 2003||Birchenough et al.|
|6633899||October 14, 2003||Coward|
|6698018||February 24, 2004||Zimniewicz et al.|
|6701514||March 2, 2004||Haswell et al.|
|6802067||October 5, 2004||Camp et al.|
|6829770||December 7, 2004||Hinson et al.|
|20010034771||October 25, 2001||Hutsch et al.|
|20020188941||December 12, 2002||Cicciarelli et al.|
|20030084436||May 1, 2003||Berger et al.|
- Sun Microsystems, Inc., J2SE 1.3.1, API Specification, 1999-2001 (14 pages extracted) http://java.sun.com/j2se/1.3/docs/api/overview-summary.html.
- Kiselev, “A Portable Distributed Event-Logging Facility”, Dr. Dobb's Journal, vol. 26, No. 9, pp. 26-30, Sep. 2001.
- “WinRunner Power Test Automation for the Enterprise”, May 30, 2002, pp. 1-2 http://www-heva.mercuryinteractive.com/products/winrunner/.
Filed: Jul 30, 2007
Date of Patent: Feb 22, 2011
Patent Publication Number: 20080005735
Assignee: International Business Machines Corporation (Armonk, NY)
Inventor: Bryce Allen Curtis (Round Rock, TX)
Primary Examiner: Thomas K Pham
Attorney: Yee & Associates, P.C.
Application Number: 11/830,011