DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
The limitations of this approach are that as long as clients are up and running and registered with the connection point they will be informed of the event via their sink. If they have been shut down or have temporarily failed, they will never know. The event isnt stored for them. This means that if our customer, for example, was unfortunate enough to have gone for lunch when the share price rose to an all-time high and the process written to handle the share price event wasnt running, he or she would never know about the event.
We will be seeing in a later chapter that Microsofts message queuing technology gets around some of these problems and provides an alternative way of broadcasting events that need to be safely delivered to all interested clients.
The additional communication services provided within DCOM in addition to the ones provided by the MS RPC and Cedar mechanisms are triggering, context bridging, and broadcast/multicast delivery. Context bridging requires no programmer involvementit is automatic and is used to bridge network protocols.
Triggering requires programmer involvement, although the actual triggeringloadingof the server is done by DCOM. I rather wish it needed no programmer involvement as this counting stuff could surely be done by DCOM. Perhaps in the future we will see more automation in this area.
The broadcast/multicast communication service clearly needs programmer involvement because it provides an alternative form of communication to the normal one-to-one communication, which is provided as a default with DCOM. This is a useful service and one which can be used to good effect in certain special cases by the programmer. You may want to look, however, to see how the messaging service works before deciding to use the outgoing interface because MSMQ may provide a more robust means of achieving the same thing.
Previous | Table of Contents | Next |