Subsystems in OSGi

Neil Bartlett's excellent article on Eclipse Extensions versus OSGi Services touches on an interesting issue. OSGi services are always potentially dynamic - they can come and go when you least expect it.

Some developers may prefer always to use services to interface between bundles, but that is probably not a winning strategy for larger systems.

An ideal structure for such systems, IMO, is to group bundles into subsystems and have subsystems interact with other subsystems via services. Subsystems are not a formal OSGi concept, but they are an important concept in the mind of the designer.

Within a subsystem, bundles can depend on each other more tightly, e.g. by sharing classes. They could even use require-bundle for really tight coupling, although importing and exporting packages with a suitable attribute is sufficient to prevent subsystems from interfering with each other while maintaining the benefits of a somewhat looser coupling.
The benefit of tighter coupling in a subsystem is that there are fewer failure modes (types of error that can arise) due to bits of a subsystem coming and going when other bits of the subsystem least expect it.

In the example above, bundle a1 will not resolve unless its package import can be resolved. So by the time any code in bundle a1 runs, it can be sure that the dependency on a2 has been met and will not break for the lifetime of a1.