Doug Purdy on Remoting

About a month ago, there was a flurry of activity around the question if remoting is dead. Now some people think that it's not dead, it just smells funny.

However, Doug Purdy pointed out today in his versioning talk at TechEd that a number of features in Longhorn are built using .Net remoting. Now we have BizTalk 2004 and Longhorn both using remoting. I think that is a clear statement that remoting will stick with us for a while. It's important to understand who each technology fits.

One has to carefully evaluate if remoting is the right choice to connect applications running on different servers. Web services provide a solution that will easily integrate with applications built with Indigo (which is still years away).  If you need to communicate across AppDomains on the other hand, then remoting is your only option in the .Net Framework and future integration with Indigo is likely not an important consideration.

4 Comments

  • I agree w/ your assessment. I chose remoting for my team's project based on the LIKELYHOOD that the application(s) would be communicating across AppDomains on the same machine, but also the possibility that some MIGHT like to span boxes. Seemed a good fit and has been happily in production for some months now.

  • I'm going to disagree with you on this one, Christoph. Remoting is NOT the only option for communicating between app domains. Right in the box, you've got System.Messaging, which is a MUCH better option. Of course, it does cost you that extra cross-process hop (but, it doesn't necessarily go to disk or hit the network stack).



    Count me as one who thinks remoting smells funny. Let's build a better messaging oriented inter-AppDomain communication mechanism. Hmm, maybe Soap over named pipes or even memory mapped files. Who's with me?

  • We don't recommend that anyone use Remoting for the x-process/x-machine case -- save for special scenarios were you need to control the transport and format to a large degree.



    As you stated, folks should use Remoting for the x-domain case. Yes, you can use other technologies for this -- but they are big hammers and you lose a lot by using them -- and gain very, very little (if anything at all). This is the reason that we recommend it and the reason folks use Remoting internally for the x-domain case.



    The above all said, folks should follow the guidance I hightlighted in my talk about how to leverage Remoting for this scenario. We may make changes to the model in the future and want to ensure that they are on the right path.

  • John,



    I wouldn't mind having something that's more message-oriented and lighter weight than remoting to talk between AppDomains.



    I see the point you made the other day that the same rules about loose coupling that apply to applications running in different processes SHOULD apply to applications running in different AppDomains, i.e. they shouldn't really share types by design.



    However, I think that I stick with Douglas' point that remoting has still its place. The performance hit with message queues was rather large, last time I compared performance numbers to lighter weight techniques. Given, .NET Remoting wasn't around at the time, but since remoting has enough information to optimize away much of the overhead for x-domain calls in the same process I am hoping that it's pretty efficient.



    Since the whole reasoning to use AppDomains over processes is to increase performance and scalability, I would think that communicating between them over queues invalidates some of the benefits of choosing AppDomains in the first place.



    Now if we had something lighter-weight and message-oriented, then I might be game, because I see the benefits of loose coupling. I'm wondering though if you can get much lighter-weight than the BinaryFormatter while being message-oriented? Serializing objects with the BinaryFormatter is so efficient and compact because of the assumption that the receiver of the serialized object has access to the meta data to deserialize it. When you move to a more message oriented model, then you need to add the meta information to the serialized message, which in turn adds quite a bit of extra overhead.



    To come back to my original point, I think it is really important to carefully evaluating if remoting really fits the bill. It certainly doesn't if loose coupling is a requirement. If performance and loose coupling are both important then it might be worth implementing a custom solution based on your suggestion.



    Your thoughts?

    Christoph





Comments have been disabled for this content.