• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OSGI usage in the ecosystem

 
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
The most famous OSGI usage in Java culture is Eclipse and Glassfish (and maybe NetBeans but I'm not sure), otherwise I didn't notice OSGI.
Is this because OSGI is complex? does this mean that the best OSGI use is for IDEs and servers? what about web applications or desktop applications?
When do I know that I need OSGI for my project?
Thanks.
 
Ranch Hand
Posts: 433
Netbeans IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OSGi comes a looooong way. It's already 12 years old. It was mainly used in embedded systems, like cars, washing machines, etc. BMW for example is using OSGi (did you know that in such a car is over 1 GB of software?! *) Or Miele is using it for it's products (washing machines, oven, etc.) to communicate under each other so that you can go to your washing machine in the cellar and leave the oven on and as soon as the oven has a new status (e.g. reaching the temparature), this message is displayed on the washing machine display (it's called Miele@home **)
Okay, nothing you would have noticed. OSGi itself isn't that complex at all. But the lack of tool support for many years made it a pain in the a** to develop. I guess with Spring DM things were getting better. But it's quite a long time ago, that I looked into OSGi.

Regarding desktop-applications: what is an IDE? It IS a desktop application.
And web applications: LinkedIn was experimenting with OSGi (don't know the current status, but this old blog entry might be of interest).


If you are further interested in this topic, you shold listen to http://www.se-radio.net/2007/12/episode-80-osgi-with-peter-kriens-and-bj-hargrave/

* a presentation from BMW (in german): http://www.java-forum-stuttgart.de/jfs/2003/folien/C1_Schaefer_BMW-car-it.pps
** http://www1.miele.de/de/aktion/mieleathome/678.htm (also in german)
 
author
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

John Todd wrote:Hi,
The most famous OSGI usage in Java culture is Eclipse and Glassfish (and maybe NetBeans but I'm not sure), otherwise I didn't notice OSGI.
Is this because OSGI is complex? does this mean that the best OSGI use is for IDEs and servers? what about web applications or desktop applications?
When do I know that I need OSGI for my project?
Thanks.



OSGi technology isn't something that you should set out to do because it is so cool. It is an enabling technology for creating more modular, loosely coupled (and potentially dynamic) systems. The core concept of OSGi is simply creating more modular code to make it easier to maintain and reuse. We could do a lot of this by rolling our own mechanisms (and many people have), but then we lose the ability to have lots of reusable modules that work together.
 
author
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

John Todd wrote:The most famous OSGI usage in Java culture is Eclipse and Glassfish (and maybe NetBeans but I'm not sure), otherwise I didn't notice OSGI.
Is this because OSGI is complex? does this mean that the best OSGI use is for IDEs and servers? what about web applications or desktop applications?


I gave a "state of the union" overview in a presentation at Øredev 2010. They've not published the video yet, but you might find the slides useful: http://www.slideshare.net/mcculls/redev-2010-what-happened-to-osgi

John Todd wrote:When do I know that I need OSGI for my project?


If you're about to create your own plugin framework, or write a custom classloader to run different versions of the same application, then I'd take a look at OSGi because it's a standard solution to those problems. As Richard says, don't just use OSGi for the sake of it - do it because it satisfies a requirement. That said, you might want to look at some OSGi programming "best-practices" http://www.osgi.org/Links/BasicEducation so your code ready in case you need it in the future. Things like programming to interfaces, not assuming global classloader visibility (ie. use of Class.forName is a particular issue in OSGi) can make your code much more amenable to OSGi.

If you're providing a library for others then you might want to consider adding OSGi metadata to your JAR manifest - this is typically a painless process, but invaluable to OSGi users who want to use your library (we discuss this topic in the book).
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Joachim Rohde ,
Can we compare osgi with Jini ?
 
author
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(To quote a bit from the book :-)

Jini targets OSGi’s original problem space of networked environments with a variety of connected devices.
...
The Jini model assumes remote access across multiple VM processes, whereas OSGi assumes everything occurs in a single VM process. But in stark contrast to OSGi, Jini doesn’t define any modularity mechanisms and relies on the execution-time code-loading features of RMI.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic