WCF Interview Questions and Answers

Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data.

The ServiceContract defines the service's contract - its shape and form. It defines the name of the service, its XML namespace etc., and it's typically an interface (but could also be applied to a class) that contains methods decorated with the [OperationContract] attribute - the service methods.

[ServiceContract]
public interface IMyService
{
  [OperationContract]
  Response GetData(int someKey);
}

The DataContract is a totally different beast - it decorates a class to define it as a class that's being used as a parameter or return value from one of the service methods. It's labeling that class as a "thing" to serialize onto the wire to transmit it. It's an instruction for the WCF runtime (the data contract serializer) that this class is intended to be used in a WCF service.

[DataContract]
public class Response
{
  [DataMember]
  int Key { get; set; }
  [DataMember]
  string ProductName { get; set; }
  [DataMember]
  DateTime DateOfPurchase { get; set; }
}

So the service contract and the data contract are two totally separate parts that play together to make a WCF service work - it's not like one could replace the other or something.

In the scenarios listed below you should go for WCF: If you need to send data on protocols like TCP, MSMQ or MIME If the consuming client just knows how to consume SOAP messages WEB API is a framework for developing RESTful/HTTP services.

Consider: WCF ASP.NET Web API Enables building services that support multiple transport protocols (HTTP, TCP, UDP, and

custom transports) and allows switching
between them.

HTTP only. First-class programming model for HTTP. More suitable for access from various browsers, mobile devices etc enabling wide reach. Enables building services that support multiple encodings (Text, MTOM, and Binary) of the same message type and allows switching between them. Enables building Web APIs that support wide variety of media types including XML, JSON etc. Supports building services with WS-* standards like Reliable Messaging, Transactions, Message Security. Uses basic protocol and formats such as HTTP, WebSockets, SSL, JSON, and XML. There is no support for higher level protocols such as Reliable Messaging or Transactions. Supports Request-Reply, One Way, and Duplex message exchange patterns. HTTP is request/response but additional patterns can be supported through SignalR and WebSockets integration. WCF SOAP services can be described in WSDL allowing automated tools to generate client proxies even for services with complex schemas. There is a variety of ways to describe a Web API ranging from auto-generated HTML help page describing snippets to structured metadata for OData integrated APIs. Ships with the .NET framework. Ships with .NET framework but is open-source and is also available out-of-band as independent download.

The WCF programming model separates endpoint operations (as expressed in a service contract) from the transport mechanism that connects two endpoints. This gives you the flexibility to decide how to expose your services to the network. The transport layer is at the lowest level of the channel stack. A transport sends or receives the serialized form of a message to or from another application. The main transports used in Windows Communication Foundation (WCF) are: HTTP, HTTPS, TCP named pipes.

For a Windows Communication Foundation service to host, we need at least a managed process, a ServiceHost instance and an Endpoint configured. Possible approaches for hosting a service are:

1. Hosting in a Managed Application/Self Hosting i. Console Application ii. Windows Application iii. Windows Service
2. Hosting on Web Server i. IIS 6.0 (ASP.NET Application supports only HTTP) ii. Windows Process Activation Service (WAS) i.e. IIS 7.0 supports HTTP, TCP, NamedPipes, MSMQ.

WCF Message exchange pattern defines the way messages are exchanged between the applications(client, service). they are three ways: Request-Reply (default) - Clients will be blocked until receiving a reply or timeout. One Way - The service model releases the client connection once the message arrives to the channel and before invoking, the operation. Also client will not receive any notification of exception that occurs.

Request-CallBack (also called Duplex) - Both the client and the service can initiate communication. You can use this pattern when you want the service to send a notification or alert to the client after the client has called the service.

You can use gRPC for hosting web services inside .NET core application.

1. gRPC is a high performance, open-source RPC framework initially developed by Google.
2. The framework is based on a client-server model of remote procedure calls. A client application can directly call methods on a server application as if it was a local object.

