WO2004010289A2

WO2004010289A2 - Distributed object-oriented messaging method and system

Info

Publication number: WO2004010289A2
Application number: PCT/CA2003/001092
Authority: WO
Inventors: Samuel Guenette
Original assignee: Mediatrix Telecom Inc.
Priority date: 2002-07-19
Filing date: 2003-07-18
Publication date: 2004-01-29
Also published as: AU2003250665A1; AU2003250665A8; WO2004010289A3

Abstract

A distributed object-oriented messaging method on a network comprising establishing an action-reaction link between a first object and a second object, thereby establishing one of a first object and a second object as proactive and another one thereof as reactive so that an action is transmitted from the proactive object to the reactive object within an action message and a reaction is transmitted from the reactive object to the proactive object within a reaction message. The method further allows a number of actions, such as linking two objects, creating an object, a destroying an object, calling synchronous and asynchronous operations, transmitting an operation, locking an object, and locating an object, for a simple, portable, efficient and reliable messaging in small-embedded systems with limited resources.

Description

TITLE OF THE INVENTION

DISTRIBUTED OBJECT-ORIENTED MESSAGING METHOD AND SYSTEM

FIELD OF THE INVENTION

[0001] The present invention relates to distributed systems. More specifically, the present invention is concerned with a method and a system for distributed object-oriented messaging.

BACKGROUND OF THE INVENTION

[0002] Since the creation of networked computers, there have been intense development efforts in relation to distributed software applications. File sharing, email and instant messaging are some of today's popular applications. Generally, each distributed application type is associated with a specific dedicated network method, which usually comprises exchanging states, commands and parameters between a client and a server.

[0003] Typically, each packet received by an endpoint is analyzed, so that, from the extracted information, the application takes an action. Until such an action is taken a number of steps are required. Many different application types comprise a number of very similar low-level operations, so much so that it appears to be not very efficient to redesign every step each time a new application is created, and it is desirable to make abstraction of the network and to concentrate on the application core. [0004] Therefore, in object-oriented applications, it is desirable to allow calling an object operation independently of a location thereof and to provide a call mechanism thereof that is fully transparent to a user even over a heterogeneous network. Groups like the OMG (Object Management Group) and Microsoft have already solved parts of the problem with the creation of standards like CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Components Object Modeling).

[0005] Distributed objects method and system are illustrated in

Figures 1-2. A distributed system generally comprising a number of node units such as node units 12 and 14 distributed in a network and interconnected by a link 16, each node being a physical element representing a resource with processing and memory capabilities. Such nodes 12, 14 host a number of components and are used as execution platforms for one or more objects simultaneously. Typically, the node 12 is home to a client object 18 and the node 14 is home to a server object 20. People in the art are aware that each node unit of a distributed system may contain client objects, server objects or objects of any other type and that the system illustrated herein is only a simple example given for clarity purpose. The link 16 is a physical network allowing the two units 12, 14 and their associated objects 18, 20 to communicate between them.

[0006] In the system, the client object 18 typically sends requests to the server object 20 through, an interface 22. The client's request contains information on an operation to be executed, as well as its parameters. The client 18 has a dependency on the server object interface 22.

[0007] When the server object 18 is located on a remote node unit

14 as is the case in the present example, the client object 18 uses the link 16 via a proxy object 24a. The proxy 24a is responsible for marshaling (i.e. serialization of operation parameters) and connecting with a client Messenger 26a unit. The proxy 24a transmits the client 18-'s requests to the client Messenger 26a, which passes them to the server object 20. The marshaling actions are to be made by the client Messenger 26a derived from the proxy 24a that has knowledge of the interface 22. The client 18 is provided with a link on the proxy 24a, which validates the interface 22 and operates as an intermediate between client 18 and the server 20. The remote server 20 uses an adapter 28b, located on the same node 14 as the server 20, to recreate a memory environment and space of the remote client 18.

[0008] When a request from the client 18 is sent via the network as described hereinabove, the parameters of a requested operation are extracted and placed in the local memory, for use by the server object 20. This action is commonly called unmarshaling. The adapter 28 has a bi-directional connection with a server Messenger 26b, by which messages are independently exchanged, either coming from or going to the remote node 12.

[0009] The client and server Messengers 26a and 26b respectively are known in the art as singletons, which means that only one instance of such a Messenger may exist on the same node unit. Requests between two objets go through these Messengers, which generally manage the rules of the inter- nodal communication, known in the art as protocols.

[0010] The above described components of the distributed system provide that the interconnection between the client and the server is transparent and uncomplicated, since calling a remote server is done in a standard way. [0011] Turning now to Figure 2, a method using the above-described system, will now be explained. In a first step (110), a server objet is created, so as to allow calling for services therefrom, by the client, which specifies a target node as a host for the server to be created. The creation step 110a may be local, and the server object 20a is located and executes on the same node and inside the same process as the client 18, wherein a process comprises a control flux, known to the operating system, that has a private and protected memory space, in such a way that processes of a node share the available resources and execute concurrently according to the priority that has been allocated to them. In this case, no intermediate object intervenes between the client 18 and the server 20a. They are connected by a direct link, which allows a maximal efficiency when exchanging messages. Furthermore, as a common memory is then shared between the client 18 and the server 20a, active or not, the exchanges of structures or parameters of great size are very efficient, since these data do not need to be copied and are passed by reference.

[0012] The creation step 110b may be remote and the server object

20b may be created outside the process where the client 18 commanding this action is located. The target node for the server object may either be a distinct node or the same node where the client object is located. The client object is considered remote when located outside the process boundaries of the client object no matter whether it is located on the same node (since a given node may hold a number of processes) or on e distinct node. The creation parameters comprise the exact address of the node. This address may be statically or dynamically obtained by the client 18 and is to be provided to the system upon a request for creation.

[0013] Then, the client 18 sends a request to the server 20 thus created (step 120). In the case of a remote server object 20b, the mechanism ensures that the request goes to the associated node (step 120b). In the case of a local server object 20a, standard operations calling mechanisms are used (step 120a). In any cases (substep 120a and substep 120b), the call of an operation may be synchronous (substep 122) or asynchronous (substep 124). The synchronous call (substep 122) may be standardly performed. In the case of the local server 20a, the synchronous call (substep 122) uses the standard mechanisms of C⁺⁺. In the case of the remote server 20b, the method ensures that the client 18 is not blocked during the process of the operation and the asynchronous call (substep 124) is performed, which requires a number of evolved services, since no standard C⁺⁺ mechanism supports such a type of call. The asynchronous call (substep 124) therefore comprises allowing the server 20 to be active and receptive to the requests coming externally, so that the client 18, which calls an asynchronous type operation, is not blocked during the process of this operation.

[0014] The substep 120b of a remote request call may further comprise a substep 126 of marshaling. The marshaling step 126 is activated when an operation involving one or more parameters is called. Indeed, contrary to the case when the server object is local (20a), wherein the parameters of the operation may be passed by reference or by value, (noting that, since the memory is shared within a same process -the threads also share the same memory space-, it is more efficient to use a passage by reference), in the case when the server object is remote (20b), when calling an operation therefrom a passage by reference of the parameters is not possible, since the memory spaces are not shared between the objects 18 and 20b.

[0015] In a final step (130), the client 18 destroys the server 20 it has finished using. Indeed, the client object 18, which has a composition link or a simple possession link on another object such as the server 20, either local 20a or remote 20b, is responsible for its destruction. More precisely, in the case of a local server object 20a, the destruction step 130a comprises calling a local destruction for the local server object 20a and freeing a local memory associated therewith. In the case of a remote server object 20b, the destruction step 130b comprises sending a message commanding the destruction thereof through a Messenger and once the remote server object 20b is effectively destroyed, destroying the proxy attached to the client.

[0016] Since errors may occur in a communication between two nodes, especially on the Internet network, the method may further include a step 140 of reporting of errors to the application in a standard way.

[0017] Although the above system and method with commercial implementations are appropriate in most cases, they prove inadequate for embedded systems. Indeed, embedded are generally autonomous and possess so very little hardware resources that the usage of available resources is to be optimized, which makes choosing a distributed objects technology a lot more complex. In many cases, it is not required, or even inadequate, to abide by standards like CORBA or DCOM that are not intended for small-embedded systems. As an example, the Microsoft DCOM technology, based on the DCE RPC (Distributed Computing Environment Remote Procedure Call) protocol, is not easily portable over systems that do not use Windows based OS like Windows CE. Even Windows CE, which was designed for small embedded systems, appears not to be appropriate for many application types.

[0018] Therefore, there is a need in the art for a method and a system for distributed object-oriented messaging, which are simple, portable, efficient and reliable in particular in small-embedded systems with limited resources. OBJECTS OF THE INVENTION

[0019] An object of the present invention is therefore to provide an improved method and a system for distributed object-oriented messaging.

SUMMARY OF THE INVENTION

[0020] More specifically, in accordance with the present invention, there is provided a distributed object-oriented messaging method in a system having at least two objects communicating through process boundaries over a network of host nodes, comprising the acts of establishing an action-reaction link between a first object and a second object; preparation of data of an operation message to be exchanged between the first object and the act of establishing an action-reaction link establishes one of the first object and second object as proactive and another one thereof as reactive so that an action is transmitted from the proactive object to the reactive object within an action message and a reaction is transmitted from the reactive object to the proactive object within a reaction message.

[0021] Other objects, advantages and features of the present invention will become more apparent upon reading of the following non- restrictive description of embodiments thereof, given by way of example only with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In the appended drawings:

[0023] Figure 1 , which is labeled "Prior art", is a is a schematic diagram of a distributed system; [0024] Figure 2, which is labeled "Prior art", is a is a schematic diagram of a use of the distributed system of Figure 1 ;

[0025] Figure 3 is a flowchart of a method according to a first aspect of the present invention;

[0026] Figure 4 is a is a schematic diagram of a distributed object- oriented messaging system according to an embodiment of a second aspect of the present invention;

[0027] Figure 5 is a schematic diagram of a client calling a remote server mechanism in the system of Figure 4;

[0028] Figure 6 is a schematic diagram illustrating basic messages exchange between internal entities of a Messenger in the mechanism of Figure 4;

[0029] Figure 7 is a schematic diagram of classes comprised in the

Messenger of Figure 6; and

[0030] Figure 8 is a schematic diagram of internal states and transitions in a client transmitter comprised in Figure 7;

[0031] Figure 9 is a schematic diagram of internal states and transitions of a server transmitter comprised in Figure 7;

[0032] Figure 10 is a schematic diagram of internal states and transitions of a client receptor comprised in Figure 7; [0033] Figure 11 is a schematic diagram of internal states and transitions of a server receptor comprised in Figure 7;

[0034] Figure 12 is a schematic diagram of an object proxy comprised in the system of Figure 7;

[0035] Figure 13 is a schematic diagram of an object adapter comprised in the system of Figure 7;

[0036] Figure 14 is a schematic diagram of a marshaler used in the system of Figure 4; and

[0037] Figure 15 is a schematic diagram of an internal memory structure of the marshaler of Figure 14.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0038] Generally stated, the present invention provides a distributed object-oriented messaging method allowing a selective support of features required for small embedded systems, for a fast message exchange based on UDP/IP and improved portability by using standard object-oriented languages.

[0039] It is to be noted that while the C⁺⁺ language is the object- oriented language used herein for simplicity purpose, clearly any other object- oriented language implementing an inheritance feature may be used.

[0040] The system of the present invention comprises at least two objects located on different network nodes connected by a link allowing them to communicate transparently and to use each other's operations.

[0041] In order to allow the two objects existing on different nodes of a network to communicate, the method of the present invention establishes communication-monitoring guidelines defining constraints of information packet transport. At a higher level, the objects are free to expose all types of interfaces, which allows a great versatility and very few constraints at the distributed objects system level.

[0042] Turning first to Figure 3 of the appended drawings, an embodiment of a method according to the first aspect of the present invention will be described. The method provides that activating a creation operation returns a valid pointer to a newly constructed object on a remote node in such a way that the pointer is then able to be used by a client object remote to the server object, by establishing rules that govern the communication between the objects through the boundaries of the respective processes thereof. '

[0043] The method 200 generally comprises an act of preparation of the data, referred to as the marshaling act (300), an act of transporting the data (act 400) and an act of transmission of the data (act 500).

