Does WCF raise the bar or just the complexity level?

Okay, here we go. First, Michele Leroux Bustamante's book has been updated for VS2008. The website for the book is not gone. It's up right now, and it has tons of great WCF info. On that website she provides updated code compatible with VS2008 for all the examples in her book. If you order from Amazon, you will get the reprint which is updated.

WCF is not only a replacement for ASMX. Sure it can (and does quite well) replace ASMX, but the real benefit is that it allows your services to be self-hosted. Most of the functionality from WSE has been baked in from the start. The framework is highly configurable, and the ability to serve multiple endpoints over multiple protocols is amazing, IMO.

While you can still generate proxy classes from the "Add Service Reference" option, it's not necessary. All you really have to do is copy your ServiceContract interface and tell your code where to find the endpoint for the service, and that's it. You can call methods from the service with very little code. Using this method, you have complete control over the implementation. Regardless of the method you choose to generate a proxy class, Michele shows both and uses both in her excellent series of webcasts on the subject.

Michele has tons of great material out there, and I recommend you check out her website(s). Here's some links that were incredibly helpful for me as I was learning WCF. I hope that you'll come to realize how strong WCF really is, and how easy it is to implement. The learning curve is a little bit steep, but the rewards for your time investment are well worth it:

• Michele's webcasts: http://www.dasblonde.net/2007/06/24/WCFWebcastSeries.aspx
• Michele's book website (alive and updated for VS2008): http://www.thatindigogirl.com/

I recommend you watch at least 1 of Michele's webcasts. She is a very effective presenter, and she's obviously incredibly knowledgeable when it comes to WCF. She does a great job of demystifying the inner workings of WCF from the ground up.

I typically use Google to find my WCF answers and commonly find myself on the following blogs:

Blogs with valuable WCF articles

• http://blogs.msdn.com/drnick/default.aspx
• http://blogs.msdn.com/wenlong/default.aspx
• http://blogs.thinktecture.com/buddhike/
• http://www.dasblonde.net/default.aspx

Other valuable articles I've found

• http://blogs.conchango.com/pauloreichert/archive/2007/02/22/WCF-Reliable-Sessions-Puzzle.aspx
• http://blogs.msdn.com/salvapatuel/archive/2007/04/25/why-using-is-bad-for-your-wcf-service-host.aspx

I'm having a hardtime to see when I should or would use WCF. Why? Because I put productivity and simplicity on top of my list. Why was the ASMX model so succesful, because it worked, and you get it to work fast. And with VS 2005 and .NET 2.0 wsdl.exe was spitting out pretty nice and compliant services.

In real life you should have very few communication protocols in your architecture. This keeps it simple an maintainable. If you need to acces to legacy systems, write specific adapters for them so they can play along in the nice shiny and beautiful SOA world.

WCF is much more powerful than ASMX and it extends it in several ways. ASMX is limited to only HTTP, whereas WCF can use several protocols for its communication (granted, HTTP is still the way most people will use it, at least for services that need to be interoperable). WCF is also easier to extend. At least, it is possible to extend it in ways that ASMX cannot be extended. "Easy" may be stretching it. =)

The added functionality offered by WCF far outweighs the complexity it adds, in my opinion. I also feel that the programming model is easier. DataContracts are much nicer than having to serialize using XML serialization with public properties for everything, for example. It's also much more declarative in nature, which is also nice.

Wait.... did you ever use .NET Remoting, cause thats the real thing its replacing. .NET Remoting is pretty complicated itself. I find WCF easier and better laid out.

I don't see it mentioned often enough, but you can still implement fairly simple services with WCF, very similar to ASMX services. For example:

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class SimpleService
{
    [OperationContract]
    public string HelloWorld()
    {
        return "Hello World";
    }

}

You still have to register the end point in your web.config, but that's not so bad.

Eliminating the verbosity of the separated data, service, and operation contracts goes a long way toward making WCF more manageable for me.

VS2008 includes the "Add Service Reference" context menu item which will create the proxy for you behind the scenes.

As was mentioned previously, WCF is not intended solely as a replacement for the ASMX web service types, but to provide a consistent, secure and scalable methodology for all interoperable services, whether it is over HTTP, tcp, named pipes or MSMQ transports.

I will confess that I do have other issues with WCF (e.g. re-writing method signatures when exposing a service over basicHTTP - see here, but overall I think it is a definite imrovement

If you're using VS2008 and create a WCF project then you automatically get a test harness when you hit run/debug and you can add a reference without having to use svcutil.

My initial thoughts of WCF were exactly the same! Here are some solutions:

1. Program your own proxy/client layer utilising generics (see classes ClientBase, Binding). I've found this easy to get working, but hard to perfect.
2. Use a third party implementation of 1 (SoftwareIsHardwork is my current favourite)

MSDN? I usually do pretty well with the Library reference itself, and I usually expect to find valuable articles there.

In terms of what it offers, I think the answer is compatibility. The ASMX services were pretty Microsofty. Not to say that they didn't try to be compatible with other consumers; but the model wasn't made to fit much besides ASP.NET web pages and some other custom Microsoft consumers. Whereas WCF, because of its architecture, allows your service to have very open-standard--based endpoints, e.g. REST, JSON, etc. in addition to the usual SOAP. Other people will probably have a much easier time consuming your WCF service than your ASMX one.

(This is all basically inferred from comparative MSDN reading, so someone who knows more should feel free to correct me.)

WCF should not be thought of as a replacement for ASMX. Judging at how it is positioned and how it is being used internally by Microsoft, it is really a fundamental architecture piece that is used for any type of cross-boundary communication.

I believe that WCF really advances ASMX web services implementation in many ways. First of all it provides a very nice layered object model that helps hide the intrinsic complexity of distributed applications. Secondly you can have more than request-replay messaging patterns, including asynchronous notifications from server to client (impossible with pure HTTP), and thirdly abstracting away the underlying transport protocol from XML messaging and thus elegantly supporting HTTP, HTTPS, TCP and other. Backward compatibility with "1-st generation" web services is also a plus. WCF uses XML standard as the internal representation format. This could be perceived as advantage or disadvantage, especially with the growing popularity "fat-free alternatives to XML" like JSON.

The difficult things I find with WCF is managing the configurations for clients and servers, and troubleshooting the not so nice faulted state exceptions.

It would be great if anyone had any shortcuts or tips for those.

I find that is a pain; in that I have .NET at both ends, have the same "contract" dlls loaded at both ends etc. But then I have to mess about with a lot of details like "KnownType" attributes.

WCF also defaults to only letting 1 or 2 clients connect to a service until you change lots of configuration. Changing the config from code is not easy, shipping lots of comfig files is not an option, as it is too hard to merge our changes into any changes a customer may have made at the time of an upgrade (also we don't want customers playing with WCF settings!)

.NET remoting tended to just work most of the time.

I think trying to pretend that .NET to .NET object based communications is the same as sending bit so of Text (xml) to an unknown system, was a step too far.

(The few times we have used WCF to talk to a Java system, we found that the XSD that the java system gave out did not match what XML it wanted anyway, so had to hand-code a lot of the XML mappings.)