Hi friends,
Formatters
A formatter is responsible for taking an object and converting it into a form that can be passed over the communication channel. The .NET Framework supplies two formatters:
- The SoapFormatter uses XML-encoded SOAP as the message format.
- The BinaryFormatter uses a native binary representation.
You can use either formatter with both TCP and HTTP channels. Consider the following when choosing a formatter:
- Use the BinaryFormatter for optimized performance. Use the BinaryFormatter for optimum performance. The BinaryFormatter creates a compact binary wire representation for the data passed across the boundary. This reduces the amount of data that needs to be passed.
- Consider Web services before using the SoapFormatter. If you need SOAP for interoperability reasons, consider using Web services ahead of the SoapFormatter with .NET remoting. Web services outperform .NET remoting, when using SOAP-based communication.
MarshalByRef vs. MarshalByValue
This section describes the two kinds of remotable objects:
- Marshal-by-reference (MBR). The state in an MBR object remains where it is and an object reference is passed across the remoting boundary. A proxy is created and used by the client to access the object.
- Marshal-by-value (MBV). The state in an MBV object is copied and passed across the remoting boundary. A new object with identical state is created at the recipient end.
Marshal-by-Reference
Marshal-by-reference (MBR) objects are accessed by using a proxy object in the source application domain. The .NET remoting infrastructure marshals the calls, sends them to the remote application domain, and invokes the call on the actual object.
MBR can result in chatty calls over the network if the object's interface has not been designed efficiently for remote access. Also, the client proxy may throw exceptions if the network connection breaks.
Marshal-by-reference is appropriate in the following situations:
- Use MBR when the object state should stay in the host application domain. If the state of the object is relevant only in the host's application domain, use MBR. For example, if the object is referencing a handle to a file or other source such as a database network connection, use MBR.
You may also want to use MBR when you do not want to serialize and send sensitive data over the network.
- Use MBR when you need to update data frequently on the server. If the data needs to be frequently updated on the server, using a MBV may serve as a costly option. Use MBR to reduce the cost of serializing the whole of the object. The proxy marshals the data to the server's application domain.
- Use MBR when the size of the object is prohibitively large. If the size of the object is prohibitively large, it makes sense to use MBR. In this way, the client can access the object's resource directly from the server with only the most relevant data getting passed over the network.
Marshal-by-Value
Marshal-by-value (MBV) objects declare their marshaling rules, either by implementing their own serialization by implementing the ISerializable interface, or by being marked with the Serializable attribute: Consider the following recommendations for using MBV:
- Use MBV when you need to pass object state to the target application domain. When the state of the object is very lightweight and can easily be passed across application boundaries, use MBV objects. This reduces the lengthy, resource consuming round trips across processes, and application domain boundaries.
- Use MBV when you do not need to update data on the server. MBV objects are appropriate when the data does not need to be updated on the server and needs only to be passed to the client. This can save server resources, network latency, and network bandwidth.
- Use small MBV objects when you need to update data frequently on the server. If you frequently need to update data on the server, use small MBV objects where the complete state of the object is passed to the server. Using MBV reduces the marshaling and unmarshaling overhead associated with MBR, especially where non-blittable types are passed.
Serialization and Marshaling
When you use MBV, the object's state must be serialized into a byte stream and be marshaled from source to destination application domain. Serialization and marshaling costs represent a significant proportion of any .NET remoting communication overhead. Use the following recommendations to reduce this impact:
- Consider using a data facade.
- Marshal data efficiently and prefer primitive types.
- Reduce serialized data by using NonSerialized.
- Prefer the BinaryFormatter.
Consider Using a Data Facade
Consider using a data facade to wrap the most relevant data needed by the client. You can develop a wrapper object, with a coarse-grained interface, to encapsulate and coordinate the functionality of one or more objects that have not been designed for efficient remote access. It provides clients with single interface functionality for multiple business objects.
Alternatively, instead of making a remote call to fetch individual data items, you can fetch a data object by value in a single remote call. When you do that, you operate locally against the locally cached data. This might be sufficient for many scenarios.
In other scenarios, where you need to ultimately update the data on the server, the wrapper object exposes a single method which you call to send the data back to the server.
Marshal Data Efficiently and Prefer Primitive Types
A method call across a remoting boundary is expensive and slow, in comparison to in-process method calls. Make sure that you pass only the data that you need. Avoid passing data that can be simply recalculated.
.NET serialization support makes serializing an object graph very easy by using the Serializable attribute. However, if you overuse this attribute, you ensure that a large amount of extra data is passed when simpler data types would frequently suffice. Try to return value types, such as simple primitive types or structures, first. You should consider using more complex types only if these simple types are not sufficient. A classic example of extreme inefficiency is to return a DataSet that has been populated with a single row, single column value when an integer would do.
Reduce Serialized Data by Using NonSerialized
Serialize only the required data. You can reduce the amount of object state that is serialized by marking specific fields that you do not need to serialize with the NonSerialized attribute as follows.
Code:
[Serializable]
Class MyObject: MarshalByRefObject
{
[NonSerialized]
Private DataSet dt;
}
Note You need to use the NonSerialized attribute on both public and private fields.
Prefer the BinaryFormatter
The BinaryFormatter produces a compact data representation and should be preferred, unless you have a specific requirement for SOAP, in which case you should use Web services. You can use the BinaryFormatter with both the TcpChannel and HttpChannel.
More Information
For more information about improving the serialization performance, see "How To: Improve Serialization Performance" in the "How To" section of this guide.
Source:
http://msdn.microsoft.com/library/en...hapt11_topic15
_____________
Mehdi.
software student.
