2

How do I get WCF to generate a list or IEnumerable of proxies to the actual object? I'm doing this in a self-hosted application.

Here's what I have:

public interface IRemoteControlGroup {
     List<IRemoteControl> GetInstances();
}

public class RemoteControlGroupImpl : IRemoteControlGroup {
    public List<IRemoteControl> GetInstances()
    {
        System.Console.Error.WriteLine("Called GetInstances()");
        List<IRemoteControl> list = new List<IRemoteControl>();
        // implementation detail: get this list of IRemoteControl objects
        return list;
    }
}

public interface IRemoteControl {
     void Stop();
     void Start();
     void GetPID();
}

public class RemoteControlImpl : IRemoteControl {
     // actual implementation
}

I want WCF to:

  • Offer a service, RemoteControlGroupImpl, defined by the contract on IRemoteControlGroup.
  • Give me a List<IRemoteControl> when IRemoteControlGroup.GetInstances() is called (on the client), where elements of the list are proxies that implement IRemoteControl (by calling the host's actual IRemoteControl objects).

I don't want WCF to push actual RemoteControlImpl objects through the wire; I just want it to push proxies that implement IRemoteControl. RemoteControlImpl objects actually contain handles to the local system (Window handles, because our apps only expose a GUI interface), and therefore, are not serializable. The number of elements returned by GetInstance() can vary.

I found this article, which sounds like what I want. Kind of. But it doesn't tell me how to do this in code; just in the configuration. It also doesn't quite describe what I want. The entry point for the service delivers a proxy; but I want the entry point for my service to deliver a list of proxies.

user314104
  • 1,528
  • 14
  • 31
  • Caveats welcome for WSHttpBinding/NetTcpBinding and sessions. I'm new to all this WCF technology. – user314104 Feb 20 '12 at 02:24
  • 1
    If you're new, then you shouldn't be going so far from the examples you've seen. WCF is not .NET Remoting. – John Saunders Feb 20 '12 at 02:48
  • Thanks. Unfortunately, there's the usual management demand of "future-proofing" our technology, so while I'd be happy to use .NET Remoting or CORBA, I don't have the clout to suggest anything besides WCF. – user314104 Feb 20 '12 at 03:16
  • No, I was saying you're trying to do something that makes sense in .NET Remoting, but not in WCF. It' s a _good_ thing you're not using Remoting, which has been replaced by WCF. – John Saunders Feb 20 '12 at 03:17
  • Ah. Do you have any recommendations to accomplish the task at hand, then? – user314104 Feb 20 '12 at 03:30
  • Yes. Get over it. Don't even _think_ in terms of passing proxies around. – John Saunders Feb 20 '12 at 06:54

1 Answers1

0

As @John Saunders has pointed out you need to rethink your approach. I can think of a couple of general approaches that may be useful depending on what is driving your 'multiple' instances.

1) If they are driven from outside the application (i.e. the list of available IRemoteControl targets does not change dynamically at run time), then you could expose the same contract via multiple endpoints. E.g. http://localhost/remotecontrol.svc/instance1, http://localhost/remotecontrol.svc/instance2, etc. The availability of the different endpoints can be publicised via your WSDL.

2) If the multiple targets are dynamic then the simplest approach would be to redefine your contract:

public interface IRemoteControlGroup {
     List<string> GetInstances();
     void Stop(string instanceId);
     void Start(string instanceId);
     void GetPID(string instanceId);
}

Internally your service would maintain a dictionary of available IRemoteControl objects, keyed by InstanceId and simply route the incoming operation to the target instance.

Phil Degenhardt
  • 7,215
  • 3
  • 35
  • 46
  • Hi, thanks for the response. What's the rationale for me to "need to rethink [my] approach?" Does WCF simply not support a paradigm, or is there a design reason? – user314104 Feb 21 '12 at 00:30
  • @John Saunders has already clearly explained that. I was under the impression ('Ah. Do you have any recommendations to accomplish the task at hand, then?') the discussion had moved on to suggestions of workable approaches using WCF. – Phil Degenhardt Feb 21 '12 at 02:58
  • I must not be reading it right then. Could you please enlighten me? The closest thing I see for an explanation of that is that it "makes sense in .NET Remoting, but not in WCF." Does that imply that this usage model is a rational omission in WCF ("You can't do that in WCF."), or does that imply that it's functionality that exists, but shouldn't be used ("Don't use this because...")? – user314104 Feb 21 '12 at 13:13
  • 2
    WCF has replaced .Net remoting. Passing proxies around (a .Net remoting approach) is no longer considered good form and is not supported in WCF. (The document you refer to was based on pre-release software). WCF is a big improvement on .Net remoting, providing better performance AND interoperability but you need to forget the concept of passing proxies around. – Phil Degenhardt Feb 21 '12 at 13:56