Cloud Cover Episode 12 - Hosting WCF and Inter-Role Communication

Play Cloud Cover Episode 12 - Hosting WCF and Inter-Role Communication

The Discussion

  • User profile image

    Hi. Just wanted to thank you for another great episode. This really helped me understand better how to work with WCF inside Azure. You guys rock!!! Smiley

  • User profile image



    I don't think you could do the same thing using a Worker Role and not a "Web Role for WCF Service", since for some strange reason you can't use port 80 for self-hosting WCF in a WorkerRole.


    Go ahead and try to self host a WebHttpBinding Endpoint on a WorkerRole, then go and try it in a "Web Role for WCF Service" and you will see what I mean. The most interesting thing is that if you use any none Microsoft process on port 80 in a Worker Role, such as you did in your with your Mongoose server example, it works..



  • User profile image

    Hi tarlano -


    I will have to give it a shot.  It might be a case of the http versus tcp port choice (http.sys).  I have not tried what you are talking about, but I would be interested in seeing if it didn't work.  Thanks!

  • User profile image

    So, I gave it a shot and was able to host WCF services using the BasicHttpBinding on a worker role.  The only trick to this was that you needed to not only use the http (as opposed to tcp) port type, but you had to use the HostNameComparisonMode enumeration and set it to Exact.



    typeof(IEchoService), new BasicHttpBinding(BasicHttpSecurityMode.None) { HostNameComparisonMode = HostNameComparisonMode.Exact }, "echo");

  • User profile image

    Why we need to change “AddressFilterMode” on Windows Azure.


    Few days back I had firsthand experience where on-premise services stopped working when I hosted them on Windows Azure. After doing some digging I found that I’ve to change service behavior by adding [ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)]. It worked but why? I did some research and here is my version of why we have to change AddressFilterMode.Any or AddressFiterMode=Prefix. (During my investigation I found that AddressFiterMode=Prefix also works) Let me know if it is correct:


    Each WCF service endpoint has two addresses associated with it, logical and physical address (usually these two addresses are same). The logical address is “To” and physical address is “Via” and it is specified using WS-Addressing. WCF channel received incoming message using a particular transport at a specific physical address location. The WCF Dispatch maps the incoming message to an endpoint.  The message filter is used by dispatcher to determine the matching logical address/endpoint-address. The dispatch filters looks at address and contract calls the right method.


    On Windows Azure the public facing endpoints are actually Load-blance-endpoints. This means when a message arrives at the LB, it routes the message to the actual instance where is service is hosted. Now the SOAP message had endpoint which was LB-endpoint but the instance which actually processed the message was different. WCF match dispatcher filter tries to match the endpoint address and it fails.

    Therefore on windows azure we have to relax prefix match on the address of an incoming message and must relax the message filter rule at the message dispatch level by using AddressFiterMode=Any or AddressFiterMode=Prefix.



  • User profile image

    The more I think about the WCF services hosted using internal endpoints inside a worker role, it seems to me that the clients of these services are at a particular disadvantage compared to the clients of public WCF services behind NLB. Since these clients pick an instance at random (or use some sort of software load balancing algorithm) and then connect to them directly, they have to be particularly mindful about calling GetRandomEndpoint() method (and possibly implement retry logic) for every single call to account for fault and upgrade domains that each of those worker role instances belong to. Since the clients in this example are Web Roles with high availability (if more than 2 instances), not remembering to call GetRandomEndpoint() prior to service call may indirectly affect the availability of the app as a whole.


    What are your thougths or I am missing something here?

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.