GB2360369A

GB2360369A - A system for distributing requests from one or more clients amongst a plurality of server processes

Info

Publication number: GB2360369A
Application number: GB0005891A
Authority: GB
Inventors: Robert Martin Mitchell; Michael Peter Monschau
Original assignee: OMNIS TECHNOLOGY CORP
Current assignee: OMNIS TECHNOLOGY CORP
Priority date: 2000-03-10
Filing date: 2000-03-10
Publication date: 2001-09-19
Also published as: GB0005891D0

Abstract

A system for distributing requests from one or more clients amongst a plurality of server processes includes functions for receiving requests at servers and extracting the identification of a group of servers from the request. A load sharing process at the server then determines to which of the servers the request should be passed. Various methods for determining which server is least busy are disclosed, they include the use of server process statistics such as: number of connections, maximum number of concurrent connections allowed to, number of requests issued, time elapsed processing requests, etc. One embodiment includes arranging groups of server processes into logical sub-groups using various server process statistics, the load sharing then being performed at sub-group level. The stated field of the invention is computer software development and application deployment over the internet the implementation preferably using object oriented programming.

Description

2360369 F:\CLIENTS\OMNIS\drafts7\41539.001 COMPUTER APPLICATION

DEVELOPMENT AND DEPLOYMENT

FIELD OF THE INVENTION

The present invention relates to rapid development and deployment of computer applications. In particular, the invention relates to fulfilling requests at a server computer.

BACKGROUND OF THE INVENTION

Techniques exist for developing computer software applications and also for deploying applications, for example by publishing HTML pages over Internet Protocol on the World Wide Web. The present invention relates generally to these two fields.

Object Oriented (00) programming is well known and involves certain key concepts that will be discussed by way of background. These techniques are well known to those skilled in the art, but will be explained nonetheless for consistency of terminology when describing the embodiment of the invention later.

An object is a software bundle of related variables and methods. software objects are often used to model realworld objects found in everyday life, and are used to represent such real world objects through the variables and methods. Variables represent the state of an object (e.g. name, colour, etc.) whereas methods represent behaviour (e.g. moving, flashing, etc.). Variables are the principal container of data, and methods are pieces of code that perform an action when interacting with the object. Objects are created from templates known as classes. An object is said to be an instance of a class. Accordingly, an object is sometimes simply referred to as an instance.

software objects can, therefore, model real world objects through variables and methods. In addition, software objects are used to model abstract concepts. For example, an event is a common object used in Graphical User Interface (GUI) window systems to represent the action of a user pressing a key on a keyboard.

A single object alone is not very useful and needs to interact with other objects to provide functionality of a larger program or application. Software objects interact and communicate with each other by sending messag-,s to each other. For example, when Object A wants object B to perform one of B's methods, object A sends a message to Object B. A message comprises:

1. The object to whom the message is addressed 2. The name of the method to perform 3. Any parameters needed by the method These three parts of a message provide enough information for the receiving object to perform the desired method. No other information or context is required. An object,s behaviour is expressed through its methods which are supported by message passing. As a result, objects do not need to be part of the same process, or even on the same machine, to send and receive messages between each other.

To provide reusability of code, and facilitate creation of objects, the definitions of variables and methods common to objects of a certain kind are stored as a class. A. class is, therefore, a blueprint that defines the variables and methods common to all objects of a certain kind. In a real world example, a particular bicycle is an object which is an instance of the class of objects known as bicycles. All bicycles have common methods and variables. To create a particular object one creates an instance of the class of objects or, in other words, one instantiates the class.

The values for instance variables are provided by each instance of the class. When instantiating the class (creating an instance of it), an object of that type is created and the system allocates memory for the instance variables defined by the class. Then you can invoke the objects, instance methods to make it do something. Instances of the same class in general share the same instance method implementations (methods are not duplicated on a per object basis) which reside in the class itself.

4 In addition to instance variables and methods, classes can also define class variables and class methods. Class variables and methods can be accessed from an instance of the class, or directly from the class itself. A system has a single copy of class variables for a class, and all instances of the class share the class variables. If one object (an instance of a class) changes a class variable, then that variable changes for that class, and all objects of that class.

