Enterprise Architecturing II

re: Enterprise Architecturing II

Mercede — Sat, 30 Aug 2008 07:24:14 GMT

This is August 2008. things have changed much now. COM+ or Enterprise Services are really a thing of past now. No new development done in that area by Microsoft after Windows XP. We now have .NET 3.5 that offers many features thus we can address the application scalability without resorting to COM+

Enterprise Services is alive and well!

TrackBack — Thu, 17 Jun 2004 15:13:00 GMT

.Net Enterprise Services

TrackBack — Thu, 25 Mar 2004 15:52:00 GMT

Further clarification

TrackBack — Thu, 26 Feb 2004 09:26:00 GMT

re: Enterprise Architecturing II

Sam Gentile — Wed, 18 Feb 2004 20:37:00 GMT

Tiago, first thanks for your interest in this area. In between builds here at work and while waiting for my PC I thought I'd add a few words. Basically, I agree with everything that Robert and Alex (and James) have said already. Architecture is a complicated subject. Architecture has to do with many things such as knowing first and foremost the customer and business needs as wekk as history, current and possible technology. But the most important thing is the business needs. Every architecture is completly different and there is no one set architecture or even way to do one. It all depends on the business needs and the technology. Sure, we have some common patterns as described in Fowler's most excellent book and we have some best pratices but thats it.

I believe it's very important to note that ES as well as Remoting as well as WS are just tools in a toolbox, like other technologies. They *don't* apply to every application. My point is been to make people aware of these tools so that they could put them in one's toolbox *if* the business and technology needs dictated it. Being a good arhcitect also means knowing when *not* to use a tool or technology as when you do.

I plan to write an extensive post on this but a rough take is you need ES if you have true distributed transactions, or want isolated physical security via physical layers (not tiers) or multiple databases. It's a toss up on whether the other features of COM+/ES matter in a managed world and can't be done better through other means. If you don't have one of these cases you don't need ES. Just need to get between one point and another? Remoting or WS. Its when you start to deal with a distributed transaction with two or more RM's coordinating via the MSDTC that ES shines. If you have a logical transaction with an atomic operation that must complete as a unit versus two or more RM's thats when a ES distributed transaction shines.

A lot of this does get fuzzy and thats why ASMX, Remoting, ES and more converges all to Indigo and we have one managed distibuted messaging facility.

As a last tidbit, Alex is completly right: where I was going in the post is my personal desire for developers to understand the complex parts of these technologies so that they can make that crucial decision when they have a bunch of business needs and need to figure out whether a particular technology in their toolbox applies or not. More later.

re: Enterprise Architecturing II

Alex Lowe — Wed, 18 Feb 2004 19:15:00 GMT

Tiago, I'm with you on the whole database angle......it definitely is my impression that poor database design or other related database issues seem to be the bottleneck and the most challenging to scale. SQL Server 2000 made federating or splitting the database an easier task but it is still far too difficult to accomplish, IMHO (I'm certainly not a DB genuis but I play one on TV).

I think you, Robert (and Sam once he gets his PC back up and running) are pushing folks in the right direction and this statement that Robert made regading history/future is so extremely true (and important!). I mean, you have to know all the past issues and the future direction of ES and distributed computing technologies in order to make the most informed decision.

I also completely agree with and admire your desire to understand the complex side of these technologies in order to make a more informed decision (right or wrong). More developers (and publishers, et al) need to take this approach and I think that, ultimately, this is where Sam was going with his initial blog post. I'm certainly not speaking for Sam but I think he was working along this lines.

re: Enterprise Architecturing II

Robert Hurlbut — Wed, 18 Feb 2004 16:28:00 GMT

Sam is having some PC problems the last few days, but is planning a further update on his blog about some of the issues/questions you have been raising.

As expressed by James and Alex, you make choices based on your needs and requirements. You also make choices based on history, current technology, and possible future technology (in terms of what will work tomorrow when the "whole world" changes!). I favor knowing all the options, all the requirements, and making the choices that seem to best fit for now and in the near future.

