On
l10i wrote: With OSGi this is not the case: the application is made of a large set of bundles, each hopefully designed to handle a separate part of the functionality. This approach enables intra-application hot deployment, since the framework is designed to consider the effect that restarting any single jar brings to the application as a whole, and to let the other jars react appropriately. That offers the ability to preserve application state as much as possible.
Just to elaborate on this a little more, the best OSGi applications are service-oriented applications which integrate through OSGi services registry. This service registry is dynamic, services can come and go at any time and OSGi service consumers react to this dynamicity appropriately. So let's say your application is comprised of a number of bundles, including a bundle that uses a payment service (e.g. for handling credit card payments) and another bundle that provides that payment service. If you find yourself in a situation that the payment service needs to be updated (because you have a critical fix or maybe you have found a cheaper provider, etc) you can update this payment service without even taking the consumers of this service down. To achieve this, you can update the payment service bundle itself, but what I would recommend in such a case is to install the new version of the payment service bundle alongside the old version first. This is possible because OSGi allows multiple versions of the same bundle to co-exist. Then once the new bundle is up and running you can remove the old payment service bundle at which point the consumers will automatically flip to using the new ones, courtesy of the OSGi service registry.
Such an architecture as the above example is really powerful and great to ensure that your enterprise applications stay up, and it can be realized by using OSGi services combined with the ability to dynamically install, uninstall or update OSGi bundles.
BTW there is a little more detail to the above example as bundles can also be written to use all services of a particular type - what's best for you depends on your situation.
There are a number of ways to use the OSGi service registry, you can use it with the ServiceTracker API, which is fairly low-level. In most cases it's preferable to use a framework for this such as OSGi Declarative Services (DS), OSGi Blueprint or other framework. In most cases these frameworks work through injection and handle the dynamicity of the OSGi Service Registry for you. For information on DS or Blueprint see the OSGi 4.2 Enterprise Specification.
I believe that the answer is the same as every OSGi use case: modularity and finer update granularity.
OSGi is far more than updating jars at runtime without restarting the server. From the perspective of your question, it is updating jars at runtime without restarting the application.
I admit I do not know the particular implementation of EAR hot deployment in JBoss AS, but in any case EAR updating cannot possibly be designed so to preserve the whole state of the application. The server is still running, but you essentially restart the application upon updating. The degree of such state loss really depends on how you design your application, but the fact remains that you are doing things monolitically.
With OSGi this is not the case: the application is made of a large set of bundles, each hopefully designed to handle a separate part of the functionality. This approach enables intra-application hot deployment, since the framework is designed to consider the effect that restarting any single jar brings to the application as a whole, and to let the other jars react appropriately. That offers the ability to preserve application state as much as possible.
Hence the benefits of an OSGi design in the Enterprise case is application liveness. No need to underline the importance of that. Truly, there are use cases where the application may be safely restarted. But OSGi in my opinion is the only really scalable and maintainable choice for Java EE nowadays. The fact that the most important application servers have moved (or are going to) to an OSGi runtime (and consequently giving OSGi application support) is proof of that.