Creative use of MarshalByRefObject

Question

I've been banging my head trying to figure some things out. So, I'm looking for advice and research material (via links). Here's the scenario:

We have a library (say, CommonLib) that contains resources needed by several other applications (say, AppA, AppB, AppC, and so on...). Now, the way this is currently working is AppA instances, checks to see if the specific port is available. If it isn't, then it kicks CommonLib ("Hey, wake up") and the service is started. Then AppA is happy and off we go.

Now, I've done a lot of research on Remoting.Channels and I've come to the conclusion that I'm starting an application built on a technology that is considered 'legacy'. Well...I don't like that. Honestly, WCF is way more overhead than we require and not fully implemented in Mono. We are targeting multi-platform compatibility (Windows, Mono, Linux) so we are researching all options.

The idea of remoting started, in the first place, because we wanted CommonLib to be a guaranteed single instance (as I understand it, a singleton is pretty much only guaranteed to be a singleton within a given AppDomain - feel free to correct me if I'm wrong). Anyway, I realized the power of remoting and decided to begin some experimental implementation. I have been successful in my initial use of the MarshalByRefObject. But, I'm concerned about the continued implementation of this legacy technology.

So, with all this...I am considering how I can implement CommonLib (as a host application) and, without remoting, implement MarshalByRefObject through Stream, standard TCP Socket, or some other way. What I'm thinking is, instead of instancing AppA to get CommonLib running, just implement CommonLib as the base app. Then, you select what app (really just a 'hosted' .dll) you want instanced within CommonLib. CommonLib would then load that .dll into the CommonLib framework along with whatever custom controls that hosted app uses. Along with this idea, I'd forego the requirement (for now) that CommonLib must be a genuine singleton.

So...that is a detail of our scenario. Again, my question is really 2 parts: (a) What technology(ies) should I research, and (b) Do I need to be concerned with the legacy status of the remoting technology?

Any other advice, comments, or questions are more than welcome.

UPDATE 1: I'm starting off with this snippet. This will allow me to load a file (or script) with a list of apps (or plug-ins) that have been installed. I can create this file as Xml or Binary formatted. When a new app is installed, the file & path can be added. Hmmm...I don't necessarily need to use MarshalByRefObject.

Answer 1

I'm not sure that .NET Remoting is obsoleted by WCF. I think they have somewhat different use cases; WCF (deliberately) has no concept of "marshal by reference" because it's designed for distributed and (relatively) loosely coupled apps that might need to avoid chatty protocols due to latency etc. If your components are naturally tightly coupled, latency will be low but performance needs to be high, preserving rich .NET types is important, etc. then Remoting may still be a good fit. Anyway, I wouldn't worry about being "legacy", "legacy" technologies at least on Windows/.NET have a way of staying around for quite some time if they get a decent amount of usage. Remoting still exists in the latest (4.0) version of .NET.

None of this is meant as a claim that Remoting necessarily is the best fit for your situation ...

Answer 2

While WCF may not be as complete in Mono, Mono 2.6 provides everything required for silverlight / moonlight, so a WCF-based implementation should be perfectly feasible. As long as you don't try anything exotic (different transports, inspectors etc) it should be more than sufficient to provide an RPC stack that is reliable between windows / mono / etc.

The key difference between WCF and remoting is in usage - remoting is based abound an object that pretends to be at a different end, where-as WCF is based around a service; the point being you should base your interactions around discrete methods (rather than accessing properties etc) - this also has the advantage of helping making it explicit when you are crossing the boundary.

Another option would be to write a very basic socket server; very lightweight, and you could use something like protobuf-net to provide a portable (cross-platform) serializer implementation (you shouldn't really trust BinaryFormatter between the two - it is... flakey).

In short - I wouldn't build around MarshalByRefObject at all; I would write a service layer, something like:

interface IMyService {
    void Method1();
    int Method2(string s);
}

and abstract these details away from the caller. If you end up using WCF, then that is all you need; and for existing remoting support I would write an IMyService implementation that encapsulates (privately) the whole MarshalByRefObject story. Ditto if I wrote a socket server.