Future of .NET Remoting | The Coffeehouse

zombie

What does the future hold for .NET Remoting? I recently got the impression that we should steer away from .NET remoting for an easier migration path to Longhorn.

Maze_werks
Coding to no good

I have been told the same thing in a recent joint R&D effort with Microsoft. It is clear they see WebServices as their focus. I have used ASP.NET web services and like them particularly for intergration but have trouble seeing it as viable for client/server (although some prototyping I have done looks positive). In the end you have to bolt on compression, security, encrytion, etc.

We are an ISV and I have had reservations about ASP.NET web services and had been leaning torward remoting and offering clients the option of using Binary formatter or SOAP formatter as an option on certain functions. One problem is that it leaves you writing more code particularly for the plumbing side of stuff.

Another option is to look at WSE 2.0

Mike Zammuto

zombie

I heard that we should use web services or enterprise services (com+) instead of remoting.

We have a product that uses remoting servers to interface with a lot of different hardware, including real time control and transfer of video and audio recordings back to the clients on demand. I don't think web services are suitable or this type of application, even if we use WSE 2 over TCP/IP. I guess it is worth another look at WSE 2 and com+ again.

jwanagel

.NET remoting will continue to exist in Longhorn and beyond, since backwards compatibility is always a key requirement for our operating systems.

The thing is the product group that owns the Remoting, WebService, and COM+ technologies has made the decision to invest all future enhancement efforts on the WebServices technology. The reason is because of the existence of the broad industry adoption of the standards, we're able to make WebService technology better in ways that is logistically impossible with the other ones, but there aren't reasons why the WebService technology can't be made every bit as good as Remoting and DCOM.

So basically Microsoft is encouraging customers to transition to using WebService technology because it's the technology that will continue to improve.

Today, there really isn't much in terms of features in Remoting that you can't get with using either WebServices or COM+. Maybe over Webservices, but not really over COM+. However, there are still some distinct features that COM+ has over WebServices. So that's why they say COM+ is fine if you need some of those extra features not yet available with WebServices.

Because COM+ is still very widely used, they plan to try and offer really good code migration strategies from COM+ to WebServices, but they're not planning on creating as good of code migration strategies from Remoting to WebServices. So that's another reason why if you need more features then WebServices can offer they are encouraging using COM+ (versus Remoting).

They expect the gap between the features offered by WebServices and by COM+ or Remoting will be closed when Indigo ships. So at that point you'll likely want to switch to WebServices because they expect it will have all the features that COM+ and Remoting have to offer and more.

kojiishi

Well, that makes sense, but you do not respond to zombie's question, which is the same question as mine.

I have multiple processes running on a computer, and they need to communicate for a real time thing. For instance, a process runs a DirectShow graph, and the other process displays its intensity level of the graph. I do not see Indigo and web services will help such requirements in a few years.

So, what is MS's response to who want real time communication between AppDomains in a PC?

zombie

What about app domains within a single process! Currently, I think you can only use remoting to communicate between application domains within a single process. Right?