Inter process communication with events and delegates
Architecture Design
The Remote Object Process Requires A Reference To Each Class That Subscribe To The Event. In order for a remote server object to wire up an event (or register a callback) with a client, the server object needs to know a little bit about the client. This requires the server object to have a reference to each client that will subscribe to its events. This seems like a huge limitation for remote events. Imagine creating a server object to be used over remoting from many different types of client objects, and being required to add a reference to each of these client objects in the server object. Additionally, we may want to instantiate remote objects from within a client executable, and have the executable handle the remote event. Unfortunately, we cant add an executable as a reference to our server object.
So, having a client executable subscribe to remote objects events might seem impossible. However, there is a good way to get around this limitation with the use of a small event helper class, or event shim.
The idea is to create a small class that has a basic purpose of subscribing to remote objects events and then raising its own event. At first, this might seem like we are only postponing our event problem by propagating it up one level, but were really not. Remember, the real problem is our server object needs a reference to the client that will be subscribing to its event.
By placing a reference to this small event helper class in both the client and server assemblies, we circumvent the problem.
The server can see the object that will be subscribing to its event (the event helper) so it will know how to wire up the delegate callback for the event, and because our client has a reference to this small helper object it is able to subscribe to events on it.
Architecture Design
The Remote Object Process Requires A Reference To Each Class That Subscribe To The Event. In order for a remote server object to wire up an event (or register a callback) with a client, the server object needs to know a little bit about the client. This requires the server object to have a reference to each client that will subscribe to its events. This seems like a huge limitation for remote events. Imagine creating a server object to be used over remoting from many different types of client objects, and being required to add a reference to each of these client objects in the server object. Additionally, we may want to instantiate remote objects from within a client executable, and have the executable handle the remote event. Unfortunately, we cant add an executable as a reference to our server object.
So, having a client executable subscribe to remote objects events might seem impossible. However, there is a good way to get around this limitation with the use of a small event helper class, or event shim.
The idea is to create a small class that has a basic purpose of subscribing to remote objects events and then raising its own event. At first, this might seem like we are only postponing our event problem by propagating it up one level, but were really not. Remember, the real problem is our server object needs a reference to the client that will be subscribing to its event.
By placing a reference to this small event helper class in both the client and server assemblies, we circumvent the problem.
The server can see the object that will be subscribing to its event (the event helper) so it will know how to wire up the delegate callback for the event, and because our client has a reference to this small helper object it is able to subscribe to events on it.
IPC Event Design
No comments:
Post a Comment