1. Java Paas : Building your first app
2. Java PaaS : Handling authentication in your web apps

Before proceeding further let me clarify some terms that we’ll be using . It has become a bit cloudy (no pun intended) since many people mean different things for the same word.

Multitenancy – In the context of Stratos, I’m using the word multitenancy to mean as defined in Wikipedia.

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants).

When you register and get an account in Stratos, that’s a tenant. An organization. Your data will be isolated from other tenants/organizations in the system. When you sign up, you’ll be creating the administrator account for your tenant. Which we naturally refer to as the tenant admin. Tenant admin can add users to your domain, turn off/on various Stratos services such as the ESB, App Server, Data Services Server etc… Monitor data and bandwidth usage of your users, grant/revoke permissions to users.

Let’s me take a little step back here. When you talk about Stratos, there are two major deployment scenarios. One that’s hosted by WSO2. That’s available to users as a service, you sign up, you get an account, your data is hosted on hardware that we manage. This version is called StratosLive. Other scenario, you setup Stratos on your hardware in your private data center, you control everything it’s not accessible to anyone else.

2 scenarios. StratosLive vs Stratos on your private cloud.

Now, coming back to multitenancy, there’s one user we called the super tenant. This acts as an admin account for all the tenants in Stratos. It’s configured at the time of setting up Stratos. In StratosLive scenario, super tenant is WSO2. In the other scenario, super tenant is you. You can do stuff which will affect to all the tenants across the system. Why would you need this? It’s necessary when you’re developing SaaS applications. You’re providing a service which all the tenants can use.

In Stratos, to make your applications SaaSify you need to add a context parameter to your deployment descriptor.

<context-param>
    <param-name>carbon.enable.saas</param-name>
    <param-value>true</param-value>
</context-param>

Authentication mechanism will be the standard form based authentication that we configured in the Jwitter app we developed earlier. This however, does not mean that this is the only thing that you need to build SaaS applications, nor does it allow you to take any existing web app out their and magically turn it to a multitenanted app. For that you need to have a multitenant data architecture for you application.

When you add the context parameter and deploy the web application as the super tenant, Stratos will authenticate against any user account in the system that has sufficient permissions. When you call request.getPrincipal().getName(), user account will appear in the format foo@example.com. From this point on it’s upto you to move to the bits of your application.

“Cloud requirements” differ from person to person and for what they’ll be using the technology. And of course, methods for reaching to the clouds are as diverse as the requirements (ahem).

• For a hosting company adopting cloud technologies means having an infrastructure that enable them to create virtual machines from a cluster of servers upon customer requests. Using Xen/KVM/OpenNebula etc… they can easily do this. Additionally what they need is a nice web based interface that they can integrate into their existing customer portals.
• A web based application vendor, changes they need to make their applications to run in the cloud is minimal. Here, a differentiation should be made for single-tenanted vs. multi-tenanted applications. Popular multi-tenanted web applications include Google Apps and Salesforce.com. SQL Azure, the popular database as a service platform runs on a multi-tenanted version of SQL Server.
• When it’s not a web based application things start to get interesting. Paul has written a wonderful post explaining the requirements that need to fulfill in order to be called a “cloud native” application.

As Paul mentions, being “on the cloud”, applications need to have features like autoscaling. Pay for what you use has a huge advantage of paying for resources depending on your daily resource needs. Several more aspects are listed on his post.