Welcome to Windows Communication Foundation (WCF)
Top Tasks :

WCF Team Bloggers

Tuesday, January 09, 2007 - Posts

  • Manual Addressing

    How can a client application control the To address of an outgoing message? I don't want to create a new proxy for every connection. This is one of those topics that I could have sworn that I wrote about but can't find any evidence of it online. Actually, I was going through some papers the other day and found notes for five or six topics that got sketched out but never published. I'm guessing that that's what happened to the advice on manual addressing. In light of this discovery, today I'll focus solely on manual addressing from a service perspective and leave the channel perspective on manual addressing for another time. Manual addressing controls the stamping of addressing headers on outgoing messages. Normally, the transport just overwrites the message headers with whatever addressing information it's been configured with. No amount of fiddling at the service level will change that behavior because any existing addressing headers get obliterated when going through the transport. However, some transports, such as HTTP, have a setting on the binding element called ManualAddressing that turns off this automatic stamping behavior. Other transports, such as TCP, don't offer this option because it's not possible to redirect an existing TCP connection on a per-message basis. This isn't a problem for HTTP because every HTTP request can have its own connection if desired. Support for manual addressing of messages is purely a transport-specific feature. The answer to the question therefore comes in three parts. First, make sure that the transport that you're using supports some form of manual addressing. If not, then you're out of luck in terms of sending messages to different destinations without creating some new object on a per-destination basis. Second, turn on that manual addressing option to prevent the automatic application of addressing headers during message sends. Third, use whatever method you want to apply your own addressing headers to the outgoing message. If you're just making service calls on a proxy, then you'll want to use something like this: OperationContext.Current.OutgoingMessageHeaders.To = this .replyTo.Uri; If you're creating Message instances yourself, then you'll want to apply your addressing headers to the message header collection and so on. Next time: MSMQ: Net vs Integration Read More...
  • Final Touches on CardSpace Support for OhmBlog

    I fixed a few remaining issues today: 1. Cleaned up the logon page: have nice icons now for “Use an InfoCard” along with a better layout which I stole from Kevin Hammond ; also added a linkbutton that opens up the registration control, so that the login page is cleaner) 2. Added support for registering via a userid/password, in addition to an InfoCard 3. Removed the annoying warning about a mixed secure/non-secure pages by removing the link to jigsaw.w3.org/cssvalidator from the movable radio heat and movable radio blue templates (w3.org only supports HTTP traffic) 4. Added support for picking up the infocard claims and using them for the commenter metadata. That's pretty much all I plan on doing... next time, I'll talk about my other project - replacing SyndicationService.asmx with the WCF equivalent. Read More...

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us