This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes What does Consuming OSGi Services mean? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "What does Consuming OSGi Services mean?" Watch "What does Consuming OSGi Services mean?" New topic
Author

What does Consuming OSGi Services mean?

Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
It's just calling services or does something more?


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Hussein Baghdadi
clojure forum advocate
Bartender

Joined: Nov 08, 2003
Posts: 3479

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.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
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.


Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
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

Joined: Jul 05, 2005
Posts: 1936
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
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What does Consuming OSGi Services mean?