Communications on a network

[0002] This is a File Wrapper Continuation of application Ser. No. 08/432,372, filed May 1, 1995, which is a Continuation application of Ser. No. 08/065,926, filed May 21, 1993, now abandoned.

[0003] 1. Field of the Invention

[0004] This invention relates to techniques for dealing with calls between objects or entities in computer software and systems.

[0005] 2. Description of the Prior Art

[0006] Object oriented computer software and systems utilize entities, called objects, for providing enhanced abilities to design, develop, implement and operate software and other computer related systems. One conventional object related system is known as the object linking and embedding, or OLE, system. Object related systems use various strategies for exchanging data with and between objects. One conventional approach to handling the interchange of data with objects is known as the System Object Model, or SOM, used in the OS/2 operating system.

[0007] Another conventional approach for the interchange of data with objects is known as the dynamic data exchange, or DDE, system format used in Windows in the DOS operating system. The DDE system was originally developed for use with non-object oriented systems and modified by means of the SOM for use with object oriented systems through message passing utilizing a system table.

[0008] In conventional object oriented systems, the interchange of data with objects is accomplished with a two phase data exchange procedure. In such conventional two phase data exchange procedures, the first phase or stage includes the communication request from the calling or client object which must be acknowledged by the called or server object. Successful completion of the first stage results in the receipt by the client object of the acknowledgement of the communication request by the server object. Thereafter, the second stage of the server becomes available.

[0009] Remote procedure call, or RPC, techniques are known and used for many operations between platforms but often have overhead requirements within a platform which degrade system efficiency and can result, under certain conditions, in loss of accuracy. What are needed are techniques for data interchange with both local and remote objects which do not result in the reduction of data transfer accuracy nor the increased processing overhead in conventional data interchange systems.

[0010] In accordance with the present invention, inter-object communications are handled through an internal remote procedure call which provides an enhanced mode for local platform object oriented environments. In particular, inter-object communications between a client and a server object on the same platform are handled via an internal queuing arrangement using local platform memory, eliminating the need for the client object to wait for an acknowledgement by the server object. That is, the remote procedure call operates in a two phase data exchange mode that is transparently superseded when the server object is determined to be on the same platform as the client object. The message calls are placed in a local queue with an object identifier or handle when the client object first requests acknowledgement from the server object of a message call from the client to the server. No further action by, or delay of, the client object is then required. No overhead is wasted by repetitive requests for the same data exchange if the server object is not currently available. No unwanted multiple data exchanges result and therefore data exchange is maintained at 100% accuracy. The present invention thereby avoids the reduction in system performance inherent with known data interchange techniques which may result, for example, from multiple requests for data transfer acknowledgements.

[0011] In another aspect, the present invention provides a method of communicating between client and server entities on computer platforms interconnected by a transport network by determining if a server is located on the same local platform as a client wishing to communicate a message to the server, transferring the message to the server via the transport network if the client and server are not located on the same local platform, storing the message in a local memory queue on the local platform if the client and server are located on the local platform, causing the server to interrogate the local queue when the server is available, and then transferring the message to the server from the local memory queue.

[0012] These and other features and advantages of this invention will become further apparent from the detailed description that follows which is accompanied by drawing figures. In the figures and description, reference numerals indicate various features of the invention, like numerals referring to like features throughout both the drawing figures and the description.

[0013] FIG. 1 is a simplified flow diagram of the inter-object data path in an internal RPC implementation in accordance with the present invention.

[0014] FIG. 2 is a simplified flow diagram of the inter-object data flow path in an external RPC implementation of the present invention.

[0015] FIG. 3 is a simplified flow chart of an OPM implementation according to the present invention.

[0016] In accordance with the present invention, inter system object communications are achieved through an internal remote procedure call, or internal RPC, which also provides for a local platform object oriented environment. The internal RPC manages data issues including operational semantics and communications, and provides a convenient and consistent mechanism for specifying the interaction between objects within a local platform.

[0017] In accordance with the present invention, the internal RPC is part of an internal/external RPC system referred to herein as an Object Procedure Messaging, or OPM, facility which may be used to transfer data to objects whether included on the same platform or on other platforms interlinked by means of heterogeneous as well as non-heterogeneous network paths.

[0018] The OPM of the present invention provides operational semantics, and ensures that a data transfer request or other message to an object is executed only once if the client and server objects are on the same local platform. A message that is sent to or waiting on a busy server object is queued in the OPM facility. There is no need to resend a message to a busy object in a local platform. This reduces or eliminates the possibility of data inaccuracy resulting from the reprocessing of the same message by the inadvertent processing of both the original as well as the resent message.

[0019] In other words, the present invention does not require a message to be sent to a server object more than once, even if that server object is busy when the message is sent by the client object. The first version of the message is therefore the only one that can be processed, substantially enhancing data integrity.

[0020] The OPM facility provides a set of object services that are made available to all objects. These services include common naming and/or directory facilities so that, for example, messages for a busy object may be held in a queue and conveniently identified or retrieved by the destination object.

