Popular patterns revisited on OSGi - Christian Schneider (Adobe)

Popular patterns revisited on OSGi - Christian Schneider (Adobe)

• 1.
  Popular patterns revisitedon OSGi Christian Schneider
• 2.
  Christian Schneider » Computerscientist at Adobe. » Apache member and committer » Twitter @schneider_chris » Website liquid-reality.de blog.liquid-reality.de
• 3.
  Software Design Patterns Reusablesolution 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 - agolden 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 EventSource 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 getEvent 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 dependenciesinto 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 + Candirectly 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 ofband 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 Boundedcontext 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 perbounded 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 yourattention Questions?