What is Method Invocation Remoting?

MethodInvocationRemoting is a framework which allows methods to be invoked remotely between C# and Java.

Method invocations are represented as objects and then serialized and transported from code in the calling language (e.g. Java), before being invoked on the receiving side (e.g. C#). Any return values from invoking the method are then passed back and handled in the calling language.

The object model is based around interfaces and an inversion of control / dependency injection design pattern, so users can easily substitute the provided classes which perform serialization and transport with their own classes.

MethodInvocationRemoting includes interchangeable default transport classes which utilize the file system, Apache ActiveMQ message queuing, or a direct TCP network connection, allowing for persistence, performance, or ease of testing depending on the use case. The default serialization classes convert objects to XML, and provide built-in support for many native data types and single-dimension arrays of these types in C# and Java. Additionally the serialization classes can be easily extended to support serialization of user's custom data types.

Whilst remote method invocation is already available between C# and Java using protocols like web services, MethodInvocationRemoting is lightweight and can be utilized in client code without the need for installation and configuration of a separate server-side application, as is the case with web services. MethodInvocationRemoting also provides bidirectionality (duplex networking), so that methods can be invoked from both the C# and Java sides.

Both the C# and Java projects include extensive unit tests to allow for easier extension and refactoring of the code.

Detailed logging and instrumentation is available from all major classes in MethodInvocationRemoting using the ApplicationLogging and ApplicationMetrics projects. These two projects are decoupled from MethodInvocationRemoting (interaction is through clearly defined interfaces) and are standalone frameworks in their own right with multiple implementations, which could easily be utilized by other client applications and frameworks.


I had developed a simple GUI application based around the MVP (model-view-presenter) design pattern, and demonstrated to colleagues that if the interface between the presenter and model components was well defined, it was simple to put the model behind a web service interface, and allow the application to be easily converted from a standalone desktop application to a client-server or mobile app.

In addition to managing interaction between the model and view components, the presenter in my application was additionally performing error handling, and managing threads to allow the UI to remain responsive during long running tasks. This meant that there was a reasonable amount of presenter code that would need to be duplicated if the model was put behind a web service and the presenter and views were ported to a mobile platform or similar.

My colleague questioned whether it was possible to make the client side of the application even more 'thin', by pushing the presenter functionality to the server side as well. This would mean that the client only had the task of the simple 'painting pixels on the screen' responsibility of the views. The communication between the presenter and model layers in the MVP pattern is unidirectional (i.e. requests are only instigated by the presenter), so it was simple to put the model layer behind a web service which itself is unidirectional. The problem was that the interaction between the view and presenter in MVP is bidirectional (i.e. requests can be instigated by both the view and the presenter). If the presenter was put behind a web service, the view could send requests to the presenter, but the presenter (located behind the unidirectional web service) could not send requests to the view(s).

I initially thought about how the view and presenter layers could be located on physically separate machines, and how methods that were invoked between them could be serialized and sent between the components via a transport medium like a TCP/IP network or message queue. I then realized that if the method invocations were serialized into a platform-independent format like an XML document, it would also be possible to have the view and presenter components written using different languages or technologies. The application was originally written in C#, but I realized that using such a mechanism to serialize and send the method invocations, it would be possible to write the view layer in another language like Java.

I started off trying to write application-specific code to do the serializing and sending of the method invocations, but quickly realized that it would be only slightly more effort to build a reusable framework to do this. This was how work on MethodInvocationRemoting started.