[CONF] Apache Felix > Apache Felix Dependency Manager - OSGi Design Patterns

[confluence]

Apache Felix Dependency Manager - OSGi Design Patterns Page edited by Marcel Offermans Changes (1) ... h4. Motivation 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, represented as a URL. They can be implemented to serve resources embedded in bundles, somewhere on a file system or in a content repository or database. h4. Structure ... Full Content OSGi Design Patterns This section lists a couple of design patterns as they can be applied in an OSGi context. (Singleton) Service Provides a service as long as its dependencies are resolved. Motivation 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. Structure Aspect Service Provides an aspect on top of a specific type of service. Motivation 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. Structure Adapter Service Provides an adapter for a specific type of service. Motivation 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. Structure Resource Adapter Service Provides an adapter for a specific type of resource. Motivation 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, represented as a URL. They can be implemented to serve resources embedded in bundles, somewhere on a file system or in a content repository or database. Structure Temporal Dependency Provides a proxy that hides the service dynamics of a dependency, even if it disappears for a short time. Motivation As a service consumer, you sometimes do not want to deal with the dynamics of services and the fact that they tend to go away for short periods of time whilst their hosting bundle gets updated. A temporal dependency provides you with a proxy that hides these dynamics and blocks your calls if you try to invoke a method on a service that is currently "updating". The maximum time to wait is configurable and you will get an exception if no new service becomes available before that time. Structure Null Object Provides an implementation of an object that does nothing and can be used in the absence of the real object. Motivation When a component depends on a service, but the dependency is optional, it means that it will use this service when available, but it can still operate if it's not. Constantly checking in your code if a service is actually available tends to lead to code with a lot of "if (service != null) service.invoke();" constructions which do not help with code readability. Instead, the dependency manager offers you a mechanism where it will inject null objects for services that are currently not available so you can simply invoke methods on them that "do nothing". Structure Whiteboard Handles listeners by leveraging the OSGi service registry to publish and look them up. Motivation The traditional model for dealing with listeners in Java needlessly complicates things in an OSGi context. Instead of having listeners registering themselves with the component that will invoke them on any change, a listener simply registers itself in the service registry and the component will do a lookup of all relevant services. This is explained in more detail on the OSGi.org wiki in the "Listeners considered harmful: the 'whiteboard' pattern" article. Structure Change Notification Preferences View Online | View Changes | Add Comment