• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

What does Consuming OSGi Services mean?

 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's just calling services or does something more?
 
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Currently I'm reading "Modular Java" and I didn't reach the chapter regarding OSGI services but I think it just means calling the service.
BTW Graig, it is an amazing book thank you for every minute you spend writing it.
I always wanted to learn about OSGI but never found a guide, your book is my guide.
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kengkaj Sathianpantarit wrote:It's just calling services or does something more?



There's two sides to this story: In one bundle you have a POJO that implements some interface. Let's say that the POJO is called FooImpl and the interface is called Foo. When that bundle starts, it can register an instance of FooImpl in the OSGi service registry, identifying it by its interface (Foo). This registration can be done programmatically or declaratively (using Spring-DM, iPOJO, or DS).

On the other side is a bundle that consumes the service. The way it consumes the service depends on whether you're doing it programmatically or through one of the declarative service models, but the gist of it is that the bundle asks the OSGi service registry "Do you have anything that implements Foo?" If the OSGi service registry has such a service, it will hand a reference to it over to the consuming bundle and the consuming bundle can make calls on it through the Foo interface. Note that the consumer only knows about the interface...not the implementation (thus the loose-coupling benefit).

A couple of important notes:
- These two sides are in the same JVM...I'm not talking about web-services or any remoting here. (Although OSGi R4.2 offers remote services so that it *could* be across the wire.)
- If the service registry can't find a matching service, several things could happen (it's up to the consumer to decide how to handle it). It could throw an exception or it could block, waiting for a service to become available. Remember, the OSGi runtime is dynamic, so services could come and go as bundles are installed and started or stopped and uninstalled.
- If the service registry finds multiple matches, then the client may choose to consume all of them. In that case it can be given a collection of those service references to work with.

 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks. So consuming OSGi services does cover services discovery, and services calling. Sounds much like web services.

Do OSGi services have services description? So in the case that there are more than one service, it's possible for users to select a service or services to execute.
 
Craig Walls
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kengkaj Sathianpantarit wrote:Thanks. So consuming OSGi services does cover services discovery, and services calling. Sounds much like web services.



Actually, a better comparison might be JNDI/JavaSpaces. To consume a service you just approach the service registry with the interface of the service you want. The service registry gives it to you. The big difference between the JNDI service model and the OSGi service model is that JNDI is a distributed model while OSGi is an intra-VM service model. (That is, until you get to remote services in OSGi R4.2.)

Do OSGi services have services description? So in the case that there are more than one service, it's possible for users to select a service or services to execute.



Like I said...you ask the registry for a service by its interface. The consumer already has the interface in hand (probably because it imported it from another bundle). What could be a better service description than it's interface?

If there are more than one service, then yes...you can get back a collection of matching services and consume all of them.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Craig Walls wrote:

Do OSGi services have services description? So in the case that there are more than one service, it's possible for users to select a service or services to execute.



Like I said...you ask the registry for a service by its interface. The consumer already has the interface in hand (probably because it imported it from another bundle). What could be a better service description than it's interface?


I mean textual description. By users I mean human users (or any intelligent agents), interface is not enough, because you know it's only interface, the caller wouldn't know what would be an implementation.

I think it would be nice if OSGi services can have user-friendly description similar to JavaDoc, because if there are more than one service available, the application would have a choice to let the user decide what services should be executed.
 
Craig Walls
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kengkaj Sathianpantarit wrote:I mean textual description. By users I mean human users (or any intelligent agents), interface is not enough, because you know it's only interface, the caller wouldn't know what would be an implementation.



That's the point! You don't need to know anything about the implementation. All you need to know is its interface and the service registry can give you what you need. That's where the loose-coupling comes into play.

You can further "describe" services with attributes when you register them and then have the service registry only give you services with certain attribute values...but in general the interface is all you need to know.

I think it would be nice if OSGi services can have user-friendly description similar to JavaDoc, because if there are more than one service available, the application would have a choice to let the user decide what services should be executed.



Again, it's just an interface...a Java interface. You can mark up an interface with JavaDoc, right?

And if what you want is a way to pick out certain services among those that implement a certain interface, then again, you can tag those services with certain attributes and then request only those whose attributes match certain criteria.
 
It wasn't my idea to go to some crazy nightclub in the middle of nowhere. I just wanted to stay home and cuddle with this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic