On Dec 5, 2006, at 6:00 PM, Steven E. Harris wrote:
Richard S. Hall <[EMAIL PROTECTED]> writes:
The spec used to recommend packaging a bundle with its
interfaces...I am not sure if it still does or not, but it is
definitely not anti-OSGi.
Today I've been wondering about this too. In many cases, I wish to
define some service interface for clients to use, then write at least
one implementation of the service interface. Clients will rely on the
interfaces, but should have no knowledge of the
implementation(s). What's the right way to package this in OSGi?
If I put the interfaces in the same bundle as the implementation, the
two have to be in different packages to maintain the intended privacy
of the implementation. Alternately, I can place the interfaces in a
bundle, and have both the clients and the implementation bundle rely
on that interface-only bundle. This is based on the assumption that a
given class or interface should only wind up in one bundle. Also, the
latter separated approach seems more favorable to there being multiple
implementations of a single interface, as it wouldn't make sense to
put the interfaces in the first implementation's bundle and have all
other implementations rely on the first.
Since Felix is written largely as an implementation of a separate set
of OSGi interfaces, it's more obvious how it splits the two
domains. For an application or system that's more self-contained,
though, it's harder to figure out a discipline for separating
interfaces and implementations.
Overall, it doesn't really make a difference which approach you choose,
since they will all work equally well on the OSGi framework. The main
issues are that if you separate out interfaces, then you end up with a
bunch of small bundles needing to be deployed and you essentially have
no self-contained bundles.
If you package service interfaces with all of your service
implementations (and both import and export them), then the framework
will correctly handle sharing among the different providers properly so
that they can interoperate (if possible). The main downside to this
approach is that if you refresh the implementation it will also refresh
any dependent clients or other providers.
If you expect to only have one service provider at a time, then it
might make sense to package the service interfaces with the service
impl. If you expect to have multiple providers of the same service,
then maybe it makes sense to package the service interfaces separately.
Unfortunately, there is no single rule.
-> richard
