Aarti Malhotra wrote:How do we achieve flexibility in the applications using OSGi and Spring?
Flexibility is attained by having loosely-coupled elements in your application. This is true with DI and more so with OSGi.
Think about plain-old dependency injection for a moment. When your objects are given the objects that they use and only know about those objects through a common, stable interface, then you can swap out implementations of those objects transparently. That is, if FooImpl is given an implementation of Bar and only knows about Bar through the Bar interface,
you should be able to give FooImpl *any* implementation of Bar without changing FooImpl. That, by itself, offers a lot of flexibility.
OSGi takes it a bit further. Rather than saying "Here's a BarImpl...wire it into that property of type Bar.", OSGi says "Hey...anyone got a Bar?" FooImpl would be wired with a Bar, but not even the Spring configuration knows what the implementation will be. It only knows that it will be given a Bar...how that Bar is implemented is a separate concern handled by the OSGi framework. The OSGi framework, when asked for a Bar, will search its service registry for services that implement Bar.
The nice thing about this is that Bar implementations can come and go, have multiple versions, and all sorts of other dynamic things at runtime. But OSGi handles it all gracefully. (The details of how it handles the dynamic nature of services is *way* to detailed to outline here...suffice it to say that you usually don't need to worry too much about it...it just works. In some cases, you may have to help it out a little, but for the most part, it just works.)