Object Oriented systems also allow classes to be defined in terms of other classes. This brings in the concept of superclass and subclass. Each subclass inherits variables from the superclass (e.g. mountain bikes and. racing bikes have variables of speed, etc. from the superclass bicycles) and also inherits methods (e.g. braking) from the superclass. Subclasses can also have additional variables and methods in addition to those inherited from the superclass. An inheritance tree, or class hierarchy, can be as deep as needed, but in practice the depth is limited for practical reasons.

With the discussion of 00 techniques as background for consistency of terminology, a known application development system will now be described. To simplify discussion, the terminology used from now on will refer to classes and instances.

BRIEF DESCRIPTION OF A KNOWN SYSTEM

A known 00 system for application development is named OMNIS Studio of OMNIS Software, Inc. OMNIS Studio 2.x is a Rapid Application Development (RAD) environment that supports 00 development as well as providing access to a full range of databases and Internet services.

The building of an application involves assembling various building blocks or components, including:

an executable program one or more library files data access modules (DAMs) for server database access data files for local data access The key parts of the application are the executable and the library files. The executable directs instances in an application and provides the Integrated Development Environment (IDE) in which to design an application. It also provides the runtime environment in which a finished application runs. The main component in an application is the library file, and so the next part of the description will concentrate on a discussion of libraries.

The system uses many of the concepts and terms from 00 Programming, including messaging, inheritance, and code reuse.

Developing an application is all about creating the right instances and implementing how these instances interact with each other and the end user. A library can contain definitions of many different types of data and GUI instances including windows, menus, toolbars, and.reports.

The definition for each of these instances is stored in the library as a separate class. Some classes are never instantiated and simply provide templates such as file formats.

The system provides several tools that let you create and examine the libraries and classes in an application. The main tools that let you do this are the Browser and the Component Store.

The Browser can create libraries and classes, examine existing libraries and copy classes from one library to another. The Component Store contains templates for classes and controls (controls are defined below). Classes are thus gathered together as libraries. To create instances of a class the relevant class is instantiated, or put another way, the class is opened.

Controls provide the user interface element of an application. Examples of controls are data entry fields, lists, and push buttons. Controls are contained in a class, and when the class is instantiated, an instance of the control is also created. Only certain types of class can contain controls. You add a control to a class using the Component Store.

Every instance has certain characteristics that define exactly how it looks and behaves. These are called its properties. Properties of an instance might include its name, type, colour, size, border style, visibility, and so on. Every library has its own set of properties, classes - 7 have their own properties, and individual instances such as controls on a window have properties as well. Some properties are common to all instances, such as name, and some are unique to a specific type of instance.

Instances also contain methods, as previously described, which are pieces of code that perform some action when you send the instance the appropriate message. For example, window classes contain a method to construct the class. In this case, when you open the window the construct method is executed which initialises the window.

Instances contain default methods, but further methods can be added that either add to the instances's functionality or-override its standard behaviour. You use the method editor to add methods to an instance. Methods contain commands that define exactly what the method does. The system has over 400 commands that do everything from opening a window, installing a menu, printing a report, to responding to events in your application.

Methods can be added to most types of class and the controls within the class. For example, you can add methods to a window and to each of the controls on the window, and you can add methods to a toolbar class and put methods behind each of its controls.

The principal data container is the variable. Most instances can contain variables but their scope and the kind of data they can contain depends on the variable type. Variables can be added to most types of class.

Such class variables are visible only within that-class, and their values are available to all the methods in the class. Also you can add variables to any method. These are called local variables, and are available only to the method in which they are defined. You add variables to an instance using the method editor.

An instance is what you create when you open or instantiate a class. For example, you create an instance of a window when you open a window class. When you print a report you create an instance of a report class, and similarly when you install a menu you create an instance of a menu class. When you open an instance of a class it inherits all the properties, methods, and variables from the class. In addition to class variables, each instance can contain instance variables; these are defined in the class using the method editor. You can create multiple instances of most types of class, which means each instance can have its own set of instance variable values. For example, you can create multiple instances of the same window class and display different data values in each separate window instance.

