views:

278

answers:

3

It may be a beginner question but I want to know,

What is the basic difference between Remoting or WebServices?

Which one is better?

+1  A: 

"Better" is quite circumstancial here.

Remoting's uses Binary Serialization so takes up less space over the wire and is generally faster, but will only work with .net on both ends. The versions of your dll's have to match, and you can host server endpoints in applications without requiring IIS.

Webservices are a bit more flexible as they're done using XML, are designed to interoperate with other providers (Java, Python etc).

Alternatively, have a look at WCF (Windows Communication Foundation) as it's where things are heading in the .net world. It allows you to write the code once and then host it on various endpoints

Matthew Steeples
A: 

"Which is better" is a relative comparison that can only be decided by your scenario. Both these mechanisms to implement distributed applications exist for different reasons and it is important for you to choose the one that is most suitable for your setup.

Keep in mind that the entire Webservices framework is built upon the Remoting framework. IOW, Webservices are an abstraction created from Remoting. Therefore, while ASP.NET webservices provide a much simpler programming model and greater interoperability, Remoting offers the full flexibility and power of the System.Net.Remoting namespace, requires much more technical know-how and has lesser interoperability. That said, Remoting using TCP undoubtedly performs better than Webservices over HTTP.

Here's an MSDN article that explains which one you should choose under which circumstances. And another that elaborates on the instrinsic differences.

Cerebrus
A: 

It depends what you want to do; remoting is falling out of favor for true "remote" scenarios; in general, for communication between systems it would be preferable to use a service interface, such as via WCF.

Remoting is still valuable for communicating between AppDomains in a single application.

Note that remoting isn't available for all .NET frameworks - for example, Silverlight doesn't support remoting, but WCF and things like http / (raw)sockets are fine.

If you can, look toward WCF. If WCF isn't an option, look at regular web-services.

In particular, problems with remoting:

  • it ties client and server to .NET
  • it ties client and server to the same binary implementation
  • it tends to lead to poorly considered boundaries (it is very easy to leak the wrong objects over the wire, which can lead to big latency issues)

etc.

Re performance; remoting uses binary serialization, which is useful in some ways, bur problematic in others (see above bullets). Web-services tend to be xml based (although other formats exist) - and are contract based (rather than implementation based) - meaning client and server can have different types representing the objects, as long as they are similar enough.

It is also possible to use binary on web-services; for example, protobuf-net provides a WCF hook to use Google's "protocol buffers" binary (contract-based) format over a WCF service (caveat: this is then a bespoke protocol, and you'd need the tool at both ends).

There are also other ways of talking between systems, all of them arguably preferable over remoting (even if they are less versatile - sometimes, minimalist is a virtue):

  • sockets (custom communications)
  • http (simple POX messages etc)
  • middle-ware (msmq, biztalk, etc)
Marc Gravell