Skip to main content

Windows Communication Foundation (WCF) - Glossary

WCF Fundamentals
  • Service are applications that wait for clients to communicate with them and respond to that communication. They expose the functionalities to client.
  • Client initiate the communication. They consume the service offered by Service.
  • Message: A message is a self-contained unit of data that may consist of seveal parts, including a body and headers. Clients & Service  communicate using XML messages.

A single application can act as both a client and a service.

Messages are sent between endpoints. Endpoints are places where messages are sent or received (or both), and they define all the information required for the message exchange. A service exposes one or more application endpoints (as well as zero or more infrastructure endpoints), and the client generates an endpoint that is compatible with one of the service's endpoints.

An endpoint describes in a standard-based way where messages should be sent, how they should be sent, and what the messages should look like. A service can expose this information as metadata that clients can process to generate appropriate WCF clients and communication stacks.

An endpoint consists of these components:
  • address Each endpoint has a unique address that helps a client know where it is located on the network.It is specified as a Uniform Resource Identifier (URI). The URI schema part names the transport mechanism to use to reach the address, such as HTTP and TCP. The hierarchical part of the URI contains a unique location whose format is dependent on the transport mechanism.  The client uses this address to send messages to an endpoint. An address can be absolute or relative. If you enter a relative address, WCF uses the absolute base address as the prefix for it. An example of an absolute address is http://localhost:8888/SampleService.
  • binding The binding of an endpoint describes the channels used to communicate with the endpoint. A channel is a route through which all messages pass in a WCF architecture. A channel is composed of binding elements that tell clients which transport protocol, encoding, and security configurations should be used to communicate with the endpoint. WCF provides many default bindings such as BasicHttpBinding and NetTcpBinding.
  • contract An endpoint's contract informs clients about the type of capabilities or features the endpoint provides. It tells clients the form of the message, what operations they can call, how they can call an operation, and what response message they will receive from the endpoint. A contract is created by applying the  ServiceContract attribute to an interface or class description and applying the OperationContract attribute to each method included as a service operation.

An WCF service is exposed to the world as a collection of endpoints.
  • Infrastructure endpoint An endpoint that is exposed by the infrastructure to facilitate functionality that is needed or provided by the service that does not relate to a service contract. For example, a service might have an infrastructure endpoint that provides metadata information.
  • Application endpoint An endpoint exposed by the application and that corresponds to a service contract implemented by the application.
  • Binding element A binding element represents a particular piece of the binding, such as a transport, an encoding, an implementation of an infrastructure-level protocol (such as WS-ReliableMessaging), or any other component of the communication stack.
  • service operation: A service operation is a procedure defined in a service's code that implements the functionality for an operation. This operation is exposed to clients as methods on a WCF client. The method may return a value, and may take an optional number of arguments, or take no arguments, and return no response. For example, an operation that functions as a simple "Hello" can be used as a notification of a client's presence and to begin a series of operations.
  • service contract :The service contract ties together multiple related operations into a single functional unit. The contract can define service-level settings, such as the namespace of the service, a corresponding callback contract, and other such settings. In most cases, the contract is defined by creating an interface in the programming language of your choice
  • Operation contract: An operation contract defines the parameters and return type of an operation. When creating an interface that defines the service contract, you signify an operation contract by applying the OperationContractAttribute attribute to each method
  • Message contract:A message contract describes the format of a message. For example, it declares whether message elements should go in headers versus the body, what level of security should be applied to what elements of the message, and so on.
  • Fault contract: A fault contract can be associated with a service operation to denote errors that can be returned to the caller. An operation can have zero or more faults associated with it. These errors are SOAP faults that are modeled as exceptions in the programming model.
  • Data contract: The data types a service uses must be described in metadata to enable others to interoperate with the service. The descriptions of the data types are known as the data contract, and the types can be used in any part of a message, for example, as parameters or return types. If the service is using only simple types, there is no need to explicitly use data contracts.

  • A behavior is a component that controls various run-time aspects of a service, an endpoint, a particular operation, or a client.
  • Behaviors are grouped according to scope.
  • Common behaviors affect all endpoints globally, service behaviors affect only service-related aspects, endpoint behaviors affect only endpoint-related properties, and operation-level behaviors affect particular operations. For example, one service behavior is throttling, which specifies how a service reacts when an excess of messages threaten to overwhelm its handling capabilities. An endpoint behavior, on the other hand, controls only aspects relevant to endpoints, such as how and where to find a security credential.
