February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox
March 22 - 25 - Tutorial on Modular Architecture
June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture
July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.
Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29
The opinions expressed on this site are my own, and not necessarily those of my employer.
For years, OSGi technology has flourished in the embedded systems and networked devices market. Till now, it’s remained a relatively obscure technology for the enterprise developer. Now, in part thanks to Eclipse, OSGi is emerging as a viable and valuable technology in the enterprise.
In 2003, the Eclipse team began looking for ways to make Eclipse a more dynamic Rich Client Platform and increase the platform’s modularity. Eventually, the team settled on the OSGi framework as the run-time component model, codenamed the project Equinox, and in June of 2004 released Eclipse 3.0. This newest version of Eclipse sported a runtime model based on OSGi. OSGi was no longer a technology isolated to use in embedded software and networked devices, but had now become the foundation upon which all Eclipse plug-ins would be developed, and the platform upon which thousands of software developers would use the Eclipse IDE to develop software. Eclipse adoption of OSGi marked a significant milestone for the OSGi Alliance, as adoption by a major product and brand such as Eclipse thrust it into the spotlight for many commercial software companies. Today, several major vendors build on OSGi, and almost all application servers used within the enterprise currently support, or plan to support, OSGi. While OSGi has not yet made significant in-roads to the enterprise, server-side support for OSGi is going to facilitate adoption of OSGi in the enterprise. And this is where it gets interesting for the enterprise Java software developer.
OSGi is a dynamic module system for Java. There is quite a bit of literature discussing OSGi at the OSGi Alliance, specifically the OSGi Technology page. Instead of rehashing what’s already been said, I want to focus on how OSGi is going to influence positive change for the enterprise developer creating server-side software applications.
Let’s take a moment, digest exactly what OSGi entails, and examine what it means for the enterprise developer in the trenches. No longer need we emphasize development and deployment of individual web applications and portals. Instead, we develop enterprise software systems as a composition of software components that can be assembled dynamically to form a complete system. The challenge of inter-application communication is a non-issue, since individual components can expose resources that serve content to the user, and consume behavior exposed by other components. No longer need we redeploy an entire suite of enterprise software systems due to a behavioral change in a single .jar file. Instead, simply update the .jar on the OSGi platform.
Extending the software system to support new processes is as simple as deploying or redeploying only the necessary components, without any interruption to critical processes. An SOA built on web services is also assembled from the same software components by simply building a service protocol layer on top of the appropriate components. It’s possible to assemble a rich client application from the same software components. Additionally, it’s possible to allow separate components within an OSGi container to utilize the behavior of different versions of the same component.
Because component dependencies are explicitly stated, the component structure of the application is well understood. At the very least, this minimzes the risk of change as the ramification of change can be more accurately assessed. Since OSGi bundle collaboration is in-process, granularity of components can be established that allow teams to maximize component reuse without incurring performance degradation due to excessive inter-component collaboration. Overall, OSGi has eliminated many architectural challenges with enterprise software development, and has established more refined techniques for deploying and managing enterprise software.
When you add it all up, OSGi fills an important technology gap between SOA and object-oriented design on the Java platform. For some time, we’ve been able to build flexible and extensible class structures in Java. With technologies such as EJB (primarily Sessions Beans and Message Beans) and web services, we’ve had a service deployment model. But we’ve lacked a robust component model. Today, there are several server-side open source implementations of the OSGi platform, including Server-Side Equinox and Apache Felix, as well as several commercial implementations. The current development release of Spring-OSGi supports building Spring applications that run in an OSGi environment. In typical Spring fashion, Spring managed OSGi bundles eliminate dependencies to OSGi. The Java Open Application Server v. 5 (JOnAS) is designed with an OSGi based architecture. Even Sun is noticing as is evident through the ongoing saga of JSR-291 and JSR-277. And interest in OSGi doesn’t stop there, as a quick Google search reveals.
OSGi is a key technology filling an important void in enterprise software development. While OSGi adoption within the enterprise may be a year or three away, as the platform continues to gain momentum it’s going to offer significant benefits to enterprise software development teams.