Alex headshot

AlBlue’s Blog

Macs, Modularity and More

The Omega Problem

Conference 2011 Eclipse Osgi

What is the Ω problem? It's a problem caused by the use of greek letters and astrological signs to refer to OSGi projects (or ΩSGi projects), thereby hiding the purpose of the project itself behind a name that is likely to be both unfamiliar and eminently forgettable.

There are certainly Java projects which have a good naming convention, such as the Spring project set – where the name of the project gives immediate reference but also is easy to discuss in community forums, project mailing lists and on CVs.

  • Spring Data
  • Spring Web Services
  • Spring LDAP
  • Spring Social
  • Spring Batch
  • Apache Commons Lang
  • Apache Commons IO
  • Apache Directory Server
  • Apache RegExp

Then there are projects whose name you're not even sure how to spell, let alone remember when you're trying to advertise the benefits to muggles. And since they're all so similar, you often end up confusing one for another:

  • Eclipse Epsilon
  • Eclipse Gemini
  • Eclipse Libra
  • Eclipse Virgo
  • Eclipse Orion
  • Eclipse Orbit
  • Apache Aries
  • Apache Gogo
  • Apache Karaf
  • Apache Sigil
  • Apache Tuscany

About the only thing you can take away from this list is that both Apache and Eclipse make some weird sounding project names.

The problem is that in order to progress with OSGi in an Enterprise world, you need implementations of some of the Enterprise services. Whilst the Core services are all part of the standard release (e.g. Equinox, Felix), the Enterprise services are extras that are required in order to do anything but are not shipped by default. So, to talk to a database you need the Enterprise JDBC service, the Enterprise JDNI service and quite probably the Enterprise JPA and JTA services as well.

If you buy into Big OSGi Servers – like WebSphere – then it's quite likely that all of these will be present and Just Work™. But if you're trying to kick start a project in Felix or Equinox (or Knopflerfish or ProSys or …) then knowing which the magic set of bundles required is the key.

In an ideal world, these bundles would already be grouped together and work in an out-of-the-box package. The fact that we have so many bundles to pull together – assuming you can remember the names – is one of the reasons why Enterprise OSGi isn't as used as it could be.

For Enterprise OSGi to be successful, it needs to be as easy as when the likes of Tomcat servers provide a JNDI mapping for your database, and can surface that to a Servlet looking up a jdbc/DataSource. Ideally, this wouldn't need code changes to work for non-OSGi code, in order to allow the migration of existing JPA-enabled persistence units and databases configured externally to the bundles that ultimately get wired to them. Anything more complex and developers are likely to shy away from using OSGi and be stuck with Hibernate and Tomcat through ease of use alone.

The Omega Problem was coined at the OSGi Community Event 2011. It uses a greek letter for irony, but also because it fits with the ΩSGi name as well. Finally, is a nod to the footnote in The Last Continent, Page 74, which can be seen here, and is a parody of the Mad Lib Thriller Title genre. There's even a site which helps you make you own.