Summary
This has been a rather long chapter, but you should have gleaned from this chapter the following points:
Remote objects are easy to build and easy to use.
Remoting provides a consistent programming model.
Binary format can transfer any .NET object.
SOAP allows for interoperability between .NET and non-.NET platforms.
SingleCall, Singleton, and Client-Activated models allow for much flexibility in designing your remoting service.
Synchronous and asynchronous calls allow for a responsive application that scales easily.
Remoting allows the programmer to extend the channel and formatters. It is possible to hook into the remoting services at almost any level. You have seen two examples of how to hook into IServerChannelSink and IClientChannelSink. You can hook into the remoting services at other points by inserting your custom processing into other parts of the sink chain.
Note
The SDK has additional samples that show how to hook into the transport layer so that you can transport data via another medium such as a named pipe. The SDK also has samples on how to create your own proxy and how to dynamically modify the proxy.
Remoting allows the user to use IIS as a host or server. A direct host can be run as a service or from the command line, or you can allow IIS to be a host for a remoting service that you want to provide.