Use of Legacy "Communication" Classes in .NET Framework

Question

I have a web application which passes long-running requests to a Windows Service on another computer, using .NET Remoting. I have been told that .NET Remoting is an obsolete technology, and that it should no longer be used.

Should I rewrite the service using WCF, or leave it as it is? If I rewrite it, am I going to have to rewrite it again when Microsoft replaces WCF with something else?

NOTE: This is not a rhetorical question. Microsoft has changed its remoting story at least three times. (DCOM, .NET Remoting, WCF, ?...)

Answer 1

Given that WCF and .NET Remoting are not very easily interchangable (.NET Remoting is based on remote objects while WCF is more about document-oriented messaging), I wouldn't go to the trouble of rewriting the code to WCF just because .NET Remoting is no longer considered hot. Of course, your actual circumstances may vary heavily.

If .NET Remoting works for you and nothing needs change, keep it. At some point you may have to consider switching to WCF-based technology to support more diverse clients - such transitions seem to be common these days - but until that day comes, keep it simple. I would, however, write new applications on WCF from the start, mostly to encourage myself to keep within the SOA-minded document communications model.

Answer 2

WCF is simply an all-encompassiing abstaction of several different ways put together that includes remoting. There are no performance guarantees, in fact, in some cases, remoting is much faster than WCF.

If you implemented your project as per the .NET remoting guidance. then migration should not be very simple.

My personal suggestion would be to leave it as is, unless you can justify the migration in terms of business needs.

Answer 3

.NET Remoting is not obsolete. To become obsolete technology should have successor, this is not the case for .NET Remoting. WCF and .NET Remoting is actually do different things. WCF is messaging solution (and it successor of ASPX) when .NET Remoting is object distribution solution.

So my suggestion is not bother to update your implementation to WCF, just use .NET Remoting (disclimer, I used to use .NET Remoting as messaging solution and now my default chouise is of cource WCF).

Answer 4

If you want true longevity, you should build your own remoting technology, for two reasons. First, it is not a good idea to bind yourself too closely to a Microsoft technology. As you said, they obsolete things rather too quickly. Second, tuned to your own needs, it should outperform any remoting framework for your applications.

I beat SOAP remoting by 10% in benchmarking, but for some reason unknown to me, that 10% benchmark tuned into a 90% field gain.

Answer 5

i would say that unless your current solution does not meet a particular need there should be no need to rewrite it. True, .NET Remoting will no longer be advanced bna din theory has been replaced by WCF but my feeling is if it aint broke why fix it?

ps. WCF is not a pure messaging solution as some people above are making it out to be. MS has positioned it as the common way for all COMMUNICATION between applications and application components. it is a consolidation of a variety of technologies like MSMQ, .NET Remoting, Web Services etc.

Answer 6

I think we should be clear on the status of Remoting. It most likely will never be improved. It most likely will have a sharply reduced number of bugs fixed. It could reach the point where only business-critical bugs, or security-critical bugs, will ever be fixed.

You may also want to consider that Microsoft apparently does not consider a "Remoting" solution to be necessary. That is, the solution where there is an object in a server, complete with state, and a remote machine may make method calls that actually go to that specific object, across the network, via a proxy.

Note that a great deal of the technology of Remoting is part of WCF. The channel and message stack extensibility; the extent of the configurability; all of those things are part of WCF.

Frankly, I see no reason for you to change your existing code. However, I recommend that you take the time to reach the point in your organization where, if you would have started a new project using Remoting, that you can be comfortable using WCF instead.

Finally, is there any part of Remoting that you feel WCF does not accommodate? I mean, other than the fact that behavior and data have been separated in WCF.

---

P.S. In my opinion:

• WSE is obsolete. Don't use it unless you have no other choice at all. Replace it as soon as possible.
• ASMX is now publicly acknowledged to be "legacy technology". See ASMX Web Services are a “Legacy Technology”, and comment if you feel like it.
• Remoting, in my opinion is pretty much in the same position as ASMX, as having had most, or all, of its features superseded by WCF.