Team LiB
Previous Section Next Section

.NET Remoting in the Enterprise World

When you design your enterprise application, you need to consider many issues, as you have discovered, and decide how your system architecture should look. The communication between the different layers in your enterprise application and the communication between different enterprise applications and services can be done in two different ways—either as Web services or as remote objects.

All of our real-life solutions so far have usedWeb services by default for exposing functionality to other systems and to retrieve information, mainly because they are simpler to implement and use and they are not limited to a consumer that needs the complete framework installed (as is the result when using .NET Remoting). Another important aspect is that a Web service client proxy can be invoked from code running in a sandbox under the default security policy.

The .NET Remoting system provides you with functionality to activate objects, control the lifetime of each object, and transport messages to and from the client and the server using communication channels. Communication channels are the items that transport the data between the remote object and the server. The data that is sent via communication channels are serialized using the native .NET serialization formatters, such as SOAPFormatter and the BinaryFormatter. The data that is sent between the client and the server is transmitted over either TCP or HTTP.

Note 

Serialization is a process by which the state of an object is stored on disk or transferred on a network. Deserialization is the reverse—the incoming byte stream is converted back into an object. It is possible to choose the serialization type independently from the transport type. For example, an HTTPChannel can serialize data with the BinaryFormatter.

To achieve the best performance, you should use the BinaryFormatter together with the TCP transport protocol. Where you need interoperability with remote systems, the SOAPFormatter is the preferred choice. Even if the best performance is achieved by using the BinaryFormatter together with the TCP transport protocol, we recommend using Web services with the SOAPFormatter and HTTP, because they are not so complex and their output is pure XML, which is supported on all platforms.

The .NET Remoting Architecture

To be able to choose between using Web services and .NET Remoting objects, you need to know how .NET Remoting works. To communicate between a client and a server object in .NET Remoting, you need to use object references of the server object in the client application.

When you create a server object in the client application, you receive a reference to a server object via .NET Remoting. You can then use the object as a traditional local object—similar to how you use Web services via SOAP.

Remotable objects can be exposed in two different ways: marshal-by-value or marshal-by-reference.

Marshal-by-value objects are server objects defined as Serializable and implementing the ISerializable interface. When a client calls a method of this object, the Remoting system creates a copy of the server object and passes back the whole object to the client. The client can then work with the object locally and thereby avoid expensive round-trips over the network and application boundaries.

Note 

When choosing the marshal-by-value approach, remember that some types of functionality cannot be done in the client process. For instance, a server object working with files will likely fail since the resource pointers to the file system are application domain–specific and the pointers the copied object receives from the server are not the same in the client process.

If you have a large server object with many properties and methods, it is not suitable to use the marshal-by-value approach. Instead, you can create a small remotable object that can be published or copied to the client application. This small remotable object makes a direct call to the larger nonremotable object on the server.

The other way to expose a remote object is via marshal-by-reference. Instead of copying the object to the client process, a proxy object is returned to the caller by the .NET Remoting infrastructure. This proxy object contains references to all the methods and properties in the real server object. When you call a method on your proxy object, the request is encoded and serialized to a message by using the preferred techniques and sends the message to the server. When the server receives the message, it traverses back to an object call and executes on the server. Figure 5-20 shows the flow between the client proxy and the real server object when using the marshal-by-reference approach.

Click To expand
Figure 5-20: The message flow between the client proxy and the server object
Note 

.NET Remoting is quite clever. If the marshal-by-value object exists in the same application domain as the client, no marshaling will take place. This is the same for the marshal-by-reference object if it is in the same application domain as the client. In this case, a direct reference is returned to the client instead of a -reference to the proxy object.

When you are working with an enterprise application, communication over application domains will likely occur. (An application domain exists between two different applications or between two machines, for instance.) This will happen when you split your enterprise application layers and place them on different servers (Web server, application server, and data server). To be able to choose the right technology, Web service or .NET Remoting, for your enterprise application, you need to know more about the communication channel between the client and the server when you use .NET Remoting.

Channels make it possible for a client application to send messages to another application running in a different application domain, process, or computer. Channels work with transport protocols such as TCP, HTTP, and others to send messages. Nowadays developers mainly work with TCP and HTTP as transport protocols for channels. A channel works as the message carrier between the client and the server and converts the method call into the selected encoding such as binary format or XML. Choosing between TCP- or HTTP-based channels depends on which features of the two you need to use. The HTTPChannel transports the messages to and from the client by using the HTTP transport protocol. It also uses the SOAPFormatter by default to serialize the method call before it is transferred.

The maximum number of channels that can be simultaneously opened to a given server is configurable via the clientConnectionLimit attribute in the application configuration file. By default two channels are allowed. All channels that a process has registered are unregistered automatically when the process terminates.

The TCPChannel uses TCP as its transport protocol. It also uses, by default, the BinaryFormatter class to serialize and deserialize messages. One new connection for each client call is created. The connections are closed if they remain inactive for 15 to 20 seconds.

Choosing .NET Remoting Objects or Web Services

So how do you decide when to use Web services and when to use .NET Remoting? It is not possible to give a clear answer that will suit all solutions. If you have a homogenous environment with machines that all run .NET Framework, and you need the extra performance boost the use of .NET Remoting currently gives you compared to Web services, you should use the .NET Remoting functionality. .NET Remoting gives you a traditional distributed object model with full support of CLR type fidelity. However, when you use .NET Remoting, try to host the objects in IIS to take advantage of the process life cycle management and the security support found in IIS. In a homogenous environment with a .NET client, you can use the BinaryFormatter instead of the SOAPFormatter to achieve better performance (no serialization occurs).

Though both the .NET Remoting infrastructure and Web services can enable cross-process communication, each is designed to benefit a different target audience. Web services provide a simple programming model and a wider reach because they do not require the .NET Framework on the client machine. .NET Remoting provides a more complex programming model because the complete .NET Framework is supported. In the described enterprise application architecture, we are mainly working with Web services in our examples due to their simplicity and the portability to other platforms.


Team LiB
Previous Section Next Section