WCSF, SaaS and multi-tenancy

About five years ago I worked for a company where we implemented a web-based enterprise SaaS solution for supply chain. In those days we didn't know it was SaaS, and we called ourselves an ASP (Application Service Provider). However, if it smells like an apple, feels like an apple and tastes like an apple...guess what, it's probably an apple :). I could go into a similar story about AJAX, but I wont.

Recently there was a question on the forums around WCSF and SaaS (Software As A Service). The question was on how WCSF fits in with the SaaS model. One of the cornerstones of SaaS is multi-tenancy. In its essence, a multi-tenant web application is one that is driven by metadata in order to allow it to look and behave differently depending on the customer who is accessing it.

In a multi-tenant solution, the data for multiple customers all lives in the same place and is tagged with additional metadata that defines which customer the data belongs to. For example in the simplest form (only for illustration) imagine each row in the database was tagged with a CustomerID. The system then automatically embeds the appropriate CustomerID in all queries to ensure that ONLY the appropriate data is retrieved. There are actually several variations on this where you can have separate databases / servers for each customer, however this is not a long-term scaleable solution.

Back to the WCSF question. One of the beauties of WCSF is our guidance "does what we do best" and then leaves the rest for you to implement as you will. In the case of SaaS, we don't give specific guidance within the factory on building SaaS sites. However, there are several capabilities within WCSF that play very well in a multi-tenant solution, and we definitely don't block you from implementing a SaaS solution.

• Services - CWAB sites are heavily service centric, and the service implementation can be dynamically replaced. This allows you to change on the fly the functionality depending on the customer. Services in this case are not strictly web services (though they include them) but are also your own custom objects that you want to be available throughout your application.
• Modularity - In CWAB, the web site is divided into separately deployable and loadable modules that are loaded at runtime. By building a module site you can turn on and off different portions of the site depending on the customer. This also plays well with the previous point in that within each module the Services can change depending on the customer metadata, etc.
• Dependency Injection - Modules within CWAB do not have to be responsible for managing and creating their dependencies. Using metadata they can have them injected at runtime. This means the dependencies can change based on the customer.
• MVP Separation - Within WCSF we give guidance on using the MVP pattern meaning that the UI (View) is abstracted from the UI business logic (Presenter). The main reason we do this is to provide testability of the UI however, the other benefit MVP yields is allowing you to reskin your presenters with multiple Views. This means CustomerA might have a completely different look and feel from CustomerB.

Of course the real heavy lifting of implementing the multi-tenant infrastructure is up to you, but when you do, WCSF can work nicely with it.

For more info on SaaS and multi-tenant architecture, check here. Also check out Eugenio Pace's blog.  Finally, if guidance on SaaS is something you'd like to see us deliver, please tell us with your vote.