AU1953000A - A method of advising an object of the unavailability of other objects in a distributed object environment - Google Patents

Description

/00/011 Regulation 3.2

AUSTRALIA

Patents Act 1990

ORIGINAL

F

COMPLETE SPECIFICATION STANDARD PATENT r Invention Title: 'A method of advising an object of the unavailability of other objects in a distributed object environment The following statement is a full description of this invention, including the best method of performing it known to us: FHPSYnIRINATPffl12ftnlfiifi2-i 1 A METHOD OF ADVISING AN OBJECT OF THE UNAVAILABILITY

OF

OTHER OBJECTS IN A DISTRIBUTED OBJECT ENVIRONMENT The present invention concerns a method of advising an object of the unavailability of other objects in a distributed object environment, based on a distributed object manager. A manager of this kind is usually referred to as an object request broker (ORB).

BACKGROUND OF THE INVENTION "Two particularly well-known and widely used ORBs are the common object request broker architecture (CORBA) and Sthe distributed component object model (DCOM).

Many applications use a manager of the above kind.

Examples which might be cited are telecommunications or transportation supervisory applications, applications S 15 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 (an instance of execution of a program) can solicit a service from the server by sending it a corresponding message. A corresponding object of the server executes the service and where appropriate sends a result back to the requester.

In practice the two remote objects communicate using an object-object protocol.

In that protocol, when an object of a client process sends a message to an object of a server process for a given service, a pair of elements representative of the server object is created to manage the corresponding inter-process calls in a manner that is transparent for both remote objects, namely the client object and the server object. To be more precise, a representative element Proxy of the server object is created in the client process and a corresponding representative element Stub is created in the server process. All messages from the object of the client process addressed to the object of the server process and any responses to those messages (results) pass through the Proxy/Stub interface of the object-object protocol. The object-object protocol is also used to send messages from a server object to a client object: there is then a representative element Proxy of the client object in the server process and a corresponding representative element Stub in the client :10 process.

An advantage of an object-object protocol of the above kind is that the objects do not need to know where the objects with which they are exchanging messages are located. With this protocol, the ORB conceals the 15 location of the objects, so to speak, which considerably "..simplifies access to the objects wherever they might be located. These pairs of representative elements are well-known to the skilled person and are not described in more detail. Note that the terms Proxy/Stub are those employed in the DCOM terminology. Their counterparts in the CORBA terminology are Stub/Skeleton. The DCOM terminology is used hereinafter, but the skilled person will know how to extend anything described hereinafter to any ORB known in the art.

In some industrial applications, in particular in the telecommunications and transportation fields, it is important to detect the unavailability of some remote objects quickly. For example, in a supervisory context, there are fault detection services which generate corresponding alarms in the form of notifications to user clients. A user client no longer receiving alarms must be advised that this corresponds to the disappearance of the corresponding service. The client cannot tell in advance if or when it will receive notifications. It therefore needs to be certain of the status of the server object, i.e. whether it is accessible or unavailable.

Note that the unavailability of a process can have different causes and consequences: for example, without seeking to be exhaustive, it may be a temporary disappearance, for example due to a break in the network, or a permanent disappearance, either intentional or due to a software or hardware incident.

A life cycle service known in the art and available in the DCOM environment is based on the time-out used by the ORB (DCOM) to manage the call in accordance with the object-object protocol. This time-out'is a parameter of 10 the ORB itself and is generally not configurable.

In this service, it is the ORB which detects that a representative element Stub of a client object is no .longer responding, the detection process being based on the time-out and automatically releasing the resources of the server processes to which the disappearance of the corresponding client object is relevant.

The invention seeks also to advise client objects of the disappearance of a server object.

One mechanism for advising client objects of the disappearance of a server object is described in European Patent 98400942.3 (EP 0 872 797) whose title in translation is "Managing the accidental death of an object during a call between distributed objects in a COM environment". In that mechanism, a dedicated additional object is used in a client process to create a reverse link through which the mechanism previously described can also advise a client object of the unavailability of a server object.

The above prior art is unsatisfactory, however, as it is still based on the ORB time-out. It has been shown that the time-out depends only on the ORB used and is therefore generally not configurable. For example, with an ORB such as DCOM, its value is six minutes.

