|
|
Remoting, in short, is the replacement technology for Distributed COM (DCOM) in intranet solutions. It allows you to communicate among application domains, processes, and machines. So the question at this point is this: What do you get with Remoting that you didn't get with DCOM? The answer lies in one word: control!
Remoting provides control by allowing you to determine how objects are created, which protocol you will use as a transport, how messages are transferred between the client and server, and the lifetime of objects. That is a lot of control!
Your control of how objects are created specifically refers to whether objects are client-activated or server-activated. This allows you to control the lifetime of the object and who will control the object.
For protocols, you have maximum control in that you may use TCP, HTTP, IPC, or any custom protocol that you choose to write via the open-programming structure of sinks.
Finally, you control the formatting of the messages that are transferred from the client to the server. You have a choice of SOAP, binary formatting, or a custom format that you design.
Now that you have a clear picture of what Remoting is, you may be wondering when Remoting is necessary. Remoting is most effective in an intranet environment where performance is a priority.
There are three parts to Remoting:
Hosting process: Hosts the remoted object and opens a channel that clients may connect to. This could be your executable, IIS, or a service.
Client process: Calls and uses the remoted object.
Remoted object: A DLL that implements the remote object.
When deciding how the remoted object will be made available to clients, you should consider the choices carefully. Each of the following options requires specific design considerations.
Shared DLL: The object is implemented in this shared assembly.
Shared interface: The interface of the remoted object is defined in this assembly, and the implementation is in another assembly.
Shared abstract base class: The base class is defined in this assembly, and another assembly contains the base class in a new derived class.
SoapSuds: This tool is used to connect to a running instance of a remoted object and generates a new assembly with the metadata needed to use the remoted object in a client.
Remoting provides for MarshalByValue objects and MarshalByRefObject objects.
MarshalByValue objects are created on the client, and all calls to these objects run in the same context as the calling client. This means that these types of objects are not really remoted objects. These objects must be marked with the [Serializable] attribute or inherit from the ISerializable interface, so they will be serialized to a specific format and sent in their entirety to the client.
MarshalByRefObject objects are true remoted objects. When you create an instance of one of these objects, a proxy will be created on the client, and all calls will be forwarded to that proxy. The proxy will then create a serialized message that is passed to the server to be processed and run on the server. Any out parameters or return values are then serialized back and returned to the client. There are three types of MarshalByRefObject objects:
Server Activated Object (SAO), SingleCall: These objects are created on calling a method of the remoted object, and then the object is destroyed when that method returns.
Server Activated Object (SAO), Singleton: These objects are created once on the server, and the single instance that is created services all client requests.
Client Activated Objects (CAO): These objects contain state information and are maintained by their lifetime values and reference counts.
|
|