I asked another question stating that the I am unable to use WCF in a new Web Service project and have come to see that it seems to be the technology to use in regards to extensibility and security.
My question is a simple one:
How can I persuade management (and developers for that matter) to move over to using WCF as opposed to other web service technologies (ASMX/CFC)? They won't be concerned with a comparison between the types (especially with regard to ASMX), simply what there is to gain.
The benefits really depend on your specific scenario, but in general, there are many.
WCF was designed for handling services from the start, and does so in a very clean manner. It addresses many of the shortcomings of other technologies. The main differences are in the flexibility WCF brings to the table.
For example, it's pretty easy to do RESTful services using ASMX or WCF. However, if you later need to add SOAP, transformation, more complex authentication, some asynchronous communication with rich clients, etc - you can easily reconfigure and adapt a WCF service application to accommodate. With previous technologies, you'd be stuck doing a re-architecture or a rewrite.
In response to your comment re: security, I'd recommend also reading up on MSDN about WCF's Security Model. It's actually far superior to all of the older Windows technologies for service architecture, so if security is the focus, then WCF is definitely the way to go.
This is especially true if you're dealing with multiple authenitication sources. The WCF authentication model is standards based, but extensible. It's much simpler to implement a secure service that's accessable via multiple forms of authentication, especially if you need to integrate with other authentication services.
You can't really state what there is to gain without at least indirectly comparing the two types - otherwise you have no baseline on what the improvements are.
Generally though, WCF will give you the following:
Not limited to SOAP. This can make services much easier to consume, and much, much more performant. This is probably the biggest in my mind as an ASP.net developer.
Performance. WCF can be much faster.
Anything can host a WCF service, so you're not limited to IIS. Gives you much more flexibility in your architectures.
The best thing you can do is read MSDN documentation on it, as Microsoft is pushing WCF over ASMX in a big way, and have provided a lot of documentation around the advantages. Start here: Differences Between ASMX and WCF Services.
Plain-vanilla ASMX does not support WS-Security or any of the other WS-* extensions at all. In order to implement those, you need to use Microsoft's Web Services Enhancements (WSE).
WSE was a hold-over solution that Microsoft implemented in haste in order to satisfy the need for .NET Web Services to conform to the WS-* specifications. WCF is not just an upgrade to that, it is a flat-out replacement. Because of that, WSE (and subsequently ASMX, if you want to use the WS-* protocols) is officially an unsupported product.
So - does your management want to start a new project using an officially unsupported product?
Here are all of the things you won't get with WSE:
Technical support. Maybe someone on Stack Overflow can help you, but Microsoft can't.
Bug fixes. The Visual Studio integration of WSE 3.0 (the last released version) does not work in Visual Studio 2008. It also does not work in Visual Studio 2005 if you're running Vista x64, or Windows 7.
New features. WCF offers performance improvements, REST protocols, message queuing, binary serialization over TCP/Named Pipes, WCF Data Services (Linq over Web Services), and a whole host of new opportunities. You will never get any of these with WSE/ASMX.
Active Directory integration. Oh, sure, it "worked" in WSE using the kerberos assertion - very, very poorly. WCF is so easy to integrate with Active Directory that it's secured this way by default.
Fault contracts. Exception handling in WSE/ASMX is brutal, everything comes across the wire as a SoapException or ResponseProcessingException. With WCF, you can actually send back strong-typed exceptions (faults) back to the client.
Callback contracts. Want to start some long-running operation on the client side and be notified of completion/status updates from the server? Tough - hope you like writing polling loops.
Interoperability with new technologies. You can sometimes get a WSE 3 service to talk to a WCF or Java service, with some finagling, but not necessarily the other way around. And if you're using a version of WSE prior to 3.0, forget it. By contrast, WCF was able to support Azure and MSMQ with a few trivial configuration changes.
Starting a new project using ASMX/WSE is equivalent to starting a new project on the .NET 1.1 framework. Your product will be "legacy" before the first line of code is ever written.
If your management understands the term "legacy technology", and I suspect they do, you might want to throw that around a bit. Also "obsolete." Also "unsupported."
WCF has been around for, I think, 4 years now. That's more than enough time for any serious issues to be discovered in the wild. There is no reason whatsoever not to trust it as a technology.
And in fact, WSE 3 was released at the tail end of 2005, so it is not much older than WCF! It's illogical to trust a 5-year-old technology but not a 4-year-old technology - especially when support for the 5-year-old technology was discontinued 2 years ago.
WCF provides SOA -
Single biggest bonus for me is: reliability both in delivery and transactions.
Staying with tried, tested and well understood technology can be the best option - there will be a learning curve with any new technology both for us developers and for rollout, support etc.
WCF is better, much better, but never forget the above when considering any new technology or methodology.
Microsoft now considers ASMX to be "legacy technology". Ask your management if it's a good idea to start with legacy technology.