9.5 Designing for Remoting

only for RuBoard

Designing an object that lives in distributed environments almost runs counter to traditional OOP, in which public interfaces are kept lean and mean. Here are some general guidelines for remotable objects:

• Avoid "chatty" objects. These objects contain numerous properties that generate unnecessary traffic over the wire. Remember, each time a property is set, a round-trip on the network occurs.

• Make " chunky " calls. This means passing as much data as possible when making a method call.

• The method on a remote object should be Herculean. Normally, a method performs one specific task. In a remoting situation, a method should perform as many tasks as possible before returning.

• Return as much data as possible from a remote method. When you can, try to use structures containing only value types (but only if you know that boxing and unboxing will be kept to a minimum once the data is across).

The "GC allocations and collections" item in the Performance Monitor tells you how much boxing and unboxing is occurring.

Here are some general guidelines for the various activation models:

• Singletons are ideal for providing and maintaining data that is static or updated very infrequently. The services provided by a Singleton are not specific to any client.

• SingleCall objects are stateless and best used in high-traffic situations (for reasons of scalability) when data is specific to a client and is updated frequently.

• Client-activated objects are used when maintaining state (specific to one client) is necessary.

The ServerInfo class that was used throughout this chapter is very poorly (but purposefully) designed to make a point: objects that will live in a distributed environment should be designed with that environment in mind. ServerInfo was definitely not built with any such consideration.

In Example 9-7, it takes quite a few round-trips on the network to get all of the information because the object must be queried for each distinct piece of information it provides. It's not possible to marshal the current version of ServerInfo by value because the idea is to get machine information at a remote location. What is needed is a way to get all the information at one time and return it to the client in one call.

The idea behind this, of course, is to minimize travel across the wire. There is no reason why ServerInfo could not return all the required information at once. The point emphasized here is to design with distribution in mind. Don't expect to retrofit existing objects for dispersed locales and gain any benefits.

only for RuBoard