What is more, with a solution of that kind, a dedicated additional object is required for each remote object to be supervised and for each client object for which detecting the life cycle of a remote object is relevant, together with a corresponding pair of representative elements Proxy/Stub. This mobilizes memory resources.

OBJECTS AND SUMMARY OF THE INVENTION An object of the present invention is to provide a supervisory process which is free of the above disadvantages.

The invention is based on the fact that, if an object of a process is unavailable, its unavailability is generally valid for all the objects of the process. It is a rare event for an object to be unavailable independently of the process to which it belongs.

The method of the invention supervises a single object per process. That object can be a dedicated 15 manager which is centralized in the process to be ooo supervised.

Also, to effect this supervision in a manner which retains the advantage of the transparency of *."communication between the remote objects, it is useful to 20 be able to use an object-object protocol between the client object requesting supervision and the server object to be supervised. 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 and depending on the ORB. The invention uses this property to transmit requests for advice to a centralized manager provided in each client process.

Thus, within each client process concerned, the mechanism of the invention can use a centralized client manager responsible for supervising one or more processes on behalf of objects of that client process. According to the invention, the manager: receives the requests to be advised of the unavailability of a server object by the representative elements Proxy of the client objects which send those requests; performs the corresponding supervision of the centralized server managers concerned; and where appropriate, sends notifications of unavailability to the client objects concerned if it detects the unavailability of a centralized server manager.

The use of the centralized client manager is transparent for the client object which requests to be advised of the unavailability of a server object: from *its point of view, it is requesting a server object to advise it of its unavailability and, where appropriate, S. it receives a corresponding unavailability notification without knowing that its request has been processed by S• the centralized client manager of its client process.

A method of the invention for advising a client S 15 object of the unavailability of server objects therefore uses a centralized client manager in a client process to supervise the activity of centralized server managers of processes in which the objects to be supervised are located. Each centralized client or server manager is unique in its process. In parallel with normal client processing, the centralized client manager supervises the S"centralized server managers on behalf of client objects but in a manner that is totally transparent for the latter. It also sends corresponding notifications of unavailability to the client objects concerned if a centralized server manager that it is supervising ceases to respond.

Finally, the invention can also be used to advise a server object of the unavailability of a client object, by interchanging the roles of the centralized managers of the invention.

The invention therefore provides a method of advising a first object of a first process of the unavailability of a set of objects of a second process, the first object sending a request for advice to each of the objects of the set via a pair of representative elements associated with each of the objects of the set, the pair including a first representative element located in the first process and a second representative element located in the second process. For each of the advice requests, the method includes the steps of: diverting the request for advice to a centralized supervisory manager of the first process via the first representative element, supervision by said centralized supervision manager of a centralized manager to be supervised 9o 10 of the second process, in order to send an -unavailability notification to the first object if the centralized supervision manager detects failure to respond by said centralized manager to be supervised.

Note that all the objects of the second process can be reduced to a singleton, i.e. the process consists only of supervising the accessibility of a single object of the second process.

In some cases, the centralized server manager can itself supervise one or more server objects on behalf of the centralized client managers, if it is necessary to detect the disappearance of server objects independently.

The supervision method of the invention is therefore transparent for the client and server objects, with a configurable detection time-out. Because supervision of client processes is effected in parallel, using light processes (threads) or interrupts, the supervisory process is asynchronous, freeing the client objects of the supervisory task as soon as they have sent their request for advice. It necessitates the creation in each process of only one ORB object, the centralized manager and possibly a pair of representative elements for the centralized client manager/centralized server manager pair if they do not communicate using shared resources such as a memory, a network connection, etc. Finally, it is located above the ORB, using only mechanisms offered by the ORB; it is therefore entirely portable from one application to another, from one ORB to another.

BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the invention are explained in the following description, which is'given by way of non-limiting example only and with reference to the accompanying drawings, in which: Figure 1 is a flowchart of a method of the invention, and Figure 2 shows a variant of the invention.

MORE DETAILED DESCRIPTION Figure 1 shows a client process ProC, containing client objects ObjC, and ObjC 2 and a server process ProS 1 S•containing server objects ObjA and ObjB.

The example described refers to a server object life cycle service. However, the invention applies to a life cycle service of objects in general.

