What am I missing about WCF?

Question

I've been developing in MS technologies for longer than I care to remember at this stage. When .NET arrived on the scene I thought they hit the nail on the head and with each iteration and version I thought their technologies were getting stronger and stronger and looked forward to each release.

However, having had to work with WCF for the last year I must say I found the technology very difficult to work with and understand. Initially it's quite appealing but when you start getting into the guts of it, configuration is a nightmare, having to override behaviours for message sizes, number of objects contained in a messages, the complexity of the security model, disposing of proxies when faulted and finally moving back to defining interfaces in code rather than in XML.

It just does not work out of the box and I think it should. We found all of the above issues while either testing ourselves or else when our products were out on site.

I do understand the rationale behind it all, but surely they could have come up with simpler implementation mechanism.

I suppose what I'm asking is,

• Am I looking at WCF the wrong way?
• What strengths does it have over the alternatives?
• Under what circumstances should I choose to use WCF?

OK Folks, Sorry about the delay in responding, work does have a nasty habbit of get in the way somethimes :)

Some clarifications My main paint point with WCF I suppose falls down into the following areas While it does work out of the box, your left with some major surprises under the hood. As pointed out above basic things are restricted until they are overridden

1. Size of string than can be passed can't be over 8K
2. Number of objects that can be passed in a single message is restricted
3. Proxies not automatically recovering from failures
4. The amount of configuration while it's there is a good thing, but understanding it all and what to use what and under which circumstances can be difficult to understand. Especially when deploying software on site with different security requirements etc. When talking about configuration, we've had to hide lots of ours in a back-end database because security and network people on-site were trying to change things in configuration files without understanding it.
5. Keeping the configuration of the interfaces in code rather than moving to explicitly defined interfaces in XML, which can be published and consumed by almost anything. I know we can export the XML from the assembley, but it's full of rubbish and certain code generators choke on it.

I know the world moves on, I've moved on a number of times over the last (ahem 22 years I've been developing) and am actively using WCF, so don't get me wrong, I do understand what it's for and where it's heading.

I just think there should be simplier configuration/deployment options available, easier set-up and better management for configuration (SQL config provider maybe, rahter than just the web.config/app.config files).

OK, back to the daily grid.

Thanks for all your replies so far.

Kind Regards Noel

Answer 1

I'll address the rest of your issues after clarification. In the meantime, I can address your question on when you should choose to use WCF: always.

WCF is the replacement for the old ASMX technologies, including WSE. It is also the replacement for .NET Remoting. It is the only technology upon which high-level communications features in .NET will be based for the forseeable future.

For example, consider Windows Azure. It was not inevitable that the new concept of "cloud computing" would have its communications aspects covered by WCF. Yet, WCF was flexible enough to be extended to cover those cases, with very little change in code.

If you're having trouble with WCF, then you'd do well to make sure Microsoft knows about it. WCF is the present and future of web service and other service-oriented development in .NET, so they've got a very strong incentive to listen to you and resolve your pain points. Either contact them directly through Connect, or ask questions here on SO (tag with WCF, please), and a lot of people will help you.

Answer 2

I use WCF all the time now and I share your pain. It seems like it was grossly over-engineered, but we are going to be stuck with it for a long, long time so I'm trying to learn it.

One thing I am certain about, XML sucks. I've had nothing but problems using XML to control it and have since switched to handling everything via code.

Answer 3

Looking at how you mention XML and SQL, you are using WCF to build a web application or an actual web service (service on the Web, and not just SOAP exchange).

It helps thinking about WCF as a replacement for .NET Remoting (or DCOM, CORBA etc), which also happens to support web services as one of the transports. Interfaces declared in assemblies, behavior of proxies, certain configuration options and other aspects of the framework that look unnatural and complicated from perspective of web apps - actually do work out of the box for DCOM-style systems of distributed objects.

To answer the question: no, you are not missing anything and using WCF for web applications is complicated, because WCF is not a framework for building web applications. Probably such framework can be built on top of it, but I would hate to see WCF itself changed to move into web realm.

Answer 4

To address the problem of maintenance nightmare of application config, some standard like UDDI or WS-Discovery exist, WS-Discovery will be supported by WCF in .NET 4.0.

Keeping the configuration of the interfaces in code rather than moving to explicitly defined interfaces in XML, which can be published and consumed by almost anything. I know we can export the XML from the assembley, but it's full of rubbish and certain code generators choke on it.

