Hi Eugen, This is a very interesting question, thanks for asking it!
I appreciate that dynamics are not a big feature of enterprise applications, but there is one time when ALL applications are dynamic, and that is during startup (also, less importantly, during shutdown). This is what I find most useful about OSGi Services: bundles can be started in any order and they can find each other and wire themselves up without requiring a fragile start ordering or a central "God" component to do the wiring. If you are using Declarative Services (DS) you do not necessarily have to handle dynamics and concurrency. The default policy for a service reference is "static": this means that your component instance will be destroyed and recreated if the target of the reference ever changes. This hugely simplifies the programming model because you don't need to worry about concurrency at all. It can be inefficient if things are changing frequently but in an environment where dynamic installation/uninstallation is rare then it can be the best policy. Spring DM/Blueprint has some similar features for "damping" dynamics; I will let somebody else describe them because I am not an expert. With regard to ensuring all mandatory dependencies are satisfied, it's very simple... just start ALL of your bundles! DS has a very helpful feature called "delayed services" in which the implementation of the service is not created until the service is actually needed by a client. This means that it is essentially free to start a DS-based bundle. You just have to be sure NOT to include a BundleActivator... you don't need activators anyway if you are using DS. Regards, Neil On Wed, Feb 16, 2011 at 5:34 PM, Eugen Reiswich <[email protected]> wrote: > Hi folks, > > we had today a conversation regarding OSGi with DS for business applications. > The main point of the discussion was: how can I get rid of OSGi dynamics in > applications where I do not need dynamics. For example: in an application for > a savings bank I will NOT start to use hot plugging to add new bundles or > remove existing bundles, start and stop services while customers are > transferring money from one account to another. The point is that in OSGi > applications I have to deal with dynamic behavior of services and bundles > although I explicitly do not want to have this behavior. Declarative services > in fact simplify the service orchestration and concurrency but they still > have a dynamic character. > > Moving from a world currently dominated by Spring to an OSGi world the > question arise: how can I ensure in an OSGi application that all > required/mandatory services are satisfied at start up? In applications with > more than a few services the OSGi console is not an appropriate way for this > task. > > To give you an example: we are developing a server-side OSGi application > which provides several domain related services: CustomerService, > AccountService etc. When we start our server we do not know whether all > service relations are satisfied and thus all mandatory services are started. > Any ideas/best practices would be appreciated. > > Regards, > Eugen > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
