Enterprise Services in ASP.NET

[the4man]

Hi all!

First, excuse me for my english, I'm not a native.

Until now I have used for my enterprise web sites ASP + DLLs + COM+.
Why COM+? Because we have two database servers and some distributed
transactions. And another thing: with COM+ I can change any DLL without
restart the server (less "dll hell"). JIT and the other features are
important, but they aren't key features for me.

COM+ have some disvantages too. For example, I can use "real" OO,
because the objetcs are stateless (if they can participate in
transacctions and you use SetComplete/SetAbort in all methods, like in
my case). So something simple like this:

objClient.Name = "lala"
objClient.FirstName ="lala"
objClient.Email = "(e-mail address removed)"
objClient.Insert
objClient.SendEmail

must be done like this:

objClient.Insert(name, firstname, email)
objClient.SendEmail(email)

Now I have to migrate some sites to ASP.NET. And I'm thinking that COM+
is no really mandatory in my case. There is no "dll hell" in .Net. JIT
and object pooling is not very important for me. Connection pooling is
done by ADO.NET. Distributed transactions.....I can replace it with an
alternate mechanism. I prefer to lost some features to gain others,
like real OO, the posibility of replicate pages an dlls to others
machines with robocopy instead of Microsoft "very expensive"
Application Center 2000, no need of register components in COM+ (yes, I
know that is an automatic process now, but I'm sure that I'll have
problems with that),.....

So, what is your experience? In what case do you think that COM+ is
really necesary? By the way, do the new Transactions classes of ado.net
2.0 resolve my problem? are they capable of extend the transaccions
through machines?

Thanks in advance!

 

[Joerg Jooss]

Thus wrote the4man,

Hi all!

First, excuse me for my english, I'm not a native.

Until now I have used for my enterprise web sites ASP + DLLs + COM+.
Why COM+? Because we have two database servers and some distributed
transactions. And another thing: with COM+ I can change any DLL
without restart the server (less "dll hell"). JIT and the other
features are important, but they aren't key features for me.

COM+ have some disvantages too. For example, I can use "real" OO,
because the objetcs are stateless (if they can participate in
transacctions and you use SetComplete/SetAbort in all methods, like in
my case). So something simple like this:

objClient.Name = "lala"
objClient.FirstName ="lala"
objClient.Email = "(e-mail address removed)"
objClient.Insert
objClient.SendEmail
must be done like this:

objClient.Insert(name, firstname, email)
objClient.SendEmail(email)

That's common sense for any remoting API, be it ES, ASMX, WCF, .NET Remoting,
or EJB. Fine-grained OO APIs make terrible remoting APIs.

Now I have to migrate some sites to ASP.NET. And I'm thinking that
COM+ is no really mandatory in my case. There is no "dll hell" in
.Net. JIT and object pooling is not very important for me. Connection
pooling is done by ADO.NET. Distributed transactions.....I can replace
it with an alternate mechanism. I prefer to lost some features to gain
others, like real OO, the posibility of replicate pages an dlls to
others machines with robocopy instead of Microsoft "very expensive"
Application Center 2000, no need of register components in COM+ (yes,
I know that is an automatic process now, but I'm sure that I'll have
problems with that),.....

So, what is your experience? In what case do you think that COM+ is
really necesary?

I think you gave yourself a good answer already. If you can avoid distibuted
transactios, do it. And that's not meant to be a COM+ specific advise ;-)

By the way, do the new Transactions classes of
ado.net 2.0 resolve my problem? are they capable of extend the
transaccions through machines?

The Leigthweight Transaction Manager (LTM) will propagate transactions to
MSDTC if another connection enlists in a transaction. The current issue of
CoDe Magazine features an article that covers the entire LTM/MSDTC story.

Cheers,