Deploying WCF Service on Azure : Web Role or Worker Role? - wcf

I am evaluating the various options to deploy a web service in Azure. Presently, the web service would be consumed only by a front end UI which will be deployed as a separate web role within the same cloud service that would be hosting the web service. However, the web service would be exposed in its own right at a later stage. Apparently, web services can be hosted from within either Web Role or from a worker role. Could you please throw some light on pros and cons of either approach? Which of these approaches would you recommend for my scnario?

A web role assumes that the application will be hosted in IIS. If your service does not require any of the benefits provided by IIS or its HTTP stack, then hosting it in a worker role may do you perfectly fine and also provide you a lower resource utilization for that service (since there's no "overhead" for the IIS server).

Related

How to Consume Non-public NTLM WCF Service From Windows Azure Cloud Service?

I have a Windows Azure Cloud Service with a single worker role. The worker role's App.config file specifies NTLM credentials should be used for the WCF authentication (Gist for all of this : http://goo.gl/wFCLv7 ).
Everything works as expected locally but when I deploy my CloudService to Azure, though I am prompted to enter my NTLM credentials (which are successfully audited according to the Windows Event Security logs of the Worker Role's machine which I RDP onto), invocations of the WCF service return null. (I don't know how to gather further debugging information)
After verifying with colleagues, sure enough the host machine for the WCF service is private, and not publicly facing - this probably explains why I can't query it from my application when it is hosted on the cloud, even with my Windows Authentication credentials.
How to I leverage non-public, NTLM-secure WCF services from Windows Azure? What do I need to change on the WCF server in order to consume the services from Azure? An easy answer may be to make the WCF host public - however the company is very fearful of "The Cloud" as it is -- is there a smaller alternative that can used for proof of concept?
Best,
networking/security/Azure noob

Restrict WCF Service Calls to Regions

The company I'm working at does not have a great Infrastructure, it is treated as one big network, there is no network segregation. As such when were developing applications we have a TEST/UAT/PROD/DR setup. I have been developing a suite of services that have been deployed on all the above regions. How do i make sure that a developer can not call a production web service by accident? Is there anyway to restrict the service by caller (ie: server name?).
BTW all these services are internal and are not externally available.
Thanks Again for your help.
Josh
You could use Role based Authorization
Authorization In WCF-Based Services

Azure endpoints - different deployments

Currently we run a UI web role and a web service web role(WCF REST) on Azure. Each role contains 2 instances (for load balancing and meeting the SLA reqs.)
The UI Web role and web service web role are within the same subscription but in different deployments. We do not want to merge the code bases (maintainability etc etc). So the UI layer is on xyz.cloudapp.net and the Web Service layer is on abc.cloudapp.net.
Currently, the requirement is to make the web service web role an internal endpoint i.e only accessible by the UI layer. The literature on configuring internal endpoints and accessing it from a different deployment is not very clear.
I am assuming that the two different roles need to be part of a single deployment for this to work. Can this be done without affecting the deployments? Any pointers in the right direction would be greatly appreciated.
Internal endpoints are only accessible within a single deployment, and do not route through the load balancer (so if you have 2 instances of your wcf services accessible on internal endpoint, you'd need to distribute calls between the instances). This, of course, would require you to put both your web role and wcf web role into the same deployment.
You might want to consider service bus for a secure way of reaching your wcf services from your web role instances. Or... expose the wcf services via input endpoint but secure the service.
There's an approach I like to call the virtual DMZ that sould meet your needs: http://brentdacodemonkey.wordpress.com/?s=virtual+dmz
It leverages the ACS and WCF bindings to allow you to create access control to input endpoints (which are then load balanced). Of course, if you don't want something tha robust, you can go with just a standard old WCF mutual auth scenario.
That said, David makes an excellent point. Internal endpoints are only accessible with a single deployed service. This is because that service represents an isolation boundary (think virtual lan branch) and the only input endpoints can be adressed from outside of that boundary.
Have you considered using ACS (Access Control Services) for restricting access using claims-based authentication to your WCF endpoint?
There are numerous protection schemes you could provide via WCF bindings.
Internal Endpoints can only communicate with inter-roles in the same deployment. If you have 2 separate deployments (abc.cloudapp.net and xyz.cloudapp.net, internal endpoints won't help you).

Why would you want to deploy a Web Service as a Web Role on Azure?

I was under the impression that a Web Service that should be run under a worker role. I just found out that a web service can be setup using the web role. What are the advantages to using one role over the other ?
If you use the Web Role, your service will be hosted in a full IIS, and you can for exemple co-host it with your Web site, and use all of IIS features.
If you go for a Worker Role, you will have to new up a ServiceHost to host your service. You will not run within IIS.
I answered a similar question here. Note that, even with a Web Role, you'll have your choice of hosting your web service via IIS or on your own with a Service Host.
Back in March, there was an update to input port handling, so now you can spread your input ports out across your roles in any fashion you like, even having up to 25 in one role. This mitigates issues related to single-role deployments with RDP enabled (since in that case, RDP consumes 2 input ports). See my blog post here for more info about port allocation, as it really opens up options for you when setting up service-hosting.

"Role discovery data is unavailable" when accessing Azure RoleEnvironment

I am using a WCF Service (which is a web role) and is interacting with the worker role. When I try to throttle between different instances of the worker role. It throws the following exception:
"Role discovery data is unavailable"
RoleEnvironment.Roles["MyWorkerRole"]
is not accessible in the WCF web service.
I am answering to my own question to clarify a bit. I am new to Windows Azure and did not get the full concept of implementing WCF in Windows Azure and tried to add a simple WCF service using add new project and then wanted to add that WCF service by adding web reference of it in the web role (which is not the right way).
Watch this video, if you are experiencing problems with WCF and Azure and don't know in detail about the basics of Azure...
Azure Walkthrough of WCF by Ryan and Steve