13 responses

  1. Alex Blewitt
    August 28, 2008

    Good summary, thanks.

  2. Richard Nicholson
    August 28, 2008

    Agreed nice summary!

    Agree that 4.2 will be a big step forwards for OSGi.

    That said, I’m skeptical of RFC119 – and the vendor “spin” associated with it. As, as you note, RFC119 ignores the really issues concerning distributed computing (i.e. Deutsch 8 Fallacies). I also found the RFC119 demo somewhat underwhelming.

    If you are interested in distributed OSGi based systems – check out our approach ‘Newton’ (newton.codecauldron.org) – I’d be interested in your thoughts. Newton based systems have been dynamically scaled to a 1000 nodes – so I guess this has somewhat redefined my expectation of what an impressive OSGi demo should be :)



  3. Mirko
    August 28, 2008

    Yeah, looking into the Newton project is on my TODO list for quite some time and I will definitely look into it. The only problem is, when you’re not directly working on a distinct topic it is not always easy to find some spare time looking deeper into it. The project popped up pretty often in interesting discussions, so even if you don’t want, I’ll take a closer look ;-) Do you have any documentation other than the project doc, like a white paper on the mentioned deployment scenario, lessons learned or something similar, you would recommend? You can send me a mail under mirkojahn “at” gmail “dot” com, if you don’t want to distribute it in public.


  4. Chris
    August 29, 2008

    I feel this move forward actually hurts OSGi. OSGi is heading more into the application domain. This means a lot of overlap between app servers and OSGi. The reason in IMHO that OSGi is popular can be summed up as, “the better classloader”. Once OSGi gets bloated with features and does too much it will no longer be an option for use in other platforms. Reason is simple, OSGi would be the platform rather than aiding others. Fine if that is the plan for OSGi, but just be open and say that. Up to this point I had thought even the service API was over the line, but moving to these features really pushes it over.

  5. Tim Diekmann
    August 29, 2008

    Very nice summary.

    I can assure you that the EEG is actively working on the JEE story, but it is not likely that it will be addressed in the next version of the spec. Time for that is running out and the JEE problematic is very complex and comprehensive.

    RFC 119 is about the integration of remote communication systems (like ESBs) into the OSGi service programming model. It purposefully does not address in any way how the transport is implemented. We do agree that trying to hide the remote semantics from the clients is a fallacy we want to avoid. Nothing in the spec requires the remote invocation to magically work for existing clients. However, this is the first step in supporting new SOA applications using the OSGi service programming model. Very exiting :-)

    Tim Diekmann
    co-chair Enterprise Expert Group, OSGi Alliance
    co-spec lead of RFC 119 – Distributed OSGi

  6. Eric Newcomer
    August 29, 2008


    Great summary, thanks very much. This is indeed a major release, despite the minor version number.

    I think you are right, the Spring-DM design may very well be the most significant thing we are doing in this release.

    What’s going to happen to DS is definitely a good question, but it is not really going anywhere even though if the Spring-DM stuff catches on I agree with you that will be the way most people will want to configure OSGi services.

    On the distributed design, as you might imagine we spend a lot of time debating things like the level of transparency to shoot for (we do not believe distributed computing is transparent, and should not be promoted as such) but the main goal we have is very simple: Extend OSGi properties to suport the configuration, discovery, and provisioning of remote services.


    If we really wanted to include a vendor spin in 119 we would have adopted the Paremus product ;-) We specifically avoid endorsing any one approach to distributed computing, since OSGi is all about lots of ways of doing lots of things, and we did not want (for example) to require things that could only be done with RMI and Java. Another important requirement is interoperabilty with non-OSGi environments.

    However we also expect the Paremus design to work with the extensions we are defining – please let us know if you don’t think that’s the case.


  7. John Wells
    September 2, 2008

    Hi Mirko,

    While I see your point about black lists being less secure what I find in practice (I’ve been doing security for quite a while now) is that the bigger threat to security is complexity. Without “black lists” the security policies becomes more complex, meaning that as a practical matter the judicious use of “black lists” can make your system *more* secure rather than less by making your policies simpler.

    Furthermore the use of “black lists” is optional and any framework administrator can always choose to not use them at all if they feel it will lead to weaker security.

    I believe that system vendors (such as OSGi framework vendors or application server vendors) would like to be able to provide default policies that provide a “secure” system to users. At the very least for the services they themselves may provide. This is not possible without the use of “black lists”! For example, today there is no way for an OSGi vendor to say “only the system bundle can advertise the PackageAdmin” service with an out-of-the-box policy file!

    I see the option to use black lists as another tool in the security professional’s arsenal of tools. And while they can certainly be abused or used incorrectly, *not* having them has caused people to abandon the use of J2SE security completely! I know this from personal experience unfortunately.

    I really hope that “black lists” (or deniable permissions as we call them) along with the dynamic nature of the OSGi model will help foster the use of J2SE security in real systems!

    John Wells (Aziz)

  8. Mirko
    September 3, 2008

    @Tim and Eric
    Please don’t get me wrong. I am looking forward to see how this will work in real live applications. And I actually hope that it’ll be a great success. Right now, I am investigating issues with Secure WebServices and this is no fun, so having something within the realm of OSGi would be greatly beneficial. My only concern here is that the unawareness of the remote nature of a service will introduce problems that could have been avoided. Sometimes, doing this explicit reminds people to take more into account. For instance if remote services are not found, unless a specific property is set in the filter of the tracker. In this case, you consciously decide that you want to have remote services as well. Ok, this is just a stupid example from the top of my head, but I hope you understand, where I was aiming at. Without knowing people might get things that behave different as they expect (and test for). Always a nasty root of errors.

    Looking at it from your point of view, I have to agree, that there is a clear advantage of having “deniable permissions”. There is a reason for white lists and applied with causion I have nothing against them at all. The point, I was trying to make was somehow different. When I look at fragments for instance(I just like this example, sorry) they can be extremely useful as well and I am using them quite often. Unfortunately, people find out about the potentials and use them in a “not intended” manor (like creating a global class space like extension mechanism) – just because it is possible.

    What I am trying to say is (and I kinda think we agree on this one I guess), is that managing security in OSGi is a not trivial task. However, I am more seeking for methods to help the user/developer/admin to do his job easier. In our team, we actually came up with an approach that can solve some of the typical problems without introducing black lists and still allowing to dynamically add unknown components safely and more or less self managed. For the Common Criteria evaluation, we’ll be facing next year, such black lists are pretty much a no go for us, because they are harder to evaluate and increase the attack surface unnecessarily.

    As a last note I want to add, that till now, working with OSGi and security is pretty painful (like with plain Java). In my opinion, it doesn’t have to be this way. The only thing we need to start with is providing tooling support, like a framework deploying a basic set of bundles with the minimum on permissions and a UI (web, java, command line, what ever), that allows to safely install new bundles in a secure context by dynamically applying permissions. Such simple tool would help people to just “play” with security and familiarize themselves with it. Right now getting started is really painful and in many cases a show stopper.

  9. Eric Newcomer
    September 15, 2008


    yes, we discuss this issue a lot. And as you might expect we get opinions on both sides.

    Some folks say “I just want to find a service, I don’t care whether it’s remote or not.”

    Others say “I really don’t want to end up using a remote service by accident”

    What we’re doing has the potential to go either way, but the current model tips more toward the conscious use of remote services (you have to give them special properties and configuration metadata and can easily filter them out if you want to).

    Although the possibility exists that someone might end up using a remote service accidentally, I think it’s more of an edge case than the typical situation.

    Thanks again for your comments!


  10. Martin Zdila
    September 22, 2010

    I don’t agree that Spring-DM is way superiour to DS. They both use different approach.

    We switched our project from Spring-DM to DS. Problem with Spring-DM is that it relies on proxies and there was no tool to find out a missing dependency. We often had to wait until the dependency timeouts (default 5 minutes?). Now with DS it is very simple to find the dependency issue (scr info ). Also DS forces us do define one component.xml for one service. This is correct. DS is also more lightweight and low level (no proxies…) = better control and easier to debug.

Leave a Reply




Back to top
mobile desktop