File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Other Application Frameworks and the fly likes OSGi services best practices Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "OSGi services best practices" Watch "OSGi services best practices" New topic
Author

OSGi services best practices

Augusto Sellhorn
Ranch Hand

Joined: May 24, 2007
Posts: 57
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?
Richard S. Hall
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
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

Joined: May 24, 2007
Posts: 57
OK, so at least we've established the book covers a lot of topics I'm interested in. :-)

Thanks for the answers!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OSGi services best practices