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.

[update]: where are some nice thoughts on this subject too Oh where art thou Business Logic?

7 Comments

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



    I don't read James post that way. I read James post to say that ES should be used when it should be used. That is, ES should not be used in every application. ES is important and developers should still be looking at ES and other distributed computing technologies when building applications that need the scalability, security, and the ability to easily share information with other applications that ES, ASMX, Indigo provide.



  • "I read James post to say that ES should be used when it should be used"



    That seems like a tautology to me. :-)



    I think developers should look at ES too, that's what i'm doing. Would you care to elaborate a little more?



    "when building applications that need the scalability,



    how exactly is ES more scalable than other solutions?



    "and the ability to easily share information with other applications that ES, ASMX, Indigo provide. "



    how does ES provides me the ability to easily share information? i mean what does it provide more than remoting running inside IIS or runing in an isolated process?



    Thanks.

  • You are comparing ES to remoting, I was comparing both ES and remoting to non distributed applications.... I also don't think it has to do with the size of the application, but rather the performance needs of the application. I know that sometimes they are used to mean the same thing, but I think it is important to make the distinction in this case.



    I would still be interested to hear there reasons for choosing ES over remoting or ASMX. Personally I feel that ES is the past and that ASMX is the future, of course things that might be possible with ASMX/Indigo in the future are only available now in ES.



    -James

  • 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.

  • 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.

  • 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.

  • 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+

Comments have been disabled for this content.