Is OSGi Adoption Growing? An Interview with Kirk Knoernschild
Is OSGi Adoption Growing? An Interview with Kirk Knoernschild
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
Interest in OSGi has seen a steady increase over the years as the benefits of modularity drive its adoption. In a recent blog post, Kirk Knoernschild of the Burton Research Group found some clues that suggest OSGi adoption is increasing. DZone conducted an exclusive interview with Knoernschild to see if more companies are using OSGi and to understand the significance of increasing OSGi adoption.
DZone: What surveys and data have you seen that indicate the growing usage of OSGi?
Kirk Knoernschild: I don't have any quantifiable research that suggests OSGi adoption is increasing, only anecdotal evidence that it's use is growing. The OSGi survey I conducted this year elicited almost four times as many responses as last year. The indeed graph speaks for itself. And major platform vendors are baking OSGi into their products. In general, Java modularity is a hot topic today, with the entrenched OSGi framework, the work being done to modularize JDK7, and Jigsaw. While not everyone is in agreement on how we should bring modularity to the Java platform, there are a lot of folks behind the movement. It's only a matter of time before Java modularity is a mainstream technology that development teams will be able to leverage to modularize their own applications. It's time is overdue. With the increasing complexity of enterprise applications, modularity is an important intermediary technology that's going to help us manage this complexity. I talked a little bit about this in my blog post on Turtles and Architecture. We need modularity!
DZone: What do you think is driving the adoption of OSGi?
Kirk: The benefits of modularity is what's driving OSGi. Examples of these benefits include plug-in architecture and dynamic deployments, easier understanding of complex applications, and increased reuse. Though I'm a little leery of touting reuse as a benefit of any technology, because reuse is really a product of how we design our applications, not something a technology can give us. Take OO and SOA for example. They promised reuse, but really failed to deliver in most cases. That's not the fault of the technology, but ours in how we used it. But I digress...that's a separate topic of discussion. Modularity is really all about taming complexity.
DZone: What are some of the major barriers preventing developers from using OSGi?
Kirk: There are a few barriers. First, today's widely used enterprise platforms don't expose OSGi to the enterprise developer, so they can't take advantage of the runtime benefits of modularity. There are platforms that do expose OSGi, from vendors such as Paremus and SpringSource, but these platforms aren't widely used today. Second, tools that help developers build applications on top of OSGi. Dealing with manifests and other OSGi artifacts can be cumbersome. Third, finding OSGi-ified bundles of 3rd party software can be difficult. SpringSource has done some really good things here with the SpringSource OSGi Bundle Repository. And finally, even after all these pieces come together, there is still going to exist the challenge of understanding how to modularize our applications.
DZone: What types of systems can be deployed within a OSGi runtime and which ones are the most popular to deploy within OSGi? Which types of systems benefit the most from OSGi?
Kirk: Big, complex enterprise software systems will benefit from OSGi because breaking the system into a set of modules gives us better ways to manage the applications. And by manage, I mean a few different things. Not just manage them at runtime, but also manage the development effort. Also, another example is an application that would benefit from dynamic deployment or a plug-in architecture. For instance, a mobile platform running OSGi would allow me to provision new bundles and extend existing applications with new functionality. Likewise, rich client applications would also benefit from OSGi because of similar benefits, like Eclipse.
DZone: What is the difference between using OSGi on the framework level and the platform level?
Kirk: When you say at the framework level, I'm assuming you mean that OSGi isn't baked into the platform but a framework that I use within my application. And there's a big difference, especially with web applications. Today's platforms don't expose OSGi to the developer, so using it is incredibly unwieldy, almost prohibitive. I'd have to include the OSGi framework with my application just like I would any other framework. And because OSGi uses a different class loading model than today's application servers, I have to bridge those two worlds. It requires me to do some pretty heavy lifting. When OSGi is baked into the platform, however, using it is second nature because the platform does the heavy lifting for us.
DZone: What steps need to be taken to implement OSGi and what are the unique benefits of doing so?
Kirk: The first step must be taken by the platform vendors who have to build support for OSGi into their products and then expose the virtues of modularity to the enterprise. Then, the benefit of using OSGi is that we can leverage the benefits of modularity. Since most of us don't design modular applications today, this benefit may not be obvious. In lieu of going into excruciating detail here, it'll help ease maintenance and management, increase architectural agility, and more. My blog post on Modularity by Example illustrates one example of how modularity helps understand the impact of change, which is a critical component of increasing architectural agility. But really, designing modular applications is almost a paradigmatic shift, similar to what we experienced when we transitioned from procedural languages to OO because there isn't a lot of knowledge about how to best modularize applications. Understanding the design paradigm is going to be significant.
DZone: Are modular architectures helping companies reduce IT costs?
Kirk: Probably not right now because most organizations aren't building modular applications. And I'm always hesitant to say that any technology helps companies reduce cost directly. It's so cliche. But the long-term benefits of modularity are significant enough that it will improve quality, ease maintenance, increase reuse, and a number of other things. In general, I think we can say that if a modular architecture achieves these benefits, then it helps reduce technical debt which will help us save some coin.
DZone: In what ways might OSGi need to improve before adoption becomes more widespread?
Kirk: Just look back at the major barriers that are preventing adoption to see what we need to improve before OSGi becomes widespread. And even after OSGi does become widespread, there'll be a learning curve as development teams discover how to use it most effectively.
DZone: What's the significance of OSGi (increased) adoption?
Kirk: Organizations are going to discover new ways to design and manage complex enterprise applications. They're going to realize the benefits of modularity. That's going to be significant.
DZone: Is there anything else significant about OSGi and its future that you think should be mentioned?
Kirk: Modularity is coming. Even though the platforms in use today by most enterprises don't directly support modularity, there are things that enterprise developers can do to start designing modular applications. When speaking at conferences, I often ask folks if they are consciously designing JAR files. By this I mean, the behavior of a JAR file and managing the relationships between JAR files. Not many development teams are doing this today, but they can.
Tools such as JarAnalyzer, an open source utility which I wrote a few years ago, helps identify the relationship between JAR files and generate metrics that inform the development team on the quality of their design. Other tools exist too, such as Structure 101 from Headway Software, that aren't reliant on OSGi and can help us design more modular applications. I have a proven collection of modularity design patterns that also offer guidance on designing modules and decreasing coupling between modules.
So while OSGi will bring support for modularity to the platform, there are things we can do today to realize the benefits of modularity, and it's really important to recognize this fact, and explore what we can do to take advantage of modularity right now. I've blogged extensively about many of these topics, so you might want to check out some of those entries to learn more about the benefits of modularity, how to design more modular applications, and what we can expect when platforms support modularity.
Opinions expressed by DZone contributors are their own.