More EnterpriseServices Fun
Clemens Vasters and Ingo are carrying on an interesting conversations on .NET's EnterpriseServices and Remoting. I agree with a lot of what they say.
However, I also have my pet peeves about COM+/EnterpriseServices. Now, don't get me wrong, I really like what services ES provides, and .NET makes it super-easy to use it (compared to doing it all from raw C++), but there are some things that could improve to make it better.
I much prefer to work with library applications whenever possible, as they give you tons of services without many of the disadvantages of server apps: more complex deployment (GAC and all that), no control over the process lifetime, etc. Of course, Library apps also have one big disadvantage: no remote invocation. However, some upcoming COM+ 1.5 features will improve this somewhat.
My other gripe with ES is tied to the particular underlying protocol it uses: DCOM. While DCOM does tons of things and works very well in some scenarios, it doesn't work as well in others. The first problem is its dynamic allocation of ports for applications (which is somewhat improved in Win2K SP3), and the other, of course, the fact that it isn't Load-Balancing friendly. At least, from my [limited] understanding, getting load balancing on these scenarios requires Application Center Server, and adding another third-party product to an already complex application doesn't excite me too much. Not to mention that the way AppCenter does Component Load Balancing (CLB) sounds pretty much like a hack to me. There's also the fact that, afaics, it doesn't exactly play very nicely with .NET (deploying complete applications to the GAC is not my idea of fun). If anyone happens to know more about this than I do (Clemens?), I'd love to be proved wrong and understand this in more detail :)
So, while I think EnterpriseServices already provide a ton of value, I think there's room for improvement, so at least I, personally, would like to see some sort of support for taking advantage of the ES services while breaking out some of the limitations of DCOM... I think that SWC is a step in the right direction, but it's certainly not enough.
In my opinion, using “yet another product” for load balancing shouldn’t be a problem. Yes, true, when using Web Services or Remoting, you could use any TCP/IP or HTTP based load balancer, including maybe some open source packages (but that’s yet another product, too). On the other hand, I guess that if a corporation needs an application server backend scaling larger than a quad-processor intel box – or a zero downtime hot standby failover cluster – the price (in terms of TCO) of yet another server side product shouldn’t really matter too much.
-Ingo
Well, I guess that is debatable… at US$3000, appcenter is not exactly cheap, particularly when you live in a third-world country. There’s also the operating costs that enter the TCO equation.
I’m certainly trying to learn more about appcenter, since I know fairly little about it, but from all I’ve gather to learn, I’m not exactly thrilled by it, from a technical POV…
I got a little story about AppCenter. Once upon a time I was leading a .NET technical team at NaviSite. Our team and others were and did build an Auto Provisioning system based on all sorts of monitored parameters and data of systems. The AppCenter team came for a “discussion.” It was very clear they were more interested in “borrowing” our ideas. AppCenter did not impress me then nor does it now.