We are planning to develop a client side Java API to retrieve stock market data. It is expected to design the API as modular system so that various components can be plugged into the core API to facilitate extended features.
Components should be plugged into the core API dynamically and there should be a way to control component’s life cycle via common API.
Up to now my selection is to use OSGI container for the API and develop pluggable components as OSGi bundles.
Since this is an API, will OSGi be the best solution for this context?
can anybody advise on me this?
Having worked w/ the OSGi f/w for close to a year, i’ve been totally impressed by what OSGi has to offer – strong and enforced modularity, zero downtime, reliable pluggability of modules and performance.
However, having said that, let me assure you that all the goodness is not instantly apparent. Be sure to get hold of some good technical document [the in-action book is a fine text, so is the r4 specification]. a lack of understanding can put you in the company of
LinkageErrorsandBundleExceptions, which are usually very cryptic, and can serve as good sources of headaches.besides understanding the f/w, you should also emphasise on “good-practices” related to cohesion and loose-coupling, programming against interfaces. you should also look into the BND tool which is an excellent way to package the OSGi bundles.
you might often come across arguments stating that OSGi is quite an “overkill”, and i won’t outrightly deny it. however, if you truly desire the unique features available through OSGi, it’s simpler to get your hands dirty w/ this f/w than to implement a complicated work-around from the scratch.
one last thing – you might keep encountering Spring time and again when working w/ OSGi, but it’s really not required, and unless you’re familiar w/ Spring it might not really be worth it to get into that as well.