But then, my 3rd anniversary in Red Hat is due in 4 days too, so I will take the opportunity to also talk a bit about JAIN SLEE and Mobicents history or how close we became.
In case you are not *that* familiar with the JAIN SLEE container, and Mobicents JAIN SLEE in particular, sometimes it is defined as - specially by competing specifications :) - as a heavy weight platform, mostly with respect to 2 ideas: it is a lot more than you will ever need, and a bit as a consequence, it is impossible that it keeps up in performance.
The above ideas are both very wrong, lets begin with the first one. SLEE was designed to fulfill the requirements for full feature carrier grade telco apps, and those, if taken serious, will always needs the army of management APIs that SLEE provides and others competing specs don't. It's hard to conceive, if you are responsible for a serious telco app, that you think it is important that the app runtime code follows a spec but then all the management can be proprietary... Sure one can say that now one has JMX and other frameworks, but those are just generic frameworks, it's way too far to bind to the runtime application needs, I would say that one needs to develop more on the management side that on service runtime logic, and that is of course a bad thing. SLEE used to have the muddy and proprietary RA API, but the 1.1 revision nailed it, making it a complete platform spec.
Anyway, I'm not saying the SLEE spec is perfect, no way, in my humble opinion it is far from that... For instance I'm not a big supporter of SLEE profiles, it's a bit like reinventing the wheel, and Java EE has very nice round and shinny ones! Another bad point is the too strong relation with Java transactions, I would prefer something transparent as all Java EE APIs, if you want/need then use it, otherwise skip it, this would be really nice specially when the big majority of external resources use APIs which are not transaction aware, making the recover of a rollback a lot of trouble. Shhhh... it's also very true, then even when it is good to use it, a lot of developers tend to ignore or run away from it, it's scary some say. On top of it add a good mix of abstract components which most people struggle to understand difference of objects and entities and there you go, SLEE API runtime gets ugly and complex... well, at least till you get it after a couple weeks or months, by that time if you're still on SLEE there are high chances that you now are in love with it and try to apply it to everything out there, even if it is nothing more that an hello world, perhaps because it is was such a challenge? Okay, enough enough ;-)
The second argument, SLEE is slower, this one I really don't understand, SLEE is by all means at least at same performance of other specifications, and by the time you start adding extras that you end up needing, such as management parts or data sources/transactions, SLEE is probably way faster than anything out there, and that is simply - on top of the highly efficient async model - because that big platform design/api was fine tuned considering all parts, and there are very high chances that the user will fail to come up with something proprietary that tuned. Right, nothing impossible of course, but how many apps do you known with good performance that don't need a fine profiling and tuning till you end up loosing most of the language high level charm? Doesn't even matter of which spec...
And that's it, my bla bla bla of why SLEE is big, why SLEE is full of features you may not need in your app first release, etc etc, which leads to what really this post is about. Maybe a bit of more preliminaries first? Okay, lets talk about Mobicents history, right someone of you are now awake...
Mobicents open source started right in the middle of the java.net boom, and once JAIN SLEE 1.0 spec was out, a top secret society - including Ivelin Ivanov (now JBoss Commnications / Mobicents platform lead), Ranga (now JAIN SIP API and RI lead), Jean Deruelle (now Mobicents SIP Servlets! lead) and others (it's funny the well known OSS related names you find out in the oldest sources) gather around that new shinny platform, maybe noticing that it could very well be the most wanted piece of telco software in the following years, and knowing that the telco middleware cost was outrageous it was difficult to not succeed...
Well, that didn't came fast, even with very good developers, JAIN SLEE is not an easy platform to implement, it took quite some time to achieve certification, and surprise surprise... after all those years it's still is a 3 vendor world, well 2 if we only consider the certified ones. Others have tried, and with a lot of resources, but eventually gave up, the JAIN SLEE market really struggled to justify that investment too, be it because another spec, more high level took off - Sip Servlets, be it because it was damn hard to understand the API in one week, or even because the serious offers at that time were not that cheap. And this is the world which I got in right after university, but hey I was really really lucky, I was always around good people, first in Portugal Telecom Inovação, and then in Red Hat, and those persons gave me the chance to learn a lot in such short time. What better places to learn both telco related and OSS Java development than those companies, they are fors sure in the top for each "world" :-)
Moving on, I switched to Red Hat/JBoss in the 1st of May 2007 , when the company bought the rights for the Mobicents code and the first year and half was just to make it a product. Like I said the code was complex, many different authors in many different times, we started with SIP performance around 10/15 cps, no kidding. By the time we achieved version 1.2 we were able to come up with around 150 cps, at that time we were getting almost all we could get of it, and was time to kickoff the development of the second generation, targeting the new 1.1 spec revision, which EG I joined late.
Clearly we need to start from its foundations, but we couldn't simply throw away the 1.2 code, too risky and not much time, but even with such constraints the team came up with something like 75% of new code, and it paid off, the 2.0.0.GA born with strong features and performance (well above the 500 cps mark). The "core" code had now new modules to deal with JAIN SLEE components building and management, combining stuff like JAXB or Javassist, or very different code such as the SLEE profiles mapping to JPA, attractive to any open source developer for sure, all the latest and challenging APIs or tools (big bet in JBoss AS5 and Maven2 also) to get dirty, improve skills and why not, get a better job around Mobicents or these technologies, that's what happened to me and all of the Mobicents team, it's that real, open source communities pay off!
Okay, against my believes, the community didn't jumped on board right away, sure it's still too fresh, and there are already some great success stories, but lets clearly say, 90% of the community boards are requests for help, the ones that the team can't fully embrace as one would like, it's not that difficult to understand the why. Now this lack of contributions is a trend in nowadays open source platforms, a lot confuse it with free software with free support, that is not what makes the community evolve. In all my community or sales talks I try to really make a point about the advantages of the open source community, it's such an opportunity to evolve the code and skills (both the user, dev team and work process) in a friendly environment that truly most really don't understand what is the miss when being shy.
In Mobicents JAIN SLEE 2.1, most of those 25% of code in 2.0 that were not new, which were the foundations of the whole platform, and how the modules glued together, will now be completely reworked, targeting an attractive multi module platform, on top of an SPI that overrides the javax.slee interfaces. Sure at first this SPI may not come in the best shape, it's a big effort to extract a big set - hundreds - of interfaces which mean something in a couple of weeks, but we will get there. On those modules, the idea is to make them more and more efficient, both in the SPI and Implementation, have their own configurations (and pluggable) means, for instance different implementations of the event router mapping of thread executors to activity contexts, different datasources to store every kind of instance state, all wrapped and tighten by a great packager named JBoss Microcontainer, making it so easy to replace modules or sub-modules as dropping jars and change XML or JMX properties. In summary, it's the container that you easily personalize to your own needs, whiteout meaning the change to proprietary specification, easily target a single module for your contributions. Yes, I'm that excited with this kind of move.
Okay, I must stop it for now, initial work is now on the svn trunk, documentation on the Core modules and SPI will start popping up in the mobicent public wiki, hopefully by the community users too. Hope you enjoy our work and join efforts to make it better and better, we all win.
Cheers.
