.NET Remoting convention

Question

I have a server-side code using .NET Remoting to establish the connection with client. Normally, I understand that using interfaces with objects passed between the client and server is the norm and is a safer alternative, but for the simple communication I am establishing, I do not see the need to go through the trouble of defining the necessary classes and interfaces.

So for the following code, since I'm only returning a string to the client, I don't feel the necessity but some might say otherwise so I'm posting my question here. Should I follow the general convention or stick with the way I'm doing? Also is the code shown below a correct way of establishing a server with remoting?

(Don't ask why I'm using remoting instead of WCF. My boss specifically requested for remoting and I don't know why.)

class HttpServer
{

    [STAThread]
    public static Boolean startService()
    {
        HttpChannel channel = new HttpChannel(80);

        ChannelServices.RegisterChannel(channel);
        Type ddcServerType = Type.GetType("DDCEngine.DDCServer");
        RemotingConfiguration.RegisterWellKnownServiceType(ddcServerType, "DDCServer", WellKnownObjectMode.Singleton);
        return true;
    }
}

public class DDCServer : MarshalByRefObject
{
    public string Hello()
    {
        string r = "hello";
        return r;
    }

    [Description("Sets a new IO Point List in the DDC.")]
    public string SetIOPointList(string host, DDCService.pointInformation[] pointList)
    {

        string result;

        DDCService.LGeDDCClient ddc = new DDCService.LGeDDCClient("LGeDDC", host);

        try
        {
            result = ddc.SetIOPoint(pointList);
        }
        catch (Exception ex)
        {
            result = ex.ToString();
        }
        return result;
    }

I guess it's OK, being this simple and all, but you have a mean boss. Consider future changes and what chances are there to extend this. Then you better do it properly from the beginning. — Marcel N., Jun 29 '12 at 09:24

score 1 · Accepted Answer · answered Jun 29 '12 at 12:54

The problem with not using an interface is that you then need to include the server code on the client. That's not an issue with something simple like this, but can be a real problem if the server interface becomes more complicated or the server implementation is involved.

This becomes something of a deployment problem, too. Any time you change something in the server implementation, you have to copy the new server implementation to all clients. If you're using an interface, then the only time you have to update the clients is if you change the interface. Server implementation changes don't affect the clients. At least, they don't affect the way that the clients interact with the server.

This can also cause a security problem. If there is proprietary information in the server code, that code is exposed on every client. But if you use an interface, there's no need to include the server code.

It might look easier up front to avoid defining an interface for the server. But in the long run, using an interface is more secure, easier to modify, and easier to deploy--especially when there are multiple clients.

All that said, you should ask your boss why he asked for Remoting. But read up on the differences between WCF and Remoting before you do. WCF is clearly a more robust technology.

.NET Remoting convention

1 Answers1