To each of the various client objects there correspond Proxy/Stub type representative elements created when-the client objects subscribe to server process managers.

A client object which registers for services with a S"server object may need to verify if the server object is accessible or not. This applies in particular if the requested service consists in having the server object send notifications to the client object to report changes of properties or alarms. In this case, the client object cannot tell in advance whether or when it will receive such notifications. In other words, if it receives nothing for a certain time it must be able to find out for certain the status of the server object, namely whether it is accessible or unavailable.

Accordingly, in the example shown in Figure 1, the client object ObjC 1 is registered with the server object ObjA and the object ObjC 2 is registered with the server object ObjB, for corresponding services. For the client object ObjC 1 a pair of Proxy/Stub type representative elements has therefore been created: Proxy(A)/Stub(A) Similarly, for the client object ObjC 2 a pair of Proxy/Stub type representative elements has been created: Proxy(B)/Stub(B). These pairs of representative elements enable the objects concerned to communicate using the standard object-object protocol.

Assume that each of the client objects ObjC 1 ObjC 2 is interested in being advised of the unavailability of the associated server object. Each sends an advice o..request.

According to the invention, the first representative element of each pair is modified so that if it receives an advice request from the associated client object it S• sends it to a centralized supervisory manager in the client process instead of sending it to the corresponding representative element Stub. The centralized supervisory manager of the client process is referred to hereinafter as the centralized client manager.

o0 ""The centralized client manager supervises a centralized manager to be supervised in the server process concerned. The centralized manager to be supervised in the server process is referred to hereinafter as the centralized server manager.

If the centralized client manager detects a lack of response from a centralized server manager, it sends an unavailability notification to each object concerned of its client process, i.e. to all the client objects to which the unavailability of at least one of the server objects of said server process is relevant.

In the supervisory service using the method of the invention, a client process corresponds to a single centralized client manager and a server process corresponds to a single centralized server manager.

Those managers are objects of the process concerned (in the ORB sense) and can communicate using an object-object protocol or shared resources: memory, connection by sockets, in particular enabling network connections, etc.

The method according to the invention is based on the fact that if the centralized server manager which becomes unavailable is a server object of the server process, all the objects of the server process are themselves unavailable, and consequently the server process itself is unavailable.

In practice, the advise message sent by the client object does not contain the identifier of the server object or of the centralized server manager, since, in rooe accordance with the principle of the transparency of the object-object protocol, it does not know the location of those objects. The advise message therefore contains only an identifier of the client object (for example, a pointer).

According to the invention, when the element Proxy 15 receives an advise message, it adds at least the parameter identifying the corresponding centralized server manager before diverting the message to the *e centralized client manager.

Thus, in accordance with the invention, the standard representative elements Proxy/Stub of the object-object *"protocol, created when the client objects subscribe to services on server objects, are modified to enable supervision of the centralized server managers by the centralized client managers. Each representative element Stub knows or can find out the addresses of the objects present in the process in which it is located. Thus the representative element Stub in the process concerned or the corresponding server object knows (or can find out) the parameter identifying the centralized server manager.

In one practical embodiment of the invention, the representative elements Stub of the server processes are therefore modified so that each of them sends this information to the associated representative element Proxy. In this way, as shown diagrammatically by a dashed line arrow in Figure 1, the element Stub(A) of the pair Proxy(A)/Stub(A) sends to the element Proxy(A) the identification parameter pLS 1 of the centralized manager LS of the server process concerned. The information can be sent when creating the pair of representative elements or afterwards.

In this embodiment of the method according to the invention, the Proxy/Stub gateway is therefore used to repatriate to the elements Proxy the information needed for the centralized server managers to be supervised by the centralized client manager. Note that the person skilled in the art can use other mechanisms. One such other mechanism is to use the server object to which the advice request is addressed directly to provide the o* information to the elements Proxy, for example, using shared resources.

Figure 1 simply shows two processes, namely a client 15 process ProCi with a centralized client manager LC 1 and a server process ProS, with a centralized server manager

LS

1 9* Thus the message advise(pObjCi,...) sent by the object ObjCi to the representative element Proxy(A) is not sent by the latter to the corresponding representative element Stub(A) but instead to the centralized client manager LC 1 with an additional identification parameter pLS 1 on the corresponding centralized server manager LS 1 The message received by the centralized client manager is therefore of the type advise(pObjC,...,pLS,...).

