Architecture: System.Transactions vs EnterpriseService
Hi,
I'm a little bit confused with this new System.Transactions namespace.
I was able to understand its propose, but it looks like it is the
replacement for EnterpriseService (ServicedComponent) when all you want
from COM+ is the transaction coordination.
I'm about to start a new project and I have to decide how to architect
the components. I'd like to know if is possible to use only single
assemblies without all the COM+ stuffs (packages, registration, etc).
My environment: .NET 2.0, Win2003, SQL 2000 and Oracle 9i.
Thanks,
David
Hi David,
System.Transactions is not a replacement for EnterpriseServices namespace. EnterpriseServices is a component oriented namespace that provides all the COM+ services in .Net.
System.Transactions is, if you want, a replica in .Net for MSDTC unmanaged APIs that allows you to create and manage transactions in explicit or implicit models and also allows you to create different types of resource managers that are volatile or durable (from the transaction point of view).
If all you need from the list of COM+/EnterpriseServices features is transactions, then using System.Transactions is a better alternative. Sys.Tx is more lightweight and it doesn't require you to derive from a base class. The TransactionScope class is providing an implicit model that handles automatically the "ambient" transaction so that you don't have to remember to pass it to resource managers (for instance when making System.Data calls). The only difference compared with EnterpriseServices is that transactions don't automatically flow cross-threads, cross-app-domains, cross-processes etc. You have to manually take care of the transaction flow. Fortunately, the Transaction class is serializable so you can easily flow it when needed.
I hope this helps.
Hi Florin,
Thanks for you post. I also need to make a decision between using Enterprise services and system.transactions. Can you point out a more comprehensive list of considerations that would help us in choosing between these technologies? There doesn't seem to be much information out there on this topic. For example how do they compare when it comes to security and performance?
Any further help would be much appreciated.
Regards,
Avner
Hi Avner,
Juval Lowy's "Introduction to System.Transactions" might be of help for your question: http://www.microsoft.com/downloads/details.aspx?familyid=aac3d722-444c-4e27-8b2e-c6157ed16b15&displaylang=en
Please note that in .Net 2.0, EnterpriseServices is using System.Transactions for its transaction related feature.
The "rule of thumb" should be: if you only need transactions support, stay with System.Transactions. If you need other COM+ services like object pooling, process pooling etc, you might want to look at EnterpriseServices.
Of course, if you are starting your project now, you might also look at Windows Communication Foundation (aka Indigo) which will be available .Net 3.0.
Cheers!
"Of course, if you are starting your project now, you might also look at Windows Communication Foundation (aka Indigo) which will be available .Net 3.0."
Will .Net 3.0 final release be possible to use it with VS 2005?
