I’ll present a simple application that shows how to dynamically provide an application upgrade with zero downtime and no JVM restart. It will load a HTTP Server and then register a handler with it. This handler then processes the request using a ComplexService. Multiple bundles of this ComplexService implementation are possible (suppose V1 and V2). We can start the OSGi container with 0 or more of these and let the handler decide which one to use. If we start with suppose V1 then we can load V2 and stop V1, creating an update without a JVM restart.
The following sequence diagram shows the events.
Sequence diagram for OSGi example
With this simple set of bundles (less than 200 lines of code in all!) I can show the following:
Run multiple versions of your app simultaneously: If your application is designed with this mind, you can continue to run singletons of the http server and your data access layer, however you have multiple versions of your business logic which may be used dynamically.
Dynamic routing: Expanding on the point above you can build a smart routing mechanism to invoke the different versions of the services that are available.
Install new bundles to upgrade features: You may create new services and register them with the http server to provide new features all without a JVM restart.
Upgrade application version: You may install a new version of any service and shutdown and remove a previous version and have existing http services use this dynamically. Again no JVM restart.
Note on versioning: In OSGi it is possible to version packages exported/imported by bundles. For the purpose of this exercise I’ll keep things simple and not use it.