Tiago Pascoal's WebLog

Enterprise Architecturing II

I've been wondering for a long time why we should we use Enterprise Services, what benefits can we reap from them, when they have (in my point of view) a high price. Basically the questions i still have today, were clearly presented in november 2002 (a long time ago,by .Net standards by John Lam), mine are still present i don't know if in the meanwhile John has changed his mind.

Avery also tends to think that ES is only suited for large systems.

This post launched a more heated internal debate on my head,i posted some thoughts about it and hoped that either Sam or Robert could explain me better the architecture they have been developing on the last few months and involves heavy use of ES. I didn't want to know any kind of details about the client nor it's internal architecture, i just wanted some rationales and why they did feel that ES were the way to go.

Sure i know ES provide queued components, role based security, object pooling, distributed transactions among other things, so i can think on top of my head a few reasons to use it,but i think they are weak  per se and are not worth the trouble. (yes i know the whole can be bigger than the sum of the parts)

For argument's sake let's say we don't need distributed transactions (i'm not talking about inter components transactions, will try to address that later i'm thinking in terms of transactions spanning multiple databases (or other sort of transactional resource (MSMQ for example)).

The most used argument for going the ES way is scalability, i've really tried to understand this argument; since ES are based on COM+, calling ES will make us pay the penalty toll for crossing managed/unmanaged boundaries. So i can't really see how ES will help us on the scability balance, the cost seems to high for the achieved benefit (none that i can see).

Pooling

If we need object pooling, we need to either measure it it's worth doing it by hand or using enterprise services. For example  here, Don Park implemented some simple object pooling by hand (with great results for such a cheap effort), on the other hand i remember Clemens advocating the use of ES object pooling for guarding acess to a limited resources  (the example was a terminal emulation program used for screen scraping some mainframe application with limited logins).

Distributed Transactions

When it comes to distributed transactions, i separate them into two groups:

Transactions spanning multiple transactional resources

The ones that span more than one transactional resource. When we encounter such a kind of distributed transaction, using ES seems like a nobrainer to me. I really love the way that we can use declarative programming, to enlist ES components in a transaction. Doing it manually is really painful, using DTC's and manually enlisting transactions in a DTC is really something i would not like to do, so here i think ES are really useful and would have no doubts in using it. But to be honest, i've never seen that many cases where distributed transactions were needed. To be honest i've been presented with a lot of scenarions when distributed transactions were needed, but either the technology to support wasn't present (heteregenous systems) or they could be considered long duration transactions  and sagas (transaction/compensation pattern) were a lot more appropriate.

Transactions spanning multiple components

In here i use the term components in a broad way. I could as well used the term modules, methods or whatever.

In this scenario i mainly see 2 camps.

1. Those that defend that a database is something that should be merely used as a data store (period).
2. Those that defend that business logic does have a place in the database

For the first group, there aren't many choices there, it really is a degenerate case of the a transaction spanning multiple transactional resources. Either you manage transaction manually (a nightmare to manage, real easy to leave the database hanging by forgetting to close a transaction) or use ES and do it declaratively. For these kind of scenario ES are really a great fit. However there is danger lurking, when junior people are involved (people who barely know what a transaction is let alone what a lock is, so they use transactions indiscriminantly (i've seen people opening transactions for reading a database, i've seen people calling database insertions in a tight loop without any sort of transaction, and everytime i think i've seen it all bang someone amazes me and ). People on these camp, also argue that they want database independence. That someday they might switch providers (while such an argument is comendable i've never seen it happen,and unless you are using some kind of O/R mapper or code generation such a task will never be easy unless we are dealing with a toy database). People on this side of the trenches,defend that (rightly i might add) if more performance is necessary you can allways buy some more iron (either scale vertically or horizontally), because you have saved a lot in developing and in maintenance. They also tend to favor code generation techniques.

[Update: where is such an opinion]

The second group, are normally the control freaks, the ones that want to squeeze the last millisecond out of the database. A lot of business logic inside the database in order to reduce round trips and to micromanage the transactions (again inside the database)(making sure the transactions time windows are really small and really know what kind of locks are involved when they do what they do.

I've found that the people entrenched on this kind of reasoning, are people who normally develop applications that are highly contained, the composition of components use,components interactions (relations, dependencies,use, whatever) are rather small (and highly predictable) so they can manage all these interactions on their heads, therefore can easily control them all.

Security

I will pass this on to Robert, he tooked the plunge and explained from a security point of view how he thinks ES presents himself as a nice solution.

No arguments from me here. I guess in this case ES seems to have a nice fit (and from previous posts they seem to use distributed transactions extensively).

[Update: Robert added some clarification to his original post]

[Update] Ian griffith has some thoughs on security here

Conclusions? (not really)

Using a DTC for "local transactions", seems like a heavy price too. However i've read (heard?) somewhere that in whidbey and yukon, transactions will only be escalated into the DTC if needed (until they, are are placed upon Sql server exclusively).

If you have reached this far, you are probably confused. Everything i say, implicitely says the ES are the way to go and yet i've never grasped the need to use ES. Oh well maybe it's a paradox, or perhaps this post should reply my own questions and the light has presented to me by myself. (perhaps it's the train coming running at full towards me, but i bet it's not the clue train) :-)

Oh well. Keep those thoughts coming.