What am I missing in WCF?

Question

I have been developing in MS technologies longer than I remember at this stage. When .NET arrived on the scene, I thought that they hit the nail on the head, and with each iteration and version I thought that their technologies were becoming stronger and stronger and were looking forward to every release.

However, working with WCF last year, I have to say that it is very difficult for me to work with the technology and understand it. Initially, this is pretty attractive, but when you start to delve into this, the configuration is a nightmare that should redefine the behavior for message sizes, the number of objects contained in messages, the complexity of the security model, utilization of proxy servers on failure, and finally returning to the definition interfaces in code, not in XML.

It just doesn't work out of the box, and I think this should happen. We found all of the above problems, testing ourselves or when our products were in place.

I understand the meaning of this, but, of course, they could find a simpler implementation mechanism.

I guess I ask

• Am I looking at WCF incorrectly?
• What strengths does this have alternatives?
• Under what circumstances should I choose to use WCF?

OK. People, sorry for the delay in the answer, the work has an unpleasant habit sometimes interfere :)

Some clarifications My main point of paint with WCF, I suppose, falls into the following areas While it works out of the box, your left is with some serious surprises under the hood. As stated above, the main things are limited until they are redefined.

• The size of the line that can be transmitted cannot exceed 8K
• The number of objects that can be transmitted in one message is limited
• Proxies do not automatically recover from crashes
• The scope of the configuration, while there is a good thing, but everyone understands and what to use what, and under what circumstances, can be difficult to understand. Especially when deploying software on a site with various security requirements, etc. When we talk about configuration, we had to hide many of them in the internal database, since security and network users in place tried to change the situation in the configuration files without understanding it.
• Saving the configuration of interfaces in code, rather than moving to explicitly defined interfaces in XML that can be published and used by almost everyone. I know that we can export XML from the assembly, but it is full of garbage, and some code generators overwhelmed it.

I know that the world is moving on, I have moved to the last several times (the 22-year-old scheme I was developing) and I am actively using WCF, so don’t get me wrong, I understand what it is for and where it heads.

I just think that there should be simpler configuration / deployment options, easier setup, and better management for the configuration (perhaps the SQL configuration provider, not just the web.config / app.config files).

Answer 1

I use WCF all the time and I share your pain. It seems like it has been heavily redesigned, but we are going to be stuck with it for a long time, so I'm trying to study it.

One thing that I know for sure is XML sucks. I had nothing but problems using XML to manage it, and since then I switched to processing everything with code.

Answer 2

You mentioned the following issues:

---

• The size of the line that can be transmitted cannot exceed 8K
• The number of objects that can be transmitted in one message is limited
• Proxies do not automatically recover from crashes
• The scope of the configuration, while there is a good thing, but everyone understands and what to use what, and under what circumstances, can be difficult to understand. Especially when deploying software on a site with various security requirements, etc. When we talk about configuration, we had to hide many of them in the internal database, since security and network users in place tried to change the situation in the configuration files without understanding This.
• Saving the configuration of interfaces in code, rather than moving to explicitly defined interfaces in XML that can be published and used by almost everyone. I know that we can export XML from the assembly, but it is full of garbage, and some code generators overwhelmed it.

---

here is my trick:

(1) examined the actual problem that customers faced with ASMX. It was too wide open, without the ability to easily control it. The 8k limit is easily removed if you know where to look. I think you may consider this a surprise, but it is rather a one-time thing. Once you find out about it, you can pick it up and do with it forever if you choose.

(2) also customizable.

(3) It is known, but there are boilerplate ways to get around this. For example, StockTrader code demonstrates a proven template. You can reuse the code in your application. Not sure if this is fixed in WCF for .NET 4.0. I know this was an open request.

(4) Configuration is a beast. This is a concern for many people. The problem here is that WCF is so flexible, and the configuration of all this flexibility is revealed through XML files. This can be overwhelming. An approach that seems to work is to take it in small bites as you need it.

