1. Why OSGi matters for Enterprise Java Infrastructures
Santosh Kumar
Why OSGi matters for Enterprise Java Infrastructures

2. Agenda Introduction to OSGi Why is OSGi technology important
How OSGi matters for Infrastructure
OSGi Enterprise spec
OSGi in Cloud
Q&A
Lets take a vote.. How many people have heard of OSGi, Used OSGi

3. Take away from this session
Overall understanding to view OSGi as THE module system for Java
Understanding of what this OSGi Enterprise spec is all about
Should be able to start experimenting with it themselves using one of the available implementations
OSGi
Key for Infrastructure

4. What is OSGi OSGi - Open Services Gateway initiative
Technology is the dynamic module system for Java™.
Provides a service-oriented, component-based environment for developers
Offers standardized ways to manage the software lifecycle.
Support for building modular dynamic and extensible systems
OSGi
Consider as Universal
Middleware

5. Lets put things in perspective…
The Complexity & Scale of Software requires:
1. Service Oriented
As complexity and size
increases
Need for higher level of
abstract programming

6. Why OSGi? 2. Modularity Java Platform Modularity Class visibility:
Classes encapsulate data
Packages contain classes
Jars contain packages
Class visibility:
private, package private, protected,public
No “jar scoped” access modifiers.
No means for a jar to declare its dependencies.
No versioning.
Jars have no modularization characteristics
At runtime, global classpath to search
Jar as unit does
not have modularity

7. Why OSGi? 3. Versioning Enterprise Apps have isolated classpaths but…
Across apps - each archive typically contains all the libraries required by the application
Common libraries/frameworks get installed with each application
Multiple copies of libraries in memory
Within apps - 3rd party libraries consume other libraries leading to version conflicts

8. Overall Architecture Module (Bundle) OSGi Java Operating System
Framework
Operating System
Java
OSGi as
module system
Driver
Driver
Driver
Hardware
= service

9. OSGi –The Dynamic Module System for Java
OSGi specifies a modular architecture for dynamic component based systems
• Execution Environment
• Module Layer
• Life Cycle Layer
• Service Layer
OSGi introduces
Bundles
as modules

10. Module layer Bundle - unit of module
Packaged as JAR - classes + manifest + resources
- Versioning support
- Dependency specification
- JAR with MIME type : application/vnd.osgi.bundle
OSGi enforces modularity in bundles
Bundle as module
represents
separation of concerns

11. OSGi ClassLoading
Each bundle has its own classloader / classpath. More efficient for large systems
Multiple versions of bundles supported concurrently

12. Service Layer Defines a publish/find/bind service model Fully dynamic
Intra VM
service registry
A service is a normal Java object published under one or more Java interfaces with additional metadata with the service registry
Bundles can register services, search for them, or receive notifications when their registration state changes.
Service lifecycle is highly dynamic
Service may be published or unpublished at any time

13. Service Orientation OSGi intrinsically supports SOA Service Registry
publish
find
Service Description
Service Provider
Service Consumer
interact

14. Life Cycle
API to control the security and life cycle operations of bundles
Install, uninstall, start, stop bundles dynamic without restarting applications

15. What does the OSGi Framework provide?
Horizontal Software Integration Platform
Component Oriented Architecture
Module (Bundles)
Package sharing and version management
Life-cycle management and notification (events)
Service Oriented Architecture
Publish/find/bind intra-VM service model
Life-cycle notification (events)

16. Framework Features Runs multiple applications and services
Single VM instance
Separate class loader per bundle
Class loader network
Independent namespaces
Class sharing at the Java package level
Lifecycle management of bundles
Intra VM publish/find/bind service model
Java Permissions to secure framework

17. Where OSGi is used widespread use in desktop and servers Equinox
Reference implementation of core framework and various services
Base runtime for all of Eclipse (rich client, server side and embedded)
Felix - Ships with GlassFish
Application servers : Websphere, JBoss etc
SOA Virtualization Platform : TIBCO Active Matrix
widespread use in desktop and servers

18. Does Enterprise Java need OSGi?
Current challenges
Lots of Libraries To Manage
Designed for Extensibility
Dynamic Deployment, Uptime
Well-defined coherent modules
Simplify unit of reuse

19. OSGI in Enterprise
Integration of established Java Enterprise Edition technologies into an OSGi Environment
Multiple, interoperable, dependency injection based component models
Distributed service model for multiple service platforms and external heterogeneous systems
Database persistence support
Enterprise-class life cycle and configuration management

