Have you looked at TIP - "Transaction Internet Protocol"?
SCENARIOSuppose I call the following method in a ServicedComponent:
public void DoMixedUpdates()
{
DoDBUpdateA();
DoDBUpdateB();
CallWebService1ToDoDBUpdateC();
CallWebService2ToDoDBUpdateD();
DoDBUpdateE();
DoDBUpdateF();
}
All 6 calls perform DB updates but the middle 2 calls call "plain old" ASMX web services that each then call a component that performs DB update C and DB update D.
QUESTION
On the current shipping versions of Windows Server 2003, does
a) .NET 2.0 with WSE 3.0 or
b) .NET 2.0 without WSE 3.0
support the "transactional web service" scenario depicted above?
or c) is Windows Commucation Foundation (Indigo) needed because that is the first place where Microsoft is supporting the WS-Atomic Transaction protocol?
or d) is there will be an new version of WSE "shipping soon" that will support WS-Atomic Transaction that you should use until WCF is released?
Thanks,
Michael.
Michael:
ASMX does not provide any automatic support for flowing atomic transactions through web service messages. As you know, WCF does provide support for this, with both WS-AtomicTransaction and OLE Transactions as transaction propagation protocols.
Do you own the contract and implementation of both the web service client and the server? If so, you can use ASMX to manually flow a transaction as an explicit byte[] parameter on your web service operations. To do this, you can use the System.Transactions.TransactionInterop class to marshal the transaction (on the client) and unmarshal it (on the server).
Note that for this to work correctly, your client and server will need to be mutually addressable over RPC, just as if you were flowing transactions over COM+ or Enterprise Services. This is because the two transaction managers will resolve the outcome of the transaction using the two-phase-commit protocol over their own independent communications pipe (OLE Transactions over RPC, in this case). For what it's worth, this restriction applies to WCF's OLE Transaction support as well.
I can't comment authoritatively on the features that future versions of WSE will provide. You may want to ask in a forum dedicated to WCF or WSE itself.
Hi Michael,
Have you considered using MTS/DTC's Transaction Internet Protocol (TIP) support for your requirement? (Lots of documentation/discussion available on MSDN and elsewhere)
For you to successfully PUSH your local transaction to the node hosting the Web service(s) then that node would need to support the TIP protocol, but if you're running DTC everywhere then that shouldn't be a problem. Simply pass the resulting transaction URL as an additional parameter to your Web Service/RPC/Socket/Whatever.
Regards Richard Maher
Code Snippet: -
#include <XoleHlp.h>// define DTCGetTransactionManager (requires xolehlp.lib)
. . .
ITransactionDispenser*pTransactionDispenser;
ITransaction *pTransaction
hr = DtcGetTransactionManager(
NULL,// pszHost
NULL,// pszTmName
IID_ITransactionDispenser, // ID of the interface
0,// Reserved: must be null
0,// Reserved: must be null
0,// Reserved: must be null
(void **)&pTransactionDispenser// the interface
);
hr = g_pTransactionDispenser->BeginTransaction (
0,// Must be null
ISOLATIONLEVEL_ISOLATED,// Isolation level
ISOFLAG_RETAIN_DONTCARE,// Isolation flags
0,// Transaction options
(void **)&pTransaction);// The transaction object
ITipTransaction*tpTipTransaction;
Char*remoteTxUrl;
hr = pTransaction->QueryInterface (IID_ITipTransaction,(void **)&pTipTransaction);
hr = tpTipTransaction->Push(“tip://remotehost.co.uk/”,&remoteTxUrl);
I can think of no good reasons to use TIP and many not to (e.g. it is insecure, it requires COM interop in this scenario, it is insecure, it is being deprecated as of Vista, it is insecure... :)).
I would second Max's recommendation of using TransactionInterop to explicitly marshal, send the marshalled form over the wire, explicitly unmarshal with TransactionInterop on the service side, and let OleTx "flow" the transaction.
Hi Miguel,
> I can think of no good reasons to use TIP
Then let me enlighten you: -
1) TIP is a context-rich connection-oriented protocol.
2) TIP is extremely lightweight and very fast. With no debilitating layers of crud.
3) TIP’s two-pipe strategy permits it to be middleware neutral, and therefore places no restrictions on your application’s program-to-program infrastructure. You can use RPC or XML or MMQ or COM or plain Sockets and TIP will encompass all you critical updates with the ACID properties of a true 2PC.
4) TIP is an extremely “open” protocol and is unsurpassed for ease of implementation.
5) Run-Time discovery of transaction participants
I am happy to discuss these, and more, good reasons to use TIP at length if you wish but let us move on to your concerns: -
> it requires COM interop in this scenario
Can you please explain why that is? (BTW, what’s wrong with COM anyway?)
> it is being deprecated as of Vista
Neither I nor my customers have received notification of this from Microsoft. I look forward to reading the official notice, but it certainly doesn’t bode well for WS-AT if you’re having to burn your customers bridges behind them. My insecurity-meter is going off the scale at the moment; is this a Cane -v- Abel thing? Me, I’m all for pluralism and giving the customers what they want. “Best tool for the job” and not “One size fits all”. Maybe Microsoft is short of development dollars and needs to claw back the millions you’re outlaying on TIP development each year :-)
Anyway I’m looking forward to many more productive years with TIP transactions driven by that truly amazing product that is MSDTC!
> (e.g. it is insecure, . . ., it is insecure, . . ., it is insecure... :)).
I normally wouldn’t recommend throwing-stones as the most prudent course of action, especially for one with your choice of abode :-) but I certainly have to admire your bravado so let’s have at.
Please explain (in detail) TIP’s inherent security flaws and how these don’t apply to other protocols.
Admittedly, I haven’t seen TLS implemented anywhere with TIP but is there some reason that IPsec can not be implemented between two TIP TMs? VPNs? Firewalls?
It seems that a lot of MSDTC communication relies on Authenticated RPC, is that not correct?
(You gotta love lifting the bonnet on all this OO stuff to see the big RPC V8 there!)
Is it true that if a txn spans a box that is not part of the Windows domain then you need to turn off Mutual Authentication. Can you have Authenticated RPC if you do this? Under what circumstances (registry settings) are other DTC transactions insecure?
Is it true that with WS-AT all transaction participants have to be “Pre-Authorized”? Do we have to implement the “Recommended” WSSec, WSTrust and WSSecConv?
That should be enough to get us started ;-)
Regards Richard Maher
PS. Just dug out my copy of RFC 2371 and thought this paragraph on page 1 could be relevant (Good to see Johannes Klein is still there): -
"Numerous two-phase commit protocols have been implemented over the years. However, none of them has become widely used in the Internet, due mainly to their complexity. Most of that complexity comes from the fact that the two-phase commit protocol is bundled together with a specific program-to-program communication protocol, and that protocol lives on top of a very large infrastructure."
The more things change hey?
Hi Miguel,
It looks like the MSDTC parts of Vista are out the door, and you guys/gals are emerging from the cave :-) so I'm just replying to my own post in an attempt to put it on your radar.
If you had already seen it and were, in fact, ignoring it then please feel free to continue. But if you had missed the above then here it is (again :-)
Regards Richard Maher
Richard,
You raised a number of questions around the TIP protocol, and our support for it. I want to cover some background around the protocol, where we are with it, and where our implementation is likely to go.
I also want to cover (and contrast) aspects as they relate to WS-AT.
TIP was conceived in the 90s as a standard 2PC protocol to encourage interoperation between vendors. That it is an IETF standard, and one that we contributed to, is a sign of how seriously we took the goal to interwork between vendors. TIP is effectively a least common denominator 2PC protocol, and one that, in fact, does not represent the MSDTC feature set with full fidelity. Simplicity, in order to encourage takeup, was the order of the day.
It is also not especially fast as 2PC protocols go. Many optimizations, in both state machine and format, were not included -- again, presumably with the goal of simplicity of takeup.
By any objective measure, this protocol has failed to achieve significant cross-industry takeup. It has some limited support from a small handful of vendors, with Microsoft as almost certainly the most ardent and visible. The time is long past when it would have been taken up if it was going to be. Understanding this is important when we come later to discuss WS-AT.
On a technical level, TIP was written in a gentler time. There are mandated security issues in the specification, even setting aside TLS vs non-TLS transports. To be fully conformant is to expose unnecessary attack vectors. MSDTC, by default, is not fully conformant (although that can be enabled if needed).
So, would I recommend that a customer use TIP? Not if it could be avoided, and not in an environment with hostile network access.
Will we continue to support its use? Yes, of course.
However, what will change is that it is going to get progressively more difficult to enable TIP access. In Vista, the MSDTC administration dialog boxes no longer list TIP as an option, and the installation will disable TIP. The API that can be used to query and update configuration options (IDtcNetworkAccessConfig*) is still supported, and can still be used to enable TIP.
I cannot say if it will get yet more difficult post-Vista.
Why don’t we extend our TIP implementation to support TLS? First, I hope that it is clear from the text above that we have no interest in promulgating an insecure protocol. With TIP we effectively have three choices: disable it, or extend the implementation to support TLS, or to do that and to rev the protocol document to remove the other attack vectors.
If TIP had succeeded as an interoperation protocol, the third option would be the one that we would want to do -- it would be a necessary step to secure interoperation. But it didn't. What we have done is to apply the lessons we've learned from TIP to WS-AT.
Of course, even if TIP had a role in normal use between MSDTC services, it would still make sense to do the second option. This is because if we're only interested in working with ourselves there's no real need to worry about the other aspects of the standard that we've had to violate to achieve any level of security. However, MSDTC to MSDTC traffic using TIP is pretty much always a bad topology even just considering feature completeness or performance.
Looking forward at the potential for interoperation, frankly, the takeup is in WS-AT. Based on the vendors involved with the OASIS effort, the takeup and interest is already higher than I am aware of for TIP implementations through to today.
At the end of the day, WS-AT has better takeup, better feature fidelity, and much better security than TIP. Our goal remains for successful transaction interoperation, and we're actively working to achieve that.
Hi Jim,
Thanks for the reply. (I hope I didn't scare Miguel off)
I want to take the time to address some of the issues raised in your post in detail, but let me shoot one question out there quickly and maybe we can resolve it in isolation: -
Q1: "With regard to TIP, what would TLS give us (or would've given us) that IPsec today won't?"
What's wrong with my System/Network Manager saying "Secure everything going to port (for example) 3372 from these servers, and set the firewalls shut out the rest."
What don't you like about IPsec, or why isn't it up to the task? Is it only TIP where it is inadequate?
Cheers Richard
PS. Going back for Christmas?
Richard,
Most simply, security by an admin doing something actively correct doesn't meet our 'secure by default' goals. Having to configure IPSec doesn't do that, nor does TLS support in TIP alone do that (due to the other attack vectors).
Jim.
PS: Nope, the kids are coming here...
TIP was a non-starter for us.
