structuring software systems with osgi - ulf fildebrandt
DESCRIPTION
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.TRANSCRIPT
COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved
Structuring Software Systems with
OSGi
Ulf Fildebrandt
SAP AG
22.09.2011
OSGi Alliance Marketing © 2008-2010 .
All Rights Reserved
Page 1
OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 2
Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 3
Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 4
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 5
Example
• Web application to analyze data
• OSGi bundles, services, and exported
packages are used to structure the application
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 6
Structure of Application
• Fulfills the business requirements, but no modularity
(decoupling, extensibility)
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 7
Servlet
Data
Source 1
Data
Source 2
Structure Of Application
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 8
Servlet
Data Aggregate
Data Source 1 Data Source 2
Data
Aggregator 1
Data
Aggregator 2
Data Aggregator
Interface
Data Source
Interface
OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 9
Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 10
Structure Of Application
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 11
Servlet
Data Aggregate
Data Source 1 Data Source 2
Data
Aggregator 1
Data
Aggregator 2
Data Aggregator
Interface
Data Source
Interface
IDataAggregate
IDataSource
IDataItem
IDataAggregator
IDataSourceService
OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 12
Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 13
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 14 Data Source Interface
Data Aggregator Interface
Data Provider
Aggregator
Aggregate
UI Servlet
Data Aggregate
Data Source 1 Data Source 2
Data Aggregator 1
Data Aggregator 2
Data Aggregator Interface
Data Source Interface
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 15
Class
Structure
• Classes fit
to bundle
structure
OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 16
Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 17
OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 18
Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 19
OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 20
Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
Testing
• Layers have to be separately testable • Mock objects (Easy Mock)
• Example: DataAggregate layer
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 21
OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 22
Agenda
• OSGi: basic structure and declaration
• Interface Usage
• Layers
• Services and Layers
• Versioning
• Testing
• Assemblies
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 23
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 29