49

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 habit of get in the way sometimes :)

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 assembly, 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 simpler configuration/deployment options available, easier set-up and better management for configuration (SQL config provider maybe, rather than just the web.config/app.config files).

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Bigtoe
  • 3,372
  • 1
  • 31
  • 47
  • 2
    Useful discussion if rephrased as a "what do you do to overcome the complexities of WCF" question. And marked it as community wiki – Peter Lillevold May 29 '09 at 08:10
  • Also, I think this needs more detail about what problems you're seeing. Perhaps you should ask a number of separate questions on the individual problems, then summarize the answers here. I don't think you'll get a lot of agreement about such a broad question. – John Saunders May 29 '09 at 08:18
  • This was closed once as not a real question, and it's still horribly open/attack like – blowdart May 29 '09 at 08:35
  • @blowdart: that's why I asked him to clarify and maybe ask some smaller questions. This is also not the first time I've heard this. I've worked with some before who have expressed this, and have been able to pinpoint their issues. I'd like to try to do the same here, if the OP will cooperate. – John Saunders May 29 '09 at 08:38
  • 1
    I can't back up your statement: "It just does not work out of the box" - I think it does - BIG TIME! It's much more flexible and powerful and useful to work with than ASMX, Remoting and what-not together. It's a unified communication framework - it's quite compelling, actually! – marc_s May 29 '09 at 09:02
  • 8
    You're not missing anything. It will die out just like DCOM did, exactly for the reasons you outline. WS or SOAP never kicked off and unlikely they ever will. Dare covered this extensively and you can see what Amazon and Google offer. Very simple and effective apis, and non of the lock-in you get with wCF. And don't forget there is a whole class of applications that simply do not fit for functional requirements when choosing WCF. One of them being good streaming models, high-performance apps, P2P, games, you name it – rama-jka toti May 29 '09 at 09:12
  • 2
    And then MS realised oh wtf: json, pod, rest and the rest. Thus a sudden rush to patch more models and classes into the framework. Typical overengineering.. – rama-jka toti May 29 '09 at 09:17
  • Updated description above with some additional points. Thanks to Binary warrior for re-opening and to all contributions so far. I do love stack-overflow. – Bigtoe May 29 '09 at 09:27
  • Ahem, that's "Binary WorriER", as in "one who worriers" it is a "pun" or "play on words" :) – Binary Worrier May 29 '09 at 09:31
  • @Majkara Tito. The ability to add more models is the whole point of WCF. JSON, Rest, etc. they are all supposed to look the same to the application. – Jonathan Allen May 29 '09 at 09:44
  • 4
    Yes it is, but REST in WCF only supports 1 verb per handler, you can't have GET & POST on the same handler. JSON suffers from similar problems, data returned is wrapped in non-standard wrapped format. AJAX ScriptManagers can't be imbeded in user controls for AJAX support, need to resort to script libraries like the excellent dojo/jquery to give these capabilities. So WCF still has issues even with so called standard implementations like REST & JSON. – Bigtoe May 29 '09 at 11:48
  • @Bigtoe, there are not such thing as a standard REST specification. ;-). Anyways,right now MS is a mess and nobody can says "hey,MS will use this technology for the next decade". Example: Silverlight. – magallanes Nov 27 '12 at 16:57

8 Answers8

15

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.

