The OSGi Alliance announced approval of its long-brewing OSGi Enterprise Specification. An effort outside the conventional Java Community Process, OSGi aims to bring better modularity to Java development in the enterprise. It includes profiles for development based on both Blueprint Containers and Declarative Structures.

Read full coverage of the OSGi Enterprise Specification announcement.

Congratulations to all involved! I have been playing with Blueprint and the Aries implementation recently and both appears to have great promise.

Sincerely,
Daniel Selman

It feels like a DejaVu to me - CORBA and OMG( object mgmt group ).
i fully understand the benefits - but its going to be a hard sell in most places. The costs are goign to be huge to refactor anything existing. And selling new ideas menas lots of training to developers and prod support etc. Smaller / start ups should look into this right away, but BIG coprorations ? oh man!

good luck !

It feels like a DejaVu to me - CORBA and OMG( object mgmt group ).
i fully understand the benefits - but its going to be a hard sell in most places. The costs are goign to be huge to refactor anything existing. And selling new ideas menas lots of training to developers and prod support etc. Smaller / start ups should look into this right away, but BIG coprorations ? oh man!

How is OSGi like CORBA or OMG?

How is OSGi like CORBA or OMG?

Because it is bloated and overcomplicated, it reinvents everything again from scratch etc. I mean do we have to define specification for licensing (Bundle License)? Is that really necessary? Who would spend even a minute thinking about this is real life project? Quoting from this blog: http://osgi.mjahn.net/2008/08/28/some-thought-on-the-osgi-r42-early-draft/

"Now, it is possible to display, which licenses are actually contained in your container and even more important, you can define rules for certain Licenses not being deployed in your environment."

Now, I don't know on what kind of projects OSGi supporters are working on, but in my world, when counting all deadlines, budget cuts and many more, spending even a minute to read these kind of things is crazy.

Things like these make OSGi look like a joke.

Now, I don't know on what kind of projects OSGi supporters are working on, but in my world, when counting all deadlines, budget cuts and many more, spending even a minute to read these kind of things is crazy.

This isn't something that's designed for developers.  It's designed to eliminate a lot of work and frustration for administrators.  Just because you don't understand something the need doesn't mean it has no value.

"This isn't something that's designed for developers.  It's designed to eliminate a lot of work and frustration for administrators."

Thank you Captain Obvious.

"Just because you don't understand something the need doesn't mean it has no value."

Understand what? Need to write full specification for some Log Service so we can reinvent the wheel and add yet another level of abstraction.

OSGi guys are doing great job, but their vision is not aligned with reality and current market need.

"This isn't something that's designed for developers.  It's designed to
eliminate a lot of work and frustration for administrators."

Thank you Captain Obvious.

How old are you?

"Just because you don't understand something the need doesn't mean it has no value."

Understand what? Need to write full specification for some Log Service so we can reinvent the wheel and add yet another level of abstraction.

OSGi guys are doing great job, but their vision is not aligned with reality and current market need.

You apparently don't understand how simplifying license management is valuable.  Companies spend a lot of money on this kind of thing.

I see value in a lot of what OSGi offers.  It's already incorporated into tools that we are just starting to use.  I don't see what wheel it reinvents exactly.  I see some things that it succeeds at where other attempts have failed but that's not really the same thing.  It's only 'reinventing the wheel' if it doesn't improve on what came before.  Perhaps if you could be more specific about what it is that you think has already been done, it might be meaningful.

"Perhaps if you could be more specific"

If you are developing middleware tools, servers or even development tools like Eclipse, I do see need for OSGi. Eclipse is perfect example of concrete problem (need for good modularity), and good solution for it (OSGi).

If you are however working on some of the remaining 95% of systems which solve concrete business problems like trading, insurance, integration, I did not see need for OSGi in the last 4 years since its hype started, and neither did my colleagues. Existing tools solve such problems very good already.

"Perhaps if you could be more specific"

If you are developing middleware tools, servers or even development tools like Eclipse, I do see need for OSGi. Eclipse is perfect example of concrete problem (need for good modularity), and good solution for it (OSGi).

