Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

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

Download

Right click “Save as…”

  • WMV (WMV Video)
  • MP3 (Audio only)
  • MP4 (iPhone, Android)
  • Mid Quality WMV (Lo-band, Mobile)
Join Ryan and Steve each week as they cover the Microsoft cloud. You can follow and interact with the show at @cloudcovershow

In this episode: 
  • Learn how to host WCF Services in Windows Azure using public input endpoints as well as private internal endpoints (i.e. inter-role communication)
  • Discover how to get your WCF Services MEX endpoints working from behind the load balancer

Show Links:

Exporting Data from SQL Azure
Vertical Partitioning in SQL Azure: Part 1
Extending the Thumbnails Sample
Datacastle Brings Data Protection From the Cloud
2-hr Windows Azure class (includes free hours on Windows Azure)

Tags:

Follow the Discussion

  • Hans Olavhansol Cloudtastic

    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

  • 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 

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

  • 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");

  • 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

  • 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?

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.