the invention may be run on a variety of computers or collection of computers under a number of different operating systems . the computer could be , for example , a personal computer , a mini computer , mainframe computer or a computer running in a distributed network of other computers . although the specific choice of computer is limited only by memory and disk storage requirements , computers in the ibm ps / 2 series of computers could be used in the present invention ( ibm is a registered trademark and ps / 2 is a trademark of ibm corporation ). for additional information on ibm &# 39 ; s ps / 2 series of computers , the reader is referred to technical reference manual personal system / 2 ( model 80 ) ibm corporation part no . 68x 2256 order number s68x - 2254 . one operating system which an ibm ps / 2 personal computer may run is ibm &# 39 ; s os / 2 2 . 0 , for more information on the ibm os / 2 2 . 0 operating system the reader is referred to os / 2 2 . 0 technical library , programming guide vol . 1 , 2 , 3 version 2 . 00 order nos . 10g6261 , 10g6495 , 10g6494 ( os / 2 is a trademark of ibm corporation ). in the alternative , the computer system might be in the ibm risc system / 6000 line of computers which run on the aix operating system ( risc system / 6000 and aix are trademarks of ibm corporation ). the various models of the risc system / 6000 are described in many publications of the ibm corporation for example , risc system / 6000 , 7073 and 7016 powerstation and powerserver hardware technical reference , order no . sa23 - 2644 - 00 ( powerstation and powerserver are trademarks of ibm corporation ). the aix operating system is described in general concepts and procedure -- aix version 3 for risc system / 6000 order no . sc23 - 2202 - 00 as well as other publications of the ibm corporation . in fig2 a computer 10 , comprising a system unit 11 , a keyboard 12 , a mouse 13 and a display 14 are depicted in block diagram form . the system unit 11 includes a system bus or plurality of system buses 21 to which various components are coupled and by which communication between the various components is accomplished . the microprocessor 22 is connected to the system bus 21 and is supported by read only memory ( rom ) 23 and random access memory ( ram ) 24 also connected to system bus 21 . a microprocessor in the ibm ps / 2 series of computers is one of the intel family of microprocessors including the 386 or 486 microprocessors . however , other microprocessors including , but not limited to , motorola &# 39 ; s family of microprocessors such as the 68000 , 68020 or the 68030 microprocessors and various reduced instruction set computer ( risc ) microprocessors such as the powerpc chip manufactured by ibm , or other microprocessors from hewlett packard , sun , motorola and others may be used in the specific computer . the rom 23 contains among other code the basic input - output system ( bios ) which controls basic hardware operations such as the interaction and the disk drives and the keyboard . the ram 24 is the main memory into which the operating system and application programs are loaded . the memory management chip 25 is connected to the system bus 21 and controls direct memory access operations including , passing data between the ram 24 and hard disk drive 26 and floppy disk drive 27 . the cd rom 32 also coupled to the system bus 21 is used to store a large amount of data , e . g ., a multimedia program or presentation . also connected to this system bus 21 are various i / o controllers : the keyboard controller 28 , the mouse controller 29 , the video controller 30 , and the audio controller 31 . as might be expected , the keyboard controller 28 provides the hardware interface for the keyboard 12 , the mouse controller 29 provides the hardware interface for mouse 13 , the video controller 30 is the hardware interface for the display 14 , and the audio controller 31 is the hardware interface for the speakers 15a and 15b . an i / o controller 40 such as a token ring adapter enables communication over a network 46 to other similarly configured data processing systems . in one of the preferred implementations of the invention the set of instructions 48 - 52 , previously described with reference to fig1 resident in the random access memory 24 of one or more computer systems configured generally as described above . until required by the computer system , the set of instructions may be stored in another computer memory , for example , in the hard disk drive 26 , or in a removable memory such as an optical disk for eventual use in the cd - rom 32 or in a floppy disk for eventual use in the floppy disk drive 27 . the memory address spaces coupled together by means of the orbs can be resident in separate systems communicating over the network 46 or can be two or more address spaces 53 , 54 in the memory of a single computer system as depicted in fig2 . referring to fig3 in the present invention , a bridge 300 is introduced between the client 53 and the server 54 . the purpose of the bridge 300 is to receive requests from the client 53 destined for the server 54 , forward the requests to the server 54 , receive replies from the server 54 destined for the client 53 and forward the replies to the client 53 . the bridge 300 presents an interface to the client 53 corresponding to that of the server 54 and an interface to the server 54 corresponding to that of the client 53 . in this way , neither the client 53 nor the server 54 can determine the existence of the bridge 300 and both operate as if it were not there . two embodiments of the invention are described , one for operation in an asynchronous environment and one for operation in a synchronous environment . in an asynchronous environment ( shown in fig5 ), the client 53 continues other processing whilst waiting for a reply from the server 54 . in a synchronous environment ( shown in fig8 ), client 53 waits for a reply from server 54 before continuing processing . referring again to fig3 which includes the components parts of a bridge 300 for use with a client and server operating in an asynchronous mode . the client 53 , the bridge 300 and the server 54 all include , what in dsom terminology is called a server object . these are shown respectively as client &# 39 ; s server object 404 , bridge &# 39 ; s server object 301 and server &# 39 ; s server object 501 . these objects are not to be confused with the functions which a server performs or with the server itself . a server object is an object which manages objects within a server to allow client applications to create and destroy objects in servers . it also identifies which object within a server should handle a request and dispatches such requests , received by it for the server , to the identified object for execution . client 53 contains at least one object called the client &# 39 ; s object 403 , which is the initiator in the client of the request for service to be provided from the server 54 . a client application ( not shown ) makes calls to client &# 39 ; s object 403 to perform operations on data . these operations are either completed locally within the client &# 39 ; s object 403 itself , or they are completed remotely by means of the client &# 39 ; s object 403 requesting services from a server 54 . server 54 contains at least one object called the server &# 39 ; s object 503 ( not to be confused with a server object ). this corresponds to a target object described earlier with reference to fig1 and 2 . this is the object that actually provides the services which are requested by the client &# 39 ; s object 403 . bridge 300 contains an object called the bridge &# 39 ; s object 304 which provides the functions of the bridge itself . the client 53 , the bridge 300 and the server 54 all include , what in dsom terminology are called proxy objects . a proxy object is an object that is a local representative for a remote target object . a proxy object inherits the target object &# 39 ; s interface , so that it responds to the same methods . methods invoked on the proxy object are not executed locally , but are forwarded to the real target object for execution . a program running in a client always has a local proxy object , in the client , for each remote object , in a server , on which it operates . the proxy object contains , within it , a pointer to the memory location in the server where the target object is located . the proxy object is created by the dsom run - time environment whenever a request is made to a remote server to invoke a method on a remote object . client 53 contains a proxy object called bridge &# 39 ; s server proxy 401 which is the local representative of the bridge &# 39 ; s server object 301 . the client believes that this represents the server &# 39 ; s server object 501 in the server providing the services . similarly , bridge 300 contains a proxy object called server &# 39 ; s server proxy 302 which is the local representative of the server &# 39 ; s server object 501 . as was explained above a server object is an object which manages objects within the server . client 53 also contains a proxy object called bridge &# 39 ; s object proxy 402 which is the local representative of the bridge &# 39 ; s object 304 . the client believes that this represents the object 503 in the server providing the services . similarly , bridge 300 contains a proxy object called server &# 39 ; s object proxy 303 which is the local representative of the server &# 39 ; s object 503 . these proxies are used in the communications between client 53 and server 54 which are initiated by the client 53 . in an asynchronous system , communications are also initiated by server 54 when it has a reply for the client 53 . these communications are achieved by means of a bridge &# 39 ; s object proxy 502 located in the server 54 enabling the server 54 to communicate with the bridge 300 and by means of a client &# 39 ; s object proxy 305 located in the bridge 300 enabling the bridge 300 to communicate with the client 53 . as can now be seen from the description above , the objects and proxy objects shown in fig3 located in the upper part of each of the blocks depicting client 53 , bridge 300 and server 54 are used in the creation , destruction and location of objects by the client and bridge . the objects and proxy objects shown in fig3 located in the lower part of each of the blocks depicting client 53 , bridge 300 and server 54 are used in the communication process between client 53 , bridge 300 and server 54 . fig4 shows the interactions between a prior art client and a prior art server via a prior art network in an asynchronous environment . in an asynchronous environment the client initiates a communication with the server by making a request of the server to provide a service . the server acknowledges the request and the client continues with other processing . the server may complete the request after a delay whilst it too may be completing other processing . when the server has completed the request it initiates another communication with the client by providing the client with a reply . this communication is initiated by the &# 34 ; server &# 34 ; effectively making a request to the &# 34 ; client &# 34 ;, that request being to accept the reply from the previous request . in these circumstances , it may be considered that the &# 34 ; server &# 34 ; and the &# 34 ; client &# 34 ; have reversed roles , with the server &# 34 ; requesting &# 34 ; the client to accept the reply . this is the reason why the client requires a server object when operating asynchronously . at step 310 , the client makes a request for a service to be provided from the server . this request is transmitted via a network to the server at step 320 . the server sends an immediate acknowledgement to the client at step 322 . the server accepts the service request at step 330 and proceeds to process the service request at step 332 . whilst the server is processing the request , the client is completing other processing at step 312 . the server may also be processing other requests prior to this request being processed . on completion of processing of the request at step 332 , the server sends a reply 324 to the client at step 334 . the reply is received at step 314 and the client continues processing . fig5 shows the interactions which occur when a bridge is inserted into the asynchronous system of fig4 . the interactions of the client at steps 310 , 312 and 314 are the same as in fig4 as are the interactions of the server at steps 330 , 332 and 334 . request 320 , immediate return 322 and reply 324 are split into corresponding responses between the client and the bridge and between the bridge and the server . the operation of the bridge in response to these interactions will now be described . a request 320a is transmitted from the client to the bridge at step 310 . the bridge sends an immediate acknowledgement 322a to the client at step 410 and the bridge accepts the service request 320a . instead of processing the request , the bridge records the client name at step 412 and completes any extra processing at step 414 . this extra processing may be any extra processing that it is desired to complete on the request from the client or on its associated data . such processing may make changes to the request or the associated data or it may leave it unchanged . examples of such processing include : 1 . the fact that the method detailed in the request was called with parameters equal to the data associated with the request may be logged ; 2 . processing may be done to determine which of a number of servers this request is to be routed to in order to perform workload balancing between servers , the results of such processing being used to determine where the request is routed to ; or 3 . the request may be checked to see which server the client thought that it was sending the request to , and then routed by the bridge to that server . at step 416 , the bridge forwards the service request 320b to the server . the server sends an immediate acknowledgement 322b to the bridge at step 330 . whilst the server is processing the request , the bridge is completing other processing at step 420 . on completion of processing of the request by the server at step 332 , the server sends a reply 324a to the bridge at step 334 . the reply is received at step 430 and any extra processing , such as logging the parameters returned from the server to the client is performed by the bridge at step 432 . the bridge then forwards the reply 324b to the client at step 434 . a bridge ( 300 in fig3 ) is derived from a client object and a server object by inheritance . this means that the interface ( that is all of the attributes and methods ) of both the client object and the server object are inherited by the bridge . example 1 shows how a bridge is defined in the idl language for an asynchronous system . ______________________________________ // define an asynchronous bridge class # include &# 34 ; server . sub .-- obj . idl &# 34 ; // declaration of serverclass # include &# 34 ; client . sub .-- obj . idl &# 34 ; // declaration of clientclass // the above lines include the methods and attributesof both the // server and client classes interface client . sub .-- server . sub .-- obj : client . sub .-- obj , server . sub .-- obj // the above line defines the interface of theasynchronous bridge // as having all of the feature of both a clientclass and // a server class { ______________________________________ referring to fig6 which includes the components parts of a bridge 300 for use with a client 53 and a server 54 operating in a synchronous mode . the bridge 300 and the server 54 include a server object . these are shown respectively as bridge &# 39 ; s server object 301 and server &# 39 ; s server object 501 . server 54 contains at least one object called the server &# 39 ; s object 503 ( not to be confused with a server object ). this is the object that actually provides the services which are requested by the client . bridge 300 contains an object called the bridge &# 39 ; s object 304 which provides the functions of the bridge itself . client 53 contains a proxy object called bridge &# 39 ; s server proxy 401 which is the local representative of the bridge &# 39 ; s server object 301 . the client believes that this represents the server &# 39 ; s server object 501 in the server providing the services . similarly , bridge 300 contains a proxy object called server &# 39 ; s server proxy 302 which is the local representative of the server &# 39 ; s server object 501 . as was explained above a server object is an object which manages objects within the server . client 53 also contains a proxy object called bridge &# 39 ; s object proxy 402 which is the local representative of the bridge &# 39 ; s object 304 . the client believes that this represents the object 503 in the server providing the services . similarly , bridge 300 contains a proxy object called server &# 39 ; s object proxy 303 which is the local representative of the server &# 39 ; s object 503 . these proxies are used in the communications between client 53 and server 54 which are initiated by the client 53 . in a synchronous system , communications are initiated only by the client 53 . these communications are achieved by means of the bridge &# 39 ; s object proxy 402 located in the client 53 enabling the client 53 to communicate with the bridge 300 and by means of a server &# 39 ; s object proxy 303 located in the bridge 300 enabling the bridge 300 to communicate with the server 54 . as can be seen from fig6 the objects and proxy objects located in the upper part of each of the blocks depicting client 53 , bridge 300 and server 54 are used in the creation , destruction and location of objects by the client and bridge . the objects and proxy objects located in the lower part of each of the blocks depicting client 53 , bridge 300 and server 54 are used in the communication process between client 53 , bridge 300 and server 54 . fig7 shows the interactions between a prior art client and a prior art server via a prior art network in an synchronous environment . in a synchronous environment the client initiates a communication with the server by making a request of the server to provide a service . the server completes the request and returns the result to the client through a simple return from processing the request . the server does not initiate a communication with the client to pass the reply back . the client 53 simply receives the reply via return parameters from the method which it invoked on the server 54 . in the prior art system , there are two differences between operation in an asynchronous environment described above with reference to fig4 and a synchronous environment . the first is that after the client has made a request for a service at step 310 , the client does not complete other processing at step 312 , but instead , at step 510 , waits for a reply from the server . the second is that the server does not send an immediate acknowledgement to the client at step 322 . otherwise , the numbered steps in fig7 are identical to the corresponding numbered steps in fig4 . fig8 shows the interactions which occur when a bridge is inserted into the synchronous system of fig7 . the interactions of the client at steps 310 and 314 are the same as in fig7 as are the interactions of the server at steps 330 , 332 and 334 . request 320 and reply 324 are split into corresponding responses between the client and the bridge and between the bridge and the server . the operation of the bridge in response to these interactions will now be described . at step 410 the bridge accepts the service request 320a . instead of processing the request , the bridge records the client name at step 412 and completes any extra processing at step 414 . this extra processing may include any or all of the items of extra processing described above in connection with the asynchronous environment and with reference to fig5 . at step 416 , the bridge forwards the service request to the server . whilst the server is processing the request , the bridge is waiting for a reply from the server at step 610 . on completion of processing of the request by the server at step 332 , the server sends a reply 324a to the bridge at step 334 . the reply is received at step 430 and any extra processing , such as logging the parameters returned from the server to the client is performed by the bridge at step 432 . the bridge 300 then forwards the reply 324b to the client at step 434 . as can be seen from the description above , the client operates synchronously with the bridge and so the interface that the client sees from the bridge is the same as if the client were communicating directly with the server . the bridge operates synchronously with the server and so the interface that the server sees from the bridge is the same as if the server were communicating directly with the client . a bridge is derived from a server only . there is no need for explicit client objects , since a client 53 simply invokes a method upon a server 54 , and receives the reply via return parameters in that same method . no separate communication is initiated by the server 54 . example 2 shows how a object 300 is defined for a synchronous system . ______________________________________ // define a synchronous bridge class # include &# 34 ; server . sub .-- obj . idl &# 34 ; // declaration of server class // the above line includes the methods and attributesof the // server class interface client . sub .-- server . sub .-- obj : client . sub .-- obj , server . sub .-- obj // the above line defines the interface of thesynchronous bridge // as having the features of the server class interface bridge . sub .-- obj : server . sub .-- obj { ______________________________________ the structure and definition of a bridge has been defined above , both for asynchronous operation and for synchronous operation . having defined a bridge for use in either of the modes of operation , it is necessary to transparently insert the defined bridge between the client and the server , so that when a request to create a server is made , a bridge with the full interface of a server object is created instead . the client 53 and server 54 contain instances of respective client and server classes . there are many different methods which can be used for finding remote objects , for creating an instance of a remote object and for invoking methods on remote objects . a typical representative prior art method will now be described , referring back to fig1 . 1 . a dsom object manager ( somd -- objectmgr ) ( located in 50 ) will either have been created when the client was initialised or must be created now by calling the somd -- init () function , which is available in the client 53 as part of the object request broker 50 . 2 . the client 53 executes a method on the somdobject -- mgr in order to locate a server 54 of an appropriate object class for use with the client 53 . somdobject -- mgr creates a proxy object ( located in 50 ) in the client 53 as a local representative for the server object ( located in 52 ) on the remote server 54 . note that no server object yet exists in the remote server 54 . 3 . the client 53 issues a somdcreateobj () method call on the server proxy object . included as a parameter in the method call is the class of target object 51 which the client wishes to create . communication with the remote server is established and a server object ( not shown ) of the appropriate class created on the remote server 54 . once the server object ( not shown ) is created , it creates a target object 51 of the requested class in the server 54 itself . as part of the return parameters , information is supplied to the client 53 to enable it to create a proxy object 49 for the target object 51 . 4 . the client is now able to issue method calls on its local proxy object 49 , which are executed on the target object 51 and the results returned to the client 53 . there may be more than one class of server object . for example , there may be a class of servers for use in providing printing services , another for file storage services and another for communications services . in the prior art , these communicate with each other without the aid of the present invention . the method by which the bridge is transparently inserted between the client and the server will now be described with reference to fig3 . a bridge class is created corresponding to each of the prior art server object classes . server &# 39 ; s server object 501 is an instance of a prior art server object class . bridge &# 39 ; s server object 301 is a subclass of the default server class . in the example given above , there may be a bridge class of servers for use in providing printing services , another for file storage services and another for communications services . the server object ( inherited from the server class ) within the definition of each bridge server class is modified , so that when bridge &# 39 ; s server object 301 is created as a member of a bridge server class , it includes the modifications . the modifications are to the method which creates target objects , and to the method which dispatches methods received by the server object to target objects in the server . the modified method for the creation of server &# 39 ; s object 503 ( a target object ) takes the request from the client to create a server &# 39 ; s object 503 in a server and constructs a bridge object 304 in its place . the modified method which dispatches methods received by the bridge &# 39 ; s server object 301 to server &# 39 ; s objects 503 ( target objects ) in the server merely records the clients name ( step 412 in fig5 ), completes the extra processing ( step 414 in fig5 ) and calls the original dispatch method to dispatch the method to the object . referring to fig9 using the bridge 300 of the present invention which has been described above , a single client 53 can request services from multiple servers 54a - 54d . the client 53 is unaware that the requests are being performed on different servers 54a - 54d . the bridge 300 decides which of the multiple servers 54a - 54d the request is to be directed to . workload balancing between each of the multiple servers 54a - 54d can be achieved without any additional programming in either the client 53 or in the servers 54a - 54d . in an embodiment which achieves workload balancing , the bridge 300 uses a &# 34 ; round - robin &# 34 ; algorithm . in this algorithm , each new client request is directed to the next server 54a - 54d in sequence . in another embodiment to achieve workload balancing , response times obtained from each of the servers 54a - 54d are measured and more sophisticated algorithms known to those skilled in the art are used to balance the workload between each of the servers 54a - 54d . both of these embodiments can be achieved without any modifications to the code in either the servers 54a - 54d or in the client 53 . fig1 shows three clients 53a - 53c connected to three servers 54a - 54c connected together in a prior art manner . each of the clients 53a - 53c has a connection 901 - 909 to each of the servers 54a - 54c . thus there are a total of nine connections 901 - 909 between clients and servers . referring to fig1 , with the bridge 300 of the present invention which has been described above , there can be multiple clients 53a - 53c requesting services from multiple servers 54a - 54c , without any of the clients 53a - 53c being aware that the requests are being performed on different servers 54a - 54c or that the servers 54a - 54c are carrying out other requests for other clients 53a - 54c . the bridge 300 decides which of the multiple servers 54a - 54c each of the requests from each of the clients 53a - 54c is to be directed to . connectivity in the network is reduced by routing all of the requests through the bridge 300 . in a more generalised form , in a system having n clients 53 and m servers 54 , the number of connections is reduced from n * m to n + m .