Browse Prior Art Database

Methodology to Execute and Forward Application Commands at Remote Workstations

IP.com Disclosure Number: IPCOM000107516D
Original Publication Date: 1992-Mar-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 3 page(s) / 151K

Publishing Venue

IBM

Related People

Johnson, WJ: AUTHOR [+3]

Abstract

If a requested service cannot satisfy a request locally, it is often desirable in a networked environment to check remote workstations for an instance of that service which can satisfy the request. In turn, the remote workstations which also cannot satisfy the request will forward the request to other remote workstations for checking availability of the requested service. Ultimately, the request is satisfied or the request has encountered connected workstations only to find it cannot be satisfied. A methodology is described which governs propagating requests through a network for satisfying requests which could not be satisfied local to the machine running a requesting application. Processing for satisfying the request is transparent to the requesting application.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 45% of the total text.

Methodology to Execute and Forward Application Commands at Remote Workstations

       If a requested service cannot satisfy a request locally,
it is often desirable in a networked environment to check remote
workstations for an instance of that service which can satisfy the
request. In turn, the remote workstations which also cannot satisfy
the request will forward the request to other remote workstations for
checking availability of the requested service. Ultimately, the
request is satisfied or the request has encountered connected
workstations only to find it cannot be satisfied. A methodology is
described which governs propagating requests through a network for
satisfying requests which could not be satisfied local to the machine
running a requesting application. Processing for satisfying the
request is transparent to the requesting application.

      Often within a heterogeneous network, services running at a
particular node may not contain requested information or the machine
where the request is made does not have the requested service. There
may or may not be other nodes running this requested service. There
may be cases of remote nodes knowing about other remote nodes which
run the requested service. Each node may have a unique set of
connectivity to other nodes, thereby obtaining access to the needed
machine only through a specific topology path not available to other
nodes. A mechanism is needed for the user to take advantage of the
networking capability irrespective of the capabilities of the
application the user is running. A scheme is needed to search the
network for instances of a service and run a user request on that
remote node transparent to the requesting application. Remote
machines should be able to act on behalf of a user's local request.

      The creation of a Remote Application Service (RAS) can
intercept a user's request and distribute the request to a remote
workstation if the requested service is not found locally. This
permits a user's request to be directed to the appropriate service.
The Remote Application service issues the request to corresponding
services upon receiving a request from some local application. The
RAS can reissue the request to a remote RAS. Each RAS, which may, in
turn, propagate the request to other workstations, constructs a
packet to send which governs correct processing of remote request
management. The packet manipulated by any RAS is defined as:

                            (Image Omitted)

      The requesting RAS prepares a packet for sending to connected
nodes. The requesting application request (e.g., "QUERY ADDRESS BOOK
FOR PERSON'S PHONE NUMBER") is placed as a string into the REQUEST
STRING FIELD. Data in the request is not limited to characters and
can be any binary data appropriate for the requested service. A
unique current date/time stamp is derived by adding the current
sending machine's system time to a configured timeout value....