Similarly, the message advise(pObjC 2 sent by the object ObjC 2 to the representative element Proxy(B) is not sent by the latter to the corresponding representative element Stub(B) but instead to the centralized client manager LC 1 with an additional identification parameter pLSi on the corresponding centralized server manager LS 1 The message received by the centralized client manager is therefore of the type advise The centralized client manager LCi sorts the various advice requests that it receives according to the client objects which sent them and the centralized server manager identified in each message. It stores the corresponding identification parameters in a suitable data structure Tab, for the purposes of initiating the corresponding supervisory tasks and, when it detects that a centralized server manager is unavailable, looking up in this structure the client objects to be advised. It then sends them a corresponding notification directly, using the identification parameters stored in memory.

In Figure i, this data structure contains two advice 0000 owesmessages, the first corresponding to the request from the :Oeo *o 10 object ObjC 1 on the object ObjA and the second corresponding to the request from the object ObjC 2 on the object ObjB. The two messages therefore concern supervision of the centralized server manager LS, and contain the corresponding identification parameter pLS 1 oeo oo 15 stored in the data structure. The data structure can *boo contain other messages to objects of other server processes. It can also contain more than one message from the same client object to different server objects of the same or different server processes.

The centralized client manager sorts all these S: messages by centralized server manager to be supervised.

s It initiates only one supervisory task for all the messages concerning the same centralized server manager.

The supervisory service according to the invention therefore significantly reduces the traffic of supervisory messages between the two processes.

If the centralized client manager detects that a server process is unavailable, it looks up in its data structure all the messages that contain the identification parameter of the corresponding centralized server manager. For each message it finds, it sends an unavailability notification to the corresponding client object.

The same client object can submit various advice requests. It can therefore receive various unavailability notifications. If it needs to be able to identify the notifications, it can use a key allocation mechanism. It uses this mechanism to allocate a key to each message it sends. The key is a parameter of the message which identifies the message uniquely for the client object that sends it.

The centralized manager that receives the message stores the corresponding key in its data structure to use it as a return parameter in the corresponding unavailability notification if it has to send a notification of this kind to the client object. Figure 1 shows the use of a key K1, respectively K2, in the message advise(pObjC 1 K1, respectively advise(pObjC 2 K2, and these keys K, and K 2 are stored in the data structure coo•..

by the centralized client manager LC

I

The centralized client manager can initiate various 15 types of supervisory task, depending on the centralized server manager interface. For example, it can use "ping" messages, with failure of a message to return after a predetermined time dO constituting a lack of response detected by the centralized client manager as signifying that the server process is unavailable. The task can also consist in requesting transmission of a regular message, such as a heartbeat, from the centralized server oooo manager. Failure to receive the heartbeat for a particular time period dO constitutes the failure to 25 respond that is to be detected. In this case, and as shown in Figure 1, the centralized client manager sends an advice request to receive the heartbeat. The centralized server manager therefore includes a data structure Tab 2 for storing in memory the centralized client managers interested in the heartbeat.

The detection time-out dO is fixed or configured in each centralized client manager. The time-out can therefore be adapted according to the requirements and specific features of each process in a given application.

In all cases, the method of the invention for advising a client object of the unavailability of server objects is entirely transparent for that object and conforms to an asynchronous communications process: each time that the client object submits an advice request and the corresponding element Proxy has indicated to it that it has received the request, it can perform other tasks.

It receives a corresponding notification if one or more the server objects in respect of which it has requested advice becomes unavailable.

It has been shown above that in some cases it may be necessary to supervise a server object itself, if it can be destroyed independently of the others by a software error. The centralized server manager can then perform a supervisory task on server objects specified by the centralized client manager. In this case, the representative element Proxy of the client object is 15 modified to recover not only the identification parameter of the centralized server manager but also the identification parameter of the server object concerned.

As already shown, several mechanisms can be used to recover these two parameters, for example using the corresponding representative element Stub, modified accordingly. Thus Figure 2 symbolizes by means of an arrow the communication of these two parameters to the eeoc representative element Proxy of each pair by the .corresponding representative element Stub.

T. 25 The representative element Proxy adds these two parameters to the message sent by the client object and then transmits the message to the centralized client manager.

The centralized client manager can then send a message to the centralized server manager corresponding to a supervision request with the identification parameter of the server object concerned.

Supervision of the designated server object by the centralized server manager is particularly simple because they are both in the same process. The person skilled in -the art knows how to implement means in each server object for sending a notification to the centralized server manager when it is about to die.

In the latter case, the centralized server manager sends a corresponding unavailability notification to the centralized client managers concerned. In practice, and as shown in Figure 2, the centralized server manager therefore manages a data structure Tab 3 in which it holds, for each server object, the identifications of the centralized client managers interested in the unavailability of that server object. Each time it detects the unavailability of a server object, it looks up the centralized client managers concerned in this table in order to send them a corresponding notification.

In the example shown, the centralized server manager supervises objects ObjA and ObjB at the request of the ooe 15 centralized client manager LC 1 The two types of service, namely supervision of the centralized server manager and supervision of a particular server object, can co-exist, the centralized eeoc **server manager providing the appropriate response to the supervisory tasks on itself and in parallel assuring the supervision of server objects.

Although the invention is described above in an example of an application to a server object life cycle detection service, it applies equally well to a client 25 object life cycle detection service. In this case, each server process contains a centralized supervision manager for supervising centralized managers to be supervised in the client processes.

Claims (14)

1. A method of advising a first object of a first process of the unavailability of a set of objects of a second process, said first object sending a request for advice to each of the objects of said set via a pair of representative elements associated with each of the objects of said set, said pair including a first representative element located in said first process and a second representative element located in said second process, wherein, for each of said advice requests, the method includes the steps of: diverting the request for advice to a centralized :....supervisory manager of the first process via the first representative element, 15 supervision by said centralized supervision o0 manager of a centralized manager to be supervised of said second process, in order to send an ~unavailability notification to said first object ~if the centralized supervision manager detects failure to respond by said centralized manager to be supervised.

2. A method according to claim 1, wherein the first representative element of the first process transmit the requests for advice to the corresponding centralized supervision manager by adding an identification parameter of the centralized manager to be supervised concerned to each request as an additional parameter.

3. A method according to claim 2, wherein said first representative elements each transmit requests for advice to the centralized supervision manager, adding an identification parameter of the second object of the other process which said request concerns as an additional parameter.

4. A method according to claim 2 or claim 3, wherein the identification parameters are transmitted to each first representative elementby the associated second representative element or directly by the second object concerned.

5. A method according to any preceding claim, wherein the centralized supervision manager of a process manages a data structure for sorting requests for advice that it receives from objects of its process according to the centralized managers to be supervised concerned and to manage the sending of corresponding unavailability notifications to the objects concerned in its process, referenced in said structure.

6. A method according to any of the preceding claims 1 to 5, wherein the supervision of a centralized manager to be supervised consists in a centralized supervision ,manager requesting it to return it a heartbeat, the centralized manager to be supervised managing a data structure containing the identification of the centralized supervision managers interested in receiving 20 the heartbeat.

7. A method according to any of the preceding claims 1 to 5, wherein the supervision of a centralized manager to be supervised uses "ping" messages.

8. A method according to any preceding claim, wherein the time-out for detecting non-response from a centralized manager to be supervised can be parametered and is defined in the centralized supervision manager of each process.

9. A method according to any preceding claim, wherein the centralized manager to be supervised of a process itself supervises objects of its process, to return an unavailability notification to centralized supervision CE00368350.9 17 managers who have requested such supervision of it, if necessary, referenced in a corresponding data structure of the centralized manager to be supervised.

A method according to any of claims 1 to 9, the method being used in an application based on a CORBA type ORB distributed object manager.

11. A method according to any of claims 1 to 9, the method being used in an application based on a DCOM type ORB distributed object manager.

12. A computer program including instructions adapted to implement a method according to any preceding claim when said computer program is executed on a computer.

13. A memory medium, containing instructions adapted to implement a method according to any of claims 1 to 12 when said instructions are executed on a computer.

14. A method of advising of the unavailability of a set of objects substantially as hereinbefore described with reference to the accompanying drawings. Dated this 28th day of February 2000 ALCATEL by its attorneys Freehills Patent Attorneys