Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-11-30
2002-06-11
Maung, Zarni (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S200000, C709S230000, C709S231000, C709S232000, C709S238000, C709S241000, C709S241000
Reexamination Certificate
active
06405266
ABSTRACT:
TECHNICAL FIELD
This invention relates in general to network communications, and in specific to information sharing within a domain of a publication/subscribe communication system.
BACKGROUND
Publication and subscribe (PUB/SUB) is a mechanism for the distribution of information in a computer system or domain. A broker is used to send information to interested parties. An individual would construct a process that would detail the particular types or forms of information that the individual is interested in receiving. The process would then subscribe with the broker to receive such information. Processes that desire or are required to share information, send the information to the broker. The broker then sends the information to subscribed processes. Note that subscribing processes do not have any knowledge of the sending process. Likewise, the sending process does not have any knowledge of the subscribing processes.
A single process of a domain typically includes multiple process objects. Each object may send (or receive) information to (or from) other objects with in the process (intraprocess communications) or may send (or receive) information to (or from) objects from other processes within the domain (interprocess communication). Note that intraprocess communications is typically between objects running in the same address space, whereas interprocess communications is typically between objects running in the different address space.
There are well defined and implemented interprocess PUB/SUB engines in existence today. These engines do well in creating an architecture for sharing information between processes. However, there is little architecture in place in regards to how events are delivered inside the process to the appropriate location. In other words, there are few architectures which allow for message and information sharing between objects within the same process, and the architectures that are available are difficult to use. The most sophisticated is association of a callback method with an event subject or class of events. This is insufficient as it is often the case that multiple objects within a process may be interested in an event type. Current architecture does not allow distribution of the event to these multiple objects, nor is it consistent with any internal information sharing architecture.
Interprocess communications in object oriented code have been performed in a synchronous manner. For example, one form of interprocess communications uses TCP/IP protocol, wherein a TCP/IP server listens for requests from one process to access data in another process. However, with this technique marshaling becomes a factor as the two processes involved in the communication could reside on different machines with different formats. Thus, code would have to be manually written to allow for marshaling and unmarshalling of the communications. Another form is a distributed computing environment remote procedure call (DCE-RPC). This form links the communicating processes together, and thus marshaling is no longer required. Another form is common object request broker architecture (CORBA), which is similar to DCE. However, in, DCE the calling process must know the location of the called process. Whereas, in CORBA, the calling system uses a name server to locate the called procedure. Thus, all of the process must register with the name server for CORBA to operate properly. However, all synchronous communications mechanism suffer the same common problem, i.e. both processes must be alive during communications. Consequently, the system is very fragile system, as a problem with one process will halt operations of the other process.
PUB/SUB systems communicate asynchronously, and thus do not suffer the problems of synchronous communications. PUB/SUB systems use a queuing mechanism for routing information so process A can request information from process B, which may not be alive. The request will be queued until B is alive and can satisfy the request. The PUB/SUB broker knows to forward the request to process B when process B is alive.
Note that the discussion so far is with regards to interprocess communications, and not intraprocess communications. Intraprocess communications is typically performed synchronously, via a direct procedure call, wherein one object directly invokes another object. This call is a local form of the CORBA DCE call.
Therefore, PUB/SUB systems have two different mechanism for accessing remotely located information, one mechanism for intraprocess information (i.e. information that is located with another object in the same process) and another for interprocess information (i.e. information that is located with another object in a different process). Thus, for PUB/SUB systems, every time an object want publish information a different mechanism must be used. This problem is exemplified by the system depicted in FIG.
3
.
FIG. 3
depicts a prior art PUB/SUB system
300
with two processes, process A
301
and process B
302
, that communicate with each other via broker
303
. Process A has two objects, object
1
304
and object
2
305
, and process B has two objects, object
3
306
and object
4
307
. Note that the double headed arrows indicate the bi-directional flow of information between the connected elements. When objects within a process desire to communicate with each other, they use a synchronous mechanism, the internal event application programming interface (API)
308
. This API is a non-standard application specific API usually rewritten by the programmers. The specific nature of the API is a problem, in that upgrades and transportability are difficult, not to mention the costs of the initial creation. When an object desire to communicate with an object located in a different process, a different API must be used. The PUB/SUB API
309
is an asynchronous mechanism that sends information to the broker
303
for publication, via object
310
. Note that this API is actually different depending on the vendor of the broker being used.
Thus, for an object to publish a message, the object must determine if the destination object is with in its process (or uses the same address space) or if the destination object is in a different process (or uses different address space). If the object is local, then the internal event API
308
must be used. Moreover, the internal event API requires that the object know the destination location. If the object is remote, then the PUB/SUB API
309
must be used. Note that location transparency is achieved with PUB/SUB, thus the destination location does not have to be known. However, the vendor of the PUB/SUB API must be known, as it is their specific API that must be used.
For example, suppose object
1
desires to send information message Xa to object
2
and object
4
. Note that the single headed arrows indicate the direction of movement of message Xa in this example. For object
1
to send Xa to object
2
, object would have to use the internal event API
308
, and specify the precise location of object
2
. This would route the message from object
1
to object
2
. For object
1
to send Xa to object
4
, object
1
would have to use the vendor specific PUB/SUB API
309
. This would route the message through the client object
310
to the broker
303
, which would then publish the message to process B via client object
311
and on to object
4
.
Burdening each object of each process with this much information and functionality is troublesome. It makes object communication difficult. Moreover, changes to the system will force changes in the objects, for example use a different PUB/SUB vendor will cause modification to existing objects API communication. Thus, the system is tightly coupled, and subject to more changes. Moreover, if an object wants to send a message to both local and remote objects, then the object must actually send to messages, one using the internal API and a second using the PUB/SUB API. This slows down programming of the system.
Therefore, with the prior art, a different AP is used for synchron
Bass Michael A.
Nguyen Frank T.
El-Hady Nabil
Maung Zarni
LandOfFree
Unified publish and subscribe paradigm for local and remote... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Unified publish and subscribe paradigm for local and remote..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Unified publish and subscribe paradigm for local and remote... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2936648