When you have a large amount of data to transfer, the streaming transfer mode in WCF is a feasible alternative to the default behavior of buffering and processing messages in memory in their entirety. In WCF any receiving message is delivered only once the entire message has been received. What I mean here is that first message is buffered at the receiving side and once it is fully received it gets delivered to the receiving end. The main problem with this approach is that the receiver end is unresponsive while the message is getting buffered. So default way of message handling in WCF is ok for small size messages but for the large size messages, this approach is not good. So to overcome this problem Streaming in WCF come into action.

A Fault Contract is a way to handle an error/exception in WCF. In C# we can handle the error using try and catch blocks at the client side. The purpose of a Fault Contract is to handle an error by the service class and display in the client side. We use return codes if it's a known, possible error. If it's a scenario that I know can, and will happen, then there's a code that gets sent back. Exceptions are used solely for things that I'm NOT expecting. This is why WCF's architects chose to provide the Fault Contract mechanism, rather than implement the same functionality via return codes. To support SOAP Faults, WCF provides the FaultException class. This class has two forms: FaultException: to send an untyped fault back to the caller FaultException: to send a typed fault data to the client. It is basically a Generic Type.

[OperationContract]
[FaultContract(typeof(MyException))]

string getDetails(int value);

The Web Service stack. There are a bunch of specifications for Web Services, and there names are written WS- whatever, for example: WS-SecurityPolicy. The * is used as a wildcard to indicate that you are referring to the Web Services stack.

Bindings specify how a Windows Communication Foundation (WCF) service endpoint communicates with other endpoints. At its most basic, a binding must specify the transport (for example, HTTP or TCP) to use. You can also set other characteristics, such as security and transaction support, through bindings. WCF provides nine built-in bindings: BasicHttpBinding: Basic web service communication. Exposes WCF services as legacy ASMX web services. Used for interoperability. No security by default. WSHttpBinding: Web services with WS-* support. Supports transactions and reliable messaging. WSDualHttpBinding: Web services with duplex contract and transaction support. WSFederationHttpBinding: Web services with federated security. Supports transactions. MsmqIntegrationBinding: Communication directly with MSMQ applications. Supports transactions. NetMsmqBinding: Communication between WCF applications by using queuing. Supports transactions. NetNamedPipeBinding: Communication between WCF applications on same computer. Supports duplex contracts and transactions. NetPeerTcpBinding: Communication between computers across peer-to-peer services. Supports duplex contracts. NetTcpBinding: Communication between WCF applications across computers. Supports duplex contracts and transactions.

Sometimes complete control over the structure of a SOAP message is just as important as control over its contents (that defined by Data Contracts). This is especially true when interoperability is important or to specifically control security issues at the level of the message or message part. In these cases, you can create amessage contract that enables you to specify the structure of the precise SOAP message required.

Data Contracts define the data type for variables that are the same as get and set properties but the difference is that a Data Contract in WCF is used to serialize and deserialize the complex data. It defines how data types are serialized and deserialized. Using serialization, you can convert an object into a sequence of bytes that can be transmitted over a network. Using de-serialization, you reassemble an object from a sequence of bytes that you receive from a calling application. The DataMemberAttribute attribute must then be applied to each member of the data contract type to indicate that it is a data member, that is, it should be serialized. namespace MyTypes

{
  [DataContract]
  public class PurchaseOrder
  {
    private int poId_value;
    // Apply the DataMemberAttribute to the property.
    [DataMember]
    public int PurchaseOrderId
    {
      get { return poId_value; }
      set { poId_value = value; }
    }
}
}

Windows Communication Foundation is designed to exchange standard SOAP-based messages using variety of transport protocols like HTTP, TCP, NamedPipes or MSMQ, etc. On the other hand, ASP.NET API is a framework for building non-SOAP based services over HTTP only.

An operation contract is defined within a service contract. It defines the parameters and return type of an operation. An operation contract can also defines operation-level settings, like as the transaction flow of the operation, the directions of the operation (one-way, two-way, or both ways), and fault contract of the operation.

[ServiceContract]
interface IMyContract {
  [FaultContract(typeof(MyFaultContract))]
  [OperationContract]
  string MyMethod();
}

