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 the 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 the application, certain features/functionalities from the removed module will also be removed from the application without affecting the 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 the 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 a 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 a 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 use 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 a technical point of view, bundles are jar files that 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 on a specific platform.
OSGi has several implementations, for example, Equinox (used by eclipse IDE), Knopflerfish OSGi or Apache Felix. The core concept of OSGi remains the 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 the 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 any 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 the apache axis, then we have to 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 that 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 vary from country to country.
2) Bank policies within a country may vary from bank to bank.
3) Customers from different countries may ask for different looks and feel of the application.
4) Some paid features that are only available in the premium version of the product.
If we develop this application using a traditional approach, we have to maintain a separate code base for individual customers/countries and a lot of things get 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 the application that manages loading/unloading of the various plug-in(s), provides access to application’s infrastructure (e.g. database), glue various bundles together. This part of the 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 the 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
The 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 you want to upgrade a classic version of the product to a premium version, then we just need to add a “premium feature” bundle in the 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 the market for almost the last 10+ years but, it was not popular among developers. Recently, OSGi has picked up momentum in the developer and business stake holder’s community.
Initially, OSGi may look complex and expensive because of the learning curve, inadequate availability of experienced OSGi developers and time required during the design phase of application to break down everything into smaller functional units (plug-ins). But, in the long term, OSGi will pay off the initial investment. In today’s fast-moving world with constantly changing business requirements everyone wants to reduce the time to hit the market and who’d like to change the majority of the application when an 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 potentials and a great future so; it’s worth considering it for development.
Source: http://suryakand-shinde.blogspot.com/2013/02/osgi-and-modular-java-applications.html
No comments:
Post a Comment
If you have any doubts or questions, please let us know.