• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OSGi services best practices

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Do you guys find it is better to define a service API (Java interface) separate from a bundle providing an implementation? This is the convention I've used in my projects, the idea being that many people can use the API and should provide different implementations.

The only downside of this is you end up with at least 2 bundles always which can kind of clutter up the environment. Sometimes even for simple projects, I can see the argument of providing the API and a "default" implementation in one bundle. Kind of curious what your opinion on this is.

2. How important is it to call ungetService(...)? So far I've pretty much ignored it, but I'm sure I'm supposed to be using it somehow. Not sure what the side effects are (or if it really depends on what the service is doing).

3. Declarative Services. Are people still using them?

I remember a while ago I started using DS, seemed like a nice idea. But it seems like there's a bit of frameworks that do the same thing, of course not part of the standard. Lately I've been registering services via Spring, and they pretty much have all the options you get with DS (like service cardinality), i've seen these in Spring DM and Blueprint services. Seems there's a lot of overlap, is DS still the preferred ... standard way?
 
author
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Augusto Sellhorn wrote:1. Do you guys find it is better to define a service API (Java interface) separate from a bundle providing an implementation? This is the convention I've used in my projects, the idea being that many people can use the API and should provide different implementations.

The only downside of this is you end up with at least 2 bundles always which can kind of clutter up the environment. Sometimes even for simple projects, I can see the argument of providing the API and a "default" implementation in one bundle. Kind of curious what your opinion on this is.



We cover this topic in the book. There is no single answer, it just depends on your situation and your preferences. If someone asked me to recommend an approach, I would probably say keep them separate. The reasoning is maybe not what you'd expect, but I think this approach is the best because people are less likely to do it incorrectly.

Augusto Sellhorn wrote:
2. How important is it to call ungetService(...)? So far I've pretty much ignored it, but I'm sure I'm supposed to be using it somehow. Not sure what the side effects are (or if it really depends on what the service is doing).



We cover this in the book too. No major side effect other than a little bit of memory in the framework keeping track of something you are not using and the inability to have getServicesInUse() return something meaningful. Potentially if service factories are in use, they could be using more memory or resources, depending on what they do.

Augusto Sellhorn wrote:
3. Declarative Services. Are people still using them?

I remember a while ago I started using DS, seemed like a nice idea. But it seems like there's a bit of frameworks that do the same thing, of course not part of the standard. Lately I've been registering services via Spring, and they pretty much have all the options you get with DS (like service cardinality), i've seen these in Spring DM and Blueprint services. Seems there's a lot of overlap, is DS still the preferred ... standard way?



And we cover this in the book too. :-) There is no preferred way, there are just different ways. Both DS and Blueprint are OSGi standards, but neither is preferred over the other. Apache iPOJO is another, non-standard way of doing it. Each has their strengths and weaknesses. You should use the one (or any other) if it meets your needs.
 
Augusto Sellhorn
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, so at least we've established the book covers a lot of topics I'm interested in. :-)

Thanks for the answers!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic