After we have established the theoretical basis and requirements for our real-world FoodApp, we can finally focus our attention to actually coding and architecting something. In this part we will create the solution, all relevant projects and explore the configuration options available for cloud deployment. We will also take a look at some options available for inter-role communications and establishing a WCF service connection between two different roles.
This blog post is a little longer than I originally planned, so I hope you will still take the time to read it through. If you want to “jump” around a little, we cover the Pre-requisits first, move on to Creating the solution,Exploring the Configuration options and finally, cover Inter-role communication.
Pre-requisites
This article assumes you have already installed all the required tools for Azure Development. If not, hop on over to the Microsoft Web Platform Installer. You can then install the SDK with the PI instead of having to manually download all components. In case you don’t want to use the PI, you can use this link. This will install the emulators and integrations with Visual Studio 2010.
Other than software pre-requisites, I have to assume that you have some experience developing web sites using ASP.NET or better yet, ASP.NET MVC and that you have already used WCF services at some point in time.
Creating the solution
Let’s start with creating the solution, and adding the projects later. Create a new Project, and you will see Cloudlisted under the Installed Templates section. Select the Windows Azure Project.
Hold off on adding a web role, as we need to use a trick to create a MVC 3 application. But you can add a WCF Service Web Role and a Worker Role. You should rename the roles, after you add them – you can do that by pressing the little pencil icon on the right.
You will now see a solution created, with the two projects you specified and a “global” FoodApp.This is the project that defines the Azure deployment, and it also contains the configuration options.
Configuration options
Let us first explore the configuration options available. If you double click FoodApp.AnalyzerorFoodApp.Services under the Roles you will see the configuration editor. If you explore the available options, the most important ones in my opinion are Instance count, .NET trust leveland Endpoints.
The Available Settings
| .NET trust level | Full Trust unlocks several new possibilities previously not possible with the Windows Azure partial trust (which itself is similar to ASP.NET Medium Trust Policy), likeinvoking non-.NET code, inter-process communication via Named Pipes.
Note: Some features are still not available in the “Cloud”, like writing to registry, writing to system directories etc. |
| Instances | The name is pretty self-explanatory. This allows you to set the number of instances your role will spawn when it is deployed to Windows Azure. You can change this number later, depending on the needs of your application |
| Diagnostics | If you enable diagnostics, you can log to your Windows Azure storage account. We will cover more on diagnostics in a later blog post. |
| VM Size | There are currently 5 available sizes, ExtraSmall, Small, Medium, Large and ExtraLarge. They differ in respect to CPU cores, memory and disk space for local storage resources. You can read more about the differenceshere. |
| EndPoints | Endpoints are the connectors where the outside world can connect to your instances. They also provide ways for your roles to communicate amongst themselves. These endpoints can be of various types, like HTTP, HTTPS, TCP… Please note if you want to use HTTPS you need a valid certificate. |
| Local Storage | You can specify/partition your local storage by adding what are effectively folders. You can also specify sizes, and if |
| Certificates | You may associate certificates with your role, which you can then use for HTTPS connections. |
| Virtual Network | Windows Azure offers a service called Windows Azure Connect, which allows for IPsec protected connections between one or more computers in your local network and the role instances running inside Windows Azure. |
Our roles mostly have default settings for now, and it’s ok that way. We will change the options as we add features (e.g. services).
Adding the main front-end web role
As you may have noticed, we are missing a key role, the one where the actual web site will reside. The reason for this is that in its current version, the Azure SDK does not support MVC 3, and we want to use it for our front end.
Fortunately for us, there is a trick we can use, because in theory, Azure does not define a new programming concept, but merely a new deployment concept. So our old knowledge still applies.
Create the MVC3 Project
Let’s first add a new project to our solution. It should be an MVC3 Web Application. Following our naming convention, I have named it FoodApp.Web.
I want to use the Empty template, as I do not need the membership implemented. You can choose whatever suits your needs.
Work the References magic
Next step is to add some references. We need to add:
- Microsoft.Web.Infrastructure
- System.Web.Helpers
- System.Web.Razor
- System.Web.WebPages
- System.Web.WebPages.Deployment
- System.Web.WebPages.Razor
Make sure to set Copy Local to True on all of these assemblies.
Registering the project as a Web role
The next step is to tell the Azure deployment tool that we have this project, and that it is in fact a web role. We do this by right clicking on the Roles folder under the FoodApp and selecting Add > Web role Project in solution…
You get a list of all the projects suitable for the Web Role. In our case, there is only one, so we can add it.
Configure the endpoint
This step is optional, but it will not hurt you and could prove to be a good help later on, with complex applications. Double click the newly added Role, and select the Endpoints configuration tab. I have renamed the endpoint, and used a different port as I am already running IIS on my machine so “80” is already taken. This port and configuration will be used when you deploy the solution to the Cloud. You can however change this later on if you want to.
Running the application
It’s finally time to run our application for the first time. Admittedly, the results are a little anti-climactic. You will notice a couple tabs open in your browser, and if you look in the Compute Emulator, you will see three instances running.
Making the application work
Those of you that have done some MVC work already understand that the reason we see this error page is because we have no controller and no action defined, so the application has no idea what to do at this point.
This is a good time to create a new controller in the MVC project, I will create a controller named “HomeController”, and a new action called “Index”. Since MVC has a default route registration this will work out of the box.
Inter-role communications
When we first started exploring Azure this was a topic that was covered superficially in almost all the blog posts we could find. We tried to accomplish a fairly simple task of calling a WCF service, hosted in another role, from a web role.
While the basic functionality is the same as with using WCF Services in a classical approach, we must understand the fundamental difference of the cloud is that we do not know where our role is. Nor should we care.
There are two ways we could have achieved our goals. We intentionally avoided queues, service buses and other technology that seemed overly complicated for our initial look.
Public Endpoint
We could have used a public endpoint, and deployed the service before testing our solution. This is OK if you have separate developments, and a service that can be publicly accessed and is already running. You get the benefits of load balancing, and you skip all the hassle of getting the address of your role.
Internal Endpoint
However, for most projects that is not the case. While you may have some part of the service available to the outside world, we wanted to keep it internal. This meant using a mechanism in Azure called RoleEnvironment.
The first step, like any other .NET application is to add a service reference to the .svc. If you followed our advice, the FoodApp.Services project already contains a service called Service1.svc,and accompanying contract. We will get rid of this service in our next installment, but until then, let’s use it to prove a concept.
You can use the Discover feature and just ignore the address for now.
I will use our HomeController, and create an action called GetData that takes one argument. This action will call our service, hosted on a different role, and print the result.
Next step is to configure the endpoint for our services role. Again, I want to point out that this architectural decision was made solely on the premise of testing out certain options, and may not be suitable for all projects. Each instance costs money, so make sure you need to deploy one before you code it J.
I went ahead and configured one Internal endpoint in the FoodApp.Services role. The name is the key thing to remember in this case.
Now, we need to call this service from within the action. It is worth mentioning I have modified the default route definition, for clarity. I changed id to value.
My current action implementation looks like this:
public ActionResult GetData(int value)
{
string result = String.Empty;
return View();
}
Next step is to add the View, and for simplicity sake, I will use the ViewBag feature instead of a type-safe view.
The View code is:
@{
ViewBag.Title = ”GetData”;
}
<h2>GetData</h2>
The response recieved from the service was:<br />
@ViewBag.Response
Now the question remains how to connect to the service. As mentioned previously, the key difference is the address to which we need to connect. As we are connecting to an internal endpoint, we won’t have the benefit of a true load balancer. For our demo, we will use a “random” load balance where our algorithm randomly selects the instance to connect to.
To use the functionality of the Azure environment, make sure you add a reference toMicrosoft.WindowsAzure.ServiceRuntime assembly. This is necessary because we created the MVC3 project using a minor hack.
The next step is to create a function to return a random endpoint. We will then use a ChannelFactory<> to create a channel and call the GetData method on the service.
The implementation will look something like this:
private static EndpointAddress GetRandomEnpoint()
{
var endpoints =
RoleEnvironment.Roles["FoodApp.Services"].Instances.Select(i => i.InstanceEndpoints["InternalEndpoint"]).ToArray();
var r = new Random();
return new EndpointAddress(String.Format(“http://{0}/Service1.svc”,
endpoints[r.Next(endpoints.Count() - 1)].IPEndpoint));
}
The reason this works is RoleEnvironment conveniently contains a list of all our available internal endpoints. Public endpoints are not listed in this array!
So what we effectively end up doing is retrieving the role named FoodApp.Services (the name is the same as what we named it a few steps earlier when creating the solution). We then query this role for instances and select all endpoints like the one we created earlier named InternalEndpoint.
Note: this code is all but production, so make sure to use best practices, like checking for null values, constants instead of magic strings, etc.
Ok, so once we get the endpoint array, we get the next random address. This leaves us to modify the action implementation to include the following code:
var factory = new ChannelFactory<SampleService.IService1>(“BasicHttpBinding_IService1″);
var client = factory.CreateChannel(GetRandomEnpoint());
result = client.GetData(value);
If you want to get creative you can get the endpoint first, and also print that out in your result – just to see if ourrandom load balancing works. Sure enough, if we run this code now, and open the corresponding address, passing in “5” as our parameter, this is the output.
The key part to take out of this is that we can safely ignore the configured endpoint address, as the service is listening somewhere else. If we now try to increase the instance count, and refreshing the page a couple of times you will see that the endpoints are indeed fairly randomly chosen.
Retrieved from: http://www.studiopesec.com/blog/azure-applications-101-part-ii.html
For more information visit Windows VPS | Shared Hosting | Forex VPS | Cheap VPS | MT4 VPS| Cheap Hosting |Windows Hosting | Virtual Server | VPS Hosting
