Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Popular patterns revisited on OSGi

483 Aufrufe

Veröffentlicht am

We will look at common cloud and design patterns and see how the special properties of the OSGi environment allows us to rethink these patterns. The talk shows some well known patterns like the service registry and the whiteboard but also some unique patterns like out of band circuit breaker or graceful degredation.

For OSGi beginners the well established OSGi patterns will help getting started the right way. Experienced OSGi developers will find some new patterns to think about. Cloud or enterprise developers will get a new approach to some patterns they are used to which hopefully inspires them to take another look at the current state of OSGi.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

Popular patterns revisited on OSGi

  1. 1. Popular patterns revisited on OSGi Christian Schneider
  2. 2. Christian Schneider � Computer scientist at Adobe. � Apache member and committer � Twitter @schneider_chris � Website liquid-reality.de blog.liquid-reality.de
  3. 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. 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. 5. OSGi: Different patterns? OSGi � Dynamic runtime � Strong modularity � Requires construction AND deconstruction of components
  6. 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. 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. 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. 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. 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. 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. 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. 13. Domain driven design Bounded context AggregateService Enity Enity Service Aggregate Enity Enity Enity
  14. 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. 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. 16. Thanks for your attention Questions?