Communication Protocols
One required element of the communication stack is the transport protocol. Messages can be sent over intranets and the Internet using common transports, such as HTTP and TCP. Other transports are included that support communication with Microsoft Message Queuing (MSMQ) applications and nodes on a Peer Networking mesh. More transport mechanisms can be added using the built-in extension points of WCF.

Encoding is specified in communication stack which specifies how any given message is formatted. WCF provides the following encodings:
  • Text encoding, an interoperable encoding.
  • Message Transmission Optimization Mechanism (MTOM) encoding, which is an interoperable way for efficiently sending unstructured binary data to and from a service.
  • Binary encoding for efficient transfer.
More encoding mechanisms (for example, a compression encoding) can be added using the built-in extension points of WCF.

Message Patterns
The message exchange patterns used in WCF are either
  • One Way: The One Way is when the sender sends a message to the receiver but the sender doesn't expect the receiver to reply to this message, it is something like Fire & Forget.
  • Request/Reply: The Request / Reply is when the sender sends a message to the receiver and expects ONLY one reply from the receiver, as an example any web page you request for it in your browser you expect a reply (Response) which is the Page you requested.
  • Duplex: The Duplex is when both Sender & Receiver construct a channel between them and everyone of them can send messages to the other at well, it is just like a Phone Call.

Hosting: A service must be hosted in some process. A host is an application that controls the lifetime of the service. Services can be self-hosted or managed by an existing hosting process.

Self-hosted service: A self-hosted service is one that runs within a process application that the developer created. The developer controls its lifetime, sets the properties of the service, opens the service, and closes the service.

  • The metadata of a service describes the characteristics of the service that an external entity needs to understand to communicate with the service. Metadata can be consumed by the ServiceModel Metadata Utility Tool (Svcutil.exe) to generate a WCF client and accompanying configuration that a client application can use to interact with the service.
  • The metadata exposed by the service includes XML schema documents, which define the data contract of the service, and WSDL documents, which describe the methods of the service.
  • When enabled, metadata for the service is automatically generated by WCF by inspecting the service and its endpoints. To publish metadata from a service, you must explicitly enable the metadata behavior.

WS-* Shorthand for the growing set of Web Service (WS) specifications, such as WS-Security, WS-ReliableMessaging, and so on, that are implemented in WCF.


Popular posts from this blog

PDCA & SCRUM (or Agile); Why is it important?

The PDCA (Plan DO Check Act) cycle was made popular by Dr. W. Edwards Deming. This is a scientific cyclic process which can be used to improve the process (or product). This is cyclic in nature and usually time boxed. Plan  This is the first stage of the process. During this step the team discusses the objectives, the process and the clear conditions of exit (conditions of acceptance). This stage sets the measurable and achievable goals for the team. DO Team works together to achieve the objective set in the planning phase. Team works with the set of agreed process. Check Once the implantation is done team regroups and verifies the output and compares it to the agreed conditions of acceptance decided during the planning phase. The deviation, if any, is noted down. ACT If any deviation in planned tasks is observed during the Check stage, a root cause analysis is conducted. Team brainstorms and identifies the changes required to prevent such deviations in future. Team also

Product Backlog: Should you write everything in user story format?

I like user stories a lot. They help everyone talk the same language and results in a better product. User story alone does not constitute product requirement. User story is supposed to be a place holder for discussion which should happen between the team, Product Owner and the customer. This discussion result in a common understanding which along with the user story content is the product requirement. This format captures the essence of requirement without confusing the readers User Story is only one of the many different ways in which requirements can be represented. This is not mandatory in any Agile “process”. But many have made this mandatory. I have seen many spending countless hours trying to write the requirements in user story format when they could have easily written that in simple one-line sentence in few minutes.   I have seen team members refusing to even discuss the requirement until product owner rewrote the requirement in user story format. Once I

Why is potentially shippable product quality important

Agile teams work in iterations. During this period, they are supposed to work on product increments which can be “delivered” at the end of iteration. But how you know that the correct product was delivered? Many teams have different kinds of acceptance criteria and Definition of Done (DoD). But in many cases, this “done” is not the real “done” there might be some testing pending, some integration or review pending or anything else which prevents the actual use of the product increment. Many of these teams will need additional iterations to finish hardening their products. Many teams will implement different types of “gates” or approval steps to move to next stage. The free flow of product will be interrupted. They might end up doing mini waterfall within their agile process. Many don’t even realize this. This results in poor quality and requires additional effort to “harden” the product. Potentially Shippable Product increment The acceptance criteria and DoD should be modified