Can you be more explicit ? I think you are talking about service behavior configured in code. You can easily code behavior extensions to configure what your are talking about in config file instead of code BUT I think that if microsoft didn't do that there is a good reason. For example a service with this behavior :

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall, ConcurrencyMode=ConcurrencyMode.Single)]

The implementation knows that the instance is not shared between multiple thread so it's developed differently than :

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)]

In this case the service implementation should take care about concurency problems. The implementation is coupled with the attribute ServiceBehavior, so moving this behavior in a XML file is not a good idea.

What if you can change a InstanceContextMode.PerCall service to a InstanceContextMode.Single service inside the config file ? You break the application !

Answer 5

The concerns you listed were:

---

1. Size of string than can be passed can't be over 8K
2. Number of objects that can be passed in a single message is restricted
3. Proxies not automatically recovering from failures
4. The amount of configuration while it's there is a good thing, but understanding it all and what to use what and under which circumstances can be difficult to understand. Especially when deploying software on site with different security requirements etc. When talking about configuration, we've had to hide lots of ours in a back-end database because security and network people on-site were trying to change things in configuration files without understanding it.
5. Keeping the configuration of the interfaces in code rather than moving to explicitly defined interfaces in XML, which can be published and consumed by almost anything. I know we can export the XML from the assembly, but it's full of rubbish and certain code generators choke on it.

---

here's my take:

(1) addressed a valid concern that customers had with ASMX. It was too wide-open, with no way to easily control it. The 8k limit is easily lifted if you know where to look. I guess you can count that as a surprise, but it's more of a one-time thing. Once you know about it, you can lift it and be done with it forever, if you choose.

(2) is also configurable.

(3) is known, but there are boilerplate ways to work around this. The StockTrader code for example, demonstrates a proven pattern. You can re-use the code in your own app. Not sure if this is fixed in WCF for .NET 4.0. I know it was an open request.

(4) The config is a beast. This is a concern for a lot of people. The problem here is that WCF is so flexible, and config of all of that flexibility is exposed through xml files. It can be overwhelming. An approach that seems to work is to take it in small bites, as you need it.

(5) I don't understand.

Answer 6

Hi Folks, thanks for all the replies. Like I said at the start I do understand WCF, but do think it is over kill so most situations and that it should be easily configured with configured deployment options protected somehow. Also finding out about max string sizes, number of objects in a messages when your application is deployed across multiple servers and some 4,500 clients with proxies is not the nicest thing in the world to explain and then recover from.

As for defining contracts in XML, maybe it's because I've been developing for 20+ years but it makes perfect sense to me and 10,000's of others. Have people already forgotten about IDL (Interface Definition Language) used in CORBA and COM (MSIDSL there though, wouldn't you know) for decades. There are major benefits to be gained from defining your interfaces outside of your environment.

For example Because we have our interfaces defined in XML it allows us to do code generate the following.

• .NET Web-Service, delegating down to a hand written business layer
• .NET Classes to represent the schema layer and messages.
• Java Classes to represent the schema layer and messages.
• COM Classes to represent the schema layer and messages.
• .NET Proxies to access those services
• Java Proxies to access those services
• COM Proxies to access those service
• Automatic marshaling layers when entities/messages change versions v01 -> v02

Now if the schema is defined in code, it's just plain difficult to get all that out of the box using open source utilities.

Anyhow there was a mixed bag of responses and again I'm not WCF bashing, I do use it, I don't love it, I do think there are short comings there and unnecessary complexity but sur what the hell, we've all lived through worse.

Answer 7

Biggest advantage of using WCF from a programmer's point of view: separates the definition of exposed services (operations, contracts, etc.) from the protocol's specific details, unlike ASMX where you expose a class as a web service directly in the code using attributes. Using a real example of mine: we where able to easily switch the transport protocol between web services and named pipes, whatever suited better the deployment and performance needs, without changing a line of code.

Answer 8

WCF is intended to SOA methodologies. Work professionally using it is a nightmare. I delivered a SOA solution using WCF as tool and hell, hundreds configurations and hidden tips! My past distributed solution using old style Web Services and Remoting were more stable. I've spent days working out the solution for the error "The underlying connection was closed: An unexpected error occurred" which makes no sense to happen for one method among 4 in the same contract. I'm very disappointed. It took me back through time where .net was first introduced with lots of promises and when we got hands on, hell, log problems came up!