"Moving traditional Java EE applications to an OSGi stack is
intentionally as easy as possible, however there are a number of common
mistakes that can make it feel very hard. This session will describe
some best practices for developing Enterprise OSGi applications and OSGi
bundles, allowing developers to utilise the power of OSGi in a painless
way."
- Enterprise OSGi, first release 2010
- OSGi for "Enterprise" applications
- web applications
- databases
- managed transactions
- remoting services
- in terms of scope, OSGi bundles are like JARs with better isolation
- good, but Enterprise Applications are rarely single JARs
- for a long time OSGi had no scope beyond the bundle
How should I use OSGi:
- well designed Object Oriented code -> modular properties
- classes being cohesive and loosely coupled
- avoid tight coupling
- require-bundle is like casting to an implementation
- do enough to be cohesive
- don't do too much in your bundle
- too much is as bad as too little
- version everything!
- package exports can be versioned too
- imports can declare range of accepted versions
- semantic versioning
- specifying a single version means: that version to infinity
- major/minor/micro versions
- use services for looser coupling
- java lacks a satisfactory way to get implementation objects
- using new introduces tight coupling
- OSGi has a service registry
- services are registered using their API, so clients don't need to _____ them
- make services substitutable
- sharing services needs same version of API
- don't do it all yourself
- OSGi is powerful, but hard to use
- Enterprise specifications offer helpful tools
- acessing services
- it is difficult to use use OSGi services properly
- several OSGi dependencies injection containers
- Blueprint & DS
- DS is light-weight, great for simple wiring
- accessing data
- trying to use traditional access patterns leads to unpleasant hacks
- there are standard ways to get hold of things in OSGi
- use these
OSGi specs @ osgi.org
No comments:
Post a Comment