Carbon And Multi-Tenancy

Time Flies .. we have been very busy here at WSO2 !

I promised I would talk about multi-tenancy , in our on-premises product and there it goes, finally! I recently worked on a packaged demo for a Governance Tutorial at WSO2Con – We illustrated how to prepare applications to separate environment specific data from an application. To simulate isolated Dev and QA environments, I leveraged the multi-tenancy feature of our AppServer ( this feature is part of the Carbon platform, and therefore available on-premises in most of our products).

ImageIn order to create a tenant, you need to login as “super-admin” , i.e. out of the box, the default admin/admin credentials. When you log as admin, you are in “super-tenant” mode. Managing tenants is only available in this mode. In the setup above, I have added two tenants: DevAS and QA-AS. Let’s add a third one:

ImageMost of the fields are rather obvious , but two need further attention:

  • Domain name, here this is a unique identifier for my domain. I need to use it to log into the admin console and being taken to my specific tenant, and it’s also used in URLs to distinguish one tenant from another.
  • Usage Plan :  this is inherited from our Stratos PaaS – The idea is that you can limit the capabilities of a tenant using a plan (nb of users, bandwidth, etc.) – The product comes with a predefined list, and you can add your one and/or tailor the existing ones. For on-premises deployment, there is only one default plan, Demo.

Once the tenant is created, you can log out from super tenant mode, log into your tenant, using the admin user you just created, i.e. and work on the application server.

You can now deploy, manage and test applications on this tenant, using the specific tenant URL, for example:

If you want to experience how this works in our PaaS environment, I encourage you to connect to StratosLive, which is a Stratos environment deployed and managed by WSO2.

That’s all for today !



Carbon: the core of WSO2 products

Carbon 4 is available! and there is no better way to start blogging about WSO2 than telling you about WSO2 core’s architecture and what the Carbon framework brings.

When I started to work with WSO2 products 6 months ago, the lean, well-designed, architecture behind it immediately convinced me we had gold in our hands. As a product manager, working with products built on top of a bad architecture is kind of a desperate task 🙂 As a friend of mine used to say, “there is that much lipstick one can put on a pig” meaning, if an architecture is bad, no matter how many pretty layers you put on top, it’s still a bad architecture…

So, what is Carbon? Carbon is a composable server architecture. When I explain this to customers, I usually make a parallel with Eclipse : as a developer, you download Eclipse, which provides some basic services and if you want your Eclipse environment to do more for you, you point at a repository, choose a set of features and install them. You don’t actually need to install another Eclipse instance. If you know you are going to develop say J2EE applications, you can download the J2EE edition, which comes pre-installed with the right set of features for this purpose.

All WSO2 products work exactly the same: you can start with the Carbon base and its core services, then install features on top, or you can download pre-packaged products depending on your needs: an ESB, a Business Process server, or an API management solution!

So, why is this a good architecture to start with ?

  1. It allows our customers to get a consistent experience across the platform : same admin console, same operational management, same clustering, same way to secure services, etc.
  2. It gives our customers freedom of choice in terms of setup and deployment. Let me illustrate this point by a couple examples: many of our customers are using the ESB and sometimes want to add BPEL support to it, as they need to orchestrate services and want to host those composite services in the same runtime as the ESB. All they need to do is downloading the ESB product, pointing to our P2 repository, and adding the BPM features on top of the ESB. In Carbon 4, we have made this even easier by grouping features in the administration console. This also works the other way around: if you think our packaged ESB is doing too much for your deployment, just remove the features you know you won’t use.
  3. You can easily separate the UI part from the server part: each feature comes with a UI and server part, and you can for example decide to remove all UIs if you want a server to run headless.
  4. It allows us to develop products much faster – A product is simply the Carbon core plus a few features on top, et voila.. We are reusing, leveraging everything the core has to offer. This allowed us to create the new API Manager product in less than 6 months.

How does it work ? As a user, you really don’t have to know.. but if you want to know how we leveraged OSGi and P2 Equinox to achieve this, I encourage you watch this presentation from our Director of Architecture (Afkham Azeez)  given at WSO2Con 2011.

Next, I will introduce how Carbon 4 supports multi-tenancy, even in an on-premise deployment!