Difference between BasicHttpBinding and WsHttpBinding

Questpond
Posted by in WCF category on for Advance level | Views : 21970 red flag

WCF has introduced lot of bindings and protocols. This article will concentrate on two important protocols BasicHttpBinding and WsHttpBinding which look similar but have some huge fundamental differences. So we will first start with the difference and then we will make a small project and see how the differences look practically.


 Download source code for Difference between BasicHttpBinding and WsHttpBinding

Difference between BasicHttpBinding and WsHttpBinding

Introduction and Goal

Pre-requisite

Difference between BasicHttpBinding and WsHttpBinding

Five steps to see the actual difference between BasicHttpBinding and WsHttpBinding

Consideration when to use BasicHttp and WsHttp

Source code

 

Introduction and Goal
 

WCF has introduced lot of bindings and protocols. This article will concentrate on two important protocols BasicHttpBinding and WsHttpBinding which look similar but have some huge fundamental differences. So we will first start with the difference and then we will make a small project and see how the differences look practically.

Now a days I am distributing my 400 questions and answers ebook which covers major .NET related topics like WCF,WPF,WWF,Ajax,Core .NET,SQL Server,Architecture and lot lot more. I am sure you will enjoy this ebook.
http://www.questpond.com/SampleDotNetInterviewQuestionBook.zip 
 

Pre-requisite
 

In case you are new to WCF please do read the basics from the below give links. Basics of WCF are not in scope of this article.

http://www.dotnetfunda.com/articles/article221.aspx to see Windows Communication Framework (WCF) - Part 1

http://www.dotnetfunda.com/articles/article222.aspx to see Windows Communication Framework (WCF) - Part 2

 

Difference between BasicHttpBinding and WsHttpBinding
 

If we want to summarize in one sentence the difference between ‘WsHttpBinding’ and ‘BasicHttpBinding’ is tha ‘WsHttpBinding’ supports ‘WS-*’ specification. WS-* specifications are nothing but standards to extend web service capabilities.

Below is a detailed comparison table between both the entities from security, compatibility, reliability and SOAP version perspective.
 

Criteria

BasicHttpBinding

WsHttpBinding

Security support

This supports the old ASMX style i.e WS-BasicProfile 1.1.

This exposes web services using WS-* specifications.

Compatibility

This is aimed for clients who do not have .Net 3.0 installed and it supports wider ranges of client. Many of clients like Windows 2000 still do not run .NET 3.0. So older version of .NET can consume this service.

As its built using WS-* specifications it does not support wider ranges of client and it cannot be consumed by older .NET version less than 3 version.

Soap version

SOAP 1.1

SOAP 1.2 and WS-Addressing specification.

Reliable messaging

Not supported. In other words if a client fires two or three calls you really do not know they will return back in the same order.

Supported as it supports WS-* specifications.

Default security options

By default there is not security provided for messages when the client calls happen. In other words data is sent as plain text.

As WsHttBinding supports WS-* it has WS-Security enabled by default. So the data is not sent in plain text.

Security options

  • None
  • Windows – default authentication.
  • Basic
  • Certificate
  • None
  • Transport.
  • Message.
  • Transport with message credentials.

 

One of the biggest differences you must have noticed is the security aspect. By default ‘BasicHttpBinding’ sends data in plain text while ‘WsHttpBinding’ sends in encrypted and secured manner. To demonstrate the same let’s make two services one using ‘BasicHttpBinding’ and the other using ‘WsHttpBinding’ and then let’s see the security aspect in a more detailed manner.

We will do a small sample to see how ‘BasicHttpBinding’ sends data in plain text format and how ‘WsHttpBinding’ encrypts data.

Note :- By Default security is not enabled on ‘BasicHttpBinding’ for interoperability purpose. In other words it like our old webservice i.e. ASMX. But that does not mean we cannot enable security in ‘BasicHttpBinding’. Sometimes back we had a written a article on how to enable security on ‘BasicHttpBinding’ http://www.dotnetfunda.com/articles/article362.aspx  
 