[0021] The OPM facility is compliant with the Object Management Architecture, or OMA, of the Object Management Group. The name service creates an object name space that accesses names and data from existing directory services.

[0022] RPC facilities according to the present invention utilize client and server object stubs to shield the client and server objects from the details of communication between the objects. The client or calling object which originates the message call, and the server or called object which is to receive the call, are programmed as if they were intended to be linked together. A description of the server interface, that is, the names of the procedures and the types of arguments the server implements, is processed, yielding a client stub and a server stub.

[0023] The client stub is linked with the client. To the client, the client stub looks like the server. The server stub is linked with the server. To the server, the server stub looks like the client. The client stub allows the client to operate as if it has received acknowledgement of the message call from an available server, whether or not the server is then actually available. The server stub operates to permit the server to retrieve the message call when the server does in fact become available.

[0024] Building applications using the internal and external RPC, or OPM, facility of the present invention includes three phases: the compile time, bind time, and call time interceptor phases. The compile time phase involves the development of the client and server stubs. These stubs are complied by a stub generator that processes an explicit definition of the interface, written in an interface description language (NIDL). The bind time phase involves the object making its availability known by registering itself and, when appropriate, associating itself with a particular language.

[0025] The call time phase involves the local transport protocol, control protocol, and data representation. The transport protocol is used by the stubs to convey arguments and results reliably between objects. The control protocol consists of information included by the OPM facility in each transport packet to track the state of the message. The data representation is a convention for ensuring data compatibility between objects.

[0026] The OPM facility is therefore an extension of a conventional, external only RPC facility, expressed through a procedural abstraction of the call time components (transport, control, and data representation). OPM is an effective way to provide basic communication with a diverse set of objects by emulating the native conventional RPC facilities of these systems for data exchange between objects on the same platform. One of the major aspects of the OPM is the defining of the interfaces between objects that make this emulation of the native RPC facilities, and the use of local protocols, conveniently achievable.

[0027] Referring now to FIG. 1, a simplified flow diagram of internal or local platform inter-object data path 10 according to one embodiment of the present invention, is presented for several objects as an illustrative example in which client objects 12 and 14 need to transfer a message with server object server 16. Client objects 12 and 14 and object 16 are all on the same local platform, shown as local platform 15. Using client object 12 as an example, each object is provided with an appropriate connection to a portion of the RPC interface layer, such as RPC interface 18 of client object 12. Each such object is also provided with a communication path to directory services 20 as well as message queue 22 which may conveniently be maintained within local platform memory 24 on local platform 15.

[0028] Server available data path 26 between client object 14 and server object 16 on local platform 15 will be described first as an illustration of the message and data flow path between objects on the same platform when the server object is available to accept and acknowledge the client object message call when made by the client object.

[0029] Referring also to FIG. 3, in which a simplified flow chart of an OPM implementation according to the present invention is presented, the first step of server available data path 26 is step 28 in which client object 14 requests service from another object, such as server object 16, using an object related messaging facility. Conventional messaging facilities for individual objects may be used to request service from other objects. The details of the particular messaging facility used are dependent upon the local platform and language and may be conveniently determined by a person of ordinary skill in this art by reference to the appropriate available descriptions thereof.

[0030] As a result of step 28, client object 14 requests information concerning the location of server object 16 from directory services 20 as indicated by step 30. In a local platform configuration, directory services 20 may conveniently be locally maintained. In a multi-platform environment, directory services 20 may conveniently be centrally maintained and/or replicated on each local platform. The development and use of directory services 20 are well known from conventional RPC systems and need not be described herein in any further detail.

[0031] Steps 28 and 30 are common to all internal, that is, intra-platform, client-server data paths such as server available data path 26, as well as external or inter-platform data paths as will be discussed below with respect to FIG. 2. When the result of the interrogation of directory services 20 by the messaging facility of the client object determines that the server object is locally resident, as represented by step 32, the intra-platform message and data paths as depicted in FIG. 1 diverge from the inter-platform data paths depicted in FIG. 2. It is important to note, however, that the next step in both intra- and inter-platform data paths uses the RPC facility. In the case of an intra-platform path, such as server available data path 26 depicted in FIG. 1, the RPC facility is used to send the message call to message queue 22 rather than to the server object located on a separate platform.

[0032] In particular, as indicated by step 34, when interrogation of directory services 20 by the messaging facility of client object 14 indicates that the called object, server object 16, is co-resident on local platform 15, the RPC facility is used to send the message and the local transport layer on local platform 15 places the message on message queue 22. The message call placed on message queue 22 includes an object handle representing server object 16.

[0033] Server available data path 26 being currently described operates when the server object is available. When a server object is available within a conventional external RPC which operates in a manner similar to that of the inter-platform portion of the OPM facility of the present invention as shown in FIG. 2, the server object listens for message calls to it using a conventional asynchronous RPC signal.

