Browse Prior Art Database

Method for Determining if Software Being Configured Needs to be Relaunched in a High Performance Administration Environment

IP.com Disclosure Number: IPCOM000014678D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 43K

Publishing Venue

IBM

Related People

Kent Hayes Jr: AUTHOR

Abstract

When software is launched from an Profile Management Administration environment, it is launched in a context (i.e., the User, User Group, Machine Group, etc, that is being administered.) When the context is changed (i.e., another User or User Group is to be configured), the Administration software needs to determine whether or not the configuration software user software being configured needs to be relaunched. Relaunching the configuration software every time forcing it to load new preferences and update its GUI is a poor performer. Creating a method to determine whether software needs to be relaunched leads to large performance gains. The Admin tool establishes a persistent connection to the server and passes an object (call it callBack) that the server software can use to determine whether Administration software is still running on a client. All software that is launched under Administrative control, gets the desired Administrative context from the server (so software can be controlled in different namespaces). Software that is launched as part of the Administrative tool itself is flagged as nonContextFloating (the software wants to load and retrieve preferences from a set context, i.e., the Administrative user that is logged on to the Admin tool as opposed to the context (i.e., User , User Group, etc.) set by the Administrator from within the config tool. (If the Administrator sets his/her Administrative tools background color to blue, the Administrator wants to retrieve this preference the next time he/she runs the Admin tool, not the next time he/she runs the Admin tool and sets the context to "User BOB").

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 65% of the total text.

Page 1 of 2

  Method for Determining if Software Being Configured Needs to be Relaunched in a High Performance Administration Environment

      When software is launched from an Profile Management Administration environment, it is launched in a context (i.e., the User, User Group, Machine Group, etc, that is being administered.) When the context is changed (i.e., another User or User Group is to be configured), the Administration software needs to determine whether or not the configuration software / user software being configured needs to be relaunched. Relaunching the configuration software every time forcing it to load new preferences and update its GUI is a poor performer. Creating a method to determine whether software needs to be relaunched leads to large performance gains.

The Admin tool establishes a persistent connection to the server and passes an object (call it callBack) that the server software can use to determine whether Administration software is still running on a client.

All software that is launched under Administrative control, gets the desired Administrative context from the server (so software can be controlled in different namespaces).

Software that is launched as part of the Administrative tool itself is flagged as nonContextFloating (the software wants to load and retrieve preferences from a set context, i.e., the Administrative user that is logged on to the Admin tool as opposed to the context (i.e., User , User Group, etc.) set by the Administrator from within the config tool. (If the Administrator sets his/her Administrative tools background color to blue, the Administrator wants to retrieve this preference the next time he/she runs the Admin tool, not the next time he/she runs the Admin tool and sets the context to "User BOB").

Configuration and end user software that is launched in the Admin environment is flagged as context floating. All context floating software that is launched and loads preference information is tracked and correlated to the client running the Admin tool that is launching it.

Whether or not the client is still under Administrative control is checked utilizing the afore mentioned callBack connection to the client (if the connection is down, the software is no longer under Administrative control and the desired context is that of the user logging on), else the context is that desired by the Administrator running the Administration tool. Non-context floating software is not tracked. The Administrator changes context locally on the client and notifies the server of the new desired context for the software on the client.

The Administration software then notifies all interested clients in the same name space (through an appropriate Java EventListener

1

Page 2 of 2

or som...