Brad More is asking whether and why he should use Enterprise Services.

Brad, if you go to the PDC, you can get the definitive, strategic answer on that question in this talk:

“Indigo”: Connected Application Technology Roadmap
Track: Web/Services   Code: WSV203
Room: Room 409AB   Time Slot: Wed, October 29 11:30 AM-12:45 PM
Speakers: Angela Mills, Joe Long

Joe Long is Product Unit Manager for Enterprise Services at Microsoft, a product unit that is part of the larger Indigo group. The Indigo team owns Remoting, ASP.NET Web Services, Enterprise Services, all of COM/COM+ and everything that has to do with Serialization.

And if you want to hear the same song sung by the technologyspeakmaster, go and hear Don:

“Indigo": Services and the Future of Distributed Applications
Track: Web/Services   Code: WSV201
Room: Room 150/151/152/153   Time Slot: Mon, October 27 4:45 PM-6:00 PM
Speaker: Don Box

If you want to read the core message right now, just scroll down here. I've been working directly with the Indigo folks on the messaging for my talks at TechEd in Dallas earlier this year as part of the effort of setting the stage for Indigo's debut at the PDC.

I'd also suggest that you don't implement your own ES clone using custom channel sinks, context sinks, or formatters and ignore the entire context model of .NET Remoting if you want to play in Indigo-Land without having to rewrite a large deal of your apps. The lack of security support of Remoting is not a missing feature; Enterprise Services is layered on top of Remoting and provides security. The very limited scalability of Remoting on any transport but cross-appdomain is not a real limitation; if you want to scale use Enterprise Services. Check out this page from my old blog for a few intimate details on transport in Enterprise Services.

ASMX is the default, ES ist the fall-back strategy if you need the features or the performance and Remoting the the cheap, local ORPC model. 

If you rely on ASMX and ES today, you'll have a pretty smooth upgrade path. Take that expectation with you and go to Joe's session.

[PS: What I am saying there about ES marshaling not using COM/Interop is true except for two cases that I found later: Queued Components and calls with isomorphic call signatures where the binary representation of COM and the CLR is identical - like with a function that passes and returns only ints. The reason why COM/Interop is used in those cases is very simple: it's a lot faster.]