Developing a broadly available set of services upon which your enterprise will rest is a daunting task. Typically difficult issues such as performance, scale, and availability need to reach 10 or 100 times that of a single application. Consider a simple logging mechanism. Implemented for enterprise consumption it needs to support hundreds of concurrent users not just a single local desktop, writing thousands of rows per second instead of tens of rows per minute, and provide process isolation so one user can corrupt another’s information. All this and you are not allowed to degrade security. No performance tricks like pooling database connections on a single user ID. And of course, everything must work, all the time, for everyone.
Microsoft has given us a hand to achieve these goals... COM+ hosted components and the .Net frameworks Enterprise Services namespace create a safe, performant, and scalable environment. I am a huge fan of COM+. Object pooling, Just-In-Time-Activation, and role based security are the cornerstones of any Microsoft based enterprise architecture implementation. Add in Network load balancing on the front and database server clustering on the back and you real safety and stability right out of the box.
Of course it's not all that simple. Implementation details are wrapped in confusion, complexity, and aggravation. COM+ documentation is very intricate and, in my opinion lacking in step-by-step details. At least for now there seems to be a fair amount of lore handed down from developer to developer. Even that is cloaked is bounded by personal experience as full of ambiguity. So here is my short list of things that drive me nuts in a product set I love to implement.
#1: Why do I have to apply [AutoComplete] when I turn [JustInTimeActivation] on? I suspect it is nice to be selective as to which methods use JITA but the IDE auto-generates so much code now can't we get this one.
#2: COM+ is fast. REALLY FAST. By some accounts COM+ components are 30 times faster than plain old unmanaged code. So why is the reputation, and much of the documentation, about the performance costs? Like most things, done poorly it is slower, but done well, it rocks.
#3: Why do people try to apply stateful patterns to the COM environment? I have a mantra .. small, stateless, fast. Whenever I am designing parts for a Microsoft environment I want them to be as small as possible, each focused on accomplishing a single task. I don't hold state in the middle tier (it's fine in the client or the database) because I want to use pooling. And I want these parts to go in and out of memory as fast as I can, again to support pooling. If you try to do stateful things you will not get the benefits of Enterprise Services and you will forever chase performance, scalability, and concurrency. It can be done ... but it's just not as easy.
#4: If I have no impact on your approach other than this ... please ... Don't wait for the end of the project to consider security. My grandparents use to never lock their home. Today, I don't walk away from my keyboard without locking my computer. It's an evil world and we are responsible for the future safety of our users. Enterprise Services and COM+ provide for flowing Identity, access to the SecurityContext, and role-based security. Use them. Know who is doing what at all times and code for the "good" scenarios to the exclusion of all other paths.
#5: If software is a team sport (and I for one believe it is) then an enterprise architect is the coach. I'm not much for sports analogies but here it goes. Most teams have an offense and a defense. They perform different tasks, requiring different skills, and generally run counter to each other. Enterprise work requires Software and Hardware. Our job as architects is to leverage both, striking a balance as needed for the task at hand. It is as important to understand clustering and load-balancing as it is to know when a member variable is going to cause JITA to fail.
