Hi Richard S. Hall, Karl Pauls, Stuart McCulloch, and David Savage,
I will explain my question by example. Assume I am developing billing application for different clients. I want to decompose (or modularized) my application in to mainly 3 plugable components.
1. Core - Act as the controller or mediator
2. Billing - Handles Billing functions called by Core
3. Stock Handling - Handles Stock Controlling called by Core
Also I have a separate client application which only deals with Core
For a function of a Core, it may call both billing and stock handling. For example client application calls Core's "AddBill" method, so core calls billing for storing the bill and calls stock handling for updating available stock with in one transaction.
But One customer may ask Billing + Stock Handling. while other ask only billing and Other may ask only Stock because of their budget and applicability. From my side I dont want to give Billing component to who has not paid for that.
Currently what I am doing is deploy Mock or Null component (they do nothing). I have a Mock or Null component for both Billing and Stock Handing. For example If client needs only Billing, I deploy regular billing component + Mock component.
My question is in OSGI model do we have more sophisticated way to handle such problem. And do you describe such complex situation in your book?
I'm not sure I fully understand the question. Is the issue you are trying to highlight one of dependency management?
It sounds like you are merely describing an optional service, meaning it may or may not be there. For optional services, you only need the service API to be present to resolve code dependencies, but you do not actually need an implementation of the service API. Technically, you can also specify optional code dependencies. In either case, your component with optional dependencies needs to be programmed to deal with the fact that the dependency might not be satisfied (which is slightly different for optional code dependencies vs optional service dependencies).
An alternative is to use something like iPOJO which can automatically inject null object proxies into your component for missing optional service dependencies, then in this case you don't even need to check for null. This would be basically the same as your suggested approach in your example description.
You could ship each component as a separate bundle and use OSGi services to wire the components together at runtime. As Richard suggested you could then use something like iPOJO (or one of the many IoC frameworks that support OSGi services, such as Spring-DM/Blueprint) to provide null/mock proxies for situations where you ship a subset of bundles and some services are missing.
In other words bundles can help you divide up your application and services can help wire them back together. The book contains a simple paint example that we take apart and re-implement using different parts of OSGi (modularity, lifecycle, services, IoC, etc.) to show the pros and cons of each layer. We also take an existing application (jEdit) and turn it into an OSGi application.
Hope this helps - you might want to read the first chapter (which is free) as this takes a smaller "Hello, world" example through similar steps.
subject: How should we modulariz an application in OSGI