WSO2 and the Raspberry PI

During our last WSO2Con, we gave away one Raspberry PI to each attendee. We did not do that because we think it is way cooler than a bag or a coffee mug, but mostly because our fabulous technical team, with our CEO Sanjiva at the forefront, thought that using this 35$ computer, we could do miracles. And so we did. 

First of all, we clustered it. 24 of them. You can read the whole story and see the pictures there: http://blog.afkham.org/2013/01/raspberry-pi-control-center.html. We used that cluster to run the WSO2Con event application. We used what we learnt to create an ultra-optimized execution mode for Carbon (something you will see soon in our products), and now our support team uses those same PIs to display the support dashboards at our offices.

You may ask: does that really matter to me ? How is that going to make the WSO2 products better or fix my problems ? My comment to that would be : because the same people who achieved this world-first cluster, built an application to manage it, built a power supply for the cluster, managed to run first-class middleware on such a small system, used a vacuum cleaner to cool their computers to build a new PI kernel (my favorite one!), those smart, committed people are the ones building our middleware and engaging with you directly through our support channels. And that, does matter to you.

Enterprise Integration Patterns in WSO2 ESB

We are often asked whether WSO2 ESB supports Enterprise Integration Patterns (EIP) – We just completed a very comprehensive guide here. Enterprise Patterns are classified and for each of them, you will:

  • Learn what the pattern is about 
  • Learn how implementing the pattern is achieved in WSO2 ESB
  • Get a sample configuration
  • For more complex patterns, get a tutorial taking you through the pattern implementation.

Enjoy!

Custom User Store in our Identity Server

Over the past 3 months, I have been leading a couple QuickStarts (or QSP as we call them) around API Manager and Identity Management (IS). Our API Manager relies on some of the IS components, especially for all OAuth2-based security scenarios ( issuing and validating access tokens).

In both QuickStarts, we had to create custom user stores, both backed by JDBC. We either totally replaced the default user store by a custom one, or leveraged the multiple user store feature. IS turned out very flexible to accomodate to the specific schema requirements of our customers, and my colleague Johann, who works in the IS team, very quickly implemented the custom code that would allow IS to interact with those custom user repositories.

The magic for all this to work is in the user-mgt.xml file. IS is packaged with a default LDAP-based store, based on ApacheDS. All other products are packaged with a JDBC-based store, using H2.

Here is a sample user store definition, which shows how you can externalize the SQL queries used to manage users and roles in the custom DB:

<UserStoreManager class="com.sample.wso2.TestUserStoreManager">
 <Property name="dataSource">jdbc/testuserstore</Property>
 <Property name="DomainName">custom.com</Property>
 <Property name="ReadOnly">false</Property>
 <Property name="MaxUserNameListLength">100</Property>
 <Property name="IsEmailUserName">false</Property>
 <Property name="DomainCalculation">default</Property>
 <Property name="PasswordDigest">SHA-256</Property>
 <Property name="StoreSaltedPassword">true</Property>
 <Property name="UserNameUniqueAcrossTenants">false</Property>
 <Property name="PasswordJavaRegEx">^[\S]{5,30}$</Property>
 <Property name="PasswordJavaScriptRegEx">^[\\S]{5,30}$</Property>
 <Property name="UsernameJavaRegEx">^[^~!#$;%^*+={}\\|\\\\&lt;&gt;,\'\"]{3,30}$</Property>
 <Property name="UsernameJavaScriptRegEx">^[\\S]{3,30}$</Property>
 <Property name="RolenameJavaRegEx">^[^~!#$;%^*+={}\\|\\\\&lt;&gt;,\'\"]{3,30}$</Property>
 <Property name="RolenameJavaScriptRegEx">^[\\S]{3,30}$</Property>
 <Property name="UserRolesCacheEnabled">true</Property>
 <Property name="maxFailedLoginAttempt">0</Property>
 <Property name="InternalJDBCRolesOnly">true</Property>
 <Property name="SelectUserID">SELECT USER_ID,PWD_HASH FROM USERS WHERE USER_ID=?</Property>
 <Property name="AddUser">INSERT INTO USERS (USER_ID, PWD_HASH) VALUES (?, ?)</Property>
 <Property name="GetIsUserExisting">SELECT USER_ID FROM USERS WHERE USER_ID=?</Property>
 ...
</UserStoreManager>

Now, what about coding ? Well, that’s the advantage of OpenSource code : here is the JDBCUserStore we use, which extends the AbstractUserStoreManager class:
https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.0.0/core/org.wso2.carbon.user.core/4.0.0/src/main/java/org/wso2/carbon/user/core/jdbc/JDBCUserStoreManager.java

A tip : start with overriding the user methods (addUser, getUser, isExistingUser, listUsers) as well as doAuthenticate.

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 blogging.com: 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. admin@blogging.com and work on the application server.

You can now deploy, manage and test applications on this tenant, using the specific tenant URL, for example: https://10.0.2.15:9446/services/t/blogging.com/HelloService?tryit.

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!