Simply SaaS (Part 3)

This is part three of a multi part series where I will talk about what it means to develop and deliver a Software-as-a-Service application. I'll be trying to strike a balance between the technical aspects of bringing an app into the cloud and the advantages of using the SaaS approach as an Independent Software Vendor (ISV). I am NOT an expert in SaaS by any means...I'm writing this to educate myself and hopefully any reader that has the same curiosity. Your mileage may vary.


In the last post we talked about a sample SaaS application to be developed, discussed getting started with our development framework (SaaSGrid Express), and covered setting up our deployment infrastructure (Amazon EC2). With this post we will take a look at the SaaSGrid SDK in action to give a better idea of how easy it is to SaaS-enable a .NET application. To get started we need the following:

1. Visual Studio 2010 - Since I don't own a copy of Visual Studio, I decided to give the 30 day trial a spin for this exercise. Although I didn't try it you can use the Express version of VS with SaaSGrid if you follow the instructions here.
2. SaaSGrid SDK - You may have already installed this when you installed SaaSGrid. If not you can download it here.
3. Familiarity with Windows Communication Foundation (WCF). It's pretty much essential to all things SaaSGrid. I'd highly recommend the book "Programming WCF Services" if your knowledge is advanced enough to circumvent the Hello World tutorial and move directly into best practices.
4. You should read the "Developer Topics" section of the SaaSGrid Developer Guide at a minimum - if you are really serious about using SaaSGrid you should take the time to work your way through the guide in its entirety before you sit down to develop.

In order for SaaSGrid to function properly, your Visual Studio project must adhere to a semi-rigid structure. The project must consist of a root project that houses the Web UI and one or more projects that contain the WCF services needed to make your Web UI function. Additionally a "Database Scripts" folder with a file called ApplicationProvisioning_Script.sql must contain the SQL necessary to build the table structure(s) for your WCF services to use. For my project I relied on the SaaSGrid template (that's included in the install of the SDK) to provide the basic structure. I ended up replacing the root web application project with an ASP.NET MVC 2 web application project since I was interested in checking out the .NET MVC framework. If you follow a similar path be sure to copy the SaaSGrid.cfg.xml file from the original root web application. 


In a SaaSGrid application WCF services will provide the majority of the application's functionality. This paradigm doesn't fit the traditional MVC development methodology but I was able to find some people that took the same plunge. Additionally, If you're like me and think most modern web applications will have a mobile counterpart, the push to a "pure" service oriented web application is a good thing. Not only will your application be ready to scale at the click of a button - you'll be able to pump out a mobile app without the added effort of exposing your application's business logic after the fact. Sweet. 

Recalling the description I gave for the sample application, a movie buff (Fred Film) will be able to manage a list of his/her favorite movies. Movie rental store owners (Ralph Rental) will be able to connect with users like Fred Film and tell Fred how many copies of his favorite movies they have in stock so that Fred can plan accordingly before heading out to the store. As an added bonus Ralph will be able to collect demographic information on users like Fred and perform some very simple analysis on his client base so that he can optimize his marketing strategies moving forward. Since we are building one application instead of two separate apps (one for the general public and another for store owners) we need to define the features of the application that will be for paying subscribers (i.e., store owners) only:

• The ability to set the inventory level for a given movie
• Associate a movie with the store
• Provide 10 reports a month that show the number of users (based on zip code) connected to the subscribers store

At a general level, here are the features of the application that the general public can use:

• Find and associate with a local rental store
• Add favorite movies
• View the inventory level of the user's favorite movie at his/her local rental store

Another great feature about SaaSGrid is that it controls the account (and role) creation for all users of your application. We can organize the functionality that we need to implement into the various roles and start coding. Let's take a look at our first SaaSGrid enabled method signature in a service interface we've defined for a rental store owner:

The FaultContract attribute will raise an exception if there is a failed authorization when trying to execute the implemented version of this method. This attribute indicates that the implemented function will contain SaaSGrid authorization. Now let's look at the implemented method for the signature above:

The Secured attribute in the implemented method defines a role based operation for associating a movie to a store. As you can see there is very little effort for this level of granularity. In fact all we are doing is decorating the method with an attribute - no code change required! Also note that I'm taking advantage of the TenantId instead of making the developer supply a Guid for a given store. The SaaSGrid SDK provides access to a series of heirarchal contexts (e.g., ProviderContext, TenantContext) allowing developers to access relevant details about the current tenant, user, provider, etc. This concept is another reason why it's important to go through the SaaSGrid Developer Guide. This post provides some additional details on accessing information that belongs to tenant's outside of the scope of the current context.


To help with testing your application locally you'll need to use the Mocker application (installed as part of the SDK) to add sample tenants, users, roles, as well as securables. You will need to define a securable for each Secured attribute that's in your application (essentially the attribute value is the securable definition). When you define each role you'll assign one or more securables to a role to define permissions. Moving on, roles are assigned to users and users belong to a tenant (or subscriber). Finally, before you launch the debugger for your WCF services and your web app, you will need to create the database and tables by executing the SQL contained in the ApplicationProvisioning_Script.sql script that was previously defined.


In the next post I'll show case some snippets that highlight finer grained monetization constructs, discuss how to package your application for deployment, discuss the product management features included with SaaSGrid, and talk about versioning your application. Enjoy!

You're OK with .NET?

So sue me, I think Visual Studio is a damn fine product. I'd like to elaborate on why, despite Visual Studio's cool factor, I think the majority of .NET products end up being crap.

From talking with a few .NET developers and working with .NET a little lately, I have come to realize that Microsoft forces developers into design patterns and makes it easy for developers to get comfortable with Microsoft dictating their programming style (amongst other things of course). Granted it's not impossible to break out of the canned design pattern(s) but Microsoft would much prefer if you just used what they give you. Microsoft is like the parents in the movie The Christmas Story when they make their son, Ralph (aka you the .NET developer), put on the pink bunny suit. Ralph didn't want to do it but it was easier than starting a fight on Christmas morning.

Why you wouldn't free the developer to make their own decisions is beyond me but I guess developers who pay an arm and a leg for a IDE don't want the extra burden of a white board session or two. All in all Visual Studio is perfect for the lazy developer...you don't have to go through that strenuous activity of thinking about architecture and feel perfectly comfortable doing things such as mixing up business logic with the presentation stuff. It's a good thing you sold all those crazy books on logic and theory for beer money after all because you won't be needing them here.

Before you think I'm being to negative - don't get me wrong, it's entirely possible to build a .NET application that goes above and beyond. Myspace.com is the biggest website out there and that's powered by ASP.NET (come on, who said good products have to be visually pleasing?). Microsoft has a large influence in the enterprise and attract a lot of brilliant developers who hammer away at mission critical applications day in and day out with nary a hiccup. The real issue I still have with .NET is that it makes lazy developers even lazier and those developers end up thinking they are smarter than they really are. There I said it, .NET developers can be successful but they really need to think before they code and they need to keep in mind that it is OK to break free from Microsoft once in a while.

Yea it's rant, yea I haven't posted in a while, but this topic is something that reinforces my frustration with developers who focus entirely on the monetary aspect of software development instead of appreciating the art that it really is. Let me leave you with this last comment, how many happy, inspired .NET developers do you see out there?