A task is a runtime container for the instances in your application. Instances of any class must always be opened in a task. Since instances are owned by the tasks in which they are running, manipulating the task manipulates all instances owned by the task. In this way you.can hide and show all the instances or close all the current instances belonging to a particular task.

- 9 The essential components of any 00 Programming system are the instances in that system and the messages sent to and from those instances. A message is an instruction to do something to an instance, such as open, close, print, or redraw the instance. Messages are sent to and from the various instances in an application using commands and a standard notation. The notation for messages will not be described in detail here. Messages are provided, for example, to change the background colour of a window instance you would sent the $backcolor. $assign() message with a colour value as a parameter. As well as assigning to an instance, you can return information from an instance using messages. For example, you could find out the background colour of a window instance by returning the value of its colour property. You do this using similar notation.

Any user action that occurs in the system is reported as an event message. The key to creating an event-based application is in the methods you write to intercept or handle these events. These methods are called event handling methods and you would normally put them behind controls and windows, or place them in the tasks in your library. When the user generates an event, a message is sent describing the event. Usually this message is a simple predefined code for the event. Depending on where the event occurs it is intercepted by an event handling method. For example, if the user clicks on a f ield, a simple click event is generated and the event handler for the field is called. The event handling method can modify the default action for the event or redirect method execution to anywhere else in your application. Alternatively, the event handler may discard the event altogether or pass it on to the next method in a series or chain. Most instances including window controls and classes, toolbar controls, and menu lines contain a default event handling method, while window classes and tasks can contain a method as a further level of control. These methods contain the code that handles events passed to the instance.

When creating a new class, instead of having to set up all its properties and methods you can derive it from an existing class. The new class is said to be a subclass of the existing class, which is in turn a superclass. In this way you can create a hierarchy of classes, each class being a subclass of the one above it in the chain. The real advantage of inheritance is that a subclass takes on or inherits all the properties, variables and methods of its superclass. And in the case of a window, menu and toolbar subclass, it inherits all the controls or menu lines of the superclass as well. This saves time and effort when you develop your application, since you can reuse the controls or menu lines from the superclass. when you make a change in the superclass, all its subclasses inherit the change automatically. In addition to its own inherited properties and methods, you can add methods and any other controls or menu lines to the subclass. You can view the inheritance structure for all the classes in your library using the Inheritance Tree.

The description above provides an explanation of known 00 techniques in application design. The main job of application design is to create the classes that define the data structures, data entry windows, reports, menus, and other user interface elements in your application. These classes are stored in your library file. You can create many different types of class in your library. You can create classes either from the Browser or by dragging templates from the Component Store. The Component Store contains a number of templates and wizards that you can use to create classes. Each library file contains a number of system tables and preferences that control the behaviour of your library and its contents. A library has certain properties too, which you can examine andchange using the Property Manager. You can create and open any number of library files and each library can contain any number of classes. In fact you may want to split your whole application into one or more libraries and store different types of classes in different libraries. A client application is, from the user's point of view, a collection of windows or forms in which they enter or view their data. You define the appearance and behaviour of each window in your application as a separate window class. Each window class can contain a number of controls which you can create from the Component Store.

The Component Store contains a number of window templates and wizards for you to use as a basis for your window classes. You can also add your own templates to the Component Store and change the default ones.

In summary, the known system provides 00 application

12 - design by allowing a designer to select GUI classes and gather them as a library of classes for instantiation as instances. The main class, from a user's point of view, is the window class. As with other classes, these can be selected and modified from a Component Store from which all classes are selected. The functionality provided by an application can thus be constructed using existing classes, such as toolbars and windows, and existing controls such as buttons, selected from a Component Store to build a library of classes. The properties, variables and methods of any such instance instantiated from a class can be configured to provide the required functionality of an application. The known system thereby provides rapid application development with re-usable code and extendable design.

The system described so far provides an excellent 00 approach to application design and deployment. Nonetheless, we have appreciated that improvements could be made.

SUIVY OF THE INVENTION A problem has been appreciated in deploying an application to a server. A plurality of clients connecting to a server running an application will request services from a server process. A server may actually comprise a group of server processes running on different machines, and a client request will connect to one such server process. once connected, subsequent requests for that client are dealt with by the same server process. However, this can result in a server process becoming overloaded. We have appreciated that improvements can be made to such systems.

