Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

OSGi Perspectives

  • submit to reddit

It seems my recent post on OSGi has ruffled a few feathers. I’ve also received a few personal e-mails suggesting that I have missed the mark because OSGi is a significant component of the next generation application platform. Major vendors such as IBM are building OSGi into their products, and other leading edge vendors leverage OSGi as an enabling technology upon which their technical architecture is built.

My intent wasn’t to indict OSGi, so I was pretty surprised with the defensive responses I received…it’s a great technology and the benefits of modularity are real. As I’ve mentioned, and as many already know, I’m an ardent supporter of OSGi and modularity.

Based on the type of the feedback I’ve gotten on my previous post though, I’ve come to the realization that various constituencies have different perspectives that is contributing to the perception of OSGi adoption. Let me explain.

Differing Perspectives

In my post, The Two Faces of Modularity & OSGi, I talk about the runtime model and the development model. There are significant advantages to each. But interestingly, it’s possible for one to succeed while the other never sees widespread adoption. That is, OSGi might lie at the core of the next generation platform, but it doesn’t necessarily imply that enterprise developers will leverage it to build applications with a modular architecture.

Today, most vendors emphasize the runtime model, touting the cost savings, improved responsiveness, and flexibility of a dynamic platform. So I can understand why a lot of folks have reached out to explain to me the error of my ways. From their perspective, OSGi is flourishing.

An excellent example is the Eclipse platform, which released Eclipse 3.0 in June of 2004. However, I’d wager that only a fraction of Java developers using the Eclipse IDE know that OSGi is the major enabling technology upon which Eclipse is built. Instead, they use Eclipse, install plug-ins, but know very little about the underpinnings of the platform.

From a development perspective I’m incredibly interested in the benefits of modular architecture, and I want tools that reduce the accidental complexity of the development model. However, these tools don’t exist today, and developing enterprise server-side Java software applications leveraging OSGi is painful. So while vendors are leveraging OSGi for various platform benefits, as long as they encourage the traditional deployment model and the dearth of tools persist, enterprise developers will not use OSGi to build applications with a modular architecture. We don’t have it today, and we won’t see it in the future until this changes.

Parting Thoughts

I do believe that OSGI has the potential to be a major component of the next generation application platform. Though there are no guarantees, and I still have concerns. Let’s take SpringSource as an example. After seeing almost zero adoption of dm Server, they donated it to the Eclipse Foundation. And the recent VMForce announcement makes nary a mention of OSGi. Instead, tc Server provides the execution environment. So while some might argue that the runtime platform benefits of OSGi are real, there is a far more significant trend called the cloud that provides many of the same advantages. And the cloud certainly doesn’t need OSGi. Though OSGi could thrive in the cloud.

I’m also not convinced that the benefits of modularity will be realized by enterprise development teams. Will enterprise developers leverage OSGi and modularity as a core component of next generation architecture? I hope so, but I don’t believe it’s the slam dunk that many believe it is. Modularity is important. The benefits are real. It helps teams overcome a serious challenge when developing large enterprise software systems. But we need more developer advocacy surrounding OSGi and the benefits of modular architecture. Software is a fashion industry, and we must attach modularity to something trendy and more aggressively advocate adoption.

It is what it is. And unfortunately, that’s just the way it is.


Published at DZone with permission of its author, Kirk Knoernschild.


Mitch Pronschinske replied on Thu, 2010/04/29 - 8:48am

Very educational read.  Thanks Kirk!
Now I'm interested in knowing what those same advantages are that the cloud provides when compared to an OSGi runtime, and how OSGi could flourish in the cloud.

Peter Kriens replied on Thu, 2010/04/29 - 11:07am

See if I can comment this time ... last time I decided to write a blog because the comment did not make it:

 I fully share your perspective that the greatest problem is perspective, I meet too many people that their world is the world. Yes, there are other developers than "enterprise app" developers.

I think the issue with OSGi adoption in fashion oriented web application market is not yet happening because that market is very mature. There are lots of very good tools out there and OSGi as a newcomer in that market has not much support yet, worse, it works badly with a number of (arguably bad for modularity) patterns that are pervasive in that market. I actually expect that many people will be happy with the WAR model for years to come. However, most applications get more complex and larger. Application server vendors have huge amounts of code to handle and OSGi was the logical answer. Many applications will meet the same fate that the existing technology is not sufficient to handle the complexity. OSGi is then currently the only answer. But hey, don't use an 18 wheeler when you can transport your stuff in a minivan ... It just does not make sense.

OSGi is a very solid foundation for modular software, better than anything else I know. For what it does it is incredibly simple. Maven is working hard on creating a build tool that is based on this foundation.Neil Bartlett works on a very powerful Eclipse based tool has an offline build included. Eclipse is doing a lot of thinking how to improve their PDE. Tooling will be largely solved in the next two years.

However, the biggest gain for small to medium web applications will come when we get components, sofftware ICs as Brad Cox called them. OSGi is the only popular and industrially technology that enables robust Java components based on service oriented programming. I strongly believe that software will be simplified if we can reuse highly cohesive components. Partly from a marketplace, but mostly from components built in-house. The biggest gain I see at my customers from using OSGi is how they can parallelize the development work because services are such an excellent design concept.

