OSGi™ in the enterprise is here to stay. It's a done deal from the Java application server vendor perspective and there is a real ground swell of activity within numerous open source projects and growing interest from the ISV communities.

Anyone watching the blogsphere and JavaOne announcements will have seen the huge surge in posts and press releases around OSGi adoption over the last couple of months. Sun's announcement that GlassFish will adopt OSGi rather than their own proprietary component model rounds out the Java App Server world, with IBM, Oracle/BEA and Red Hat (JBoss) already publicly committing to and delivering products using OSGi. The most recent entrant to this space is SpringSource with the announcement of their S2AP OSGi runtime platform.

To date only a couple of the vendors have exposed the OSGi component model to the users, choosing instead to only take advantage of the OSGi internally within their own products. It is our understanding that all of them, except for JBoss, intend to take this next step and offer an OSGi runtime directly to developers.

SpringSource has, of course, also brought the use of OSGi directly in to the development community, with Spring Dynamic Modules (formerly Spring-OSGi) making it easy for developers to produce applications from OSGi bundles (components). This means that it's even easier for developers to become more productive by benefitting from the well documented OSGi capabilities such as code re-use, peer classloading, full component lifecycle (install, start, stop, update & uninstall) and multi-component version support.

Mapping OSGi onto Gartner's ‘hype cycle', it seems clear that OSGi in the enterprise is in the “Peak of Inflated Expectations” phase – and we can all see what comes next … the dreaded “Trough of Disillusionment”!

At Paremus, we have been working, since 2003, on our product, the Infiniflow Service Fabric, which enables developers, architects, operations and businesses themselves, to realize the compelling benefits of reduced development time, improved time to market and the massive cost savings that can be achieved from the composition of applications from re-usable components run across what is now fashionably referred to as a Cloud-style infrastructure. Specifically, we have been offering a distributed OSGi runtime since 2006, and we are really excited that our choice of OSGi was well placed and has achieved the industry-wide backing evident today.

Our experience with using OSGi to realize our vision of a flexible, scalable, distributed, commodity Service Fabric to support componentized applications, has, however, made us acutely aware of a significant impediment, and challenge, that no-one else appears to have embraced – and we believe that this will be one of the factors that leads OSGi in the enterprise from the “Peak” into the “Trough”.

A brief history of OSGi and its move in to the Enterprise

OSGi is a mature standard, originally starting out as JSR-8, and resulting in the formation of the OSGi Alliance in 1999. OSGi was initially used in embedded solutions (such as smart homes, set top boxes, car engine management systems and mobile phones), and it has achieved significant adoption in these consumer markets.

In 2004 Eclipse adopted OSGi as its component model, and they produced Equinox, an OSGI Service Platform that provides the foundation for Eclipse. As a result, anyone using Eclipse from 2004 onwards has automatically been using OSGi. This seeded interest in OSGi in the enterprise software world.

As a side note, if you are familiar with Eclipse, you will know that you sometimes have to restart the IDE. This is not a failing of OSGi but instead is a hangover from its pre-OSGi days, as Eclipse doesn't yet take full advantage of the hot-swappable capabilities provided by OSGi.

This interest grew significantly, resulting in the establishment of the OSGi Enterprise Expert Group (EEG) within the OSGi Alliance in 2006. The EEG is chartered to define the technical requirements and specifications to tailor and extend the OSGi Service Platform to address use cases found in enterprise business scenarios. Members of the OSGi EEG include IBM, Oracle/BEA, Red Hat, Siemens, SAP, Iona and SpringSource.

Paremus has been active with the EEG, and has contributed two RFPs which have been taken forward as RFCs to be included in the next release of the standard.

It's great for businesses – enabling the realization of significant cost savings through component re-use, and also increased responsiveness to customers and the market in general with huge reductions in the time to market for new application-based initiatives.

Developers' lives get more rewarding as they can focus on the exciting challenges rather than being bogged down with reproducing the same old mundane functionality for each application and system.

Architects benefit as they can build systems from a set of components, making it easier to review existing components and identify those that need to be built from scratch. Even more importantly, the systems they produce become living, evolvable solutions rather than rigid, hard wired, point solutions that are difficult to change once delivered.