In particular, the invention provides a system for distributing requests from one or more clients amongst a plurality of server processes, comprising: means for receiving a request at a server system; means for extracting from the request an identification of a group of server processes; a load sharing process for determining a selected server process of the group of server processes to which the request should be passed; and means for passing the request to the selected server process; wherein the load sharing process determines the selected server process as a function of which server process is least busy.

This system provides the advantage that client requests are dealt with more efficiently leading to a faster, more reliable system.

In an embodiment, the load sharing process comprises means for determining which server process is least busy as a function of the number of connections to each server process of the group of server processes, or as a function of the maximum number of concurrent connections allowed to each server process, as a function of the number of requests issued to each server process, or as a function of the time elapsed to process requests at each server process. These alternatives may also be used in combination and provide efficient ways of determining the appropriate server process to deal with a request.

In the embodying system the load sharing process comprises; means for arranging a group of server processes into logical sub groups based upon the average time for each server process to process a request; means for determining the sub-group of server processes having free connections that has the lowest average time to process a request; and means for determining which server process of the sub-group of server processes having free connections with the lowest average time to process a request'has the smallest percentage of connections in use.

BRIEF DESCRIPTION OF THE FIGURES

An'embodiment of the invention will now be described, by way of example only, and with reference to the accompanying figures in which:

Figure 1 is a screen print of a component store and library of an 00 system embodying the invention; Figure 2 is a screen print of an application designed using an 00 system embodying the invention as deployed on the web; Figure 3 is a screen print of a second application designed using an 00 system embodying the invention as deployed on the Web; Figure 4 is a graphical representation of a communication process for application designed using an 00 system embodying the invention may be achieved; Figure 5 is a graphical representation of two ways in which connection to an an application designed using an 00 system embodying the invention may be achieved; Figure 6 is a graphical representation of the load sharing process as related to the preferred embodiment; and Figure 7 is a flow diagram showing the handling.of a connection using load sharing.

DETAILED DESCRIPTION OF AN EMBODIMENT OF THE INVENTION

The embodiment of the invention described is based on one product of OMNIS Technology Corp, known as OMNISTM Studio 3. 0. and its Web Client component. In broad terms, this product provides Rapid Application Development and Deployment on the World Wide Web (Web for short). In this context the Web also encompasses an Intranet running Transmission Control Protocol over Internet Protocol (TCP/IP). The Web uses HyperText Markup Language (HTML) to publish material in a standard format. The present embodiment can work alongside HTML.

The system embodying the invention is written in C++ (itself an 00 language) and comprises, from a user's point of view, a GUI through which an application may be developed. The development of an application using the system requires either:

an Intel Pentium processor - based PC or compatible with Windows 95, Windows 98 or Windows NT4 or later 50 MB disk space required or a Power Macintosh with Macintosh System 8.0 or later 50 MB disk space required; or an Intel Pentium processor - based PC or compatible with Linux RedHat 6.0 or later Caldera 2.3 or later SuSE 6.2 or later 50 MB disk space required.

other hardware/ software combinations may be appropriate.

The system provides a package having a Component Store of classes such as types of window, toolbars or menus. As previously described, developing an application using an 00 system involves creating the right instances and implementing how these instances interact with each other and the end user.

A library can be used to store the definitions of many different types of data and GUI classes including windows, menus, toolbars, and reports. The Component Store and library are shown in figure 1.

To design a new application, a user simply selects a graphical representation of a class from the component store and moves this to the library. The methods and properties of the class can then be altered according to the functionality required of the class using a method editor and Property Manager. These techniques are similar to those previously described in relation to the preceding brief description of a known system, and will not be repeated here.

The present system allows creation of a new type of class to facilitate deployment on the Web. This class is named the Remote Form Class. The system provides for design of remote forms that users can access and display in a Web browser. A remote form is a class that contains all the necessary controls to display data and allow users to interact with an application and database via the Web. Once connected a remote form posts events to a server application, which in turn sends results back to the client. An existing 00 designed application can be adapted for Web access by adding remote forms and adding one or two components to an existing Web server and network infrastructure.