I feel that today we have focused in the OSGi Alliance on solving some really hard problems and I also think we have been quite succesful in finding elegant solutions with a small footprint. We've proven that it works in very, very, large applications like Eclipse, Websphere, and so many systems at customers which I cannot discuss here. Yes, one of the next frontiers is to make OSGi easier to use for the web app developers. The solid foundation is there, so stop whining and help us create the tools, books, and tutorials that will make OSGi palatable in those markets. :-)

Vladimir Vivien replied on Thu, 2010/04/29 - 12:14pm

Kirk I enjoy your series on modularity (as it is one my interests I like OSGi as a substrate to create modular system software. However, I never thought the OSGi abstraction should be directly exposed to all types of developers. The idea of using OSGi as a universal abstraction for all module domains troubles me. It creates gaps that require OSGi to become bloated and a lost of focus on what it was intended to be in the first place.

To me, OSGi is a system tool and should be used by system developers creating frameworks, API's, and other low-level type development. Vendors and system developers should (to a certain extent) hide the intricacies of OSGi and expose its functionalities in user-friendly APIs. I like what SpringSource did with dm by letting developers create OSGi service using POJO's. Developers understand POJO's and that approach works well. Another approach is to use of OSGi as a plugin mechanism for extensible software (witness Java-based SIP communicator).

However, the abstraction mismatch widens when we want OSGi to scale to other modularity models. For instance OSGi does not fit well with other modular abstractions such as Web ARchives (WAR). The problem there is that WAR have its own execution context that does not map directly to OSGi's execution context. To make this work we have seen all sorts of prescriptions and best practices, etc, all in hope of making WARs work as OSGi bundles or load OSGi Bundles from WARS, and so forth. None, however, offers a compelling enough reason for enterprise developers to steer their big, bloated, WAR files toward the OSGi horizon.

WAR is one of the most popular modular abstraction for enterprise software distribution. It will take a frictionless integration between WAR and OSGi bundle before we see wide adoption in the enterprise. One solution I like is to have WAR context load the OSGi bundles similar to how the WAR context loads Spring application contexts. That way the WAR abstraction model remains intact requiring little change from the enterprise developer build and deploy their ware.

But this introduce the next issue with abstraction mismatch that of "granularity". Do you map a servlet to an OSGi Bundle? Do you map a servlet to an OSGi service? Or, do you map a URI to an OSGi service, etc, etc. I am waiting for the framework which solves these issues either by convention or through configuration. dm Server went far but try to hide the WAR and let too much OSGi-specific concerns sip out.

Peter Kriens replied on Mon, 2010/05/03 - 2:10am

@Vladimir I think calling a WAR a module is a bit of a stretch, though it encapsulates it provides no support for decoupling or maximizing the cohesiveness. The power of modularity is that the cohesiveness of the modules and low coupling makes modules independent of each other. The resulting benefit is a significant reduction in complexity and thus maintenance cost and a chance for reuse of components. WAR files provide global visibility to each of its constituents thereby not enforcing any boundaries making both cohesiveness and decoupling completely unenforced and thus not there in practice.

That said, WAR files are popular and are therefore we support them out of the box in OSGi R4.2 Enterprise release ...  Though I guess this will to help get enterprise programmers run on OSGi, I always think the biggest bang for your buck is not just running a WAR as a bundle. 90% of the value of OSGi is in the µService model. Alas, the µService model is not understood well by most people looking at OSGi but used well it is the pinnacle of decoupling, which is the hallmark of modularity. 

Your answer about the Servlet has a completely obvious answer in the OSGi world: its a service. You can contain many servlet services in a bundle, or just one. Your servlet can depend on any number of other services. You can make it by hand, you can use Blueprint, Spring DM, iPOJO, DS, etc. As an example, Apache Felix has a Http Service Whiteboard bundle that allows the following code to act as a servlet (using DS and bnd annotations):

class MyServlet extends HttpServlet {
  public void doGet( HttpServletRequest rq, HttpServletResponse rsp) {
     rsp.println("Hello World");

Placing this code in a bnd (ant, maven, bndtools) based bundle will make it available on any local web server on the /hello url (and you can also override it with Configuration Admin). I challenge anybody to give me a smaller and more decoupled programming model ...

The sad story is that most people look at OSGi for the super-duper class loading modularity, 99% of the reported problems with OSGi are closely related to programs that blindly assume there is global visibility (the antithesis of modularity).Using the µService model makes all those problems disappear because implementation classes stay inside their module, visibility is always local. Unfortunately, I see that precious few people really understand this model until they've really tried it. It reminds me very much of introducing Objects in the eighties: most experienced programmers dismissed objects because they saw the mechanics (pointers to descriptors=classes) and the jump tables (method dispatch/virtual tables) instead of realizing that OO provided the new design primitives of polymorphism and inheritance. Today, few programmers are aware of the mechanics of OO but we all understand objects, classes, inheritance, and polymorphism. Today µServices are in that place where objects were in the eighties. Clearly, objects were not very popular with mainstream structured programming developers either.

So the question remains (and I am struggling with this soul searching question) is do we work on making a  better Java EE moustrap (and get popular and rich) or do we continue with the quest to provide a significantly better programming model in the long run (and be bullied for not being compatible with mainstream ;-)? For me personally the answer lies in being as acceptable as possible but keep the the cross-hair focused on a better programming model because I think we're soooo close.

 Peter Kriens


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.