Distributed OSGi RI Now Available at Apache CXF

Home

News: Distributed OSGi RI Now Available at Apache CXF

  1. Distributed OSGi RI Now Available at Apache CXF (87 messages)

    Those of us who have been working on the upcoming enterprise revision of the Specifications (now officially called OSGi 4.2 - pdf here - pretty good summary here) are happy to see that a preliminary version of one of its key new capabilities is available in open source. The ability of an OSGi service running in one JVM to invoke an OSGi service running in another JVM is among the key requirements collected at the OSGi Enterprise Workshop back in September, 2006. The EEG put a lot of time and thought into the design for Distributed OSGi, also known as RFC 119. Preliminary drafts of this design are included in the early release drafts mentioned previously. The code for the reference implementation of RFC 119 is now available in the Apache CXF project area. (As part of the OSGi process, all parts of the specification must have an approved design doc, reference implementation, and conformance test suite.) The requirements on which the Distributed OSGi design is based include not only the ability for an OSGi service to invoke another OSGi service remotely, but also for non-OSGi environments to interact remotely with OSGi services. The current RI demonstrates both capabilities, as shown in the introductory and extended tutorials recently posted by David Bosschaert (one of the RFC 119 authors and RI coders). A on Distributed OSGi has been scheduled for EclipseCon / Dev Con March 26 featuring David along with Scott Lewis, Scott Rosenbaum, Markus Kuppe, Tim Diekmann,and Thomas Kiesslich. From the beginning of this effort there has been some controversy over the intent and purpose of the distributed OSGi capability. I can't tell you how many times I've had to say that we are not (repeat not) inventing any new distributed computing infrastructure. We have simply designed a standard way in existing distributed computing infrastructure can be configured into an OSGi framework. The RI illustrates this using Web services, but we believe the design supports the use of other approaches, such as Eclipse ECF, Java RMI, CORBA, and so on. RFC 119 also includes a design for a discovery service, which also is intended to map to existing discovery services, and for the use of SCA metadata in configuring distributed software infrastructure. We are expecting reference implementations of both of these capabilities in the near future. As a final note, another important design goal of Distributed OSGi is to work with Spring-Dynamic Modules and the OSGi Blueprint service design which is based upon it, to ensure a good development model is available. As always, please let us know what you think (as if this crowd is shy ;-).

    Threaded Messages (87)

  2. Sounds like pretty exciting stuff! :) I will no doubt have a look at it in time, but until then can I ask about the Web Services part. I've been wanting to expose certain services that have been registered as SOAP based Web Services for some time. Amongst other things, does this allow me to do that now? And it reads as though I can 'drop in' other remoting implementations as well, perhaps? Thanks in advance, Chris
  3. Actually, never mind - I decided to read some of the links. Awesome stuff! I have created a collection of bundles that allow AMF3 remoting using a similar way of thinking. I suspect I can make it specification compliant without much effort. :) http://www.arum.co.uk/amf3osgi.php
  4. Great, thanks![ Go to top ]

    Christopher, Sorry for the late reply, you were one of the earliest commenters and I got distracted answering some of the later posts. This is great news, and thanks very much for trying it out and letting us know that the design should not take you much effort to implement. I'm sure I speak for the whole group when I say that's good news. Any other feedback, just let us know. You can always reach me through my OSGi topic blog: http://modualrit.blogspot.com/ Eric OSGi EEG Co-Chair
  5. very nice blog[ Go to top ]

    So far in the RI we are showing from OSGi to Web services, but over time additional capabilities will be added to it (as usual I suppose). One other capability we need to fill out for example is support for the upcoming Blueprint Service, which is based on Spring dynamic modules. muhabbet , mIRC , Chat
  6. Can the services be exposed using Contract First approaches? For OSGi OSGi I could see that not being needed, but if you want to have .Net OSGi then being able to have a contract (using WSDL and schema) helps. I have run into a number of occasions where I have needed to tweak a schema that was WS-I compliant so that .Net would work correctly with it ad if it is generated always that doesn't seem like an option. All that a side, I think this is a great new capability for OSGi. - James
  7. "All that a side, I think this is a great new capability for OSGi." In itself, maybe. But this is a move towards "enterprise capabilities". What's next? Transactions? Let's hope they're not building another failure that is EJB... I'm enjoying osgi as a plugin framework as it is.
  8. "All that a side, I think this is a great new capability for OSGi."

    In itself, maybe. But this is a move towards "enterprise capabilities". What's next? Transactions?
    See: "RFC 98 - Transactions in OSGi (P. 154)" http://osgi.mjahn.net/2008/08/28/some-thought-on-the-osgi-r42-early-draft/ (linked from the article)
    I'm enjoying osgi as a plugin framework as it is.
    While part of me shares your concern that OSGi could jump the shark, I also think it's unfair to assume a new effort will fail just because previous efforts have failed. Before almost all human accomplishments there is a trail of failed attempts. Unless you or anyone else is arguing that any standard supporting transactions is doomed for reasons other than historical failures, I think we need to judge OSGi on it's merits in isolation.
  9. overreaching..[ Go to top ]

    "All that a side, I think this is a great new capability for OSGi."

    In itself, maybe. But this is a move towards "enterprise capabilities". What's next? Transactions?


    See: "RFC 98 - Transactions in OSGi (P. 154)"

    http://osgi.mjahn.net/2008/08/28/some-thought-on-the-osgi-r42-early-draft/ (linked from the article)

    I'm enjoying osgi as a plugin framework as it is.


    While part of me shares your concern that OSGi could jump the shark, I also think it's unfair to assume a new effort will fail just because previous efforts have failed. Before almost all human accomplishments there is a trail of failed attempts.

    Unless you or anyone else is arguing that any standard supporting transactions is doomed for reasons other than historical failures, I think we need to judge OSGi on it's merits in isolation.
    I hope OSGi is keeping its focus on being a kernel/kernel-like API/Container rather than something that is consumable by application developers. IMO, application developers should *NEVER* see this stuff and it should really only be the domain of framework, app server, and container developers. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  10. Not really[ Go to top ]

    The key question here is: If OSGi is so beneficial to vendors' large Java projects, why don't the same benefits apply to customers' large Java projects? This is really a shortsighted view. Sure, we have lots of existing APIs that developers can use, and lots of products built around them that are more or less successful, but the OSGi programming model has inherent benefits compared to the old static APIs. Especially the benefits of efficient development through improved modularity, and 100% uptime of applications through dynamic loading/unloading. Your suggestion amounts to keeping those benefits for vendors, and not allowing customers to have them. That doesn't make sense. Eric
  11. Re: Not really[ Go to top ]

    The key question here is: If OSGi is so beneficial to vendors' large Java projects, why don't the same benefits apply to customers' large Java projects?

    This is really a shortsighted view.
    Not really. JBoss has already gone through this evolution. It has been our goal since 2002 (when we introduced our JMX kernel) to provide hot-deployment, class loader isolation and flexibility, and dependency management. We *also* invented a consumable API on top of JMX with remoting, etc. services.
    The OSGi programming model has inherent benefits compared to the old static APIs.

    Especially the benefits of efficient development through improved modularity, and 100% uptime of applications through dynamic loading/unloading.
    You're not understanding me. You can have improved modularity and 100% uptime with *EXISTING* component models. The app-server/kernel/container can usually figure out the dependency graph itself and manage hot/re-deployment seamlessly and transparently with little to no metadata supplied by the application. We have achieved this to a large degree in JBoss 5. The problem from a container, framework, component model developer is that you either code for portability, aka to the lowest common denominator, or you let proprietary kernel APIs bleed into your implementation. What had exited me about OSGi is that a standardized spine would exist so that we could get both portability and modularity and pluggability of our containers, frameworks, and *existing* component models.


    Your suggestion amounts to keeping those benefits for vendors, and not allowing customers to have them. That doesn't make sense.

    Eric
    No, I just don't want yet another bloated, reactionary, component model infecting application development when we can achieve modularity and 100% uptime with simpler, existing component models. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  12. Re: Not really[ Go to top ]

    Wow, "bloated and reactionary" huh? I couldn't make this up and better. Way over the top here Bill. You remember when we were working together at IONA on the ART microkernel? One of the classic blunders of IONA was to consider Java a "toy language." I'm sure you remember hearing that, and it did cost the company dearly. In some ways IONA never recovered from being late to the Java EE party. But the point is that there is always skepticism of new things from folks deeply involved in the old stuff. To be fair about this, and a bit more objective, I certainly understand that there are two points of view about the OSGi programming model out there, one of which says that OSGi frameworks are good for deployment only, but another that says the OSGi programming model provides additional benefits beyond deployment. Although many people think the major benefit of OSGi is improved deployment, it's actually the service model that provides the greatest benefit. But when you look at the two sides arguing about this, it tends to be the established app server vendors focusing on deployment only (i.e. don't let those users see it) and the smaller, disruptive vendors on the other, who are willing to stick their necks out and promote something new and better. This is normal industry stuff, of course, but it doesn't help anyone to mischaracterize things. You cannot get all the benefits of OSGi through Java EE APIs and static metadata. The question becomes whether it's worth the additional investment in the OSGi programming model to achieve its additional benefits. I'm going to take a wild guess here and say that you would be among those who say it isn't. But many of us disagree, and what we need here is a good discussion, not a bunch of distortion and exaggerated claims. "Bloated, reactionary...infecting development..." and we can achieve all this with existing component models... This kind of thing just isn't helpful. It is neither bloated nor reactionary on the one hand, and you just cannot achieve everything OSGi gives you with any other existing component model.
  13. Re: Not really[ Go to top ]

    This kind of thing just isn't helpful. It is neither bloated nor reactionary on the one hand, and you just cannot achieve everything OSGi gives you with any other existing component model.
    Ok then, which specific features are you talking about now? Originally you said 100% uptime and modularity were the key features. And I stated you can have both uptime and modularity with existing component models (I added dependency management and classloader isolation). So what features are you talking about now? Just to clarify, I'm not against OSGi as a kernel (I'm quite excited about it as a portability layer), I'm against it bleeding into the application space. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  14. Re: Not really[ Go to top ]

    "100% uptime" At what level are we talking about. Application. Service. Component. Bundle. Process. Does anyone (i.e. user) really care whether a particular instance of such is down (or up) as long as the (macro) service level objectives are obtained and agreements fulfilled. OSGi and other similar runtimes/frameworks are more likely to see downtime caused not by planned changes to a jar (bundle, deployment module) but by service failures in the applications, middleware, and runtimes. I hear daily of companies restarting processes each morning or night because of this. What does OSGi offer these poor sods other than obscure ClassNotFoundExceptions stacktraces? Nothing discounting the partial start-up of a process in under 3 seconds that is ready-state to do nothing. No coffee no Workee.
  15. Re: Not really[ Go to top ]

    What does OSGi offer these poor sods other than obscure ClassNotFoundExceptions stacktraces?
    How does OSGi contribute to this? Just to be clear, I've never seen a Java environment that eliminated the possibility of a ClassNotFoundException. It seems to me that OSGi relieves a lot of issues for 'poor sods'. If I specify my dependencies, the container tells me at deploy time if they are not there. That will often prevent a ClassNotFoundException. If I am using a class and it's source bundle is unloaded, OSGi guarantees (IINM) that the version I am using hangs around as long as I need it. I might not always actually want that behavior but it won't result in a CNF exception. If I built my code on a certain version of a library and my co-worker (or friendly neighborhood contractor) decides drop a different version into the app server classpath, my code can keep running happily. What issues are you talking about? What am I missing?
  16. Re: Not really[ Go to top ]

    Ok then, which specific features are you talking about now? Originally you said 100% uptime and modularity were the key features. And I stated you can have both uptime and modularity with existing component models (I added dependency management and classloader isolation). So what features are you talking about now?
    Those are the main features, but within them are other key features for developers using the service oriented programming model. For example, instead of having to program applications using complex APIs and embedded attributes, developers can invoke common, shared services with well defined interfaces. They can access services they need using the registry, filter for the right ones, and if they are not already loaded, the OSGi framework will load them automatically. I don't think either of these benefits are available to Java EE developers today. I agree Java EE has improved a lot in the last few years, and EJB3/JPA are big steps forward. However I also see these as having been done as a result of innovation outside the JCP, i.e. Hibernate for JPA and Spring for EJB3. That's not to say they aren't good, but I think it's fair to say that major innovations are not coming from the JCP anymore. But back to the point, which is the extended benefits of using the OSGi service oriented programming model, dynamic registry and other framework services, and the ability to consume third-party services from a repository of bundles.
    Just to clarify, I'm not against OSGi as a kernel (I'm quite excited about it as a portability layer), I'm against it bleeding into the application space.
    Yes, I understand that, and it's a view shared by other Java EE folks. I would not go so far as to say its adoption at the application level is certain, but I think it is likely. I could be wrong of course, and in 2009-2010 I expect we will find out. It's already achieved certain adoption at the kernel level, and in the embedded space the programming model is well adopted. This year when the enterprise edition comes out we will see more how the adoption goes in the enterprise space.
    Eric Newcomer
    Independent Consultant
    Representing Progress Software, CTO Office
    Co-chair OSGi Enterprise Expert Group
  17. Re: overreaching..[ Go to top ]

    I hope OSGi is keeping its focus on being a kernel/kernel-like API/Container rather than something that is consumable by application developers. IMO, application developers should *NEVER* see this stuff and it should really only be the domain of framework, app server, and container developers.

    --
    Bill Burke
    JBoss, a division of Red Hat
    http://bill.burkecentral.com
    Before being good for containers, OSGi was already good for applications. Hey I can use OSGi today in standard applications, and it's good! :-OOOOO
  18. Re: overreaching..[ Go to top ]

    OSGi used to be a little kernel, now it's closer to SCA! I see some overlapping between them. That means fraction and wars between vendors backing this or that. I understand that SCA is focused on the integration problem and OSGi is more core. But the feature sets are becoming more and more similar. And all that when EJB and SCA are in some ways overlapping too! What's going on here?! Ara.
  19. Re: overreaching..[ Go to top ]

    Ara, We have had a requirements doc for mapping SCA to OSGi in the pipeline for a while now, but no one has been working on it for a while. A couple of good designs have been proposed, and as EEG co-chair, I'd really like to see this happen sometime, and I have had some informal discussions with some vendors that make me think it's only a matter of time. Currently planned for the enterprise release are mappings of various Java EE bits, but this is to make them available as OSGi bundles. The first order of business is to ensure they work in an OSGi framework as they do today in a Java SE/EE environment. The next step will be to define OSGi services and bundles for them so that someone wishing to use the OSGi programming model can access them as services via the OSGi registry. Finally, bits of SCA are already included in the Distributed OSGi design, especially the intents and configuration metadata (bindings and policies) for multiple distribution software environments. The goal of the OSGi enterprise work is not to create something like EJBs or SCA, but to map those (and other) things to the OSGi framework where we have received requirements for them, so that they can be better used within an OSGi environment. We are explicitly not inventing anything new here, our focus is on adapting existing technologies to the OSGi microkernel, registry, service oriented model, etc. That way the current benefits of the OSGi dynamic framework can be available to those wishing to incorporate existing technologies used in enterprise applications. Of course, anyone can code everything themselves if they want, but the idea is to be able to make it easier to reuse things in an OSGi environment such as existing middleware systems, persistence abstractions, and other system level capabilities already in wide use in the Java world. Eric Newcomer
    Independent Consultant
    Representing Progress Software, Office of the CTO
    Co-Chair, OSGi Enterprise Expert Group
  20. Re: overreaching..[ Go to top ]

    I think OSGi should be the domain of container developers or developers writing for system services.. Using it in application development might be too much of an overkill
  21. Unless you or anyone else is arguing that any standard supporting transactions is doomed for reasons other than historical failures, I think we need to judge OSGi on it's merits in isolation.
    The crux of my post was "what's next". Feature proliferation is rarely a good thing. OSGi does what it was supposed to do in a very clean and non-intrusive way. I'm just hoping...
  22. "very clean and non-intrusive way." On paper that is but certainly not in the way is has been implemented with its butchering of the classloader mechanism just so one (a developer) can do a hot deploy on a workstation because lets be honest here in the context of Java enterprise applications (and not some telco service) most operations teams would rather restart the complete process than attempt to do a partial deployment. There are many reasons for this some not at all technical but has anyone truly considered how does one actually test a change that is based on a partial (re-)deployment of one or more bundles. To actually test this the test team would have to have an exact replicate of the live production processes and we are talking about state being maintained in some form of another whether it is correct or not. At least with a restart the test team have actually tested is does restart whereas with a live deployment who knows it is anyones guess whether it will happen without dire consequences later. Those claiming OSGi is lightweight are simply blind to the fact that most enterprise applications running in such containers are monsters of complexity with deep request processing pipelines (call depths > 400) and large footprints and this hold true (more so) for spring applications. The only thing lightweight is the people how believe that things are lightweight. William
  23. Unless you or anyone else is arguing that any standard supporting transactions is doomed for reasons other than historical failures, I think we need to judge OSGi on it's merits in isolation.


    The crux of my post was "what's next". Feature proliferation is rarely a good thing. OSGi does what it was supposed to do in a very clean and non-intrusive way.

    I'm just hoping...
    I agree that feature proliferation is a bad thing but only when those features are unnecessary or poorly thought out. I guess all I am saying is that we shouldn't just assume that new features imply bloat. Transactions are pretty fundamental. I'm not sure whether they belong in OSGi or not but I think that would be an interesting discussion. If you have specific reasons why transactions are a poor fit in OSGi, you should present them so we can evaluate the merits of the argument against them. P.S. I'm not criticizing you for expressing that you want OSGi to remain slim. In general, I fully second that desire.
  24. Transactions etc[ Go to top ]

    As an old transactions guy, I really cringe whenever I see them being used as example of what to avoid. ;-) Honestly, I don't think anyone familiar with transactions recommends using them where they aren't needed. I can understand a backlash in the industry because the existing Java EE and .NET frameworks made it too easy to abuse them, but I think it remains true that if you need them, they provide an important capability. Certainly I am one old guy old enough to remember programming against a database that did not have them, and I can tell you for sure it was a real pain backing out partial updates by hand. But this is probably more accurately about distributed transactions, which is a bit of another story. Ok, so why did we include distributed transactions (i.e. a JTA mapping) in the OSGi enterprise release work? The requirement originated from folks wanting to update the framework transactionally, i.e. to change config in an all or nothing manner. But like any good OSGi mapping, nothing forces anyone to use or even load it. The benefit of having it mapped thought will be for a bundle to be able to make a service call to use it, instead of coding to the APIs or using static config or embedded attributes (which are way more clunky).
  25. Yes, eventually[ Go to top ]

    The requirements for the design of distributed OSGi include bi-directional capability i.e. from and to external environments. So far in the RI we are showing from OSGi to Web services, but over time additional capabilities will be added to it (as usual I suppose). One other capability we need to fill out for example is support for the upcoming Blueprint Service, which is based on Spring dynamic modules. Eric
  26. Re: Yes, eventually[ Go to top ]

    The requirements for the design of distributed OSGi include bi-directional capability i.e. from and to external environments. So far in the RI we are showing from OSGi to Web services, but over time additional capabilities will be added to it (as usual I suppose). One other capability we need to fill out for example is support for the upcoming Blueprint Service, which is based on Spring dynamic modules.

    Eric
    The OSGi spec doesn't include web service specifcations, does it? I personally think it would be really unwise to tie OSGi to SOAP-WSDL.
  27. No, Web services is just an option[ Go to top ]

    The RFC 119 design supports the configuration of existing distributed software into an OSGi Framework. Web services are one example of a distribution software type. The design is intended to support RMI, IIOP, JINI, Jabber, etc. What we mean when we talk about external systems is that we want to be sure that we can support the multiple protocols and data formats not only within an OSGi Framework, but when they are used to interoperate with non-OSGi environments as well.
  28. The RFC 119 design supports the configuration of existing distributed software into an OSGi Framework. Web services are one example of a distribution software type. The design is intended to support RMI, IIOP, JINI, Jabber, etc.

    What we mean when we talk about external systems is that we want to be sure that we can support the multiple protocols and data formats not only within an OSGi Framework, but when they are used to interoperate with non-OSGi environments as well.
    I think I understand the goal. But the spec only defines the OSGi interface and doesn't state what protocols are supported or how they should be handled, correct?
  29. Correct[ Go to top ]

    Yes, that's correct. The OSGi interface is defined as usual, and properties are added to indicate it's "remotable" i.e. can be accessed remotely. Additional metadata specific to the protocol being used is not visible in the OSGi environment, but it's used by the distribution software system to create a proxy and provision and advertise the service etc. When a remote OSGi service is invoked, the remote property information also can be used to configure and instantiate the service dynamically. But in either case the OSGi service is unaware of the specific communication protocol being used. The goal of the design is to allow (as Peter Kriens often says about OSGi) "lots of ways of doing lots of things" - in other words we specifically did not want to constrain the solution to the use of any particular protocol.
  30. Re: Correct[ Go to top ]

    The goal of the design is to allow (as Peter Kriens often says about OSGi) "lots of ways of doing lots of things" - in other words we specifically did not want to constrain the solution to the use of any particular protocol.
    This is remote service capability is really interesting. The way I see this, it actually makes OSGi a provocative platform for integration and service oriented systems. One issue I've seen with naively developed webservices that make use of other web services is that it's convenient to separate the service from it's address. That is, if the service is remote, call it using HTTP but if it's local, call it on same call stack. What would be really slick would be the ability to automatically call the service remotely when the local version is too busy although I could be over-thinking this.
  31. Nice idea[ Go to top ]

    James, That's a good suggestion, thanks. I believe the design can accommodate it, although I need to double check. The OSGi framework design supports filtering services and tracking their use, so it should be possible to check when a service is too busy and search (using filters) for a remote instance of the same service. Eric
  32. WTF! Where is the snarky comment from Bill Burke?!?! I opened this thread just to see that! :P
  33. Sebastian -
    WTF!

    Where is the snarky comment from Bill Burke?!?!

    I opened this thread just to see that!

    :P
    You commented too soon ;-)
    No, I just don't want yet another bloated, reactionary, component model infecting application development when we can achieve modularity and 100% uptime with simpler, existing component models. -- Bill Burke JBoss, a division of Red Hat
    Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  34. Ok, I get it now. You guys already knew Bill's position on OSGi! ;-) I have to tell you that the last time I spoke in person with Bill, quite a few years ago now I suppose, he was telling me how he was against Web services, which is what I was working on at the time. I am not sure what that says, but I wonder if there's some kind of trend there, or maybe I just pick things to work on that Bill doesn't like.
  35. Hi Eric, You've done well to bring Bill out, we sit and lurk on TSS wondering what's going to wake him up, OSGi obviously did the trick. Basically Bill dislikes anything that's not done well in JBoss, which of course gives him a lot of choice. Just ignore him, if Bill supports a technology then you need to start worrying as it's obviously not destined for main-stream. I'll leave my opinion of OSGi to a few beers one night in Boston but well done Eric, great work! -John-
  36. Hi John, Great to hear from you and thanks for the comment. Bill and I go way back to my early days at IONA, but I haven't seen him much since then. One thing I can tell you is that the JBoss guys talk a lot about OSGi but they almost never show up for the meetings. Hope to take you up on those beers sometime, should be an interesting discussion. I remember we had a few (well both beers and discussions) back in the day, so hope we have another chance to catch up soon. Eric
  37. You've done well to bring Bill out, we sit and lurk on TSS wondering what's going to wake him up
    John, its all part of my grand plan. Waking up on TSS lately that is...I figure if I piss enough people off nobody will attend my TSSJS sessions and I can spend more time playing poker. cheers.
  38. John, its all part of my grand plan. Waking up on TSS lately that is...I figure if I piss enough people off nobody will attend my TSSJS sessions and I can spend more time playing poker.
    cheers.
    Just post your slide a week before then you'll get a quiet session :-) -John-
  39. he was telling me how he was against Web services, which is what I was working on at the time.

    I am not sure what that says, but I wonder if there's some kind of trend there, or maybe I just pick things to work on that Bill doesn't like.
    Well, just go ask any RESTafarian on whether I was right or not on WS-* :)
  40. he was telling me how he was against Web services, which is what I was working on at the time.

    I am not sure what that says, but I wonder if there's some kind of trend there, or maybe I just pick things to work on that Bill doesn't like.


    Well, just go ask any RESTafarian on whether I was right or not on WS-* :)
    And, please, don't put words into my mouth... I never said I didn't like OSGi. I just don't think it is appropriate for it to bleed into application code.
  41. he was telling me how he was against Web services, which is what I was working on at the time.

    I am not sure what that says, but I wonder if there's some kind of trend there, or maybe I just pick things to work on that Bill doesn't like.


    Well, just go ask any RESTafarian on whether I was right or not on WS-* :)


    And, please, don't put words into my mouth... I never said I didn't like OSGi. I just don't think it is appropriate for it to bleed into application code.
    One man's framework/platform is another man's application.
  42. he was telling me how he was against Web services, which is what I was working on at the time.

    I am not sure what that says, but I wonder if there's some kind of trend there, or maybe I just pick things to work on that Bill doesn't like.


    Well, just go ask any RESTafarian on whether I was right or not on WS-* :)


    And, please, don't put words into my mouth... I never said I didn't like OSGi. I just don't think it is appropriate for it to bleed into application code.

    One man's framework/platform is another man's application.
    I was thinking about this a little more - If you ever had to support or enhance a 3rd party app, there would be no question as to why OSGI is needed for "applications". This happens quite often in "enterprise" environments.
  43. If you ever had to support or enhance a 3rd party app, there would be no question as to why OSGI is needed for "applications"
    Please explain why because I have done this many times and never had to resort to duplicating different version of a class across multiple class loaders. I accept (regrettably) that occasionally one or more different versions of a library could exist in a single JVM but I cannot accept an architecture that strongly promotes this as it is a nightmare to test & manage. This is band-aid to a symptom and not a cure to a problem.
  44. If you ever had to support or enhance a 3rd party app, there would be no question as to why OSGI is needed for "applications"


    Please explain why because I have done this many times and never had to resort to duplicating different version of a class across multiple class loaders.

    I accept (regrettably) that occasionally one or more different versions of a library could exist in a single JVM but I cannot accept an architecture that strongly promotes this as it is a nightmare to test & manage. This is band-aid to a symptom and not a cure to a problem.
    So you wouldn't use OSGI anywhere? I am just looking for the point to start the explanation)
  45. The product I work on supports OSGi so I would not say that I do not use it at all. I did state above that some of the concepts (modularity, event life cycle) introduced in the specification are beneficial but that the implementation and/or mapping to the Java runtime seems forced and rather narrow in its view of the outside world (its initial frame of reference applications) which is why vendors have had to introduce "innovations" (workarounds) to make it (fix it) applicable to a different execution context and environment. Do I believe we need another organization re-inventing every enterprise service again in another stack? No. Do I believe that modularity would be better addressed explicitly at the design time rather than the runtime? Yes though I do recognize that the two might both be applicable for slightly different purposes. Do I believe the hype? No. I see no such correlation in production applications that I have been called into diagnose. I also do not hear operations or testing teams screaming for partial hot deployments of fragments of an application code base to keep a single JVM up during a managed change request (it would be nice outside of a change request like before it crashed but that it not being addressed here).
  46. Do I believe we need another organization re-inventing every enterprise service again in another stack? No.
    That's great. Neither do those of us working on the enterprise OSGi release. That's why we are focused on mapping existing technologies to the OSGi model. I am therefore not sure what organization you might be referring to.
    I also do not hear operations or testing teams screaming for partial hot deployments of fragments of an application code base to keep a single JVM up during a managed change request (it would be nice outside of a change request like before it crashed but that it not being addressed here).
    Once again I have to say it is very difficult to understand your viewpoint and what specific examples you're drawing you conclusions from. Operations and testing teams are unlikely to take a strategic view of applications such that they would be thinking about or asking for a new procedure for building and deploying them (the design and build stages of the lifecycle being where modularity is most applicable). I don't want to put words in your mouth, but you seem to be acknowledging the benefits of a modularity system in general but not for your job in particular. The benefits of improved modularity during the development process are well documented. Regarding hot deployment I suppose this is application dependent - some applications haven't changed much in years and are unlikely to.
  47. The statement was "explicitly at the design" not "during the development process" but made I was not explicit enough. The language and runtime must have explicit and inherent support for modularity. I also believe that this modularity can be independent of the deployment packaging. It can even be augmented by other deployment technologies at runtime.
  48. The language and runtime must have explicit and inherent support for modularity. I also believe that this modularity can be independent of the deployment packaging. It can even be augmented by other deployment technologies at runtime.
    Would you say that you agree with Sun's approach to modularity in Project Jigsaw and JSR 294 then?
  49. @William, Apologies, I should have checked your blog before. I see a lot of heavy experience with Java EE, but no mention of OSGi. Perhaps you are assuming things about the OSGi framework because the java EE vendors are all using it or moving toward it? This is true, but the original reason was to efficiency in a large Java development project (anyway that's what the IBMers have told me about why it was used in WebSphere application server - and they were the first). And certainly a lot of the reporting about OSGi technology that's coming from the Java EE world is very different than what you would hear in the embedded space, for example, or even from the startups working with OSGi frameworks on new products, such as Paremus or SpringSource. If you are judging OSGi work by what you hear from the Java EE context, I would suggest taking another look at it from outside that context. It is really not the same thing at all. Eric
  50. Eric, I have probably more experience of proprietary frameworks than most people I know as a software product designer and software performance engineer but I suspect most people reading my blog entries would not be interested because they are mainly using the dominate platform(s) in the Java space. Unlike most of the developers I come into contact with I actually read the specifications of each new "silver bullet" technology before I listen to what others have to say (or promote because of an agenda which is not necessarily an evil thing but something to be aware of). I can quickly envisage costs (not just from a developers perspective) and benefits (not from a fanboy perspective). [as I have stated above] OSGi could indeed be "lightweight" in relation to some benefit being derived for some amount of effort at design, development, deployment or runtime. But I also argued that no matter how "lightweight" a framework is viewed it still represents a very small proportion of what is actually being done (during design, dev, ....) at higher levels in the application stack in an enterprise context (in the embedded space this is different). Using OSGi will not make an enterprise application lightweight no matter what perspective you take unless of course it is to make statements like "heavy ..... Java EE".
  51. Eric,

    I have probably more experience of proprietary frameworks than most people I know as a software product designer and software performance engineer
    But not with OSGi standard compliant frameworks... Therefore you are extrapolating, and may or may not be right.
    Unlike most of the developers I come into contact with I actually read the specifications of each new "silver bullet" technology
    Did you read the OSGi specification?
    OSGi could indeed be "lightweight" in relation to some benefit being derived for some amount of effort at design, development, deployment or runtime. But I also argued that no matter how "lightweight" a framework is viewed it still represents a very small proportion of what is actually being done (during design, dev, ....) at higher levels in the application stack in an enterprise context (in the embedded space this is different). Using OSGi will not make an enterprise application lightweight no matter what perspective you take unless of course it is to make statements like "heavy ..... Java EE".
    No, that is correct, you cannot take OSGi technology and "sprinkle it on" to an existing application and magically reduce its weight. And like any technology, it can be misused and abused. Application developers can always make something lightweight into something heavyweight by adding too much to it, or by using it in the wrong way. But the OSGi approach is to build up from a lightweight core rather than assume developers need every possible API.
  52. Eric,
    Did you read the OSGi specification?
    Now how would you like me to respond to such a fatuous question? Would you like my print records? My registration with OSGi? It has been a while since I have actually worked on a typical project. I develop a performance management and problem diagnostic product so I first start with specifications or API's to determine appropriate extensions and then use these extensions in the field to evaluate projects and diagnose problems. Via software activity analysis (the core of our product offering) I can see how contracts are manifested and what is the degree of coupling and usage of various systems/services/components/... We have extensions for OSGi API's which I created myself. I think if one was to look back over those paragraphs I wrote that Eric and others fail to follow-up one would find the truth. Everything else might just be noise that I unfortunately allow myself to contribute or happen by inviting a sideway response from Eric. Sorry and stupid of me to get caught up talking to those who are obviously no intention of listening (to experience). [my I ask] Do you honestly think that the current 4.x API specification represents the current state of the art in terms of API and service (utility) design? No wrinkles. No warts? No flaws? I know this is highly subjective question but the answer will allow me to understand were you are coming from and whether your technical opinion matters.
  53. @William, Look, I honestly could not tell where you were coming from on this. Sorry if I said anything to upset you, or asked questions you think were inappropriate. It really just seemed from some of them that you did not know much about OSGi. Certainly if I contrast your replies with others who I know have experience with OSGi, they are very different. I am sorry if my guesses as to why were upsetting - it was not my intent. I honestly cannot understand why you have a different impression of the OSGi work than the others. And now you are trying to insult me, to get revenge for something I suppose ;-) Sorry it has come to this. Eric
  54. Eric, I do see the benefits of OSGi but I also see its heritage and were it currently stands today in terms of the life-cycle and runtime each of which I think it not optimal and lessens the possible benefits that could be derived from a truly modular runtime and application platform. I also see some pain points which others [you have mentioned] have had to addressed by way of "innovations". I believe you and others are over selling this technology in the context of the standard enterprise application which today still relies on a number of those heavyweight enterprise services offered up by those heavyweight containers. [Again] I also believe that modularity does not necessarily have to manifest itself in terms of classloader(hiders/copiers) at the runtime. Packaging and deployment technologies could still remain independent and decoupled from this. I think we are not going any further with this. In fact I think we are going over the same items of concerns again with not redress. EOT.
  55. I believe you and others are over selling this technology in the context of the standard enterprise application which today still relies on a number of those heavyweight enterprise services offered up by those heavyweight containers.
    This must be why I am not understanding what you are saying, since I am not trying to oversell anything here. I have no idea where you get that idea. You agree OSGi has benefits but when I suggest they can be applied to enterprise applications you say that I'm overselling? This does not make sense. Also BTW I am simply trying to call attention to the work we're doing in the enterprise expert group at the OSGi Alliance. This thread started because we have achieved a milestone of significance, which is the release of reference implementation code for distributed OSGi at Apache CXF. Because of its membership structure, and IP rights agreements, much of the work of the OSGi Alliance is not public. In this era of open source and increased transparency, we are often asked about what we're doing. Yes, I am promoting what we're doing, but I am looking for constructive feedback. Saying that enterprise developers can get themselves into the same mess with a different approach to the problem doesn't seem very helpful. Sorry about that. Or saying that if we don't do our job the right way, we will not improve the current situation, also does not seem very helpful. Sorry again. So I have been trying to find out if you have any specific feedback for us. And yes, you are saying the same things again about other possible approaches to modularity. And that is of course fine - some folks at Sun have been saying something similar (which I still don't know if you agree with or not) - but it is (obviously) not the approach OSGi is taking. Different approaches to solving the same problem can have benefits, just saying there's another way to do something doesn't really help, either. Sorry about that too. And finally, I believe you have misunderstood the distinction between a heavyweight container (one that attempts to decide for the developer which capabilities he or she needs) and a more lightweight approach in which the capabilities are configurable (not just the applications). Of course complex requirements need complex solutions, you can't avoid that. I have never argued this point, and perhaps this is another reason for the difficulties in this discussion. You have accused me incorrectly of several things by now, and perhaps due to this type of preconception I have not been able to understand your view. By this I mean it appears you are not arguing with me but someone else. Eric
  56. I missed this one.
    you are extrapolating, and may or may not be right.
    Funny I thought this was exactly what you were doing in promoting OSGi with very little in the way of evidence in the enterprise context. Granted it has been adopted and used in more constrained environments were running up multiple JVMs would be prohibitively expensive.
  57. I am really new to OSGi even if I am playing with the same concepts since a long time. Coming to the specific topic, I don't understand yet this interest on distributed services from the framework point of view. Let's keep out management issues from the discussion and focus on consumer perspective. What is the difference in locating services ? None. If (remote) services are registered through ServiceFactory, consumer can use BundleContext to locate whatever it wants. The problem moves to ServiceFactory that, for example, have to search a CORBA NameService or make a string_to_object on an IOR or whatever to generate the stub on the client side. Obviously, proper metadata will certainly help. What is the difference in invoking services ? A lot. History tells that pretending to treat remote call as if is a local call isn't the best way to approach distributed computing. From the provider point of view the approach is the same. ServiceFactory has the responsibility to create the service and properly register it to the specific "remoting" middleware. Here the problem is that server-side deployment is rarely well-specified, so that a ServiceFactory wishing to register a CORBA servant in the POA is rather trivial, while dinamically exposing a SOAP endpoint isn't that easy. I really hope that this is not a trojan horse to give a new suit to old stuff. Guido P.S. I have found a little vague sentence in the spec: 13. The solution MUST NOT prevent the use of asynchronous programming models if these are provided by the transport used. In other words, if the transport provides an asynchronous protocol such as JMS, CORBA one-ways or other message queue or publish-and-subscribe model, it must be possible for the application programmer to take advantage of this asynchronous nature. JMS is not a protocol. CORBA one-ways is not the only asynchronous mechanism available. AMI invocation style is a matter of stub generation (even if client blocks until server orb acknowledges request). Message queue and publish-and-subscribe model are not asynchronous protocols by definition (nor protocol at all from a communication point of view). Here, it is a matter of perspective. For example, a client wishing to publish an object or put it in a queue performs an operation that, normally, IS synchronous (in CORBA world, a publisher must use NotificationService/EventService AMI stub to be really asynchronous). Hope, more care is taken in writing specs.
  58. History tells that pretending to treat remote call as if is a local call isn't the best way to approach distributed computing.
    No one said we're doing that, and we are not. We are tagging remote services so that the application is aware they are being used.
    Here the problem is that server-side deployment is rarely well-specified, so that a ServiceFactory wishing to register a CORBA servant in the POA is rather trivial, while dinamically exposing a SOAP endpoint isn't that easy.
    Yes, of course there will be distributed software systems that may not work with this design, or won't work easily, but this will hopefully be the job of the middleware vendors who want to integrate their protocols with the OSGi framework.
    I really hope that this is not a trojan horse to give a new suit to old stuff.

    Guido
    Not sure what you mean by this - we have specifically avoided inventing a new distributed computing stack on the one hand, and on the other specifically avoided restricting the solution to a single distribution software system on the other.
    P.S.
    I have found a little vague sentence in the spec:

    13. The solution MUST NOT prevent the use of asynchronous programming models if these are provided by the
    transport used.
    In other words, if the transport provides an asynchronous protocol such as JMS, CORBA one-ways or other
    message queue or publish-and-subscribe model, it must be possible for the application programmer to take
    advantage of this asynchronous nature.

    JMS is not a protocol.
    CORBA one-ways is not the only asynchronous mechanism available. AMI invocation style is a matter of stub generation (even if client blocks until server orb acknowledges request).
    Message queue and publish-and-subscribe model are not asynchronous protocols by definition (nor protocol at all from a communication point of view).
    Here, it is a matter of perspective.
    For example, a client wishing to publish an object or put it in a queue performs an operation that, normally, IS synchronous (in CORBA world, a publisher must use NotificationService/EventService AMI stub to be really asynchronous).
    Hope, more care is taken in writing specs.
    You have quoted from the requirements section of the document. I should explain a little about the OSGi process. First we start with requirements statements, next we create design documents (the one we published and from which you quoted), and finally we develop the actual spec (actually Peter Kriens writes it based on the agreed design docs). The requirements (RFCs) are quoted in the design documents (RFPs) for reference. They are not actually part of the design. The idea of this requirement was really just to ensure that nothing we do prevents the use of asynchronous protocols. One of our major goals is to support asynchronous protocols in the design, but we have not, however, included any in the design so far, because once we started the discussion we decided it would take too long for the initial release time frame. So we have postponed this part of the design I'm afraid. ;-) Yes, JMS is not a protocol - but it is a kind of common shorthand, and I find myself using it just because people know what I mean. It's hard to say more than that at this point, since this post is about the OSGi EEG work, in particular the Distributed OSGi design and reference implementation, and we have not yet tackled the design. But in my personal view, the world of distributed computing is divided in somewhat equal proportions between those applications for which asynchronous messaging is more appropriate, and those for which synchronous messaging is more appropriate. These two communication paradigms overlap considerably, however, and many application requirement can be met with either. At the simplest use in the current model, we can easily imagine a JMS compliant asynchronous message broker to emulate the semantics of a synchronous Java interface invocation, and I imagine it will be very likely we will at least see this appear in the implementations as they arrive later this year. I probably should have been signing my posts -
    Eric Newcomer, Independent Consultant
    Representing Progress Software, Office of the CTO
    Co-Chair, OSGi Enterprise Expert Group
  59. Those who have worked with CORBA/IIOP know that every new lightweight RPC technology eventually looks like CORBA/IIOP once the sun shines on it. This is similar for every new component architecture/technology.
  60. Yes, CORBA too[ Go to top ]

    Of course you can use CORBA here, that is definitely part of the intention behind the design. I haven't been signing my posts (my bad) but the design was led by IONA folks (now Progress) with our CORBA and multi protocol heritage firmly in mind. Actually during some of the meetings we've had a standing joke to "just use CORBA" when all else fails. But seriously, the point here is not to invent something new, but to reuse what already exists the best way possible in an OSGi environment.
  61. Re: Yes, CORBA too[ Go to top ]

    Of course you can use CORBA here, that is definitely part of the intention behind the design. I haven't been signing my posts (my bad) but the design was led by IONA folks (now Progress) with our CORBA and multi protocol heritage firmly in mind.

    Actually during some of the meetings we've had a standing joke to "just use CORBA" when all else fails.

    But seriously, the point here is not to invent something new, but to reuse what already exists the best way possible in an OSGi environment.
    I think you might have missed his point. William appears to me to be suggesting that OSGi remote services are going to become like CORBA. I don't really follow that logic: if you worked with CORBA, you know all RPC becomes CORBA (I know maples so I know all trees are just like maples?) but I think I get where he is coming from. My personal belief is that all distributed computing is message based. As soon as you start pretending that you are 'executing remote methods' or 'distributing object' or similar types of abstractions, you are getting into dangerous territory. That was the issue with CORBA, that's the issue with RMI and it's the problem with SOAP (which is mostly dead now despite the ubiquity of the envelope and a couple other elements.) To be specific, I think a lot the problem these previous attempts was conflating the message format with the way programs represent data in memory. The rest of the issues are basically the realization of one or more of "The Eight Fallacies of Distributed Computing." I probably sound like I am talking out of both sides of my mouth here since I just suggested that it would be nice to seamlessly remote when a local service was unavailable or busy but I'm actually thinking of it the other way: assume it's remote and if it's local it just a really fast 'remote' service. In what was is the service "marked" as remote? I'm not sure it's that important but how would you use that?
  62. Re: Yes, CORBA too[ Go to top ]

    "William appears to me to be suggesting that OSGi remote services are going to become like CORBA." Not exactly my point. I just wanted to point out that every new lightweight * turns into a heavyweight * for similar reasons that what it replaced was viewed as heavyweight. Everyone wants modularity and a well defined life cycle with appropriate hooks and extension points. It is the way it is achieved by OSGi within the Java runtime that is not worth the effort at least in the current incarnation. I also believe that some aspects are oversold by people who show a real lack of production experience of deploying and managing the typical enterprise application. In the end it will be a even bigger mess as is evident in the bundles I see in repositories that export & import that complete world. This really has to be inherent to language and runtime design to have any chance of success outside of a few special cases and teams. Hopefully by then we will have a cloud computing platform and programming model that will make all this irrelevant.
  63. Re: Yes, CORBA too[ Go to top ]

    Hopefully by then we will have a cloud computing platform and programming model that will make all this irrelevant.
    Interesting William. I was just talking to Bob McWhirter the other day about his JBoss Cloud and Red Hat's Thincrust project. We're currently creating JBoss Appliances based on RHEL/Fedora with ready-to-go images. With virtualization and if we can shrink these images down enough, I really question the need for versioning and classloader isolation between applications within the same JVM. Enterprises can deploy application specific images, test, then throw a switch to put a new image into production instead of trying to mimic operating system and virtualization within the JVM itself with something like OSGi or JBoss's kernel for that matter. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  64. Re: Yes, CORBA too[ Go to top ]

    "William appears to me to be suggesting that OSGi remote services are going to become like CORBA."

    Not exactly my point.
    I apologize. I was sure I understood.
    I just wanted to point out that every new lightweight * turns into a heavyweight * for similar reasons that what it replaced was viewed as heavyweight.
    I get you. There's often a good reason why things are the way they are that isn't apparent until you experience the problem yourself. On the other hand, sometimes the reasons things are the way they are don't apply anymore. Going back to what I was saying before, it's important to explain why some feature is specifically needed or not instead of just assuming all solutions to a given problem are equivalent in terms of complexity and effectiveness.
    Everyone wants modularity and a well defined life cycle with appropriate hooks and extension points. It is the way it is achieved by OSGi within the Java runtime that is not worth the effort at least in the current incarnation.
    Can you elaborate on why? What (little) I've done with OSGi seems very natural to me. Maybe it's just that I'm most comfortable with straight Java. I like being able to use interfaces and threads and whatever else I need to solve my problems. I get this feeling that a lot of vendors think that the people using their products are stupid. There's this idea that they are 'protecting' us from the tough problems. The reality that I see on a daily basis is that not having the ability to solve problems at more than one level causes more problems and wastes more time than what is saved by being 'looked after'. It's not just that it's insulting to assume that most people can't be trusted to get it right (which it is) but that in reality, makes it almost impossible to deliver quality solutions.
    I also believe that some aspects are oversold by people who show a real lack of production experience of deploying and managing the typical enterprise application.
    A lot of what OSGi provides are solutions to problems that I face as an enterprise application developer. I respect your right to your opinion but I'm not convinced by your arguments.
  65. Re: Yes, CORBA too[ Go to top ]

    get this feeling that a lot of vendors think that the people using their products are stupid. There's this idea that they are 'protecting' us from the tough problems.
    The "poor sods" was a reference to operations staff who have to re-start the crap that is thrown over the fence by those who the vendors are "protecting" from themselves. Now I am making the assumption here that we are talking about an organization that does not have developers doing the actual deployment (or testing for that matter). Please James you know this is not the case because if it was then vendors are doing a pretty bad job as a google search reveals 15,000 matched documents with OSGi + ClassNotFoundExceptions listed and this for a technology that has yet to go mainstream for a sufficient period of time.
  66. Re: Yes, CORBA too[ Go to top ]

    Please James you know this is not the case because if it was then vendors are doing a pretty bad job as a google search reveals 15,000 matched documents with OSGi + ClassNotFoundExceptions listed and this for a technology that has yet to go mainstream for a sufficient period of time.
    I'm not really following your logic here. I'm not trying to be difficult. I just don't understand. I've lots had issues with ClassNotFoundExceptions in JEE and plain-ole Java apps. Are you saying that OSGi increases these issues? As far as whether it's an implementation issue or a spec issue, take this excerpt from the problem description from the first hit from your Google search:
    The Spring-bundle requires the org.w3c.dom package andis started correctly without any problems by Felix, which tells me, that Felix at least knows that there is a bundle providing it, otherwise i could not have started the Spring bundle."
    I can try to look up the actual specification for this. Although it would be a lot easier if Eric clarified whether my understanding is correct here. [Hint hint] Also, please note that I don't think OSGi is perfect by any means. If I find fundamental flaws with it, I will be the first to criticize it. I'm a d*ck like that. I'm not sure it's mature enough for me to use it professionally but I see a lot of potential. It may be true that there are some flaws in the error handling for classloading although I've had issues with trying to find the cause of NoClassDefFoundErrors (which it appears to really be in a number of the hits in your search) outside of OSGi and it could just be a flaw in the JVM.
  67. Re: Yes, CORBA too[ Go to top ]

    Actually William's view seems to represent Sun's view of OSGi, perhaps that is where the objections to OSGi are coming from?
  68. Re: Yes, CORBA too[ Go to top ]

    Actually William's view seems to represent Sun's view of OSGi, perhaps that is where the objections to OSGi are coming from?
    Very funny if you only knew the half of it. As stated previously some of the concepts are sound (standard engineering best practices) it is the shoehorning (mapping) of it onto the Java runtime that is ill-conceived and limiting in terms of shelf life. As it [OSGi] stands today it reminds me of a project at the second largest software company in the world in which millions of dollars and man years were wasted trying to do component development using effectively a hash map (and event listeners) to mimic an OO runtime with reams of reference type (enum like) code and external configuration data listing the possible keys that each type could contain at runtime - with design and development practically decoupled. They eventually did deliver something and managed to fool a significantly large number of product development teams (did they need protection?) within the company to adopt it only to see it die in production as soon as the first product came off the product line. Yes it is possible to get this clunk working but surely there is a much better way which has an architecture design and conceived now for the future rather than what was and is now.
  69. Re: Yes, CORBA too[ Go to top ]

    This is a very strange view of OSGi, one that I almost never encounter. Is this view based on some production use of it, a reading of the specifications, or what? Most people I talk with about OSGi have the opposite view, since it has a relatively small footprint, good consistent architecture, and successful 10-year track record.
  70. Re: Yes, CORBA too[ Go to top ]

    You are obviously making the mistake of ** not ** distinguishing between the application and the underlying framework/runtime. The "small footprint" is more a reflection of the projects/applications/services/ that have previously elected to use this "10 year" old technology and its operating environment. But that is all about the change and what was sufficient in the previous context might not necessarily be the case now when applied to a different type of beast - the standard enterprise business application. OSGi might be light (relatively to what?) but that does not extend to the applications and middleware that use it in some form. I doubt anyone would say that Eclipse is lightweight or WebSphere for that matter. But if you did nothing in these environments they could indeed have a smaller footprint that is normally attributed to them. If a technology does not do much it has a very good chance of having "a small footprint" and "consistent architect". But could it be done more efficient and not just in the runtime but across the complete life cycle (including dev and test)? Now that is what we should be asking ourselves when looking at forward 10 years and not backwards.
  71. lightweight[ Go to top ]

    William -
    OSGi might be light (relatively to what?) but that does not extend to the applications and middleware that use it in some form.
    Lightweight is not simply about the size on disk. (WebSphere could never, ever be light-weight in that regard.) A lightweight framework is one that you can utilize without: * heavy re-architecture of your existing code * having to extend classes (abstract or otherwise) of the framework * having to implement lots of interfaces of the framework * having to provide lots of framework-specific artifacts In other words, "lightweight" is often used as the antonym of "intrusive" (or perhaps, "obtrusive" ;-). A lightweight framework is one that: * allows you to take advantage of some of its functionality without forcing you to support all of its functionality * is designed to minimize the necessity of tightly coupling your work with its implementation In the long term, a lightweight framework is one that can be removed, replaced, upgraded, adjusted, etc. without undue injury to the applications that rely on it. From my limited experience, and IMHO, OSGi is relatively lightweight in that a large number of its benefits should be able to be added to libraries (etc.) without becoming significantly invasive. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  72. Re: lightweight[ Go to top ]

    Cameron what post are you referring to? Disk size? I am glad you removed the corporate muzzle and stop using TSS as a alternative twitter service but disappointed you replaced it with the party line piece. WebSphere could never be regarded as lightweight in any regard but that could be true of WebLogic on a number of fronts in particular memory footprint and performance and it also uses OSGi. I do not think that others promoting "lightweight" frameworks would agree with your definition because the majority seem to refer to the "heavyweight" frameworks as "bloated software". Where does "bloat" come into any of your points. William
  73. Re: lightweight[ Go to top ]

    Hi William -
    Cameron what post are you referring to? Disk size?
    People who refer to something not being "light-weight" often refer to its size. I was trying to point out that -- unlike people -- light-weight software may not be directly correlated to small software.
    I am glad you removed the corporate muzzle and stop using TSS as a alternative twitter service but disappointed you replaced it with the party line piece.
    Hmm .. I'm not sure if I should be complimented or insulted, so I'll take it as a compliment ;-)
    WebSphere could never be regarded as lightweight in any regard but that could be true of WebLogic on a number of fronts in particular memory footprint and performance and it also uses OSGi.
    Yes, and it's also true of "light-weight" frameworks like Spring, which (despite its size) is still arguably light-weight.
    I do not think that others promoting "lightweight" frameworks would agree with your definition because the majority seem to refer to the "heavyweight" frameworks as "bloated software".
    I've never given a toss who agrees with me .. ;-) Of course people who label their own work as "light-weight" will tell you that other (particularly competing) products / frameworks / whatevers are "bloated software". There's no reason to stop self-aggrandizing at the border between truth and nonsense. Nonetheless, my non-definition of light-weight works pretty well because it attempts to reflect what I feel is light-weight about the various successful light-weight frameworks (etc.) that I interact with. I admit to a high degree of circularity in my logic, but that does not (in and of itself) invalidate it, as these are all made-up terms to categorize made-up concepts.
    Where does "bloat" come into any of your points.
    Once we define an objective unit of measurement for "bloat" (e.g. "that project is bloated by almost 3 kilolipids"), then I would better be able to use it for my descriptions. It does bring up a good point that I failed to make in my previous post, which is that "light-weight" is also a description of the minimalist nature of the surface area of the API (etc.) with which you must interact when using a product / framework / etc. Again, that has nothing directly to do with the size of the software package itself. That concept of "surface area" can also be expanded to the "back side" of a product / framework / etc., to the dependencies (versions et al) that are required. The more the dependencies (direct and indirect), the more "bloated" a product will seem, the more "fragile" it is (due to the increased points of coupling and potential for version conflict), and the less "light-weight" it will seem. Perhaps this is one of the aspects to which you are referring? If so, I would tend to agree. "Surface area" can also include the necessary configuration to get a product working. The numbers of nobs and switches that products have is relatively unbelievable at times (this is an area which our own product team is focused on improving for just this reason). Finally, regarding J2EE, part of what contributes to its traditional non-light-weight-ness is the [all too large] minimum set of work required to do the simplest "hello world" example, and the perceived size and complexity of the products that were used to over-complicate the same. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  74. Re: lightweight[ Go to top ]

    Oops ..
    The numbers of nobs and switches ..
    /s/nob/knob
  75. Re: lightweight[ Go to top ]

    In the long term, a lightweight framework is one that can be removed, replaced, upgraded, adjusted, etc. without undue injury to the applications that rely on it.
    I know of many Java applications running in Java EE containers that could easily be run in any number of other containers even containers that have only implemented aspects of a web container (grizzly?). Does that mean these applications are using the "lightweight" features of the Java EE framework - (re-)deployment? Complete nonsense. It all comes down to what benefit is derived for a particular amount of effort. So please do list the benefits within the OSGi specification (the one that has been around for 10 years). Then weight & value these benefits? Finally tell me how you achieve these without extending/implementing a class/interface (activator? eventhandler? configplugin? monitorable? managedservice) and not creating any artifacts (bundles? meta-inf? attributes?) I am surprised you also did not mention the explicit usage of API's and tooling to get anything done inline with the specification and its component model. I have yet to meet any framework that can be "removed, replaced, upgraded, adjusted etc. without undue injury to the applications that rely on it" even with frameworks that are completely transparent (other than reams of xml files scattered all over the place). This is especially true for non-standardized frameworks. If the software relies on it and it is removed and replaced things tends to break in the world that I live it.
  76. Re: Yes, CORBA too[ Go to top ]

    get this feeling that a lot of vendors think that the people using their products are stupid. There's this idea that they are 'protecting' us from the tough problems.


    The "poor sods" was a reference to operations staff who have to re-start the crap that is thrown over the fence by those who the vendors are "protecting" from themselves.
    I didn't mean that to apply to you unless you do feel that 'normal' developers need to be kept in a sandbox. I'm making that sound more simple than I mean it to be. Even when I have the power to do anything I want, I build a sandbox for myself and put myself into it. But invariably, there will come a moment in time when I need to get out of it and do solve some problems. I've seen plenty of people restarting servers everyday. In all cases they were JEE applications servers. I just spent an hour helping someone move a couple messages from one queue to another using a vendor tool. I have a hand-rolled app that can do the same task with a lot less effort. I've seen absolutely no evidence that vendors are any better at solving my problems than me or my colleagues.
  77. Re: Yes, CORBA too[ Go to top ]

    This really has to be inherent to language and runtime design to have any chance of success outside of a few special cases and teams.....
    I pointed out that the problem was rooted in language design about 5 years ago on TSS. Static languages just aren't designed for this type of stuff. It beggers belief that people are still flogging this dead horse in 2009. Fortunately others have noticed the static language component model mania too. Take a look at this blog. Types and Components Now if the rest of you are willing to go back to circa 1990 and DCE just to repeat the whole sorry episode once again, for about the tenth time then good luck :) Paul.
  78. Re: Yes, CORBA too[ Go to top ]

    Static languages just aren't designed for this type of stuff. .
    Are you implying dynamical languages should replace static languages in main stream software development? Sorry English aint my native and I couldnt figure it out.
  79. Re: Yes, CORBA too[ Go to top ]

    Static languages just aren't designed for this type of stuff. .


    Are you implying dynamical languages should replace static languages in main stream software development?

    Sorry English aint my native and I couldnt figure it out.
    I think the blog post explains the issues eloquently (better then I ever did/could). I'm merely pointing out that people have been trying to put a round peg into a square hole for a very long time now. It didn't work then, and there is no reason to think it will work now. Paul.
  80. Re: Yes, CORBA too[ Go to top ]

    Static languages just aren't designed for this type of stuff. .


    Are you implying dynamical languages should replace static languages in main stream software development?

    Sorry English aint my native and I couldnt figure it out.
    OK, I'll bit (a little). One option that Yardena speaks about is wrapping the hard bits (static) with soft bits (dynamic). People have been doing this for a while now. Its called the World Wide Web. The languages and protocol of the web are dynamic (HTTP, HTML, Javascript). This provides the web with a great deal of flexibility through late binding. This is why the Web is successful as a distributed system, and why REST is winning out over WS-* and SOAP. If you hard code the interface at compile time, the moment anything changes your solution will break. If instead you keep the interface soft and malleable, then you stand a better chance of it flexing and surviving change. Yardena makes the point that this is the case in nature so why not software? Take the example of a website as a service. If someone adds a new link to the home page, do all the existing bookmarks to other links fail? Does everyone who references the site have to re-compile their clients due to a change in the "static" interface? The answer is no, why? Because the binding happens at runtime. Either the service provides you with the resource you requested, or it gives you an error (404 Page not found). The only way to find out is to suck it and see. On error you can choose to try a different service if you wish or report the problem to your end user. Simple and it works. Paul.
  81. Re: Yes, CORBA too[ Go to top ]

    OK, I'll bit (a little).
    I agree there are domains where dynamic languages are better than static ones (mostly applications with relaxed requirements, such as web sites). Mission critical software requires static languages. What majority of people are missing is that next generation of mainstream languages are not going to be dynamic, they are going to be static (semi)-functional languages.
  82. Re: Yes, CORBA too[ Go to top ]

    OK, I'll bit (a little).


    I agree there are domains where dynamic languages are better than static ones (mostly applications with relaxed requirements, such as web sites).
    People are using REST for far more than just websites. With protocols such as ATOM gaining momentum, HTTP is becoming the protocol of choice for building robust distributed systems.
    Mission critical software requires static languages.
    Misson critical software requires runtime error handlers (dynamic type safety) and thorough testing. Just take a look at the Ariane 5 disaster report. Static types didn't help there.
    What majority of people are missing is that next generation of mainstream languages are not going to be dynamic, they are going to be static (semi)-functional languages.
    An this is the root of the problem. Everyone is waiting for someone else to solve their problem for them, rather than going back to first principles and evaluating what is the best solution for their problem themselves. I don't know what is going to be the next mainstream language and frankly I don't care. All I want are viable alternatives that address my problems. For this to happen the industry has to stop looking for a golden hammer, it doesn't exist. Fortunately, I think this is now happening, so we can now choose, dynamic, static, OO, functional etc as makes sense. I'm not saying that static languages don't have there place, they do, but the place is not late-bound component models. Take a look at <a href="http://www.opencroquet.org" "="" rel="nofollow"> open croquet where they create a 3D distributed virtual world built from late bound Objects in Smalltalk. The processor intensive 3D rendering is performed in C++ using OpenGL. Another example of wrapping hard with soft and getting the best of both worlds. Paul.
  83. Re: Yes, CORBA too[ Go to top ]

    Ok, you definitely bring up a lot of good points here. But I think the main response is that some applications are better suited for synchronous communications, and some better suited for asynchronous communications. I do not thing one paradigm can meet the requirements of all applications. There have been recent and lengthy debates in the blogosphere about the value of RPC (see Steve Vinoski's blog) but in the end the advice really boils down to use one or the other when appropriate, and don't just blindly use one approach for everything. I have always viewed RPC as a programming abstraction, not a transparent distribution capability. I agree with the critics who say distribution is not transparent, and never can be. But there can still be value in simplifying the programmatic approach to distributed computing. If you had to explicitly set up and tear down persistent sessions, for example, that would seem like work you really shouldn't have to do. It is definitely a big hole in the current Distributed OSGi design - that it doesn't yet include asynchronous protocols. But we nonetheless hope it is the start of a useful new capability. Eric Newcomer
    Independent Consultant
    Representing Progress Software, Office of the CTO
    Co-Chair, OSGi Enterprise Expert Group
  84. It must be me, surely, but again from the spec:
    5.2 Distribution software 5.2.1 Functionality The distribution software is responsible for the actual network communication between a remotely available service and its consumer, including the data format (i.e. serialization) and communication protocol. When a consumer invokes on the remote service the distribution software knows how to marshal the arguments and will then make the dispatch invocation on the remote entity. On completion it will unmarshal the response and return to the caller.
    In case of CORBA, what is distribution software ? Is it a plain org.omg.CORBA.ORB implementation ? If so, what's the value added ?
    On the provider (service) side, the distribution software knows how to make an OSGi Service available over the network so that it can be invoked remotely. The distribution software may optimize on a particular distributed computing protocol, which may require the OSGi Service Java interface to be mapped onto that technology.
    Here things start taking a dangerous way. Let's stay with CORBA example. Are you planning to implement something that takes a Java (POJO) object, creates a CORBA servant that delegates operation to the POJO and register it to the POA ? I guess you know **very** well that types conversion is a big issue, so I hope you expect to require a specific CORBA servant factory in the metadata in order to create the adapter. I guess you expect to require proper metadata for target POA identification and proper metadata for POA creation. Obviously, same applies to consumer side when dealing about proxy creation. If this is the plan, I still wonder if the resulting framework worth the effort and really helps developers. Guido
  85. Ok, you are quoting from the requirements section again, not the solution design. Please start reading at Section 5, page 217 in the preliminary draft PDF. Re: CORBA - the value add is simply being able to use CORBA as a type of distribution software with an OSGi framework such as Eclipse Equinox or Apache Felix. If you look at the actual changes to the OSGi framework that the design requires, they are very small. To make this design work, we will need to change the OSGi Framework, but distributed computing suppliers will also need to adapt their distribution software systems, whatever they are, to work in the OSGi framework, following this design. We are not telling the CORBA vendors how to do this, so exactly how it will work is beyond the scope of the design. And yes, type conversion is an issue. Normally we expect some "data fencing" around the data types since 100% compatibility with all data types between Java and CORBA is not possible. Using CORBA therefore for a solution will mean some constraints and some design issues have to be taken into account. Regarding the value of the solution, please understand we are not trying to replace CORBA, RMI/IIOP, EJBs or anything else. We are simply trying to map these kinds of technologies into the OSGi world so that OSGi developers can use them together with OSGi. If you are happy just using CORBA on its own, there is no issue, no one is trying to convince you to move to this. But if you are using OSGi and you want to communicate among OSGi deployments in different JVMs, we need a standard way for doing that so we can achieve interoperability and compatibility across implementations. Hope this helps. Eric OSGi EEG Co-chair
  86. Ok, you are quoting from the requirements section again, not the solution design. Please start reading at Section 5, page 217 in the preliminary draft PDF.

    I was quoting from RFC 119 (page 21/47). At page 217 there is RFC 124 that is not exactly what I was referring to.
    Re: CORBA - the value add is simply being able to use CORBA as a type of distribution software with an OSGi framework such as Eclipse Equinox or Apache Felix. If you look at the actual changes to the OSGi framework that the design requires, they are very small.

    To make this design work, we will need to change the OSGi Framework, but distributed computing suppliers will also need to adapt their distribution software systems, whatever they are, to work in the OSGi framework, following this design.

    We are not telling the CORBA vendors how to do this, so exactly how it will work is beyond the scope of the design.

    And yes, type conversion is an issue. Normally we expect some "data fencing" around the data types since 100% compatibility with all data types between Java and CORBA is not possible. Using CORBA therefore for a solution will mean some constraints and some design issues have to be taken into account.

    Regarding the value of the solution, please understand we are not trying to replace CORBA, RMI/IIOP, EJBs or anything else. We are simply trying to map these kinds of technologies into the OSGi world so that OSGi developers can use them together with OSGi.
    I understand that you are not trying to replace existing middleware with a brand new one. What I look with some doubt is this kind automagic creation of wrapper for publishing on the provider side and for stub on the consumer side.
    If you are happy just using CORBA on its own, there is no issue, no one is trying to convince you to move to this.
    Why is it always put in this terms ? It is not a matter of religion conversion. It is a matter of pros/cons understanding. I don't want to abuse of anyone time. I simply asked a confirmation on the purpose of the solution.
    But if you are using OSGi and you want to communicate among OSGi deployments in different JVMs, we need a standard way for doing that so we can achieve interoperability and compatibility across implementations.

    Hope this helps.

    Eric
    OSGi EEG Co-chair
    The reason behind this statement is rather obscure to me because of my lack of knowledge, but I find very hard to understand what OSGi brings on the table in terms of interoperability and compatibility not already provided by a specific middleware. Keep on reading. Guido
  87. Yes, I did recognize what you were quoting from. What I want to do is point out the difference between the requirements (which are simply requirement statements) and the actual design, which is what the RFC is really for. In other words, you have been quoting from introductory information, and not the actual design that's been implemented in the RI at Apache CXF. The reason I want to point this out is that your comments are concerned with solutions rather than requirements, so you are debating a requirement with a solution. I apologize for being formal about this, but we are interested in feedback on the design at this point. However if you have any issue with the requirements on which the design is based, that's fine, but then it would be helpful to hear which requirements are missing, what is wrong with them as requirements etc. I think at the end of your comment is the real issue. If you are not interested in OSGi at all, this solution probably has little meaning for you. I don't want to debate the value of OSGi here since that's a very different topic, but as a general statement it provides benefits to developers in the areas of java modularity and dynamic class loading/unloading etc. If you want to look at OSGi very simply it addresses a lot of issues in the Java language around modularity and dynamic behavior. It also offers a service oriented programming model, and supplies many services out of the box in the framework. The distributed OSGi effort was started because OSGi has been successful in the embedded space, and was starting to be adopted in the enterprise space. OSGi is behind the Eclipse plug-ins and for example IBM ships between 200-300 products on OSGi today - and all app server and most ESB vendors have endorsed OSGi as well. So the OSGi Alliance folks hosted a workshop to investigate requirements for a possible enterprise edition (the current edition of OSGi is part of Java SE, see JSR 291). OSGi started life BTW as JSR 8, and subsequent editions are basically derivatives and extensions of that. Anyway at the enterprise workshop one of the key requirements was the ability for OSGi services to invoke other services running in other JVMs. The specification as of R4.1 (current version) defines single JVM invocations only. That is why we have been working on this design. I apologize if I said something wrong in saying we're not trying to replace CORBA etc. The point is really that the design is intended for OSGi based applications.
  88. Draft version[ Go to top ]

    I am sorry, I only just re-read the post and noticed the page number discrepancy. I am referring to the second version of the early release drafts from Nov. 17: http://www.osgi.org/download/osgi-4.2-early-draft2.pdf Check page 217 in this version for the solution design starting in Section 5. Sorry for the confusion. Eric