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?
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
“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.Runnableinterface, 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:
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.