AU1943600A - Method of communication between distant objects - Google Patents

Abstract

The system offers message management to minimize the cost of communication between distant objects. The communication procedure is based on management of distributed objects (ORB). The procedure includes modifying the first representing elements Proxy(A) of the Proxy/Stub representing element pairs associated with the objects of a first process. This enables transmission of messages relating to a given service (SX) and transmission by the objects (ObjC) from the first process (GCLIENT1) to the objects (ObjA of the other process (PROSERV1). Management called GCLIENT corresponds to this service and is provided within the first process. This call management manages the received messages and transmits certain of these messages to a corresponding receiver (GSERV1).

Description

P/00/01i1 Regulation 3.2

AUSTRALIA

Patents Act 1990

ORIGINAL

COMPLETE SPECIFICATION STANDARD PATENT

S

S*

S Invention Title: 'Method of communication between distant objects' The following statement is a full description of this invention, including the best method of performing it known to us: PNPSYN NAT M12I1MIflb'.Rf Method of communication between distant objects The present invention concerns a method of communication between distant objects based on an object request broker (ORB) distributed object manager.

Particularly 'Well-known and widely used ORB include the common object request broker architecture (CORBA) and the distributed component object model

(DCOM).

Many applications use an environment of the above kind. Applications that may be cited include telecommunication or transportation supervisory applications, applications constituting an intelligent network, etc.

In a distributed object environment, an application can use different servers to provide services to clients. A client process is a program which uses services and a server process is a program which offers services to clients. An object of the client process can request a service from the server by sending it a corresponding message.

corresponding object of the server executes the service and where appropriate returns a response to the requester. Communication between the two distant objects in practice uses an object-object protocol.

Figure 1 shows the principle of this protocol whereby, when dn object ObjC of a client process PROCLIENT requests any service on a given server object of a server process, the corresponding message passes between a pair of representative •o 20 elements of the object. It is this pair of objects that manages the corresponding interprocess calls in a manner that is transparent for the two distant objects, namely the client object and the server object.

For example, in the case of an objedt ObjA of the server process, a representative element Proxy(A) of the object ObjA is created in the client process and 25 a corresponding representative element Stub(A) is created in the server process. All ".:messages from the object ObjC of the client process to the object ObjA of the server process and any responses (results) to those messages pass through the Proxy/Stub interface of the object-object protocol.

There is therefore a pair of representative objects Proxy/Stub for each object of a server process with which a client object wishes to communicate. This Proxy/Stub terminology is that of the DCOM environment. It corresponds to the Stub/Skeleton terminology of the CORBA environment. The DCOM terminology is used hereinafter, but the person skilled in the art will know how to extend the following description to any ORB known in the art.

Figure 1 shows two pairs of representative elements Proxy(A)/Stub(A) and Proxy(B)/Stub(B) for respectively accessing via a client object ObjC different services provided by objects ObjA and ObjB of the server process.

The object-object protocol applies equally well to messages transmitted by server objects to client objects. A notification service supported by the ORB enables a client object of a client process to register to receive notifications from server processes. A typical example of the use of a notification service of the above kind concerns supervisory applications in which the clients wish to be advised of changes of properties of objects. According to the object-object protocol, and as shown diagrammatically in Figure 2, when a client object has registered to be a sink object SinkC for notifications from an object ObjA of a server process PROSERV, the notifications sent by that server object to that client object are transmitted via a pair of representative elements of the sink object. That pair of elements comprises a representative element Proxy(C) of the sink client SinkC in the server process PROSERV and a corresponding representative element Stub(C) in the client process PROCLIENT.

A notification message from the server object ObjA to the sink client SinkC is transmitted to the representative element Proxy(C) which sends it to the •corresponding representative element Stub(C) of the corresponding client SinkC which therefore receives the notification message which is addressed to it without the objects ObjA and SinkC needing to know their respective locations.

oe*o 20 The advantage of an object-object protocol of the above kind is that the objects do not need to know the location of the objects with which they exchange messages. With this protocol, the ORB conceals the location of the objects, as it were, which considerably simplifies access to the objects wherever they are located.

These pairs of representative elements are well known to the skilled person and will 25 not be described in more detail here.

In some applications, very large numbers of messages can be exchanged in accordance with this protocol in one direction or the other.

There are many examples of this. In a service referred to as the "life cycle service", which enables a client object to find out if a server object is still available, i.e.

has not been destroyed, or that the network has not failed, messages are sent cyclically by all the client objects concerned to all the server objects in respect of which they require this information. If the server process is unavailable, all the server objects of its process are also unavailable.

In an identity service, whereby a client object can request a server object to return to it the name of the process in which it is located, all client objects can request this service of server objects, which can be on the same process.

In another example, which relates to the notification service used in supervisory applications in particular, there may be a very large number of notification messages concerning properties (activity, status) of various equipment units of a system.

A further example is that of messages for subscribing to a service executed by a server process, for example a notification channel. When a client process is created, it typically registers some or all of the objects that it contains with one or more server processes. Clearly there can then be a very large number of registration messages.

In the above examples, it is clear that the number of interprocess calls is not optimum. It would be beneficial to reduce the number of calls.

It is therefore beneficial to group the messages between two processes to send them in groups in order to reduce the number of interprocess calls, which are costly, and to optimize communication.

For the above reasons, the messages for some services are concentrated.

Concentration services then receive and process all messages from processes subscribing to the corresponding service. For example, a concentration service can modify messages, filter them, send them periodically to the destination processes, etc.

20 A communication method of the above kind for use with a notification ooo• service is shown diagrammatically in Figure 3. With a process of the above kind, an object ObjB of a server process must send its notification message with a parameter identifying the destination sink object SinkD, typically a pointer pSinkD. The object ObjB then sends an n(pSinkD, type message and the sink object SinkD receives an type message. With a service of the above kind the transparency of the -•.object-object protocol is clearly lost: the sending object must provide a pointer to the :.:destination object.

The concentration service is therefore one more intermediary in the communication protocol with which the advantage of the transparency of the objectobject protocol is lost.

An object of the present invention is to provide a method of communication between distant objects which does not have the aforementioned disadvantages.

The invention uses the mechanisms of the object-object protocol of the ORB, i.e. it does not enter into the internal mechanisms of the ORB, to provide a communication protocol enabling concentration of messages without losing the transparency of the object-object protocol.

By remaining above the ORB, the communication method is advantageously portable, i.e. applicable to any ORB.

In an ORB environment, it is possible to modify the Proxy/Stub type representative elements of the object-object protocol using mechanisms known in the art dependent on the ORB. The invention uses this property to transmit messages via centralized service managers in each process.

In accordance with the invention, a manager object is therefore created in each process to concentrate messages relating to a given service.

For that service, a calling manager in the calling process and a receiving manager in the destination process are created.

The pairs of representative elements are modified to enable the transmission of messages relating to the service concerned received by the Proxy type elements of a calling process to the calling manager corresponding to that service in that process.

The calling manager -can process the messages according to the requirements of the service. For example, it can filter them, modify parameters, sort them and group them in order to transmit them to corresponding receiving managers in the destination processes, etc.

Each receiving manager of the destination processes can then distribute S 20 messages received in this way to the destination objects or itself provide the o *corresponding service.

The invention therefore provides a communication method based on an SO. ORB distributed object manager, in which messages are transmitted from objects of a first process to objects of another process via pairs of representative elements, each pair of representative elements includes a first representative element in the calling .process and a second representative element in the other process, first representative o. elements of the first process are modified so that they transmit messages relating to a given service and sent by objects of the first process to objects of other processes to a calling manager corresponding to the service in the first process, and the calling manager manages messages received in this way and transmits some of them to a corresponding receiving manager in each destination process.

The above communication method applies equally well to services for which client objects send messages to server objects and services for which server objects send notification messages to client objects.

Another object of the invention is to reduce the number of registration messages sent by objects of a client process to the address of a server process. To this end, the invention provides a method of registering with a server process a client process containing a set of objects each of which objects sends a registration message, wherein the registration messages are communicated to the server process by the communication method previously described.

Other features and advantages of the invention are explained in the following description, which is given by way of illustrative and non-limiting example only and with reference to the accompanying drawings, in which: Figure 1, already described, is a diagram showing the use of an objectobject protocol to transmit messages from a client process to a server process, Figure 2, already described, is a diagram showing the use of an objectobject protocol to transmit notification messages from a server process to a client process, S1- Figure 3, already described, is a diagram showing the management of messages exchanged between.a client process and a server process and vice versa by a prior art centralized notification service, Figure 4 is a diagram showing the management of messages exchanged between a client process and a server process by the communication method according to the invention, Figure 5 shows the management of messages by the communication method of the invention applied to a notification service, and go- Figure 6 is a diagram showing a mechanism for modifying a message parameter.

Figure 4 corresponds to a first embodiment of the invention applied to a given service SX for transmitting messages corresponding to that service from a client r..object ObjC of a client process PROCLIENT 1 to server objects ObjA and ObjB of a server process PROSERV 1 The client process can include different client objects. Proxy/Stub type representative elements which are created when the client objedts register for different services on those objects correspond to each of the different client objects.

In the simplified example shown in Figure 4, there is a single client object ObjC for which two pairs of Proxy/Stub type representative elements, Proxy(A)/Stub(A) and Proxy(B)/Stub(B), have been created to provide access to different services provided by server objects ObjA and ObjB, which in this example are part of the same server process PROSERV 1 The client process PROCLIENT 1 further includes a calling manager GCLIENT 1 for the service SX. The calling manager receives messages relating to the service SX transmitted by the Proxy type representative elements of the client process. If the message does not relate to the service SX, the first Proxy type representative element can behave in the standard way, by directing the messages to the corresponding Stub type second representative element, or in the particular, specialized way according to the invention, by rerouting the messages to the calling manager of a corresponding service. The server process PROSERV 1 includes a receiving manager GSERV 1 of the service SX which receives messages from corresponding calling managers from the same service SX) of different calling processes and distributes them to the destination server objects.

The standard Proxy/Stub type representative elements of the object-object o protocol, created when the client objects register for services on server objects, are modified to enable communication between the calling and server managers of the 15 service SX in accordance with the invention. For each message that it receives, the oe. calling manager of a service in a client process needs to know not only the identification parameter of the destination distant server object but also that of the corresponding receiving manager.

The client object which sends the message does not know the location of the ogle 20 server object it is calling. On the other hand, each representative element knows, or can find out, via the associated object, the addresses of objects in the process in .o which it is located. Thus the Stub type representative element in the process concerned or the corresponding server object knows (or can find out) the oooo identification parameters of the destination server object and the corresponding 25 receiving manager.

In a practical example of application of the invention the Stub type representative elements of the server processes are therefore modified so that each sends information to the associated Proxy type representative element. Accordingly, as shown K l a dashed-line arrow in Figure 4, the element Stub(A) of the pair Proxy(A)/Stub(A) sends the element Proxy(A) the identification parameters pObjA and pGSERV 1 of the server object ObjA and the receiving manager GSERV 1 of the server process concerned. The information can be sent when the pair of representative elements is created or afterwards.

In this example of application of the invention the Proxy/Stub gateway is used to repatriate to the Proxy type elements the information needed for the calling and receiving managers to communicate. Note that the skilled person will know how to apply other mechanisms. One such other mechanism uses the destination server object directly .to provide the above information to the Proxy type elements, for example, using shared resources.

According to the invention, the Proxy type representative elements of the client processes are therefore modified so that they no longer transmit the messages relating to the service SX to their corresponding representative element Stub but instead to the calling manager of that service in their process, each message including the identification parameters of the destination object and the corresponding receiving manager.

Accordingly, if the client object ObiC wishes to send an type message relating to the service SX to the object ObjA of the server process PROSERV 1 the corresponding representative element Proxy(A) sends an a(pObjA, pGSERV 1 type message to the calling manager GCLIENT 1 of the service SX in the client process S 15 instead of sending the message directly to the representative element Stub(A).

ooeo Thus the calling manager in the client process receives all messages relating to the service SX from client objects of the client process and addressed to any server object of any server process.

It can process the messages according to the requirements of the service SX Oil• .20 concerned. For example, it can filter, sort and group the messages by server process, in order to send to each server process a corresponding group of received messages, S° in accordance with predefined policies on grouping and sending messages.

ioThus it can send the messages in packets, asynchronously: when the off* receiving manager has received the packet of messages, it releases the calling manager, which can concern itself with the management of other messages. If the calling manager sends the messages in packets, the sending can be cyclic.

If the sending is cyclic, the cycle can be a cycle defined by each calling manager or by the receiving manager.

Cyclic sending can'be complemented by sending triggered by a particular event, for example when a particular number of messages has been received.

The messages can also be filtered so as to transmit only some of them, in accordance with predefined criteria, as explained hereinafter in connection with an example of application of the invention to an identification service.

A synchronous transmission process can also be used to send a message to a corresponding receiving manager, followed by a wait for a result to be returned.

8 There are therefore many practical applications, depending essentially on the services to which the invention is applied.

Figure 4 shows an application of the invention to a service SX for which client objects send messages to server objects. Depending on the service concerned, there may be a result to be returned to the client object or not.

If, for the service SX concerned, there is a result to be returned, the results normally take the reverse of the transmission path to the calling object: ObjA--

GSERV

1

->GCLIENT

1 Proxy(A)->ObjC. They are then processed in substantially the same way as the messages by the receiving and calling managers using the reverse process: the receiving manager receives the results directly from the server objects; it can link them to the messages to which they correspond, sort them and group them.

It can send them in packets to the corresponding calling managers, which in turn distribute the results to the corresponding client objects. The sending can be cyclic, triggered by a particular event, etc. All the foregoing remarks on the management of 15 messages by the managers apply equally to the management of the corresponding oooo results.

The managers use appropriate data structures (tables, stacks, etc.) to manage messages, and where applicable results, in the above manner according to the invention.

Thus Figure 4 shows a data structure Tab, in the form of a table managed •go by the calling manager GCLIENT 1 At any given- time this data structure contains a list of messages received by each destination object for each receiving manager concerned. In this example, the calling manager GCLIENT 1 contains two messages eo for a receiving manager identified by a pointer GSERV 1 and one message for another 25 receiving manager identified by a pointer pGSERV 2 The receiving manager GSERV 1 of the server process may itself have to manage a data structure, such as the data structure Tab 2 shown in Figure 4, in which it stores received messages. In particular, this enables it to sort messages it receives by destinatign server object and to send them to those server objects. It also enables it to manage any corresponding results it may receive in return, in order to return them to the corresponding calling managers.

Thus each manager manages one or more data structures, as required. It can store messages, results and information relating to its own management therein, for example a message transmission flag, an awaiting result flag, etc.

Also, the calling and receiving managers can apply filtering or compression type transformations or modify certain parameters of the messages or corresponding results at each step of transmitting the messages and/or results. This facility is described in more detail hereinafter in connection with an example of application of the invention to the notification service. However, it can be used for any of the services to which the invention applies, for the needs of the service in general and to optimize interprocess calls.

In implementing a communication method according to the invention, the receiving manager of the server process can itself provide the corresponding service.

Thus concentration of the service itself can complement concentration of transmission of messages (and results, where applicable).

This application of the invention typically addresses services such as the server process identification service, which a client object uses to find out the process on which the server object it is addressing is located, or the fault detection service, which a client object uses to find out if the server object it is addressing is still available if it has not disappeared) or that the network is not down.

°.wel Taking the example of the identification service, a centralized object can very Sowell provide the service instead of each server object. Thus in this variant of the invention the service is provided by the receiving manager itself. Accordingly, the corresponding code for the service has to be implemented only in the manager and °go• OO 20 not in each server object. This is highly advantageous. It is also achieved in a ooo° manner which is transparent for the client objects.

In this example of application to the identification service, some of the service can also be centralized at the calling manager, which significantly reduces i interprocess calls. The calling manager can store in its data structure the identity of 25 the server processes as and when it finds them out. Thus if it already knows the identity of a process for which it receives an identity request message it returns the required result to the client object itself. For each server process for which it is sollicited, the calling manager therefore transmits a corresponding identity request to the receiving manager once only, on the first request that it receives.

In this application example, note that packets of messages are not necessarily transmitted between the managers; the communication process can then be synchronous, each element involved which sends a message waiting for the returned result: the client object which sends the message, the calling manager which receives it and which transmits it to the receiving manager if it does not know the result.

Figure 5 shows an application of the invention to another kind of service, namely the notification service. In this case, the calling managers are in the server processes and the receiving managers are in the client processes. According to the invention, each server process, respectively client process, contains a single calling manager, respectively receiving manager, for the notification service. Each server process can send notifications to different client processes via its calling manager.

Each client process can receive notifications from different server processes via its corresponding receiving manager.

Thus in the example shown in Figure 5 there is a calling manager GNSERV 1 for the notification service in the server process PROSERV 1 and a receiving manager

GNCLIENT

1 in the client process.

The calling manager receives all the notification messages from all the server objects of the process which send these messages. The receiving manager can receive notifications from calling managers of different processes. It distributes the 15 notifications received to the destination collecting objects. More generally, this o independence between the two processes is obtained as soon as the messages (or the returned results) are sent in packets at least between the two managers. Depending on the type of service concerned, the asynchronism can be only at the level of the managers or at all levels of the transmission system. The person skilled in the art can O lO O 20 use standard techniques (threads, interrupts, etc.) to introduce this asynchronism.

The calling manager must sort the various notification messages that it receives from the server objects of its server process according to the destination client process and, for each destination process, according to the destination sink object, to send them to the destination calling managers, for example in packets, possibly o 25 applying a transformation to them beforehand. It uses an appropriate data structure Tab 3 for this (see Figure In this example the data structure contains three messages, namely two messages ml and m2 for the client process PROCLIENT 1 of which message ml is from the server object ObjA for a sink object SinkC and the other message m2 is from a server object ObjB for a sink object SinkD, and a message m3 from the server object ObjA for a sink object SinKO of another client process PROCLIENT 2 not shown.

The calling manager of the server process preferably groups messages addressed to the corresponding receiving manager of the same client process to send them in packets in a single call. It has been shown that it can also apply transformations such as filtering or compression mechanisms to the packet of 11 messages that it sends at this stage. It can also modify some parameters.

For example, it can filter the messages by transmitting only those which correspond to the latest modifications of some properties. In this case, it eliminates earlier messages. It can then modify a flag type parameter of the message whose state indicates whether filtering has been applied or not.

As shown in Figure 5, the receiving manager of a client process can also manage a data structure Tab 4 to store notification message/sink object pairs that it receives from calling managers. It can also process messages and/or modify some message parameters before distributing the messages to the objects concerned.

It has already been shown that the calling or receiving manager of a process can modify parameters of messages or of corresponding results to facilitate its management and for the needs of the service in general. One example of a o: :parameter which can be modified by a manager is the filtering flag parameter previously mentioned.

Another example relates to key type parameters. An element which sends ao:. many diverse messages usually employs a key allocation mechanism. A key is an identifier allocated by the client when it logs on. The key is transmitted in the *095*5 9 notification and enables the client to identify the connection to which the notification **corresponds.

oooo 20 Because, in the method. according to the invention, messages are lof s's. concentrated by means of the managers, the managers receive messages sent by o° different elements each of which applies its own key allocation mechanism. Thus °***each manager can encounter messages using the same key.

The invention then provides for each calling or receiving manager to use its own received message key allocation mechanism. In the example shown in Figure 6, a receiving manager receives a message from a calling manager GCLIENT 1 of a client process for a server object ObjA. The message is of the type a(pObjA,X,Y,keyl in which key1 is the corresponding key, allocated by the calling manager GCLIENT 1 Th6 receiving manager receives another message from a calling manager

GCLIENT

2 of another client process for the same server object ObjA. This message is of the type a(pObjA,X,Y,keyl,...) in which keyl is the key allocated by the calling manager GCLIENT 2 When it receives its messages, the receiving manager can allocate a new key using its own allocation mechanism (for example, according to the order of arrival of the messages). It therefore replaces the received key in each message with a new key it allocates. It can retain the correspondence between the new key and the key originally received in the data structure Tab 6 so that it can return any corresponding result to the calling manager with the original key. In the example shown in Figure the new key of the first message is therefore keys 1 and that of the second message is keys2. Accordingly, generally speaking, a calling or receiving manager can modify parameters of messages or of corresponding results.

Note that in some cases the communication method of the invention makes the calling and destination processes independent. In the notification service example, considering the corresponding transmission system shown in Figure 5, if an object sends a notification message, it is the corresponding calling manager in the server process which receives it and the latter then releases the server object to perform other tasks. If the calling manager decides to send a packet of notification messages to a receiving manager, the latter receives the packet and immediately releases the calling manager, which can deal with other packets, other calling 15 managers, etc. Finally, when the receiving manager distributes messages to a client object, the latter releases the receiving manager as soon as the messages are received.

With a communication method according to the invention, various S applications and variants of which have lust been described by way of purely 20 illustrative example, a calling object does not know that a calling manager is being used and, where applicable, a destination object does not know that it is being called by a receiving manager.

Note that the system can revert at any time to the standard form of communication using the standard Proxy/Stub pair, for example to perform an 25 individual test on a server object. All that is required in the calling process is to modify the Proxy type representative element again so that it again transmits the messages to the corresponding Stub type representative element. The communication method according to the invention is therefore reversible.

Note that communication between a calling manager and a receiving manager can use the standard Proxy/Stub pair scheme of the object-object protocol.

It can also use shared resources R provided on the ORB or in the operating system, as shown in Figures 4 and 5. The shared resources can be a memory, a network connection, etc.

Finally, the communication method of the invention does not use any internal mechanism of the ORB, which makes it portable, i.e. usable with any ORB.

13 It reduces the number of interprocess calls for each service to which it is applied by virtue of the mechanism for sending packets of messages with or without transformation (filtering, compression) and where applicable by centralizing the service itself, without losing the transparency of the object-object protocol.

In some cases, for example in the case of the notification service, it advantageously makes the calling process and the destination process independent because, in this case, it makes the processes asynchronous.

In practice, the communication method according to the invention allows great freedom of implementation, enabling it to be adapted to various potential applications.

In particular, it is possible to use the method of the invention to enable registration of the objects of a client process with a server process. Registration enables the server process to send registered objects notification messages as oooo previously referred to. The number of objects within a client process wishing to register with the same server process can typically be very high. It is therefore oo" necessary to reduce the number of registration messages in order not to overload the underlying communication means (in particular the data processing network).

The method of the invention can be used for this: each registration message is then sent to a calling manager by an associated representative element (Proxy(A)).

20 The calling manager can then transmit all the data relating to the registration requests to the server process in a sngle registration message.

requests to the server process in a single registration message.

o•

Claims (12)

1. A communication method based on an ORB distributed object manager, in which messages are transmitted from objects of a first process to objects of another process via pairs of representative elements, each pair of representative elements includes a first representative element in the calling process and a second representative element in the other process, first representative elements of the first process are modified so that they transmit messages relating to a given service and sent by objects of the first process to objects of other processes to a calling manager corresponding to the service in the first process, and the calling manager manages messages received in this way and transmits some of them to a corresponding receiving manager in each destination process.

2. A communication method according to claim 1 wherein each modified first representative element transmits messages relating to the service to the corresponding calling manager with an identification parameter of the 15 corresponding receiving manager in the destination process and an identification S"parameter of the destination object.

3. A communication method according to claim 2 wherein the parameters are supplied to the first representative element by the associated second representative element or the destination object. 20 4. A communication method according to any of claims 1 to 4 wherein the receiving manager of a destination process transmits messages received from calling managers to the objects concerned of that process. A communication method according to claim 4 wherein the receiving manager receives results in response to messages that it forwards to the calling managers 25 concerned. A communication method according to any of claims 1 to 3 wherein the receiving manager for a message itself provides the corresponding service, where applicable returning a corresponding result to the calling manager concered.

7. A communication method according to any of claims 1 to 6 wherein messages and/or corresponding results are transmitted between a calling manager and a receiving manager by means of a pair of representative elements.

8. A communication method according to any of claims 1 to 6 wherein messages are transmitted between a calling manager and a receiving manager using shared resources.

9. A communication method according to any preceding claim wherein a caloiling or receiving manager modifies parameters of messages and/or corresponding results. A communication method according to any preceding claim wherein messages and/or the corresponding results are transmitted in packets between the calling and receiving managers with or without prior transformation.

11. A communication method according to claim 10 wherein the packets are transmitted cyclically in accordance with a cycle defined by the receiving or calling manager.

12. A communication method according to claim 11 wherein transmission of packets is also triggered by the occurrence of a particular event.

13. A communication method according to any preceding claim applied to a service in which the calling processes are client processes and the destination processes are server processes.

14. A communication method according to.any of claims 1 to 12 applied to a service in which the calling processes are server processes and the destination processes •are client processes. A communication method according to any preceding claim wherein the ORB environment is a CORBA environment. 20 16. A communication method according to any of claims 1 to 14 wherein the ORB "environment is a DCOM environment. 1 7. A method of registering with a server process a client process containing a set of So"objects each of which objects sends a registration message, wherein the a registration messages are communicated to the server process by a method according to any preceding claim.

18. A communication method substantially as hereinbefore described with reference Sto figures 4 to 6 of the accompanying drawings.

19. A method of registering a client process with a server process substantially as hereinbefore described with reference to figures 4 to 6 of the accompanying drawings. Dated this 23rd day of February 2000, ALCATEL by its attorneys Freehills Patent Attorneys