As promised, here begins the technical portion of the series on moving application functionality to the cloud.
As suggested, we’re going to take code from a couple of previous posts and put it in the cloud (although not immediately – first we’re going to move it to a local web-service, consume that in AutoCAD, and then look at our various cloud-hosting options).
So why did I choose these two pieces of code, in particular? A couple of reasons: firstly, they both implement “behind-the-scenes” algorithms that are independent of AutoCAD – a typical piece of business logic that companies might choose to place behind a web-service, in my opinion – and, secondly, they are both implemented in F#, which gives us an opportunity to abstract away technology from the user (it removes the need to deploy a separate class library built using F# from our application).
We’re going to use ASP.NET for this effort, which is Microsoft’s application framework for creating web-sites and applications. To expose our web-services (as opposed to a web-site), we’re going to make use of the ASP.NET Web API feature, which is brand new in the as-yet-unreleased ASP.NET MVC 4.
Let’s first resolve some acronyms…
ASP.NET is the .NET-based version of ASP, which standards for Active Server Pages rather than Application Service Provider.
ASP.NET MVC is a framework that sits on top of ASP.NET (which perhaps makes it a meta-framework or even a meta-meta-framework, if you consider the CLR :-) allowing web developers to use the Model-View-Controller architectural pattern (a type of design pattern) to implement web-sites. MVC encourages a clean separation of data (the model) from the way it is presented (the view) and interacted with (the controller).
It’s not specifically interesting to us in today’s post – where we’re simply using MVC 4 to get at the Web API feature – but it’s generally an interesting paradigm for web-site exposure.
So why use an unreleased (albeit open source) technology for this post? The short answer is that the Web API makes it incredibly easy to expose RESTful web-services. I’ve briefly mention REST a few times in the past, but it’s been a while. I fully expect to be making increasing use of web-services implementing REST over the coming years, though.
I won’t go into the steps needed to install ASP.NET MVC 4, but I will just say that there are a few different ways of getting it, right now: you can install the Beta for Visual Studio 2010, you can install Visual Studio 11 Express Beta for Web, or you can install Visual Studio 11 Ultimate Beta. I was a little unlucky, in that I had Visual Studio 11 Professional Beta installed – which meant I lost some time trying to install MVC 4 Beta on to of it, before I realised I actually needed to upgrade to Ultimate – but I got there in the end. One thing to bear in mind for later: at the time of writing it seems the Windows Azure .NET SDK doesn’t support Visual Studio 11, so I may have some hurdles to face when I get to that point. So sticking with VS2010 may prove the best option, for those of you who haven’t yet gone with VS11 (they can sit side-by-side, anyway, which is how I’ll probably manage the Azure deployment).
With MVC 4 installed, I went ahead and looked at the project types to create. If you want a good foundational article on using the Web API to use C# to expose web-services, take a look at this one. In our case, we want to use F# on the server, so I ended up choosing an online project template that gives us both C# and F# in an MVC 4 app:
We then get to specify that we want an Web API project and that we don’t (for the purposes of this simple example) care about testing:
This creates some nice boilerplate code that makes it really easy to expose our web-services. In the next post we’ll flesh out this project, hooking it up with our existing F# code to expose a couple of web-services for consumption inside our AutoCAD application.