Designing Servers

This chapter covered the basics of creating and distributing COM servers with Visual Basic. You must first decide whether to package your coclasses in an in-process server or an out-of-process server. The way you package your code affects your server's performance, robustness, and security. Many distributed application designs require that your objects be deployed in an out-of-process server. However, many sophisticated run-time environments, such as MTS, provide a surrogate process, which means that you still distribute your code in an ActiveX DLL.

Visual Basic builds a lot of support into your server automatically. Your job is to concentrate on how to expose things through the type library and how to provide an implementation for the functionality you expose. It is important to understand all the issues surrounding component versioning. As you have seen, you have the choice of two approaches for extending your objects. There is also a huge difference between versioning for automation clients and for clients that use custom vTable binding.

This chapter also exposed you to the important issues of raising and handling errors. It's comforting that Visual Basic provides a transparent mapping on top of COM exceptions. Visual Basic objects and clients can participate in exception handling with components that are written in other languages.

The next chapter explores approaches to interface design and describes their effect on maintainability and extensibility. It also takes an in-depth look at designing interfaces for out-of-process servers. You'll see that the overhead of the proxy/stub layer has a profound effect on how you design a remote interface. Many designs that are acceptable in a classic object-oriented programming sense must be adjusted to minimize expensive round-trips to the server.