1.
Popular patterns revisited on OSGi
Christian Schneider

2.
Christian Schneider
� Computer scientist at Adobe.
� Apache member and committer
� Twitter @schneider_chris
� Website liquid-reality.de
blog.liquid-reality.de

3.
Software Design Patterns
Reusable solution to a commonly occurring problem
� Context (when to use)
� Description (how to use)
� Advantages
� Disadvantages
https://en.wikipedia.org/wiki/Software_design_pattern

4.
Patterns - a golden hammer?
� Patterns add indirection
� Is the pattern suitable for your situation?
� Do not overdo pattern usage
Source: https://de.m.wikipedia.org/wiki/Datei:Golden_gavel_1.jpg

5.
OSGi: Different patterns?
OSGi
� Dynamic runtime
� Strong modularity
� Requires construction AND
deconstruction of components

6.
Observer / Listener
https://en.wikipedia.org/wiki/Observer_pattern
Event Source Event Listener
addListener
Event Object
update
+ Event Source not coupled to Listeners
- Listeners coupled to Event Source
- Add / remove is manual

7.
OSGi Whiteboard
Event Source
Registry
get Event Listener
register
Service Event Listener
Event Source 2
+ Listener not coupled to Event Source
- Listeners might miss updates
- No error if Event Source is not present

8.
OSGi Whiteboard + Requirements
R7 spec: Annotations can define service properties
+ requirements
Example:
@HttpWhiteboardServletPattern(path)
+ Requirements make sure event source is deployed
- Listeners might miss updates

9.
Dependency injection
Inject dependencies into an object from outside.
� Construtor
� Field
� Setter
Annotations to mark where and what to inject.
+ Injection happens only once
- Can not easily adapt to environment
- Injection of complete application at one time
https://en.wikipedia.org/wiki/Dependency_injection

10.
OSGi: Service Injection (declarative
services)
� Each component has its own lifecycle
� Lifecycle bound to service dependencies and
configuration
+ Can react to environment
+ Components shut down nicely
+ Different DI frameworks can work together
- Dynamics surprise OSGi beginners

11.
Circuit breaker
+ Can directly react on timeouts and errors
- Needs proxy to emulate original service
- Difficult to implement without external lib
External Serviceconsumer client
circuit breaker
proxy
fallback
when open
when closed

12.
OSGi: Out of band circuit breaker
External Serviceconsumer client
ServiceAvailable
Checker
Create /
Destroy
check availability
fallback
client
rank 1
rank 2
Depends on
+ No proxy needed
- Does not cover all error cases

13.
Domain driven design
Bounded context
AggregateService
Enity
Enity
Service Aggregate
Enity
Enity
Enity

14.
Microservice per Aggregate
� Results in many microservices
� Most wide spread microservice approach today
+ Easy to start with (spring boot)
- Errors in service splits are very costly
- Lots of remoting and error handling necessary
- REST service dependency hell

15.
OSGi: Microservice per bounded
context
� OSGi services inside context
� Messaging / REST between contexts
� Dry inside bounded context
� Separate ways outside
+ Matches the original microservice and system of
systems ideas very well
+ Minimizes remoting
+ Refactoring inside bound context is cheap
- Does not work well with spring boot

16.
Thanks for your attention
Questions?