DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
The COM interface functions and COM Library API use specific conventions for error conditions that the client must pass back with the reply. Where the reply is used, the return value, status and error information (for example, a Boolean result of true or false), and a failure/success field must be specified. It is illegal to throw an exception across an interface invocation because errors need to be platform independent.
The key field used in DCOM error reporting is the HRESULT fielda simple 32 bit field that is used by DCOM to report communication errors, RPC errors, and so on. It is used rather than the parameter return values in the interfaces and is structured as follows:
Failover-Is not supported in DCOM. That is, DCOM does not have the ability to actually transfer calls from clients to the same application on another machine if the application on a machine fails, even if the call is mid-process, or to also transfer any connections the application had with other software along with the call. In other words, in true failover, the middleware can transfer the call and the links to the databases the application is using too.
MS RPC, based on the OSFs DCE RPC, is a key and vital piece of technology. It is what puts the D in DCOM; without it there would be no support for distribution.
You rarely see the effects of what MS RPC is doing for you. The handling of sessions, network synchronization, network calls, and data format translation are all handled automatically for you by this piece of clever technology, but you do get the results of one of its servicesthe error handling services. Only here are you actually communicating with MS RPC and using its services directly, and only here is the service not automatic. Rather than thank Microsoft, we should perhaps be thanking the OSF for putting together such a useful piece of code.
Previous | Table of Contents | Next |