This post is about understanding some lower level details about endpoints. As we discussed previously, an endpoint has it’s ABCs.
- A is for Address
- B is for Binding
- C is for Contract
Ultimately, Windows Communication Foundation is a framework for building services that process XML messages. The whole point of WCF is for applications to communicate across networks.
Windows Communication Foundation (WCF) uses bindings to define how it communicates with other software. The client will need to incorporate the same bindings as in the service.
The terms to learn about with respect to Bindings are:
- Protocol details
Windows Communication Foundation allows you to transmit messages using different transport protocols.
- Hypertext Transfer Protocol (HTTP)
- Transmission Control Protocol (TCP)
- Message Queuing (also known as MSMQ)
- Named pipes
HTTP leverages the traditional request/response pattern. HTTP is stateless, so if there is any multi page transactions, the application (server and client) needs to maintain state. the main value of HTTP is interoperatbility with non-WCF clients.
TCP is connection based and provides end-to-end error detection and correction. TCP is a great choice because it provides reliable data delivery. It handles lost packets and duplicate packets. The TCP transport is optimized for scenarios where both ends are using WCF. It is the fastest of all the bindings. TCP provides duplex communication and so can be used to implement duplex contracts, even if the client is behind network address translation (NAT).
Note A duplex contract enables clients and servers to communicate with each other. The calls can be initiated independently of the other one. It is comprised of two one-way contracts.
Named Pipes is ideal for two or more WCF applications on a single computer, and you want to prevent any communication from another machine. Named pipes are efficient because they tie into the Windows operating system kernel, leveraging a section of shared memory that processes can use for communication.
MSMQ is allows applications to communicate in a failsafe manner. A queue is a temporary storage location from which messages can be sent and received reliably. This enables communication across networks and between computers, running Windows, which may not always be connected.
Encoding types represents how the data is structured across the wire. There are 3 main formats:
Text – for interoperability
Text uses base64 encoding, which can make messages up to 30% bigger. If you are sending binary data, this can introduce a large amount of overhead.
Binary – for speed
This is the fastest encoding. Unless you are sending very large messages, the binary format is ideal (with the assumption that text isn’t needed for interoperability)
MTOM – for large objects
MTOM is the W3C Message Transmission Optimization Mechanism, a method of efficiently sending binary data to and from Web services. MTOM doesn't use base64 encoding for binary attachments keeping the overall size small. MTOM is based on open specifications & hence is largely interoperable.
Message Protocol Details
WCF leverages SOAP for its network messaging protocol. SOAP, aka Simple Object Access Protocol, specifies how structured information is exchanged in the implementation of Web Services in computer networks. It relies on XML for its message format.
One big advantage is that SOAP can tunnel easily over existing firewalls and proxies, without modification. The disadvantage of SOAP is that it has a verbose XML format and can be slow.
One alternative to SOAP is JSON/XML.
With respect to SOAP, there are a number of WS-* specifications. These WS-* specifications can be broken into various categories:
|Messaging Specifications||WS-Addressing, WS-Enumeratio, WS-Eventing, WS-Transfer|
|Security Specifications||WS-Security: SOAP Message Security, WS-Security: UsernameToken Profil, WS-Security: X.509 Certificate Token Profile, WS-SecureConversation, WS-SecurityPolicy, WS-Trust, WS-Federation, WS-Federation Active Requestor Profil, WS-Federation Passive Requestor Profil, WS-Security: Kerberos Binding|
|Reliable Messaging Specifications||WS-ReliableMessaging|
|Transaction Specifications||WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity|
|Metadata Specifications||WS-Policy, WS-PolicyAssertions, WS-PolicyAttachment, WS-Discover, WS-MetadataExchang, WS-MTOMPolicy|
|Management Specifications||WS-Managemen, WS-Management Catalog, WS-ResourceTransfe,|
|Specification Profiles||WS-I Basic Profile|
In this hands-on lab, you will learn how to:
- Create a Virtual Machine with Visual Studio 2013 RC from the Windows Azure Management Portal
- Download and install SQL Server 2012 Express
The following is required to complete this hands-on lab:
- Visual Studio 2010 - 2013
- Finished the steps about my previous post (http://blogs.msdn.com/b/brunoterkaly/archive/2013/10/18/getting-started-with-wcf-windows-communication-foundation-running-and-debugging-quickly.aspx)
In order to execute the exercises in this hands-on lab, you need to set up your environment.
- Start Visual Studio and open the previous project here: (http://blogs.msdn.com/b/brunoterkaly/archive/2013/10/18/getting-started-with-wcf-windows-communication-foundation-running-and-debugging-quickly.aspx)
How to Modify Bindings Using the WCF Service Configuration Editor
In the next section we will enable the Reliable Messaging protocol. It is useful where the quality of network connectivity is potentially very poor. The WS-ReliableMessaging (or WS-RM) protocol is for creating reliable communication paths over unreliable connections. Very simply, it provides the infrastructure that provides explicit acknowledgement of messages into the communication flow
Task 1 – Starting the WCF Service Configuration Editor
This task is about using the WCF Servcie Configuration Editor to create a new binding configuration.
You will need to return back to the solution created in the previous blog post. From Solution Explorer right mouse click on App.config and choose Edit WCF Configuration. This will bring up the WCF Service Configuration Editor.
Editing the binding information
In this section we will create a new binding. In the Configuration section you will right mouse click on Biindings.
Editing the bindings
After right mouse clicking on the Binding node, choose New Binding Configuration.
Adding a new binding
A list of bindings will appear. Select wsHttpBinding. By choosing wsHttpBinding we will modify the attributes of this binding type.
We will need to provide a name for this new binding.
Providing a name to the new binding
We will set the Reliable Session Property to enabled. We will leave the other attributes alone.
Enabling Reliable Sessions
Task 2 – Attaching the new binding to the endpoint
In this task, we will attach our newly created binding to the endpoint for wsHttpBinding.
You will now return to your endpoints and attach the binding we just created. Recall the name of BindingReliableMessaging. Notice that we selected the endpoint” whose **binding is wsHttpBinding.
Attaching the new binding to our endpoint
Return back to the menu and save the changes to the App.config file.
Saving the changes
Note that if we open App.config we can see the new binding created (BindingReliableMessaging).
Viewing the changes
Notice that the endpoint has also been configured with the WCF Service Configuration Editor. We are done – we have modified a binding to suite the desired behavior (Reliable Messaging).
Verifying that the new Binding is attached to the endpoint
<?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true"/> </appSettings> <system.web> <compilation debug="true"/> </system.web> <!--When deploying the service library project, the content of the config file must be added to the host's app.config file. System.Configuration does not support config files for libraries. --> <system.serviceModel> <bindings> <wsHttpBinding> <binding name="BindingReliableMessaging"> <reliableSession enabled="true"/> </binding> </wsHttpBinding> </bindings> <services> <service behaviorConfiguration="FlipCaseService.Service1Behavior" name="FlipCaseService.FlipCaseService"> <endpoint address="flipcase/wsAddress" binding="wsHttpBinding" bindingConfiguration="BindingReliableMessaging" contract="FlipCaseService.IFlipCaseService"/> <endpoint address="flipcase/basic" binding="basicHttpBinding" contract="FlipCaseService.IFlipCaseService"/> <endpoint address="net.tcp://localhost/FlipCaseNetTcp" binding="netTcpBinding" contract="FlipCaseService.IFlipCaseService"/> <endpoint address="flipcase/mex" binding="mexHttpBinding" contract="IMetadataExchange"/> <host> <baseAddresses> <add baseAddress="http://localhost:8080"/> </baseAddresses> </host> </service> </services> <behaviors> <serviceBehaviors> <behavior name="FlipCaseService.Service1Behavior"> <!--To avoid disclosing metadata information, set the values below to false before deployment --> <serviceMetadata httpGetEnabled="True" httpsGetEnabled="True"/> <!--To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information --> <serviceDebug includeExceptionDetailInFaults="False"/> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> </configuration>
In this post, you learned a few things:
- How to use the WCF Service Configuration Editor
- How to add Reliable Messaging to the wsHttpBinding endpoint
In the next post, we will learn how to use the WCF Service Configuration Editor to create the needed configuration settings for a client application that consumes our FlipCaseService.