In Windows Communication Foundation (WCF), if you want to be able to pass an object with code around a distributed application then you have to compile the receiving end with the interface definition of the remote object.
You wouldn’t ever put a DataContract on a code method because that means all clients that have to use it have to be recompiled if the code in that method is changed. This creates lots of coupling between the server and client side which is not desirable. An even less desirable effect occurs when OO principles are used in distributed computing. Let’s talk about the problems of passing and object by reference first, before we talk about how passing by value can improve the performance of the application.
Passing by Reference
WCF does not support passing by reference because it is an OO principle that, when stretched over a network, does not give efficient solutions. If you pass a pointer to an object residing on the server, then the client would receive a reference to the object that allows it query each class field as it is required. This adds more network overhead with issues like TCP header size (minimum of 20 bytes, read this and time required for ACKs to propagate slowing down the process considerably, especially when lots of member fields must be retrieved. When multiple small member fields are retrieved this way, the size of the actual data is insignificant compared to the packet overhead (format info, destination machine, sequence numbers, TTL and so on). The other disadvantage of passing by reference is the increased coupling between server code and client code. The initial decision to use good OO principles was done because these principles are proven to work, however, solving a problem in a distributed fashion (i.e. involving a network connection) changes the nature of the problem.
Passing by Value
So now that we’ve crapped all over passing by reference… is passing by value any better? Passing objects directly across a network in a distributed application causes a whole bunch of other problems. The first one involves the fact that objects are data and code. How can we pass both to the remote end? Is it even a good idea to pass code between server and client? It’s definitely not good for interoperability and coupling goes through the roof! We are breaking the rules of good object-oriented design. That is why it took so long for RPC to evolve.
Solution? Compile both sides with class Definition
The remote end cannot infer getters and setter from serialised object data. The only way to make the remote end aware of this is to compile both sides, not only the object interface, but also the source code of the class implementation. This is obviously terrible from a design point of view as we are creating strong coupling between the remote and the server. Change any code and everything needs compiling. In addition to that, this approach is not very language independent either. Solution. WCF’s Best Effort Deserialization.
WCF will try to shove the deserialised data into the class the remote end is assigning it to. This class must have the same fields as the incoming data. There is an interoperability issue when .NET’s built in types are serialised.
