PojoSR or OSGi (µ)Services For the Rest of Us
•
1 gostou•1,686 visualizações
PojoSR provides a lightweight OSGi-style service registry and lifecycle management for Java applications without requiring them to be fully modularized as OSGi bundles. This allows services to be introduced incrementally as a first step towards modularity and loose coupling, facilitating a migration path to full OSGi usage. PojoSR removes OSGi's module layer but retains the standardized service API, registry, and lifecycle hooks to promote service-oriented programming. It can also be used to run OSGi bundles in environments that do not support a full OSGi framework.
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (8)
Semelhante a PojoSR or OSGi (µ)Services For the Rest of Us
Semelhante a PojoSR or OSGi (µ)Services For the Rest of Us (20)
Último
Último (20)
PojoSR or OSGi (µ)Services For the Rest of Us
- 1. PojoSR or (OSGi) µServices for the rest of us Karl Pauls !"#$%&'&()"* Dienstag, 25. Oktober 2011
- 2. Karl • Member Apache So?ware FoundaDon • PMC: Felix, Sling, Incubator • PPMC: Ace, Clerezza, Celix • Fellow at Luminis Hall et al. C re at in g M od ul ar A pp lic at io ns in J av a • Project Owner PojoSR O SGi IN ACTION • Co‐Author of „OSGi in AcDon“ Richard S. Hall Karl Pauls Stuart McCulloch David Savage • karl.pauls@luminis.eu FORE WORD BY PETE R KRIENS (a.k.a. karlpauls@gmail.com) MANNING Dienstag, 25. Oktober 2011
- 4. PromoDng a service‐oriented interacDon paSern !"#$%&"' +"0%./#1 2-34%.5 86* !"#$%&"' %6/"#7&/ !"#$%&"' (#)$%*"# +",-"./"# Dienstag, 25. Oktober 2011
- 5. µServices Dienstag, 25. Oktober 2011
- 6. µServices • Interface‐based programming, but more • Service Registry • Centrally accessible • Browsable • NoDficaDons • Service Registry Benefits • Consuming code is in control of provider selecDon • But not provider instanDaDon and configuraDon • Provider code is in control of when to provide • Promotes very loose coupling and late binding Dienstag, 25. Oktober 2011
- 8. OSGi services • OSGi framework provides the concepts we need • Centralized service registry • Consumer has control over selecDon • Provider has control over when to provide • Plus full‐blown deployment and packaging modularity with run‐Dme dynamism Dienstag, 25. Oktober 2011
- 9. OSGi Dienstag, 25. Oktober 2011
- 10. OSGi • The downside to OSGi is that it requires a boSom‐up commitment • You need to convert all of your code into proper modules to take advantage of services • A top‐down approach of adopDng services can help ease migraDon to more modular code Dienstag, 25. Oktober 2011
- 11. OSGi framework Dienstag, 25. Oktober 2011
- 12. PojoSR Dienstag, 25. Oktober 2011
- 13. What is PojoSR? • It largely removes the modularity layer from the OSGi framework • Provides • A centralized service registry based on OSGi API • Lifecycle hooks for JAR files • A “light” OSGi framework for the class path Dienstag, 25. Oktober 2011
- 14. Why this approach? • OSGi API is a standard with years of experience behind it • Can re‐use OSGi modules (a.k.a. bundles) and/or technology • Can leverage services without having to completely modularize first (i.e., top‐down) • Provides a path to full‐blown modularity Dienstag, 25. Oktober 2011
- 15. Use Cases Dienstag, 25. Oktober 2011
- 16. MigraDon Dienstag, 25. Oktober 2011
- 17. MigraDon • Without PojoSR • Turn applicaDon into one big bundle (jar) • Split into several bundles • Fix problems • Split into even more bundles (etc.) • Eventually, start using services • Allows you to remove ugly hacks needed to fix problems • With PojoSR • Start using services • Split into bundles Dienstag, 25. Oktober 2011
- 18. Use OSGi where you can‘t • OSGi (lite) on Google App Engine using PojoSR Dienstag, 25. Oktober 2011
- 19. Use OSGi where you can‘t • hSp://vimeo.com/22571224 Dienstag, 25. Oktober 2011
- 20. Android Dienstag, 25. Oktober 2011
- 23. Services and dependency injecDon • Advantages when combined with service orientaDon • Dependency injecDon no longer needs global view • InformaDon localized to just the provider/consumer • No longer restricted to a single DI framework • Different DI frameworks can play together via the service registry Dienstag, 25. Oktober 2011
- 24. Usage Dienstag, 25. Oktober 2011
- 27. Standalone Dienstag, 25. Oktober 2011
- 28. Demo Dienstag, 25. Oktober 2011
- 30. Benefits and Drawbacks • PojoSR provides part of the power of OSGi • in a non‐intrusive way. • allows to increase modularity and use µServices • without first ridding an exisDng code base of class loader hacks • Can run OSGi bundles where you can‘t • The drawbacks are • does not enforces module boundaries • does not allow mulDple versions of the same package; does not support the Bundle‐ClassPath. • But you can use the µService model to get rid of the class loading hacks over Dme, a?er which it will be easier to move to OSGi and get side by side versioning and real module boundaries. Dienstag, 25. Oktober 2011
- 31. QuesDons? http://pojosr.googlecode.com Dienstag, 25. Oktober 2011