r0044] The marshaling act 300 allows exchanging parameter values that define an operation from a client node to a server node, and, once in the server node, reconstructing the operation inside the memory space of the server process in such a way that a call of the operation may take place, so that once the action and its corresponding operation are ready for transmission to the remote object, a message may be created and transmitted over the network. [0045] More precisely, the client communicates with the server only by the public operations of the latter. In the context of a system of distributed objects, the server may exist within a process different than that of the client. The server may either be local to the process of the client or on another process, or even on another node of the network. In the case when the server is located on a remote node, calling an operation of that server may not be directly achieved by a pointer local to the process of the client, since, the parameter values characterizing the operation need be transferred from one process to the other without information loss, and then the operation is to be reconstructed within the memory space of the server's process. Therefore, the marshaling act takes place. As people in the art are aware of, the term marshaling refers in the art to the action of serializing any type of data within an octet stream, so that they are ready for transmission by a RPC infrastructure for instance.

[0046] In the present method, the marshaling act 300 comprises the serialization of an operation within the octet stream for transmission to a remote process and the unmarshaling or extraction of the operation from the octet stream and its reconstruction.

[0047] The marshaling act 300 has the following characteristics:

- variable order of octets: two nodes may exchange messages without adapting the octet order, since the order standard is encapsulated within the octet stream. When two nodes use a different order standard, the transmitter determines the order and the receptor is responsible to put the octets back in the order corresponding to its natural order. Data type encoding is thus bi-canonical;

- octet alignment: the basic types are aligned according to their natural boundaries within the octet stream, in order to allow an efficient manipulation of the data on the systems requiring data alignment in memory, such as MIPS (millions of instructions per second) processors;

- Basic Data Encoding Rules (BDER): these rules define an encoding for each type of basic data covered by the protocol. The most developed types, such as structures or tables, are constructed from the basic types. The basic types may all be independently serialized within the octet stream. This octet stream may also be encapsulated within another octet stream.

[0048] Rules and standards governing the marshaling act 300 will now be described with more details.

[0049] The operation is serialized within an octet stream to be transmitted on the network. The octet stream is an abstract notion physically corresponding to a memory buffer sent to another node located on the network by any IPC (Inter-Process Communication) transport mechanism. The octet stream may also be compared to a long sequence (finite) of octets starting at a determined position. In C⁺⁺ terms, the octet stream corresponds to an octet table of finite length. The octets being part of the stream are numbered from 0 to n-1, wherein n represents the size of the sequence, and the numerical position of an octet in the sequence is called the index.

[0050] Two types of octet streams may be considered. On the one hand, message headers are represented in a format of octet stream. On the other hand, data are also represented in a format of octet stream. However, the octet stream of data differs from the octet stream of message headers and may be used independently of the type of message. [0051] The octet being the smallest element (it is made up of 8 bits), it may not be decomposed during marshaling. Hence, it is processed atomically and a most significant bit (MSB) thereof is serialized first.

[0052] Generally, a particular attention is paid to the octet order carried on a cable of a heterogeneous network. The well-known Big-Endian standard specifies that the MSB of the data is always transmitted first, whereas the well known Little-Endian standards specifies that the least significant octet (LSB) is transmitted first. For instance, the LSB of a long type (to be defined hereinafter), encoded according to the Little-Endian standard, is transmitted first on the network, whereas its MSB (index 3) is transmitted last.

[0053] In order to allow two nodes to share the same standard and to communicate without useless overload, the octet stream contains a flag that indicates which standard has been used upon serializing. The first bit of the stream represents a flag indicating the encoding order of the data that have been serialized: if the value is (0) the data have been encoded according to the Little-Endian whereas if the value is (1) they have been encoded according to the Big-Endian order. This value is not part of the encapsulated data, but it is part of the octet stream containing the data. Based on the value of the flag, the data are then serialized within the octet stream according to the BDER encoding rules. The same rules apply when the data are extracted from the octet stream. When extracting the data, the order of octets is inverted if required, by the receptor. It is to be noted that any other order standard type currently in use on a node requires that the transmitter serialize the data according to the Big-Endian order or Little-Endian order.

[0054] Moreover, in order to allow inserting and extracting basic types of the octet stream in accordance with specific requirements of a processor, each data is aligned on a natural boundary thereof. The natural alignment boundary for a given type comprises multiples of the size of the basic type (or the size its takes in memory), this size being calculated in number of octets. A size of type n begins at an index, within the data stream, which is equal to a multiple of n. For all the types covered, n may take one of the following values: 1 , 2, 4, or 8. For instance, a 32 bits (4 octets) type is aligned on an index that may be divided by four. When required, a gap may be inserted before a basic type so that the index of the first octet is properly aligned, which is referred to as a padding act. The value of the inserted octets is 0. The following Table I summarizes the alignment convention of basic types in memory:

Table I

[0055] The alignment is relative to the beginning of the message containing the octet stream transmitted on the network. The first octet of the stream is at index 0. For the octet stream resulting from the marshaling act 300, the first octet corresponds to the flag indicating the encoding order of the octets. Since an octet stream may be inserted after another octet stream, either the preceding octet stream has a length that is a multiple of eight or padding is required.

[0056] Before transmitting an action, a description of the desired operation is required, including the following elements: an operation identifier (OPID), zero or a return parameter; zero or input parameters (IN); zero or output parameters; and zero or input-output parameters. The OPID specifies the number of the called operation, since each operation of the object is granted a unique number within the context of its interface, related to the calling method used during the marshaling act 300. For calling an operation, the octet stream describing the operation contains, in order, the operation identifier and_, the value of each input parameter (IN). Each value is serialized according to the declaration order of the operation parameters. For instance, calling the following operation: int Example (IN short nPl, OUT shorts. rnP2, INOUT long* plP3) ;

is performed by the following marshaling of input parameters in Big-Endian:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

1 padding

Operation ID (OPID) nPl padding

*plP3

It is to be noted that only the values of the IN and INOUT parameters are encapsulated within the octet stream.

[0057] Once executed, the operation yields a result that is then transmitted with the reaction. The octet stream describing the result contains, in order, the value of the return parameter and the value of each output parameter (OUT). As for the call, each value is serialized according to the declaration order of the operation parameters. For instance, upon retum, the marshaling of the output parameters the operation described above corresponds to the following:

It is to be noted that only the values of the return parameter and the OUT and INOUT parameters are encapsulated within the octet stream.

[0058] As mentioned hereinabove, BDER are used for the marshaling of the data transferred between distinct processes. In the present method 200, all the basic types of C⁺⁺ are covered for each of the standards. The BDER rules also offer a representation for each octet order standard as follows:

- Integer Numbers: the following integer types are represented: short type and long type (see below). The signed types are represented as two's-complement numbers and an unsigned version is represented as an unsigned binary number.

Big-Endian octet Little-Endian octet short MSB LSB 0

LSB MSB 1

Short Encoding Big-Endian octet Little-Endian octet long MSB 0 LSB 0 1 1

2 2

LSB 3 MSB 3

Long Encoding

no rule is defined for the int base type. Since this type is of variable length according to the system architecture, it may not be encoded without ambiguity. An int typo integer is encoded as a long type no matter what the processor and the operating system. This constraint limits the value range of an int, but allows interoperability between the various systems;

