Hi, <disclaimer> Below are just my thoughts about COM+ declarative transactions that could happen to be just my speculations without any relation to any official position of my employer or associates, bla, bla, bla... ;-). Ie: don't read it if you don't need it ;-). </disclaimer>
COM+ transactions appear to be a very controversial topic that created lots of confusion and misinterpretations among developers. Partially it could be explained by the considerable COM+ marketing/advertisement efforts (remember the slogan "COM+ brings transactions to the COM world")... But hey, don't we all know that advertisement people are used to exaggerate? And that's, I believe, exactly the case with COM+ transactions. COM+ declarative transactions are about distributed transactions. And when you say distributed transactions - the major use of them is for integration purposes only (for example when one tries to integrate in-house made legacy system with SAP's or Great Plain's or any other 3rd-party solution). Does anybody know any new solution that wasn't about integration with some legacy/3rd party system, but required access to multiple databases from different database vendors? I bet - no. Note: "multiple database vendors" is an important part here, because as far as I know - any database that supports distributed transactions has its own internal (read - more efficient) mechanism of providing distributed transaction across multiple databases of the same db vendor, than going COM+/OLE transactions/XA distributed transactions path between two or more different DB vendors. Ex. see: SQLServer - "sp_addlinkedserver" + "Transact-SQL Distributed Transactions"; or Oracle - "create database link..." + local transactions transparently propagated to the distributed transactions by the Oracle DB engine... For the moment, let us be idealistic (from systems integrator's perspective) and say that most/all 3rd party/legacy system are developed as a set of COM+ components with suitable support for COM+ declarative transactions (read - most of them just use transaction support "required"), and most/all database vendors support distributed transaction COM+ compatible way. Integration with such systems would be just a joy and I'd rather become system integrator my-self ;-)... However everybody knows that simply stays too far from the reality. Most of legacy/3rd party systems weren't (and aren't going to be) developed such way due to the number of reasons. The major reason now is probably that COM+ is relatively new technology. The major reason later could be related to the fact that distributed transactions COM+/DTC/XA way are way too expensive + they are incapable to be extended to the long running transaction over Internet (or other similarly unreliable media transport). Also note that not all databases (data sources) support distributed transactions COM+ compatible way (or just support them at all). That even concerns some of the Microsoft's own databases (like, I'd love to see distributed transactions support on Exchange Server...). So, even if I develop a completely new system relying exclusively on COM+ declarative transactions support (with future integration benefits as one of the major focus) I still would not be able to integrate my transactions with f.e Exchange Server, or some (fictional) John Smith's custom OLE DB provider because they simply don't support ITransactionJoin and family!?... Hello? And all that after I accepted significant extra expenses that system's performance is paying due to use of COM+/DTC distributed transactions, all just in favor of future integration benefits!?... In fact, COM+ declarative transactions are expensive in such way, that anyone who is doing real COM+ development surely heard of an advice to use declarative transactions only when it's absolutely necessary, otherwise just use local transactions (or db-vendor specific distributed transaction) and mark your component with transactions support "disabled"... Of course, COM+ provides elegant transactions model with transaction's stream bound to the transaction's root object + BYOT + Compensating Resource Mangers + Resource Dispensers (if former was not enough)... But face it: there are too many limitations to blindly start using them without looking into other considerable alternatives. And if we bring WebServices + Internet (HTTP, SMTP or any other Internet related transport protocol) and/or applications integration story up to the picture then integration the way of BizTalk server could become more attractive and reliable investment than going COM+ declarative transactions way. Ie. paradigm's shift back to the message based solution where you define XML messages + rules of their processing (workflow). Infrastructure provides you with the rest, like reliable execution, long-running compensating transactions (but no isolation, sorry) + much more... And when it concerns to the COM+ services in general - COM+ offers significant help for solving some common tasks of developing distributed systems beside of using declarative distributed transactions... And when it concerns to the last (COM+ distributed transactions) then COM+ benefits is rather exaggerated... -Valery. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