Figures 2 and 3 show examples of remote forms constructed using the system. As can be seen, the example remote forms provide access to functionality of an underlying application, such as the image catalogue of figure 2, or the bookstore of figure 3.

The system has two main parts: the Client and the Server. The client is an end-user's Web browser which they use to access and view Web pages containing a Web Client. The client is embedded in an html page which in turn displays the remote form(s) stored in a library located on the server.

The server side of the system comprises a Web server, and an application server, that is, an application and a runtime engine, and database. These are shown, along with the client side, in figure 4.

To access an application at any time, from anywhere in the world, the user only requires a standard Web browser. The first time a user accesses the application they need to download and install the Web Client. Having installed the Web Client, the user would navigate to the appropriate page(s) on a Web site containing the application.

The Web Client is an ActiveX or Netscape plug-in that you can place in an html page. You could however use the Web Client in any development environment that supports ActiveX. On a Windows client machine, the Web Client uses the Wininet API to communicate with the web server extension via HTTP, or HTTPS if secure transmission is required. Communications between the OMNIS Web server extension and the Runtime and library is via TCP/IP.

To use an application via the web, a user must download and install the Web Client. This is a one-time operation. When the user accesses the application in their browser, the Web Client is activated and a connection is established with the server extension on the Web server once a connection is established, the Web Client - 19 receives the remote form class plus all the instance variable data, icon pages, font tables, etc, which it gets from the library. The Web Client instantiates the visual instance of the remote f orm, and all its controls, and the user can now use the f orm. As previously described, an instance is what you create when you open or instantiate a class.

You can monitor and control what happens in the form by monitoring the events triggered by the user while using the form. For example, an event is generated in the form when the user clicks on a form field, when they select a line in a list, press a button, or tab from field to field. You can detect and respond to an event by creating an event handling method stored with the object in the remote form. When an event is triggered, it is sent from the client to the server application and the event handling method for the object is executed. The method could do anything you want, for example, it could save the data in the f orm to a database, or return the result of a calculation to the client. By default all events are turned off in a remote form to cut down needless traffic, but you can enable specific events for each form control.

The server side of the system comprises a Web server, a Web server extension, the runtime or executable, the application, and your data source, either a bespoke database or proprietary server database. All these various server pieces may or may not be located on the same machine, but typically they would be on the same LAN.

The system uses a stand-alone, industry- standard Web server. Web server software is available from many different third-parties, including Web servers downloaded from the Internet. The Web server manages the html pages containing the Web Client, giving access to the application. Using a search engine on the Internet, you can search for "Web server software,, to find many hundreds of sources for a suitable Web server.

The Web server also requires a Web server extension, that handles communications between the client and the application. The Web server extension is a piece of software that sits on your Web server, and listens for and queues any requests from the Web Client in the user's Web browser. Similarly, it passes any results sent from the server back to the Web Client in the user's Web browser. The Web server extension is typically installed inside the cgi-bin folder of the web server.

To complete the system the server-side uses a Runtime executable, and library containing remote forms and any necessary business logic and reporting capabilities. The Runtime and your library reside on the Web Server, or a machine local to your Web server.

Remote form classes are designed as described above using an 00 development environment. You can debug or test your remote forms during development using your own Web browser; note that in this case, you do not need a web server in order to test your remote f orms. There are many types of controls you can use in your remote forms. The form controls, and include pushbuttons, single and multiline edit fields, radio buttons, check boxes, sidebars, list boxes, drop lists, and combo boxes. In addition, you can use the built-in page pane control in your remote forms.

The remote forms and any necessary business logic.for the system arestored in a library file. The remote forms are stored as remote form classes. In addition you create a remote task class to handle the connection to each client.

A remote task is a type of class that handles the connection between a remote form instantiated on the client and the server application, and in some cases performs some server-side event handling and processing. Therefore, all remote forms require a remote task. You need to create a remote task to use in conjunction with a remote form.

A task is a runtime container for the instances in your application. Instances of any class must always le opened in a task. Since instances are owned by the tasks they are running in, manipulating the task manipulates all instances owned by the task. In this way you can hide and show all the instances or close all the current instances belonging to a particular task.

