OSGi in the Enterprise

Posted by Alex Blewitt on Nov 11, 2008

Sections

Development

Topics

Java

Tags

JBoss ,

OSGi ,

Spring Dynamic Modules ,

Spring ,

Java EE

Share |

With the recent announcement of GlassFish v3 “Prelude”, Sun's OSGi-based Java EE 6 server, the use of OSGi across the enterprise has grown to encompass almost all of the back-end servers. A recent press release by the OSGi alliance listed the vendors and the technology that uses OSGi:

• IBM's WebSphere
• Oracle's Weblogic
• Paramus' Infiniflow Service Fabric
• ProSyst's ModuleFusion
• Red Hat's JBoss
• SpringSource's SpringSource Application Platform
• Sun Microsystem's GlassFish Enterprise Server

Peter Kriens noted that Jonas, arguably the first OSGi-based JEE server, was not mentioned on the list because it is not an OSGi member. He also noted that SAP NetWeaver is moving towards OSGi in the future as well.

As previously covered by InfoQ, the main reason these systems are moving to OSGi is to enable greater modularity. This allows a system to be decomposed into more manageable (and testable) units, whilst at the same time providing greater re-use of the component libraries. At the moment, the big players (IBM, Oracle) are using OSGi internally and not exposing that directly to users of the application, but others (SpringSource) are building on the fact that the container itself, and not just the applications, are open to extension.

Projects built with Maven are also similarly componentised, leading some to wonder what OSGi adds on top of the modularisation aspect. There's two key differences between Maven's modularisation and OSGi's runtime:

1. Maven's dependencies are on specific artifacts; OSGi can import Java packages from arbitrary artifacts discovered at runtime
2. Maven's build-time nature means that it does not imply a level of runtime dynamic behaviour

Application servers like SpringSource's DM Server take advantage of OSGi's dynamic nature when deploying Spring beans inside an OSGi container, allowing services to be stopped and restarted at runtime. The Spring Dynamic Module framework handles the wiring and runtime under the covers transparently.

Open-source projects are also moving to OSGi. Spurred on by the Apache Felix OSGi server, other Apache projects are generating OSGi metadata in their builds or moving completely, like Apache Tuscany's recent move. For those open-source projects that don't create metadata at the source, a number of OSGi bundle repositories (SpringSource Enterprise Bundle Repository, OBR, Eclipse Orbit, Felix bundle repository etc.) exist to provide open-source Jars annotated with OSGi metadata.

As a result of the growth of OSGi, both web-based and back-end systems are being built on OSGi directly. Linked In's use of OSGi has been discussed on their engineering blog, and a copy of the presentation at the Colorado Software Summit 2008 is available. It's even possible to run OSGi services on Amazon EC2 and even on an iPhone.

Whether directly or indirectly, the chance of using OSGi in enterprise applications is growing higher. With the Spring framework becoming a de-facto standard for application development and the benefits of the Spring DM server, building dynamic, modular applications is where the industry is headed.

1. Back to top

   OSGi for mere mortals...

   by Mike Funk

   Alex,
   
   No doubt OSGi makes perfect sense for server vendors. But building an OSGi enterprise application, using Maven, Spring, Hibernate, JAXWS, JAXB and the like is damn near impossible for mere mortals. In comparison, building a standalone or web application, using the same technologies, is child's play. As I understand it, much of the pain lies with classloader issues between an OSGi container and 3rd party components.
   
   So when do you see developers being able to 'easily' build OSGi applications?
   
   Also, do you expect developers to adopt the OSGi service/registry programming model?
   
   Regards, Mike

   Reply

2. Back to top

   Re: OSGi for mere mortals...

   by Neil Ellis

   Hi Mike
   
   Why not take a look at Sigil - it's designed to take the pain out of OSGi development and is specifically targeted for Newton/Infiniflow but provides general OSGi development support. It's still pre-1.0 but should give you some ideas. The first wave of adding simplicity to OSGi is going to be in the form of tooling and this is one of the first tools tackling this properly - I'm sure it won't be the last.
   
   All the best
   
   Neil
   

   Reply

3. Back to top

   SAP and NetWeaver

   by Alex Blewitt

   I wrote about SAP in the above post - there's an interview with Fredrik Alstroemer discussing it in more detail here:
   
   www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/1...

   Reply

4. Back to top

   Re: OSGi for mere mortals...

   by Adam FitzGerald

   But building an OSGi enterprise application, using Maven, Spring, Hibernate, JAXWS, JAXB and the like is damn near impossible for mere mortals ... As I understand it, much of the pain lies with classloader issues between an OSGi container and 3rd party components.

   
   
   Mike, the complaints you list are very valid and that is commonly what happens when people try to naively glue together common OSGi implementations and enterprise libraries. The nuances here are substantial and the task of expressing appropriate OSGi meta data for common enterprise libraries can seem daunting. However, making OSGi accessible for mere mortals is exactly what SpringSource is doing.
   
   The SpringSource dm Server makes enterprise OSGi development straightforward for end users instead of vendors. There is a guide and sample code for modularizing existing web applications and making them ready for OSGi deployment. The SpringSource Enterprise Bundle Repository already contains over 400 common enterprise libraries that have been sanitized for use in OSGi deployments including most of the ones you mention.
   
   Give dm Server a try and while you may not transcend mortality, I'm sure you will feel that OSGi is within your grasp as an enterprise developer.
   
   Adam FitzGerald
   SpringSource

   Reply

5. Back to top

   Re: OSGi for mere mortals...

   by Rob Harrop

   Mike,
   
   You might want to take a look at SpringSource dm Server. We've done a lot of work to make OSGi for enterprise applications a reality. In particular, a lot of effort has been put into making traditional libraries like Hibernate 'just work' in real-life (i.e multi-bundle) scenarios.
   
   You should take a look at the Petclinic sample we created which shows EclipseLink, Commons DBCP, Spring, JSP and JSTL working in a very natural way in a multi-bundle application.
   
   To make life even easier, we've also created the dm Server tools as part of SpringSource Tool Suite. This makes rapid turnaround development with OSGi a reality for real enterprise applications.
   
   I'll disagree a little with Neil. I think that tools are very useful in making OSGi development easier, but I also think that, as with dm Server, the core programming model should be more easily accessible to developers with existing enterprise Java skills.
   
   Regards,
   
   Rob Harrop
   dm Server Lead Engineer
   SpringSource

   Reply

6. Back to top

   plugging in the concepts first

   by theo gough

   interestingly i began looking at OSGi initially purely to reuse the DS schema to describe artefacts in a component-based architecture i'm working with at the moment. i was working towards defining a 'component manifest' to help with publication and reuse of large volumes of artefacts. the OSGi DS schema (or something very close to it) is as 'good' as any other at containing the information relevant to design/build/assembly-time as the next manifest (pom, anyone?), and although adoption of OSGi runtime is probably a while off yet (in the example of the enterprise i'm talking about), i can at least realise some gains from producing the metadata during asset publication in the same way as alex notes is being done in many open source projects at this time.
   
   adoption in the enterprise will as with all approaches be as much dependent upon perception of skillset availability in the marketplace as with the technology's inherent positive/negatives at a given point in time. in the meantime, enterprises ought to look to see what can be gained from this maturing of the modular programming model from a perspective of application of the concepts even prior to full technology adoption.

   Reply

• Older >