Java Tech & Tools | OSGi Best Practices | Emily Jiang
•Download as ODP, PDF•
3 likes•1,379 views
The document discusses OSGi best practices for modular application development. It covers: 1) Using Import-Package instead of Require-Bundle to avoid tight coupling between bundles. 2) Avoiding split packages to prevent classpath issues. 3) Versioning bundles and packages to allow compatibility checks. 4) Separating APIs from implementations for flexibility.
![OSGi Best Practices Emily Jiang, IBM OSGi Developer, Apache Aries Committer [email_address]](https://image.slidesharecdn.com/5emilyjiangosgibestpractices-111108115225-phpapp01/85/Java-Tech-Tools-OSGi-Best-Practices-Emily-Jiang-1-320.jpg)
![[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (16)
Viewers also liked
Viewers also liked (20)
Similar to Java Tech & Tools | OSGi Best Practices | Emily Jiang
Similar to Java Tech & Tools | OSGi Best Practices | Emily Jiang (20)
More from JAX London
More from JAX London (20)
Recently uploaded
Recently uploaded (20)
Java Tech & Tools | OSGi Best Practices | Emily Jiang
- 1. OSGi Best Practices Emily Jiang, IBM OSGi Developer, Apache Aries Committer [email_address]
- 4. No means for a jar to declare its dependencies.
- 10. Governed by OSGi Alliance: http://www.osgi.org
- 14. Import-Package: What packages from other bundles does this bundle depend upon?
- 16. No flat or monolithic classpath.
- 17. Class sharing and visibility decided by declarative dependencies, not by class loader hierarchies.
- 21. Dynamic (can come and go), framed by bundle lifecycle
- 25. High coupling between bundles
- 28. Loose coupling between bundles
- 29. Only import the package you need
- 35. Minor – API enhancement, e.g. adding methods to an API
- 36. Micro – bug fixing
- 37. Qualifier – identifier such as timestamp
- 42. Many implementation bundles -> enable more services provided
- 44. Put implementation classes in a separate bundle
- 49. Register an implementation of the OSGi ServiceFactory interface in the OSGi service registry.
- 57. “ singleton” scope is the default.
- 59. service can change over time
- 60. can be temporarily absent without the bundle caring
- 61. managed by Blueprint container
- 66. BP2 - Avoid split packages
- 67. BP3 - Version bundles and packages
- 68. BP4 - Separate API from implementations
- 69. BP5 - Share services not implementations
- 70. BP6 - Use Blueprint
- 71. BP7 - Make bundles loosely coupled & highly cohesive
- 72. BP8 - Use Bundle Repositories
Editor's Notes
- WSAD512_IntroToPortal.ppt Page of 32
- .
- On the provider side, the BillingServiceImpl is another POJO implementing a Java interface for which a service is registered by the Blueprint container when the Billing bundle is started. By default beans are created with “singleton” scope which means only a single instance is created by the container. If the bean maintains any state then it can be declared with “prototype” scope so that the container creates a new instance each time it needs to inject the dependency into a client.
- Here is a simple example of an eCommerce bundle which contains a “shop” bean which uses a BillingService provided by another bundle. The Blueprint container locates the Billing Service provider and injects it into the shop bean at runtime. OSGi services are dynamic so if the service provider can be changed then the blueprint container is able to dynamically rewire the reference to a new service without impacting the shop bean instance.
- What best practices used? BP4 - Separate API from implementations BP5 - Share services not implementations BP6 – Make bundles loosely coupled & highly cohesive BP7 - Use Blueprint If you show the source code, the following three best practices can be included: BP1 - Use Import-Package instead of Require-Bundle BP2 - Avoid split packages BP3 - Version bundles and packages