Are there any Java PaaS solutions out there that offer OSGi containers as a service?
Google App Engine --> has their own GAE server which is modified Jetty
CloudBees --> has their own RUN#Cloud container which is modified Tomcat
OpenShift --> uses JBoss/Wildfly
??? --> uses, say, Karaf or Equinox
If not a full-blown PaaS, just a clusterable/scalable OSGi host. Google turned up nothing, so I'm assuming there isn't anything like this. Thanks in advance!
(In contrast to the other answers:) No, there is no OSGi-as-a-Service in the cloud, yet.
I am currently writing my master thesis about porting an OSGi application on a PaaS, so I did my own researches about PaaS and OSGi. I did not find any satisfying solution based on OSGi in the cloud (however I did find other solutions ;). The problem is that OSGi is pretty unpopular and the cloud is notoriously trendy.
As the other questions mentioned, OSGi is a Java library. So you could set it up pretty much everywhere where Java is supported. But that would be more a IaaS solution as a PaaS solution (which you seem to look for, as you are asking for OSGi-as-a-service). You would need to setup a OSGi framework on your own and you would have no support for deploying bundles. Which degenerates this solution pretty much. So no, there is no special cloud offer for OSGi, despite there are many for Java.
However, there is a nice book called Modular Cloud Apps with OSGi from Paul Baker and Bert Ertman published by O’Reilly. The book describes their PaaS-like solution to use OSGi in the cloud. The basically setup a repository of OSGi bundles, where they stored all their stuff. Then they created a cloud image, which only contains an empty OSGi framework/server (just like Apache Karaf, but they wrote their own tool called Apache ACE for what reason ever...). They were able to boot those images and as soon as the machine was up, they just deployed the bundles from their repository to the instance (via a web interface).
There is also a video of their demo on youtube: https://www.youtube.com/watch?v=oN3jYKOQ1Tk
I think this strategy is the best PaaS-like solution you could get. But - unfortunately - this is not supported by any cloud vendor out of the box. But you could set it up on (for exmaple) Amazon very easily.
EDIT
There also exists a Build Pack for Cloud Foundry to setup a Virgo server which can run OSGi apps: https://github.com/glyn/virgo-buildpack
Take a look at Gyrex. It's not a service yet but can be used to build you're own OSGi PaaS cluster. It uses Equinox, p2 for provisioning and Jetty.
http://eclipse.org/gyrex
Disclaimer: I'm a committer and heavy user of it.
There is a commercial provider of OSGi cloud services - Paremus. They have 2 cloud products - Nimble and Service Fabric. You might want to check them out. The Nimble product is available in a limited free edition for trial.
OSGi can be used on pretty much any cloud provider that offers Java support, since it is essentially just a Java library.
The exception to this would be Google App Engine, since they don't just modify Jetty, they modify Java itself and remove the ability to create threads and classloaders, both of which are required for full OSGi support.
OSGi is basically a Java library that can run on a virtual machine that has a JDK/JRE support. But remember one stuff, out of the box support is what you are looking for and you need to customize the PaaS you choose to run your app. I think to do this, you need to choose the provider that is easiest to configure and scale. Try out Jelastic. It is easiest of the lot to cinfigure and get started. Check their jar uploads, and I think it will suffice your needs.
Let me know what you think and if this answer is of any help.
Surya
I have a plan to reimplement one of my small but usefull applications with OSGI framework. I never used it, so I ask is it appropriate to use OSGI on small app and is it a big difference in speed or/and memory footprint when using such framework. Also if it is a good option I would ask what implementation is best for small applications.
thank you!
For modern computer systems, speed and memory footprint of OSGi are of no concern at all: remember that OSGi was developed for resource-constrained devices. The memory footprint is in the hundreds of kBs, and once the service resolution is done, the framework has no impact on the speed of your application (for instance, there are no proxies). In short, no worries at runtime.
I like the way a properly designed OSGi application cleans up the application's structure, by forcing you to think about your modules and services. I will stay away from all the benefits of modularization and service orientation here, just remember they apply just as well to small applications as to large. Hey, you might even start to find reusable components!
You will need to think about packaging and shipping your application: depending on your audience, you can get away with just shipping a bunch of bundles, using a shell script to get the system going (using e.g. Pax Runner), or you might need to invest in something a little more fancy, like nice application packaging with an icon.
I use karaf/iPOJO as an OSGi container to allow upgrading versions of libraries while the application is running.
However, for a small application which you can restart any time, I would keep things as simple as possible.
Today, OSGi has basically no overhead, the frameworks range from 350k to 1mb. In runtime, OSGi stays out of your way.
You should take a look at bndtools, it provides a very nice development environment for OSGi bundles including launching, debugging, and testing. You can easily switch between frameworks.
You can find bndtools in the Eclipse marketplace.
OSGi has still a "little" more overhead than regulare Java projects. I would instead rely on Maven modules, if you wanna have versioning.
If you choose the OSGi apporach take a look at the Eclipse plugin creation. This is based on Eclipse Equinox and can be applied to new projects fast by the wizzards Eclipse offers for creating new projects.
Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm currently starting a new app development. The app architect insists we use JBoss5 because its "better". Do anyone has a wider definition of "better" (if its the case)?
I have experience using Tomcat5 and 6 in large scale applications with big user loads and it handles pretty well (IMHO). Both would be running over a RedHat6 in identical hardware conditions (in case the implementation matters).
Thanks in advance
To say that any tool or framework is just 'better' is ridiculous. It always depends on the situation, architecture, etc. You don't necessarily want to use a hammer to drive a screw.
I wrote JBoss in Action, so I obviously like the JBoss technology, but I'll be the first to say that JBoss can be overkill in many situations. For example, for the last two sites I've developed, it made more sense to build with Grails and deploy on a standalone Tomcat instance.
Its a bit unfair to say that all you get when using JBoss is EJB and JMS. JBoss offers many services and features, including:
Servlet/JSP container
JNDI
EJB
JTA
clustering
caching
JMS
Datasource / Resource management
JMX integration
OSGi support
web services
portals
Web Beans (Seam)
Some administrative consoles
an IoC container
etc.
The thing that attracts many architects to JBoss is its flexibility. It uses a plugin architecture that allows you to add and remove services. As other have said, in uses Tomcat as its Servlet container, so you can literally whittle JBoss down to where it is practically just a Tomcat server. What is the benefit of doing this? Future proofing if you think that you're going to utilize other features of JBoss.
These services in JBoss come pre-integrated and strive to provide a consistent deployment model that minimizes your effort in writing application logic or configuration to integrate them yourself. That being said, other frameworks like Spring also do a great job of supporting a uniform ways of integrating many popular libraries and frameworks. But since they focus on integrating 3rd party libraries, the interoperability between services is up to you. Because JBoss is building the services and the integration platform, they spend time developing (and providing support) for interoperability.
Some questions to ask when making a choice are:
Are you going to use standard JavaEE architectural components like EJB?
BTW, EJB can be run in standalone Tomcat using the JBoss embedded container, so if EJB is all you're using, then you still don't have to use JBoss
Are you going to utilize Web Services, Portals, JMS?
Are you looking into building with Web Beans or Seam?
What deployment platforms (Tomcat, JBoss, etc) does your IT, support, and development staff currently use? If you are going to use something new, you will incur additional cost to learn the new platform.
If you're selling a product that customers will deploy, what impact will it have on the customers' IT organization.
Are you going to need paid support?
You can find support for Tomcat through many companies (including Red Hat I believe).
You'll need to compare the costs, because I don't think JBoss support is cheap, though I haven't looked up prices lately.
Will you need to do any sophisticated clustering?
JBoss has some wonderful clustering capabilities, and you'll probably get good clustering support through Red Hat. Though, for full disclosure, I've never done any complex clustering with any other frameworks to be able to compare.
Are you going to need advanced transaction management (distributed transactions, 2-phase commits, etc)
Not to sound like a shameless plug, but the first chapter of JBoss in Action is available for free on the Manning website. Though we don't do a direct comparison between JBoss and other applications servers and deployment environments in the chapter, we do talk about the architectural differences a bit, which is relevant to your question.
I'm currently starting a new app
development. The app architect insists
we use JBoss5 because it's "better". Do
anyone has a wider definition of
"better" (if its the case)?
Funny, because JBOSS uses Tomcat as its servlet/JSP engine.
Sounds like "better" means "supports EJBs and JMS", because Tomcat out of the box has neither.
But that's not an issue if your application doesn't use EJBs or JMS.
And if you do need them, you can add them to Tomcat with OpenEJB and RabbitMQ or ActiveMQ.
I'd ask your app arch when the last time they wrote something besides Power Point slides or UML documents. The response might surprise you.
JBoss is an Application Server while Tomcat is a Servlet container
So JBoss may be better than Tomcat in the sense it contains it, plus other components. That's it.
If you're not going to use those other components, you're wasting resources. If you need those other components then Tomcat is not enough.
It depends, probably your Architect has something else in mind.
I wonder what would he say if you ask him directly?
It's not better, it's just more. JBoss includes Tomcat.
As #duffymo points out, JBoss uses Tomcat for its web container so better makes not much sense if we compare equivalent things (i.e. Tomcat and the web container part of JBoss). And if you are not going to use JTA, EJBs, JMS, JMX, etc, there is no real advantage at using JBoss, especially during development (Tomcat is lighter and starts faster, this is often appreciated by development teams).
There are some cases where you could prefer JBoss for production though (I'm still assuming you're not using EJBs, etc):
The production team is trained or used to use JBoss in production, tools (deployment, monitoring, etc) are tailored for JBoss.
The company has a support contract for JBoss (although you can also get support for Tomcat).
But I'm not sure this is what the app architect meant. I would try to discuss this choice with the architect, maybe he has a rationale explanation. And if really JBoss has to be used in production, you can always use Tomcat or Jetty during development.
If you use JBoss, you can pay Jboss.org for support. But it is not the case with Tomcat.
This is true, however RedHat (who bought out Jboss.org) will require you to change to one of their supported versions of JBoss
JBoss is J2EE specification compliant, it supports J2EE specification very well, such as EJB, JTA,JMS, JNDI and etc. Tomcat is only a servlet container, although it also supports a bit J2ee specification. When you want to use J2EE component, you should consider JBoss first.
Forgot a point, JBoss supports JMX very well, especially in version 4.*. I have experienced a project, it doesn't have a web UI, JBoss is used just as a platform and EJB container to integrate all the standalone application on it use MBean.
I've read on Wikipedia and other sites about OSGi, but I don't really see the big picture. It says that it's a component-based platform, and that you can reload modules at runtime. Also the "practical example" given everywhere is the Eclipse Plugin Framework.
My questions are:
What is the clear and simple definition of OSGi?
What common problems does it solve?
By "common problems" I mean problems we face everyday, like "What can OSGi do for making our jobs more efficient/fun/simple?"
what benefits does OSGi's component system provide you? Well, Here is quite a list:
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. Hiding internals means more freedom to change later. This not only reduces the number of bugs, it also makes bundles simpler to develop because correctly sized bundles implement a piece of functionality through well defined interfaces. There is an interesting blog that describes what OSGi technology did for their development process.
Reuse - The OSGi component model makes it very easy to use many third party components in an application. An increasing number of open source projects provide their JARs ready made for OSGi. However, commercial libraries are also becoming available as ready made bundles.
Real World - The OSGi framework is dynamic. It can update bundles on the fly and services can come and go. Developers used to more traditional Java see this as a very problematic feature and fail to see the advantage. However, it turns out that the real world is highly dynamic and having dynamic services that can come and go makes the services a perfect match for many real world scenarios. For example, a service could model a device in the network. If the device is detected, the service is registered. If the device goes away, the service is unregistered. There are a surprising number of real world scenarios that match this dynamic service model. Applications can therefore reuse the powerful primitives of the service registry (register, get, list with an expressive filter language, and waiting for services to appear and disappear) in their own domain. This not only saves writing code, it also provides global visibility, debugging tools, and more functionality than would have implemented for a dedicated solution. Writing code in such a dynamic environment sounds like a nightmare, but fortunately, there are support classes and frameworks that take most, if not all, of the pain out of it.
Easy Deployment - The OSGi technology is not just a standard for components. It also specifies how components are installed and managed. This API has been used by many bundles to provide a management agent. This management agent can be as simple as a command shell, a TR-69 management protocol driver, OMA DM protocol driver, a cloud computing interface for Amazon's EC2, or an IBM Tivoli management system. The standardized management API makes it very easy to integrate OSGi technology in existing and future systems.
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. Many Java developers do not believe this can be done reliably and therefore initially do not use this in production. However, after using this in development for some time, most start to realize that it actually works and significantly reduces deployment times.
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. This makes code more flexible and resilient to changes.
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. For example, most frameworks provide a command shell that shows this internal state. Parts of the applications can be stopped to debug a certain problem, or diagnostic bundles can be brought in. Instead of staring at millions of lines of logging output and long reboot times, OSGi applications can often be debugged with a live command shell.
Versioning - OSGi technology solves JAR hell. JAR hell is the problem that library A works with library B;version=2, but library C can only work with B;version=3. In standard Java, you're out of luck. In the OSGi environment, all bundles are carefully versioned and only bundles that can collaborate are wired together in the same class space. This allows both bundle A and C to function with their own library. Though it is not advised to design systems with this versioning issue, it can be a life saver in some cases.
Simple - The OSGi API is surprisingly simple. The core API is only one package and less than 30 classes/interfaces. This core API is sufficient to write bundles, install them, start, stop, update, and uninstall them and includes all listener and security classes. There are very few APIs that provide so much functionality for so little API.
Small - The OSGi Release 4 Framework can be implemented in about a 300KB JAR file. This is a small overhead for the amount of functionality that is added to an application by including OSGi. OSGi therefore runs on a large range of devices: from very small, to small, to mainframes. It only asks for a minimal Java VM to run and adds very little on top of it.
Fast - One of the primary responsibilities of the OSGi framework is loading the classes from bundles. In traditional Java, the JARs are completely visible and placed on a linear list. Searching a class requires searching through this (often very long, 150 is not uncommon) list. In contrast, OSGi pre-wires bundles and knows for each bundle exactly which bundle provides the class. This lack of searching is a significant speed up factor at startup.
Lazy - Lazy in software is good and the OSGi technology has many mechanisms in place to do things only when they are really needed. For example, bundles can be started eagerly, but they can also be configured to only start when other bundles are using them. Services can be registered, but only created when they are used. The specifications have been optimized several times to allow for these kind of lazy scenarios that can save tremendous runtime costs.
Secure - Java has a very powerful fine grained security model at the bottom but it has turned out very hard to configure in practice. The result is that most secure Java applications are running with a binary choice: no security or very limited capabilities. The OSGi security model leverages the fine grained security model but improves the usability (as well as hardening the original model) by having the bundle developer specify the requested security details in an easily audited form while the operator of the environment remains fully in charge. Overall, OSGi likely provides one of the most secure application environments that is still usable short of hardware protected computing platforms.
Non Intrusive - Applications (bundles) in an OSGi environment are left to their own. They can use virtually any facility of the VM without the OSGi restricting them. Best practice in OSGi is to write Plain Old Java Objects and for this reason, there is no special interface required for OSGi services, even a Java String object can act as an OSGi service. This strategy makes application code easier to port to another environment.
Runs Everywhere - Well, that depends. The original goal of Java was to run anywhere. Obviously, it is not possible to run all code everywhere because the capabilities of the Java VMs differ. A VM in a mobile phone will likely not support the same libraries as an IBM mainframe running a banking application. There are two issue to take care of. First, the OSGi APIs should not use classes that are not available on all environments. Second, a bundle should not start if it contains code that is not available in the execution environment. Both of these issues have been taken care of in the OSGi specifications.
Source : www.osgi.org/Technology/WhyOSGi
I've found the following benefits from OSGi:
Each plugin is a versioned artifact that has its own classloader.
Each plugin depends on both specific jars that it contains and also other specific versioned plug-ins.
Because of the versioning and isolated classloaders, different versions of the same artifact can be loaded at the same time. If one component of your application relies on one version of a plug-in and another depends on another version, they both can be loaded at the same time.
With this, you can structure your application as a set of versioned plugin artifacts that are loaded on demand. Each plugin is a standalone component. Just as Maven helps you structure your build so it is repeatable and defined by a set of specific versions of artifacts it is created by, OSGi helps you do this at runtime.
I don't care too much about the hotplugability of OSGi modules (at least currently). It's more the enforced modularity. Not having millions of "public" classes available on the classpath at any time protects well from circular dependencies: You have to really think about your public interfaces - not just in terms of the java language construct "public", but in terms of your library/module: What (exactly) are the components, that you want to make available for others? What (exactly) are the interfaces (of other modules) you really need to implement your functionality?
It's nice, that hotplug comes with it, but I'd rather restart my usual applications than testing all combinations of hotplugability...
You can, analogically speaking, change the motor of your car without turning it off.
You can customize complex systems for the customers. See the power of Eclipse.
You can reuse entire components. Better than just objects.
You use a stable platform to develop component based Applications. The benefits of this are huge.
You can build Components with the black box concept. Other components don't need to know about hidden interfaces, them see just the published interfaces.
You can use in the same system several equal components, but in different releases, without compromise the application. OSGi solves the Jar Hell problem.
With OSGi you develop thinking to architect systems with CBD
There are a lot of benefits (I reminded just these now), available for everyone who uses Java.
edited for clarity. OSGi page gave a better simple answer than mine
A simple answer: An OSGi Service Platform provides a standardized, component-oriented computing environment for cooperating networked services. This architecture significantly reduces the overall complexity of building, maintaining and deploying applications.
The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring a restarts.
In a single application structure, say the Eclipse IDE, it's not a big deal to restart when you install a new plugin. Using the OSGi implementation completely, you should be able to add plugins at runtime, get the new functionality, but not have to restart eclipse at all.
Again, not a big deal for every day, small application use.
But, when you start to look at multi-computer, distributed application frameworks, that's where it starts to get interesting. When you have to have 100% uptime for critical systems, the capability to hotswap components or add new functionality at runtime is useful. Granted, there are capabilities for doing this now for the most part, but OSGi is trying to bundle everything into a nice little framework with common interfaces.
Does OSGi solve common problems, I'm not sure about that. I mean, it can, but the overhead may not be worth it for simpler problems. But it's something to consider when you are starting to deal with larger, networked, applications.
A Few Things that drive me nuts on OSGi:
1) The implentations and their context loaders have a lot of quirks to them, and can be somewhat async (We use felix inside of confluence). Compared to a pure spring (no DM) where [main] is pretty much running through everything sync.
2)Classes are not equal after a hot load. Say, for instance you have a tangosol cache layer on hibernate. It is filled with Fork.class, outside of the OSGi scope. You hotload a new jar, and Fork has not changed. Class[Fork] != Class[Fork]. It also appears during serialization, for the same underlying causes.
3)Clustering.
You can work around these things, but it is a major major pain, and makes your architecture look flawed.
And to those of you advertising the hotplugging.. OSGi's #1 Client? Eclipse. What does Eclipse do after loading the bundle?
It restarts.
OSGi makes your code throw NoClassDefFoundError and ClassNotFoundException for no apparent reason (most probably because you forgot to export a package in OSGi configuration file); since it has ClassLoaders it can make your class com.example.Foo fail to be cast to com.example.Foo since it's actually two different classes loaded by two different classloaders. It can make your Eclipse boot into an OSGi console after installing an Eclipse plugin.
For me, OSGi only added complexity (because it added one more mental model for me to grok), added annoyances because of exceptions; I never really needed the dynamicity it "offers". It was intrusive since it required OSGi bundle configuration for all modules; it was definitely not simple (in a larger project).
Because of my bad experience, I tend to stay away from that monster, thank you very much. I'd rather suffer from jar dependency hell, since that's way way more easily understandable than the classloader hell OSGi introduces.
I am yet to be a "fan" of OSGi...
I have been working with an enterprise application at Fortune 100 companies. Recently, the product we use has "upgraded" to an OSGi implementation.
starting local cba deployment...
[2/18/14 8:47:23:727 EST] 00000347 CheckForOasis
finally deployed and "the following bundles will be quiesced and then restarted"
[2/18/14 9:38:33:108 EST] 00000143 AriesApplicat I CWSAI0054I: As part of an update operation for application
51 minutes... each time code changes... The previous version (non-OSGi) would deploy in less than 5 minutes on older development machines.
on a machine with 16 gig ram and 40 free gig disk and Intel i5-3437U 1.9 GHz CPU
The "benefit" of this upgrade was sold as improving (production) deployments - an activity that we do about 4 times a year with maybe 2-4 small fix deployments a year. Adding 45 minutes per day to 15 people (QA and developers) I can't imagine ever being justified. In big enterprise applications, if your application is a core application, then changing it is, rightly so (small changes have potential for far reaching impacts - must be communicated and planned with consumers all over the enterprise), a monumental activity - wrong architecture for OSGi. If your application is not an enterprise application - i.e. each consumer can have their own tailored module likely hitting their own silo of data in their own silo'd database and running on a server that hosts many applications, then maybe look at OSGi. At least, that is my experience thus far.
If a Java based application requires adding or removing modules (extending the base functionality of application), without shutting down the JVM, OSGI can be employed. Usually if the cost of shutting down JVM is more, just to update or to enhance functionality.
Examples:
Eclipse: Provides platform for plugins to install, uninstall, update and inter-depend.
AEM: WCM application, where functionality change will be business driven, which can not afford down times for maintenance.
Note: Spring framework stopped supporting OSGI spring bundles, considering it as unnecessary complexity for transaction based applications or for some point in these lines. I personally do not consider OSGI unless it is absolutely necessary, in something big like building a platform.
I've been doing work with OSGi almost 8 or so years and I have to say that you should consider OSGi only if you have a business need to update, remove, install or replace a component on runtime. This also means that you should have a modular mindset and understanding what modularity means. There's some arguments that OSGi is lightweight - yes, that is true but there are also some other frameworks that are lightweight and easier to maintain and develop. Same goes to secure java blah blah.
OSGi requires a solid architecture to be used correctly and it's quite easy to make OSGi-system that could just as easily be a standalone-runnable-jar without any OSGi being involved.
The OSGi provides following benefit:
■ A portable and secure execution environment based on Java
■ A service management system, which can be used to register and share services across bundles and decouple service providers from service consumers
■ A dynamic module system, which can be used to dynamically install and uninstall
Java modules, which OSGi calls bundles
■ A lightweight and scalable solution
It is also being used to bring additional portability of middleware and applications on the mobile side. Mobile side is available for WinMo, Symbian, Android for example. As soon as integration with device features occurs, can get fragmented.
At the very least, OSGi makes you THINK about modularity, code reuse, versioning and in general the plumbing of a project.
Others have already outlined the benefits in detail, I hereby explain the practical usecases I have either seen or used OSGi.
In one of our application, we have event based flow and flow is defined in plugins based on OSGi platform so tomorrow if some client wants different/additional flow then he just have to deploy one more plugin, configure it from our console and he is done.
It is used for deploying different Store connectors, for example, suppose we already have Oracle DB connector and tomorrow mongodb is required to be connected then write a new connector and deploy it and configure the details through console and again you are done. deployment of connnectors is handled by OSGi plugin framework.
There is already a quite convincing statement in its official site, I may quote as
The key reason OSGi technology is so successful is that it provides a very mature component system that actually works in a surprising number of environments. The OSGi component system is actually used to build highly complex applications like IDEs (Eclipse), application servers (GlassFish, IBM Websphere, Oracle/BEA Weblogic, Jonas, JBoss), application frameworks (Spring, Guice), industrial automation, residential gateways, phones, and so much more.
As for the benefits to developer?
DEVELOPERS: OSGi reduces complexity by providing a modular architecture for today’s large-scale distributed systems as well as small, embedded applications. Building systems from in-house and off-the-shelf modules significantly reduces complexity and thus development and maintenance expenses. The OSGi programming model realizes the promise of component-based systems.
Please check the details in Benefits of Using OSGi.