OSGi is providing a module system, but during implementation in projects it becomes difficult to really use the benefits of an OSGi runtime. Without follow the principles an OSGi system can evolve to a tightly-coupled system like in the past. Some principles and guidelines have to be followed to achieve a good architecture of a software system: - interface/implementation separation for bundles - visibility usage of bundles (import/export) - extensibility for services (and special focus on declarative services) - layering of bundles and using declarative service for layer communication - mocking of layers to achieve maturity of the implementation - interface evolution of bundles to achieve extensibility The presentation will show the changes by refactoring a small web application. The application starts as a tightly coupled system and will be improved by applying the architecture principles. So, in the presentation a lot of coding will be shown, until a good structure of the application is achieved. The guidelines are based on experiences in different projects and are used as best practices in new projects.

1. Structuring Software Systems with
OSGi
Ulf Fildebrandt
SAP AG
22.09.2011
OSGi Alliance Marketing © 2008-2010 . 1
Page
COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved
All Rights Reserved

2. Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Page 2 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

3. Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Page 3 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

4. Principles of Modularity
• Decoupling
• Logic has to be decoupled, otherwise the structure evolves into a monolithic
block („architecture erosion“)
• Simplicity
• Design the concepts as simple as possible, otherwise the system solves non-
existing requirements
• Extensibility
• Decoupling implies that frameworks are open for logic
• Extensibility for logic is not the exception, but rather the common principle for
all frameworks
Page 4 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

5. OSGi basics
• Bundles are the atomic entities for structuring
(containing binaries)
• Services are the communication means between
bundles
• Exported packages are the public interface of bundles
• Imported packages define the usages of bundles
Page 5 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

6. Example
• Web application to analyze data
• OSGi bundles, services, and exported
packages are used to structure the application
Page 6 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

7. Structure of Application
• Fulfills the business requirements, but no modularity
(decoupling, extensibility)
Servlet
Data Data
Source 1 Source 2
Page 7 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

8. Structure Of Application
Servlet
Data Aggregate
Data Data
Aggregator 1 Aggregator 2
Data Source 1 Data Source 2
Data Aggregator
Interface
Page 8 Data Source
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved
Interface

9. Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Page 9 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

10. Interface Usage
• Implementation should only use interfaces  Services
in OSGi
• Services are difficult to implement in OSGi fulfilling all
lifecycle requirements (Service Tracker, Service
Listener)  „boilerplate coding“
• Frameworks: Declarative Services (DS) is part of the
OSGi specification, Blueprint, etc.
• DS are meant to declare the dependencies of services and service usage
• DS is a mechanism to bring dependency injection into OSGi
Page 10 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

11. Structure Of Application
Servlet
IDataAggregate
Data Aggregate
Data Data
Aggregator 1 Aggregator 2
Data Source 1 Data Source 2
IDataAggregator
Data Aggregator
Interface
IDataSourceService
IDataSource
Page 11 Data Source
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved
IDataItem Interface

12. Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Page 12 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

13. Layers
• In architecture, layers are used to structure the software
• Entities within a layer can only have dependencies to
lower layers
• Bundles in OSGi belong to one layer only
• In reality more coarse grained frameworks are used
• Feature (P2, Eclipse)
• Application (Aries)
• OSGi sub system specification
• For simplicity in these examples only bundles are used
Page 13 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

14. Servlet UI
Data Aggregate Aggregate
Aggregator Data Data
Aggregator 1 Aggregator 2
Data Source 1 Data Source 2 Data Provider
Data Aggregator
Data Aggregator Interface
Interface
Data Source InterfaceAlliance Marketing © 2008-2011 . All Rights ReservedSource
Page 14 OSGi Data
Interface

15. Class
Structure
• Classes fit
to bundle
structure
Page 15 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

16. Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Page 16 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

17. Interface of a Layer
• Layers should have a clear interface
• API (Application Programming Interface)
• is defining the publicly available functionality
• is an interface
• is implemented as service in OSGi
• Example: IDataAggregate, IDataSourceService
• SPI (Service Provider Interface)
• is defining the extension point
• is implemented as service in OSGi in a separate bundle
• Example: IDataSource, IDataAggregator
Page 17 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

18. Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Page 18 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

19. Versioning in OSGi
• Bundles and exported packages are versioned
• Usage of versioning is different for implementation, API,
SPI
• Implementation: can be replaced easily, because interface is not changed
• API: can be evolved in a compatible way, but implementation has to be
adapted, too
• SPI: evolution is difficult, because if interfaces are extended, then the old
implementations are not valid any more
• Java evolution: Ix  Ix2, e.g. IDataAggregator  IDataAggregator2 in the
same package
Page 19 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

20. Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Page 20 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

21. Testing
• Layers have to be separately testable
• Mock objects (Easy Mock)
• Example: DataAggregate layer
Page 21 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

22. Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Page 22 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

23. Multiple assemblies
• Bundles assembled into multiple assemblies (e.g.
products)
• An assembly contains bundles from different layers
• A layer does not have to be used completely
• Examples:
• Other access layer (REST)
• Configuration data aggregator
• DSL data aggregator
Page 23 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

29. Summary
• Module and service concepts should be used to
structure software
• Bundles expose clear interfaces
• Communications works by using services (minimum
requirement between layers)
• Layers are testable separately
• Different assemblies should be possible
Page 29 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved