Browse Prior Art Database

Process for Transparently Locating and Running Applications on Servers

IP.com Disclosure Number: IPCOM000122883D
Original Publication Date: 1998-Jan-01
Included in the Prior Art Database: 2005-Apr-04

Publishing Venue

IBM

Related People

Kaminsky, DL: AUTHOR

Abstract

In the coming "Network Centric" computing world, users will be able connect to a global network from anywhere and to run any application residing anywhere and have the application execute as if were running locally. To the user, application location will be transparent.

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

Process for Transparently Locating and Running Applications on Servers

      In the coming "Network Centric" computing world, users will be
able connect to a global network from anywhere and to run any
application residing anywhere and have the application execute as if
were running locally.  To the user, application location will be
transparent.

      Such a world will require infrastructure far superior to that
existing today.  For example, for a user to access applications
transparently will require a "Resource Location Mechanism" (RLM).
Given only the user's "name", the user's password and the name of the
application, the RLM will allow the user to run any application.
Such an RLM is the subject of this filing.

      As described above, the RLM uses a user name (U), a password
(P) and an application name (A), and starts the application on some
server.  The process of translating  U, P and A into a running
application occurs in three stages.  Once U and P have been
specified, the RLM can start an arbitrary number of applications for
that user.

      The activities of the RLM are coordinated by a program, called
the RLM client (or simply "the client"), running on the user's
computer.  The client inputs, from a user, U and P, and an arbitrary
number of application names.  The client then executes the three
stages, retaining the results from each stage to execute later
stages.

      The first stage (the "logon" stage) maps the pair (U,P), sent
from the client, into a machine address (M) and a security token
(ST).  M describes the location of a machine that stores a list of
the user's servers.  S securely encodes the user's access
permissions. The  client retains M and ST.

      In the second stage, the client uses M and ST, and obtains the
user's list of servers (SV).  For each server SV(i) in the list, SV
also encodes the directories within SV(i) that might contain
applications for  the user.  Thus, when searching SV(i) for the given
application (A), the  client need not search every directory on the
machine.  In the preferred  implementation, the directory list is
unnecessary.

      Note here that the list of servers can be an arbitrarily large,
but bounded size.  Since the size of the list is bounded, the time
required to search the list is predictible given knowledge about the
underlying network.

      In the final stage, the client takes A, SV and ST and starts
the user's application.  The client iterates over the servers in SV,
attempting to start A on each server.  In the preferred
implementation, the client sends an allocate request to the attach
manager (a standard  component of SNA) on the first server listed in
SV.  The allocate contains A and ST.  If the allocate succeeds, the
process terminates successfully.  If the allocate fails, the client
sends an allocate to the second server in SV, and so on until an
allocate succeeds or until  no further servers exist in SV.

 ...