Service model versus Extender?

Question

I just finished a thorough review of the Apache Felix Application Demonstration with shapes. State of the article:

When creating an application based on OSGi, there are two main orthogonal issues that should be considered:

• Service Model and Expander Model
• Associated Hosted Infrastructure Application

The first problem is actually a common problem when creating an OSGi-based Application. There are two general approaches that you can use when creating an extensible OSGi application. The service model approach uses the OSGi service concept and service registry as an extensibility mechanism. The extender model approach uses the OSGi installed set of packages as an extensibility mechanism. Both approaches have advantages and disadvantages and can be used independently or together.

I think this is generally accepted best practice regarding the second point in order to prefer the attached application, unless for really good reason you are not forced to use the hosted infrastructure.

Regarding the first point, having studied both the service model and the extender model, I understand the differences between them, but I'm still trying to figure out what are the advantages and disadvantages for the different models.

What are the advantages and disadvantages of each model (Service vs Extender) and what are the best methods for determining which one to use or when it would be wise to use a combination of both?

Answer 1

Services are more commonly used, and they should usually be your first choice unless you have a good reason to develop a new expander.

OSGi is a service oriented platform. The service API concludes a contract between the two parties, the consumer and the supplier. The contract is defined in terms of a Java package containing interfaces, and the provider provides it by implementing these interfaces. The consumer uses the services registry to search for instances of the interface that he wants to use.

The drawing of the expander is somewhat more flexible and abstract, but more difficult to understand and use. In fact, a set of expanders provides additional functionality on behalf of some other packages (packages) that are usually selected that contain some kind of declaration.

For example, suppose you want to implement a help system for your application. Bundles can simply contain an HTML document along an agreed path, and the central help package can scan packages to find these documents and add them to the main directory. Doing this with services would be rather cumbersome: if you follow the board style, you will need to define the Java HelpProvider interface using the getHelpDocuments() method; every package that wants to provide assistance will have to implement this interface and register it as a service. On the other hand, the set of help system extenders should be relatively smart, as it should keep track of incoming and outgoing packets. But at least you only need to write this smart code once.

Real examples of expanders are as follows:

• Declarative Services is an expander that searches for Service-Component declarations in other packages and does all kinds of things on their behalf - instantiating components, publishing services, etc.
• Blueprint is an expander that does something similar. It searches for a Bundle-Blueprint ad or XML files along an agreed path.
• The OSGi enterprise specification defines a JPA extender that looks for packages containing the persistence.xml file declared by the Meta-Persistence header. When he finds one, he creates a containment unit for this package.
• Eclipse contains an extender (vaguely called an extension registry) for creating things like Views, Perspectives, Menus, etc. All of them are declared in the plugin.xml file in the root directory.

To summarize ... services are used to register and search for objects based on a contract. Extenders are designed to extend the functionality of packages, usually based on some declarative resource or header, rather than executable code.

Answer 2

The extender model is mainly used for frameworks. He must look deep into the knot in order to complete his work. So this is not good for free communication. The advantage is that it can define a completely new abstraction, such as a plan or declarative services or cdi. All of these frameworks use the extender model to connect your package based on the specification.

A service model is the right thing for your application. Services allow you to hide implementation details, as well as instantiate a service from a user. So it is very good for free communication.

In the end, both are commonly used together. For example, you can use cdi annotations to bundle your package from the start and indicate that you offer and consume services. Thus, the cdi platform uses an extension cable to interconnect your package when you use the service model to freely bundle your packages.