(5) I do not understand.

Answer 3

I will consider the remaining questions after clarification. In the meantime, I can answer your question when should you use WCF: always.

WCF replaces legacy ASMX technologies, including WSE. It is also a replacement for .NET Remoting. This is the only technology on which .NET's high-level communications features will be based on the foreseeable future.

For example, consider Windows Azure. It is possible that the new concept of "cloud computing" will have its own communication aspects covered by WCF. However, WCF was flexible enough to be extended to cover these cases, with very little code change.

If you are having problems with WCF, you should make sure that Microsoft knows about it. WCF is the present and future of web service and other service-oriented developments in .NET, so they have a very strong incentive to listen to you and solve your pain points. Either contact them directly through Connect , or ask questions here on SO (tag with WCF, please), and many people will help you.

Answer 4

I highly prefer ASP.NET MVC and Web API through WCF. If I had to generalize WCF to the developer who was just presented at it, I would say: "WCF is a well-thought-out attempt to replace over-engineered Java EE-style RPC development." Unfortunately, many of the decisions made require you to become an expert in setting low-level, non-essential elements (message sizes, timeouts, uninteresting protocol elements, etc.), while abstracting absolutely critical parts (URL design, parameter serialization, serialization of the response, etc.).). The difference in performance and exacerbation between the teams that I know with WCF vs. Web API is night and day.

Come a little: I always hated the basic concept of .NET Remoting. I believe that developers need a comprehensive understanding of the resource structure of their application and how these resources are serialized. In addition, using the verb “POST” to easily retrieve data is alarming when reading a heavy application that needs to be scaled.

Answer 5

The biggest advantage to using WCF from a programmer’s point of view is: it separates the definition of open services (operations, contracts, etc.) from specific concrete protocols, unlike ASMX, where you expose a class as a web service directly in code using attributes. Using my real example: we can easily switch the transport protocol between web services and named pipes, no matter what is best for deployment and performance, without changing the line of code.

Answer 6

To solve the problem of servicing the app configuration nightmare, there are some standard ones, such as UDDI or WS-Discovery, WS-Discovery will be supported by WCF in .NET 4.0.

Saving the configuration of 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 XML from an assembly, but it is full of garbage and certain code generators are throttled on it.

Can you be more explicit? I think you are talking about service behavior configured in code. You can easily code behavioral extensions to customize what you're talking about in the configuration file instead of code. But I think that if Microsoft did not do this, there is a good reason. For example, a service with this behavior:

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

The implementation knows that an instance is not split between multiple threads, so it develops differently than:

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

In this case, the implementation of the service should take care of compatibility issues. The implementation is related to the ServiceBehavior attribute, so moving this behavior into an XML file is not a good idea.

What if you can change the InstanceContextMode.PerCall service to the InstanceContextMode.Single service inside the configuration file? You are breaking the application!

Answer 7

WCF is for SOA methodologies. Work using it professionally is a nightmare. I delivered a SOA solution using WCF as a tool and hell, hundreds of configurations and hidden tips! My past distributed solution using old web services and remote applications was more stable. I spent days developing a solution for the error "The main connection was closed: an unexpected error occurred", which does not make sense for one method among 4 in the same contract. I'm very disappointed. It took me a while when .net was first introduced with a lot of promises, and when we got our hands, damn it, there were problems with the magazine!

Answer 8

Considering how you mention XML and SQL, you use WCF to create a web application or an actual web service (a service on the Internet, not just a SOAP exchange).

This helps to think of 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, proxy behavior, some configuration parameters and other aspects of the structure that look unnatural and complex from the point of view of web applications really work out of the box for distributed object systems like DCOM.

To answer the question: no, you are not missing anything, and using WCF for web applications is difficult because WCF is not the basis for building web applications. Probably, such a structure can be built on top of it, but I would really like for WCF to change itself in order to move to the web area.