Sorry to be so vague, but please wait for Sam to post his thoughts in the next day or two.

re: Entrerprise Architecturing II

tspascoal — Wed, 18 Feb 2004 15:05:00 GMT

" Sorry, I didn't write my original response very well (and you broke up the sentences in a way that made it worse)."

Sorry,it wasn't my intention. I was just quoting the parts that seemed relevant.

"ES provides scalability with object pooling and COM+ Load Balancing (CLB). Now, I'm not saying that these features are appropriate for all applications but they can increase scalability. If you are able to scale horzontaly with replication and load balancing without ES then great, you don't need ES apparently."

It has hapenned either way:
A)I never really needed ES and the choices i've made have been the best ones
B) ES could really helped me, but since i'm a poor slob i never knew that ES could have really helped me.

That's why i'm going on this quest to understand ES. I'd really prefer making a wrong decision despite having all the facts and knowledge to have made the correct decision on the first place, than to make a wrong decision by not knowing the tools at my disposal.
I prefer to be the idiot that says "it was a judgement call" rather then "i didn't know that was an option" :-)

From my experience, it's the database that is hard to scale and allways seem to be the bottleneck and from the way i see it, ES can't really help me there.

"On the performance side of things, loosely coupled events, queued components, configurable isolation levels, application recycling, and low memory activation gates can all help with performance."

i hope GC eases the ned for application recycle (but if i'm unnecessaraly holding references to
non managed resources i guess i get what i deserve :-))

But i do like queued components. Low memory activation was something i wasn't aware that ES offered. Seems great to me.

"When I was referring to sharing data I was referring to ASMX, Indigo, etc"

sorry. Misunderstood you.

I think things are becoming a little clearer now. Not sold out yet, though. :-)

re: Entrerprise Architecturing II

Alex Lowe — Wed, 18 Feb 2004 14:14:00 GMT

Sorry, I didn't write my original response very well (and you broke up the sentences in a way that made it worse).

Yes, my tautology was meant to say that distributed computing techniques were not required for all applications but rather those that need the capabilities that things like ES, Remoting, ASMX, etc. bring to the table. I was making that statement because there seems to be this idea that ES, et al are either good for all applications or good for only big applications. I don't think it is either. I think these technologies are good for applications that need the additional functionality - this could mean any size of application in any organization.

ES provides scalability with object pooling and COM+ Load Balancing (CLB). Now, I'm not saying that these features are appropriate for all applications but they can increase scalability. If you are able to scale horzontaly with replication and load balancing without ES then great, you don't need ES apparently.

On the performance side of things, loosely coupled events, queued components, configurable isolation levels, application recycling, and low memory activation gates can all help with performance. Now, as you allude to all the time, these technologies are complex and can be difficult to use/troubleshoot if you have not used them extensively. So, they may not be useful to you and that is ok. The complexity of these technologies becomes another factor in your decision to use them in an application that may benefit from them. In some cases, the cons will outweigh the pros and that is why you don't hear anyone advocating ES for all applications.

When I was referring to sharing data I was referring to ASMX, Indigo, etc.

re: Entrerprise Architecturing II

tspascoal — Wed, 18 Feb 2004 09:38:00 GMT

" You are comparing ES to remoting, I was comparing both ES and remoting to non distributed applications...."

Seems like an unfair comparison. For example in
http://weblogs.asp.net/tspascoal/archive/2004/02/13/72424.aspx i expressed that for now i've allways scaled my applications horizontally (replication & load balancing) without the need to use ES. How (with a similar architecture off course) ES would be better than is? wouldn't we just be adding the overhead crossing managed/unmanaged territory (assuming we don't need distributed transaction)

"I also don't think it has to do with the size of the application, but rather the performance needs of the application. "

Yes. What i've failed to understand so far is: how will ES help me on the performance field?
and on the scalability field? i can easily scale it using other tecnhiques and while at it remaining a purely managed solution.