WCF contract specifies the service and its operations. WCF has five types of contracts: service contract, operation contract, data contract, message contract fault contract.

ASMX is: easy and simple to write and configure only available in IIS only callable from HTTP WCF can be: hosted in IIS, a Windows Service, a Winforms application, a console app - you have total freedom used with HTTP (REST and SOAP), TCP/IP, MSMQ and many more protocols

It's a misconception that ASP.NET Web API has replaced WCF. It's another way of building non-SOAP based services, for example, plain XML or JSON string, etc. Yes, it has some added advantages like utilizing the full features of HTTP and reaching more clients such as mobile devices, etc. But WCF is still a good choice for the following scenarios: If we intended to use transport other than HTTP, e.g. TCP, UDP or Named Pipes Message Queuing scenario using MSMQ One-way communication or Duplex communication

A few sample scenarios include: A secure service to process business transactions. A service that supplies current data to others, such as a traffic report or other monitoring service. A chat service that allows two people to communicate or exchange data in real time. A dashboard application that polls one or more services for data and presents it in a logical presentation. Exposing a workflow implemented using Windows Workflow Foundation as a WCF service. A Silverlight application to poll a service for the latest data feeds. While creating such applications was possible prior to the existence of WCF, WCF makes the development of endpoints easier than ever. In summary, WCF is designed to offer a manageable approach to creating Web services and Web service clients.

Features of WCF** Windows Communication Foundation (WCF) is a secure, reliable, and scalable messaging platform for the .NET Framework 3.0, Service Orientation Interoperability Multiple Message Patterns Service Metadata Data Contracts Security

Multiple Transports and Encodings Reliable and Queued Messages Durable Messages Transactions AJAX and REST Support Extensibility Advantages of WCF:

1. Service Oriented
2. Location Independent
3. Language Independent
4. Platform Independent
5. Support Multiple operation
6. WCF can maintain transaction like COM+ Does
7. It can maintain state
8. It can control concurrency
9. It can be hosted on IIS, WAS, Self hosting, Windows services.

SOA stands for **service-oriented architecture. Service Oriented Architecture is an architectural approach in software development where the application is organized as "Services". Services are a group of methods that contain the business logic to connect a DB or other services. For instance you go to a hotel and order food. Your order first goes to the counter and then it goes to the kitchen where the food is prepared and finally the waiter serves the food. Some important characteristics of Service Oriented Architecture SOA services should be independent of other services. Altering a service should not affect the client calling the service. Services should be self-contained. Services should be able to define themselves (in the Web Service Description Language (WSDL)). It should be able to tell the client what all of the operations it does, what are all the data types it uses and what kind of value it will return.

A service contract defines the operations which are exposed by the service to the outside world. A service contract is the interface of the WCF service and it tells the outside world what the service can do. It may have service-level settings, such as the name of the service and namespace for the service.

[ServiceContract]
interface IMyContract {
  [OperationContract]
  string MyMethod();
}

class MyService: IMyContract {
  public string MyMethod() {
    return "Hello World";
  }
}

Have a look at this mindmap to navigate yourself through WCF service components:

All communication with a Windows Communication Foundation (WCF) service occurs through the endpoints of the service. Endpoints provide clients access to the functionality offered by a WCF service. A WCF service endpoint has three basic elements, i.e. Address , Binding and Contract (ABC). Address: It defines "WHERE". Address is the URL that identifies the location of the service. Binding: It defines "HOW". Binding defines how the service can be accessed. Contract: It defines "WHAT". Contract identifies what is exposed by the service.

The differences between gRPC and WCF: GRPC does not use SOAP to mediate between client and service over http. WCF supports SOAP. GRPC is only concerned with RPC style communication. WCF supports and promotes REST and POX style services in addition to RPC. GRPC provides support for multiple programming languages. WCF supports C# (and the other .net languages). GRPC uses protobuf for on-wire serialization, WCF uses either XML/JSON or windows binary. GRPC is open source gRPC does not support Windows/Kerberos authentication In short: GRPC seems a much more focused services framework, it does one job really well and on multiple platforms. WCF is much more general-purpose, but limited to .net for the time being (WCF is being ported to .net core but at time of writing only client side functionality is on .net core)

