This section lists a couple of design patterns as they can be applied in an OSGi context.
Provides a service as long as its dependencies are resolved.
In a dynamic framework, services can come and go. Components that publish a service are often themselves dependent on other services to perform their task. In such cases, they have a dependency on those services and it makes sense to only publish their own services when these dependencies are available. Being able to declare such dependencies in code ensures consistent life cycle behavior.
Provides an aspect on top of a specific type of service.
In aspect oriented programming, supporting functions are isolated from the main application's business logic. This increases modularity at the source level by allowing the separation of cross-cutting concerns. In OSGi we want to extend this modularity to the runtime, therefore we implement aspects to work on certain services, where the aspect itself publishes that same service but (usually) with a higher priority. This allows you to dynamically add and remove aspects.
Provides an adapter for a specific type of service.
Like with aspects, sometimes you want to create adapters for certain services, which add certain behavior that results in the publication of (in this case) a different service. Adapters can dynamically be added and removed and allow you to keep your basic services implementations clean and simple, adding extra features on top of them in a modular way.
Provides an adapter for a specific type of resource.
Resource adapters are similar to normal adapters, but instead of requiring a service, they require a resource and provide a service on top of it. Resources are an abstraction that is introduced by the dependency manager. They can be implemented to serve resources embedded in bundles, somewhere on a file system or in a content repository or database.
Provides a proxy that hides the service dynamics of a dependency, even if it disappears for a short time.
Provides an implementation of an object that does nothing and can be used in the absence of the real object.
Handles listeners by leveraging the OSGi service registry to publish and look them up.