Let me introduce you to our sample enterprise application, but firstly let us run through some of the rules of engagement for our sample enterprise application, and the logic and reasoning as to why we have chosen the application that we have.
Web-based: The application must be web-based. While there are certainly a large number of .Net applications designed today that are still 'thick clients', the move by enterprises in conjunction with Microsoft is to build web-based applications. In this case, the majority of the code runs on a backend sever, with just the presentation layer running on the client machines in a web browser. So our enterprise application will embrace the new Microsoft technologies, as would be expected if this were a new application built today.
Good design principles: The application must abstract the data, application, and presentation layers. Our enterprise application must adhere to good design principles as would be expected from an enterprise application.
Standard technologies: Our application will use off-the-shelf Microsoft technologies. While this isn't always the case, as most enterprise applications contain some third-party technologies, in the case of this example, we wanted to be sure that we were as 'vanilla' as possible and that the technologies were freely available from the Microsoft website.
Browser agnostic: Our candidate enterprise application must be browser and operating system agnostic, so no Internet Explorer-specific, or Windows-specific code on the client. We feel this is important, because even though your organization may be based around the Microsoft platform, the organizations that are your vendors and clients may not be.
No proprietary technologies: No use of proprietary technologies in the browser. By that we mean no use of Flash, Silverlight or any other technology, which will limit the adoption of your cloud application, for the same reasons as mentioned in the previous point.
Single sign on: Our application must support single sign on within an enterprise framework. This is mandatory for any modern enterprise application, and our cloud application is no different.
So now that we have our rules of engagement, where does that leave us?
Well, we have a 100 percent pure Microsoft web technology stack, using no proprietary technologies in the browser, which supports single sign on and is built using good design principles.
So what will our enterprise application look like?
Our enterprise application will be a fairly typical .ASP . Net application with one twist. Instead of using a .ASP Web Forms application, we will be using a .ASP Model View Controller or (MVC) application.
Note
For more information on .ASP .NET MVC please visit the Microsoft website at http://www.asp.net/mvc.
There are good design reasons for choosing a .ASP .Net MVC application, which are as follows:
Firstly, an MVC style application adheres very well to good enterprise design principles, separating the data (model), application (controller), and web (view) components of the application.
Secondly, Microsoft is investing heavily in both .ASP Web Forms and MVC, and both are healthy, active communities.
But thirdly, and most importantly, I'm going to show why a .ASP MVC application lendsitself much better to a cloud environment.
Note
Chapters 8 - Chapter 10 show how we can take our application and make it better in the cloud!
On the backend we are going to use Microsoft SQL Server. This is Microsoft's enterprise database solution and an appropriate choice for our enterprise application.
For the application tier, we will be using C# .NET.
For the presentation tier, we will be using Microsoft's Internet Information Server (IIS).
For our authentication, we are going to use Microsoft Active Directory (AD).
So our application will look something like this:
Our enterprise application will have a network load balancer, which will forward to two IIS servers. These in turn will use a redundant pair of application servers, which in turn will communicate with a SQL server database set up in a mirrored environment.
So that's the general architecture, but what will our enterprise application be called and what will it do?
Well, let's make it something that would be typically used within an organization, but something that wouldn't already be catered for by an off-the-shelf product. That rules out time-sheeting, for example.
Let's assume that our company makes software widgets for the software services industry. So our company would need some way of displaying what software services the company makes, as well as some way for customers to buy services on an on-going basis. There would need to be a way to identify clients, and to enable clients to stop their services at any time.
Let's call our company 'The Widget Company', and let's call our application "Widgets are always available here" or 'Waaah'!
Note
Waaah! is also the sound you will most likely be making when you get to the end of this book and discover just how much you have been missing out on by waiting so long to get on the AWS cloud!
For the purposes of this book, we will assume that the actual payment and purchasing of these widgets are handled elsewhere.
Here is a screenshot of our enterprise application Waaah:
We have a login screen, a screen that shows us all of the available products, and a screen that shows us just the products that the user has selected. (These are actually the same screen but displayed slightly differently using a filter).