CA2098417C - Method and system for project management across process boundaries in a data processing system - Google Patents
Method and system for project management across process boundaries in a data processing systemInfo
- Publication number
- CA2098417C CA2098417C CA002098417A CA2098417A CA2098417C CA 2098417 C CA2098417 C CA 2098417C CA 002098417 A CA002098417 A CA 002098417A CA 2098417 A CA2098417 A CA 2098417A CA 2098417 C CA2098417 C CA 2098417C
- Authority
- CA
- Canada
- Prior art keywords
- processes
- class
- communications
- message
- communications manager
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Abstract
The present invention provides a method and system in a data processing system, having a multitasking operating system which includes a plurality of processes, for providing communication between objects executing within the processes in the multitasking operating system, the method and system includes registering an object within a communications manager in response to a launching of the object. The communications manager monitors all objects registered with the communications manager within the plurality of processes. A determination of whether a first object is registered is made utilizing the communications manager, in response to receiving a request from a second object to send a message to the first object. Automatic initiation of the launching the first object within the processes is performed if the first object is unregistered utilizing the communications manager. Next, the first process containing the first object is bound to the second process containing the second object, wherein a communications path is established between the first process and the second of the process. The message is sent to the first object from the second object via the established communications path between the two processes, wherein communication between the first object and the second object is automatically established.
Description
AT9-92-112 20~8417 M~T~n AND SYSTEM FOR OBJECT MANA~M~T ACROSS
S BOUNDARIES IN A DATA ~ 9ING SYSTEM
R~,Y~ROUND OF THE ~ ION
~ C' ical Field:
The present invention relates in general to a method and system for managing communications in a data processing system and in particular to a method and system for managing c~ ications between objects executing in a data processing system. Still more particularly, the present invention relates to a method and system for managing c~. lnications between objects executing in different processes in a data processing system.
S BOUNDARIES IN A DATA ~ 9ING SYSTEM
R~,Y~ROUND OF THE ~ ION
~ C' ical Field:
The present invention relates in general to a method and system for managing communications in a data processing system and in particular to a method and system for managing c~ ications between objects executing in a data processing system. Still more particularly, the present invention relates to a method and system for managing c~. lnications between objects executing in different processes in a data processing system.
2. Description of the Related Art:
In multi-tasking operating systems, hardware may be managed as a shared resource to be distributed among concurrently executing applications or programs. In a multi-tasking operating system, resources such as the processor, memory, files, devices and inter-process cc. ~ni cations structures are also shared in the operating system among concurrently executing applications, programs, or objects. "Timeslicing"
i8 utilized to share the processor with various concurrently executing applications or objects. Generally, an operating system will switch between applications allowing each application to run for a short period of time, a "timeslice". Thus, in this manner, the processor may be shared between various applications or objects, enabling multitasking.
For example, OS/2~ is an operating system that offers a multitasking architecture, providing the capability to execute multiple programs in a protected environment. OS/2 include~ a hierarchy of multi-tasking options called es~ion~, processes, and threads. A "session" i8 a unit of u~er input/output ('II/O") device sharing. A "process" is a unit for ~haring for various re~ources, such as memory, .
files, semaphores, queues, and threads. A process may contain multiple programs or objects. More information on OS/2 in a text entitled The Design of OS/2 by Deitel and Kogan, published by Addison-Wesley Publishing Co. 1992.
Objects are D~E objects as defined in OSF DCE User's Guide And Reference from Open Software located at ll Cambridge Center, Cambridge, Massachusetts 02143. In an environment containing different and potentially independent application objects (all of which are built upon a base class hierarchy), which are being developed, a need exists to decouple the run-time environments in which the objects execute. The need for decoupling arises out of a concern for integrity between the objects. Generally, if two objects are executing within the same process, the failure of one object will jeopardize the other object. In other words, if one object fails within a process, normally all of the other objects within the same process will also fail or become unstable. An erroneous implementation of one object also may corrupt the other ob;ects.
Objects executing within the same process are able to easily exchange data. Often times, it is desirable to interchange data or send messages to an object within a different process. Data exchange becomes more difficult between objects executing in different processes.
Presently, data sharing and message sending between two objects, located in different processes, are handled by writing a protocol specific to the two objects. As a result, djata sharing and message sending may only occur between those two objects. In order to add a third object, additional code must be produced to allow for data sharing and message sending between all three objects.
Therefore, it would be desirable to have a method and system to manage the di~tribution and communication of data and mes~ages across processes without having to produce new protocols for each additional process.
SUMMARY OF THE lN~ l0N
It is therefore one object of the present invention to provide a method and system for managing communications in a data processing system.
It i8 another object of the present invention to provide a method and system for managing co lnications between objects executing within a data processing system.
It is yet another object of the present invention to provide a method and system for managing communications between objects executing in different processes within a data piocessing system.
The foregoing objects are achieved as is now described. The present invention provides a method and system in a data processing system, having a multitasking operating system that includes a plurality of processes, for providing communication between objects executing within the processes in the multitasking operating system. The method and system includes registering an object with a communications manager in response to a launching of the object. The communications manager monitors all objects registered to it within the plurality of processes. A determination of whether a first object is registered is made utilizing the communications manager, in response to receiving a request from a second object to send a message to the first object. Automatic initiation of the launching the first object within the j processes is performed utilizing the communications manager if the first object is unregistered. Next, the process containing the first object is bound to the process containing the second object, wherein a communications path is established between the two processes. The message is sent to the first object from the second object via the c,_. ications path between the two processes, wherein cc. lnication between the first object and the second object is automatically established.
The above as well as additional objects, features, and advantages of the pre~ent invention will become apparent in the following detailed written description.
BRIEF D~PTPTION OF THE DRAWINGS
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein: -Figure 1 depicts a pictorial representation of a data processing system which may be utilized to implement a method of the present invention;
Figure 2 is a diagram illustrating the establishment of a communications link between an object dispatch process (ODP) and a process in accordance with a preferred embodiment of the present invention;
Figure 3 depicts a data flow diagram illustrating the e~tablishment of a communications link between two processes in a situation where one object has not been instantiated in accordance with a preferred embodiment of the present invention.
Fijgure 4A is a portion of logical flowchart for creating a communications path in accordance with a preferred embodiment of the present invention;
Figure 4B is a portion of logical flowchart for creating a communications path in accordance with a preferred embodiment of the present invention; and Figure 5 depicts a logical ~10wchart of the process followed by a message dispatcher (MD) in accordance with a preferred embodiment of the present invention.
DETAILED n~C~TPTION OF ~k~-~K~ EMBODIMENT
With reference now to the figures, and in particular with reference to Figure 1, there is depicted a pictorial representation of a data processing sy~tem 8 that may be utilized to implement a method and system of the present invention. As may be seen, data processing system 8 may include a plurality of networks, such as local area networks (LAN) 10 and 32, each of which preferably includes a plurality of individual computers 12 and 30, respectively.
Of course, those skilled in the art will appreciate that a plurality of intelligent work stations (IWS) coupled to a host processor may be utilized for each such network.
I
As is common in such data processing systems, each individual computer may be coupled to a storage device 14 and/or a printer/output device 16. One or more such storage devices 14 may be utilized, in accordance with the method of the present invention, to store documents or resource objects which may be periodically accessed by any user within data processing system 8. In a manner well known in the prior art, each such document or resource object stored within a storage device 14 may be freely interchanged throughout data processing system 8 by transferring a document to a user at an individual computer 12 or 32, for example.
i Still referring to Figure 1, it may be seen that data processing system 8 may also include multiple mainframe computers, such as mainframe computer 18, which may be preferably coupled to LAN 10 by means of communications link 22. Mainframe computer 18 may also be coupled to a storage device 20 which may serve as remote storage for LAN 10.
Similarly, LAN 10 may be coupled via communications link 24 through a subsystem control unit/communications controller 26 and communications link 34 to a gateway server 28.
Gateway server 28 is preferably an individual computer or IWS which serves to link LAN 32 to LAN 10.
2098~17 As discussed above with respect to LAN 32 and LAN 10, a plurality of documents or resource ob;ects may be stored within storage device 20 and controlled by mainframe computer 18, as Resource Manager or Library Service for the resource objects thus stored. Of course, those skilled in the art will appreciate that mainframe comp~ter 18 may be located a great geographic distance from LAN 10 and similarly LAN 10 may be located a substantial distance from LAN 32. For example, LAN 32 may be located in California while LAN 10 may be located within Texas and mainframe computer 18 may be located in New York.
A multitasking environment including multiple processes may be found on individual computers 12 and 30, on gateway server 28, on some computer in LAN 10 or 32, or on mainframe computer 18.
I~ accordance with a preferred embodiment of the present invention, a object management system is utilized to manage CC. ~ni cations across processe~ and to track and locate objects executing within the processes in the multitasking environment. The object management system includes an object dispatcher process (ODP) and a message dispatcher (MD). This management system may include: (1) a launching mechanism to launch or initiate the launching of an object within a process, (2) a mechanism for grouping objects within a process, (3) a location mechanism to locate the process within which an object is executing, and (4) a system for forwarding messages.
.
An object is identified by a static identity and a dynamic identity. The "static identity" is the DCE name of the object, i.e., its spatial identification, in accordance with a preferred embodiment of the present invention. For example, /.../austin.ibm.com/host~objl identifies "objl" as an object in the "host" subdirectory of "austin.ibm.com"
cell. Next, the "dynamic identity" of an object is defined by a process-ID and a pointer in accordance with a preferred embodiment of the present invention.
.
The object management system monitors the objects within the various processes and maintains a local registry of all active objects. An object requesting a communications path to a target object utilizes a static identity to identify the target object. An object locator component of the object management system in the ODP is utilized to identify the dynamic identity of an object that corresponds to the static identity of the object. A mapping table is employed in the ODP to track and monitor objects registered to the ODP. If an entry for the name of an object is absent from the mapping table, the ODP launches or initializes the launching of the object in accordance with a preferred embodiment of the present invention. The ODP registers an object when the ODP launches the object. Registration also occurs when an ob;ect communicates with the ODP.
Three pieces of information are required to launch an object in accordance with a preferred embodiment of the present invention: (1) object identity, (2) class of the object, and (3) object handler. With an object identity, the static identity is sufficient if the object is not yet active. The object handler includes the code corresponding to the methods of the object.
The ODP is a pivotal process in the method and system utilized to initiate and manage inter-object communication across processes and also may provide an "object locator"
~ service in accordance with a preferred embodiment of the present invention. The ODP is a communications manager and constantly monitors for messages on a well-known port. Each cc lnications path or channel to the ODP from a process is ; serviced by a "receiver thread'l, which is responsible for receiving a message on the appropriate path, decoding the message, and taking or initiating appropriate actions. A
"receiver thread" is a thread within the ODP. Appropriate actions such as launching or initiating the launching of objects and creating communication paths or channels between processes are examples of actions taken by the receiver thread.
A message received by the ODP may include the following components: (1) object name, (2) class, (3) operation, and (4) arguments. An operation may be, for example, to find and load an object, to create a new instance of an object, or may be any other operation that is defined in an object's object handler. The object name is the name of the object that is to receive a message. The class is the class of that object. ODP registers objects that it launches and objects that CG In1 cate with the ODP.
The MD may manage inter-process and intra-process cc ln~cation between objects in accordance with a preferred embodiment of the present invention. It is responsible for dèlivering messages or methods to objects within the process in which the MD is located. Incoming messages from another process are handled by forwarding them to the appropriate object by utilizing the object handle field within the message .
When a local object sends a message to a foreign object, located in a different process and no communications path has been established between the two processes, the MD sends the message to the ODP to establish a communications path to the process containing the foreign object. The ODP searches the mapping table to determine if an entry for the foreign object exists.
In the event that an entry exists, the ODP extracts the dynamic identity (process-ID and handle within the process) of the foreign object from the mapping table. The handle within a process is utilized to identify an object within the proces~. The ODP sends the message to the foreign object and returns a message to the requesting process that contains the method name, argument list, and a handle within the process for the foreign object in accordance with a preferred embodiment of the present invention. The MD of the local object utilizes this information to send a message to the forelgn object vla a cc. In~cations path or channel in accordance with a preferred embodiment of the present invention.
2098~17 If the ODP does not find an object entry in the mapping table, the ODP searches a class table to determine whether or not the foreign object'~ ~lass has been loaded into any process. If it has, a message is ~ent to that proces~ to launch the foreign object. The message sent to the process may be in the format: (operation, argument list, class name, a DLL name). DLL stands for Dynamic Link Library. If the class of the foreign object has not been loaded into a process, a new process is started and the foreign object is launched within the new process.
In launching a object, it is assumed that the DCE name of the object is known as well as the class of the object and the name of the object handler for the object in accordance with a preferred embodiment of the present invention. The object handler of the object is the name of the dynamic link library (DLL) file in OS/2. A DLL is a set of subroutines that are dynamically bound to the calling program or object when the program or object is loaded into memory or when they are loaded explicitly by an already executing program or object. The DLL file contains the methods that the foreign object will respond to in accordance with a preferred embodiment of the present invention. More information on DLL calls may be found in La-Garde et al., IBM Operating System/2~ Version 1.2 Programming Guide, International Business Machines Corporation, Document No.
OOF8833, 1989 and in a text entitled The Design of OS/2 by Deitel and Kogan, published by Addison-Wesley Publishing Co.
1992.
In the situation where a communications path has already been established between the process containing a local object and the process containing the foreign object, the invocation of an operation on a foreign object by a local object results in the MD constructing the necessary message and forwarding it directly to the process that is executing the foreign object over the a communications path that was previously set up. MD maintains two tables for managing inter-process and intra-proces~ communications: (1) class table and (2) object table in accordance with a preferred 2098~17 embodiment of the present invention. The class table is a data structure that maintains a list of all classes that are registered in a particular process. The object table is a table for storing a list of all objects existing within a particular process and foreign object~ that are an in communication with these objects. As a result, MD also provides a grouping mechanism to group objects within a process.
Foreign objects are associated with binding information and channel identification that is necessary for reaching a foreign object. Channel identification is data that uniquely identifies a communications channel between a sender and a receiver. For example if a "sockets" implementation is being utilized for communication, a port number would uniquely identify the cc- lnications channel and if "shared memory"
is employed for CG lni cation, the name of the shared memory se~_ -nt would uniquely identify the communications channel.
The MD also continuously "pings" or monitors the ODP to see if the ODP is currently executing. If MD determines through a time out mechanism that ODP is no longer running, it initiates a "clean up" and terminates itself.
Referring now to Figure 2, there is depicted a diagram illustrating the establishment of a communications link between an ODP and a process in accordance with a preferred embodiment of the present invention. ODP 200 scans port 202 for requests from other processes or subsystems, such as process 204, to connect to ODP 200. A subsystem is a logical sub-component of a larger system, e.g., a file system in a operating system. Port 202 is a well known port known to those skilled in the art. Port 202 is a well known port that may be associated with a well known server process (i.e., name server, file-transfer protocol server, etc.). "Well known" ports are those that are active on all machines. In a network of computers, a process on a machine may be identified by a pair: (machine-ID, port number). The port number identifies a process on a given machine.
AT9-92-112 ~Q 9 8 ~17 In response to such a request, ODP 200 returns a "binding"
to the requesting process, proces~ 204. The new binding represents a new co Inications path or channel, channel 206, between the process 204 and ODP 200. ODP 200 utilizes this ch~nnel in all subsequent interaction with process 204.
As mentioned before, each of the communications paths or channels associated with the ODP are serviced by a "receiver" thread. This thread is responsible for receiving the message on the appropriate path or channel, decoding the message, and taking or initiating the appropriate action.
Me#sages received by ODP include object name, class, operation, and arguments.
With reference now to Figure 3, there is depicted a data flow diagram illustrating the establishment of a communications link between two processes in a situation where one object has not been instantiated in accordance with a preferred embodiment of the present invention. Object 250 of class A is executing in process 252. Object 250 attempts to instantiate a new object, Obj2, of class B. MD
254 searches it's local class table and does not find class B.
Consequently, MD 254 sends a message to ODP 256 via communications path 258, asking ODP 256 to instantiate Obj2 of class B. Cc lnications path 258 may be established as previously illustrated in Figure 2. ODP 256 decodes the message and looks in its mapping table 257 for Obj2.
Assuming ODP 256 does not find Obj2 in mapping table 257, ODP 256 then obtains the name of Obj2's class from the message.
, ODP 256 initiates process 260 with class B loaded in it. MD
261 in process 260 instantiates or launches Obj2 and returns i~ Obj2_Handle and a new binding to ODP 256 to form -~ cc lnications path 262. ODP 256 updates mapplng table 257 to include the association between Obj2 and Obj2_Handle.
.
' AT9-92-112 2 ~ ~28 4 17 ODP 256 returns binding to MD 254 to establish communications path 264. The MD 254 updates its local object table to associate Obj2 with the communications path to process 260 and returns a local handle for Obj2 to Object 250, forming communications path 264. All subsequent operations on Obj2 by objects in process 252 are sent directly to process 260 over communications path 264.
Referring now to ~igure 4A and Figure 4B, there is depicted a logical flowchart for creating a communications path in accordance with a preferred embodiment of the present invention. The procedure begins as illustrated in block 400 and thereafter proceeds to block 402, which depicts the sending of a request, MO, to the ODP by a requesting object, which is the client of the ODP, to create a communications path to a target object. MO is a message, containing the following information on the target object: (1) object name, (2) object class, (3) method name, (4) an argument list, and (5) a DLL file name. MO identifies the object utilizing a static identity. The procedure then proceeds to block 404, which illustrates the reception of the message, MO, by the ODP, the decoding of the message, MO, and the looking up of the object name in a mapping table by ODP.
Next, the procedure then proceeds to block 406, which depicts a determination of whether or not an object name has been found in the ODP's mapping table corresponding to the object name specified in MO. The mapping table contains an entry for each object that is registered with the ODP. In accordance with a preferred embodiment of the present invention, each entry contains: (1) object name, (2) process-ID, and (3) handle within the process in which the object is found. As mentioned before, objects are registered when they send a request to the ODP or when the ODP launches an object. If an object name has been found, the procedure then proceeds to block 408, which illustrates the extraction of a tuple (process-ID, handle within process) from the mapping table and corresponding the tuple to the object name in MO.
Afterward, the procedure proceeds to block 410, which depicts the sending of a mes~age, M1, to the MD in the process containing the target object. The message, Ml, contains the method name, an arguments list, and the handle within the process. Ml contains the dynamic identity of the object. The procedure then proceeds to block 414, which illustrates the MD in the process of the target object receiving the message. The message includes the method name, an argument list, and the handle within the process for the object requested by the requesting object. Thereafter, the procedure proceeds to block 430 via connector C, which illustrates the return of a binding by the ODP to the client for the process containing the target object. Binding information is found within a connection table in the ODP.
The connection table include~ a process-ID associated with binding information for a particular process. This connection table is utilized to provide binding information to various objects requiring c~ ln~cation's paths to objects in other processes in accordance with a preferred embodiment of the present invention. The process thereafter terminates as illustrated in block 432.
Referring back to block 406, if an object name is not found in the mapping table, the procedure proceeds to block 416, which illustrates the searching of a class table for the object class of the target object requested. The procedure then proceeds to block 418, which depicts a determination of whether or not the class is found in the class table in the ODP. The class table contains information on the object class and the process-ID associated with each object class in accordance with a preferred embodiment of the present invention. A class is registered when an object contacts the ODP if the class is not already in the class table. A class i8 also registered if the ODP launches or initiates the launching of a new process having a class not found in the ODP's class table. If the class is found, the procedure proceeds to block 419, which illustrates the extraction of a cla##-ID for the target object's cla~s from the class table.
Thereafter, the procedure continues to block 420 in Figure 4B via connecter A. Block 420 illustrates the extraction of the process-ID in which the class of the target object is loaded. Thereafter, the procedure proceeds to block 422, which depicts the sending of a message, M2, to the process in which the class of the target object is loaded. The message, M2, contains (1) the object class, (2) opn = new, and (3) the DLL of the target object. M2 is a request to launch the target object in the process. Next, the procedure proceeds to block 424, which illustrates waiting for a reply from the process in which the class of the target object is loaded.
Thereafter, the procedure proceeds to block 426, which depicts the reception the process-ID and the handle of the newly created target ob~ect from the process in which the cla~s is loaded. The procedure then proceeds to block 428, which illustrates the registration of the target object and its handle into the mapping table by the ODP. The procedure proceeds to block 430, which depicts the ODP returning a "binding" to the process of the newly created target object.
As a result, future requests for the target object by the requesting object may be directly sent to the process containing the target object, and thus, bypassing the ODP
and thereby increasing performance and speed of cc ln;cations between objects. The procedure then terminates as illustrated in block 432.
Referring back to block 418, if a class is not found in the class table, the procedure then proceeds, via connector B, to block 433, which illustrates the initiation or launching olf a new process and the loading of the class of the target object into the new process utilizing the class name extracted from the request from the requesting object. The procedure advances to block 434, which depicts the registration of the class name and the process-ID of the new process into the class table in the ODP.
~, Thereafter, the procedure proceeds to block 422, which - depicts the sending of a message, M2, to the new proce~s.
As described above, M2 contains the target object class, opn = "new", and the DLL of the target ob;ect. The procedure !
next advances to block 424, which illustrates waiting for a reply from the process. Afterward, the procedure continues to block 426, which depicts the returning of the proce~-ID
and the handle of the newly created target object by the process to the ODP. The procedure then proceeds to block 428, which illustrates the registration of the target object and its handle into the mapping table by the ODP. The procedure next proceeds to block 430, which depicts the return of a "binding" for the process to the requesting object by the ODP. Again, the procedure then terminates as depicted in block 432.
Referring now to Figure 5, there is depicted a logical flowchart of the process followed by a message dispatcher (MD) in accordance with a preferred embodiment of the present invention. As illustrated the procedure begins in block 500 and thereafter proceeds to block 502, which depicts the reception of a message and the decoding of the message by the MD. Thereafter, the procedure proceeds to block 504, which illustrates a determination of whether or not opn equals "new". If opn does not equal "new" the procedure advances to block 506, which depicts the extraction of the handle, method name, and argument list from the message and utilizing a system object model (SOM) dispatch to deliver the message to the object. SOM is a mechanism utilized to deliver messages to objects within the same process. SOM is found in the OS/2 2.0 Software Development Toolkit (SDK) available from International Business Machines Corporation.
Thereafter, the procedure proceeds to block 508, which illustrates the returning of the results to the object sending the message. The procedure then terminates as depicted in block 510.
!
Referring again to block 504, if "opn" equals "new", the procedure then proceeds to block 512, which illustrates using the object DLL to load the class into the process.
Thereafter, the procedure proceeds to block 514, which djepicts the lnvocation of SOM dispatch on the above "class object" to create a new object. The procedure proceeds to block 516, which illustrates the sending of a reply to ODP
to register the newly created ob~ect into ODP's mapping table. The procedure again terminates as illustrated in block 510.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
In multi-tasking operating systems, hardware may be managed as a shared resource to be distributed among concurrently executing applications or programs. In a multi-tasking operating system, resources such as the processor, memory, files, devices and inter-process cc. ~ni cations structures are also shared in the operating system among concurrently executing applications, programs, or objects. "Timeslicing"
i8 utilized to share the processor with various concurrently executing applications or objects. Generally, an operating system will switch between applications allowing each application to run for a short period of time, a "timeslice". Thus, in this manner, the processor may be shared between various applications or objects, enabling multitasking.
For example, OS/2~ is an operating system that offers a multitasking architecture, providing the capability to execute multiple programs in a protected environment. OS/2 include~ a hierarchy of multi-tasking options called es~ion~, processes, and threads. A "session" i8 a unit of u~er input/output ('II/O") device sharing. A "process" is a unit for ~haring for various re~ources, such as memory, .
files, semaphores, queues, and threads. A process may contain multiple programs or objects. More information on OS/2 in a text entitled The Design of OS/2 by Deitel and Kogan, published by Addison-Wesley Publishing Co. 1992.
Objects are D~E objects as defined in OSF DCE User's Guide And Reference from Open Software located at ll Cambridge Center, Cambridge, Massachusetts 02143. In an environment containing different and potentially independent application objects (all of which are built upon a base class hierarchy), which are being developed, a need exists to decouple the run-time environments in which the objects execute. The need for decoupling arises out of a concern for integrity between the objects. Generally, if two objects are executing within the same process, the failure of one object will jeopardize the other object. In other words, if one object fails within a process, normally all of the other objects within the same process will also fail or become unstable. An erroneous implementation of one object also may corrupt the other ob;ects.
Objects executing within the same process are able to easily exchange data. Often times, it is desirable to interchange data or send messages to an object within a different process. Data exchange becomes more difficult between objects executing in different processes.
Presently, data sharing and message sending between two objects, located in different processes, are handled by writing a protocol specific to the two objects. As a result, djata sharing and message sending may only occur between those two objects. In order to add a third object, additional code must be produced to allow for data sharing and message sending between all three objects.
Therefore, it would be desirable to have a method and system to manage the di~tribution and communication of data and mes~ages across processes without having to produce new protocols for each additional process.
SUMMARY OF THE lN~ l0N
It is therefore one object of the present invention to provide a method and system for managing communications in a data processing system.
It i8 another object of the present invention to provide a method and system for managing co lnications between objects executing within a data processing system.
It is yet another object of the present invention to provide a method and system for managing communications between objects executing in different processes within a data piocessing system.
The foregoing objects are achieved as is now described. The present invention provides a method and system in a data processing system, having a multitasking operating system that includes a plurality of processes, for providing communication between objects executing within the processes in the multitasking operating system. The method and system includes registering an object with a communications manager in response to a launching of the object. The communications manager monitors all objects registered to it within the plurality of processes. A determination of whether a first object is registered is made utilizing the communications manager, in response to receiving a request from a second object to send a message to the first object. Automatic initiation of the launching the first object within the j processes is performed utilizing the communications manager if the first object is unregistered. Next, the process containing the first object is bound to the process containing the second object, wherein a communications path is established between the two processes. The message is sent to the first object from the second object via the c,_. ications path between the two processes, wherein cc. lnication between the first object and the second object is automatically established.
The above as well as additional objects, features, and advantages of the pre~ent invention will become apparent in the following detailed written description.
BRIEF D~PTPTION OF THE DRAWINGS
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein: -Figure 1 depicts a pictorial representation of a data processing system which may be utilized to implement a method of the present invention;
Figure 2 is a diagram illustrating the establishment of a communications link between an object dispatch process (ODP) and a process in accordance with a preferred embodiment of the present invention;
Figure 3 depicts a data flow diagram illustrating the e~tablishment of a communications link between two processes in a situation where one object has not been instantiated in accordance with a preferred embodiment of the present invention.
Fijgure 4A is a portion of logical flowchart for creating a communications path in accordance with a preferred embodiment of the present invention;
Figure 4B is a portion of logical flowchart for creating a communications path in accordance with a preferred embodiment of the present invention; and Figure 5 depicts a logical ~10wchart of the process followed by a message dispatcher (MD) in accordance with a preferred embodiment of the present invention.
DETAILED n~C~TPTION OF ~k~-~K~ EMBODIMENT
With reference now to the figures, and in particular with reference to Figure 1, there is depicted a pictorial representation of a data processing sy~tem 8 that may be utilized to implement a method and system of the present invention. As may be seen, data processing system 8 may include a plurality of networks, such as local area networks (LAN) 10 and 32, each of which preferably includes a plurality of individual computers 12 and 30, respectively.
Of course, those skilled in the art will appreciate that a plurality of intelligent work stations (IWS) coupled to a host processor may be utilized for each such network.
I
As is common in such data processing systems, each individual computer may be coupled to a storage device 14 and/or a printer/output device 16. One or more such storage devices 14 may be utilized, in accordance with the method of the present invention, to store documents or resource objects which may be periodically accessed by any user within data processing system 8. In a manner well known in the prior art, each such document or resource object stored within a storage device 14 may be freely interchanged throughout data processing system 8 by transferring a document to a user at an individual computer 12 or 32, for example.
i Still referring to Figure 1, it may be seen that data processing system 8 may also include multiple mainframe computers, such as mainframe computer 18, which may be preferably coupled to LAN 10 by means of communications link 22. Mainframe computer 18 may also be coupled to a storage device 20 which may serve as remote storage for LAN 10.
Similarly, LAN 10 may be coupled via communications link 24 through a subsystem control unit/communications controller 26 and communications link 34 to a gateway server 28.
Gateway server 28 is preferably an individual computer or IWS which serves to link LAN 32 to LAN 10.
2098~17 As discussed above with respect to LAN 32 and LAN 10, a plurality of documents or resource ob;ects may be stored within storage device 20 and controlled by mainframe computer 18, as Resource Manager or Library Service for the resource objects thus stored. Of course, those skilled in the art will appreciate that mainframe comp~ter 18 may be located a great geographic distance from LAN 10 and similarly LAN 10 may be located a substantial distance from LAN 32. For example, LAN 32 may be located in California while LAN 10 may be located within Texas and mainframe computer 18 may be located in New York.
A multitasking environment including multiple processes may be found on individual computers 12 and 30, on gateway server 28, on some computer in LAN 10 or 32, or on mainframe computer 18.
I~ accordance with a preferred embodiment of the present invention, a object management system is utilized to manage CC. ~ni cations across processe~ and to track and locate objects executing within the processes in the multitasking environment. The object management system includes an object dispatcher process (ODP) and a message dispatcher (MD). This management system may include: (1) a launching mechanism to launch or initiate the launching of an object within a process, (2) a mechanism for grouping objects within a process, (3) a location mechanism to locate the process within which an object is executing, and (4) a system for forwarding messages.
.
An object is identified by a static identity and a dynamic identity. The "static identity" is the DCE name of the object, i.e., its spatial identification, in accordance with a preferred embodiment of the present invention. For example, /.../austin.ibm.com/host~objl identifies "objl" as an object in the "host" subdirectory of "austin.ibm.com"
cell. Next, the "dynamic identity" of an object is defined by a process-ID and a pointer in accordance with a preferred embodiment of the present invention.
.
The object management system monitors the objects within the various processes and maintains a local registry of all active objects. An object requesting a communications path to a target object utilizes a static identity to identify the target object. An object locator component of the object management system in the ODP is utilized to identify the dynamic identity of an object that corresponds to the static identity of the object. A mapping table is employed in the ODP to track and monitor objects registered to the ODP. If an entry for the name of an object is absent from the mapping table, the ODP launches or initializes the launching of the object in accordance with a preferred embodiment of the present invention. The ODP registers an object when the ODP launches the object. Registration also occurs when an ob;ect communicates with the ODP.
Three pieces of information are required to launch an object in accordance with a preferred embodiment of the present invention: (1) object identity, (2) class of the object, and (3) object handler. With an object identity, the static identity is sufficient if the object is not yet active. The object handler includes the code corresponding to the methods of the object.
The ODP is a pivotal process in the method and system utilized to initiate and manage inter-object communication across processes and also may provide an "object locator"
~ service in accordance with a preferred embodiment of the present invention. The ODP is a communications manager and constantly monitors for messages on a well-known port. Each cc lnications path or channel to the ODP from a process is ; serviced by a "receiver thread'l, which is responsible for receiving a message on the appropriate path, decoding the message, and taking or initiating appropriate actions. A
"receiver thread" is a thread within the ODP. Appropriate actions such as launching or initiating the launching of objects and creating communication paths or channels between processes are examples of actions taken by the receiver thread.
A message received by the ODP may include the following components: (1) object name, (2) class, (3) operation, and (4) arguments. An operation may be, for example, to find and load an object, to create a new instance of an object, or may be any other operation that is defined in an object's object handler. The object name is the name of the object that is to receive a message. The class is the class of that object. ODP registers objects that it launches and objects that CG In1 cate with the ODP.
The MD may manage inter-process and intra-process cc ln~cation between objects in accordance with a preferred embodiment of the present invention. It is responsible for dèlivering messages or methods to objects within the process in which the MD is located. Incoming messages from another process are handled by forwarding them to the appropriate object by utilizing the object handle field within the message .
When a local object sends a message to a foreign object, located in a different process and no communications path has been established between the two processes, the MD sends the message to the ODP to establish a communications path to the process containing the foreign object. The ODP searches the mapping table to determine if an entry for the foreign object exists.
In the event that an entry exists, the ODP extracts the dynamic identity (process-ID and handle within the process) of the foreign object from the mapping table. The handle within a process is utilized to identify an object within the proces~. The ODP sends the message to the foreign object and returns a message to the requesting process that contains the method name, argument list, and a handle within the process for the foreign object in accordance with a preferred embodiment of the present invention. The MD of the local object utilizes this information to send a message to the forelgn object vla a cc. In~cations path or channel in accordance with a preferred embodiment of the present invention.
2098~17 If the ODP does not find an object entry in the mapping table, the ODP searches a class table to determine whether or not the foreign object'~ ~lass has been loaded into any process. If it has, a message is ~ent to that proces~ to launch the foreign object. The message sent to the process may be in the format: (operation, argument list, class name, a DLL name). DLL stands for Dynamic Link Library. If the class of the foreign object has not been loaded into a process, a new process is started and the foreign object is launched within the new process.
In launching a object, it is assumed that the DCE name of the object is known as well as the class of the object and the name of the object handler for the object in accordance with a preferred embodiment of the present invention. The object handler of the object is the name of the dynamic link library (DLL) file in OS/2. A DLL is a set of subroutines that are dynamically bound to the calling program or object when the program or object is loaded into memory or when they are loaded explicitly by an already executing program or object. The DLL file contains the methods that the foreign object will respond to in accordance with a preferred embodiment of the present invention. More information on DLL calls may be found in La-Garde et al., IBM Operating System/2~ Version 1.2 Programming Guide, International Business Machines Corporation, Document No.
OOF8833, 1989 and in a text entitled The Design of OS/2 by Deitel and Kogan, published by Addison-Wesley Publishing Co.
1992.
In the situation where a communications path has already been established between the process containing a local object and the process containing the foreign object, the invocation of an operation on a foreign object by a local object results in the MD constructing the necessary message and forwarding it directly to the process that is executing the foreign object over the a communications path that was previously set up. MD maintains two tables for managing inter-process and intra-proces~ communications: (1) class table and (2) object table in accordance with a preferred 2098~17 embodiment of the present invention. The class table is a data structure that maintains a list of all classes that are registered in a particular process. The object table is a table for storing a list of all objects existing within a particular process and foreign object~ that are an in communication with these objects. As a result, MD also provides a grouping mechanism to group objects within a process.
Foreign objects are associated with binding information and channel identification that is necessary for reaching a foreign object. Channel identification is data that uniquely identifies a communications channel between a sender and a receiver. For example if a "sockets" implementation is being utilized for communication, a port number would uniquely identify the cc- lnications channel and if "shared memory"
is employed for CG lni cation, the name of the shared memory se~_ -nt would uniquely identify the communications channel.
The MD also continuously "pings" or monitors the ODP to see if the ODP is currently executing. If MD determines through a time out mechanism that ODP is no longer running, it initiates a "clean up" and terminates itself.
Referring now to Figure 2, there is depicted a diagram illustrating the establishment of a communications link between an ODP and a process in accordance with a preferred embodiment of the present invention. ODP 200 scans port 202 for requests from other processes or subsystems, such as process 204, to connect to ODP 200. A subsystem is a logical sub-component of a larger system, e.g., a file system in a operating system. Port 202 is a well known port known to those skilled in the art. Port 202 is a well known port that may be associated with a well known server process (i.e., name server, file-transfer protocol server, etc.). "Well known" ports are those that are active on all machines. In a network of computers, a process on a machine may be identified by a pair: (machine-ID, port number). The port number identifies a process on a given machine.
AT9-92-112 ~Q 9 8 ~17 In response to such a request, ODP 200 returns a "binding"
to the requesting process, proces~ 204. The new binding represents a new co Inications path or channel, channel 206, between the process 204 and ODP 200. ODP 200 utilizes this ch~nnel in all subsequent interaction with process 204.
As mentioned before, each of the communications paths or channels associated with the ODP are serviced by a "receiver" thread. This thread is responsible for receiving the message on the appropriate path or channel, decoding the message, and taking or initiating the appropriate action.
Me#sages received by ODP include object name, class, operation, and arguments.
With reference now to Figure 3, there is depicted a data flow diagram illustrating the establishment of a communications link between two processes in a situation where one object has not been instantiated in accordance with a preferred embodiment of the present invention. Object 250 of class A is executing in process 252. Object 250 attempts to instantiate a new object, Obj2, of class B. MD
254 searches it's local class table and does not find class B.
Consequently, MD 254 sends a message to ODP 256 via communications path 258, asking ODP 256 to instantiate Obj2 of class B. Cc lnications path 258 may be established as previously illustrated in Figure 2. ODP 256 decodes the message and looks in its mapping table 257 for Obj2.
Assuming ODP 256 does not find Obj2 in mapping table 257, ODP 256 then obtains the name of Obj2's class from the message.
, ODP 256 initiates process 260 with class B loaded in it. MD
261 in process 260 instantiates or launches Obj2 and returns i~ Obj2_Handle and a new binding to ODP 256 to form -~ cc lnications path 262. ODP 256 updates mapplng table 257 to include the association between Obj2 and Obj2_Handle.
.
' AT9-92-112 2 ~ ~28 4 17 ODP 256 returns binding to MD 254 to establish communications path 264. The MD 254 updates its local object table to associate Obj2 with the communications path to process 260 and returns a local handle for Obj2 to Object 250, forming communications path 264. All subsequent operations on Obj2 by objects in process 252 are sent directly to process 260 over communications path 264.
Referring now to ~igure 4A and Figure 4B, there is depicted a logical flowchart for creating a communications path in accordance with a preferred embodiment of the present invention. The procedure begins as illustrated in block 400 and thereafter proceeds to block 402, which depicts the sending of a request, MO, to the ODP by a requesting object, which is the client of the ODP, to create a communications path to a target object. MO is a message, containing the following information on the target object: (1) object name, (2) object class, (3) method name, (4) an argument list, and (5) a DLL file name. MO identifies the object utilizing a static identity. The procedure then proceeds to block 404, which illustrates the reception of the message, MO, by the ODP, the decoding of the message, MO, and the looking up of the object name in a mapping table by ODP.
Next, the procedure then proceeds to block 406, which depicts a determination of whether or not an object name has been found in the ODP's mapping table corresponding to the object name specified in MO. The mapping table contains an entry for each object that is registered with the ODP. In accordance with a preferred embodiment of the present invention, each entry contains: (1) object name, (2) process-ID, and (3) handle within the process in which the object is found. As mentioned before, objects are registered when they send a request to the ODP or when the ODP launches an object. If an object name has been found, the procedure then proceeds to block 408, which illustrates the extraction of a tuple (process-ID, handle within process) from the mapping table and corresponding the tuple to the object name in MO.
Afterward, the procedure proceeds to block 410, which depicts the sending of a mes~age, M1, to the MD in the process containing the target object. The message, Ml, contains the method name, an arguments list, and the handle within the process. Ml contains the dynamic identity of the object. The procedure then proceeds to block 414, which illustrates the MD in the process of the target object receiving the message. The message includes the method name, an argument list, and the handle within the process for the object requested by the requesting object. Thereafter, the procedure proceeds to block 430 via connector C, which illustrates the return of a binding by the ODP to the client for the process containing the target object. Binding information is found within a connection table in the ODP.
The connection table include~ a process-ID associated with binding information for a particular process. This connection table is utilized to provide binding information to various objects requiring c~ ln~cation's paths to objects in other processes in accordance with a preferred embodiment of the present invention. The process thereafter terminates as illustrated in block 432.
Referring back to block 406, if an object name is not found in the mapping table, the procedure proceeds to block 416, which illustrates the searching of a class table for the object class of the target object requested. The procedure then proceeds to block 418, which depicts a determination of whether or not the class is found in the class table in the ODP. The class table contains information on the object class and the process-ID associated with each object class in accordance with a preferred embodiment of the present invention. A class is registered when an object contacts the ODP if the class is not already in the class table. A class i8 also registered if the ODP launches or initiates the launching of a new process having a class not found in the ODP's class table. If the class is found, the procedure proceeds to block 419, which illustrates the extraction of a cla##-ID for the target object's cla~s from the class table.
Thereafter, the procedure continues to block 420 in Figure 4B via connecter A. Block 420 illustrates the extraction of the process-ID in which the class of the target object is loaded. Thereafter, the procedure proceeds to block 422, which depicts the sending of a message, M2, to the process in which the class of the target object is loaded. The message, M2, contains (1) the object class, (2) opn = new, and (3) the DLL of the target object. M2 is a request to launch the target object in the process. Next, the procedure proceeds to block 424, which illustrates waiting for a reply from the process in which the class of the target object is loaded.
Thereafter, the procedure proceeds to block 426, which depicts the reception the process-ID and the handle of the newly created target ob~ect from the process in which the cla~s is loaded. The procedure then proceeds to block 428, which illustrates the registration of the target object and its handle into the mapping table by the ODP. The procedure proceeds to block 430, which depicts the ODP returning a "binding" to the process of the newly created target object.
As a result, future requests for the target object by the requesting object may be directly sent to the process containing the target object, and thus, bypassing the ODP
and thereby increasing performance and speed of cc ln;cations between objects. The procedure then terminates as illustrated in block 432.
Referring back to block 418, if a class is not found in the class table, the procedure then proceeds, via connector B, to block 433, which illustrates the initiation or launching olf a new process and the loading of the class of the target object into the new process utilizing the class name extracted from the request from the requesting object. The procedure advances to block 434, which depicts the registration of the class name and the process-ID of the new process into the class table in the ODP.
~, Thereafter, the procedure proceeds to block 422, which - depicts the sending of a message, M2, to the new proce~s.
As described above, M2 contains the target object class, opn = "new", and the DLL of the target ob;ect. The procedure !
next advances to block 424, which illustrates waiting for a reply from the process. Afterward, the procedure continues to block 426, which depicts the returning of the proce~-ID
and the handle of the newly created target object by the process to the ODP. The procedure then proceeds to block 428, which illustrates the registration of the target object and its handle into the mapping table by the ODP. The procedure next proceeds to block 430, which depicts the return of a "binding" for the process to the requesting object by the ODP. Again, the procedure then terminates as depicted in block 432.
Referring now to Figure 5, there is depicted a logical flowchart of the process followed by a message dispatcher (MD) in accordance with a preferred embodiment of the present invention. As illustrated the procedure begins in block 500 and thereafter proceeds to block 502, which depicts the reception of a message and the decoding of the message by the MD. Thereafter, the procedure proceeds to block 504, which illustrates a determination of whether or not opn equals "new". If opn does not equal "new" the procedure advances to block 506, which depicts the extraction of the handle, method name, and argument list from the message and utilizing a system object model (SOM) dispatch to deliver the message to the object. SOM is a mechanism utilized to deliver messages to objects within the same process. SOM is found in the OS/2 2.0 Software Development Toolkit (SDK) available from International Business Machines Corporation.
Thereafter, the procedure proceeds to block 508, which illustrates the returning of the results to the object sending the message. The procedure then terminates as depicted in block 510.
!
Referring again to block 504, if "opn" equals "new", the procedure then proceeds to block 512, which illustrates using the object DLL to load the class into the process.
Thereafter, the procedure proceeds to block 514, which djepicts the lnvocation of SOM dispatch on the above "class object" to create a new object. The procedure proceeds to block 516, which illustrates the sending of a reply to ODP
to register the newly created ob~ect into ODP's mapping table. The procedure again terminates as illustrated in block 510.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
Claims (18)
1. A method in a data processing system, having a multitasking operating system which includes a plurality of processes, for providing communication between a plurality of objects executing within said plurality of processes in said multitasking operating system, said method comprising the computer implemented steps of:
registering an object with a communications manager in response to a launching of said object by said object manager;
determining whether a first object is registered with said communications manager, in response to receiving a request from a second object within said plurality of processes to send a message to said first object;
automatically initiating launching of said first object within said plurality of processes utilizing said communications manager if said first object is unregistered;
binding a first of said plurality of processes containing said first object to a second of said plurality of processes containing said second object, wherein a communications path is established between said first of said plurality of processes and said second of said plurality of processes; and sending said message to said first object within said first of said plurality of processes from said second object in said second of said plurality of processes via said established communications path between said first of plurality of processes and said second of plurality of processes, wherein communication between said first object and said second object is automatically established.
registering an object with a communications manager in response to a launching of said object by said object manager;
determining whether a first object is registered with said communications manager, in response to receiving a request from a second object within said plurality of processes to send a message to said first object;
automatically initiating launching of said first object within said plurality of processes utilizing said communications manager if said first object is unregistered;
binding a first of said plurality of processes containing said first object to a second of said plurality of processes containing said second object, wherein a communications path is established between said first of said plurality of processes and said second of said plurality of processes; and sending said message to said first object within said first of said plurality of processes from said second object in said second of said plurality of processes via said established communications path between said first of plurality of processes and said second of plurality of processes, wherein communication between said first object and said second object is automatically established.
2. The method of claim 1 further comprising registering an object in response to a request for communication with said communications manager by said object.
3. The method of claim 2, wherein said communications manager registers an object by storing data for an object within a mapping table, wherein said mapping table contains an entry for each object registered by said communications manager.
4. The method of claim 3, wherein said entry includes an identifier identifying the process in which said registered object has been launched.
5. The method of claim 4, wherein said entry further includes a pointer to said object.
6. The method of claim 5, wherein said binding of said first of said plurality of processes to said second of said plurality of processes includes sending said second of said plurality of processes binding data for said first of said plurality of processes.
7. The method of claim 6, wherein each of said plurality of processes includes a message dispatcher for managing communications within a process and between processes, wherein said message dispatcher has a communications path to said communications manager.
8. The method of claim 7, wherein said message dispatcher for a process maintains a data structure having a list of all objects within said process and all objects in other processes having a communications path to said process.
9. A method in a data processing system, having a multitasking operating system which includes a plurality of processes, for providing communication between a plurality of objects executing within said plurality of processes in said multitasking operating system, said method comprising the computer implemented steps of:
registering an object with a communications manager in response to a launching of said object by said object manager, wherein said communications manager monitors all objects registered to said communications manager within said plurality of processes;
determining whether a first object is registered with said object manager in response to receiving a request from a second object within said plurality of processes to send a message to said first object;
automatically searching said plurality of processes for a process containing a class for said first object within said plurality of processes if said first object is unregistered and if a process containing said class is present, automatically initiating launching of said first object within said process containing said class for said first object;
binding said process containing said class for said first object to a second of said plurality of processes containing said second object, wherein a communications path is established between said process containing said class and said second of said plurality of processes; and sending said message to said first object within said process containing said class and said second object within said second of said plurality of processes via said established communications path between said process containing class and said second of plurality of processes, wherein communication between said first object and said second object is automatically established.
registering an object with a communications manager in response to a launching of said object by said object manager, wherein said communications manager monitors all objects registered to said communications manager within said plurality of processes;
determining whether a first object is registered with said object manager in response to receiving a request from a second object within said plurality of processes to send a message to said first object;
automatically searching said plurality of processes for a process containing a class for said first object within said plurality of processes if said first object is unregistered and if a process containing said class is present, automatically initiating launching of said first object within said process containing said class for said first object;
binding said process containing said class for said first object to a second of said plurality of processes containing said second object, wherein a communications path is established between said process containing said class and said second of said plurality of processes; and sending said message to said first object within said process containing said class and said second object within said second of said plurality of processes via said established communications path between said process containing class and said second of plurality of processes, wherein communication between said first object and said second object is automatically established.
10. A data processing system, having a multitasking operating system which includes a plurality of processes, for providing communication between a plurality of objects executing within said plurality of processes in said multitasking operating system, said data processing system comprises:
registration means for registering an object with a communications manager in response to a launching of said object by said object manager;
determining means for determining whether a first object is registered with said communications manager in response to receiving a request from a second object within said plurality of processes to send a message to said first object;
initiation means for automatically initiating launching of said first object within said plurality of processes utilizing said communications manager if said first object is unregistered;
binding means for binding a first of said plurality of processes containing said first object to a second of said plurality of processes containing said second object, wherein a communications path is established between said first of said plurality of processes and said second of said plurality of processes; and sending means for sending said message to said first object within said first of said plurality of processes from said second object in said second of said plurality of processes via said established communications path between said first of plurality of processes and said second of plurality of processes, wherein communication between said first object and said second object is automatically established.
registration means for registering an object with a communications manager in response to a launching of said object by said object manager;
determining means for determining whether a first object is registered with said communications manager in response to receiving a request from a second object within said plurality of processes to send a message to said first object;
initiation means for automatically initiating launching of said first object within said plurality of processes utilizing said communications manager if said first object is unregistered;
binding means for binding a first of said plurality of processes containing said first object to a second of said plurality of processes containing said second object, wherein a communications path is established between said first of said plurality of processes and said second of said plurality of processes; and sending means for sending said message to said first object within said first of said plurality of processes from said second object in said second of said plurality of processes via said established communications path between said first of plurality of processes and said second of plurality of processes, wherein communication between said first object and said second object is automatically established.
11. The data processing system of claim 10 further comprising means for registering an object in response to a request for communication with said communications manager by said object.
12. The data processing system of claim 11, wherein said communications manager registers an object utilizing means for storing data for an object within a mapping table, wherein said mapping table contains an entry for each object registered by said communications manager.
13. The data processing system of claim 12, wherein said entry includes an identifier identifying the process in which said registered object has been launched.
14. The data processing system of claim 13, wherein said entry further includes a pointer to said object.
15. The data processing system of claim 14, wherein said binding means includes means for sending said second of said plurality of processes binding data for said first of said plurality of processes.
16. The data processing system of claim 15, wherein each of said plurality of processes includes a message dispatcher for managing communications within a process and between processes, wherein said message dispatcher has a communications path to said communications manager.
17. The data processing system of claim 16, wherein said message dispatcher includes means for maintaining a data structure having a list of all objects within a process and all objects in other processes having a communications path to said process.
18. A data processing system, having a multitasking operating system which includes a plurality of processes, for providing communication between a plurality of objects executing within said plurality of processes in said multitasking operating system, comprising the computer implemented steps of:
registering an object with a communications manager in response to a launching of said object by said communications manager, wherein said object manager monitors all objects registered to said communications manager within said plurality of processes;
determining whether a first object is registered with said communications manager in response to receiving a request from a second object within said plurality of processes to send a message to said first object;
automatically searching said plurality of processes for a process containing said class for said first object within said plurality of processes if said first object is unregistered and if a process containing said class is present, means for automatically initiating launching of said first object within said process containing said class for said first object;
binding said process containing said class for said first object to a second of said plurality of processes containing said second object, wherein a communications path is established between said process containing said class and said second of said plurality of processes; and sending said message to said first object within said process containing class and said second object within said second of said plurality of processes via said established communications path between said process containing class and said second of plurality of processes, wherein communication between said first object and said second object is automatically established.
registering an object with a communications manager in response to a launching of said object by said communications manager, wherein said object manager monitors all objects registered to said communications manager within said plurality of processes;
determining whether a first object is registered with said communications manager in response to receiving a request from a second object within said plurality of processes to send a message to said first object;
automatically searching said plurality of processes for a process containing said class for said first object within said plurality of processes if said first object is unregistered and if a process containing said class is present, means for automatically initiating launching of said first object within said process containing said class for said first object;
binding said process containing said class for said first object to a second of said plurality of processes containing said second object, wherein a communications path is established between said process containing said class and said second of said plurality of processes; and sending said message to said first object within said process containing class and said second object within said second of said plurality of processes via said established communications path between said process containing class and said second of plurality of processes, wherein communication between said first object and said second object is automatically established.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US957,339 | 1992-10-06 | ||
| US07/957,339 US5396630A (en) | 1992-10-06 | 1992-10-06 | Method and system for object management across process boundries in a data processing system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2098417A1 CA2098417A1 (en) | 1994-04-07 |
| CA2098417C true CA2098417C (en) | 1998-12-29 |
Family
ID=25499442
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002098417A Expired - Fee Related CA2098417C (en) | 1992-10-06 | 1993-06-15 | Method and system for project management across process boundaries in a data processing system |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5396630A (en) |
| EP (1) | EP0592091A2 (en) |
| JP (1) | JP2572531B2 (en) |
| CA (1) | CA2098417C (en) |
Families Citing this family (70)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5336507A (en) * | 1992-12-11 | 1994-08-09 | Sterling Winthrop Inc. | Use of charged phospholipids to reduce nanoparticle aggregation |
| US5603031A (en) * | 1993-07-08 | 1997-02-11 | General Magic, Inc. | System and method for distributed computation based upon the movement, execution, and interaction of processes in a network |
| CA2155357C (en) * | 1993-07-19 | 2001-12-18 | David R. Anderson | Dynamic linking system |
| US5548726A (en) * | 1993-12-17 | 1996-08-20 | Taligeni, Inc. | System for activating new service in client server network by reconfiguring the multilayer network protocol stack dynamically within the server node |
| US6330582B1 (en) * | 1994-03-21 | 2001-12-11 | International Business Machines Corporation | Apparatus and method enabling a client to control transaction message traffic between server and client processes |
| DE59508793D1 (en) * | 1994-08-31 | 2000-11-23 | Siemens Ag | Procedure for managing dynamic objects in an object-oriented programmed facility |
| AU3415595A (en) * | 1994-10-04 | 1996-04-26 | Banctec, Inc. | An object-oriented computer environment and related method |
| US5678007A (en) * | 1994-11-22 | 1997-10-14 | Microsoft Corporation | Method and apparatus for supporting multiple outstanding network requests on a single connection |
| US5630757A (en) * | 1994-11-29 | 1997-05-20 | Net Game Limited | Real-time multi-user game communication system using existing cable television infrastructure |
| US6466992B2 (en) * | 1994-12-07 | 2002-10-15 | Next Computer, Inc. | Method for providing stand-in objects |
| EP0733971A3 (en) * | 1995-03-22 | 1999-07-07 | Sun Microsystems, Inc. | Method and apparatus for managing connections for communication among objects in a distributed object system |
| US5802291A (en) * | 1995-03-30 | 1998-09-01 | Sun Microsystems, Inc. | System and method to control and administer distributed object servers using first class distributed objects |
| US5727203A (en) * | 1995-03-31 | 1998-03-10 | Sun Microsystems, Inc. | Methods and apparatus for managing a database in a distributed object operating environment using persistent and transient cache |
| EP0735472A3 (en) * | 1995-03-31 | 2000-01-19 | Sun Microsystems, Inc. | Method and apparatus for conspiracy among objects |
| JPH08297573A (en) * | 1995-04-27 | 1996-11-12 | Fujitsu Ltd | Object data processor |
| US6539435B2 (en) * | 1995-06-21 | 2003-03-25 | International Business Machines Corporation | System and method for establishing direct communication between parallel programs |
| US5892946A (en) * | 1995-09-12 | 1999-04-06 | Alcatel Usa, Inc. | System and method for multi-site distributed object management environment |
| US5925108A (en) * | 1995-11-03 | 1999-07-20 | Novell, Inc. | Event notification in a computer system |
| CA2199108C (en) * | 1996-03-05 | 2002-04-23 | Hirotoshi Maegawa | Parallel distributed processing system and method of same |
| US6091895A (en) * | 1996-03-27 | 2000-07-18 | International Business Machines Corporation | Object oriented central maintenance for programs and scripts |
| US6113649A (en) * | 1996-03-27 | 2000-09-05 | International Business Machines Corporation | Object representation of program and script components |
| US5848272A (en) * | 1996-06-04 | 1998-12-08 | Lucent Technologies Inc. | Object-oriented intra-process messaging arrangement for windows environments |
| WO1998002823A2 (en) * | 1996-07-12 | 1998-01-22 | Sofmap Future Design Co., Ltd. | Program modules and parameter files in a network |
| US5877761A (en) * | 1996-07-12 | 1999-03-02 | Sofmap Future Design, Inc. | Method for smooth scrolling of text using window |
| US5974469A (en) * | 1996-07-12 | 1999-10-26 | Sofmap Future Design, Inc. | System for managing communication between program modules |
| US6031527A (en) * | 1996-07-12 | 2000-02-29 | Sofmap Future Design, Inc. | Methods and systems for developing computer applications |
| US5991536A (en) * | 1996-11-12 | 1999-11-23 | International Business Machines Corporation | Object-oriented tool for registering objects for observation and causing notifications to be made in the event changes are made to an object which is being observed |
| US6286050B1 (en) | 1997-01-27 | 2001-09-04 | Alcatel Usa Sourcing, L.P. | System and method for monitoring and management of telecommunications equipment using enhanced internet access |
| US6119173A (en) * | 1997-01-27 | 2000-09-12 | Alcatel Usa Sourcing, L.P. | System and method for communications and process management in a distributed telecommunications switch |
| US6601111B1 (en) * | 1997-01-29 | 2003-07-29 | Palmsource, Inc. | Method and apparatus for unified external and interprocess communication |
| JPH10232780A (en) * | 1997-02-19 | 1998-09-02 | Hitachi Ltd | Transforming method for interface definition description and inter-object communication method |
| US6282581B1 (en) * | 1997-03-27 | 2001-08-28 | Hewlett-Packard Company | Mechanism for resource allocation and for dispatching incoming calls in a distributed object environment |
| GB9706400D0 (en) * | 1997-03-27 | 1997-05-14 | British Telecomm | Distributed computing |
| US6742050B1 (en) | 1997-03-31 | 2004-05-25 | Intel Corporation | Inter-object messaging |
| US6834389B1 (en) * | 1997-12-01 | 2004-12-21 | Recursion Software, Inc. | Method of forwarding messages to mobile objects in a computer network |
| US6385661B1 (en) * | 1998-10-19 | 2002-05-07 | Recursion Software, Inc. | System and method for dynamic generation of remote proxies |
| US6163794A (en) * | 1998-10-23 | 2000-12-19 | General Magic | Network system extensible by users |
| EP1041485A1 (en) * | 1999-03-31 | 2000-10-04 | Sony Service Center (Europe) N.V. | Object with polymorphism |
| US6880126B1 (en) | 1999-08-03 | 2005-04-12 | International Business Machines Corporation | Controlling presentation of a GUI, using view controllers created by an application mediator, by identifying a destination to access a target to retrieve data |
| US6516358B1 (en) * | 1999-09-09 | 2003-02-04 | Hewlett-Packard Company | Appliance communications manager |
| US6862629B1 (en) * | 1999-10-21 | 2005-03-01 | International Business Machines Corporation | Method and system for dispatching socks traffic based on socks connection identified by source address, application address and application level protocol |
| US6779177B1 (en) | 1999-10-28 | 2004-08-17 | International Business Machines Corporation | Mechanism for cross channel multi-server multi-protocol multi-data model thin clients |
| US6862686B1 (en) | 1999-10-29 | 2005-03-01 | International Business Machines Corporation | Method and apparatus in a data processing system for the separation of role-based permissions specification from its corresponding implementation of its semantic behavior |
| US7181686B1 (en) | 1999-10-29 | 2007-02-20 | International Business Machines Corporation | Selecting screens in a GUI using events generated by a set of view controllers |
| US6947965B2 (en) | 1999-11-30 | 2005-09-20 | Recursion Software, Inc. | System and method for communications in a distributed computing environment |
| US6678743B1 (en) | 1999-11-30 | 2004-01-13 | Recursion Software, Inc. | Method for moving objects in a distributed computing environment |
| US9098437B2 (en) * | 2010-10-01 | 2015-08-04 | Z124 | Cross-environment communication framework |
| US8819705B2 (en) | 2010-10-01 | 2014-08-26 | Z124 | User interaction support across cross-environment applications |
| US8966379B2 (en) | 2010-10-01 | 2015-02-24 | Z124 | Dynamic cross-environment application configuration/orientation in an active user environment |
| US9047102B2 (en) | 2010-10-01 | 2015-06-02 | Z124 | Instant remote rendering |
| US8726294B2 (en) | 2010-10-01 | 2014-05-13 | Z124 | Cross-environment communication using application space API |
| US8933949B2 (en) | 2010-10-01 | 2015-01-13 | Z124 | User interaction across cross-environment applications through an extended graphics context |
| US20030050886A1 (en) * | 2001-09-11 | 2003-03-13 | International Business Machines Corporation | Method and apparatus for managing the versioning of business objects using a state machine |
| US20030050813A1 (en) * | 2001-09-11 | 2003-03-13 | International Business Machines Corporation | Method and apparatus for automatic transitioning between states in a state machine that manages a business process |
| US7627484B2 (en) * | 2001-09-11 | 2009-12-01 | International Business Machines Corporation | Method and apparatus for managing and displaying user authorizations for a business process managed using a state machine |
| US7689435B2 (en) * | 2001-09-11 | 2010-03-30 | International Business Machines Corporation | Method and apparatus for creating and managing complex business processes |
| US20030050789A1 (en) * | 2001-09-12 | 2003-03-13 | International Business Machines Corporation | Method and apparatus for monitoring execution of a business process managed using a state machine |
| US20030147383A1 (en) * | 2001-09-26 | 2003-08-07 | Karen Capers | Object communication services software development system and methods |
| US6976244B2 (en) * | 2002-01-09 | 2005-12-13 | International Business Machines Corporation | Method, system, and product for storage of attribute data in an object oriented environment |
| US7124414B2 (en) * | 2002-10-31 | 2006-10-17 | International Business Machines Corporation | Method, system and program product for routing requests in a distributed system |
| US7627871B2 (en) * | 2004-06-14 | 2009-12-01 | Alcatel-Lucent Usa Inc. | Instructing management support software of a first software component to set up a communication channel between the first software component and a second software component |
| US20080114627A1 (en) * | 2006-11-15 | 2008-05-15 | Sap Ag | System and Method for Capturing Process Instance Information in Complex or Distributed Systems |
| US9176761B2 (en) * | 2009-05-29 | 2015-11-03 | Red Hat, Inc. | Management of mainframe resources in pre-boot environment |
| CN107122168A (en) | 2010-10-01 | 2017-09-01 | Z124 | Multiple operating system |
| US9052800B2 (en) | 2010-10-01 | 2015-06-09 | Z124 | User interface with stacked application management |
| US8761831B2 (en) | 2010-10-15 | 2014-06-24 | Z124 | Mirrored remote peripheral interface |
| US9182935B2 (en) | 2011-09-27 | 2015-11-10 | Z124 | Secondary single screen mode activation through menu option |
| US11234235B2 (en) | 2019-04-30 | 2022-01-25 | Bank Of America Corporation | Resource distribution hub generation on a mobile device |
| US11196737B2 (en) | 2019-04-30 | 2021-12-07 | Bank Of America Corporation | System for secondary authentication via contactless distribution of dynamic resources |
| US10998937B2 (en) | 2019-04-30 | 2021-05-04 | Bank Of America Corporation | Embedded tag for resource distribution |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4575797A (en) * | 1981-05-22 | 1986-03-11 | Data General Corporation | Digital data processing system incorporating object-based addressing and capable of executing instructions belonging to several instruction sets |
| JPH06105435B2 (en) * | 1985-10-25 | 1994-12-21 | 株式会社日立製作所 | Storage management mechanism by information processing device |
| NL8600028A (en) * | 1986-01-09 | 1987-08-03 | Philips Nv | METHOD AND APPARATUS FOR SORTING OBJECTS INCLUDING A PARAMETER ACCORDING TO THE VALUE OF THIS PARAMETER |
| US4885717A (en) * | 1986-09-25 | 1989-12-05 | Tektronix, Inc. | System for graphically representing operation of object-oriented programs |
| JPS647231A (en) * | 1987-06-30 | 1989-01-11 | Toshiba Corp | Parallel processing device for object directional system |
| US5226161A (en) * | 1987-08-21 | 1993-07-06 | Wang Laboratories, Inc. | Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data types |
| US5261080A (en) * | 1987-08-21 | 1993-11-09 | Wang Laboratories, Inc. | Matchmaker for assisting and executing the providing and conversion of data between objects in a data processing system storing data in typed objects having different data formats |
| US5079695A (en) * | 1988-04-25 | 1992-01-07 | Hewlett-Packard Company | Object management facility which includes a snapshot facility for providing data transfer between two objects |
| US4953080A (en) * | 1988-04-25 | 1990-08-28 | Hewlett-Packard Company | Object management facility for maintaining data in a computer system |
| US5058185A (en) * | 1988-06-27 | 1991-10-15 | International Business Machines Corporation | Object management and delivery system having multiple object-resolution capability |
| US4937760A (en) * | 1988-09-19 | 1990-06-26 | International Business Machines Corporation | Method for sharing common values implicitly among communicating generative objects |
| US4989132A (en) * | 1988-10-24 | 1991-01-29 | Eastman Kodak Company | Object-oriented, logic, and database programming tool with garbage collection |
| US5057996A (en) * | 1989-06-29 | 1991-10-15 | Digital Equipment Corporation | Waitable object creation system and method in an object based computer operating system |
| US5136712A (en) * | 1989-06-29 | 1992-08-04 | Digital Equipment Corporation | Temporary object handling system and method in an object based computer operating system |
| US5129084A (en) * | 1989-06-29 | 1992-07-07 | Digital Equipment Corporation | Object container transfer system and method in an object based computer operating system |
| US5313629A (en) * | 1989-10-23 | 1994-05-17 | International Business Machines Corporation | Unit of work for preserving data integrity of a data-base by creating in memory a copy of all objects which are to be processed together |
| US5093914A (en) * | 1989-12-15 | 1992-03-03 | At&T Bell Laboratories | Method of controlling the execution of object-oriented programs |
| US5157777A (en) * | 1989-12-22 | 1992-10-20 | Intel Corporation | Synchronous communication between execution environments in a data processing system employing an object-oriented memory protection mechanism |
| US5075845A (en) * | 1989-12-22 | 1991-12-24 | Intel Corporation | Type management and control in an object oriented memory protection mechanism |
| AU628264B2 (en) * | 1990-08-14 | 1992-09-10 | Oracle International Corporation | Methods and apparatus for providing a client interface to an object-oriented invocation of an application |
| US5265206A (en) * | 1990-10-23 | 1993-11-23 | International Business Machines Corporation | System and method for implementing a messenger and object manager in an object oriented programming environment |
| JPH04182739A (en) * | 1990-11-16 | 1992-06-30 | Toshiba Corp | Message communication system between objects |
| DE69228621T2 (en) * | 1991-02-25 | 1999-07-22 | Hewlett Packard Co | Object-oriented distributed computer system |
| US5303375A (en) * | 1991-04-26 | 1994-04-12 | Hewlett-Packard Company | System and method for facilitating selection of running functional process in object-oriented environments |
| US5287447A (en) * | 1991-06-28 | 1994-02-15 | International Business Machines Corporation | Method and system for providing container object attributes to a non-container object |
-
1992
- 1992-10-06 US US07/957,339 patent/US5396630A/en not_active Expired - Fee Related
-
1993
- 1993-06-15 CA CA002098417A patent/CA2098417C/en not_active Expired - Fee Related
- 1993-08-13 JP JP5220511A patent/JP2572531B2/en not_active Expired - Lifetime
- 1993-08-19 EP EP93306582A patent/EP0592091A2/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| EP0592091A2 (en) | 1994-04-13 |
| JPH07141206A (en) | 1995-06-02 |
| CA2098417A1 (en) | 1994-04-07 |
| EP0592091A3 (en) | 1994-08-31 |
| JP2572531B2 (en) | 1997-01-16 |
| US5396630A (en) | 1995-03-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2098417C (en) | Method and system for project management across process boundaries in a data processing system | |
| US5530905A (en) | Temporary state preservation for a distributed file service which purges virtual circuit control information after expiration of time limit of inactivity | |
| EP0501610B1 (en) | Object oriented distributed computing system | |
| US5748897A (en) | Apparatus and method for operating an aggregation of server computers using a dual-role proxy server computer | |
| US5280627A (en) | Remote bootstrapping a node over communication link by initially requesting remote storage access program which emulates local disk to load other programs | |
| US5377350A (en) | System for cooperative communication between local object managers to provide verification for the performance of remote calls by object messages | |
| US5818448A (en) | Apparatus and method for identifying server computer aggregation topologies | |
| US7246167B2 (en) | Communication multiplexor using listener process to detect newly active client connections and passes to dispatcher processes for handling the connections | |
| US20020062356A1 (en) | Method and apparatus for communication of message data | |
| EP0536073A2 (en) | Method and process for interprocess communication using named pipes | |
| CA2171815A1 (en) | Method and apparatus for managing connections for communication among objects in a distributed object system | |
| CN108063813B (en) | Method and system for parallelizing password service network in cluster environment | |
| EP0954918B1 (en) | System and method for communications and process management in a distributed telecommunications switch | |
| US5535334A (en) | Fault-tolerant system-to-system communications system and method utilizing multiple communications methods to transfer a single message | |
| US10013293B2 (en) | Queueing messages related by affinity set | |
| CN109194589B (en) | MDC (media data center) implementation method and device | |
| US6957427B1 (en) | Remote object activation in a distributed system | |
| EP1088422B1 (en) | A telecommunication controller messaging system | |
| US7103889B2 (en) | Method, system, and article of manufacture for agent processing | |
| Akkoyunlu et al. | Interprocess communication facilities for network operating systems | |
| CN112667419A (en) | Multi-process communication method based on client server model | |
| Zwaenepoel et al. | Perseus: Retrospective on a portable operating system | |
| Goscinski et al. | Message passing and RPC-based interprocess communication mechanisms in the RHODOS microkernel | |
| CN114356602A (en) | RPC communication method based on ARINC653 partition | |
| KR100311223B1 (en) | Method for transmitting and receiving message between processors based on shared message queue |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |