WCF Essentials: All what you need to know literally before coding.
[Problem viewing article, download PDF version of article here: WCF Essentials]
Introduction: In my last article we leant what WCF is all about, when to use it and in what kind of practical computing complexities. Haven’t read, click here to read https://vishalnayan.wordpress.com/2010/12/31/wcf-what-why-when/.
Here in this article we will learn what are all required to start writing WCF services and exposing them for usage.
A) SOA: If you are reading this article, you can’t compromise with understating of Service oriented architecture and its benefits. It’s also important to understand where the software industry is heading with service orientation; but also you should first appreciate where it came from. The interaction between the client and the service is based on industry standards that prescribe how to secure the call, how to flow transactions, how to manage reliability, and so on, you could also have off-the-shelf implementation of such plumbing. This in turn yields a maintainable application because the application is decoupled on the correct aspects. As the plumbing evolves, the application remains unaffected. A service-oriented application is robust because the developers can use available, proven, and tested plumbing, and the developers are more productive because they get to spend more of the cycle time on the features rather than the plumbing. This is the true value proposition of service-orientation: enabling developers to extract the plumbing out of their code and invest more in the business logic and the required features.
B) Service: A service is a unit of functionality exposed to the world. In that respect, it is the next evolutionary step in the long journey from functions to objects to components to services. A service-oriented application (SOA) aggregates services into a single logical application similar to the way a component-oriented application aggregates components or an object-oriented application aggregates objects.
Above picture is a Service Oriented Architecture.
The client of a service is merely the party consuming its functionality. The client can be literally anything a Windows Forms class, an ASP.NET page, or another service.
Clients and services interact by sending and receiving messages. Messages may transfer directly from client to service or via an intermediary. With WCF, all messages are SOAP messages. Note that the messages are independent of transport protocols unlike Web services, WCF services may communicate over a variety of transports, not just HTTP.
Above picture shows Cross-machine communication using WCF.
A) Addresses: In WCF, every service is associated with a unique address. The address provides two important elements: the location of the service and the transport protocol or transport schema used to communicate with the service. The location portion of the address indicates the name of the target machine, site, or network; a communication port, pipe, or queue; and an optional specific path or URI. A URI is a Universal Resource Identifier, and can be any unique string, such as the service name or a GUID.
Addresses always have the following format:
[base address]/[optional URI]
The base address is always in this format:
[transport]://[machine or domain][:optional port]
Here are a few sample addresses:
http://localhost:8001 http://localhost:8001/MyService net.tcp://localhost:8002/MyService
B) Contracts: In WCF, all services expose contracts. The contract is a platform-neutral and standard way of describing what the service does. WCF defines four types of contracts.
Service contracts: Describe which operations the client can perform on the service , i.e. here I am exposing MyMethod for client to use.
string MyMethod( );
A single class can support multiple contracts by deriving and implementing multiple interfaces decorated with the ServiceContract attribute.
Data contracts: Define which data types are passed to and from the service. WCF defines implicit contracts for built-in types such as int and string, but you can easily define explicit opt-in data contracts for custom types
Fault contracts: Define which errors are raised by the service, and how the service handles and propagates errors to its clients
Message contracts: Allow the service to interact directly with messages. Message contracts can be typed or untyped, and are useful in interoperability cases and when there is an existing message format you have to comply with. As a WCF developer, you should use message contracts only rarely.
C) Hosting: The WCF service class cannot exist in a void. Every WCF service must be hosted in a Windows process called the host process. A single host process can host multiple services, and the same service type can be hosted in multiple host processes. WCF makes no demand on whether or not the host process is also the client process. Obviously, having a separate process advocates fault and security isolation. It is also immaterial who provides the process or what kind of a process is involved. The host can be provided by IIS, by the Widows Activation Service (WAS) on Windows Vista, or by the developer as part of the application.
D) Binding: There are multiple aspects of communication with any given service, and there are many possible communication patterns: messages can be synchronous request/reply or asynchronous fire-and-forget; messages can be bidirectional; messages can be delivered immediately or queued; and the queues can be durable or volatile. There are many possible transport protocols for the messages, such as HTTP (or HTTPS), TCP, P2P (peer network), IPC (named pipes), or MSMQ. There are a few possible message encoding options: you can chose plain text to enable interoperability, binary encoding to optimize performance or MTOM (Message Transport Optimization Mechanism) for large payloads. There are a few options for securing messages: you can choose not to secure them at all, to provide transport-level security only, to provide message-level privacy and security, and of course there are numerous ways for authenticating and authorizing the clients. Message delivery might be unreliable or reliable end-to-end across intermediaries and dropped connections, and the messages might be processed in the order they were sent or in the order they were received. Your service might need to interoperate with other services or clients that are only aware of the basic web service protocol, or they may be capable of using the score of WS-* modern protocols such as WS-Security and WS-Atomic Transactions. Your service may need to interoperate with legacy clients over raw MSMQ messages, or you may want to restrict your service to interoperate only with another WCF service or client.
To simplify these choices and make them more manageable, WCF groups together a set of such communication aspects in bindings. A binding is merely a consistent, canned set of choices regarding the transport protocol, message encoding, communication pattern, reliability, security, transaction propagation, and interoperability.
WCF defines nine standard bindings:
Offered by the BasicHttpBinding class, this is designed to expose a WCF service as a legacy ASMX web service, so that old clients can work with new services. When used by the client, this binding enables new WCF clients to work with old ASMX services.
Offered by the NetTcpBinding class, this uses TCP for cross-machine communication on the intranet. It supports a variety of features, including reliability, transactions, and security, and is optimized for WCF-to-WCF communication. As a result, it requires both the client and the service to use WCF.
Peer network binding
Offered by the NetPeerTcpBinding class, this uses peer networking as a transport. The peer network-enabled client and services all subscribe to the same grid and broadcast messages to it. Peer networking requires an understanding of grid topology and mesh computing strategies.
Offered by the NetNamedPipeBinding class, this uses named pipes as a transport for same-machine communication. It is the most secure binding since it cannot accept calls from outside the machine and it supports a variety of features similar to the TCP binding.
Web Service (WS) binding
Offered by the WSHttpBinding class, this uses HTTP or HTTPS for transport, and is designed to offer a variety of features such as reliability, transactions, and security over the Internet.
Duplex WS binding
Offered by the WSDualHttpBinding class, this is similar to the WS binding except it also supports bidirectional communication from the service to the client as discussed in Chapter 5.
Offered by the NetMsmqBinding class, this uses MSMQ for transport and is designed to offer support for disconnected queued calls.
MSMQ integration binding
Offered by the MsmqIntegrationBinding class, this converts WCF messages to and from MSMQ messages, and is designed to interoperate with legacy MSMQ clients.
Choosing a binding for your service should follow the decision-activity diagram shown below;
A) Endpoints : Every service is associated with an address that defines where the service is, a binding that defines how to communicate with the service, and a contract that defines what the service does. This triumvirate governing the service is easy to remember as the ABC of the service. WCF formalizes this relationship in the form of an endpoint. The endpoint is the fusion of the address, contract, and binding , as shown below
Every service must expose at least one business endpoint and each endpoint has exactly one contract. All endpoints on a service have unique addresses, and a single service can expose multiple endpoints. These endpoints can use the same or different bindings and can expose the same or different contracts.
F) Metadata Exchange Endpoint: A metadata exchange endpoint publishes the metadata for the service. The service metadata is consumed by clients to create a proxy and then call the service.The endpoint supports a standard for exchanging the metadata, WCF provides the implementation in the form of IMetadataExchange. As any other endpoint, the metadata endpoint consists of address, contract and binding. The metadata bindings are the means for the clients to interact with the service and get the metadata for generating the proxies.
There are several out-of-box bindings like MexHttpBinding, MexHttpsBinding, MexTcpbinding etc, supporting specific protocols.
WCF Architecture: So far we learned all that is required to set up and consume simple WCF services. However, WCF offers immensely valuable support for reliability, transactions, concurrency management, security, and instance activation, all of which rely on the WCF interception-based architecture. Having the client interact with a proxy means that WCF is always present between the service and the client, intercepting the call and performing pre- and post-call processing. The interception starts when the proxy serializes the call stack frame to a message and sends the message down a chain of channels. The channel is merely an interceptor, whose purpose is to perform a specific task. Each client-side channel does pre-call processing of the message. The exact structure and composition of the chain depends mostly on the binding. For example, one of the channels may be responsible for encoding the message (binary, text, or MTOM), another for passing security call context, another for propagating the client transaction, another for managing the reliable session, another for encrypting the message body (if so configured), and so on. The last channel on the client side is the transport channel, which sends the message over the configured transport to the host.
Conclusion: Here by we learn the about important keywords which we are goin to use and program while writing WCF services. We also learn about SOA and WCF architecture which is important while writing channel. Now in next article , you are ready to dive deep into programming WCF services.
Download PDF version of article here: WCF Essentials