Tuesday, July 16, 2013

Real Men Don't Use DS

In general watching Stackoverflow is a pleasant way to spent some spare time. Helping other people out feels good and it is nice to see how the number of OSGi questions, and thus adoption, is increasing. However, it can also hurt looking at how people are struggling because of their own choices. There is this idea in our industry that real men start with the command line and Bundle Activators. Bare metal! Somehow this is considered to be a better way for real men to learn a technology than using a sissy IDE. Just like real men do not learn how to drive a car until they can clean and tune the carburator! The fact that  carburators have been absent in cars since the late seventies seems irrelevant to them.
I've written forewords for numerous books about OSGi and virtually all made the same mistake that to understand the technology you should first proof your worth by struggling with a Bundle Activator and a Service Tracker. Just like cars today have electronic injection so does OSGi have dependency injection. Use it. My strong recommendation is that if you want to learn OSGi, use bndtools with a Declarative Service (DS) example project. Make sure you understand the life cycle of declarative services and their immensely powerful integration with Configuration Admin. Realize that any class can be made a service with a simple annotation and any service can be made a dependency with a another annotation. If you need something to initialize, add an activate or start method to your service. Check your imports in the content pane and adjust imports them with drag and drop to make them cohesive and simple to use modules. Visualize what and how is running with Apache Felix Webconsole and Xray. Enjoy the sub-second edit-debug cycle. That is what you should learn and fall in love with because that is what makes OSGi so powerful.
Only after your mastered this initial level start looking under the hood and find that all the goodies that real men need are really there: Continuous integration, command line stuff, low level service access, weaving, proxying, bundle activators, bundle trackers, service trackers, whatever. It is wonderful to know it is all there when you need it but it is not what OSGi is all about.


3 comments:

  1. While I agree with the post I have to do some venting. Don't get me wrong, I like OSGi and DS but sometimes it can be quite a frustrating experience. Especially the DS tooling.

    The DS tooling is quite really bad especially considering it's part of PDE which has some if the best tooling there is. The DS tooling doesn't even offer you autocompletion when selecting a method. When you refactor a method it doesn't update the XML file. Which would be bearable if it at least did some validation. And it offers no help at all for the more obscure configuration options.
    Then there are the bugs in the implementation like Equinox registering the component only when deployed unpacked but not when deployed packaged.
    Then there are the issues of getting a library working in OSGi. When you're trying to access an OSGi service from a static method (because the library works that way) and submit a pull request "you should use DS" is not the answer you want to hear because in this case DS doesn't help at all.
    Then there are the treading issues. Firstly most examples don't seem to bother establishing a happens-before relationship between reads and writes of services. Second due to the dynamic nature of OSGi services tend to be mutable (a new version of a service get's injected) which can lead to some synchronization issues. IMHO it would be cooler if DS components could be immutable and simply new versions created and registered.
    And finally it would be cool if I could use JSR-330 instead of yet some other annotations. And a pony.

    ReplyDelete
  2. The DS annotations are voiding your tooling concerns I think. At least in bnd(tools) I do not even remotely recognize your issues with tooling. So switching to bnd(tools) might save you from this aggravation. (And I hope you reported them to Eclipse).
    In the examples I use I generally take care of the synchronization issues; the thing is that using defaults it is hard to do it wrong. Only when you want to take advantage of dynamics does concurrency become a concern. The good news of the annotations is that they promote using the defaults.
    Statics in evil. We all learned in school that we should not use globals but somehow in Java statics (which are globals) are pervasive. OSGi can run inside OSGi, below an App server, and inside a WAR; all this flexibility because there are no statics in OSGi. So I wish I could do something about your pain but it is caused by using a bad design pattern.
    Though having a common set of annotations would be nice, I think it would do a great disservice in the case of DS to use JSR-330. The ┬Áservice primitive that OSGi provides is so much more powerful than object injection, trying to push it to the lowest common denominator seems to forfeit the purpose.

    ReplyDelete
  3. So why isn't a 5 minute DS tutorial for bndtools "front and centre" on the getting started pages at OSGi? (http://www.osgi.org/Technology/HowOSGi)

    Googling for "OSGi tutorial" yields lots of Activator, ServiceTracker heavy examples.

    There is a reasonable one @ http://bndtools.org/tutorial.html - but I suspect even that could be made more n00b friendly?

    I really like what Eclipse XTend have done with their video tutorial on the home page - for me this is real tech marketing. I find myself watching the video and before it's 1 minute in thinking "interesting, I could use that"...

    ReplyDelete

Blog Archive