This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: ES never fully baked - Distributed Transaction Enlistment
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
I wanted to comment on Robert's posts in a different post. As he notes, we have been doing a lot of work with ES/COM+ on our team as it is the basis of our architecture that I designed. He confirms that you can call a Non-Configured component as long as that class/component has a reference to System.EnterpriseServices in order for the Context (and transaction and activity) to flow. He quotes Tim Ewald's follow-up article, “It is interesting to note that CLR objects behave exactly the opposite of how COM objects behave with respect to COM+ context.”
There's the rub. I grok COM+. Its ES that is fuzzy. As Frans notes in the comments, a lot of ES is very fuzzy and ES transactions are quite a bit slower than in normal transactions and COM+ implemented in C++ or even VB. Also that Microsoft did did a bad job integrating enterprise services in .NET. I agree. The initial part is so deceptly easy as I laid out in these steps. However, that will just give you a base ES object capable of doing distributed transactions. That doesn't mean it will neccessarily work (unless very simple). Things work very strangely in ES like the dual nature of it; it will use DCOM for communication under certain data types and .NET Remoting for others. Guess what? DCOM propogates a transaction context and .NET Remoting doesn't. It turns out to be one big mess and one has to dig in much further than they should have to to make any of it work. Hmm, shades of COM Interop-) I must admit I am starting to have serious reservations about ES usage compared to COM+. In unmanaged COM+ it was a no-brainer when and essentially how to use it. In ES, although it looks easy, the many quirks and flawed implementation give me hesitations. It looks as Microsoft just threw a managed wrapper over COM+ and went on to other things. This is understandable in the amount of work needed for .NET 1.0/1.1 knowing that the whole area of distributed communication was going to be done over in Indigo anyhow (as the genesis of the idea dates back to 1999 according to Don's interview).
We will continue to document the quirks and issues but I am begining to wonder if one just waits for Indigo to do this all right and just use ES only when there is no other way around it (i.e. Distributed TX to two or more RMs).
Robert also points out that Distributed Transaction enlistment can be automatic with the Tx root having declared its intentions for transactions but you can opt out in some method with by setting “Enlist=false” in the connection string. Deriving from ServicedComponent also gives you the capability to control the transaction. The area of Services Without Components is an interesting one but only available in Win2K3 and XP and doesn't help us with some Win2000 servers.
Previous Topic
