Custom .NET Remoting sinks should enhance the transport protocol, but should not normally provide application-specific functionality. Or to rephrase it: you should not implement business logic in custom sinks. The reason is that this would tie your business logic code to the transport protocol you are using.

Experience shows that business applications outlive their initial environments. In my consulting practice, I have seen several applications developed with VB4 for example, then ported to VB5, then to VB6. Subsequently, some parts have been ported to VB .NET, but some parts have simply been wrapped as COM DLLs to expose their functionality to .NET and Web Services applications. These pieces of code have definitely outlived their initial environments.

If you therefore tie your business logic code to some side effects of your custom sinks, you'll make it harder for your code to live without the .NET Remoting framework. However, this might become critical as in the future you might want to expose the same components via Web Services, or by using the upcoming stack of Indigo technologies.

All of these alternative protocols also have means of extensibility. This means you would not just have to port your business logic (which will usually be a fairly trivial task), but also your custom sinks. The latter might prove harder, as the extensibility models of these other technologies are completely different.

So, to summarize: custom .NET Remoting sinks are a great means to enhance the distributed application protocol used in your application. However, they should in most cases not be used to create side effects that unnecessarily tie your business logic code to the .NET Remoting framework. If you decide that it makes sense for your project to do this nevertheless, you have to take into account that migrating your code might be more difficult in the future.

Summary

In this chapter you have seen how you can leverage the .NET Remoting framework's extensibility. You should now be able to apply the internals shown in Chapters 11 and 12 to extend and customize the .NET Remoting programming model to suit your needs.

You now know the differences between IMessageSink, which is used before the message reaches the client-side formatter, and IClientChannelSink, which is used after the serialization of the IMessage object. You know that you can add properties to the IMessage object's LogicalCallContext to pass it to the server, where it can be read by an IServerChannelSink, and you can also encrypt or compress a request by using a combination of IClientChannelSinks and IServerChannelSinks.

You also learned how sink providers are developed, and that a client-side IMessageSink has to be created by an IClientChannelSinkProvider as well and therefore has to implement the IClientChannelSink's methods. Finally, you read about custom proxies, which allow you to implement additional functionality before the message reaches the chain of sinks.

In the next chapter, you get a chance to use the knowledge gained here to implement a complete transport channel from scratch.