The binary message encoder, uses a compact binary format and is optimized for WCF to WCF communication, and hence is not interoperable. This is also the most performant encoder of all the encoders WCF provides. Binary encodings are generally more compact than text encodings. When message size is at a premium, consider also compressing the message contents during encoding.

WCF supports 3 encodings (in context of WCF, encoding means converting a WCF message (serialized XML InfoSet) into bytes) – Text, MTOM & Binary (JSON & POX are also possible – webHttpBinding). All Http Bindings (Basic, WS, Dual, etc.) support Text / MTOM encoding, Text being the default one. Text/MTOM are preferred in WS-

* interoperability scenarios.

Problem with Text Encoding is it uses base 64 encoding format which can inflate the message size by 30%. This can be a heavy penalty while carrying large binary attachments. MTOM avoids base 64 encoding for binary attachments keeping the overall size of message in control. Moreover, MTOM is based on open specifications & hence is largely interoperable. Coming to binary encoding of WCF (TCP/Pipe/MSMQ) though it’s best in terms of performance it’s not interoperable. Some people are also averse to TCP etc. because of firewall constraints & need of Sticky Sessions (Load balancing with transport sessions). I would strongly recommend to do a performance test on all of them in your environment and then take a decision.

Interoperability is the ability to communicate with other platforms through standard protocols (such as SOAP). One of the major benefits of SOAP is that it is platform independent. WCF is designed and built to interoperate with web services that support the Web Services Specification, known as the WS-* specifications. As such, WCF comes with three system-provided bindings that facilitate interoperability. These bindings are shown in the following list: BasicHttpBinding: WCF services can use this binding to configure and expose endpoints. These endpoints in turn can communicate with *.asmx-based web services as well as clients and services that comply with the WS-I Basic Profile 1.1. WsHttpBinding: Supports distributed transactions as well as secure and reliable sessions. WsDualHttpBinding: Support for duplex communication and communication via SOAP intermediaries.

A DataContract is a description of a type that is exposed and supported by your service. A MessageContract is an abstraction over a SOAP message that allows you to explicitly dictate the structure of the underlying message. They are meant to compliment each other and serve different purpose: Using DataContract, the service can expose the types that it interchanges. But the XML (SOAP) that is interchanged is not controlled (though impacted) by it. While MessageContract can be used to explicitly define how the XML (SOAP message) will be structured.

You need duplex if you want to implement callback pattern. Callback means that client does not know when some event happens in server. If you do not know when event happens you have two options to implement: Polling - send requests every X minutes to check if event happened. Server should either return event details (if it happened) or return flag saying that you need to continue calling. Server also can return recommended timeout in advanced scenarios. Callback - client sends some form of description what server should do if event happened. This may be pointer to function in C, delegate in .NET or endpoint schema in WCF. Server remembers that info and makes call from their side when time came. As you can see duplex/callback means that at some point server works as client (initiates communication) and this is a big game change. WCF duplex communications may require special network configuration because in many cases network allows you to call external services (you work as client) but forbids external resources to call you (external service works as client). This is implemented for security purposes.

Yes it will - and more importantly boost scalability too. Client is released as soon as call is taken up at the server and client does not have to wait until processing finishes. This helps the resources at both client and server to be released as soon as possible.

There is no standard answer to this question. IIS provides you with a lot of out-of-the-box features, like app domain reloading, monitoring and so on. This is why you should answer this questions first: do you need all these features or not? If not - windows service can be considered. Other thing to consider: IIS gives you on-demand loading - this can be a plus or a minus. When a request comes in, the ServiceHost is constructed, then the service class being hosted is instantiated, and the request is handled. Nothing needs to be running around the clock. But at the same time, this setup requires more time and effort every time a message comes in, and you as a programmer don't have much control over your service host, really. Self-hosting is often times faster, since your ServiceHost is already up and running - but it's up to you to make sure it really is up and running, there's no "on-demand" loading whenever a message comes in - either it's up and can service the request, or not. But you have a lot more control over the service host - when and how it's constructed etc., and you get to pick and define your service addresses as you see fit. And some information from Microsoft: Hosting Environment Common Scenarios Key Benefits and Limitations Managed Application

