OSGi RFC 124

Who else read RFC 124? It has a really funny title: “A Component Model for OSGi”. Yeah, that really speaks for itself. Just repeat it a few times and let it settle for a while. So, RFC 124 wants to create a component model for a component model. Funny, eh?

But is that really what people need? Maybe I just don’t get it but I thought the real problem was that programming OSGi is too verbose.

Well, I’m certainly not arguing against that. Programming OSGi is verbose. When creating services you need to write additional code to maintain their registrations. When consuming services you need to write additional code to track available services. Last but not least you need some plumbing around.

Dependency injection seems like a valid solution to make programming less verbose. Imagine you get references to your services injected magically when your object is created. You suddenly don’t have to deal with all this additional OSGi specific code anymore. Of course it’s so great that you also want it for all the other objects in your code. You want to inject arbitrary objects into your objects which aren’t necessarily exposed as OSGi services. That sounds great, doesn’t it?

What a bummer!

Suddenly you find yourself in all that XML which is even more verbose than OSGi was before. Your code is harder to analyze because a simple “ctrl+shift+g” won’t do the job anymore. You traded development efficiency for pseudo flexibility. But I’m loosing the point.

I just wanted to raise a few questions that came into my mind when reading RFC 124.

  • Why must the bundle symbolic name be fixed? Why can’t it be com.springsource.osgi.service.context.extender or com.google.guice.osgi.service.context.extender?
  • Why do I need eight and a half pages of XML schema definitions?
  • Why is it coupled to XML at all?
  • Oh and why does the introduction start with “The OSGi Alliance needs an amended process for the creation and approval of press releases. This document will describe the process.”? 😉

I’m sorry but to me this isn’t a real RFC. It’s something that is written for a very specific implementation. It misses implementation flexibility. Frankly, I doubt that we will see any other implementation than Spring DM, which makes me kind of sad because it hurds diversity.