Heck, even the vendors benefit, making it easier for them to deliver more lightweight solutions and then add patches and upgrades to their products without interrupting their operation.

Hold on! We're heading for the Trough?

What about Operations? Spare a thought for these guys - the recipients of the code and systems that get built. As we all know, their task is to operate these systems for the business, often on a 24x7 basis. They are already under significant pressure to keep all the ‘plates spinning' within the corporate data centers. The IT complexity they have to deal with is already out of control, a root cause of their need to have ever growing armies of people just to keep the lights on.

So how do you think Operations will respond when you explain that instead of the seven elements that used to make up one of their systems, you have decomposed this and it's now made up of 70 different software components? Multiply this effect across the 10s, 100s or 1000s of systems that they are running on a daily basis and ... aarghh??

The need for a Model-Driven architecture

The benefits of OSGi are extremely compelling, but when used in isolation it's going to exponentially increase operational complexity within enterprises. Managing 10's or 100's of OSGi bundles in a single app server or JVM will be very hard, but consider the impact when you want to run these enterprise scale, across many app servers and in multiple large distributed systems. It will quickly become unmanageable and, we predict, will lead many people to become disillusioned with the technology.

With a background in designing and operating large enterprise applications and systems, Paremus recognized this issue very early on, and in addition to adopting OSGi technology, we ensured that Infiniflow also adopted a model-driven architecture approach based on the SCA standard. This model-driven architecture, the blueprint or recipe for your applications and systems, removes this potential explosion in operational complexity and allows the enterprise to make use of OSGi in a meaningful and productive manner.

With this approach, each application or system is ‘modeled' in a document that describes the business logic, middleware, runtime requirements and SLA policies required for its successful operation. Each model contains a list of the required OSGi components (including quantities and version numbers), details of how the components should be wired together using SCA bindings, and the minimum server specification required to run each component, such as chipset, operating system, memory capability or external 'gateway' functionality (e.g. database access). The model defines the intended runtime status of each application, something we refer to as the “Target State”.

against the model and changing its target state. The Infiniflow Service Fabric automatically responds to these changes, with no need for human intervention, driving the runtime state in to convergence with the model target state. As a result, the operations team is now abstracted from the inherent complexities of managing 100's or 1000's of application components within the distributed enterprise data center, and can control the entire application environment by simply managing the model and allowing Infiniflow to do the rest.

In addition to simplifying the operation of new and existing applications, the model-driven approach adopted by Infiniflow means that the recovery and resilience of applications and systems is also automated. By constantly monitoring the actual runtime state of an application or system and comparing it with the model, Infiniflow is able to detect changes in the runtime state caused by resource failure, and then automatically re-provision and wire in the missing components to return the runtime state to the target state.

Of course to achieve the full automation of this across a distributed environment requires many other sophisticated capabilities including provisioning, self-healing behaviors, optimization and management, but these shall be the topic of future articles.

In summary

OSGi technology is here to stay and has already started to revolutionize the enterprise software world from an end-user, developer, ISV and vendor perspective. There are real cost and productivity benefits to be achieved from using OSGi today and you should start, if you haven't already, considering how you can take advantage of these by introducing OSGi in to your enterprise.

If you want to ‘bridge' the Trough of Disillusionment, then you must not look at OSGi in isolation. You must balance the developer and architects benefits of adopting OSGi by combining it with a model-driven architecture to address the needs of operations, and avoid delivering them a ticking time bomb of complexity.

Infiniflow offers all of this today, and we are working with a number of interesting and well known companies who are building their next generation enterprise architectures in this way.

If you want to join them and explore what we can do for you then please get in touch, register for a download of our commercial evaluation or take a look at our open source project Newton, which provides the foundations of the Infiniflow product.

If you can't wait to find out more then please take a look at our website, visit our webinar archive or send me an email.

Back to newsletter

Footnote:

See the recent JavaOne ‘08 Redmonk podcast where Ian Skerrett from Eclipse Foundation confirms this. Fast forward to the 15 minutes 14 seconds section of the podcast for this information. http://media.libsyn.com/media/redmonk/redmonk47.mp3

Back to article