Putting this another way:
"With the exception of earlier TCP/IP RPC implementations, in which you even had to worry about little-endian/big-endian conversions,
all current remoting frameworks support the automatic encoding of simple data types into th echosen transfer format.
The problem starts when you want to pass a copy of an object from server to client. Java RMI and EJB support these requirements, but COM+ for example, did not.
The commonly used serializable objects within COM+ were PropertyBags and ADO Recordsets -- but there was no easy way of passing large object structs around.
In .NET Remoting the encoding/decoding of objects is natively supported.
You just need to mark such objects with the [Serializable] attribute -OR- implement the interface ISerializable and the rest will be taken care of by the framework.
This even allows you to pass your objects cross-platform via XML.
The serialization mechanism marshal simple data types and subobjects (which have to be serializable or exist as remote objects),
and even ensures that circular references (which could result in endless loops when not discovered) don't do any harm.
<sub> -- Ingo Rammer, Advanced .NET Remoting </sub>
Of all the senses I could possibly lose,
It is most often the one called 'common' that gets lost.