Future Improvements

Add support for serialization of generics. One caveat is that empty generics may not be able to be supported due to type erasure on the Java side, and hence not being able to determine the element types of generics when serializing.
Add support for structs and enums.
Review the event handling when receiving method invocations on the Java side. Currently this has been implemented using the IMethodInvocationReceivedEventHandler interface, whose operation is based on the C# event model. However there may be a more Java-standard way to implement this.
Review the way exceptions are handled in the Java MethodInvocationRemoteReceiver class. Currently exceptions encountered on the receiving thread are defered to the IMethodInvocationReceivedEventHandler member set on the class. Hence the client code is ultimately responsible for implementing the IMethodInvocationReceivedEventHandler class, and handling any received exceptions.
See if there is a more efficient way to implement the ISerializerOperationMap than the current SerializerOperationMap. The current implementation is duplicating the data into 2 Dictionary objects (HashMaps in Java) to facility bi-directional searching. There may be a more efficient way to do this.
Consider the ability to serialize and transport exceptions. Currently if an exception occurred on the receiver side, the sender could be left waiting for a return value which would never come, and would hang.
As the Parameters member of the MethodInvocation object is an array of objects, all parameters must be downcast to their specific type before using. Similarly, the XmlSerializationOperation and XmlDeserializationOperation delegates used in the C# MethodInvocationSerializer class, take in and return generic objects which also creates a requirement for downcasting. This leaves greater potential for bugs which cannot be caught at compile time. Ideally it would be good to redesign this and maybe make greater use of generics (as are used in the IObjectSerializer interface in Java) and reduce the dependence on downcasting.
The XML produced by serializing array types using the MethodInvocationSerializer class produces repeated XML tags. For example, the data type of the array elements is repeated in the XML of every element...
<Data> <ElementDataType>integer</ElementDataType> <Element> <DataType>integer</DataType> <Data>123</Data> </Element> <Element> <DataType>integer</DataType> <Data>-456</Data> </Element> </Data>

This was a conscious design decision to allow the code which serialized and deserialzed individual objects to be reused to serialize arrays of the same objects. However the expense is more verbose XML, and it would be good to somehow improve this.
Consider changing the size header in the TcpRemoteSender and TcpRemoteReceiver message format to a 4 byte integer (rather than 8 byte long). In Java, the contents of the message are written into a ByteBuffer which cannot be allocated to greater than the size of an integer.
Add checks in the constructors for TcpRemoteSender and TcpRemoteReceiver to verify that the supplied port numbers are valid (i.e. between 1 and 65535).