SOA World Magazine is running a well-written, informative article authored by Dave Chappell and Khandero Kand, on the Open Services Gateway Initiative (OSGi) that I highly recommend reading especially if you're a Java developer. While the piece is technical in nature it provides critical insight into some of the changes to application development that are gripping the future of middleware. What's particularly compelling about OSGi is the fact that it readily enables a programming model based on some of the core tenets of Service Oriented Architectures (SOA): dynamic flexibility, agility and modularity. Far too often the aforementioned are thrown about carelessly as buzzwords, loosely interpreted to sell a branded product or service. However, in the case of OSGi they are upheld down to the nuts and bolts of enterprise systems, i.e. the construction of software.
As the article points out, the current generation of Java containers is not well suited to support a fully modular SOA pattern. As a result, the prospect of designing and implementing enterprise systems without introducing issues with cross-dependencies, dynamic loading and lifecycle management is certainly complicated. The emergence of an OSGi container is dead set on changing that reality by enabling universal middleware, an ambitious term to say the least, but one that aligns with the expansion of use of the OSGi specification beyond embedded devices. More than just a catchy phrase, the prospect of universal middleware is made real by an intersection between open standards and open source. And if it can build momentum within the context of an increasingly SOA driven world, look for open source middleware to benefit tremendously as a result.
In essence, OSGi is a step towards agile systems of application modules grouped by business functionality available through interface contracts between services. OSGi provides the component-oriented, container framework that is capable of hosting dynamic services that do not have to be registered programmatically while providing the means to track and react to changes in the lifecyle of a service. In anticipation of the realities rooted in dynamic lifecycle problem, the OSGi/Spring combination has emerged as a solution with Spring providing dependency injection and aspect-oriented programming (AOP). Formerly known as Spring OSGi but renamed Spring Dynamic Modules for OSGi, the pattern of extensibility and freeing developer hands/heads to tackle more complex issues that has characterized the growth of Spring since its early days, has taken root in similar ways. Enterprise developers seeking to further simplify application development have taken to this combination, contributing to the significant industry momentum behind OSGi over alternatives like JSR 277.
In a broad sense, OSGi is at the forefront of a movement towards platform agnostic services that are inherently modular in nature. The result? Container independent services that sit above underlying implementations of OSGi. This is another of level of abstraction meant to enable the service based architectures of tomorrow but also an opportunity for the current wave of open source enterprise technologies, i.e. J2EE application servers and ESB frameworks to establish more traction. If OSGi can standardize one approach to SOA from a Java perspective, the doorway for heterogeneous SOA arsenals over single vendor suites will open even more.
Once players like Oracle/BEA and IBM step to the forefront with OSGi containers, the prospect of creating services supported by a standardized, dynamic deployment framework across the nexus of closed and open source offerings will receive a drastic boost. At this point, developers will be afforded the option of writing with the framework instead of against a product-specific approach to enabling SOA...a tantalizingly real opportunity to take a step forward in the Java enterprise application development arena.