Browse Prior Art Database

Providing Distributed Computing Environment Servers on Client Demand

IP.com Disclosure Number: IPCOM000115086D
Original Publication Date: 1995-Mar-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 138K

Publishing Venue

IBM

Related People

Lewis, JR: AUTHOR

Abstract

One major problem in client server schemes is that of provision of servers on demand. The usual situation encountered with client/server middleware, such as the Open Software Foundation's Distributed Computing Environment (DCE), is that a server must be running before a client can contact and use it. Typically, a server can handle requests from multiple clients.

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

Providing Distributed Computing Environment Servers on Client Demand

      One major problem in client server schemes is that of provision
of servers on demand.  The usual situation encountered with
client/server middleware, such as the Open Software Foundation's
Distributed Computing Environment (DCE), is that a server must be
running before a client can contact and use it.  Typically, a server
can handle requests from multiple clients.

      Whilst this is acceptable for many applications, there are some
situations in which it causes significant difficulties.  For example,
if a request from one client takes a considerable time to execute,
requests from other clients may have to wait.  This waiting and
serialisation on the server may be overcome if the server supports
multi-threading.  Even so, there are limits to the degree of
parallelism available this way.  In DCE, for example, the maximum
number of threads which the server can use has to be set when the
server starts executing.  It cannot be changed subsequently.  If more
clients are active than there are threads to process their requests,
requests become queued and have to wait.  Wait times depend on the
length of the operations already in progress.

      In addition, the standard DCE approach requires that the server
be multi-threaded.  Whilst this may be true of new applications, it
is often not true for legacy applications which customers may wish to
convert to the client/server model using DCE.

      One solution to this problem is to have a set of equivalent
servers to which connection can be made.  For those servers which
cannot tolerate multi-threading, single threading can be specified.
DCE provides techniques for randomly selecting one of a number of
equivalent servers for a particular client to use.  The drawback here
is that the maximum number of servers is fixed.  They will always be
running, whether or not there is anything for them to do, consuming
system resources.

      A more flexible approach to the provision of free servers is
the one used by CICS/6000, which maintains a pool of servers,
monitoring the use of these servers and stopping them or starting
more depending on the system load.  This is a very sophisticated load
balancing and scheduling scheme.  Whilst appropriate to a system,
like CICS, which has scheduling as one of its core functions, it is
not a generally applicable solution for simpler systems or even
specific applications.

      The approach described here was developed for the DCE
environment and uses DCE terminology.  It may, however, be applicable
to any client/server scheme in which a concept similar to the DCE
bind exists.

      The fundamentally new element in the scheme is that clients do
not initially contact the server they wish to use.  Instead, they
contact a server termed a bind server (Fig. 1).  The bind server is
contacted in the normal way, typically via its entry in the DCE
namespace. ...