As someone who is being recently re-introduced to the Java platform, there are a lot of components and pieces to become familiar with. One of those pieces is OSGi, a service registry and deployment specification for Java apps.
The OSGi specification describes a complete environment for running Java applications as components. Each component is a bundle that can be remotely installed, started, stopped, updated or uninstalled. In addition, OSGi provides a service registry that allows existing services to detect the addition or removal of other services and adapt accordingly.
Architecture
With OSGi, Java applications are compiled into JVM byte code and packaged as “bundles” described by metadata according to the specification. Below the bundle layer, services and a service registry allow dynamic connection between bundles. The bundles are then supported by a life cycle management API.
Services
The OSGi standard also specifies service APIs that can be implemented by bundles. For example, the OSGi spec provides an interface for logging; any bundle that satisfies this interface can provide the logging service to bundles deployed with OSGi.
Why OSGi?
The key benefit of OSGi is application modularity. OSGi allows you to build an application from multiple different modules, and allows them to work together through clear APIs. As an analogy, OSGi provides a service oriented architecture inside the JVM; allowing applications to dynamically register and consume bundles. By deploying an application as independent bundles, you allow for for code reuse, modular deployments, and separation of concerns. In an ideal scenario, the promise of OSGi is to provide the same benefits as micro services for the JVM.