The discussion about Reliable Messaging and WCF is widening today with comments from Clemens, Shy Cohen and even Dare Obasanjo. This is quite an interesting discussion which offers those of us that haven't followed the specs recently a glimpse about the kind of services offered by WS-ReliableMessaging and how WCF implements it. I for one certainly appreciate Shy and Clemens speaking more clearly and openly about the issues involved.
That said, one has to wonder just how useful WS-RM is in the real world if, as Clemens says, it doesn't necessarily force implementors (and more importantly, endpoints claiming to support it) to actually be reliable. As Dare quite correctly (imho) points out, it's application and server crashes that usually cause the problems in the first place. Quite honestly, I personally haven't had/seen a need for services with In-Order-Delivery and At-Most-Once-Delivery semantics were those precise semantics didn't imply the need for a Real Reliable messaging (i.e. the kind that MSMQ or MQSeries and such can offer, or webservices with a lot of built in persistence and hand built support), and not just the illusion-of-reliability (if I may be so bold as to call it that) offered by WS-RM.
Do notice, however, that I clearly use an AND on the previous paragraph. There are a few scenarios where you might need, for example, AtMostOnce semantics which can be easily guaranteed by the receiving application even without a reliable queued-based transport. The real question would be: Would you be satisfied in that scenario with what WS-RM (and thus WCF's implementation)? Probably not, since if that is your requirement, then surviving restarts is probably something you require, period, and that implies persistence you'd need to bake into your solution yourself.
The whole Reliable-debacle as well as the recent thread on WCF's lack of support for Partial Trust scenarios, do bring some interesting questions to the table as to whether moving to WCF is a good thing for some teams. Now, don't get me wrong, I'm quite excited about WCF itself, but, as luck happens, those of us in the trenches sometimes have to make hard decisions about whether to go with a technology or not, weighting not only the coolness factor but also other things like training, support, prerequisits, complexity and so on.
On using WCFSo these two topics have caused me to think what I would do if I were in the situation of requiring one of the two things above, and whether I'd go with the recommendations provided so far to "work around" those limitations in the product. Quite a few times I've been asked to help a team decide which technology to use to develop a solution, and, quite frankly, one of the things I personally worry more about in those scenarios is complexity: Will using X technology make it harder to deploy? Are team members familiar with the intrincasies in Y product? Does at least someone in the team know technology Z good enough to help out her team mates if shit happens? Will using technology W make it easier to diagnose problems?
These topics worry me a little with WCF (yes, not a whole lot as I'm not in that position right now :)), after the answers given. Consider my considerations (how redundant!) for them, if you please:
- WCF and Partial Trust: Someone suggested that to work around this you created a regular .NET service proxy to the WCF service using wsdl.exe (or VS' Add Web Reference), and configured WCF with a regular HTTP protocol binding. That's cool. Or is it? Let's consider: If the team develops both service and consumer, will having to deal with the two technologies cause any pain? Will it make it harder to diagnose problems? So, one does have to wonder, if you find yourself in this position, why use WCF to create the server side instead of using good old, well understood, ASMX WebServices? After all, you obviously don't need any of WCF's advanced features (like security).
Some of you might scream out of the top of your lungs right now: "But creating WCF Services is just as easy as creating ASMX Services, you just have to change the attributes used!". True, but only up to a point. Sure, writing trivial/initial services in both technologies is just as easy on both. But, that's only part of the equation, and unless you can address the other considerations (i.e. you or someone in your team is already quite familiar with WCF to start with), I'd say go with what's best known, simpler, and less likely to break. But hey, that's just my opinion :)
- Reliability: So how about reliable messaging? Shy Cohen quite correctly points out that if you need real reliable messaging with Indigo you should use WCF over MSMQ, whose transactional queues already provide this kind of support. This one does have one clear answer, thankfully, I think. If you need advanced security, then by all means add WCF to the mix, and again, find someone who knows what he's doing. If you don't, hey, System.Messaging has a very nice, intuitive and simple API that works, is widely documented, and easy to find information and samples about.
Let me stress that this post is not about finding reasons to avoid WCF. Quite the contrary, I believe most people should start seriously considering WCF, or at least start building services that are easier to migrate to WCF in the future. It's just that sometimes going with what is there and works is just a better solution, and helps you avoid unneeded complexity. There's something attractive about not making trouble for yourself, sometimes.
