Welcome to MSDN Blogs Sign in | Join | Help

Inside the Standard Bindings: WSHttp

The WsHttp binding is a lot like the BasicHttp binding with the Web Services knob turned up a little higher. Where BasicHttp stops with message security, WsHttp continues with transactions, reliable messaging, and WS-Addressing either enabled by default or available through a single control setting. Otherwise, the HTTP-ness of the two bindings is the same and all of the binding elements being used have appeared in previous bindings.

Standard disclaimer:

I've cut down on the number of properties presented by eliminating duplicates between the binding settings and binding element settings. For instance, the XML reader quotas can be set on either the binding or the message encoder binding element, but I'm only going to show them on the message encoder. I've also omitted most of the security credential settings because they're very messy and you hopefully won't need to change them much.

I'll start with my usual approach of presenting the channel stack and baseline settings with the Security.Mode property set to SecurityMode.None. The important points to note here are that we've got a binding element for transactions (with the transaction protocol set to the WS standard rather than OLE transactions) and the mapping mode is now SoapWithWSAddressing.

  1. System.ServiceModel.Channels.TransactionFlowBindingElement
    TransactionProtocol: WSAtomicTransactions
  2. System.ServiceModel.Channels.TextMessageEncodingBindingElement
    AddressingVersion: Addressing10 (http://www.w3.org/2005/08/addressing)
    MaxReadPoolSize: 64
    MaxWritePoolSize: 16
    ReaderQuotas:
    MaxArrayLength: 16384
    MaxBytesPerRead: 4096
    MaxDepth: 32
    MaxNameTableCharCount: 16384
    MaxStringContentLength: 8192
  3. System.ServiceModel.Channels.HttpTransportBindingElement
    AllowCookies: False
    AuthenticationScheme: Anonymous
    BypassProxyOnLocal: False
    HostNameComparisonMode: StrongWildcard
    ManualAddressing: False
    MappingMode: SoapWithWSAddressing
    MaxBufferPoolSize: 524288
    MaxBufferSize: 65536
    MaxReceivedMessageSize: 65536
    ProxyAddress: ProxyAuthenticationScheme: Anonymous Realm: Scheme: http TransferMode: Buffered UnsafeConnectionNtlmAuthentication: False UseDefaultWebProxy: True
CloseTimeout: 00:01:00
EnvelopeVersion: Soap12 (http://www.w3.org/2003/05/soap-envelope)
Namespace: http://tempuri.org/
OpenTimeout: 00:01:00
ReceiveTimeout: 00:01:00
ReliableSession:
Enabled: False
SendTimeout: 00:01:00
TextEncoding: System.Text.UTF8Encoding
TransactionFlow: False

Except for the differences in addressing, all of the features that are on by default in the WsHttp binding match the BasicHttp binding. This is still true when we set the SecurityMode to Transport, although you have to pretend like that transaction binding element isn't there.

  1. System.ServiceModel.Channels.TransactionFlowBindingElement
  2. System.ServiceModel.Channels.TextMessageEncodingBindingElement
  3. System.ServiceModel.Channels.HttpsTransportBindingElement
    RequireClientCertificate: False
    Scheme: https

However, when we switch to Message security, a slight divergence begins to appear. The message security implementation is more like the one we saw with the NetTcp binding.

  1. System.ServiceModel.Channels.TransactionFlowBindingElement
  2. System.ServiceModel.Channels.SymmetricSecurityBindingElement
  3. System.ServiceModel.Channels.TextMessageEncodingBindingElement
  4. System.ServiceModel.Channels.HttpTransportBindingElement

Moving to the TransportWithMessageCredential security mode brings us back into line with the BasicHttp binding though.

  1. System.ServiceModel.Channels.TransactionFlowBindingElement
  2. System.ServiceModel.Channels.TransportSecurityBindingElement
  3. System.ServiceModel.Channels.TextMessageEncodingBindingElement
  4. System.ServiceModel.Channels.HttpsTransportBindingElement
    RequireClientCertificate: False
    Scheme: https

To finish things up, I tried bindings with the security mode again set to None and enabling either the reliable message or MTOM features.

  1. System.ServiceModel.Channels.TransactionFlowBindingElement
  2. System.ServiceModel.Channels.ReliableSessionBindingElement
    AcknowledgementInterval: 00:00:00.2000000
    EnableFlowControl: True
    InactivityTimeout: 00:10:00
    MaxPendingChannels: 128
    MaxRetryCount: 8
    MaxTransferWindowSize: 32
    Ordered: True
  3. System.ServiceModel.Channels.TextMessageEncodingBindingElement
  4. System.ServiceModel.Channels.HttpTransportBindingElement
  1. System.ServiceModel.Channels.TransactionFlowBindingElement
  2. System.ServiceModel.Channels.MtomMessageEncodingBindingElement
  3. System.ServiceModel.Channels.HttpTransportBindingElement

There's nothing special going on here that we haven't seen before.

Next week is going to be TechEd in Boston. There's no planned schedule of topics although I'll continue to try to write a new entry each day. After TechEd, I have some short topics about our transports before we get back into the series on the standard bindings.

Some time in the future: Framing Size Limits for the Tcp and Named Pipe Transports

Published Friday, June 09, 2006 5:00 AM by Nicholas Allen

Comments

Friday, June 09, 2006 12:56 PM by Nicholas Allen's Indigo Blog

# HTTP Request and Response Messages

I've talked about the request-reply message exchange pattern that HTTP uses, but we've never looked at...
Friday, June 23, 2006 12:44 PM by Nicholas Allen's Indigo Blog

# Inside the Standard Bindings: WSDualHttp

After a few days break, the series on standard bindings continues.  This week will take care of the remainder...
Tuesday, June 27, 2006 1:43 PM by Nicholas Allen's Indigo Blog

# Inside the Standard Bindings: WSFederationHttp


The final HTTP binding that I'm covering in this series is WSFederationHttp.  Federation is the ability...
Saturday, July 29, 2006 4:59 PM by Nicholas Allen's Indigo Blog

# BindingInspector Source Code

I thought I'd share the binding inspector program I wrote a few months ago to explore the different settings...
Wednesday, August 23, 2006 12:19 PM by Nicholas Allen's Indigo Blog

# Manually Adding MEX Endpoints

One of the changes in a recent version was that MEX endpoints no longer get added to your service host...
Sunday, October 08, 2006 7:14 PM by Nicholas Allen's Indigo Blog

# Manually Adding MEX Endpoints

One of the changes in a recent version was that MEX endpoints no longer get added to your service host
Thursday, January 25, 2007 11:48 AM by Sam Gentile

# Our .NET 3.0 Enterprise Application and Architecture Shipped

I posted yesterday that we had shipped our Enterprise Collateral Management solution based on our new

Wednesday, December 03, 2008 10:26 AM by Sam Gentile's Blog

# Our .NET 3.0 Enterprise Application and Architecture Shipped

I posted yesterday that we had shipped our Enterprise Collateral Management solution based on our new architecture. As I said, we still have a lot more to do. Several people have asked and many have been interested in the continuing blog posts that I

New Comments to this post are disabled
 
Page view tracker