• Console applications used during development. - Rich WinForm and
• Flexible.- Easy to deploy.- Not an enterprise solution for services.

("Self-
Hosted")
WPF client applications accessing
services.
Windows
Services
(formerly
known as NT
services)
- A long-running WCF service

hosted outside of IIS.

• Service process lifetime controlled by the operating system, not message-activated.- Supported by all versions of Windows.- Secure environment. IIS 5.1, IIS 6.0
• Running a WCF service side-by- side with ASP.NET content on the Internet using the HTTP protocol.
• Process recycling.- Idle shutdown.- Process health monitoring.- Message-based activation.- HTTP only. Windows Process Activation

Service (WAS)
- Running a WCF service without

installing IIS on the Internet using various transport protocols.

• IIS is not required.- Process recycling.- Idle shutdown.- Process health monitoring.- Message-based activation.- Works with HTTP, TCP, named pipes, and MSMQ. IIS 7.0
• Running a WCF service with ASP.NET content.- Running a WCF service on the Internet using various transport protocols.
• WAS benefits.- Integrated with ASP.NET and IIS content.

HTTP protocol does not support duplex communication — responses are valid only for each request, so the answer is no. This prevents HTTP-based bindings such as BasicHttpBinding and WSHttpBinding from supporting duplex. To address this limitation, WCF provides WSDualHttpBinding . This binding uses composite duplex communication, which means two communication channels are created to support calls in both directions.

MTOM is a standard that uses multi-part mime-encoded messages to send portions of the message that are large and would be too expensive to base64 encode as pure binary. The SOAP message itself is sent as the initial part of the message and contains references to the binary parts which a web service software stack like WCF can then pull back together to create a single representation of the message. Binary encoding is entirely proprietary to WCF and really doesn't just have to do with large messages. It presents a binary representation of the XML Infoset which is far more compact across the wire and faster to parse than text based formats. If you happen to be sending large binary chunks of data then it just fits right in with the other bytes that are being sent. Streaming can be done used with any message format. That's more about when the data is written across the network vs. being buffered entirely in memoery before being presented to the network transport. Smaller messages make more sense to buffer up before sending and larger messages, especially those containing large binary chunks or streams, necessitate being streamed or will exhaust memory resources.

Sockets are very low level. Today I would never go down to such a low level as sockets unless you really have to. Working with high level abstractions is way more productive and creative. The big advantage of Remoting or WCF is that you can pass objects between server and client and call methods on them on each side. Also be aware that the performance of Net.tcp communication over WCF is much worse than plain socket communication. It is because WCF simplifies a lot of things but those simplification and generalizations slows processing. So it depends.

WCF client-side is already supported on.NET Core. WCF server-side is not supported in .NET Core since it's a Windows specific technology while .NET Core is supposed to be cross-platform. WCF won't likely be ported to .NET Core, because most of the code-base depends on Windows internal libraries. There are some alternatives that you could use for the server-side thought:

1. IpcServiceFramework - A .NET Core lightweight inter-process communication framework allowing invoking a service via named pipeline and/or TCP (in a similar way as WCF, which is currently unavailable for .NET Core). Secure communication over SSL is also supported.
2. gRPC - a high performance, open source RPC framework initially developed by Google. The framework is based on a client-server model of remote procedure calls. A client application can directly call methods on a server application as if it was a local object.
3. Core WCF - Core WCF is a port of Windows Communication Framework (WCF) to .NET Core. The goal of this project is to enable existing WCF projects to move to .NET Core.

The main difference is that, after the client establishes a channel to the service, the service can call the client independently at any time. In Request-Response the service only communicates back after receiving a Request from the client. So by using duplex you receive an event-like behavior from the client perspective. Obviously, such enhancement requires a Session to be maintained (instance mode PerSession on the service).