IPC for Modular Software Requires a Third Party Connect

Reconfiguration, on-line maintenance, load balancing, and similar operations on complex software require (among other things) dynamic binding of communicating peers, so that modules can be installed and removed in a frame-work of other functional modules. A binding may take the form of TCP/IP protocol connection, remote procedure call server location, shared memory address resolution, or object handle resolution, depending on the underlying communication mechanism. However, the need for abstraction and modularity is independent of the particular IPC mechanism(s) being used. A module should not need to know how it is used (specifically, how it is bound together with other modules to implement a more complex function). Therefore, the bindings between two modules A and B should in general be created and destroyed by a third module C. We call this facility a third party connect. The module C should not have to have any particular relationship (other than authentication) to modules A and B in order to dynamically connect and disconnect them. In particular, it should not have to be one of A and B, be a common ancestor of them, or have an existing binding to them. Similarly, neither A nor B should have to take an active part in establishing or tearing down bindings.