I like Clemens' current piece about power = work/time in which he states that raw performance must not be the most critical or even the only piece of data on which to base your architecture or implementation choice. (Obvious not-so-joke: else nobody would do J2EE/EJB).

I guess it's also somehow along the lines of: yes, you could implement distributed transaction propagation in Remoting, but why the heck would you want to do so? Use EnterpriseServices and it comes for free. Yes, Remoting might be a little bit faster than EnterpriseServices/DCOM, but as soon as you add all the features (like TX propagation, context propagation, etc.), I guess EnterpriseServices would win even in terms of hard, raw performance.

So, the thing basically comes back to one statement: EnterpriseServices is about Services (which are, for example: security, object pooling, just in time activation (JITA), declarative transactions, distributed transactions, compensation, loosely coupled events, ....). If you need these services, please save yourself from reimplementing them - it could be as easy as setting the correct attributes.

At the end of the day, I think that some people [1] are afraid of EnterpriseServices because of two reasons:

• First, it seems just so much like magic. Throughout history, people have been afraid of things they didn't fully understand and which therefore seemed just too powerful. In medieval Europe people with special skills which weren't available to the general public were denoted as witches and burnt at the stake. Only later, as people got more educated about healing and medicine, nobody considered their skills as black magic anymore. Would you burn your doctor at the stake just because he knows enough to cure your illness?
  The same thing is true with EnterpriseServices. Don't be afraid: they aren't magic. They are just some nice concepts (and by the way the largest production implementation of aspect oriented patterns) which can save you some time.
• Second, there's this thing, COM, in the name "COM+". It seems to be soooo 1990s, right? Forget about it. As Clemens said before, there's no COM/Interop in EnterpriseServices. Calls are marshalled using the Remoting infrastructure over a DCE/RPC [aka DCOM] channel. DCOM is only used as a wire protocol here - zero COM/Interop for the parameters of your method call.

So what can you do to prevent EnterpriseServices from being burnt at the stake - or more important, to save yourself from some work re-implementing already exisiting functionality? Learn about it. I absolutely recommend two books in this area: Clemens Vasters' (German) book ".NET Enterprise Services" and Juval Löwy's book "COM and .NET Component Services". I normally don't read tech books cover to cover, but I can tell you - I did it with both of them.

As soon as you know about EnterpriseServices - and even more important, as soon as you know about its services - you're way better equiped to make the right decision in regard to your application's architecture. Please also keep in mind that EnterpriseServices is not just for distributed or web based applications, but for every component which needs its services.

To summarize: The decision between EnterpriseServices, Web Services and/or Remoting should not be based on raw performance or scalability numbers (because you can in fact create quite well performing and scalable solutions with all of them) but more or less on the features each of these programming model provides:

• EnterpriseServices: Services. TX, security, JITA, object pooling, loosely coupled events, ...
• Web Services: Interop. It's all about interop.
• Remoting: Extensibility & ease of deployment in non-supervised environments (i.e. no SMS, no deployment procedures, no Active Directory, ...).

As I said before, the only thing that's really missing from EnterpriseServices in my opinion, is the ability to add interception layers in the same way we can with .NET Remoting.

[1] Yes, people told me that even I did so in a former life. Guilty as charged.