[0034] In a similar manner as indicated in step 36, server object 16 listens to message queue 22, whenever server object 16 is not unavailable, using a conventional asynchronous RPC signal to determine by means of object handles related thereto in message queue 22 when a message call has been placed in message queue 22 for server object 16. As further indicated by step 36, when server object 16 determines that a message call to server object 16 has been placed in message queue 22, server object 16 causes that message call to be transferred to server object 16. As indicated by step 38, the communications between server object 16 and client object 14 occur through message queue 22. In particular, the acknowledgement of receipt of the message call is sent by server object 16 to client object 14 through message queue 22. If appropriate, data may then be transferred through the queue between the client and server objects.

[0035] In this manner it can be seen that when server object 16 is available, intra-platform messaging proceeds between client and server objects, when the server is available, without substantial delay. It is a substantial advantage of the present invention that the intra-platform message transfer may proceed without delay of the operations of the client object, or retransmission of the message, even when the server object happens to be busy when called by the client object.

[0036] Server un-available data path 26 between client object 14 and server object 16 on local platform 15 will be described next as an illustration of the message and data flow path between objects on the same platform when the server object is not available to accept and acknowledge the client object message call when made by the client object.

[0037] As noted above, steps 28 and 30 of the flow of data between are common to all internal, that is, intra-platform client-server data paths, such as server available data path 26 and the external or inter-platform data paths discussed below with respect to FIG. 2. When the result of the interrogation of directory services 20 by the messaging facility of the client object determines that the server object is locally resident, as represented by step 32, the intra-platform paths are substantially similar for both server available and server unavailable paths except for the relative timing and sequencing of message acknowledgement and data transfer.

[0038] In particular, in the case of a server unavailable intra-platform path, such as server unavailable data path 40 depicted in FIG. 1, the RPC facility is used to send the message call to message queue 22 rather than to the server object located on a separate platform.

[0039] In particular, as indicated by step 34, when interrogation of directory services 20 by the messaging facility of client object 14 indicates that the called object, server object 16, is co-resident on local platform 15, the RPC facility is used to send the message and the local transport layer on local platform 15 places the message on message queue 22. The message call placed on message queue 22 includes an object handle representing server object 16.

[0040] Server unavailable data path 40 is simply the same path as server available data path 26 except that it operates when the server object is not available. Client call path 42 is the client object to message queue portion of server unavailable data path 40. In particular, step 34 operates to place a message call from client object 12 onto message queue 22 via client call path 42. As noted above with respect to step 36, a server object listens for message calls to it using a conventional asynchronous RPC signal. However, if server object 16 is not available when called by client object 12 via client call path 42 because—for example—server object 16 is serving client object 14 via server available data path 26, server object 16 is not then listening for message calls.

[0041] It is important to note that, even though server object 16 is busy when called, the use of an internal RPC type facility for intra-platform messaging between objects provides the substantial advantage that the client object does not have to wait until the server object is not busy and additional or follow-on messages are not sent.

[0042] In particular, as indicated in step 36, server object 16 listens to message queue 22 when server object 16 becomes available. Server object 16 uses a conventional asynchronous RPC signal via server acknowledgement and listening path 44 to determine by means of object handles related thereto in message queue 22 when a message call has been placed in message queue 22 for server object 16. As further indicated by step 36, when server object 16 determines that a message call to server object 16 has been placed in message queue 22, server object 16 causes that message call to be transferred to server object 16. As indicated by step 38, the communications between server object 16 and client object 14 occur through message queue 22. In particular, the acknowledgement of receipt of the message call is sent by server object 16 to client object 14 through message queue 22. If appropriate, data may then be transferred through the queue between the client and server objects.

[0043] In this manner it can be seen that when server object 16 is not available, intra-platform messaging proceeds between client and server objects by means of message queue 22 when the server later becomes available. It should be noted that except for the delay between the placement on message queue 22 of a message call from client object 12 by the local transport layer as indicated by client call path 42 and the listening and acknowledgement by server object 16 over server acknowledgement and listening path 44, server unavailable data path 40 and server available data path 26 operate in the substantially similar manners.

[0044] Referring now more specifically to FIG. 2, the operation of the external RPC facility, for example, for multi- and/or inter-platform messaging and data transfer operates in the same general manner. In particular, when the messaging facility of client object 12 determines by interrogation of directory services 20 that the requested server object, such as server object 46, is not on local platform 15 but some other computer or platform, the external RPC portion of the Object Procedure Messaging, or OPM facility, operates in a conventional manner as a standard RPC facility. That is, client object 12 passes a message call to NCK 48 of protocol independent sockets 50 by means of client RPC path 52 which is acknowledged by server object 46, when available, by means of object RPC path 54.

[0045] In this way it can be seen that the shielding of client and server objects from the details of inter-object communications conventionally use for objects not on the same platform may be extended for used for intra-platform messaging with substantial benefit and advantage. Although a generalized embodiment using intra-platform or internal messaging in combination with an inter-platform messaging operating in a conventional manner has been shown, it is well within the skill of a person of ordinary skill in this art to utilize the present invention in various specific applications in other particular and specialized manners. The specific embodiments described herein are intended to provide a convenient example illustrating the development, use and operation of the OPM of the present invention and may not be used to limit the scope of the invention which is defined by the claims hereafter appended.