UPDATE: I have since moved these articles to my own blog and they can be found here.
My second article on integrating Windows Communication Foundation with BizTalk Server is now online. The one deals with all the various WCF security configurations and how BizTalk consumes each one.
Specifically, I address message vs. transport security, certificates, username tokens and declarative code-based security. It was pleasing to see how gracefully BizTalk accommodated each security permutation I threw at it.
Richard Seroter's Architecture Musings 
Hi Richard, Great series!
I’m struggling a bit with a WCF service that is hosted in a windows service and called from a biztalk orchestration and was hoping perhaps you may have some insight. The only way it will work, on my devlopment server, is to set the Biztalk WCF netTcp transport properties in biztalk to:
Security mode: Transport
Transport client credential type: windows
Transport protection level: EncryptAndSign.
No other security combination works. Why do I have to use this combination?
I’ve checked the config of the WCF service and there are no security/identity entries there. I’d like to test with “none” but it won’t seem to accept that.
Is there something on the service side I have to add in the config? Is it because this is hosted in a windows service?
When I deploy all of this on our build server, the Biztalk WCF netTcp transport properties set like above cause biztalk to just lock up (Running service instance never goes away and CPU goes through the roof). All other Biztalk WCF netTcp transport property combinations on the build server cause an immediate failure like my development box.
Hi Chris,
What error do you get with other security configurations? If you try hosting your service elsewhere (let’s say, self hosting) do you get the same behavior, or have you isolated it to the Windows service?
Hello Richard, I am trying to understand if the send port will be “reused” for multiple orquestrations instances. Specifically, that once the “handshake” process is done with the wcf service, it will maintain the wshtttp reliable session context. I will like to know if the https process overhead will be done for each orquestration instance since we will be sending more than 10K messages per hour. I am afraid that for each orquestration instance there will be a new “instance” of the send port and the security handshake process will be done for each. Do you have any idea how does this work?
Hi Nicholas, I would suspect that each send port instance is set up to do the handshake per request. That said, you can throttle how many send ports spawn for a given endpoint, so it’s not like you’d have 1000 simultaneous send port instances, unless you configured it that way. But, unless these are very long service calls, there really shouldn’t be a problem with the volume you mention.