Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the difference between OSGi Components and Services

Tags:

osgi

Under OSGi, what are the main differences between Components vs Services? As I understand it, all Services must be Components, but not all Components must be services.

What are the benefits of using one over the other with sample use cases?

like image 882
empire29 Avatar asked Jan 16 '12 21:01

empire29


People also ask

What are OSGi components?

OSGi Component — FetchTODO As we discussed earlier, an OSGi component is the entity whose lifecycle will be managed by the OSGi container. To make a class act as component, we annotate it with @Component . We can start, stop and configure the component using Apache Felix Web Console.

What is the difference between @component and @service in AEM?

We can define a class as a service by adding the following scr annotations: @Component – defines the class as a component. @Service - defines the service interface that is provided by the component.

What are OSGi services in AEM?

An OSGi service is a Java class or service interface, along with a number of service properties as name/value pairs. The service properties differentiate among different service providers that provide services with the same service interface.

What is service component AEM?

What is a Service? An OSGi service is a java object instance, registered into an OSGi framework with a set of properties. Any java object can be registered as a service, but typically it implements a well-known interface.


2 Answers

"Components" are less formally defined than services.

A service is any object that is registered in the OSGi Service Registry and can be looked up using its interface name(s). The only prerequisite is that a service should implement some interface... any interface. For example I could register a runnable object under the java.lang.Runnable interface, and clients could look it up using that interface name.

A "component" tends to be an object whose lifecycle is managed, usually by a component framework such as Declarative Services (DS), Blueprint or iPOJO. See this page on the OSGi Community Wiki for a discussion of the different component frameworks available.

A component may have any of the following features, in combination or alone:

  • A component may be started and stopped; this would be considered an "active" component, though that is also an informal term. A component that doesn't need to be started or stopped is called passive.
  • A component may publish itself as an OSGi service.
  • A component may bind to or consume OSGi services.

In general, using a component framework is the easiest way to work with OSGi services because the framework will manage the binding to the services that you want to consume. For example you could say that your component "depends on" a particular service, in which case the component will only be created and activated when that service is available -- and also it will be destroyed when the service becomes unavailable.

like image 181
Neil Bartlett Avatar answered Nov 26 '22 08:11

Neil Bartlett


EDIT: See Neil Bartlett's answer, I've answered quite specifically wrt Declarative Services but it's more subtle than I've stated incorrectly here.

In short: Components are consumers of services not providers, Services are an extension of Components registring as service providers.

A component has a lifecycle (de/activate and modify), service dependency management (un/bind).

A service is an extension of a component; via the service registry, it offers it's services to other bundles etc by publishing implemented interfaces and properties.

The use-case for Services is obvious, the typical cases for using Components is needing management of lifecycle, configuration or service dependencies, but not needing/wanting to publish the Component for inter-bundle usage.

like image 29
earcam Avatar answered Nov 26 '22 09:11

earcam