Five steps to see the actual difference between BasicHttpBinding and WsHttpBinding
 

In order to understand the real differences between both these entities we will do a small project. In this project we will create two WCF service one service using ‘BasicHttpBinding’ and the second service using ‘WsHttpBinding’.

Step1:- So let’s first create a simple service using ‘BasicHttpBinding’. For that we just a create a simple WCF project and then modify the ‘ServiceModel’ element as shown below. You can see in the ‘endpoint’ tag we have specified ‘basicHttpBinding’ as the protocol.
 

<system.serviceModel>
<services>
<service name="WCFBasicHttpBinding.Service1" behaviorConfiguration="WCFBasicHttpBinding.Service1Behavior">
<!-- Service Endpoints -->
<endpoint address="" binding="basicHttpBinding" contract="WCFBasicHttpBinding.IService1">
<!-- 
Upon deployment, the following identity element should be removed or replaced to reflect the 
identity under which the deployed service runs. If removed, WCF will infer an appropriate identity 
automatically.
-->
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WCFBasicHttpBinding.Service1Behavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="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>

Step 2 :- We also need to create one more service using ‘WsHttpBinding’. For that you do not need to anything special as such. By default WCF project is created using ‘WsHttpBinding’. Below is how the Web.config file looks like. You can see how the endpoint tag is using ‘wsHttpBinding’.
 

<system.serviceModel>
<services>
<service name="WCFWsHttpBindingHttps.Service1" behaviorConfiguration="WCFWsHttpBindingHttps.Service1Behavior">
<!-- Service Endpoints -->
<endpoint address="" binding="wsHttpBinding" contract="WCFWsHttpBindingHttps.IService1">
<!-- 
Upon deployment, the following identity element should be removed or replaced to reflect the 
identity under which the deployed service runs. If removed, WCF will infer an appropriate identity 
automatically.
-->
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WCFWsHttpBindingHttps.Service1Behavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="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>

Step 3 :- We will not be creating any new methods in both the services. We will just use the default code created by the WCF template. So both these services will have a ‘GetData’ function which returns a string. The ‘GetData’ function is a default function created WCF project.
 

public class Service1 : IService1
{
public string GetData(int value)
{
return string.Format("You entered: {0}", value);
}
public CompositeType GetDataUsingDataContract(CompositeType composite)
{
if (composite.BoolValue)
{
composite.StringValue += "Suffix";
}
return composite;
}
}

Step 4 :- Now that out services are created we need to create a client which will consume this service. So we have created a simple web application and we have added two references one is a service reference i.e. ‘WsHttpBinding’ and the second is a web reference i.e. ‘BasicHttpBinding’. Please note when you right click to add reference you need to use the ‘Add service reference’ to add ‘WsHttpService’ and you need to add web reference for ‘BasicHttpBinding’.

We will add two buttons on the default aspx page. One button will call the http service and the other will call the wshttp service. Below is how the function ‘GetData’ is called in both the button clicks.

Step 5 :- So now we are ready with the complete project it is time to sniff and see how data is transported between client and the service in both the scenarios. So let’s download a simple http data recorder from http://www.ieinspector.com/httpanalyzer/download.html . We will then click both the buttons one by one and record the data transfer using httpanalyzer. You can see the posted data is in simple plain XML format for basic http protocol and it’s in an encrypted format for wshttp protocol.

In other words avoid ‘BasicHttp’ as far as possible.
 

Consideration when to use BasicHttp and WsHttp
 

If you are looking for back ward compatibility and to support lot of clients then basic http binding is the way to go or else WsHttp is the great way to start if you are seeing your clients made in .NET 3.0 and above.
 

Source code
 

Get the source code at the top of this article.


 

 

Page copy protected against web site content infringement by Copyscape

Login to vote for this post.

Comments or Responses

Login to post response

Comment using Facebook(Author doesn't get notification)