Jonathan Allen
  • 68,373
  • 70
  • 259
  • 447
  • 4
    Have you tried using the WCF Configuration Tool (SvcConfigEditor in the Windows SDK Directory)? No XML. – John Saunders May 29 '09 at 12:26
  • 5
    What do you mean no XML? The XML is still there cluttering up my app.config file with useless garbage. – Jonathan Allen Jun 03 '09 at 17:42
  • 1
    it may be cluttering your app.config file, but you don't need to read it. Just collapse it. – John Saunders Mar 03 '10 at 03:51
  • 7
    That doesn't help the production support guys who only have notepad available on the server. – Jonathan Allen Dec 03 '10 at 23:01
  • 1
    The WCF Configuration Tool is nice when you are a first configuring a project but is really just a pretty wrapper on an ugly section of xml (much like #region tags around ugly code). – marr75 Mar 18 '13 at 20:08
8

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.

Cheeso
  • 189,189
  • 101
  • 473
  • 713
7

I vastly prefer ASP.NET MVC and Web API over WCF. If I had to summarize WCF to a developer who was just being introduced to it, I would say, "WCF is a well-meaning attempt to replace over-engineered, Java EE style RPC development." Unfortunately, many of the decisions made require you to become an expert in configuring low level, unimportant items (message sizes, timeouts, uninteresting protocol elements, etc.) while abstracting absolutely critical pieces (URL design, parameter serialization, response serialization, etc.). The difference in productivity and aggravation between teams I know using WCF vs. Web API is night and day.

To come clean a little: I have always hated the core concept of .NET Remoting. I feel that developers need a thorough understanding of the resource structure of their application and how these resources are serialized. Furthermore, the use of the "POST" verb for simple data retrieval is worrisome in a read heavy application that needs to scale.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
marr75
  • 5,666
  • 1
  • 27
  • 41
4

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.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • Updated description above with some additional points. Thanks to Binary warrior for re-opening and to all contributions so far. I do love stack-overflow. – Bigtoe May 29 '09 at 09:24
  • 3
    "Why the downvote? Is any part of this inaccurate?" -> "when you should choose to use WCF: always" - so, in short, yes. – mattmc3 Dec 02 '10 at 22:07
  • @mattmc3: please elaborate: in which case do you feel that WCF should not be chosen? – John Saunders Dec 02 '10 at 22:09
  • Just to clarify- I wasn't the down vote to which you referred. However, in answer to your question, WCF should perhaps not be chosen (yet) for those cases when a simple ASMX file would still meet your organization's needs. While WCF is obviously where MS is going, the excessive and convoluted configuration, poor errors, and removal of the test form make it a difficult transition. Like the 1.0 version of Entity Framework, it's looking promising but it was not there yet. For many, it might not be worth fixing something that isn't broken just to go with the new-shiny-thing. – mattmc3 Dec 07 '10 at 02:27
  • 1
    @mattmc3: you're wrong on several fronts. WCF is not where Microsoft is going. They've been there for several years now. ASMX is where they've been, and it is now considered to be a "legacy technology". As such, I do not consider it appropriate for most production uses in new code. I think also that you must not have been paying attention to .NET if you feel the configuration is an issue. The test form was useless for any operation that passed or returned complex objects in any case, and could not be used to test anything other than http services. – John Saunders Dec 07 '10 at 02:30
  • @mattmc3: and ASMX was very badly broken in many ways, not least of which are the performance of the XML Serializer, lack of support for SOAP Faults, lack of support for any of the modern web services standards, and insufficient extensibility points. ASMX is a problem which has been fixed by WCF. – John Saunders Dec 07 '10 at 02:31
  • 3
    The needs of a business need not be dependent on what MS deems to be "legacy". We developers love to forget that because we like to play with new toys. Of course you're free to disagree, but don't believe that you or MS have convinced everyone to switch just for the sake of the switch. The WCF transition story, frankly, isn't that compelling yet on all fronts. For remoting though, WCF was a vast improvement. But for a quick and dirty intranet web service, you can lose too many precious hours mired in the web.config. – mattmc3 Dec 07 '10 at 02:34
  • @mattmc3: if Microsoft doesn't fix bugs in the code, then the business needs to consider it's "needs". Also, with respect, WCF has been out for four years now. You may want to learn it well enough to restate your concerns. – John Saunders Dec 07 '10 at 02:35
  • 3
    I've learned it, and have developed a fair number of them - but I've not been in any hurry to fix our old and working .ASMX services. Honestly, building RESTful `JsonResult`s from ASP.NET MVC controllers takes a small fraction of the development time so I'd recommend skipping formal webservices all together if possible. – mattmc3 Dec 07 '10 at 02:51
  • If your requirements favor REST, then use REST, either through WCF or through ASP.NET MVC or whatever you like. If you require the features of SOAP, then ASMX, which was barely updated since .NET 1.0, has been replaced, and good riddance. I also haven't suggested running to replace working code. Even Microsoft suggests using WCF for all _new_ web service development, not for a wholesale replacement of working code. – John Saunders Dec 07 '10 at 20:07
  • Downvoter: if you don't tell me what you feel is wrong with this answer, then I will be unable to improve the answer. – John Saunders Jun 13 '13 at 19:11
2

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.

t3mujin
  • 1,272
  • 1
  • 9
  • 22
2

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!

Eduardo Xavier
  • 1,520
  • 21
  • 29
  • 1
    Poorly phrased, anecdotal, subjective. – d91-jal Mar 01 '11 at 13:27
  • 2
    In terms of determining the best configuration options, this description matches my own experience. It is hell to find all the information, and xml (app.config) is not a good format for entering configuration options, especially those that should be read-only. Isn't everything in this SO entry subjective? – Frank Hileman Feb 23 '13 at 19:04
1

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 !

Nicolas Dorier
  • 7,383
  • 11
  • 58
  • 71
  • Can you be more specific about the maintenance nightmare of configuration? – John Saunders May 29 '09 at 13:08
  • If you deploy a service, and you have 15 clients, if the service change his binding or his address (including the maximal size of string, or the maximal depth of your your object's graph), clients should update their service references manually. Or you can create a new version of your service without changing the old version for backward compatibility. Ws-Discovery or UDDI address this problem, the client only know a contract, and it asks to UDDI ou Ws-Discovery how to access it. Informations: http://stackoverflow.com/questions/647816/web-service-discovery-in-wcf-ws-discovery-or-uddi – Nicolas Dorier May 29 '09 at 13:27
  • Thanks. Does anyone actually _use_ either WS-Discovery or UDDI? Do they only update the configuration information and not the contracts? – John Saunders May 29 '09 at 13:41
  • Not the contract because if the contract change,the code of the client should change too.If your contract change the only solution is to provide multiple version of your service.It's not a hack but a common practice.(usually the namespace of your service contains the date of creation of your service, like some standards do for exemple the namespace of ws-addressing is http://schemas.xmlsoap.org/ws/2004/08/addressing). Some implementation exists (http://www.codeproject.com/KB/WCF/ws-discovery.aspx),but I think it's a better solution to wait the implementation of Microsoft with WCF 4.0 to use it – Nicolas Dorier May 29 '09 at 14:12
0

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.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
ima
  • 8,105
  • 3
  • 20
  • 19
  • What part of WCF do you see as making web applications difficult? – John Saunders May 29 '09 at 12:36
  • There is a list in the question itself. The most prominent is probably that web-accessible declaration of interfaces is generated from code, the opposite would be more natural for web. To me it as an advantage of WCF though. – ima May 29 '09 at 12:47
  • Do you know of any web service technology that does not generate the web-accessible declaration of their contract through code? The only exception I know of being to create the WSDL first, and most people don't want to do that. – John Saunders May 29 '09 at 13:07
  • You can do "WSDL First" with WCF. http://www.google.com/search?hl=en&rls=com.microsoft%3A*&q=wsdl+first+WCF Not everyone wants to do this, as you point out. But it is an option. – Cheeso May 29 '09 at 14:28