OSGi is a modular system and service platform for Java applications that implements a dynamic component model. It allows components called bundles to be installed, started, stopped, updated, and uninstalled remotely without requiring a reboot. Each bundle has its own classloader and dependencies. OSGi supports a service registry that allows bundles to detect when new services are added or removed. Popular implementations of the OSGi framework include Apache Karaf, Apache ServiceMix, and JBoss Fuse.
2. What is OSGi?
OSGi 프레임워크는 독립적인 자바/가상 머신 환경에서 제공하고 있
지 않는 세련되고, 완전하며 동적인 SOA(Service Oriented
Architecture) 기반의 컴포넌트 모델을 구현한다. 응용 프로그램 또
는 구성 요소(번들, Bundle)는 재시동 과정 없이 원격지를 통해 설치
(installed), 시작(started), 정지(stopped), 업데이트(updated) 그리고
제거(uninstalled)할 수 있다.
The OSGi (Open Service Gateway initiative) specification describes
a modular system and a service platform for the Java
programming language that implements a complete and dynamic
component model, something that does not exist in standalone
Java/VM environments. Applications or components, coming in
the form of bundles for deployment, can be remotely installed,
started, stopped, updated, and uninstalled without requiring a
reboot; management of Java packages/classes is specified in great
detail. Application life cycle management is implemented via APIs
that allow for remote downloading of management policies. The
service registry allows bundles to detect the addition of new
services, or the removal of services, and adapt accordingly.
3. What does 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.
7. OSGi Framework Architecture
Bundles - Bundles are the OSGi components made by the developers.
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 in a specific
platform.
8. OSGi System Layering
Services are dynamic. This means that a bundle can decide to withdraw its
service from the registry while other bundles are still using this service.
Bundles using such a service must then ensure that they no longer use the
service object and drop any references. We know, this sounds like a
significant complexity but it turns out that helper classes like the Service
Tracker and frameworks like iPOJO, Spring, and Declarative Services can make
the pain minimal while the advantages are quite large.
OSGi 프레임워크는 크게 번들 실행주기(설치/
시작/제거/업데이트), OSGi 기본 실행단위인
번들과 서비스에 대한 운영 관리 및 리소스와
서비스 레지스트리를 담당 한다. 복수 개의 클
래스 로더에 의해 각각 서로 다른 OSGi 어플리
케이션이 독립성을 가지고 실행되지만,
OSGi Framework Service Registry에 등록된
Sharing Code와 주소에 의해 서로 다른 번들간
의 리소스 공유와 연동/통합으로
무수한 서비스들을 생성하고 실행한다.
9. Bundle Life Cycle
Bundle State Description
INSTALLED The bundle has been successfully installed.
RESOLVED
All Java classes that the bundle needs are available. This state indicates that the bundle is either re
ady to be started or has stopped.
STARTING
The bundle is being started, the BundleActivator.start method will be called, and this method has
not yet returned. When the bundle has an activation policy, the bundle will remain in the STARTIN
G state until the bundle is activated according to its activation policy.
ACTIVE
The bundle has been successfully activated and is running; its Bundle Activator start method has b
een called and returned.
STOPPING
The bundle is being stopped. The BundleActivator.stop method has been called but the stop meth
od has not yet returned.
UNINSTALLED The bundle has been uninstalled. It cannot move into another state.
Karaf Console
10. Service
The OSGi service registry enables a bundle to publish objects to a shared registry,
advertised via a given set of Java interfaces.
Published services also have service properties associated with them in the registry.
The registry is a crucial feature of OSGi, facilitating decoupling between bundles by
promoting a dynamic collaborative model based on a service-oriented paradigm
(publish/find/bind).
Blueprint integrates tightly with the service registry, allowing clients to publish, find
and bind services in a POJO-friendly manner, without coupling themselves to the
OSGi API.
11. Benefits of Using OSGi
Benefits
Reduced Complexity Fast
Reuse Lazy
Real World Secure
Easy Deployment Humble
Dynamic Updates Non Intrusive
Transparency Runs Everywhere
Versioning Widely Used
Simple Supported by Key
Companies
Small
12. Standard Services : OSGi System Services
System Services Description
Logging
The logging of information, warnings, debug information or errors is handled through the Log Ser
vice. It receives log entries and then dispatches these entries to other bundles that subscribed to t
his information.
Configuration Admi
n
This service allows an operator to set and get the configuration information of deployed bundles
Device Access
Facilitates the coordination of automatic detection and attachment of existing devices. This is used
for Plug and Play scenarios.
User Admin
This service uses a database with user information (private and public) for authentication and auth
orization purposes.
IO Connector
The IO Connector Service implements the CDC/CLDC javax.microedition.io package as a service. T
his service allows bundles to provide new and alternative protocol schemes.
Preferences
Offers an alternative, more OSGi-friendly mechanism to using Java’s default Properties for storing
preferences.
Component Runtime
The dynamic nature of services—they can come and go at any time—makes writing software hard
er. The Component Runtime specification can simplify handling these dynamic aspects by providin
g an XML based declaration of the dependencies.
Deployment Admin Standardizes access to some of the responsibilities of the management agent.
Event Admin Provides an inter-bundle communication mechanism based on a publish-and-subscribe model.
Application Admin
Simplifies the management of an environment with many different types of applications that are si
multaneously available.
13. Standard Services : OSGi Protocol Services
Protocol Services Description
HTTP Service Allows information to be sent and received from OSGi using HTTP.
UPnP Device Service
Specifies how OSGi bundles can be developed to interoperate wit
h Universal Plug and Play (UPnP) devices.
DMT Admin
Defines an API for managing a device using concepts from the Op
en Mobile Alliance (OMA) device management specifications.
14. Standard Services : OSGi Miscellaneous
Miscellaneous Services Description
Wire Admin
Allows the connection between a Producer service and a Consumer
service.
XML Parser
The XML Parser service allows a bundle to locate a parser with desir
ed properties and compatibility with JAXP.
Measurement and State
The Measurement and State service allows and simplifies the correct
handling of measurements in an OSGi service platform.
15. iPOJO
iPOJO is a service component runtime aiming to simplify OSGi
application development. It natively supports ALL the dynamism
of OSGi. iPOJO is made to run modern applications exhibiting
modularity and requiring runtime adaption and autonomic
behavior.
Main features
Components are developed as POJOs - no dependencies or complex API
Use annotations, XML or a fluent API to declare your components and
instances
Require and provide services without requiring code, while being amazingly
powerful
iPOJO applications are natively resilient to dynamism
Extensible and customizable, develop your own component model
iPOJO applications are supporting dynamic adaptation, and exhibit
autonomic behavior
Apache Felix iPOJO
16. Blueprint Service
Enterprise Modules Project (Gemini)
The Blueprint Service specification defines a
dependency injection framework, specifically for
OSGi bundles, that understands the unique
dynamic nature of services. It provides an OSGi
bundle programming model with minimal
implementation dependencies and virtually no
accidental complexity in the Java code. Bundles in
this programming model contain a number of XML
definition resources which are used to wire the
application together and start it when the bundle is
active.
This Blueprint Service specification is derived from
the Spring Dynamic Modules project.
There are currently two open source
implementations of the Blueprint:
17. Dependency injection framework
Dependency inj
ection
Declarative Servi
ces
Blueprint iPOJO
Callback injectio
n
Yes Yes (public meth
od only)
Yes
Constructor inje
ction
No Yes Yes
Field injection No No Yes
Setter injection Yes Yes Yes
Proxy injection No Yes Yes
List injection No Yes Yes
Nullable injectio
n
No No Yes
18. Dependency injection framework
Lifecycle
Declarative Servi
ces
Blueprint iPOJO
Callbacks (activa
te/deactivate)
Yes Yes Yes
Factory pattern Yes Yes Yes
Lazy initializatio
n
Yes Yes Yes
Damping No Yes Yes
Field synchroniz
ation
No No Yes
Component lifec
ycle control
Yes Partial Yes
Service lifecycle
control
No No Yes
25. Apache Karaf
Apache Karaf is a small OSGi based runtime which provides a lightweight container onto which various components
and applications can be deployed.
Here is a short list of features supported by the Karaf:
•Hot deployment: Karaf supports hot deployment of OSGi bundles by monitoring jar files inside
the [home]/deploydirectory. Each time a jar is copied in this folder, it will be installed inside the runtime. You can then
update or delete it and changes will be handled automatically. In addition, the Karaf also supports exploded bundles
and custom deployers (blueprint and spring ones are included by default).
•Dynamic configuration: Services are usually configured through the ConfigurationAdmin OSGi service. Such
configuration can be defined in Karaf using property files inside the [home]/etc directory. These configurations are
monitored and changes on the properties files will be propagated to the services.
•Logging System: using a centralized logging back end supported by Log4J, Karaf supports a number of different
APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi)
•Provisioning: Provisioning of libraries or applications can be done through a number of different ways, by which
they will be downloaded locally, installed and started.
•Native OS integration: Karaf can be integrated into your own Operating System as a service so that the lifecycle
will be bound to your Operating System.
•Extensible Shell console: Karaf features a nice text console where you can manage the services, install new
applications or libraries and manage their state. This shell is easily extensible by deploying new commands
dynamically along with new features or applications.
•Remote access: use any SSH client to connect to Karaf and issue commands in the console
•Security framework based on JAAS
•Managing instances: Karaf provides simple commands for managing multiple instances. You can easily create,
delete, start and stop instances of Karaf through the console.
26. ServiceMix
Apache ServiceMix is a flexible, open-
source integration container that unifies
the features and functionality of
Apache ActiveMQ, Camel, CXF,
andKaraf into a powerful runtime
platform you can use to build your own
integrations solutions. It provides a
complete, enterprise ready ESB
exclusively powered by OSGi.
27. JBoss FUSE
JBoss Fuse is an open source Enterprise
Service Bus (ESB) with an elastic footprint
that supports integration beyond the data
center. The ability to deploy JBoss Fuse in
several different configurations enables
intelligent integration to all facets of your
business – on premise or in the Cloud.
Editor's Notes
iPOJO is a service component runtime aiming to simplify OSGi application development. It natively supports ALL the dynamism of OSGi. Based on the concept of POJO, application logic is developed easily. Non-functional properties are just injected in the component at runtime.
iPOJO strength points are :
components are developed as POJO, nothing else is required !
the component model is extensible, so feel free to adapt it to your needs
the standard component model manages service providing and service dependencies, and so can require any other OSGi services
iPOJO manages the component instance lifecycle and the environment dynamics as it has never been possible
iPOJO provides a powerful composition system to create highly dynamic applications
iPOJO supports annotations, XML or Java-based API to define the componen
The Blueprint Service specification defines a dependency injection framework, specifically for OSGi bundles, that understands the unique dynamic nature of services. It provides an OSGi bundle programming model with minimal implementation dependencies and virtually no accidental complexity in the Java code. Bundles in this programming model contain a number of XML definition resources which are used to wire the application together and start it when the bundle is active.
This Blueprint Service specification is derived from the Spring Dynamic Modules project.
There are currently two open source implementations of the Blueprint:
Apache Aries
Eclipse Gemini