What's the best way to return an interface (and object instance) to a remote caller, having said Object method calls run in the hosting app?

Question

I'm prototyping a C#/.NET client/server environment in which I need to return an object instance (already constructed with data the client needs- avoiding the exposure of server-side (read: internal database details) that the calling code needs to perform "remote" method calls on said instance.

When the client code calls methods on this object, they should run in the context of the Host process.

Would using .NET remoting, WCF, or..? be appropriate for this task? And more importantly, can anybody provide an example of this or point me to any relevant articles regarding how this is done?

Interface Example (WCF decorations included):

[ServiceContract(SessionMode = SessionMode.Required)]
public interface IGroupContract
{
    [OperationContract]
    GroupInfo BoundToGroup();

    [OperationContract]
    Group GetEntryInfo();

    [OperationContract]
    Boolean RebindGroup(GroupInfo NewGroup);
}

[ServiceContract]
public interface IClientDatabase {
{
    [OperationContract]
    System.String[] FetchClsidList();

    [OperationContract]
    IGroupContract Create(System.String Name, System.String Group);

    [OperationContract]
    System.Boolean Delete(IGroupContract Grp);
}

Answer 1

Yes, .NET remoting is A way to do it.

Here is a good tutorial:
http://www.codeproject.com/KB/IP/remotingchatsample.aspx

Answer 2

If the object returned contains just properties, then you don't really want to use .NET remoting if you can avoid it. Plain old SOAP or WCF would work better.

Answer 3

I would avoid .NET Remoting. It's an older technology (personally, I would call it legacy) and it is very difficult to deal with in both development and deployment. You should definitely stick with WCF. There are some good introductory videos and sample applications for WCF here.

Edit: Per some of the discussions. I think you need to start looking at the problem in more of a service oriented way. The server will expose services that the client can take advantage of. The client has no interest in the implementation of these services. It just knows that it calls a service and some unit of work gets done (this can be course or fine depending on your design).

Objects on the client can easily abstract away the service calls, so you don't have to worry about not having a clean object model on the client and you can receive messages and events back from the server as well.

One of the best ways to accomplish a more robust client-server architecture using WCF and SOA is a publish-subscribe message bus. Here's a working implementation of a [pub-sub framework][2]. This will allow your client to register for and receive notifications back from the service. That completes the loop and gives you the full feel of .NET Remoting, but without all the headaches (and there are many). The benefit of WCF in a design like this is that all the pluming is abstracted away, that is any binding, channel and set of endpoints can be used and the code on the client and code on the server don't have to change.

Answer 4

Defiantly avoid remoting, before WCF there were cases that remoting made sence but now there is no excuse for using that "legacy" technology. WCF gives you a lot more flexibility and is also much easier to maintain and work with.

here is a sample calculator app done in WCF which is hosted within a windows application

http://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic3

Answer 5

Well, fine. Since everyone thinks that Remoting is so 2008, here's a WCF example. This sample demonstrates how to use WCF (Windows Communication Foundation) to develop a typical client server application using TCP/IP binding.

http://www.dotnetspider.com/resources/19314-Client-server-sample-using-WCF-net-tcp-binding.aspx

...and this article from Microsoft has details on both approaches, and why you would use one over the other It also explains how one would export an object using a WCF service and have the methods run of said object run on the server:

From .NET Remoting to the Windows Communication Foundation (WCF)
http://msdn.microsoft.com/en-us/library/aa730857(VS.80).aspx#netremotewcf_topic6

Answer 6

Migrating .NET Remoting to WCF (and even ASMX!) (from the Mattavis Weblog)

Summary:

1. Following the .NET Remoting guidance enables quick and painless upgrade to WCF
2. A single interface can be decorated to support .NET Remoting, WCF and ASMX
3. The service implementation does not need to change at all to support all three platforms
4. Wrapping the client connection code in a proxy allows developers to switch between .NET Remoting, WCF and ASMX on-the-fly

I found this article to have remarkable clarity and insight.

Read on for the details…
http://blogs.msdn.com/mattavis/archive/2005/10/10/479280.aspx

Answer 7

I believe you're correct that WCF does not provide the same concept of distributed object identity that Remoting did. You cannot actually return an object with methods and properties from the server. You cannot call the methods of such an object and have them execute on the server.

So what? That was an implementation detail of one particular technology (Remoting). I know other technologies also have that capability (CORBA, RPC). Again, so what? That has nothing to do with the question of the best way for you to achieve your goals.

If your goal is to use the same .NET types on the client and server, then you can use the NetDataContractSerializer, which serializes the full CLR type name into the XML. See Serialization and Deserialization to learn the differences between this class and the DataContractSerializer.

If your goal is to enable high-performance interaction, then WCF does that: you can use binary over TCP/IP, and can use duplex contracts to allow the service to call back into the clients.

Don't allow the difference in implementation details to fool you into using a technology that has been replaced, and which has no future.

Answer 8

WCF really doesn't seem to want to do what you're looking for. It wants to expose services, not objects. This is clear pretty well throughout the API - you have ServiceContracts that return things that are marked as DataContracts. At no point does the concept of an "object" enter into discussion.

In general, I find it's better to not force APIs into patterns that they don't want to support - use something that wants to do what you want to do in the first place. If you really want to remote objects, .Net Remoting is probably the answer.

Personally, I'd recommend thinking more in terms of messaging, as that usually seems to work better in distributed environments. Distributed objects usually don't seem to work well - see Martin Fowler's First Law of Distributed Objects.