The Web Client plug-in uses communication channels supplied by the browsers, so all traffic to and from web Client and a Web server can be secure. Security is achieved by using a secure Web server. The page hosting the Web Client control does not have to be secure, but the Web server that Web Client talks to does if security is an issue. These are shown in f igure 5.

A system adapted to embody the invention is shown in figure 6. Load sharing allows a pool of multithreaded server processes, running on one or more machines, to serve clients. Once a client connects to a server process, all subsequent requests for that client need to be handled by the same server process. This is because that server process will have retained details of the last request in memory, such as the remote form class described above.

The present system, therefore, provides a mechanism that assigns a new client connection to a server process in an efficient manner.

In the 00 system described, the server property in an HTML page currently has the syntax [(IP addressIdomain name): 1 (service name 1 port number).

To use load sharing, the server is prefixed with a name for the pool of server processes and a comma, for example 11OMNIS,600011, or "OMNIS,194.131.70.197:6000". In this case, the address information in the property no longer addresses an OMNIS server. Instead, it addresses a new module, a load sharing process 10. The logical structure of the load sharing process is shown in Figure 6. As can be seen, an incoming connection at a WebServer is referred to the load sharing process 10 prior to establishing the connection with the chosen server process.

The actions upon receiving a request are shown in Figure 7. When a new connection arrives at the Web server extension 12, means for receiving the request in the form of a receiver Module 12 receives the request and an extraction Module 12 extracts the new syntax of the Server property. If it is prefixed by a pool name, the extension establishes a connection 14 to the load sharing process, and sends it a message that asks for the address of a server process in the pool. If there is no load sharing process identified, an output 18 sends the request directly to the server.

The load sharing process 10 received the request at a receiver 16 and typically returns the address and port number of the least busy process in the pool.

The extension then connects to this process, and sends the Web Client connect request to it. When the extension responds to the client, it includes the address of the server process in the response.

When the client sends subsequent messages to the Web server for this Web Client connection, it sends the address returned in the connect response instead of the Server property. Thus the only additional overhead imposed by load sharing occurs during connection setup.

The system embodying the invention also provides a mechanism to determine:

1. Which server processes exist; and 2. Which server process is the least busy When configuring the system a file is created (a ini file), which contains the pool names for the pools for which the load sharing process is responsible, and for each pool, the addresses of the server processes in the pool. Periodically, the load sharing process polls each server process, and asks it for the percentage of Web Client connections currently in use (using the serial number as the maximum), and if available, an estimate of its CPU utilisation. The load sharing process combines this information to determine which process is the least busy.

The time interval between polls of each server pr;Dcess is configurable via the ini file. Typically, polling once every 10 or 20 seconds will be frequent enough.

When the load sharing process periodically polls the processes in a pool of Server processes, each server returns the following information:

the current number of connections to the server the maximum number of concurrent connections allowed to the server (from the serial number) the number of requests (mainly events or new connections) received since the last poll the total elapsed time in milliseconds taken to process the requests The load sharing process organises the servers into groups, based on the results of the information returned from polling the servers.

It maintains a conf igurable number of groups (N), numbered 0 to (N-1) Using a bucket size (B milliseconds), and the average time to process a request (T), calculated from the results of the most recent poll, a server is in group G if and only if:

GB ≤ T and T < (G+l)B One exception is that if T ≥ NB, then the server belongs to group N-1.

Thus, the servers are organised into groups based on how busy they are.

When a connection request arrives at the load sharing process, it allocates a server to the request using an allocation subroutine 20 as follows. It traverses the groups, from 0 to N-1, looking for a server that has some free connections using identification Module 22. Within a group, it looks for the server with the smallest percentage of connections in use, using the results of the last poll. A percentage connection Module 24 determines whether the connection percentage for a server is less 26 than 100. If not, the next server and group is selected for analysis 26. If no groups are found, an error 28 is returned. If there is more than one server at Module 30 with the same smallest percentage of connections in use, then the process allocates the connection to the server to which it least recently allocated a connection at step 32. If there is only one server 34, this is selected. At this point, the load sharing process also updates the connection statistics from the last poll, to reflect the new connection. The traversal stops when a free process has been found, or if all servers are fully utilised, after all groups have been inspected. In the latter case, failure to locate a suitable server will result in the client's attempt to connect being rejected. The chosen server is returned by means for passing the request to the chosen server by return Module 36 to the plugin.

Claims

1. A system for distributing requests from one or more clients amongst a plurality of server- processes, comprising; - means for receiving a request at a server system; - means for extracting from the request an identification of a group of server processes; - a load sharing process for determining a selected server process of the group of server processes to which the request should be passed; and - means for passing the request to the selected server process; - wherein the load sharing process determines the selected server process as a function of which server process is least busy.

2. A system according to claim 1, wherein the load sharing process comprises means for determining which server process is least busy as a function of the number of connections to each server process of the group of server processes.

3. A system according to claim 1 or 2, wherein the load sharing process comprises means for determining which server process is least busy as a function of the maximum number of concurrent connections allowed to each server process of the group of server processes.

4. A system according to claim 1, 2 or 3, wherein the load sharing process comprises means for determining which server process is least busy as a function of the number of requests issued to each server process of the group of server processes during a time interval.

5. A system according to claim any of claims 1 to 4, wherein the load sharing process comprises means for determining which server process is least busy as a function of the time elapsed to process requests at each server process of the group of server processes.

6. A system according to any preceding claim, wherein the load sharing process comprises; - means for arranging a group of server processes into logical sub groups based upon the average time for each server process to process a request; - means for determining the sub-group of server processes having free connections that has the lowest average time to process a request; and - means for determining which server process of the sub-group of server processes having free connections with the lowest average time to process a request has the smallest percentage of connections in use.

7. A computer program product having stored thereon a computer program for causing a process at a server computer, in a client server system in which a plurality of clients connect to the server:

- to receive a request at a server system; - to extract from the request an identification of a group of server processes; - to execute a load sharing process for determining a selected server process of. the group of server processes to which the request should be passed as a function of which server process is least busy; and - to pass the request to the selected server process.

8. A computer program product according to claim 7, wherein the load sharing process is configured to determine which server process is least busy as a function of the number of connections to each server process of the group of server processes.

9.. A computer program product according to claim 7 or 8, wherein the load sharing process is configured to determine which server process is least busy as a function of the maximum number of concurrent connections allowed to each server process of the group of server processes.

10. A computer program product according to claim 7, 8 or 9, wherein the load sharing process is configured to determine which server process is least busy as a,function of the number of requests issued to each server process of the group of server processes during a time interval.

11. A computer program product according to claim 7 to 10, wherein the load sharing process is configured to determine which server process is least busy as a function of the time elapsed to process requests at each server process of the group of server processes.

12. A computer program product according to claim 7 to 11, wherein the load sharing process is configured to:

- arrange a group of server processes into logical sub groups based upon the average time for each server process to process a request; - determine the sub-group of server processes having free connections has the lowest average time to process a request; and - determine which serve r process of the sub-group of server processes having free connections with the lowest average time to process a request has the smallest percentage of connections in use.

13.' A method for distributing requests from one or more clients amongst a plurality of server processes, comprising: receiving a request at a server system; extracting from the request an identification of a group of server processes; - determining a selected server process of the group of server processes to which the request should be passed as a function of which server process is least busy; and - passing the request to the selected server process.

14. A method according to claim 14, wherein the step of determining comprises determining which server process is least busy as a function of the number of connections to each server process of the group of server processes.

15. A method according to claim 13 or 14, wherein the wherein the step of determining comprises determining which server process is least busy as a function of the maximum number of concurrent connections allowed to each server process of the group of server processes.

16. A method according to claim 13, 14 or 15, wherein step of determining comprises determining which server process is least busy as a function of the number of requests issued to each server process of the group of server processes during a time interval.

17. A method according to claim any of claims 13 to 16, wherein the wherein the step of determining comprises determining which server process is least busy as a function of the time elapsed to process requests at each server process of the group of server processes.

18. A method according to any preceding claim, wherein the step of determining comprises; - arranging a group of server processes into logical sub groups based upon the average time for each server process to process a request; - determining the sub-group of server processes having free connections that has the lowest average time to process a request; and - determining which server process of the sub-group of server processes having free connections with the lowest average time to process a request has the smallest percentage of connections in use.