Comment Feed for Channel 9 - Cloud Cover Episode 12 - Hosting WCF and Inter-Role Communication

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

hansol — Fri, 21 May 2010 22:06:16 GMT

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!!!

posted by hansol

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

tarlano — Sun, 23 May 2010 22:39:50 GMT

Guys,

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..

Anthony

posted by tarlano

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

dunnry — Mon, 24 May 2010 05:05:02 GMT

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!

posted by dunnry

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

dunnry — Fri, 28 May 2010 23:18:41 GMT

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.

host.AddServiceEndpoint(

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

posted by dunnry

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

PantherOS — Fri, 25 Jun 2010 22:52:19 GMT

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.

References:

http://msdn.microsoft.com/en-us/magazine/cc163412.aspx

http://msdn.microsoft.com/en-us/library/system.servicemodel.addressfiltermode.aspx

posted by PantherOS

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

soham.tech — Wed, 14 Jul 2010 03:33:12 GMT

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?

posted by soham.tech