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 ?
- 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.
- 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.
- 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.
- 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!