OSGi and Modular Java Applications
What is Modular Application?
In simple words, an application that is divided into many independent/isolated functional or non-functional modules/components (user interface or business logic) is a modular application. Modules can be installed and uninstalled dynamically from application’s core framework. When a module is installed, the application serves features/functionalities available in that module. Similarly, when a module is uninstalled from application, certain features/functionalities from removed module will also be removed from application without affecting rest of the application and its functionality.
“Eclipse Editor” is a well-known Java editor and it is a very good example of modular application. Whenever we need a feature, we install appropriate plug-in (i.e. module) and that feature is available in our eclipse. We can also uninstall a plug-in if we don’t need specific feature, uninstalling a plug-in will only remove a specific feature from eclipse without affecting other plug-ins or editor.
Modular applications are more flexible and extendable as compared to traditional application and the concept of modularization can be applied to wide range of applications.
Benefits of Modular Application
You are probably already building a well-architected application using assemblies, interfaces, and classes, and employing good object-oriented design principles. Even so, unless great care is taken, your application design may still be "monolithic" (where all the functionality is implemented in a tightly coupled way within the application), which can make the application difficult to develop, test, extend, and maintain.
The modular application approach, on the other hand, can help you to identify the large scale functional areas of your application and allow you to develop and test that functionality independently. This can make development and testing easier, but it can also make your application more flexible and easier to extend in the future. The benefit of the modular approach is that it can make your overall application architecture more flexible and maintainable because it allows you to break your application into manageable pieces. Each piece encapsulates specific functionality, and each piece is integrated through clear but loosely coupled communication channels.
OSGi, JBoss Modules, JSF2 & CDI are some example technologies for developing modular Java applications. OSGi is the most popular technology with clear specification and we can use it as an underlying framework for developing “Modular Java Applications” (web as well as desktop). Eclipse, GlassFish, Apache Sling, DataNucleus, Adobe CQ, Atlassian Confluence and JIRA are some well-known examples that uses OSGi framework for modularization.
What is OSGi?
OSGi (Open Services Gateway initiative) is a specification. The core of the OSGi specification defines a component and service model for Java. The components and services can be dynamically activated, de-activated, updated and uninstalled.
A very practical advantage of OSGi is that every bundle must define its exported Java packages and its required dependencies. This way you can effectively control the provided API and the dependencies of your plug-ins/bundles.
The OSGi has a layered model that is depicted in the following figure.
The following list contains a short definition of the terms:
• Bundles - Bundles are the OSGi components made by the developers. From technical point of view bundles are jar files which have a bit extended META-INF/MANIFEST.MF file and OSGI-INF.
• Services - The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java objects.
• Life-Cycle - The API to install, start, stop, update, and uninstall bundles.
• Modules - The layer that defines how a bundle can import and export code.
• Security - The layer that handles the security aspects.
• Execution Environment - Defines what methods and classes are available in a specific platform.
OSGi has several implementations, for example Equinox (used by eclipse IDE), Knopflerfish OSGi or Apache Felix. Core concept of OSGi remains same across all implementation only certain services and features vary from one implementation to another.
We’ll take an example use case to see how OSGi can be used to develop a “Modular Java Application”. A modular application itself is composed of various loosely coupled bundles/plugin-ins, every bundle that has been developed using OSGi and is being used by application will show up in the “Bundles” section of Figure 1.
Benefits of OSGi
1. Reduced Complexity - Developing with OSGi technology means developing bundles: the OSGi components. Bundles are modules. They hide their internals from other bundles and communicate through well-defined services.
2. Reuse - The OSGi component model makes it very easy to use many third party components in an application.
3. Dynamic Updates - The OSGi component model is a dynamic model. Bundles can be installed, started, stopped, updated, and uninstalled without bringing down the whole system.
4. Adaptive - The OSGi component model is designed from the ground up to allow the mixing and matching of components. This requires that the dependencies of components need to be specified and it requires components to live in an environment where their optional dependencies are not always available. The OSGi service registry is a dynamic registry where bundles can register, get, and listen to services. This dynamic service model allows bundles to find out what capabilities are available on the system and adapt the functionality they can provide.
5. Transparency - Bundles and services are first class citizens in the OSGi environment. The management API provides access to the internal state of a bundle as well as how it is connected to other bundles.
6. Supported by Key Companies - OSGi counts some of the largest computing companies from a diverse set of industries as its members. Members are from: Oracle, IBM, Samsung, Nokia, Progress, Motorola, NTT, Siemens, Hitachi, Deutsche Telekom, Redhat, Ericsson, and many more.
Disadvantages of OSGi
1. Every dependency/jar/bundle that we want to use in OSGi container must include OSGi META information for exported services and packages. E.g. If we want to use write a plug-in for accessing SOAP web services using apache axis, then we have make sure that the axis.jar is OSGi enabled (contains OSGI-INF along with META-INF) else we cannot use it inside OSGi container.
2. Cannot use traditional/existing J2EE infrastructure & concepts. Everything in OSGi is a module/plug-in; even a web application (WAR) is deployed inside OSGi container (not on a web server) as a bundle and exposed to end users using OSGi HTTP Service Bridge.
3. OSGi is useful while building modular applications but, this is not for free. It is rather a heavy standard which may disallow you to do some things and force you to do the things in “The OSGi way”.
Use Case
Let’s say, we are developing a banking software product and that product will be used by various countries around the globe. Since it is a banking application we have to consider some facts, e.g.:
1) Taxation rules that varies from country to country.
2) Bank policies with in a country may vary from bank to bank.
3) Customer from different countries may ask for different look and feel of application.
4) Some paid features that are only available in premium version of product.
If we develop this application using a traditional approach, we have to maintain a separate code base for individual customers/countries and lot of things gets replicated in various code bases. Or, a single code base with lots of “ifs” and “programmatic conditions” to enable/disable features based on customer, which not a good practice.
How can OSGi help us to develop this application? To develop an OSGi application we have to divide our application mainly in two parts:
1) Core Application Bundle This is the core part of application that manages loading/unloading of various plug-in(s), provides access to application’s infrastructure (e.g. database), glue various bundles together. This part of application does not contain any business logic, user interface or customer specific implementation.
2) Modules (plug-ins) Modules are smaller building blocks that can be dynamically added or removed from application as and when required. Each module is responsible for specific features/functionality. In our case we’ll have plug-ins/modules for country/customer specific requirements:
a) Taxation
b) Banking policies
c) User interface
d) Premium features
Below diagram shows a very high level structure of banking application running inside an OSGi container and bundles associated with banking application.
Bundles can come and go dynamically as and when required. E.g. If we want to remove a feature e.g. premium features from our banking application, we just need to uninstall the “premium feature” bundle from OSGi container and OSGi container will take care of removing all services, UI and logic related to premium functionality. Similarly, if want to upgrade a classic version of product to premium version, then we just need to add “premium feature” bundle in OSGi container. We don’t need to re-build the complete application; OSGi bundles can be installed and uninstalled dynamically.
Conclusion
OSGi is a great framework for developing modular applications and we have witnessed many successful products around us developed using OSGi. OSGi is in market from almost last 10+ years but, it was not popular among developers. Recently, OSGi has picked up momentum in developer and business stake holder’s community.
Initially, OSGi may look complex and expensive because of learning curve, inadequate availability of experienced OSGi developers and time required during design phase of application to break down everything into smaller functional units (plug-ins). But, in long term OSGi will pay off the initial investment. In today’s fast moving world with constantly changing business requirements everyone want to reduce the time to hit market and who’d like to change majority of application when application can adapt quickly by installing/uninstalling modules.
Any framework or technology cannot be set as a default development standard for all applications. Every application has different requirement therefore, we need to think and glue various technologies together to come up with an optimized solution. OSGi has lots of potential and great future so; it’s worth considering it for development.
In simple words, an application that is divided into many independent/isolated functional or non-functional modules/components (user interface or business logic) is a modular application. Modules can be installed and uninstalled dynamically from application’s core framework. When a module is installed, the application serves features/functionalities available in that module. Similarly, when a module is uninstalled from application, certain features/functionalities from removed module will also be removed from application without affecting rest of the application and its functionality.
“Eclipse Editor” is a well-known Java editor and it is a very good example of modular application. Whenever we need a feature, we install appropriate plug-in (i.e. module) and that feature is available in our eclipse. We can also uninstall a plug-in if we don’t need specific feature, uninstalling a plug-in will only remove a specific feature from eclipse without affecting other plug-ins or editor.
Modular applications are more flexible and extendable as compared to traditional application and the concept of modularization can be applied to wide range of applications.
Benefits of Modular Application
You are probably already building a well-architected application using assemblies, interfaces, and classes, and employing good object-oriented design principles. Even so, unless great care is taken, your application design may still be "monolithic" (where all the functionality is implemented in a tightly coupled way within the application), which can make the application difficult to develop, test, extend, and maintain.
The modular application approach, on the other hand, can help you to identify the large scale functional areas of your application and allow you to develop and test that functionality independently. This can make development and testing easier, but it can also make your application more flexible and easier to extend in the future. The benefit of the modular approach is that it can make your overall application architecture more flexible and maintainable because it allows you to break your application into manageable pieces. Each piece encapsulates specific functionality, and each piece is integrated through clear but loosely coupled communication channels.
OSGi, JBoss Modules, JSF2 & CDI are some example technologies for developing modular Java applications. OSGi is the most popular technology with clear specification and we can use it as an underlying framework for developing “Modular Java Applications” (web as well as desktop). Eclipse, GlassFish, Apache Sling, DataNucleus, Adobe CQ, Atlassian Confluence and JIRA are some well-known examples that uses OSGi framework for modularization.
What is OSGi?
OSGi (Open Services Gateway initiative) is a specification. The core of the OSGi specification defines a component and service model for Java. The components and services can be dynamically activated, de-activated, updated and uninstalled.
A very practical advantage of OSGi is that every bundle must define its exported Java packages and its required dependencies. This way you can effectively control the provided API and the dependencies of your plug-ins/bundles.
The OSGi has a layered model that is depicted in the following figure.
Figure 1: OSGi Building Blocks
The following list contains a short definition of the terms:
• Bundles - Bundles are the OSGi components made by the developers. From technical point of view bundles are jar files which have a bit extended META-INF/MANIFEST.MF file and OSGI-INF.
• Services - The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java objects.
• Life-Cycle - The API to install, start, stop, update, and uninstall bundles.
• Modules - The layer that defines how a bundle can import and export code.
• Security - The layer that handles the security aspects.
• Execution Environment - Defines what methods and classes are available in a specific platform.
OSGi has several implementations, for example Equinox (used by eclipse IDE), Knopflerfish OSGi or Apache Felix. Core concept of OSGi remains same across all implementation only certain services and features vary from one implementation to another.
We’ll take an example use case to see how OSGi can be used to develop a “Modular Java Application”. A modular application itself is composed of various loosely coupled bundles/plugin-ins, every bundle that has been developed using OSGi and is being used by application will show up in the “Bundles” section of Figure 1.
Benefits of OSGi
1. Reduced Complexity - Developing with OSGi technology means developing bundles: the OSGi components. Bundles are modules. They hide their internals from other bundles and communicate through well-defined services.
2. Reuse - The OSGi component model makes it very easy to use many third party components in an application.
3. Dynamic Updates - The OSGi component model is a dynamic model. Bundles can be installed, started, stopped, updated, and uninstalled without bringing down the whole system.
4. Adaptive - The OSGi component model is designed from the ground up to allow the mixing and matching of components. This requires that the dependencies of components need to be specified and it requires components to live in an environment where their optional dependencies are not always available. The OSGi service registry is a dynamic registry where bundles can register, get, and listen to services. This dynamic service model allows bundles to find out what capabilities are available on the system and adapt the functionality they can provide.
5. Transparency - Bundles and services are first class citizens in the OSGi environment. The management API provides access to the internal state of a bundle as well as how it is connected to other bundles.
6. Supported by Key Companies - OSGi counts some of the largest computing companies from a diverse set of industries as its members. Members are from: Oracle, IBM, Samsung, Nokia, Progress, Motorola, NTT, Siemens, Hitachi, Deutsche Telekom, Redhat, Ericsson, and many more.
Disadvantages of OSGi
1. Every dependency/jar/bundle that we want to use in OSGi container must include OSGi META information for exported services and packages. E.g. If we want to use write a plug-in for accessing SOAP web services using apache axis, then we have make sure that the axis.jar is OSGi enabled (contains OSGI-INF along with META-INF) else we cannot use it inside OSGi container.
2. Cannot use traditional/existing J2EE infrastructure & concepts. Everything in OSGi is a module/plug-in; even a web application (WAR) is deployed inside OSGi container (not on a web server) as a bundle and exposed to end users using OSGi HTTP Service Bridge.
3. OSGi is useful while building modular applications but, this is not for free. It is rather a heavy standard which may disallow you to do some things and force you to do the things in “The OSGi way”.
Use Case
Let’s say, we are developing a banking software product and that product will be used by various countries around the globe. Since it is a banking application we have to consider some facts, e.g.:
1) Taxation rules that varies from country to country.
2) Bank policies with in a country may vary from bank to bank.
3) Customer from different countries may ask for different look and feel of application.
4) Some paid features that are only available in premium version of product.
If we develop this application using a traditional approach, we have to maintain a separate code base for individual customers/countries and lot of things gets replicated in various code bases. Or, a single code base with lots of “ifs” and “programmatic conditions” to enable/disable features based on customer, which not a good practice.
How can OSGi help us to develop this application? To develop an OSGi application we have to divide our application mainly in two parts:
1) Core Application Bundle This is the core part of application that manages loading/unloading of various plug-in(s), provides access to application’s infrastructure (e.g. database), glue various bundles together. This part of application does not contain any business logic, user interface or customer specific implementation.
2) Modules (plug-ins) Modules are smaller building blocks that can be dynamically added or removed from application as and when required. Each module is responsible for specific features/functionality. In our case we’ll have plug-ins/modules for country/customer specific requirements:
a) Taxation
b) Banking policies
c) User interface
d) Premium features
Below diagram shows a very high level structure of banking application running inside an OSGi container and bundles associated with banking application.
Figure 2: Banking Application inside OSGi Container
Bundles can come and go dynamically as and when required. E.g. If we want to remove a feature e.g. premium features from our banking application, we just need to uninstall the “premium feature” bundle from OSGi container and OSGi container will take care of removing all services, UI and logic related to premium functionality. Similarly, if want to upgrade a classic version of product to premium version, then we just need to add “premium feature” bundle in OSGi container. We don’t need to re-build the complete application; OSGi bundles can be installed and uninstalled dynamically.
Conclusion
OSGi is a great framework for developing modular applications and we have witnessed many successful products around us developed using OSGi. OSGi is in market from almost last 10+ years but, it was not popular among developers. Recently, OSGi has picked up momentum in developer and business stake holder’s community.
Initially, OSGi may look complex and expensive because of learning curve, inadequate availability of experienced OSGi developers and time required during design phase of application to break down everything into smaller functional units (plug-ins). But, in long term OSGi will pay off the initial investment. In today’s fast moving world with constantly changing business requirements everyone want to reduce the time to hit market and who’d like to change majority of application when application can adapt quickly by installing/uninstalling modules.
Any framework or technology cannot be set as a default development standard for all applications. Every application has different requirement therefore, we need to think and glue various technologies together to come up with an optimized solution. OSGi has lots of potential and great future so; it’s worth considering it for development.
Comments