If you are however working on some of the remaining 95% of systems which solve concrete business problems like trading, insurance, integration, I did not see need for OSGi in the last 4 years since its hype started, and neither did my colleagues. Existing tools solve such problems very good already.

That's not specific.  Specific would be a naming feature of OSGi that attempts to solve something that is already solved by other tools and is not improved upon by the OSGi solution.  That is, name the feature of OSGi, name the problem it attempts to solve, name the existing solution, and explain why OSGi doesn't offer a significant improvement over that existing solution.

This is not a rhetorical request.  I see that OSGi offers a number of benefits in the enterprise space (in which I am firmly planted.)  What have I been missing in the decade I've been using JEE?

"That's not specific.  Specific would be a naming feature of OSGi that attempts to solve something that is already solved by other tools and is not improved upon by the OSGi solution.  That is, name the feature of OSGi, name the problem it attempts to solve, name the existing solution, and explain why OSGi doesn't offer a significant improvement over that existing solution."

It clear two of us wont agree on this debate. Point of my post was to give warning to those wishing to hear opinion from people on both sides. Moreover, since you are 'selling' the OSGi, you should present concrete benefits of using OSGi. And by benefits, I dont mean some high level coroporate bull stuff, but rather something like Spring did when it hit the market: to anyone who tried it for 5 minutes it was clear it is better solution than existing ones, such as EJB 2. That is how you know you have better solution in front of you.

"I see that OSGi offers a number of benefits in the enterprise space (in which I am firmly planted.)"

Well good luck to you then, because I dont (except for some niche markets, such as Eclipse etc).

It clear two of us wont agree on this debate. Point of my post was to give warning to those wishing to hear opinion from people on both sides.

What debate?  A debate requires at least one rational argument.

Moreover, since you are 'selling' the OSGi, you should present concrete benefits of using OSGi.

How do you figure I am selling OSGi?  All I did was ask for someone to explain their comment.  Then once you replied, I asked the same of you.  I'm not even sure I will use OSGi.  A lot of that will depend on whether it gains enough traction.

Since you asked, the main benefit I see of OSGi is dependency management.  That is, it provides a robust approach to specifying, verifying, and resolving package dependencies.  If you want to explain how you do this now, I'm all ears [eyes].

On the other hand, I never really saw much value in Spring.  It's always a seemed like a tool for people who didn't really know how to design software to me.  Kind of a code-by-numbers approach.

"A debate requires at least one rational argument."
" It's always a seemed like a tool for people who didn't really know how to design software to me."


Haha now I remeber again why I decided in the past to avoid wasting my time with you in any kind of discussion.

"A debate requires at least one rational argument."
" It's always a seemed like a tool for people who didn't really know how to design software to me."


Haha now I remeber again why I decided in the past to avoid wasting my time with you in any kind of discussion.

Please do avoid me.  Thank you.

I am very happy that the enterprise spec is out now. Finally we get to see some convergence of OSGI and Javs EE.

I really like OSGI for its simple and extendible model. Just take the beauty of  httpService.registerServlet(...) to deploy a servlet. (this was already there before the enterprise spec came out). In a way, in addition to what Java EE does by defining an execution environment for components, OSGI also adds APIs for dynamic deployment and manipulation this environment. Also, it's component concept is more lightweight.

In the projects that I see, we regularly bump in to restrictions of Java EE where isolating two components in separate deployables either leads to great complexity (because of the use of resource adapters) or it leads to huge overhead (because of network communication, serialization, declarative security, and transactions of remote EJBs).

And, about some of the criticisms of OSGI reinventing existing stuff. This is of course not true, it uses existing specs like JPA, servlets, etc. and makes them work in a much more flexible lightweight environment.

Also, the comparison with CORBA is flawed. CORBA was a spec designed by a committee trying to become popular. OSGI on the other hand is a spec which was not even intended for enterprise usage which has been gaining more popularity in the enterprise space without anyone trying to push it.

I would be really happy to see this convergence of OSGI and Java EE continuing. OSGI really fills a lot of gaps that Java EE has. There are really numerous occasions at work where OSGI could really have helped us to reduce effort and improve efficiency (both runtime and development efficiency).