43

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?

S.L. Barth is on codidact.com
  • 8,198
  • 71
  • 51
  • 66
empire29
  • 3,729
  • 6
  • 45
  • 71

2 Answers2

64

"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.

Neil Bartlett
  • 23,743
  • 4
  • 44
  • 77
  • 1
    could you provide an example of a component that is not a service? – santiagozky Jun 18 '13 at 09:33
  • 9
    @santiagozky Sure. Suppose you want to a write Server component that sits on socket and responds to requests over TCP/IP. When the component starts, it opens the socket and creates the thread(s) required to serve clients. When it stops, it closes the thread(s) and socket. Another example: a component that creates a GUI using Swing, SWT or JavaFX. Neither of these example components are services themselves, though they may *use* services published by other components. – Neil Bartlett Jun 18 '13 at 10:05
  • 5
    @santiagozky By the way... if you think about it, you always need at least one of these "active" components in your application. If all the components are simply sitting around offering services to the other components, then your application doesn't actually **do** anything ;-) – Neil Bartlett Jun 18 '13 at 16:41
7

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.

earcam
  • 6,662
  • 4
  • 37
  • 57
  • 3
    I disagree that "components are not providers". A component can be a consumer or a provider of a service, or both, or neither. – Neil Bartlett Jan 16 '12 at 22:34
  • Hi @Neil, AFAIK (and please correct me here) I thought a Component that wasn't registered as Service couldn't be bound by another Component (even in the same bundle - certainly seems the case with Felix DS) – earcam Jan 16 '12 at 22:37
  • 4
    That's true if you limit yourself to the DS definition of a component. In Blueprint and other frameworks, components can consume or be wired to other components in the same bundle without publishing services. I don't think this is relevant though: you can have a components that are services, components that are NOT services, and services that are not components.... – Neil Bartlett Jan 16 '12 at 22:42
  • 1
    Ah, I see (I was looking at this through purely DS eyes). So a Service isn't necessarily a component (e.g. a remote service). I'll edit my post and mark you up (it won't let me mark myself down). – earcam Jan 16 '12 at 22:51
  • Right, you could create a service the old fashioned way by directly instantiating in a `BundleActivator` and registering with `registerService`. That's not a component -- at least not by my definition! -- because the lifecycle is unmanaged. Then again as I pointed out, "component" is not a formally defined term so everybody is entitled to their own definition... – Neil Bartlett Jan 16 '12 at 22:55
  • 1
    @Neil - you mentioned "creating a service the old fashioned way by directly instantiating in a `BundleActivator` and registering with `registerService`". I'm new to OSGi and that is the only way I know about creating services. What is the new way? – axiopisty Nov 22 '13 at 00:07
  • 3
    @axiopisty Declarative Services. – Neil Bartlett Nov 22 '13 at 07:28