none
转:Inside the Standard Bindings: WSHttp RRS feed

  • 常规讨论

  • Nicholas Allen's Indigo Blog

    Windows Communication Foundation From the Inside
    原文地址:http://blogs.msdn.com/drnick/archive/2006/06/09/623578.aspx


    Inside the Standard Bindings: WSHttp

    Index for bindings in this series:

    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


    Frank Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
    欢迎访问老徐的中文技术博客:Welcome to My Chinese Technical Blog
    欢迎访问微软WCF中文技术论坛:Welcome to Microsoft Chinese WCF Forum
    欢迎访问微软WCF英文技术论坛:Welcome to Microsoft English WCF Forum
    2010年1月17日 14:04
    版主