9.1 Channels

only for RuBoard

Channels are objects that help transport messages between objects in a remoting relationship. The .NET Framework comes configured with two channels: one that uses TCP as the transport protocol and another that uses HTTP. Each uses SOAP as its message format, but the TCP channel encodes it into a proprietary binary format, while the HTTP channel uses XML. The HTTP channel is ideal when firewalls must be traversed, but otherwise , it is best to use the TCP channel for its pure speed.

Although .NET is configured to use TCP and HTTP out of the box, the remoting framework is completely extensible. .NET ships with channel objects that implement two of the most popular protocols, but anyone can write a channel using any protocol, and it will plug right into the remoting infrastructure as long as the specifications are adhered to.

9.1.1 Activation Models

Remote objects fall into two major categories: server-activated objects (SAOs) and client-activated objects (CAOs).

SAOs are also referred to as "well-known" objects, probably because no mechanism for object discovery is inherently built into the remoting architecture. Compare this feature to the TCP/IP "well-known ports," which refer to ports such as 25 (SMTP), 80 (HTTP), and 110 (POP3). Clients using well-known objects have a priori knowledge of the object's location.

When a client requests an SAO, it is initially given a proxy object that resembles the object located on the server. However, the object on the server is not created until the first method call is made on the proxy object. When the remote object's lease has expired , garbage collection occurs.

Server-activated objects come in two forms: Singleton or SingleCall. The properties of each are as follows :

Singleton

Regardless of the number of clients, one instance processes every request in a multithreaded fashion. From one call to the next , the actual instance might be different, but at any given time, there is only one instance. State is shared between all clients and is maintained between calls. Singletons are marshaled by reference.

SingleCall

SingleCall objects are activated once per request. Thus, for every method called (by every client), a new instance is created on the server to process each request. As a result, SingleCall objects do not maintain state of any kind between successive calls. SingleCall objects can be marshaled by value (so that the client has a copy of the object) or by reference.

The term marshaling refers to preparing an object to be moved to another application domain.

The choice of whether to use a Singleton or SingleCall object usually involves some compromise between performance and scalability. Singletons are fast because one instance can serve every request. SingleCall objects are inherently slower because a new object is created for every request. However, the object remains active only during the lifetime of the request, so scalability is much higher.

CAOs resemble SAO Singletons in that object state is maintained between calls. The difference is that the state is unique to the particular instance of the object; it is not shared among every instance on every client. Also, when a CAO is activated by the client, an instance of the object is immediately created on the server. The other major difference involves the object's lifetime. With SAOs and CAOs alike, the server determines when a remote object can be garbage collected. However, the CAO can participate in that decision. For instance, if a CAO goes out of scope on the client, it will probably be garbage collected right then. The SAO is not freed until its lease expiresa topic that will be discussed in Section 9.4.1.1 later in this chapter.

only for RuBoard