jump to navigation

OSGi – The placebo that will rejuvenate this industry (just ask your vendor) May 19, 2008

Posted by Sacha in JBoss.
trackback

In the last few weeks, the amount of noise around OSGi was embarrassing. It seems the IT world discovered it was indeed possible to have non-monolithic architectures. These days, it is enough to say that your runtime is “OSGi-compatible” or “based on OSGi” to look like David Lynch’s new egeria.

Don’t get me wrong, I do like OSGi, it is a pretty decent spec. No, what’s interesting is how most middleware vendors only seem to care about micro-kernel-based architecture since 2007-2008 – while OSGi has been around for ages. When a vendor tells you “we are now OSGi-based”, it is actually very similar to the good old “our new software release is 200% faster than the previous one!”: 101 of anti-marketing. What users actually hear is “our previous architecture was horribly bad” and “it was also slow as a dog”.

JBoss AS has been based on a micro-kernel architecture since its 2.x series – around 2000 – (thanks to the work done by Rickard around JMX, RMI dynamic proxies, etc.) and then further extended in the 3.x series with the hot-deployable services concept (SAR files, thanks to Scott and Marc).

In the last two years, Adrian Brock and his team have been working on the next.gen JBoss Microcontainer based on our past experience with JBoss AS 3.x micro-kernel. I’ll soon write a more complete blog entry on JBoss MC features of. Without digging too much in JBoss MC’s architecture, I can tell you it was clearly not conceivable to base our microcontainer on OSGi directly: OSGi doesn’t define many of the concepts we required (services lifecycle and extended dependency management, deployment customization, metadata management, etc.). We wanted to make sure OEMs&ISVs could deeply customize JBoss Middleware through JBoss Microcontainer: from embedding it in another runtime, to hook or replace the meatadata, classloading, bytecode, lifecycle, etc. subsystems.

Then, does it mean OSGi is a bad spec? No, not at all. First, it is an open specification, which is a good start. Then it provides a standard way to extend a given runtime while controlling what gets imported/exported. That’s quite an achievement considering the erratic situation we have gone through in the last 10 years with such an underspecified classloading mechanism in EE. OSGi is a good way to define how to cleanly plug third-party/user-provided extensions to a runtime, but it is certainly not complete enough to provide what’s needed by a fully customizable application server. It is about writing an AS vs. using an AS.

Furthermore, specifications come and go, requirements stay. That’s why JBoss Microcontainer features what we call “Personalities”. A Personality is a specific view of our POJO-based Microcontainer (its services, its dependencies, its metadata, etc.). JBoss Microcontainer currently features two personalities: OSGi (almost finished) and JMX (done). It also provides a Spring-deployer that reads OSGi Spring’s DI descriptors and map them to JBoss Microcontainer constructs. Trivial to implement. That’s where we are going: runtimes à la carte. Everybody in middleware has its own religion these days, fair enough. We are providing the common infrastructure that will bridge those needs. Whatever is the programming model or DI you favor, your applications will always rely on the same set of enterprise aspects: security, transaction, messaging, etc. We care about offering the most stable and performing enterprise services/aspects. We will then provide you with bridges to whatever programming model/API you like, that’s the easy part.

So, next time somebody tells your their runtime is OSGi-based or that “their framework is available as an OSGi-bundle”, ask yourself “what does it really do for me?”. If the answer isn’t obvious, you’ve probably just stepped into BS.

Onward,

Sacha

About these ads

Comments»

1. Meredith Ples - May 21, 2008

My company is starting to migrate to Sun’s new Glassfish AS off of JBoss, and I was wondering if you were working with Sun to increase the level of interoperability between your products. From a customer perspective, that would make me think more highly of JBoss – do you have any pointers for transitioning?

2. Sacha - May 21, 2008

Meredith,

I think you should speak to SUN. Our role is to help you migrate from any app. server to JBoss, not the opposite. Much like I guess, the role of your company is to develop its own services/products, not the one of your competitors.

Cheers,

Sacha

3. EE supported\ - May 23, 2008

My understanding is, Yes Sacha, and jBoss is working toward increasing
the level of interoperability between products. At least by means of
working with the JCP in the evolution of Java EE specification. jBoss
has and is very involved with keeping standards. So, in this sense I do
see Jboss helping Improve interoperability. If Java EE continues to grow
and become a higher standard, customer like yourself should be able to
develop all your apps and distribute to any Java EE vendor.
Making your company even more profitable.

4. Sacha - May 23, 2008

EE supported,

Yes, it is true that the EE specification in itself provides a great deal of portability. However, it is also true that some specific behaviour of app servers will most probably never be standardized or are left to the interpretation of each implementation. Those items are the ones slowing down migration and for which vendors usually provide help/tools/guides to speed up migration to their AS.

Cheers,

Sacha

5. Alin Dreghiciu - June 6, 2008

Hi,

For the start I’m pretty much fan of OSGi.
What I’m missing in your blog is some pointers details about why the “services lifecycle and extended dependency management, deployment customization, metadata management,etc…” cannot be implemented on top of OSGi. What are the requirements that you would have, where OSGi stands against you, because at its basics feature (the core specs) you “only” get the module layer and the service registry.

Thanx,
Alin Dreghiciu

6. Sacha - June 6, 2008

Hello Alin,

For some services, yes, you are right: they could be easily added on top of OSGi i.e. standardized as specs sitting on top. However, given that these specs do not exist yet, how is that different from what we did i.e. we implemented our own solution :) Would we be willing to standardize this? Sure, if the community thinks (post-GA) that this is worth being standardized, we will gladly do so much like we did with Hibernate/JPA and Seam/WebBeans.

However, there are some features that probably couldn’t easily be standardized as part of OSGi. OSGi provides a pretty coarse-grain model and does it well. But finer-grain model are less ideal to implement on top of OSGi.

With our solution, that shouldn’t be a big deal though: if you like what we did, let’s standardize, if you don’t, let’s keep it as is :)

Cheers,

Sacha

7. OSGi « …in search of INTEROPerabilitY…–>|<– - May 15, 2009

[...] Blogs: OSGi – The placebo that will rejuvenate this industry (just ask your vendor) [...]

8. Why is OSGi on everyone’s tongue – or why you should take the red pill | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service - September 15, 2009

[...] a JBoss blog on “OSGi – The placebo that will rejuvenate this industry (just ask your vendor)” Sacha paints a picture of everyone just following the latest buzz-word and (at least in title) not [...]

9. Why is OSGi on everyone’s tongue – or why you should take the red pill | Service Oriented Architecture - SOA - May 7, 2011

[...] a JBoss blog on “OSGi – The placebo that will rejuvenate this industry (just ask your vendor)” Sacha paints a picture of everyone just following the latest buzz-word and (at least in title) not [...]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 29 other followers

%d bloggers like this: