What are the fundamental differences between OSGi and Java EE? [closed]

Question

So I took some time this afternoon to finally sit down and begin reading up on the mysterious and elusive "OSGi" and its so-called bundles.

OK, so I think I get it. An OSGi "bundle" is basically a JAR with some additional manifest information. And, instead of deploying it to a normal application server (or other container), you deploy it to an OSGi server like Apache Felix. It run and then provides services to users/clients.

How is this any different than a normal EAR being deployed to an app server???

OSGi seems to be on the rise (I keep running into it!), but for the life of me I don't understand what it offers (feature-wise) over anything you can do with real-deal enterprise server like GlassFish or Spring.

I know the world hasn't gone crazy, so I'm obviously missing something. Just haven't been able to figure out what. Thanks for any help or insight!

Answer 1

Comparing Java EE with OSGi is like comparing apples and oranges with the additional bonus of not knowing what is what.

Java EE focus is on scalable multi-tier business applications in heterogenous environments and enterprise wide integration of information systems.

OSGi started at another corner by integrating several independent codebases into one JVM (please excuse me for being extremely brief).

Of course some problems (e.g. hot deployment) are common to both environments - but to a varying degree.

Of course you can upgrade, downgrade and crossbreed both of them and they will meet somewhere in the middle.

So the question should not be "What benefit has A over B" but something like "In what field A has clear advantages over B and vice versa?" Let me rephrase that: "When do I need a hammer and when do I need a saw?"

Answer 2

An OSGi bundle is more of a "software module" than a "jar", "war", or "ear" file. OSGi bundles rarely provide benefit if they bundle an entire application; however, they are very beneficial in the automation and correct handling of hooking up lots of libraries.

So consider the problem OSGi attempted to solve, and you will better understand where it fits. It is the Java equivalent of the "diamond inheritance" pattern from C++. You include two libraries, which each need a common logging library, but in this case it's not because of multiple inheritance, it's because of multiple include statements.

If the two libraries both work with the same version of the common logging library, you're in luck. If they don't, then to get each library working correctly independently, you need to load two copies of the same library, each which likely uses the same name spaces (and often the same class names).

OSGi is a means of bundling which allows two versions of the same library to be loaded which use the same name spaces, the same class names, but were created at different times. It also hooks up the "right" version to the "right" OSGi bundle, preventing a bundle from using the "wrong" release of the "right" library.

Java EE does a lot, but this isn't something that Java EE even addresses. At best, project Jigsaw was working on the same problem. Where the Java EE / OSGi confusion comes into play is that most of the early adopters of OSGi bundling were those who were implementing functionality similar to some of the libraries offered in Java EE. That said, the actual container-connection framework (OSGi) had nothing to do with the bundled functionality (although some of the discovery was structurally modified to comply with OSGi bundling requirements).