20. OSGi Enterprise Spec V4.2
Brings Enterprise technologies and OSGi together - OSGi Enterprise Expert Group (EEG)
Using existing Java SE/EE specifications:
JTA, JPA, JNDI, JMX, WebApps, SCA
Framework integrates with the Java EE programming model
Adds Spring-derived component model and dependency injection container – Blueprint Container
Embeded
Desktop
Enterprise

21. What’s happening with OSGi EE
Apache “Aries” - new Apache incubator project
deliver set of pluggable Java components enabling an enterprise OSGi application programming model.
Eclipse Enterprise Modules (“Gemini”)
collection of subprojects, each of which is an implementation or integration of an enterprise-level technology
Virgo - Dynamic Enterprise Application Platform
provide a runtime platform for development of server-side enterprise applications

22. Blueprint Components and Service
Specifies a Dependency Injection container, standardizing established Spring conventions
Specifies components can be wired together within a bundle
Components can be published as services to the service registry
Components configuration and dependencies injected them Blueprint component container ( part of the runtime environment)
Configuration and dependencies declared in XML “module blueprint”

23. Blueprint Components and Service
•Extended for OSGi: publishes and consumes components as OSGi services
Blueprint standardizes the configuration metadata, and brings governance to the specification of the component model.
Simplifies unit test outside either Java EE or OSGi r/t.
The Blueprint DI container is a part of the server runtime (compared to Spring which is part of the application.)
dependencies injected
publishes service
consumes service
Blueprint managed bundle
Blueprint managed bundle
Blueprint Components（POJO)

24. The Java Persistence API
JPA is a POJO based Object Relational Mapping Framework
– defines an API for persisting
objects into a Relational Database
– API for retrieving Objects
from the database
JPA - rich API for mapping
arbitrarily complex objects to the underlying database tables

25. The JPA Service Specification
An OSGi specification for making JPA work in an OSGi framework
Core concepts:
> Persistence Bundle : An OSGi bundle containing managed classes a persistence descriptor and a Meta-Persistence manifest header
> Meta-Persistence header : – A header that defines the locations of persistence descriptors in a bundle
> EntityManagerFactory service : An EntityManagerFactory available as an OSGi service
> Persistence Client : A bundle that makes use of an EntityManagerFactory service.
> EntityManagerFactory builder : A factory for incomplete persistence units

26. Remote Services
Extending the OSGi framework to configure existing distributed computing software systems
Describes how to distribute OSGi services
Ability for OSGi services to invoke services running in other JVMs
Support enterprise application topologies for availability, reliability, and scalability
Enables Distributed
OSGi

27. Web Applications Specification
Defines how to support the Servlet 2.5 and JavaServer Pages (JSP) 2.1 specifications in OSGi
Provide deployment of existing and new web applications to Servlet containers operating on the OSGi service platform
Specification defines the Web Application Bundle, a bundle that performs the same role as the WAR in Java EE

28. Web Applications Specification
WAB uses the OSGi life cycle and class/resource loading rules instead of the standard Java EE environment
Details web application packaged as a WAR may be installed into an OSGi Service Platform

29. SCA Configuration
Provides an assembly model for distributed applications and systems using a service oriented architecture
Components that are assembled can be written in different technologies for example Java EE, BPEL, C++, and scripting languages
Execute on different machines, and can communicate through different protocols and technologies
Declarative application metadata to enable reflection of an SCA component type definition

30. SCA Configuration
Remote Services specification provides an extendable model for configuration types
SCA Configuration Type Specification defines such a configuration type

31. Infrastructure as a Service
OSGi on Cloud
Investigation underway to find possibility of using OSGi in the context of cloud computing (RFP 133 Cloud Computing)
SaaS
Software as a Service
PaaS
Platform as a Service
IaaS
Infrastructure as a Service

32. OSGi on Cloud Value of OSGi : ability to address the following
- Dependency management
- Provisioning/Configuration (Remote services API)
- Extensible, modular system
- Dynamic replacement of components

33. Conclusion Major Java infrastructures support OSGi modular approach
support apps designed &
deployed as bundles

34. Summary Consider as Universal Middleware Bundle as module represents
OSGi
Key for Infrastructure
OSGi
Consider as Universal
Middleware
Bundle as module
represents
separation of concerns
OSGi increasingly
relevant to Enterprise
OSGi and Cloud
Synergy having interesting
possibilities

35. References
services/
OSGi Core Spec
OSGi Enterprise Spec

36. That’s all folks
Q/A
Thank You
Santosh Kumar