Floating Point Number: this encoding follows the well known IEEE standard regarding the representation of simple and double precision numbers (see for instance "IEEE Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985.). For instance, a simple precision number (float), encoded according to the Big-Endian standard, is made up of the b, e and f elements in the following order: one bit for the sign (s), 8 bits for the exponent (e = e1 , e2) and 23 bits for the fractional part of the mantissa (f = f1 + f2+...+fn). This representation on 4 octets gives a value range of approximately 3,4E-38 to 3.4E+38 for the float type. The float, double, and long double types are represented as follows: Big-Endian octet Little-Endian octet float 0 0

1 1

2 2 3 3

Float Encoding

Big-Endian octet Little-Endian octet double f7 0 fδ 1 f5 2 f4 3 β 4

Ϊ2 5 fl e2 6 el 7

Double Encoding

Big-Endian octet Little-Endian octet long double

Unsigned char: corresponds to an unsigned and non-interpreted integer, represented by 8 bits. Its content is interpreted as an integer and may not be converted upon transmission. An octet corresponds to an unsigned char in C ;

bool: corresponds to a Boolean value encoded on 8 bits. True corresponds to the value 1 , while false corresponds to the value 0;

char: corresponds to an alphanumeric value encoded on 8 bits. Each of the characters corresponds to a display code, either defined in the standard US-ASCII (code 0-127) character table, or in the table (code 128-255) called IBM Character Set. The objects that exchange follow this standard for transmission at the network level. The receptor is responsible to convert the data in another representation, if required;

wchar_t: corresponds to an extended alphanumeric value encoded on 16 bits. Each of the characters is encoded following the ISO/I EC 10646-1 (Universal Character Set) standard. The objects, exchanging characters with multiple octets, follow this standard for transmitting at the network level. The receptor is responsible to convert the characters in another representation, if required. The following illustrates the representation in memory of the wcharj type:

Big-Endian octet Little-Endian octet wchar t MSB 0 LSB 0

LSB 1 MSB 1 wchαr_ t Encoc ling

[0059] Evolved types, such as structures, enums or classes, are built from the basic types. The evolved types have no restriction regarding alignment, but the alignment of the basic types they are built from is to be followed. The evolved types include the following:

- struct: elements of a structure are encoded following their order of declaration in the structure, wherein each element is encoded according to its basic type.

- union: the union value is encoded according to the type of its discriminant. The discriminant corresponds to the element with the largest size. If a number of elements share a same size, the first one that is declared defines the encoding format.

- table: each of the elements of the table is encoded in sequence, according to the type of table. The length of the table (number of valid elements) and the capacity (maximum number of elements) of the table precede the index value 0. The length and capacity are of unsigned long type and they are encoded in the order of declaration present. Only the valid elements are serialized within an octet stream. The value of the capacity is used to recreate exactly the same memory space, by the agent that extracts the data from the octet stream. In the case of a char table representing a string of characters, the terminating character (NULL) is also be encapsulated, so that the length of the table is equal to the length of the character string plus 1. The same thing applies for a table of wchar_t.

matrix: in the case of a multidimensional table, the elements of each dimension are encoded in sequence according to the type of the matrix. The number of dimensions, encoded as an unsigned long, is the first value in the octet stream. Then, for each dimension, the length and capacity thereof are encoded in order to precede the first data. The length is used to define the number of valid elements in the dimension, while the capacity is used to allocate the same memory space (same size) when the data is extracted. The length and capacity are of unsigned long type and they are encoded in this order: length, capacity. The elements are then ordered in sequence so that the index of the first dimension varies slowly and that the index of the last dimension varies quickly. Only the valid elements are serialized in the octet stream. The following example illustrates the octet stream resulting from the marshaling of the matrix of integers with three dimensions T: long [2 ] [2 ] [2] = { { { l , 2 } , { 3 , 4 } } ,

{ { 5 , 6 } , { 7 , 8 } } , } ;

which matrix is marshaled in memory according to the Big-Endian standard as follows:

In the case of a matrix of char representing strings of characters, the terminating character (NULL) is also be serialized. The same applies for a matrix of wchar_t.

- enum: types enumerated are encoded as unsigned long.

[0060] Following the marshalling act 300 described hereinabove, the transport of messages (act 400) between the nodes of the network may be performed by the UDP method based on the datagram concept. However, this method is connectionless and is not reliable due to a possibility of packet loss, dividing and inverting. Even though the transport of messages may be performed according to UDP, any other transport method offering the same services may be used, provided they have the following characteristics:

- the transport method is not based on a connection concept, and duplication or loss of packets is possible;

- the transport of octets located inside a packet is reliable, and the transport layer guarantees that the octets of a packet, when received, do not have errors and are in the same order as when transmitted;

- the transport method is able to manage packets of a length of at least 512 octets. The length of the packet is indicated; - the transmitter process and the receptor process are identifiable; and

- a notification is transmitted when the recipient is unable to receive the message. If a process dies, a node does not respond anymore or the network link is broken, a message of type ICMP Port Unreachable notifies the transmitter.

[0061] Only one UDP port is used per process on a node, both for transmitting and receiving messages, for the server and client type objects in this process, and the default port number is 22,500 for example. The first process of the node connects to this number, while the other processes use another number that is usually the next available after the default number. A different listening port may be used if it is published or known to all potential clients. The present method does not define a manner in which the listening port number is published, since a number of different mechanisms may be used. Moreover, the original port number of an MA message is used as destination port to transmit return messages ACK, NAK, or MR.

[0062] Thus provided with a transport means, the transmission act

(500) may be performed. As specified hereinabove, transporting messages between nodes and processes of a network is performed by a connectionless, packet transport method, which provides the possibility to lose and duplicate information. Therefore, the transmission method is designed so that that each message transmitted is received by the target object and that the action or associated reaction is executed only once, to ensure the synchronization of the client and server. The transmission act also allows an overlap and interlacing of messages exchanged between different objects of the network, which may comprise a number of nodes and processes, the objects being able to be located on distinct nodes. [0063] To achieve this, the transmission act 500 is based on a three ways handshake approach, whereby the transmitter is informed of the reception of a message by an acknowledgement of receipt, and the third "handshake" comes from the fact that for each action, there is a reaction from the server. The receipt of this reaction by the client then generates another acknowledgement of receipt, which terminates the exchange of action and reaction between the two objects.

[0064] Transmitting an action and its reaction, between two objects, is atomic. Even though the information is split into several messages, a client may transmit a new action as long as the current exchange is not terminated, so long as the sequence of message transmission is completed between the two objects. In addition, within the context of a link between two objects, the reaction message may not come from a server SB when the associated action has been transmitted from client C_A to server SA. Execution of actions coming from many clients is concurrently performed.

[0065] Therefore, the transmission of an action and its reaction involves exchanging at least two messages. According to the execution time of the action, up to two acknowledgements of receipt messages may also be transmitted, but generally, these messages are not used. Since the reaction is an action resulting from the execution of an operation by the server, its transmission is symmetrical to that of an action, which means the client and the server maybe considered as transmitter and receptor, and vice versa, which is reflected by the transmission method.

[0066] Transmission will now be described in detail. A transmitter Tx is defined as an object transmitting a message M_n, which is not an acknowledgement of receipt. A receptor Rx, is an object that sends an acknowledgement of receipt (MACK) or a negative acknowledgement (MNAK).

[0067] Transmission of a message between these two objects is governed by the following rules:

1. MACT is always transmitted from client to server.

2. MRCT is always transmitted from server to client.

3. MACK may be transmitted from the client to the server and vice-versa.

4. MNAK may be transmitted from the client to the server and vice-versa.

5. CFT (clock of elapsed time since the first transmission of a message) and CLT (clock of elapsed time since the last retransmission of a message) are reset to zero when M_n is transmitted for the first time.

6. C T is reset to zero after each retransmission of M_n.

7. Tx retransmits M_n after DRET (predetermined delay before retransmitting a message) has elapsed without any acknowledgement (MACKn) or a following message M_n+ι being received by Tx from Rx.

8. Tx keeps M_n in memory as long as it has not received an acknowledgement and that D_MAX (maximal delay to retransmit a message) has not elapsed.

9. Tx stops retransmiting M_n and removes it from its memory as soon as a message MACK_n, MNAK_n or M_n+ι is received from Rx.

10. CLR is reset to zero when Rx receives M_n+ι and Rx acknowledges receipt before a maximal delay before DACK (maximum delay before sending an acknowledgement of receipt).

11. If Rx receives a duplicate of message Mn, a MACK_n is transmitted without delay.

12. If Rx receives a message with a MSN different than the awaited n, this message is ignored and deleted.

13. If Tx receives a MACK for a message which acknowledgement of receipt has already been received, it ignores the message.

14. When CFT is equal to or greater than DMAX, TX may consider the link as being broken, stop the retransmission and delete M_n.

[0068] The following rules apply to an object of type client:

15. The receipt, by the client, of message MRCT_n+ι from the server is equivalent to the receipt of an acknowledgement MACT_n for the message MACT_n and rule number 9 applies immediately. 16. MACT_n+₂ may indicate receiving the message MRCT_n+ι. In some cases, the client may take advantage of the fact that DA_CK is greater than zero to transmit MACT_n+2 instead of MACK_n+ι.

17. The client waits for the reception of MRCT_n+ι before transmitting the message MACT_n+2.

18. If the server does not respond, the client assumes that it is destroyed, or that the target node is out of service and the last action has not been executed.

[0069] The following rules apply to an object of type server:

19. The receipt, by the server, of message MACT_n+ι from the client is equivalent to the receipt of a acknowledgement MACKT_n for the message MRCT_n and rule number 9 immediately applies.

20. MRCT_n+2 may indicate receiving the message MACT_n+ι. In some cases, the server may take advantage of the fact that DACK is greater than the execution time of the action to transmit MRCT_n+2 instead of MACK_n+ι.

21. If the client does not respond, the server assumes that the client is destroyed or that the target node is out of service. If the link was the last, autodestruction of the server follows immediately. Otherwise, it continues to serve its other clients normally. [0070] The client is always able to associate a reaction to one and only one action. The server may not execute a same action, which message has been duplicated by the network or by a retransmission, twice. This control is possible with the message sequence number MSN, which assignment and use, is governed by the following rules:

22. All messages transmitted on a link are numbered.

23. The MSN of the first message to be exchanged, between two newly linked objects, is equal to zero (0).

24. The MSN is sequentially attributed to the messages according to their transmission order. For each new message transmitted by the client, the MSN is incremented by 1 and for each new message transmitted by the server, the MSN is also to be incremented by 1 ;

25. The client and the server may not increment the MSN when transmitting a MACK or MNAK. They use the MACT number or the number of the associated MRCT.

26. When the value of the MSN reaches the maximum of a 32-bits encoded integer, the MSN of the following MA_n+ι is equal to 0. No particular management of the MSN is required in this case, because the messages of numbers inferior and superior to a current MSN are ignored.

[0071] Even though the retransmission parameters may be constant, an adaptive delay adjustment method, sensible to the underlying network types, may be contemplated, in order to overcome of non-application of the default values to certain network topologies containing a shorter, longer, or very variable propagation delay. The rules governing the adjustment of the retransmission delay of a message are as follows, where the suggested default values are proposed in relation to current Internet network considering that the propagation delay may easily reach 500 ms: 27. The accuracy of the CFT, CLT and _R clocks is at least in the millisecond order.

28. The default minimum value for DACK and D_REτ is 250 ms.

29. The suggested default value of DA_CK for Rx is 1000 ms: this parameter is constant and fixed to a same value all nodes of the network so as to prevent useless retransmission of messages MACT and MRCT between two nodes for which Dack of the first one if shorter than D_ret of the second one.

30. The suggested default value of DRET for Tx is 2000 ms and this parameter is adaptive, as will be explained hereinbelow. The value of this parameter is not to be set lower than the value defined by (D_Acκ 12).

31. The suggested default value for DMAX is 30,000 ms: this parameter is constant and at least four times the default value of D_REτ, since if the value selected for DMAX is close to that of DRET, retransmission may occur.

32. The DACK value is at least ten times smaller than DMAX in order to ensure an acceptable number of acknowledgement transmission from Rx to Tx, which tends to prevent, when there is some packet loss occurring on the network, Tx from falsely detecting a lost link.

33. For each retransmission of a message, from the second transmission, Tx adjusts DRET higher, following relation (1 ) hereinbelow.

34. For each new message, DRET is reset to its minimum value.

35. After five consecutive adjustments of D_REτ, its minimum value is doubled, in order to avoid, for example, useless message retransmission on the network, for which the propagating delay may be greater than DRET-

36. After ten consecutive receptions of acknowledgement receipts within a delay at least two times smaller than D_REτ, the value of the latter is divided by two, but it may not be smaller than the default value of DRET; thus, the retransmission time for a lost packet on the network is reduced and ultimately the reaction time. 37. The adjustment of DRET is made independently for each link since paths taken by messages, associated to different links for a single, over the network may vary, as well as the propagating delays. For example, communication between two given objects nodes A and B may take place over a local network, while communication between objects of nodes A and C may occur over the Internet.

The following relation governs the DRET adjustment:

D_RET = I + (char) rand O (1)

In this relation, the exponential component (D_REτ²) has an effect of automatically slowing down the messages stream in case of congestion or long propagation delay of messages, the random component (result of randQ function) has an effect of breaking up any potential transmission synchronizing between the nodes of a network, while the typecast of the return of the randQ function, in a signed char, allows to quickly add or remove the random factor included in the range [-128,127]. This technique avoids to use floating point, modulo and division computing.

[0072] It is to be noted that the above rules allow interoperability between different implementations.

[0073] The following describes the format of the message used during the transmission act 500 described hereinabove. The structure of a message comprises at least a general header followed by an action-specific header. All the headers that make up a message are aligned on a multiple of eight octets (64 bits), in order to ensure that the data of the serialized operation is also aligned on eight octets. [0074] The format of the messages is defined with the structures described in the "C" language. The byte ordering convention Big-Endian is used to describe the structures. The position of the elements of each structure is adapted for platforms with a processor that work with the Little-Endian standards, such as Intel™ X86 processors for example. Each of the bit fields is aligned on the MSB. Once again, the position is to be adapted for the platforms with a processor using the Little-Endian standards.

[0075] The transmission of the fields of a structure within the transport packet is done in the order of their declaration. The transmission of a field made up of more than one octet (e.g.: unsigned short or unsigned long) is done according to the standard defined by the BYTEordering flag. The transmission of the octets {unsigned char) is done according to the order of their declaration within the structure. For the bits making up an octet, the order of their transmission is managed by the transport layer.

[0076] Because the transport method used is UDP, it is not required to add the size of the message to the general header, since this value is extracted via a service of the transport layer. It is also to be noted that the size of the octet stream of an operation is computed from the size of the packet, minus the size of the headers that come before it.

[0077] To simplify the writing of structures, the following definitions are established: typedef struct MSG; typedef struct HDR; typedef unsigned char[l] OCTETSTREAM;

[0078] The structure of a general header of the method is as follows:

HDR hdrProtocolID

{ unsigned char ID [4]; unsigned char VERSIONMAJOR; unsigned char VERSIONMINOR;

} ; where:

ID identifies the type of method;

VERSIONMAJOR represents the most significant value of the method version;

VERSIONMINOR represents the least significant value of the protocol version.

HDR hdrRoot

{ const hdrProtocollD PROTOCOLID = { ^VD' , ^λO' , ^λO' , ^ΛM' , 0x01,

0x00 }; unsigned short BYTEORDERING: 1; unsigned short OCK:l; const unsigned short PADDING:14 = {θ}; unsigned long LKN; unsigned short MSN; unsigned short AID;

} ; , hdrProtocollD: the first four octets of the header identify the method and these octets contain the four characters "DOOM" encoded according to the standard

US-ASCII character table. They make up a magical number (0x4C494F50) that is the same for all the messages. The two following octets represent the version of the protocol and it applies to all the elements of the method

(marshaling, action, format of messages, etc.). VERSIONMAJOR, for the current specification, is one (1) and VERSIONMINOR is zero (0).

BYTEORDERING: this flag defines the octet order for the elements of the message to come. The zero (0) value indicates the Big-Endian standard is used, while a one (1) value indicates the Little-Endian standard is used. At the general header level, the LINKID, MSN and ACTIONID fields depend on the octet order.

LOCK: this flag, when positioned at one (1 ), indicates the client wants to lock the object. It offers the same functionality as the Lock action. It may be used with the Link, Create, Call, Send and Lock actions. For instance, the client may want to lock the object upon its creation and position the LOCK bit at one (1 ), within the creation message. To unlock the object, the Unlock message is used. PADDING: the flags inside the general header are each represented by a bit, that is to say the 16 bits following the hdrProtocol header are reserved for this, but only the first two bits are used, because the following 14 bits are reserved for future use. All the useless bits have a value of zero (0).

LKN: this element is the identifier of the link between client and the server.

Once allocated by the server, it stays the same for all the exchanges until there is destruction of the object or link severing.

MSN: this element is the message sequence number in relation to the link. To each action corresponds a reaction which message has the same MSN.

AID: this element is the identifier of the action to execute. The following Tables

II and III summarize the list of actions and reactions, as well as their numerical identifiers. The actions and reactions, noted mandatory (Man column), are to be supported.

TABLE II Actions ID TABLE III Reactions ID

[0079] Messages begin with the hdrRoot header. This structure clearly identifies all the common elements of a message. The version of the protocol and the type of action are examples.

[0080] The following sections specify the format of the headers of each of the messages associated to Table II:

- "msgLink' Message

The header of this message is:

HDR hdrLink

{ GUID CLSID;

GUID OBJID;

}; where CLSID uniquely identifies the class of object with which the client wants to create a link, and OBJID uniquely identifies the object (instance of object with corresponding CLSID) with which the client wants to create a link.

The message has two elements encoded in the following order: MSG msgLink

{ hdrRoot; hdrLink;

};

Both identifiers match and the object is to exist on the target node for the link to be accepted. No operation is associated to the message.

- "msgLinked" Message

The header of this message is: HDR hdrLinked

{ unsigned long LNK;

}; where LINKID is used to identify the link between the server and the client when exchanging future messages. The message has two elements encoded in this order:

MSG msgLinked

{ hdrRoot; hdrLinked;

};

No operation is associated to the message. - "msgUnlink" Message

The header of this message is empty and does not have a body because all the required information is located in the general header. The message has one element encoded in this order: MSG msgUnlink

{ hdrRoot;

};

No operation is associated to the message.

- "msgUnlinked" Message

The header of this message is empty and does not have a body because all the required information is located in the general header. The message has one element encoded in this order:

MSG msgUnlinked

{ hdrRoot;

} ; No operation is associated to the message.

- "msgCreate"

The header of this message is:

HDR hdrCreate

{

GUID CLSID;

} ^; where CLSID accurately specifies the class of the instance to create. The message has three elements encoded in this order:

MSG msgCreate

{ hdrRoot; hdrCreate; OCTETSTREAM osOperation;

}; The construction operation chosen by the client, the constructor, is serialized according to the rules of marshaling described above. The resulting octet stream is inserted after the hdrCreate header. - "msgCreated" Message

The header of this message is: HDR hdrCreated

{ GUID OBJID; unsigned long LNK; unsigned long PADDING;

}; where OBJID uniquely identifies the object created, LINKID is used to identify the link between the server and the client when exchanging future messages, and PADDING meas that the 32 bits that follow the LINKID are used to align the octet stream of the operation. All padding bits have a value of zero (0).

The message has three elements encoded in this order: MSG msgCreated

{ hdrRoot; hdrCreated; OCTETSTREAM osOperation;

}; The return of the construction operation, executed when creating the object, is serialized according to the rules of marshaling described above. The resulting octet stream is inserted after the hdrCreated header.

- "msgDestroy" Message

The server is destroyed once the client does not require the services of the server anymore. The msgDestroy message is used for this: the header of this message is empty and does not have a body because the required information is located in the general header. The message has one element encoded in this order: MSG msgDestroy

{ hdrRoot;

} ; No operation is specified in the message because there is never exchange of parameters at the destruction.

- "msgDestroyed' Message

The complete destruction of the object is announced to the client with the Destroyed message. The header of this message is empty and does not have a body because the required information is located in the general header. The message has one element encoded in this order:

MSG msgDestroyed

{ hdrRoot;

-"msgCai Message

The header of this message is empty and does not have a body because the required information is located in the general header. The message has two elements that are encoded in this order:

MSG msgCall

{ hdrRoot;

OCTETSTREAM osOperation;

} ; The operation selected by the client is serialized according to the rules of marshaling. The resulting octet stream is inserted after the hdrRoot header.

This operation may not involve a creation or destruction action.

- "msgReturn" Message

MSG msgRetum

{ hdrRoot;

OCTETSTREAM osOperation;

} ;

The return of the operation is serialized according to the rules of marshaling.

The resulting octet stream is inserted after the hdrRoot header.

- " sgSend' Message

MSG msgSend

{ hdrRoot;

OCTETSTREAM osOperation;

This operation may not involve a creation or destruction action.

- "msgReceived" Message

The header of this message is empty and does not have a body because the required information is located in the general header. The message has one element encoded in this order:

MSG msgReceived

{ hdrRoot;

} ^; No operation is associated to the message. -"msgLock' Message

MSG msgLock

{ hdrRoot;

}; No operation is associated to the message.

- Message « msgLocked »

MSG msgLocked

{ hdrRoot;

}; No operation is associated to the message.

-"msgUnlock' Message

MSG msgUnlock

{ hdrRoot;

}; No operation is associated to the message. - "msgUnlocked" Message

The header of this message is empty and does not have a body because the required information is located in the general header. The message has one element encoded in this order: MSG msgUnlocked

{ hdrRoot;

};

No operation is associated to the message.

- "msgLocate" Message The header of this message is:

HDR hdrLocate

{ GUID CLSID; GUID OBJID;

}; where CLSID uniquely identifies the class of objects searched for; this identifier may not be null; and OBJID uniquely identifies the searched object (instance of class with corresponding CLSID), and this identifier may be null.

The message has two elements encoded in this order:

MSG msgLocate

{ hdrRoot; hdrLocate;

}; No operation is associated to the message.

- "msgLocated" Message

The header of this message is: enum eLocalizationStates

{ ClassUnknown = 0, ObjectUnknown = 1 ,

ClassHere = 2,

ObjectHere = 3,

ClassForward = 4, ObjectForward = 5

};

HDR hdrLocated

{ eLocalizationStates LOCATIONSTATUS;

}; where:

Locationstatus: this element matches the result of the localization action. The ClassForward and ObjectForward results indicate the message goes on with an IOR (Interoperable Object Reference) header.

HDR hdrlnteroperableObj ectReference

{ hdrProtocollD PROTOCOLID; unsigned char OCTETORDΞRING: 1; const unsigned char PADDING: 7 = {θ}; const unsigned char ADDRESSFAMILY = {θ}; GUID CLSID; GUID OBJID;

} ;

PROTOCOLID: this element is the method identifier that is repeated in the IOR to allow a client to know, in advance, the protocol version required to communicate with the server.

OCTETORDERING: it is possible that the IOR is generated by a system different than the system that transmits the localization. In this case, it is thus necessary to adjust the octet order differently for this section of the message.

PADDING: these are bits of value zero for alignment purposes.

ADDRESSFAMILY: this byte contains an identifier that represents the addressing type supported by the node where the object lives. The present method supports the IP addresses family (value (0)), has the value (0) and is described by the header hdrlnternetObjectAddress (IOA).

CLSID: this element uniquely identifies the type of object with which the client wants to create a link. The CLSID is equal to the value specified by the client.

OBJID: this element uniquely identifies the object with which the client wants to create a link. The OBJID is equal to the value specified by the client, except in the case where the reference specified would not indicate any object in particular. At the moment, the GUID of the object found is returned to the client. HDR hdrlnternetObjectAddress { unsigned short PROCID; const unsigned short PADDING = {θ}; unsigned long NODEID;

} ;

PADDING: these are bits of value equal to zero for alignment purposes.

PROCID: this element corresponds to the address of the server in a node context. This address, in numerical format, corresponds to the UDP port number used for the reception of messages by the server.

NODEID: this element corresponds to the address of the node where the object is located. The address is in numerical format.

The message has up to four elements encoded in this order:

MSG msgLocated

{ hdrRoot; hdrLoca ed; hdrlnteroperableObjectReference; hdrlnternetObjectAddress;

The IOR is only present when the localization state is equal to ClassForward or ObjectForward. When the localization state is negative, the IOR and IOA headers are not present. Only one IOR is allowed in the message. No operation is associated to the message.

-"msgAck' Message

The header of this message is empty and this header does not have a body because the required information is located in the general header. The message has one element encoded in this order:

MSG msgAck

{ hdrRoot;

};

No operation is associated to the message. -"msgNak" Message

The header of this message is:

HDR hdrNak

{ unsigned char ERRORLEVEL; unsigned long ERRORCODΞ;

}; where:

ERRORLEVEL: this element corresponds to the error level. Smaller the number is, worst is the error. The levels defined may be: Critical (0), Error (1), and Warning (2).

ERRORCODE: this element corresponds to the code that identifies the cause of the error.

The message has two elements encoded in this order:

MSG msgNak

{ hdrRoot; hdrNak;

};

No operation is associated to the message

[0081] A number of further acts to be performed as needed, include: a linking act 220, a creating act 230, a destroying act 240, a calling act 250, a transmitting act 260, a locking act 270, and a locating act 280. Each of these acts is carried out with an action and its associated reaction. Establishing a root link between two nodes is always the first action to be executed. It is then possible to create (act 230) or link (act 220) objects between them, following the requests of the client. If the root link between two nodes is broken or recreated, all the sub-links are considered broken and all objects are destructed (act 240), except those that have at least one further link still active. In the same way, a server and its link may be destructed after a predetermined amount of time if the client does not acknowledge the receipt of the reaction. The following describe each of the acts listed hereinabove in more details. [0082] The linking act 220 allows linking two objects by creating and identifying a link. The msgLink message that transports the aLink action is used to activate the creation of a link between the client and the server. Once the link is established, the client may transmit requests to the server, which is clearly identified by its CLSID and OBJID. The action of the object is executable provided the object already exists on the target node and the CLSID and OBJID specified inside the action match with those of the object. The target node verifies the match of these two values match before accepting the request of the client, so as to avoid that the client uses an interface that is not supported by the server.

[0083] In many cases, it may be useful for a client to be able to create a link with an already existing object. When an object migrates to a new node of the network, the client needs re-establishing the link with it. Once the new node is located, the client transmits the msgLink message to get a new LNKID. The msgLinked message transports a rϋnked reaction. The LNKID is transmitted to the client inside this message. Otherwise, a msgNak error message is returned.

[0084] A client may break the link it has with an object without requesting its destruction, by using a msgUnlink message that transports an aUnlink action. It is presumed that in a case of multiple associations or infinite persistence, the client uses this message to signal that it does not want the services of the server. Once the message has been received and accepted by the server, the LNKID becomes invalid. The msgUnlinked message carrying a rUnlinked reaction notifies the client that the link is now broken, or a msgNak error message is returned.

[0085] To exchange messages between two objects, a root link is required between their respective nodes, on which messages of the method's basic acts are exchanged. For instance, the message of creating an object is transmitted on the link established between the client's node and the target node where the server is to be created. Such a root link is possible because a node is defined as a persistent object of server type, which may not be created not destructed. When establishing this link between two nodes by the msgLink message, the MSN sequence number of the messages is equal to (0), as well as the CLSID and OBJID.

[0086] The creating act 230 comprises creating and initializing an object, in reference to an operation and to the value of parameters associated therewith. If the creating operation is not explicit, the object is made up and its attributes are initialized with default values.

[0087] More precisely, during the creation act 230, an object is created on a target node by a client located on a client node provided that the two nodes are connected by a root link as explained hereinabove (act 210). A msgCreate message carrying aCreate action and a creation operation in the form of an octet stream is used to activate the creation of the object on the target node, the class of the object being defined with the CLSID identifier. If the object is unable to be created, a msgNak error message is returned, otherwise, the msgCreated message carrying a rCreated reaction notifies the client that the object is now created and fully functional, and further carries an OBJID identifier of the newly created server object and return parameters {out). From this point on, a link between the client and the server is active. This link, identified by a LNKID, is generated by the target node where the server is created. In fact, the aLink action is implicitly performed when creating an object.

[0088] The creation act 230 is executed synchronously, which means the client may continue its execution only once the msgCreated message is received. After receiving this message, the client may go on with the execution and call the services of the object.

[0089] It is to be noted that by default all created objects are public.

However, it is possible, when creating the object, to lock it, so that the object may not be shared by several clients and only the creating client may send requests thereto, as will be further described in relation to act 270.

[0090] The act 240 of destruction of an object is performed in reference to a single object, and results in the total destruction thereof, including its components and its links.

[0091] More precisely, a msgDestroy message carrying an aDestroy activates the destruction act 240, causing the total destruction of the object, its components, and its links, even if a number of clients are linked to the same server and only one of then request the destruction thereof. No protection mechanism, such as calculating a number of active links, against the hasty destruction of an object is defined by the method 200, but it may be implemented.

[0092] The client is notified of that the object is destroyed by a msgDestroyed message carrying a rDestroyed reaction. From this point on, the LNKID is invalid, so that if the client, which destroyed the server, or any other client that was linked thereto try to transmit a new message on the link, a msgNak error message is returned.

[0093] The calling act 250 comprises activating an operation of an object, in reference to a target object, to the operation, as well as to the values of the operation parameters. This act is synchronous, i.e. the client waits for the operation to be executed before taking back the control. The end of the execution is signaled by a return of the operation result, which transfers the control to the client that has called the operation and is only allowed within an operation previously activated by a call. In addition the return signal comprises an optional list of values that is made available when the client takes the control back.

[0094] More precisely, a client generally performs the operation- calling act 250 for the purposes of using the services of a server through the call of operations available by an interface thereof. A msgCall message carrying an aCall action activates synchronous operations of the server. The msgCall message is made up of an octet stream describing the operation to be called, as will be further described hereinbelow. Once the msgCall message is transmitted, the client waits for the end of execution of the called operation, signaled by a msgReturn message carrying a rReturn reaction, before taking the control back. The return of operation as well as the parameters thereof are contained in the msgReturn message. In the case when the operation designated by the aCall action fails to be executed, a msgNak error message is returned instead of the msgReturn message, notifying that the operation has failed at the object level, either due to inadequate parameters, to an inappropriate call sequence, or simply to a particular state of the object. As explained further hereinbelow, the method 200 provides means for managing this type of error.

[0095] The transmission act 260 comprises sending a call signal for an operation to an object, in reference to a target object, to the operation, as well as to the values of the operation parameters. This act 260 is asynchronous. [0096] More precisely, the transmission act 260 is a specific act of the method 200 that allows calling an asynchronous operation of an object, since a given client may have a number of asynchronous operations executing on one or more servers of different classes. A msgSend message that carries an aSend action is used to activate the asynchronous operations of the server. This msgSend message is made up of the octet stream that describes the operation to be called in act 250. The client is not required to wait for the beginning or the end of the execution of the operation to go on with its execution, since the client is given back the control immediately after the message is transmitted. A msgReceived message carrying a rReceived reaction and transmitted by the server as soon as the aSend action is received notifies the client that the signal has been received. The msgReceived message does not include any return parameter, which involves that receiving the msgReceived message does not mean that the server successfully executes the action. If the client wants to know the status an operation's signal, an additional notification mechanism may be integrated into the interface of the server.

[0097] As mentioned hereinabove, the locking act 270 allows limiting the access to an object.

[0098] More precisely, the client desirous of benefiting from the exclusive services of an object may resort to the locking act 270, which enables to restrict access to the server object, so that once locked, it may not be shared. A msgLock message carrying an aLock action is used to lock the access to an object. However, since a node may accept or refuse to lock the access to an object according to its own parameters, it is not guaranteed that the action is successful. The object is to be itself unlocked when executing the locking action otherwise the action is rejected. If two clients request a lock of the same object, the first message processed by the node is responded to. To avoid such conflict conditions, an object may also be locked upon its creation. A msgLocked message carrying a rLocked reaction notifies the client that the object lock is successful, or, if not, a msgNak error message is returned. Once locked, the server may accept only messages from the client which address and LNKID match those used when locking. In addition, the server may not migrate from one node to another as long as it is under lock.

[0099] When a client wants to share access to the object that it has previously locked, it may unlock it with a msgUnlock message carrying an aUnlock action. Only an unlock action from the client that has last locked it accepted by the server. Otherwise, a msgNak error message is returned. Once the server is unlocked, the msgUnlocked message carrying a rUnlocked reaction is returned to the client. From this point on, any other clients may call the services of the server, and even to acquire a new lock on this server.

[00100] The locating act 280 comprises locating an object among the nodes of a network, in reference to the object and to the class thereof.

[00101] More precisely, the locating act 280 is an extended optional act that allows a client to locate an object by transmitting a msgLocate message, considering that a given object may be activated at different locations throughout its life, i. e it may dynamically migrate from one node to the other. Therefore, an object's address obtained by the location act is an ever to be verified data. For example, once a link is broken, the client may try to reuse a previous address, but in case it fails, the client has to repeat the locating act 480. Similarly, the locating act 280 is to be repeated each time the server migrates to another node of the network.. [00102] The locating act 280 is initiated with the msgLocate message, which identifies, for example, the class and object that are searched for. The aLocate action has many uses. For example, it may be used by a client to find the address of an object, or to verify that a reference to an object is still valid. It may further be used by the client to validate a node's capability to create an instance of a certain class of objects. Alternatively, it may be used as an optimizing mean in the case where the client does not know the exact location of the server, so as to avoid any useless transmission of a creation message containing a great amount of data for instance.

[00103] During the locating act 280 a match is sought between the OBJID and the valid CLSID. In the case when the client uses an OBJID equal to zero, no particular object is searched, but rather a node that has the capability to create an instance of a specified type.

[00104] The msgLocate message is the only message that supports many recipients, thereby allowing broadcasting a message for a more efficient location in the network. The client may therefore receive a number of msgLocated messages coming from various origins. While the broadcast is performed by port 8945, all reactions are transmitted in unicast to the original PROCID.

[00105] The information generated by the locating act 280 is returned by the msgLocated message carrying a rLocated reaction to an aLocate location action. The locating act 280 may fail since a node may be unable to locate an object. When the search is successful, the msgLocated message may include an IOR (Interoperable Object Reference). In all cases, the client is informed of the search's state, as described below: - ClassUnknown: the class is unknown from the target node and all searches initiated by this node have failed. This state implies that the object looked for is also unknown. The message does not contain an IOR.

- ObjectUnknown: the object is unknown from the target node and all searches initiated by this node have failed. However, since the class specified is not unknown, the message contains an IOR reference pointing to the node able to create instances of this class.

- ClassHere: the target node knows the class and is able to create instances thereof, but no object in particular has been searched for. The message msgLocated does not contain an IOR since the client already possesses the location information.

- ObjectHere: the object exists on the target node and the message msgLocated does not contain an IOR since the client already possesses the location information.

- ClassForward: the class exists on a node different from the target node and the message contains an IOR reference.

- ObjectForward: the object exists on a node different from that of the target node and the message contains an IOR reference.

[00106] A given node may only partially support the locating act 280, whereby the node may accept actions dedicated to the classes and objects it supports, while returning a ClassUnknown state or ObjectUnknown state for the others: the node then does not research the network to locate the class of he object. In this case, the state of the search result never has either a ClassForward status or a ObjectForward status.

[00107] The msgLocated message may also be returned automatically to indicate a new location of a known object, which allows keeping track of the objects as they migrate. Indeed, the locating act 280 automatically starts and replaces an action requested when the class involved in the action does not exist or when the object involved therein, yielding a ClassForward status or a ObjectForward status. For instance, if a call to operation is sent to an object that is not located anymore on the node targeted by the message, the msgLocated message, with the ObjectForward state, is returned to the client to indicate the new location of the object in the network. Once thus notified of the new location, the client is responsible to retransmit the original message to the newly located server. However, since the LNKID is not valid anymore, the link is to be re-created to allow transmitting the action.

[00108] During the locating act 280, the IOR is used to report the exact reference of the object to the client making the request, wherein the reference to an object may include the following characteristics:

- Protocol Version refers to a version of the method used to communicate with the object defined by the IOR;

- Range of address relates to the address type used to reference the object on the network;

- Class Identifier refers to the class of the object identified by a CLSID;

- Object Identifier is an instance of the object identified by an OBJID;

- Node ID refers to an address of the node where the object is located; and

- Process ID is a message-receiving port of the process where the object is located.

[00109] No strict publication mechanism of the IOR, to make public the reference to an object or to a class of objects, is defined by the method 200. The nodes of the system ensure the exchange of the lORs.

[00110] It is to be noted that the locating act for a node is optional. When not supported by the node, the node returns the message msgNak to notify the client that it is unable to execute the aLocate action. [00111] In order to prevent messages to get lost, the method 200 further provides a mechanism ensuring that messages that do not reach their destination be retransmitted. The reaction message, received by the client and confirming that the server has well received the action message, is usually used as an acknowledgement receipt for the action message. However, it is sometimes useful to send an acknowledgment of receipt before the end of the execution of the action after a predetermined maximum period of time, to avoid the retransmission of the original message by the client. A msgAck message is used in this case. A new action message received by the server confirms that the client has well received the reaction message. Usually, the action message is used as an acknowledgement of receipt to the reaction message. However, it is sometimes required for the client to send an acknowledgement of receipt to the server when no action is transmitted within a predetermined maximum period of time. As in the previous case, the msgAck message is used. The msgAck message is identified by the same LINKID and MSN as those identifying the original message and for which an acknowledgement of receipt is transmitted. These two identifiers allow associating the acknowledgement of receipt to the message previously transmitted. When the acknowledgement of receipt is received, the retransmission of the original message is stopped.

[00112] In addition, the method 200 also provides for managing exceptional conditions, which may induce errors, such as when, for example, a message header is not formed properly, an action is not supported by the server, a message content is erroneous, etc. An error message, originating from the server or the client, usually means than an exception has occurred. An msgNak message reports the error level and code of a low-level exception of the method. For instance, three levels out of 256 may be defined, which are sufficient in the majority of cases, as follows: - Critical: this level indicates that a critical error, generally irretrievable, has occurred at the system level, and causes the system to be blocked, so that no other process may be performed by the system before it is reset. For instance, a memory leak overloading the system resources may thus force it to restart.

- Error, this level indicates a specific process has failed without obstructing the system to work. This error is generally isolated and irretrievable for the process that experienced it. For instance, executing a synchronous operation is aborted because of a processing error within the object. In this case, the answer may not be returned to the client, but the msgNak informs it of the situation.

- Warning: this level indicates that an error that does not have a real impact on the process has occurred. The process may continue almost normally after the error has been retrieved. For instance, when a client requests the destruction of an object that does not exist or has already been destroyed, an error message of warning level is returned, although this error does not have any impact and the client may go on normally with the execution.

[00113] Obviously, more levels may be defined as needed. Each error message is associated to a pre-defined node number identified over 32 bits. Protocol, communication and marshaling errors maybe reported by this mechanism, contrary to errors occurring at the client objects and server objects level. The mechanism for notification of such errors between client and server is implemented at the objects interfaces level and encapsulated within standard messages of the method. For instance, if an operation returns a Boolean indicating an execution is successful or not, this Boolean is transmitted by the standard operation return mechanism with the msgReturn message. [00114] A relatively complete set of errors has been defined for the DOOM needs, wherein a name, code, severity level and definition are associated to each error. The format used may be as follows: name (code, level): definition. The errors that may be flagged in the msgNak message are for example the following:

- UnknownC tical (0, critical): an unknown error of critical level has occurred;

- UnknownError (1 , error): an unknown error of error level has occurred;

- UnknownWarning (2, warning): an unknown error of warning level has occurred;

- NodeShutdown (3, critical): an error internal to the node has occurred and the node must restart;

- ProcessShutdown (4, critical): an error internal to the process has occurred and the process must restart;

- OutOfMemory (5, critical): there is no more memory available on the node;

- OutOfResource (6, critical): there is no more resource available on the node;

- ProcessUnknow (7, error): the target process is unknown from the node;

- ClassUnknown (8, error): the class is unknown from the process;

- ObjectUnknown (9, error): the object is unknown from the process; it has been destroyed or has never existed;

- LinkUnknown (10, warning): the link is unknown;

- BrokenLink (11 , error): the link is broken and thus invalid;

- ActionUnknown (12, warning): the action is unknown and not specified by the protocol;

- ActionUnsupported (13, warning): the action is not supported by the node;

- Action Rejected (14, error): executing the action has been refused by the node;

- ActionAborted (15, error): executing the action has been cancelled by the node;

- OperationUnknown (16,warning): the operation is unknown to the server object;

- Operation Unsupported (17, warning): the operation is not supported by the server object;

- OperationRejected (18, error): executing the operation has been refused by the server object;

- OperationAborted (19, error): executing the operation has been cancelled by the server object;

- UnmarshalingFailed (20, error): reconstructing the operation has failed;

- MessageUnknown (21 , warning): the type of the message received is unknown;

- Messagelnvalid (22, error): the format of the message received is invalid; and

ServerAborted (23, critical): the server does not respond to actions anymore. All its operations currently executing are terminated and the object destroyed. The link is then broken.

[00115] Although the present method 200 does not specify any authentication or encryption mechanism, it may allow the server to accept or refuse to process a message. In general, the server accepts to execute any action properly formulated, but it is free to establish its own acceptation policy. For instance, the server may be provided with a security mechanism that rejects all messages that do not come from a specific node. When a message is rejected, the server returns an error message to the client, and if the client still tries to transmit messages thereto, the server may ignore them, without further returning error messages.

[00116] Turning now to Figure 4 of the appended drawings, a system according to an embodiment of the second aspect of the present invention will be described.

[00117] As a distributed objects system, it comprises a first node unit

12 hosting a client object 18 acting in a first process and a second node unit 14 hosting a server object 20 acting in a second process, connected by a link 16. The server object 20 may be located in the same process, in another process, or in a process that executes on a remote node, in relation to the client object 18.

[00118] According to the present invention, the link 16 is an action- reaction link 16. As defined in the art, an action usually comprises executing a primitive operation of an object, in an atomic way, and it is to be executing quickly to avoid modifying the behavior of the system. Executing an action results in a state change at the object level. The system behavior is made up of primitive actions. The system may execute a number of actions simultaneously, providing that their execution is independent. A primitive action associated to a message is made up of a target object, a reference to an operation or a signal (referred to as the request) and may include parameter values. A reaction results from executing an action.

[00119] Communication and message exchange between the objects

18 and 20 relies on an action-reaction principle whereby every action generates a reaction, the client 18 being proactive and the server 20 being reactive. The client initiates the link 16 by requesting the creation of the server or by requesting to be linked to an already existing server object. The client 18 then transmits the action by the link 16, so that the server 20 receives the action, executes it and returns the result by the reaction. Consequently, the exchange of messages between the objects 18 and 20 is not symmetrical since the action is transmitted from the 18 to the server 20 within an action message, while the reaction is transmitted from the server 20 to the client 18 within a reaction message. Moreover only the client 18 may transmit an action and only the server 20 may transmit a reaction, contrary to other types of messages, which may be transmitted by any one of the two objects.

[00120] As explained hereinabove in relation to the first aspect of the present invention, the action-reaction link 16 of the present invention involves specific features in a marshaling act, and in a message transmission act and a message format rules.

[00121] As more precisely illustrated in Figure 5, the client object 18 uses the services of a proxy 24 and the server object 20 uses the services of an adapter 28, the proxy 24 and the adapter 28 communicating via a Messenger 26, which provides that messages are transmitted from the client 18 to the server 20 and vice versa, in such a way that the client 18 and the server 20 objects may operate without modifying a respective source code thereof.

[00122] An operation called by the client 18 through the proxy 24

(arrow A) is serialized (arrow B) and then sent to the Messenger 26 (arrow C) for transmission across the boundary separating the client and the server processes respectively. Even though only one Messenger 26 objects is illustrated, it is to be understood that each process has an own instance thereof, as will be described in more details hereinbelow.

[00123] A cooperation of the different components of the link 16 as described hereinabove allows calling an operation of a remote object's interface as now described. The Messenger 26 (CMessenger class) transmits and receives messages, by acting between the proxy 24 and the adapter 28 as an interface allowing to exchange serialized operations through the boundaries of the network of remote nodes. The CMessenger class is complex and made up of a number of other classes and methods, as will now be described in relation to Figure 6.

[00124] Figure 6 describes the Messenger 26, limited to the

CMessenger class itself, as well as its four main classes. In this Figure 6, Send messages represent the transmission of a message between the client and server processes separated on the Figure 6 by a vertical full line. The client 18 is located on the left side of the boundary, while the server 20 is on the right side. On the client side, the Messenger object 26 is specialized as a client Messenger 26a, while on the server side, it is specialized as a server Messenger 26b, for the purpose of better distinguishing the behavior of the Messenger 26 according to the type of objects that use its services. In reality, the CMessenger class is not specialized in function of the role played, because it may support both roles at the same time.

[00125] When the client 18 calls an operation of the proxy 24 (see arrow A Figure 5), the proxy 24 activates the serialization of the operation (see arrow B Figure 5) and calls the Messenger 26 (see arrow C Figure 5) to transmit the message and its action to the server 20 located on a remote node. As detailed in Figure 6, the client Messenger 26a uses a client transmitter 30a {CCIientTransmitteή to transmit the message to a server receptor 32b {CServerReceptoή located in the opposite side of the process boundary. The server receptor 32b receives the message and redirects it to the server Messenger 26b that is responsible to transmit the action to the associated adapter 28 (see Figure 5). Once the action is executed, a message of reaction is transmitted from a server transmitter 30b {CServerTransmitteή to a client receptor 32a {CCIientReceptoή. The reaction is then routed to the external client 18, while the client transmitter 30a transmits an acknowledgement of receipt to the server receptor 32b, thereby concluding the exchange. Even though the CMessenger 26 is the same both on the client side and on the server side, the transmission and reception classes are different, since their behavior is closely related to their role.

[00126] Figure 7 presents classes comprised in the CMessenger 26.

It is to be noted that there is a single Messenger in a same process. The CMessenger instance is a singleton to which all specialized proxy and adapters of the process are connected to. The Messenger class 26 is also active, which allows it to initiate execution streams based on internal and external events such as the time events, so as to offer a concurrent execution of calls from different objects, non synchronized, and which may exist on distinct nodes of the network. The class memorizes the node identifiers and process identifiers. The Messenger 26 therefore distinguishes itself in other instances of the network by creating unique link identification for each object it manages. The Messenger 26 is responsible of the localization of the server 20 when the client 18 specifies no address.

[00127] It is to be noted that a CAsyncSocket 34 is assigned to the

CMessenger class 26 (see Figure 7), which is responsible for demultiplexing incoming messages to the proper receptor 32a, 32b. The number of proxies 24 or adapters 24 linked to the Messenger 26 is limited by the method that supports up to a maximum of 2³² different links. Even today, most systems are unable to support such a number of instances, and the number of associations is generally limited by the implementation. For each proxy registering to the Messenger, a finite number of instances of the client transmitter and client receptor classes are associated thereto. The same principle applies to the registering of an adapter, and in this case the instances are those of the server transmitter and server receptor classes. Each proxy and adapter thus have their own states instance, according to the exchange of messages in the Messenger, which allows to greatly simplify the internal code of the CMessenger class and only requires a small surplus of memory because the data structure, internal to the transmitters and receptors, is simple and light. In addition, the exchange of messages between two objects is independent from the other objects linked to the Messenger.

[00128] The operations of the CMessenger class interface replicate the acts of the method of present the invention, described hereinabove. For instance, when a client creates a remote object, in reality it creates the proxy. This same proxy passes on message to the node where the server is located. Before being able to call these operations, each proxy registers itself to the Messenger with a RegisterQ operation. The same rule applies to the adapter so that it may be traced back by the Messenger when a message is destined thereto. An ExecActionQ and an ExecReactionQ operations may be called only by the receptors. For instance, when a server receptor decodes a new action that is to be executed by the object to which it is associated, it calls the ExecActionQ operation. As for the client receptor, it calls the ExecReactionQ operation to transmit the operation return to the client.

[00129] In the following, the behavior of the transmission and reception classes that make up the core of the CMessenger class will be described.

[00130] The transmitter is the entity responsible to send the messages to the receptor at the other end of the link. First, it manages the state of the transmission of a message in relation to the existing link between two objects through a non-reliable network. It thus ensures to retransmit each message until it is indicated that the message has been received. Second, it ensures that the messages are sent according to the rules of the method of the present invention defined hereinafter. It also makes up the header of the message by adding the proper values following a correct header format as described with more detained hereinafter.

[00131] As mentioned before, in CMessenger class there are two types of transmitters, comprising the CclientTransmitter class used on the client side and the CServerTransmitter class used on the server side. These two transmission classes are different because the messages transmitted, according to the role played, are not the same.

[00132] The CCIientTransmitter class has a simple structure supporting a number of operations as follows (see Figure 8). First, the transmission of a message to the server is initiated by a TxActionQ operation used by the Messenger. This operation takes in parameter a marshaler and immediately returns the first transmission of the message done. The Messenger may then continue to execute other tasks when waiting for the reaction. Then, a RxAckQ operation is called by the receptor as soon as the acknowledgement of receipt is received, thereby causing the transmitter to stop transmitting the message and go to a Waiting state. Finally, a TxAckQ operation is also called by the receptor and when the reaction message is received. If the transmitter does not receive any other message to transmit within a maximal delay (DACK, defined hereinabove in relation to the method of the invention) in milliseconds, it sends the acknowledgement of receipt. From the moment the TxAckQ operation is called, the TxActionQ operation may be called again by the Messenger.

[00133] Figure 8 illustrates the rules described hereinabove that are related to the transmission of a message containing an action. When the client calls an operation of the server, the states of CCIientTransmitter generally go successively from Idle to Transmitting, from Transmitting to Waiting, from Waiting to Acking, and to finally o back to Idle. Depending on the delays, the Idle and Waiting states may be by passed, but for each message, the Transmitting and Acking states are achieved. The transitions are initiated by calling the TxActionQ, RxAckQ, TxAckQ actions or when the delays have expired. The meaning of the retransmission delay DRET and of the acknowledgement of receipt delay DACK will be explained hereinabove in relation to the method.

[00134] As illustrated in Figure 9, like the CclientTransmitter class

30a, the CServerTransmitter class 30b has a simple interface supporting a number of operations. First, a TxAckQ operation is called by the receptor when an action message is received. From the moment the TxAckQ operation is called, a TxReactionQ operation may be called by the Messenger. When the delay of DACK milliseconds has elapsed, an acknowledgement of receipt is sent. Then, once the action executed by the server, the Messenger orders the transmitter to send a reaction message via the TxReactionQ operation, which takes in parameter a marshaler and immediately returns the first transmission of the message done. If the call to the TxReactionQ operation is done within the DACK delay, no acknowledgement of receipt is sent. Finally, a RxAckQ operation is called by the receptor upon receiving the acknowledgement of receipt from the client, notifying the transmitter to stop the retransmission of the message and to go to the Idle state while waiting for another action to execute.

[00135] Figure 9 describes the behavior of the CServerTransmitter class as defined by the method for the transmission of a message that contains a reaction according to the method of the present invention described hereinabove. When the client calls an operation from the server, this generates the execution of an action. To transmit the return of the operation to the client, in a reaction message, the states of CServerTransmitter generally go successively from Idle to Acking, from Acking to Waiting, from Waiting to Transmitting, and finally back to Idle. According to the delays, the Idle and Waiting states may be left out, but for each message the Transmitting and Acking states are achieved. The transitions are initiated by calling the TxReactionQ, RxAckQ, TxAckQ operations or by the expiration of the DRET or DACK delays.

[00136] The receptor is responsible to receive messages coming from the transmitter located at the other end of the link. It manages the state of the reception of a message, in relation to the link existing between two objects through a non-reliable network. It thus ensures to report at a higher level each of the messages, only once, since the duplicated messages are ignored. Moreover, it ensures that the messages received follow the rules of the method as defined hereinabove, by examining the header of the messages and ensuring that the values are correct.

[00137] In the CMessenger class, there are two types of receptors: the CCIientReceptor class used on the client side, and the CServerReceptor class used on the server side. These two reception classes are different because the messages received, in relation to the role played, are not the same.

[00138] Both reception classes have only one operation at their interface. An RxMsgQ operation is called by the transport layer when a message is received and it is destined to the object associated to the receptor. If the message header is valid and is not a duplicate, the receptor passes the action or reaction at a higher level via the Messenger. The receptor has the control stream only when a message is given to it for processing purposes: it is totally passive. It is to be noted that the RxMsgQ operation may be called no matter the state in which the receptor is.

[00139] Figure 10 describes the behavior of the CclientReceptor class. This states diagram illustrates the rules of the method for the reception of a reaction message. When the server returns the result of the operation to the client, the states of CCIientReceptor generally go successively from Idle to Waiting and from Waiting to Idle. Each transition is initiated by the call of the RxMsgQ operation. The Waiting state means that CCIientReceptor is waiting for a reaction. The transition to this state is initiated by the reception of an acknowledgement of receipt. During this transition, the receptor indicates to the CCIientTransmitter, via the call of the RxAckQ operation, that the action message has been received on the server side. When the reaction message is received, the receptor informs the transmitter by calling TxAckQ. It also calls the ExecReactionQ operation of the Messenger so that the latter transmits the return of the operation to the client, via its proxy 24. The CCIientReceptor may also receive, in the Idle state, a reaction message: in this case the receptor also calls the transmitter and Messenger operations before it returns to the idle state. In any cases, incrementing a message sequence number (MSN) takes place when the receptor has properly received the reaction and proceeds to a following one, so that all messages which sequence number (MSN) is less than the last plus one are ignored.

[00140] Figure 11 describes the behavior of the CserverReceptor class. This states diagram illustrates the rules of the method for the reception of an action message. Following the reception of an action from the client, the states of CServerReceptor generally go one after the other to go from Idle to Waiting and from Waiting to Idle. Each transition is initiated by calling the RxMsgQ operation. The Waiting state means that CServerReceptor is waiting for an acknowledgement of receipt following a transmission of the reaction from the server. The transition to this state is always initiated by the reception of an action. The new action is indicated both to CServerTransmitter via the TxAckQ operation and the Messenger via the ExecActionQ operation. If the message received in the Idle state does not match an action, it is not processed. It is also possible, for the receptor, to receive a new action in the waiting state. In this case, as previously, it so informs its collaborators and returns to the waiting state. On the other hand, the acknowledgement of receipt makes it goes to the idle state. In all cases, it is important to note the incrementing of the MSN when the receptor has properly received a new action and it waits for the next. From this moment, all the messages whose sequence number is inferior to the last number plus one are ignored. [00141] Turning now to Figure 12, the proxy 24 ill now be described with more details. From the client point of view, the interface of an object is called by a pointer, which is local to the client process for obvious reasons: when the server is in the same process as the client, the pointer references the native object and calling one of its operations is direct; when the server is outside the client process, the pointer references an object of type proxy 24 and calling an operation of the server becomes indirect. In other words, the client always accesses the local memory space of its own process. For the client to be able to create or establish a link with the server, the address of the latter is passed in parameter to the proxy 24 or the address of the object may be automatically determined by the localization service.

[00142] Therefore, the proxy 24 presents the interface of the server to the client in the space addressable by the latter. To do so, it is located in the same process as the client, and a role thereof is to abstract the localization of the server, by realizing the same interface as the server to which the client wants to access. When the client calls an operation, the proxy 24 serializes the operation and its parameters with the help of a marshaler, in such a way that the operation may be transmitted and reconstructed in the memory space of the process where the server is located.

[00143] The generic entity proxy is implemented in the object proxy

{CobjectProxy abstract class). This object proxy implements access methods to the Messenger 26 necessary to all specialized proxy objects. It is passive and does not make use of execution threads. The Messenger 26 ensures synchronization with the server 20.

[00144] Figure 12 illustrates the relationships existing between the

CObjectProxy 24 and the client 18. In fact, the client 18 does not directly use the CObjectProxy class 24. For the abstraction to be complete, the client 18 only knows the interface of the server 20. It has, via the interface pointer, an association with a specialized class, which inherits from CObjectProxy 24 and the interface specific to the server 20. This relationship is illustrated by an IServer interface and a CserverProxy 24b specialized proxy, which intervenes when the client calls one of the operations of the interface. Once the marshaling of the operation done, the message is transmitted with the methods of the CObjectProxy class 24 that use the services of the Messenger 26.

[00145] Turning now to Figure 13, the adapter 28 will be further described. Due to the great variety of objects that may exist, the Messenger 26 adapts to a corresponding number of various interfaces, by using an adapter principle, whereby the adapter 28 offers the Messenger 26 the access to the operations of the server 20, in such a way that the Messenger 26 is able to communicate with any types of objects via an Object adapter 28. Each class of objects may be associated with an Object Adapter 28, to allow a number of services, including the following: creation and destruction of the server object 20; call of operations; management of security of the interactions; and registration of the object class to the Messenger 26. The adapter 28 is located in the server process, and may be considered as doing the opposite job as the proxy 24.

[00146] An CObjectAdapter class 28 implements basic services of the

Object adapter 24, such as defining a common interface between the Messenger 26 and all its adapters 28. It is thus abstract and purely virtual. CreateQ, CallQ and DestroyQ operations are implemented by dependent classes thereof, and are called by the Messenger 26 in answer to the messages received on the client side. The CObjectAdapter class 28 calls the proper operation of the server by giving it the values extracted from an octet stream. The serialization of the operation's return values, for its transmission to the client, is also its responsibility. RegisterQ and UnregisterQ operations, which are not abstract, are used to manage the registration of the class that is available through the network. A class identifier (CLSID) and a reference to the adapter (specialized class) are given to the Messenger 26. Thus, when a creation message comes in from the network for a class of object X, the Messenger 26 connects to the adapter 28 registered with these numbers.

[00147] As illustrated in Figure 13, the CObjectAdapter class is active, i.e. it has its own execution thread. Even though this class does not adapt between the Messenger 26 and the server 20, the execution stream of the Messenger 26 is independent from that of the adapter 28.

[00148] The main execution thread, that of the Messenger 26, may not block on the call of the operation of any object. Because it manages several links between several different objects, its execution is not dedicated and it remains available to messages coming from the network or to internal messages. For instance, if the Messenger is blocked on the call of an operation too long, it is unable to transmit the acknowledgement of receipt to the client, which then causes the link to be severed.

[00149] According to the behavior of the server, the adapter may be implemented in two ways. First, if the server is simple and none of its operations may risk to be blocked, one thread may be used at the adapter level for all the instances of the server. Alternatively, a thread may be provided for each instance of the server in order to avoid that the call of an operation of an instance interferes with the other instances. It is to be noted that each solution has its advantages and disadvantages, and is to be selected so as to meet the needs of the system. [00150] The adapter offers some form of security. Its implementation ensures that the format of each operation of the server is followed. It calls an operation only when no parameter is erroneous or missing, thereby preventing damage of the system by mistake or to voluntary attack the system.

[00151] Turning to Figure 14, the marshaler will now be described with more details. Since the present system ensures the distribution of the objects on a heterogeneous network, a method of marshaling common to all the implementations is used. Even if the operations may be serialized following a proprietary standard established between the client and the server object, they may be serialized using another standard in order to allow a better homogeneity of the system and to make all the objects interoperable in any type of network configuration. Therefore, in the present invention, the marshaler follows Basic Data Encoding Rules (BDER rules) described hereinabove, for each basic type of C⁺⁺.

[00152] , The marshaler comprises a multiple-classes hierarchy including a CinprocMarshaler 50, a COutprocMarshaler 52 and a CrootMarshaler 54 and an interface 56 {/Marshaler). The marshaler is an object responsible for the serialization and the extraction of an operation in an octet stream. In fact, the term marshaler designates an instance of the CinprocMarshaler 50 or CoutprocMarshaler 52. As for the CrootMarshaler 54, which is abstract, it may not be used directly, since only operations common to two modes of marshaling {inproc and outproc) are implemented, as will be explained hereinbelow.

[00153] The Imarshaler interface 56 is used to abstract a marshaling mode or a true nature of the instance. This way, it is possible to reduce the complexity of the marshaling operators to be implemented in the constructed types, such as the classes and structures.

[00154] As stated above, the marshaler allows the marshaling of an operation according to a first mode called inproc and a second mode called outproc, which are respectively taken on by the CinprocMarshaler 50 and CoutprocMarshaler 52 classes. When the client and server objects are not in the same process, the outproc mode may be used to ensure the inter-process communication. Otherwise, the inproc mode, which is faster, is used. Objects located in the same process are not bound to the BDER rules in order to be able to communicate. For instance, the marshaler in inproc mode does not manage the octet order.

[00155] It is to be noted that a pointer or a reference to an object may not be serialized in outproc mode, since, in this mode, the object itself is serialized because the remote object has no access to the memory space of the client, and vice versa. However, this constraint is not present when the objects share the same process and memory space.

[00156] The insertion and extraction method used by the marshaler is of type first in first out (FIFO). The basic types of C⁺⁺ may all be serialized independently in an octet stream and the marshaler does not manage the order in which they are serialized. However, the order established during the serialization is to be followed during extraction, i.e. the first argument to be inserted is the first to be extracted from the marshaler. Furthermore, the proxy and the adapter are responsible to ensure that the marshaling order of the parameters of an operation stipulated by the BDER rules is respected. The data type is not inserted in the octet stream, except in verification mode, so as to prevent randomly looking for a data (random access) without searching through entire stream or modifying the insertion and extraction addresses of the marshaler. The marshaling and unmarshaling of an operation are determined, complete and sequential, thereby maximizing the performances of the marshaler.

[00157] The CRootMarshaler class 54 uses two first pointers, m plnsertPosition and mjplnsertEnd, for the serialization and two other pointers, m__pExtractPosition and m_pExtractEnd, for the extraction. Upon construction, the two "position" pointers are initialized with the address of the memory segment's beginning, while the two "end" pointers indicate the "end" of the segment, minus the space required to save the address of the following segment. The serialized data is thus inserted at the location to which the m_plnsertPosition points, then the value of the pointer is increased according to the size of the data. However, if the memory segment does not contain enough free space to entirely insert the data {m_jplnsertEnd - m_plnsertPosition < sizeof{data)), part of this data is inserted in the remaining space, while the other part is inserted in the next memory segment automatically allocated. The address of this new segment is saved at the end of the present segment and the insertion pointers are relocated to continue the serialization in this new memory segment.

[00158] Extracting the data from the marshaler is performed following the same principle: each time data is extracted, it is from the location where m_pExtractPosition points and this location is then modified to point to the address of the next data. When the address pointed by m_pExtractEnd is reached, the extraction pointers are relocated according to the starting address of the next segment being located where value of m_pExtractEnd is pointing: the address stored in m pExtractEnd thus corresponds to a beginning of a next segment. [00159] The octet stream is represented in the marshaler by one or more unsigned char tables. In inproc mode, the stream may be fragmented on many memory segments, which is not the case in outproc mode. In order to optimize the serialization in inproc mode, the CinprocMarshaler class 50 uses a simply chained list of fixed length memory segments that it allocates when required. These segments are released when the marshaler is destructed. A number of memory segments may thus be used in inproc mode since the same memory space is shared between the various objects of a same process, and since the list of segments that contain the octet stream may be easily exchanged with a memory address.

[00160] The Figure 15 illustrates the interaction that exists between the various pointers of CRootMarshaler 54 and the memory segments allocated by CinprocMarshaler 50. n m_pFirstSegment pointer, part of CinprocMarshaler 50, marks the first segment of the list. The last octets of the segment are used to save the address of the beginning of a next segment, in such a way that the data of the list does not occupy superfluous memory space and the access is very quick.

[00161] As opposed to CinprocMarshaler 50, the COutprocMarshaler class 52 uses only one memory segment, called blob for Binary Large Object, and is allocated with the Cblob class 58 (see Figure 14). Because the contents of the marshaler in outproc mode are destined to network transport, noncontiguous memory segments may not be used. Furthermore, it is quicker to use a blob 58 (for Binary Large Object) that may be directly exchanged with a sockeif 36. The CrootMarshaler root class 54 performs the serialization and extraction. In this mode, the insertion and extraction pointers simply point to the memory segment that is reserved by the blob 58 when constructing an instance of CoutprocMarshaler 52. [00162] Insertion and extraction operators are available for each basic data type of C⁺⁺. These operators are simple and efficient. They are all implemented at the CrootMarshaler 54 class level. For instance, the following operators take charge of the marshaling of the bool type:

IMarshaler& operator« (IN bool data);

IMarshaler& operator» (OUT bool& data);

StoreQ and LoadQ operators are respectively used to serialize and extract a value of undefined type and variable length as follows: void Store(lN const void* pData, IN WORD wSize); bool Load(OUT void* pData, IN WORD Capacity, OUT WORD& rwSize);

[00163] A pointer in a marshaler of CinprocMarshaler 50 type may also be serialised with generic operators. These operators accept all types of pointers, from the void* type to the reference of a class. This is made possible by the following functions: template <class _Type>

IMarshaler& operator« (IN ClnprocMarshaler& rM, IN const _Type* pPtr);

template <class _Type>

IMarshaler& operator» (IN ClnprocMarshaler& rM, OUT _Type*& pPtr);

When used, only the value of the pointer is serialized, not the value of the object to which it points. These operators may not be used in outproc mode, which explains why the COutprocMarshaler class does not offer these two operations. In outproc mode, a complete serialization of the object may always be made.

[00164] As an example, the marshaling of the following operation: void FooBar(IN bool b, IN int n);

is expressed as follows: CMarshaler* pMarshaler = new CMarshaler; *pMarshaler « b « n;

The unmarshaling is expressed as follows: bool b; int n;

*pMarshaler » b » n;

[00165] It is to be noted that the extraction order of the parameters follows the insertion order. An "assertion", in verification mode, indicates an error if the type of the extracted parameter does not match the type of the parameter inserted at this position.

[00166] Concerning the marshaling of a constructed type, two operations may be used as follows: insertion and extraction operators are created for each class or structure that are to be serialized by a marshaler, and the classes that need not be serialized need not define marshaling operators. The formats of the operators are as follows:

IMarshaler& operator« (IN IMarsha!er& rMarshaler, IN const CGazou& rG);

IMarshaler& operator» (IN IMarshaler& rMarshaler, OUT CGazou& rG);

This allows a homogenous marshaling of the types constructed with the basic types of C⁺⁺. For instance, for the following CGazou class: class CGazou

{ friend IMarshaler& operator« (IN IMarshalerS rM, IN const CGazou& rG); friend IMarshaler& operator» (IN IMarshaler& rM, OUT CGazou& rG); public:

CGazou(); virtual ~CGazou(); private: int m_nlnt; long m_nlong;

};

the marshaling is ensured by the following functions:

IMarshaler& operator« (IN IMarshaler& rM, IN const CGazou& rG)

{ rM « rG.m_nInt « rG.m_nLong; return rM; }

IMarshaler& operator» (IN IMarshaIer& rM, OUT CGazou& rG)

{ rM » rG.m_nlnt » rG.m_nLong; return rM; }

Thus, the marshaling of the CGazou class may be easily made as follows: CGazou gazou;

CMarshaler* pMarshaler = new CMarshaler; *pMarshaler « gazou;

[00167] The same method may be applied to the structures that are to be serialized. It is to be noted that the operators are defined as friend at the class level in order to be able share the member data, which are private. Furthermore, the operators of the marshaling of the basic types are always be used by the operators of marshaling of a structure or a class.

[00168] In accordance with the BDER, the first octet of the stream

(index 0) contains a Boolean that indicates the encoding order of the octets that have been serialized. This flag is not part of the serialized data, but it is part of the octet stream that contains this data. Based on the value of the flag, the data to be encapsulated are serialized by the marshaler according to the encoding rules defined by BDER. The same rules apply when the data are extracted from the marshaler. However, this flag is left out in inproc mode since in this mode, there is no ordering of octets, because the server object is located in the same process as the client and then uses the same order as the client.

[00169] In outproc mode, the octet order is adjusted when the order does not match the local standard in use, in such a way that when the order flag indicates a different standard has been used upon serialization, the octet order is inverted on extraction. This operation, which is valid for signed and unsigned types, is ensured by the following methods:

unsigned short ReverseOctetOrder (IN unsigned short w) unsigned long ReverseOctetOrder (IN unsigned long dw) ;

[00170] Upon serialization, the octet order is not modified. The order follows the standard in use at the operating system and CPU level, which results in that serialization operators are the same no matter the marshaling mode. Only the extraction operators of the basic types sensible to the octet order are overloaded by the COutprocMarshaler class.

[00171] From the foregoing, people in the art will now appreciate that the system of the present invention comprises classes such as CMessenger, which offer a software infrastructure with real solutions to the problems of distributed objects for embedded systems.

[00172] Moreover, the system of the present invention supports both synchronous and asynchronous operation calls on local or remote objects. The return of an asynchronous operation is, by definition, instantaneous, while the execution a synchronous operation is undefined. [00173] The above described distributed system allows transparent interconnection between the client and the server, and is particularly client friendly, since requests from the client object to the server object located on the remote node are performed in a traditional way. In other words, there is no difference for the client regarding the use of the server interface, either local or remote.

[00174] People in the art will now appreciate that the method of the present invention allows a number of acts for objects distribution, providing a reliable mechanism for connecting remote objects over unreliable and heteregeneous networks.

r00175] Moreover, the method is effective, light and easily configured since the protocol used for transport is UDP (User Datagram Protocol), which, contrary to TCP (Transmission Control Protocol), is not connection-oriented and does not guarantee packets delivery. The method indeed takes into account that the UDP method, by nature, contains some error risks in the exchange of data packets between the objects, by a special attention in the elaboration of the inter-object communication. For instance, the packets are reorganized in sequence at their reception. Overall, without recreating the TCP connection mechanism, which is complex and heavy, the method of the present invention succeeds in ensuring a minimum of reliability at the level of exchange between objects.

[00176] The method requires minimal engineering efforts, a few CPU resources and a few memory resources and may thus be advantageously used on any type of embedded system working in a distributed environment. An efficient and low cost implementation is permitted, no matter a targeted system type.

[00177] Additionally, the method of the present invention provides a connection management that is light, rugged and entirely parameterable, thereby ensuring a good quality of services. Furthermore, the method of the present invention autonomously supports point to point connections, so that a third party entity is not required for the connection between two objects to take place. The method may also be distributed entirely without requiring a centralized support.

[00178] Moreover, the method and system of the present invention provides that the nodes of a network may contain a number of objects of a same class, or of different classes. For instance, in a given host node where a number of objects of the same class may be created by a client, each of them being able to be addressed independently. A reliable mechanism ensures the transmission of the information and the requests of service, being enabling demultiplexing the information and redistributing it to the corresponding server objects. The location of the objects is flexible enough to support several thousands of objects, located on different nodes within a world-size network.

[00179] The method and system of the present invention support invoking static interfaces, as a natural way to activate an operation, since, typically, a link between a programming language and an interface is automatically established by a compiler, with a strong type checking taking place during compiling time. Furthermore, the statically defined interfaces are easy to use and require little code. On the other hand, the discovery and invoking of dynamic interfaces do not have to be supported, because this type of invoking is not natural and it requires that only one interface be used for all the existing and future interfaces. A dynamic invoking technique thus requires a lot more code to be able to discover the operations and parameters of the various interfaces and this is not wished for in an embedded application.

[00180] Using the proxy or the actual object is transparent to the client, i.e. the proxy or the actual object that serves the client are used the same way, without any change being required at the client level. For instance, creating a local or distant server object is done with a standard operator. Implementing client objects thus stays simple. The server objects are implemented independently from an eventual use in a distributed environment, so that a server object is by a local or remote client.

[00181] As described hereinabove, the present invention supports the

C⁺⁺ language. It is believed that an extended specification mechanism, such as one based on IDL (interface description language) may be used to fill eventual interface definition problems caused by the C⁺⁺ language limitations.

[00182] The present distributed object-oriented messaging system and method allows two objects existing on different nodes of a network to communicate between them, with a great versatility and very few constraints at the distributed objects system design level. They offer simple and efficient interoperability communication guidelines used to create virtual matching (links) between several objects distributed on the nodes of a heterogeneous network.

[00183] The system and method of the present invention support networks of various sizes, and adapt to the size of today's and tomorrow's Internet while keeping up with its efficiency.

[00184] The system and method of the present invention do not make any assumptions regarding the network architecture, the system and the underlying objects. It suffices that at least one entity by process is able to send and receive distributed object-oriented messaging-type messages. All the nodes are processed as opaque entities with unknown architectures.

[00185] People in the art will now be in a position to appreciate that the method and system of the present invention provide distributed oriented solutions adapted to the requirements of small embedded systems, in particular by solving an implementation size issue through supporting a set of features required by small embedded systems, a call speed issue through using a fast message exchange mechanism, and a portability issue through using a standard object-oriented language.

[00186] Although the present invention has been described hereinabove by way of embodiments thereof, it can be modified, without departing from the spirit and nature of the subject invention as defined in the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A distributed object-oriented messaging method in a system having at least two objects communicating through process boundaries over a network of host nodes, comprising the acts of: establishing an action-reaction link between a first object and a second object; preparation of data of an operation message to be exchanged between the first object and the second object; transporting the data; and transmitting of the data. whereby said act of establishing an action-reaction link establishes one of the first object and second object as proactive and another one thereof as reactive so that an action is transmitted from the proactive object to the reactive object within an action message and a reaction is transmitted from the reactive object to the proactive object within a reaction message.

2. The distributed object-oriented messaging method according to claim 1 , wherein said act of preparation of data comprises a serialization of the data within octet streams to be transmitted on the network.

3. The distributed object-oriented messaging method according to claim 2, wherein said serialization into octet streams comprises encapsulating an octet order standard within the octet streams, aligning octets basic types according to natural boundaries thereof within the octet streams and including within each octet stream a flag that indicates which standard is used.

4. The distributed object-oriented messaging method according to any one of claims 2 to 3, wherein the octet streams comprise octet streams containing message headers and octet streams containing data.

5. The distributed object-oriented messaging method according to any one of claims 2 to 4, wherein said act of transmitting the data is performed using UDP, and a single UDP port is used per process on each of the nodes of the network, both for transmitting and receiving messages.

6. The distributed object-oriented messaging method according to any one of claims 2 to 4, wherein said act of transporting the data is performed using a mechanism allowing duplication and loss of packets whereby a transport of octets located inside a packet maintains an order of the octets of the packet; a transmitter and a receptor are identifiable; and a notification is transmitted when the receptor is unable to receive the message.

7. The distributed object-oriented messaging method according to any one of claims 2 to 4, wherein said act of transmitting comprises providing an acknowledgement of receipt of a message, and, for each reaction from the reactive object associated to an action of the proactive object, an acknowledgement of receipt terminating exchange of action and reaction between the two objects.

8. The distributed object-oriented messaging method according to any one of claims 1 to 7, further comprising linking the proactive object to the reactive object of the network.

9. The distributed object-oriented messaging method according to claim 8, wherein said linking comprises:

sending from the proactive object to the reactive object a linking message transporting a linking action including identifiers of the reactive object; validating the identifiers of the reactive object in the node thereof; and sending a linked message from the reactive object to the reactive object transporting a linking reaction and an identifier of the link created.

10. The distributed object-oriented messaging method according to claim 9, further comprising breaking the link by sending from the proactive object to the reactive object an unlinking message transporting an unlinking action and causing invalidation of the identifier of the link, and sending an unlinking reaction transported by an unlinked message from the reactive object.

11. The distributed object-oriented messaging method according to any one of claims 1 to 10, further comprising creating the reactive object on a target node by the proactive object, the target node and a node of the proactive object being connected by a root link, in reference to an operation and to parameters associated therewith.

12. The distributed object-oriented messaging method according to claim 11 , wherein said creating comprises: sending a create message transporting a create action including an identifier of the reactive object, and a create operation; and sending a created message transporting a created reaction, identifiers of the created object.

13. The distributed object-oriented messaging method according to anyone of claims 11 and 12, wherein said creating is executed synchronously.

14. The distributed object-oriented messaging method according to any one of claims 1 to 13, further comprising destroying the reactive object including components and links thereof in reference thereto.

15. The distributed object-oriented messaging method according to claim 14, wherein said destroying comprises: sending a destroy message carrying a destroy action; and sending a destroyed message carrying a destroyed reaction.

16. The distributed object-oriented messaging method according to any one of claims 1 to 15, further comprising calling a synchronous operation of the reactive object.

17. The distributed object-oriented messaging method according to claim 16, wherein said calling a synchronous operation comprises: sending a call message carrying a call action and describing the synchronous operation; executing the operation called; and sending a return message carrying a return reaction.

18. The distributed object-oriented messaging method according to any one of claims 1 to 17, further comprising calling an asynchronous operation of the reactive object.

19. The distributed object-oriented messaging method according to claim 18, wherein said calling an asynchronous operation comprises: sending a send message carrying a send action and describing the asynchronous operation; and sending a received message carrying a received reaction.

20. The distributed object-oriented messaging method according to any one of claims 1 to 19, further comprising locking access to the reactive object.

21. The distributed object-oriented messaging method according to claim 10, wherein said locking comprises: sending a lock message carrying a lock action; and sending a locked message carrying a Locked reaction.

22. The distributed object-oriented messaging method according to any one of claims 21 and 22, further comprising unlocking the reactive object by the proactive object responsible for a last locking thereof.

23. The distributed object-oriented messaging method according to any one of claims 1 to 22, further comprising locating the reactive object.

24. The distributed object-oriented messaging method according to claim 23, wherein said locating comprises: broadcasting a Locate message carrying a Locate action and identifying the reactive object; and sending at least one Located message in unicast, returning information generated by the Locate action in a Located reaction.

25. The distributed object-oriented messaging method according to claim 23, wherein said locating comprises sending at least one Located message in unicast, returning migration information generated by the Locate action in a Located reaction.

26. The distributed object-oriented messaging method according to any one of claims 1 to 25, further comprising sending an acknowledgment of receipt of the action before the end of an execution thereof after a predetermined maximum period of time, to avoid retransmission of an original message.

27. The distributed object-oriented messaging method according to claim 18, wherein said sending an acknowledgment of receipt before the end of an execution of the action comprises sending an acknowledgment message identified by identifiers of the original message and for which an acknowledgement of receipt is transmitted.

28. The distributed object-oriented messaging method according to any one of claims 1 to 27, further comprising reporting exceptions and identifying them with a name, a code, a severity level and a definition.

29. The distributed object-oriented messaging method according to claim 28, wherein said reporting exceptions comprises sending a negative acknowledgement message including an error level and a code.

30. The distributed object-oriented messaging method according to any one of claims 28 and 29, wherein the exceptions are selected in the group comprising protocol errors, communication errors, and preparation of data errors.

31. The distributed object-oriented messaging method according to any one of claims 1 to 30, wherein said transmitting the data comprises: sending the data in a numbered message; sending an acknowledgement of receipt of the message; and confirming receipt of the acknowledgement of receipt of the message;

32. The distributed object-oriented messaging method according to any one of claim 1 to 31 , wherein said transmitting the data comprises using one interface for each process to transmit and receive messages between the proactive object and the reactive object.

33. The distributed object-oriented messaging method according to claim 32, wherein the interface is able to initiate execution streams based on internal and external events, thereby allowing a concurrent execution of calls from different objects, non synchronized, and that exist on distinct nodes of the network.

34. The distributed object-oriented messaging method according to any one of claims 32 and 33, wherein said transmitting the data comprises: initiating a transmission by an Action operation of a first transmitter comprised in a side of the proactive object of an existing link between the proactive object and the reactive object; responding to the transmission of the Action by a Reaction of a second transmitter comprised in a side of the reactive object of the existing link; receiving acknowledgement of receipt by a first receptor comprised in the side of the proactive object of the existing link; and receiving acknowledgement of receipt by a second receptor comprised in the side of the reactive object of the existing link.

35. The distributed object-oriented messaging method according to claim 34, wherein the first transmitter of the messenger uses a TxActionQ operation to initiate transmission of a message by taking in parameter a marshaler and immediately returning a first transmission of the message done; the first receptor of the messenger uses a RxAckQ operation as soon as an acknowledgement of receipt is received that stops the second transmitter from transmitting the message and calls a TxAckQ operation when a reaction message is received from the end of the reactive object.

36. The distributed object-oriented messaging method according to claim 34, wherein the second receptor calls a TxAckQ operation when an action message is received, sends an acknowledgement of receipt, and once the action is executed on the reactive object, the second transmitter sends a reaction message via the TxReactionQ operation takings in parameter a marshaler and immediately returning a first transmission of the reaction message done; a RxAckQ operation being further called by the second receptor upon receiving the acknowledgement of receipt from end of the proactive object.

37. A system using the method according to anyone of claims 1 to 36.