Dr.NETjes

Dion Olsthoorn on ASP.NET

Is Microsoft trying to discourage the use of Remoting?

After visiting the TechED Europe 2004 in Amsterdam, it seemed to me that Microsoft was trying to deprecate Remoting as a solution for distributed architectures.

I guess it's because the forthcoming 'Indigo' is built upon (and extending) WebServices functionality, and Remoting just doesn't fit in very well here. During the TechED there was not a single session on Remoting, while I guess there were over 30 sessions on WebServices and SOA's. A couple of well-known speakers called Remoting an immature framework, and accused it of being built too hastily as a .NET alternative for DCOM. And even some slides were presented that showed Binary Remoting being twice as slow as Http WebServices (on a IIS6 machine that is).

What?? How is that possible?!! How can a Microsoft-specific binary remoting architecture be much slower than utf-8 WebServices? Why where these results shown now, while at the launch of .NET 1.0, Remoting was presented as the fasted solution for distributes systems?

So my conclusion: Microsoft is trying to discourage people to use Remoting, because Indigo will not support it very well. While I understand the reasons they do this (I myself am a big fan of WebServices and the power of SoapExtentions), I still don't understand how Remoting can be that slow compared to WebServices. I guess Microsoft has put a lot of effort in IIS6 to optimize it for WebServices?

Posted: Aug 27 2004, 11:28 PM by Dr.NETjes | with 2 comment(s)
Filed under:

Comments

Rob said:


Remoting is one of the coolest technologies that Microsoft did in the 1.0 and 1.1 frameworks. It's robust, scalable and extensible. It is also based on an 'older' paradigm that Microsoft is moving away from in Indigo.

Bottom line is that it is in the framework, it is being improved marginally for Whidbey (but only just marginally) and is NOT being deprecated/obsoleted anytime soon. Remoting apps will still work 10+ years from now on .Net. Oh yes and it is pretty smokin' fast from my POV (although I admit that the major app that I designed and implemented was an Intranet application and it used the TCPChannel etc. rather than the HTTP stuff).

I think the core of your conclusion is correct. Microsoft is positioning Indigo as the superset/refactored communications infrastructure stack and with todays announcements about it being available on Windows XP (in about 2 years time) you will only see more of this...and quite frankly that is a good thing. However, remoting isn't going away with Indigo, it will always still be there in the framework, but it will exist side-by-side with Indigo and I would not expect great interoperability (although I could be wrong about that)...time will tell.

Just my 2 cents.

Rob
# August 27, 2004 8:56 PM

Frans Bouma said:

It's an often heared question: "Is remoting axed? Isn't remoting something that will not be there in 2 years?".

Remoting is here to stay. The reason for that is that Indigo will include remoting, DCOM, Webservices and other communication channels/protocols, so remoting code will be runnable in the future as well. Before Indigo will see the light, remoting will be a first class protocol to do distributed applications.

The funny thing is: DCOM beats the crap out of everything related to webservices and remoting. A DCOM proxy, even through enterprise services, is far superior over remoting code and webservices. Why are webservices so important and hyped then? To get Microsoft a better position in the datacenter. That's the sole single reason. Webservices have one key feature none of the other protocols has: interoperability with other platforms like Java, a DB2 database or what have you. That's also why VS.NET has nice webservices designers/code generators but not for remoting nor even for enterprise services which is barely documented anyway.

There is a caveat though: webservices are XML based. This means that cyclic references (myCustomer.Orders contains Order objects which have a reference back to myCustsomer) and interface based types/members are not usable. Especially the cyclic references is a big blow.

Remoting can help there. it doesn't suffer from these limitations and if your application is .NET all the way, why bother with webservices?

Why are these webservices faster sometimes? Well, the XmlSerializer generates special tailored code to generate the XML for fixed input. This means that the XML generation is very fast after the first genreation / compilation of code. It's also not that flexible then, but if your service exposes data in a somewhat small set of formats, it's not that bad.

Remoting with the SOAP formatter is not having that, it needs to examine and produce the XML with generic code which is slower. The binary formatter over TCP can help though, webservices can't beat that in most scenario's.

So, remoting is here to stay, it will be merged into indigo together with webservices, DCOM and friends. In Whidbey, MS has finally documented IXmlSerializable, so 3rd party library vendors can make their code be compatible with the XmlSerializer as well.
# August 28, 2004 5:42 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)