Why OSGi is cool, but not for most enterprise apps…

Discussions

News: Why OSGi is cool, but not for most enterprise apps…

  1. Well, we certainly agree that the dependency resolution features of OSGi are cool, especially given that a lot of projects use many libraries with second-level dependency conflicts. But do you need the complexity of OSGi for that? Moreover, are you ready to switch your entire programming and component structure of existing applications to OSGi? http://blog.caucho.com/?p=213

    Threaded Messages (27)

  2. Where's the explanation of why OSGi is not useful for "enterprise apps"? I don't really see much here than: 1. Eclipse is a mess (who didn't already know that?) 2. Proper encapsulation is hard. It's frustrating how common I statements that we (don't) need X for the enterprise without any explanation. Here's where I see OSGi making sense for the enterprise: 1. 3rd part library dependencies: If I want to deploy a new service to a web container and use a new version of a 3rd party library without deploying each web app with it's own set of jars. Sure this is workable but it's not a very clean approach. And by being explicit, dependencies are documented in a very rigorous way. This is even true for internal classes that are reused. If you have to retest all of your services every time you want to make a new one, the cost of new services becomes intolerable very quickly. 2. Package modularity: This blog seems to miss the point of being about to control package visibility at the jar level. It makes structuring packages easier, not harder. The java model only provides one way to conditionally allow access to between unrelated clases: package protected access. In order to properly hide the classes you don't want to be part of your API, you have to lump all kinds stuff into a single package. With OSGi you can split the packages up and only expose the package you want people to use. This isn't about being a control-freak. Anything that you expose can potentially become a dependency somewhere else. It limits your ability to refactor and modify your code. The argument in this blog seems to be 'our packages are poorly structured and we can't be bothered to fix them.' Reloading jars is a straw-man. Enough, please.
  3. Thanks for the criticism, James. You make some fair points. Maybe I misstated my case in the blog, but I think we actually agree on some points... specifically:
    This blog seems to miss the point of being about to control package visibility at the jar level. It makes structuring packages easier, not harder.
    OSGi gives you control of dependencies at both the bundle level (Require-Bundle) and the Java package level (Import-Package), though the latter is preferred. I like the bundle level -- it usually captures the totality of the dependency relationship. The Import-Package bit is where I think OSGi goes overboard -- you don't need to cherry pick packages out of a jar most of the time and when you do, you often get into trouble. However Import/Export-Package is now the recommended way of wiring (R4 Core 3.13.3). It's fair that this isn't exclusive to enterprise apps though. I think all Java programs would have this problem. OSGi services are the part that I think are particularly badly suited to enterprise apps, but are actually very cool for mobile and desktop apps. For the third party dependency issue, OSGi does in fact provide a way to handle this pretty well, but the amount of metadata necessary was too heavyweight for our tastes. Our Pomegranate project shows that if you have jar-level dependency information (in our case in the form of Maven pom.xml/.pom files), you can get the same benefits. IIRC, Spring DM uses Maven and a bundle template to produce OSGi manifests. We thought that stripping away two layers of metadata and a transform tool to get the same functionality makes a lot of sense. Certainly OSGi has a lot of good concepts in it for the enterprise. All I'm advocating is that we strip away unnecessary functionality, whether it applies to enterprise apps or any other.
  4. I want to make a few observations about the article that I think are relevant. In the interest of full disclosure, I'm Lead Engineer of SpringSource dm Server, so I use OSGi a lot. The article mentions that there is no emerging standard for web apps in OSGi. This is wrong. The RFC66 Web Container specification has been in development for many months and has had an early RI for some time now - see http://bit.ly/axjOy. It has also been the case that web apps on OSGi has been a practical reality ever since dm Server was released in the middle of last year. The key benefit of OSGi for user applications comes in the form of better organization. OSGi provides developers with a robust mechanism to organize their code into sensible units and to enforce that organization at development and run-time. I feel that it is pretty disingenuous to imply that developers must ' switch [their] entire programming and component structure'. OSGi applications don't differ all that much from standard Java EE apps in terms of the day-to-day code that users write. In fact, if you are running dm Server and using Spring Framework to bulid your apps, changes should be minimal. The biggest impact is probably including some kind of manifest generation in your build. A major plus point of OSGi is that it is standard. It's certainly not perfect but it delivers real benefits to users and has a healthy open source community and an expert group that is dedicated to improving it. Rob Harrop SpringSource
  5. Hi Rob, If you have a link to an RFC-66 website, please let me know and I'll update my post. If there's not one yet, I can also just link to your blog post. I probably said this in a confusing way, but my understanding was that there are (or were) several competing specs trying to integrate OSGi and enterprise apps. If RFC-66 has emerged as a true standard, that's a new story. It is a bit recent though, right? (Adrian Colyer called it a "fledgling standard" on your blog last month, so hopefully I'm not too out of date. :-))
    I feel that it is pretty disingenuous to imply that developers must ' switch [their] entire programming and component structure'.
    All credit where it's due -- if you now don't have to change your programming model it's because of you guys at Spring. :-) I've followed your progress and it's been impressive, but my understanding is that your main contribution is to make OSGi actually fit into an enterprise environment. Has it been easy? :-) My blog post is about how we didn't see the gain. If you and the Spring/OSGi community do, then that's great. It just doesn't match our experience. Of course two guys from the app server/framework world won't decide anything -- it'll have to come from the actual web developers.
    A major plus point of OSGi is that it is standard.
    There are several competing OSGi containers, but are there any web containers other than Spring dm that will do RFC-66 on the horizon? Standards don't mean much until there are two implementations. Thanks for the informative points! Cheers, Emil
  6. Hi Rob,

    If you have a link to an RFC-66 website, please let me know and I'll update my post
    The best content so far is in the blogosphere including the post on my blog. OSGi spec documents are currently private to the expert group but the expert group members frequently blog about the standards and the RIs. There is much discussion about most of the RFCs out in the community.
    All credit where it's due -- if you now don't have to change your programming model it's because of you guys at Spring. :-) I've followed your progress and it's been impressive, but my understanding is that your main contribution is to make OSGi actually fit into an enterprise environment. Has it been easy? :-)
    It wasn't easy, but it was definitely worth it. Also, the cost of implementation to the few vendors who build server platforms doesn't really matter to the users. I can't imagine implementing a high-quality server like Resin was easy :)
    There are several competing OSGi containers, but are there any web containers other than Spring dm that will do RFC-66 on the horizon? Standards don't mean much until there are two implementations.
    The independent OSGi web implementations are all converging on RFC66 now. Interestingly, most of them were already close RFC66 in the way they worked. As well as dm Server, the PAX guys have a web container up and running which will be (or is) RFC66-compliant Thanks for your comments, I think this discussion is useful for the community. Regards, Rob
  7. The best content so far is in the blogosphere including the post on my blog.
    Ok, I've updated the blog with a link. Thanks for the info.
    It wasn't easy, but it was definitely worth it. Also, the cost of implementation to the few vendors who build server platforms doesn't really matter to the users. I can't imagine implementing a high-quality server like Resin was easy :)
    Well said and thanks for the nod. :-) You're certainly right about the cost of implementation to vendors. I realized after writing that bit that what I meant is the cost of making OSGi and enterprise web development compatible from an API point of view. If that's not easy, it suggests a possible impedance mismatch. The last couple of Spring dm talks I saw showed how easy it is use a .war and wire up OSGi bundles to it. (I would guess the Spring-specific metadata is now being folded into RFC-66?) Essentially all the "cool" OSGi stuff gets hidden from the developer level, so it seems to my mind to be wasted having it around. I'm guessing that this case also covers a large portion of the use cases.
    The independent OSGi web implementations are all converging on RFC66 now. Interestingly, most of them were already close RFC66 in the way they worked. As well as dm Server, the PAX guys have a web container up and running which will be (or is) RFC66-compliant
    Cool. RFC-66 just went from the status of being a spec to being a standard in my mind then. Cheers, Emil
  8. Who else implements rfc #66?[ Go to top ]

    There are several competing OSGi containers, but are there any web containers other than Spring dm that will do RFC-66 on the horizon? Standards don't mean much until there are two implementations.

    GlassFish V3 has an implementation rfc #66. It will be final when the specs becomes final, but a working version is available in maven and in GlassFish promoted builds. See http://weblogs.java.net/blog/ss141213/archive/2009/06/developing_hybr.html
    Sahoo
  9. I like the bundle level -- it usually captures the totality of the dependency relationship. The Import-Package bit is where I think OSGi goes overboard -- you don't need to cherry pick packages out of a jar most of the time and when you do, you often get into trouble. However Import/Export-Package is now the recommended way of wiring (R4 Core 3.13.3).
    I can see how this might seem a little heavy-handed. And it probably is in a lot of cases. I have to say though that I've seen some pretty tangled up dependencies. Long ago when I was working with really early versions of SAAJ, I ran into a dependency issue where I needed two versions of Xerces in the same deployment. In some cases an old version of the classes was needed, in other cases a newer version was needed. I ended up having to hack the SAAJ code to get it working. I think this feature is probably unnecessary 99% of the time (in my experience) but would really be a killer feature if you need it.
  10. I think this feature is probably unnecessary 99% of the time (in my experience) but would really be a killer feature if you need it.
    Fair enough, but frameworks need to focus on the 99%. Even if you used OSGi to merge two different Xerces versions, it sounds fragile at best.
    Do you feel you can't use just the parts you need?
    OSGi makes you go through the trouble of the 1% cases for the other 99%. (Though in fairness, Spring dm has some good tooling to help through much of this.) That being said, it sounds like you might benefit from OSGi. If you get into that 1% more often than others, it's great that you found real uses for OSGi's more complicated features. Since I wrote this blog post almost two months ago, this thread is the first time I've heard anyone respond with a defense for OSGi. We've been getting a lot of positive feedback from developers who didn't need the complexity when all they wanted is jar-level dependencies. We morphed our classloaders into Pomegranate to address the issue and gotten lots of excited responses. Thanks for the Xerces example, though. XML libraries seem to be a major culprit in a lot of these dependency problems. :-) Emil
  11. I think this feature is probably unnecessary 99% of the time (in my experience) but would really be a killer feature if you need it.

    Fair enough, but frameworks need to focus on the 99%. Even if you used OSGi to merge two different Xerces versions, it sounds fragile at best.
    It's absolutely not what I want to be doing but I often find I am forced to play with the hand I've been dealt.
    OSGi makes you go through the trouble of the 1% cases for the other 99%.
    I guess I'm confused here because I didn't think you were required to use import package. Can't use just use require-bundle if that's all you want? BTW: I found this on why import-package is important: http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html
    Thanks for the Xerces example, though. XML libraries seem to be a major culprit in a lot of these dependency problems.
    Things seem to have improved on that front. Sun actually contacted me later to say they had put my fix into the SAAJ library. The problem (IMO) with the xml libraries in Java is that the idea of have a single global configuration for XML libraries is fundamentally flawed. In theory it shouldn't matter which library you use but in practice, dependencies have been built around non-standard features of these libraries.
  12. OSGi makes you go through the trouble of the 1% cases for the other 99%.
    I guess I'm confused here because I didn't think you were required to use import package. Can't use just use require-bundle if that's all you want?
    You're right -- I overstated the case there. However, OSGi suggests using Import-Package over Require-Bundle, which more often invites trouble than usefulness. And if you're not using Import-Package, there's a strong case to be made for a lighter weight approach that provides Require-Bundle functionality.
    BTW: I found this on why import-package is important: http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html
    Yup, the cases he presents are similar to yours and the logging one is quite valid. The Eclipse one... I think you said it best. :-) Just on a philosophical note... isn't it sad that we have to invent frameworks to work around other people's broken work? C'est la vie.
    The problem (IMO) with the xml libraries in Java is that the idea of have a single global configuration for XML libraries is fundamentally flawed. In theory it shouldn't matter which library you use but in practice, dependencies have been built around non-standard features of these libraries.
    Absolutely. Are we sure that all these dependency management schemes aren't just workarounds for early XML library problems? ;-) Cheers, Emil
  13. Absolutely. Are we sure that all these dependency management schemes aren't just workarounds for early XML library problems? ;-)
    Dependency management and private packages are the big features of OSGi that appeal to me. I guess if you are saying I can get these from a simpler approach, I should consider it, especially since I don't have much investment in OSGi at this point. I do like to stick with (well designed, well supported, and well managed) standards when I can, so that's another consideration.
  14. Import-Package ...[ Go to top ]

    In regards import-package, for me the case in question is where you have a bundle where say 5% is public API (that other code depends on) and the other 95% is internal implementation. You want to explicitly hide the internal packages from other bundles because one day you will want to refactor the internal implementation. Alternatively you could break this into say 2 bundles instead (public API and internal implementation). If you always separate the public API into its own separate bundle then you could be happy without import-package. Do you *always* want to do that? To me it makes more sense to be explicit about what is truely public API (and conversely what is not public and subject to change in the future). It's a matter of better tooling etc to make this quick/easy/painless.
  15. Re: Import-Package ...[ Go to top ]

    In regards import-package, for me the case in question is where you have a bundle where say 5% is public API (that other code depends on) and the other 95% is internal implementation. You want to explicitly hide the internal packages from other bundles because one day you will want to refactor the internal implementation.

    Alternatively you could break this into say 2 bundles instead (public API and internal implementation).

    If you always separate the public API into its own separate bundle then you could be happy without import-package. Do you *always* want to do that?

    To me it makes more sense to be explicit about what is truely public API (and conversely what is not public and subject to change in the future). It's a matter of better tooling etc to make this quick/easy/painless.
    Import-Package doesn't help with that. Export-Package is what makes your packages visible to others. This brings up a question though, what's the difference between making a package private and not exporting it. I couldn't find any answers in a few minutes of Googling which might mean there is no difference. But then I ask why even have Private-Package?
  16. Re: Import-Package ...[ Go to top ]

    James,
    But then I ask why even have Private-Package?
    Private-Package isn't part of the OSGi standard. I think this is a header that BND provides since it exports all packages by default. Hope this helps, Rob
  17. Re: Import-Package ...[ Go to top ]

    James,

    But then I ask why even have Private-Package?


    Private-Package isn't part of the OSGi standard. I think this is a header that BND provides since it exports all packages by default.

    Hope this helps,

    Rob
    Thanks. That explains it.
  18. [...] We've been getting a lot of positive feedback from developers who didn't need the complexity when all they wanted is jar-level dependencies.[...]
    I can't agree that listing dependencies and exported packages in jar manifests is "complex" (regardless of whether you use package- or bundle-level dependencies). The real issue for me is that you still need a tool (e.g. Maven or Ivy) to manage your jars pre-runtime, and these tools don't make use of OSGi metadata out of the box (yet). The OSGi services concept is harder to defend: It's a pain to use (without e.g. Spring DM), and it doesn't fit in with the dependency management (i.e. service lookups ignore bundle or version dependencies). Yet it's still useful... Keep in mind that not all "enterprise applications" are web applications (where OSGi is still "unproven" and requires non-standard extensions etc). It's also not uncommon to have to support some notion of plug-ins. OSGi helped us a lot with that (even if it's a bit low-level and may require stuff on top of it, e.g. see Eclipse's plug-in registry).
  19. Certainly OSGi has a lot of good concepts in it for the enterprise. All I'm advocating is that we strip away unnecessary functionality, whether it applies to enterprise apps or any other.
    Do you feel you can't use just the parts you need?
  20. [quote] It's frustrating how common I statements that we (don't) need X for the enterprise without any explanation. [/quote] I agree. It is always the case that people are incapable of developing proper solutions or design modular applications so they blame the tools and frameworks.
  21. [quote]
    It's frustrating how common I statements that we (don't) need X for the enterprise without any explanation.
    [/quote]

    I agree. It is always the case that people are incapable of developing proper solutions or design modular applications so they blame the tools and frameworks.
    Well, that's not really the issue here. The specific issue here is the problem of: if your only tool is a hammer, then everything looks like a nail. OSGi does work well for certain architectures, for example strongly service-oriented architectures. If your architecture fits the OSGi model, it will work for you. That's not at issue. The issue is the stronger claim that OSGi is appropriate for all or even most enterprise applications. In other words, before considering redesigning your entire application around OSGi-style modules, you need to understand if it will improve your current architecture. It may not be better than what you currently have.
  22. I agree 100% with Scott Ferguson.
  23. Well, architecture aims to create different modules. Maven helps to support that module point of view. But the link is broken at the deployment step, and it makes partial deployment harder and/or more painful. So, I wish OSGi to have a complete chain, or a quite similar module-oriented deployment way, as WAR and EAR old style deployment way could be quite counterproductive for different cases. Dominique http://www.jroller.com/dmdevito
  24. on OSGi[ Go to top ]

    It is an interesting topic. When we started GridGain project (~4 years ago) OSGi was nowhere near the maturity and we've chose more traditional SPI-based architecture for our modulrity - and it worked wonders for us. If I would architect the internal of GridGain today I would take a very careful look at OSGi and probably would go with it as it fits many requirements for a complex distributed runtime such as GridGain. However, when it comes to plain-vanilla business applications I think the questions is wide open. If you are using dm Server than there's no question since this is probably the best implementation of it. If you are using any of the dozens of other frameworks I think the benefits of switching to OSGi may not that clear-cut. My 2 cents, Nikita Ivanov GridGain - Cloud Development Platform
  25. Re: on OSGi[ Go to top ]

    However, when it comes to plain-vanilla business applications I think the questions is wide open. If you are using dm Server than there's no question since this is probably the best implementation of it. If you are using any of the dozens of other frameworks I think the benefits of switching to OSGi may not that clear-cut.
    Completely agree. At Atlassian, we changed our plugin system to use OSGi about a year ago now, and it has done wonders for allowing us to build robust plugins on heterogeneous product architectures, however, it hasn't been without its bumps and bruises. As much as we've gained from OSGi, I wouldn't even consider moving any of our existing webapps to it, and would still think twice about using it at the core of a new one. As with anything, OSGi adds complexity and you better be damn sure the value, relative to your requirements, will outweight the costs.
  26. From the blog post:
    Specifically, do enterprise applications need to add services at runtime without restarting the JVM? Maybe - it would be a nice feature to have, but if you’re running a large enterprise site, you’d probably prefer to get a clean boot of a system with the new service, test it, then start directing traffic to the server. No matter how clean the framework, administrators will always prefer a freshly booted machine.
    This is an odd comment. The question is not "do folks *need* it", the question is "how much easier does it make certain problems". (After all, Java itself isn't *needed* - assembler code works fine, thank you very much.) Would I want to take down the JVM for an upgrade? That depends very much on the nature of the upgrade. I can easily envision services of a kind that are so frequently deployed and updated that it's not feasible to require a restart each time (and not necessary from an admin POV). Other kinds of upgrades, sure. Much depends on the level at which OSGi is used. If the app consists of a few large, infrequently updated components, then OSGi is likely not a good fit; but for small ones, there's a definite advantage.
  27. Re: Taking the wrong prespective, maybe[ Go to top ]

    I can easily envision services of a kind that are so frequently deployed and updated that it's not feasible to require a restart each time (and not necessary from an admin POV). Other kinds of upgrades, sure.
    Envisioning cases is where we get into trouble. If this use is something that you do all the time, then maybe OSGi is for you. (Even with OSGi though, you need to be fairly careful about your Bundle activators and services to make this really work.) This blog was meant to address the bulk of the cases where OSGi services not only don't make sense but in fact encourage bad practice. Emil
  28. "Moreover, are you ready to switch your entire programming and component structure of existing applications to OSGi?" Earlier responses already pointed out some of the early draft OSGi enterprise specifications that describe how existing web component models can exploit OSGi. There is now a new Apache Aries incubator proposal whose aim is to deliver open source componentry for the new OSGi specs to enable enterprise applications to be deployed as OSGi bundles while still using familiar Java EE technologies for persistence, transaction management and so on.