Bodhisattva in Training

May 22, 2004 Uncategorized

Don Box’s Spoutlet: Deconstructing Remoting

Don Box’s Spoutlet: April

Don has an excellent spout on .NET Remoting, where it is going, and what to count on. His blog will not allow permalinks to old entries so I have copied it here.

Deconstructing Remoting
Grant Killian asks for the skinny on remoting.

I’ve watched people try to give high-level guidance on this, but the fact that this has become a permathread means that a different approach is in order.

It’s actually quite simple if you’re willing to take a few minutes to look at what’s actually under System.Runtime.Remoting.

The Good

The transparent proxy/stack builder sink allow you to cons up an object reference for ANY CLR interface. That technology is alive and well and a crucial part of the CLR. When you make a channel call on a service contract in indigo M5 (our current milestone), the TP is working its magic on your stack frame.

The CLR uses the TP/SBS infrastructure to allow object references to marshal across appdomains inside a process. That technology is also alive and well and frankly, it just works (if it didn’t, the CLR would melt down pretty quickly). If you’ve ever called AppDomain.CreateDomain, you’ve been using the TP/SBS stuff. I would strongly recommend not counting on the existence of the CrossDomain channel. Its existence is undoc’ed and we’ve looked at various ways to change it’s implementation radically to improve perf.

The Bad

We built support for WSDL under the TP/SBS infrastructure that is an architectural dead end. If you run into me at a conference, please do me a favor and let me remove SOAPSUDS.EXE from your laptop.

The Ugly

.NET Remoting really assumes shared classes and shared assemblies between the two endpoints. Indigo exists to break this dependency. This is the biggest architectural change but it’s profound.

V1 of the CLR shipped with an extensibility point for doing custom transport channels under the TP/SBS mechanism based on bytes. Indigo has a SOAP/Infoset-based architecture that we believe is more general and has a longer life span (yes, it’s weird to think that SOAP will outlive bytes).

V1 of the CLR shipped with a binary/TCP transport channel. There are no plans to support this one-off proprietary format natively in Indigo.

For some ugly historical reasons, the TP/SBS infrastructure allows class-based remoting using System.MarshalByRefObject. Indigo does not require MBRO.

Ending this permathread once and for all?

The real asset is the TP/SBS infrastructure. If you find yourself wanting to use it, do so with a clear conscience. Feel free to point your management to this blog entry if that helps.

If you’re crossing host boundaries, ASMX is probably a better choice, both architecturally as well as in terms of tracking where the platform is headed in the next 2-10 years.

Leave a comment