11 thoughts on “OSGi RFC 124

  1. I’m glad there are others who don’t see the point in moving parts of the Java code to XML configuration files for no good reason.

    I’ve seen people being really dangerously crazy about “springifying” everything they could get their hands on, until nothing worked anymore, and nothing had been won apart from a theoretical flexibility.

  2. Why is necessary to include the Spring-DM spec under the OSGi alliance hat? There might be some problems, but Spring-DM can post their requirements which can be resolved without bringing the whole spec. What is the difference except political nuances regarding who is holding the technology driving many enterprises?

  3. Hmmm. So where’s the critique. I mean, aside from just cheap potshots – really, complaining about inclusion of boilerplate text in the template is just plain petty – where’s your issue? Complaining about pages of XSD is like complaining about the rain in Seattle. I mean, seriously, dude it’s like you’ve never done anything with schema before if you don’t understand the stuff requires reams of ungodly information. And this is a fault of RFC 124 because of? I suspect you have some alternative to XML schema that you’d like to share with us. Considering annotations aren’t exactly compatible with J2ME and the CDLC, what – pray tell – are you suggesting that RFC 124 use? Magic jelly beans?

    So, again, besides some smart allecky nitpicking, where’s the critique?

  4. Oh right, the enterprise expert group is targeting J2ME these days. How could I miss that! I guess the reference implementation will run happily in any CLDC with all that heavy reflection and XML read into memory.

    Anyway, I thought the critique would be clear. Simply put, why the hell does OSGi need RFC 124? It tries to solve something that’s not even recognized as a problem across the board. I’m sorry but to me it just looks like somebody is trying to cast his implementation into an RFC for his very own reasons.

    Why isn’t it possible to enhance declarative services (with some ideas from RFC 124)? Why does OSGi need another component model? Did the bundle and [declarative] service model fail?

  5. Gunnar, There seem to be two fundamental questions you are posing here:
    1) Why do we need RFC 124 at all?, and
    2) Why use XML if we do need it?

    Let me address these two questions in turn:

    1) Why do we need RFC 124 at all?
    You ask: “did the bundle and DS model fail?” The bundle model certainly did not fail, and is certainly not replaced by RFC 124. Bundles are the main unit of modularity in OSGi. RFC 124 addresses two problem areas with respect to bundles that do more than just contribute types into a type space. Firstly, it addresses the problem of how the object graph used to provide the bundle’s implementation gets constructed and managed when the bundle in activated. Secondly, it addresses the problem of how references between bundles (via the service registry) are managed – with a particular emphasis on the dynamic nature of OSGi and what happens when services come and go at runtime.

    You could make an argument that *for a certain set of use cases* the DS model did fail. A number of companies (including those represented on the expert groups) found that some of the design points of DS did not meet their requirements (for example, with respect to the behaviour when a mandatory dependency becomes unavailable). For enterprise (as in Enterprise Java) use cases, something different was required. Stretching DS to become that thing would have been harmful to the use cases where the current DS behaviour *is* the desired behaviour. (Remember that OSGi spans a very wide set of use cases from very lightweight embedded systems, through automotive, telecommunications etc. and only relatively recently into Enterprise Java style applications).

    The Spring Dynamic Modules project provides a (Spring) based model that addresses the requirements for (many of the) Enterprise Java OSGi-based use cases. With that project growing in popularity there were two choices: allow Enterprise Java OSGi use cases to be addressed outside of the specification (by Spring), or bring Spring Dynamic Modules to the table at the OSGi Alliance, improve it with insights from other OSGi experts, and create an open standard as a basis for moving forward. We choose the latter route.

    2) Why use XML if we do need an RFC?

    One of the early requirements placed on the RFC was that it be implementable on the OSGi Mimimum Execution Environment (MEE). The OSGi specifications currently preclude Java 5 which rules out annotation based approaches (such as those supported by Spring), and also approaches such as Spring’s JavaConfig (which also depends on annotations). XML therefore is the established model we fall back on. Note that many Spring users, even with alternatives available, still *prefer* to use the XML based approach out of choice.

    Regards, Adrian.

  6. Andrian, thanks for your detailed answers. Also, let me make a statement that I neither want to intrigue nor questioning your work or Spring DM or anybody else working on it. I respect what you guys put together. As a matter of fact, I used the Springframework happily in the past for different projects (non OSGi, though).

    You mentioned an interesting point “[…], with respect to the behaviour when a mandatory dependency becomes unavailable […] “. The idea of automatic unregistering and re-registering of services is not a bad one. I don’t see how such an enhancement could be harmful for DS. A spec can evolve in a way which preserves the current behavior for backwards compatibility.

    However, it doesn’t matter whether you unregister and re-register services or bind proxies which will throw unchecked exceptions. It’s the application code which need to gracefully handle the issues. For example, what happens when a SMTP service for sending order notifications is not available? Should the order service be unregistered which in turn unregisters the storefront service which in turn leaves users with a 404 or 503? Should the order service throw unchecked exceptions which in turns leaves the users with a 500? The SMTP service should better be optional and notifications queued in the order service until it becomes available again. The point is, no spec will solve such a problem.

    Maybe it’s just me but I would really like to better understand why it isn’t possible to enhance DS and keep DI separated with a good story for interoperability between both to address questions like the ones asked here.

    Re: XML

    In the end, the XML just gets parsed into a model. It should be possible to define this model in other ways. You don’t have to use annotations.

  7. Adrian,

    If it’s harmful to “stretch” DS to include all the enterprise use-cases, then isn’t it equally harmful to “stretch” Spring down to all the non-enterprise use cases? In other words, it seems bizarre in 2008 to avoid Java 5 contructs in a specification which is specifically aimed at enterprise usage. Developers who are targeting Java 1.4 CDC/Foundation Profile/whatever (note to Gunnar: OSGi doesn’t work on CLDC, never has) are incredibly unlikely to consider using RFC-124, or even DS for that matter.

    It’s not that I’m a big fan of annotations, nor do I dislike Spring XML that much. It just seems odd that the Enterprise Expert Group should be operating under constraints designed for the embedded market. If indeed that’s the case… as mere Supporter Member of the OSGi Alliance I have no idea what goes on in those meetings!

    BTW Gunnar… your CAPTCHA is too hard to read!!

  8. Oh right, the enterprise expert group is targeting J2ME these days. How could I miss that! I guess the reference implementation will run happily in any CLDC with all that heavy reflection and XML read into memory.

    Dude, since I haven’t seen you operating in the EEG committee, I’m assuming that your rhetoric is purely for comedy value. Having actually been there working on this, I can tell you that the J2ME and CDLC considerations are loudly and consistently voiced at all times. Just ask someone in EEG about including Generics or Annotations in your spec and see how far you get with that argument. You’ll be lucky to escape with a square inch of skin still left on you.

    Anyway, I thought the critique would be clear. Simply put, why the hell does OSGi need RFC 124? It tries to solve something that’s not even recognized as a problem across the board. I’m sorry but to me it just looks like somebody is trying to cast his implementation into an RFC for his very own reasons.

    Well, to be frank, it wasn’t.

    WRT “for his own reasons”, pray tell what spec is done for the good of man kind. every specificatino is done for commercial reasons. Every single piece of code is made with a purpose. If it doesn’t have any reason for living, it wouldn’t exist. Maybe in the world outside of EEG everyone has altruistic reasons for developing code. But the rest of us are actually in business, trying to make money off of it. Sorry, but that’s the reality of how things are done.

    But really, if you don’t see the reason for it, why not simply ignore it? Is there actually some reason that – if this RFC were to become part of the spec – that it would offend you or cause you great suffering and pain such that you would think it had to be removed?

    It’s almost like we decided to desecrate the Mother Mary or something.

    Why isn’t it possible to enhance declarative services (with some ideas from RFC 124)? Why does OSGi need another component model? Did the bundle and [declarative] service model fail?

    Well, first off it’s quite a different model than DS. And the DS people don’t like it. Second of all, there’s the whole issue with framing 124 as “THE” component model for OSGi, which seems to loom large in many people’s heads. If you make this a “tweak” of DS, then this becomes “THE” component model for OSGi and it seems to me that if you’re worried about that happening in the first place, then why on earth would you want it to be done in such a way as to guarantee it to be your worst nightmare is beyond my comprehension. But whatever.

    Further, if you don’t see any need for it, or for the model or for anything about it any way, then why on earth you wouldn’t want DS to simply be left alone rather than polluted by such obvious bad design and useless clap trap is again beyond my comprehension. But hey, consistency in logic or substance in argument does not seem to be in vogue for this topic.

    WRT to the “failure of the bundle/service model”, I can’t for the life of me see what your point is. Does 124 replace or obviate OSGi services? No. Does 124 replace or obviate bundles? No. So what’s your point? That you don’t like the idea of a private scope? That you don’t like the XML? What?

  9. Dude, since I haven’t seen you operating in the EEG committee, I’m assuming that your rhetoric is purely for comedy value.

    Just because I’m not working for somebody that is paying money to be part of some discussion club I’m a comedian? What an overbearingly arrogant assumption.

    But really, if you don’t see the reason for it, why not simply ignore it?

    Ignoring things is way more harmful.

    Is there actually some reason that – if this RFC were to become part of the spec – that it would offend you or cause you great suffering and pain such that you would think it had to be removed?

    It will be part of the spec. People will adopt it and then you have to support it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.