The editors at SD Times have proclaimed that OSGi is too complex. Unfortunately, they miss the mark, and the following statement taken from the article is misleading.
We believe that OSGi, rather than simplifying server application development, has actually made it more complex, and there aren’t sufficient benefits to justify the added complexity.
This statement should have been tempered with context. It is not universally applicable, though is made to sound as if it were. OSGi may face challenges, but complexity of the OSGi framework is not one of the long-term inhibitors to adoption.
Technology Adoption Lifecycle
All technology goes through various phases of adoption. A lack of platform support and tooling may be inhibiting adoption today, but that is today’s problem, and one that is being dealt with. And there is a stark difference between complexity brought on by lack of tooling and platform support versus complexity associated with an ill-conceived idea. OSGi suffers today from lack of enterprise-class tooling and platform support. OSGi is not an ill-conceived idea.
Whenever an organization adopts a new technology, they’ll undoubtedly face some degree of initial complexity. New technology takes time to learn. As the innovators and early adopters continue to use OSGi, tooling is going to get better and developing modular applications using OSGi is going to get easier.
The question you must answer is whether the pain of adoption today is worth the gain of a modular architecture. There are many factors to consider when answering this question, but as the technology matures, the question will be easier to answer. As I’ve alluded to, other factors that have little to do with OSGi’s technical benefits will likely determine if it’s is able to cross the chasm.
Long Term Value
But the article’s biggest flaw is in stating:
And what’s the benefit again? Enterprise developers have written many, many server-side Java applications without using OSGi.
It’s important to understand its value over time. Let me pose some simple questions.
- Is Spring too complex? It is far easier to create an application with concrete class references than it is to use dependency injection and abstractions.
- Is Hibernate too complex? It is far easier to use JDBC than it is an ORM framework.
- Is unit testing too costly? It is far easier to forego unit testing than it is to create a robust suite of tests.
Yet each contribute to more flexible software systems, and in that, there is significant benefit. So it is with OSGi and modularity, as well.
Leveraging OSGi to design modular applications will require us to learn new concepts, tools, and design paradigms, but there is no doubt that modularity has a tremendous upside. This makes the SD Times article paradoxical. OSGi does not increase complexity; the very benefit of modularity is that it helps us manage complexity.
More on Benefits
If you’re interested in exploring some of the benefits of modularity, you can start with the following:
- Architecture all the Way Down – The important role of modularity in architecture.
- Modularity by Example – A simple visual example illustrating the benefits of modularity.
- Agile Architecture, Lean Principles – Comparing my past thoughts on agile architecture to the Lean Principles of Software Development.
- Modularity & Architecture – A response to the entry on eliminating architecture.
- Eliminate Architecture – Discusses the goal of architecture and how to eliminate the impact and cost of change.
- Agile Architecture – My views on agile architecture and the natural architectural shifts that occur throughout the development lifecycle.
- Agile Architecture Requires Modularity – Discusses the role of modularity in agile architecture.
- On SOLID Principles and Modularity – Discusses where you need flexibility in architecture.
- Two Faces of Modularity and OSGi – Introduces the need for patterns and tools to help design more flexible and modular architecture.
- Reuse: Is the Dream Dead – Discusses the tension between reuse and use.
- Modularity Patterns – Presents 19 modularity patterns that help ease the tension between
reuse and use while making a software system easier to understand,
maintain, and extend.