Porting the VB.net App to the Cloud
Preliminary research into Windows Azure stated that it supported VB.net and so it was assumed that it should be ready to migrate. As it turns out, supporting a language is one thing; its host environment is another. The cloud infrastructure is quite different from a desktop PC or server and therefore the existing application needed to be adapted.
As described in Introducing Windows Azure (Chappell, 2009), “To interact with the application, the user relies on a single web role instance.” In this scenario, the user communicates through a web browser to a web role, which in turn communicates with the worker role (the background processing) via message queues. It turned out that the standalone VB.net application needed to be split into three loosely coupled distinct parts. They would be:
- A web role to handle the user interface. The ASP.net application would be running under the Internet Information Services (IIS) web server.
- A worker role with multiple instances. The VB.net module would be running under Windows Server 2008.
- A class module with the actual business logic. The VB.net class module would be imported by the worker role.
The final architecture showing these parts is shown in Figure 3. The next step was to move the standalone VB.net application to the ASP.net application.
VB.net to ASP.net
After completing the VB.net to ASP.net port, the web role GUI would have to be written, and the domain logic would be completed in the form of a VB.net class module, leaving only the worker role/web role inter-communication code. That was the plan at the beginning of this phase, although lessons were learned as it progressed.
The basic idea was to duplicate the existing VB.net GUI functionality in an ASP.net web form. Wherever feasible, the input fields, labels, controls, names etc. had to be kept exactly the same. Also the decision was made to use the vendor’s IDE, Visual Studio 2010, throughout the project, and not to code part of the project with a text editor, web design tool, or any other tool. Since the end goal was to develop a working ASP.net front end for a Windows Azure application, the supplied default templates were used initially.
Figure 3: Topography of the Migrated Cloud App
Immediately a problem was encountered, or at the very least a decision needed to be made before getting started. Somewhat confusingly, Visual Studio offers two ways to create an ASP.net application, a web project or a web site. Based on (MacDonald, Mabbutt, & Freeman, 2010), the simpler approach was chosen to use the project-less web site. At first glance, creating a new web site with Visual Studio 2010 produced a template with these main items:
- About.aspx
- Default.aspx
- A master page, site.master
- A style sheet, site.css
Using the tool’s “split view” between source and design views revealed a clean style, header, title and, most importantly, a built-in navigation bar. The idea behind the site.master was to give an ASP.net application a consistent look and feel between pages with code inherited from one central source file. Once again, the code functionality was separated as much as possible in order to aid in troubleshooting when deploying to the cloud – i.e. the default web page without any cloud specific code should come up first. The built-in navigation code was a significant time saver and, with some minor adjustments to the style sheet, the web site was personalized with a clean look and feel.
Developing the ASP.net web site in the same language as the standalone model, and using the same IDE used for the standalone VB.net application made the task straightforward. Since this was a web application, the method of accessing the data file that the simulation ran against needed to be changed from system I/O to a file upload. However, the built-in server file upload control and example code made this task easy. As stated previously, this migration step involved splitting the domain logic Monte Carlo Simulation into a separate VB.net Class module. It was evident that the Windows Azure application would require using some type of API for the web role/worker role inter-communication, but for this interim step, a simple import statement was used to emulate that functionality.
After completing the above steps, the project was ready to be tested. The Visual Studio 2010 IDE has a built-in web server to test an ASP.net application before actual deployment, and that is what was used to verify that the ASP.net web site would produce the same results as the standalone application. Initial verification was successful (Figure 4). At this point, the project was ready for the actual migration to Windows Azure.
Figure 4: ASP.net Monte Carlo Simulation Tool
ASP.net to Windows Azure
Setting up the Windows Azure Development Environment
Finally the project was at the stage where it was able to begin operating on the Windows Azure platform. One issue encountered with the development platform was that during the March/April 2011 timeframe of this project the Azure SDK changed from Version 1.3 to 1.4 and the installation method changed as well. A much simpler, all-in-one installation of SDK and Tools became available in April 2011. In fact, it changed while an installation of the tools was already in progress.
The next task was to start filling in the Windows Azure Project template with the previously created ASP.net code, including the VB.net Class module. Using code from the hands-on labs of the Windows Azure platform Training Kit, a first cut of the messaging code for the web role/worker role communication was designed and coded. In the Windows Azure platform the web roles and worker roles are loosely coupled and communicate asynchronously with messages stored in storage queues. Basically, the logic of calling a VB.net function or subfunction to initiate an action was replaced with writing a message to a storage queue. After the code for this mechanism was completed, the Azure application was ready to be compiled, built, and then executed in the Azure Emulator on the local machine.
For the initial running of the web role and a skeleton of the worker role in the Azure emulator, the actual domain logic (Monte Carlo simulation code) was disconnected to enable visualization of the running Azure cloud application. The web role displayed in the browser and the output log of the Azure emulator showed one instance of the worker role up and running.
Debug and Refine the Message Queues
Again using the example code from labs of the Windows Azure platform Training Kit and various articles on Azure message techniques, the web role/worker role communication logic was designed. All of the examples found to this point, however, used a single message queue with one-way communication from the web role (the master), to the worker role (the slave). Surprisingly, it was even stated that these queues were one-way in nature and that another process should be used to communicate back to the sender (Hay & Prince, 2010). This one-way communication was not appropriate for this particular application because the web role needed to know when the operations it gave to the worker roles were complete and what the results of those operations were.
A design using two queues was decided upon, one queue for in-bound messages (master queue) and one for out-bound (worker queue). Each message written to a queue had its own unique message ID and each worker role had its own role instance ID. It was now clear that a system could be designed to logically process the items of work. Searching the Internet revealed one simplistic example, written in C#, that used two message queues in this manner (Sawaya, 2010). Incorporating concepts from this example, the design worked with a single role instance. Next, the application was rebuilt with multiple worker role instances and was successfully able to exchange messages in a logical fashion.