Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Launch in Context Agent

IP.com Disclosure Number: IPCOM000034024D
Original Publication Date: 2005-Jan-12
Included in the Prior Art Database: 2005-Jan-12
Document File: 4 page(s) / 89K

Publishing Venue



This article describes an agent program that provides a framework for launching an application, launching a task within a running or non-running application, installing an application, and upgrading an application.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 38% of the total text.

Page 1 of 4

Launch in Context Agent

Disclosed is a framework that leverages an agent program that can be utilized for launching an application, executing a task within a running or non-running application, installing an application, and upgrading secondary applications.

    To Launch in Context means to open an application to a specific situation. The specific situation is called the "context". For example, the IBM* Director console normally brings up its main window when it is launched. If it were launched in context, it might instead open the Remote Control task window for the RBERTRAM server. The task (remote control) and target (the server) constitute the context. All but the most very basic applications exhibit this task behavior and are subject to have their functional tasks represented by unique task contexts.

    Suppose a primary application needs to launch several secondary applications in context. Further, suppose that the primary application does not have full access to the system that the secondary applications run on. The primary application might be a Web application running in a browser which has limited access to the client system. If a Web application needs to launch in context a secondary application, there are several things it cannot do through a browser.

The Web application cannot search the client system to find whether and where the secondary application is installed. For example, it can't look in the Windows registry. If the secondary application is missing, the Web application can't install it. If it is down-level, the Web application can't upgrade it.

The Web application can't communicate the context to the application using anything besides the HTTP response. Since it can't send a context to an instance of the secondary application that is already running, a new instance must be launched each time.

The Web application can't receive feedback from the secondary application, such as error reporting.

    When a browser needs to load information of a given MIME type, it launches a "helper application" that is associated with that MIME type of the document. It is possible to adapt this mechanism for Launch in Context by associating the secondary application with a MIME type. The context could be passed to the secondary application in the HTTP response stream. However, if the secondary application is not installed or is down-level, this approach could not install or upgrade it. This approach could not easily interact with an instance of the secondary application that is already running, though it is possible for the new instance to detect the existing one and forward the new context to it. Also, this would require users to configure their Internet browsers to correlate a corresponding application with a specific MIME type.

    Java** Network Launching Protocol (JNLP) and Java Web Start** (JWS) address some of these issues. A Web application could launch a secondary application using JWS. The context could be communicated via application...