Two way communication across OSGi bundles

[concombremasqué]

Hi there,

I would like to have some feedbacks regarding what you consider to be the best way to make two OSGi bundles communicate with each other (i.e. bundle 1 calls bundle 2 and bundle 2 can call back bundle 1).

If I use Camel, I saw that the VM component can achieve that (just to have a route in each bundle and then the bundles can exchange data through this VM component). Ok.

But how can I do that with an OSGi service? I mean: is it possible to define callback methods?

Given a bean registered as an OSGi service, the Spring DM documentation states that there is only one instance of this bean shared by all OSGi client bundles (unless you make use of the "bundle" scope). It seems then difficult to have dedicated callback methods as all clients share the same object.

Any advice would be greatly appreciated.

Thanks,

CM.

[davsclaus]

You can use the ServiceMix NMR

http://camel.apache.org/nmr.html

http://servicemix.apache.org/SMX4NMR/index.html

[concombremasqué]

Hi Dave,

So should I understand that it is not possible to have callback methods exposed by an OSGi service?

I thought NMR was only involved when dealing with JBI components. It can be used as well with pure OSGi bundles? How does it compare to the VM Camel component in term of performance (in short: why I would prefer the NMR vs the VM component)? Can the NMR be directly used by OSGi bundles without Camel?

Thank you.

CM

[cmoulliard]

Hi Concombre Masqué (= Arsène Lupin ?),

The OSGI specification is working on a solution to allow OSGI service to be called remotely. Apache CXF project already implements this.

More info available here : http://cxf.apache.org/distributed-osgi.html

Here is the reply to your questions :

I thought NMR was only involved when dealing with JBI components. It can be used as well with pure OSGi bundles?

>> Yes. NMR can be used now by registering directly camel endpoints to it.

How does it compare to the VM Camel component in term of performance (in short: why I would prefer the NMR vs the VM component)?

>> NMR bus is different from Camel Bus as messages that will be processed by it must be XML compliant and MEP are handled differently. I think that NMR will be slower than Camel in some points due to XML transformation.

Can the NMR be directly used by OSGi bundles without Camel?

>> Yes. There is a class that you can use from a bundle to connect to the NMR bus (= http://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/examples/nmr/client/src/main/java/org/apache/servicemix/nmr/examples/nmr/client/Client.java).

Kind regards,

Charles Moulliard

[davsclaus]

Camel VM cannot be used in OSGi.

NMR is designed to be like the VM / JBI for OSGi.

[concombremasqué]

Hi Charles (and yes, I am Arsène Lupin, glad to see you here )

Regarding my first question: maybe we are talking about something different. I don't think it is related to remote OSGi (or distributed OSGi). But correct me if I am wrong.

Let's take the following example (what I try to achieve):

1- OSGi bundle 'A' references an OSGi Service implemented by OSGi bundle 'B'

2- OSGi bundle 'A' performs a call to a method exposed by the OSGi Service interface (thus it calls a method located in OSGi bundle 'B')

Ok. Steps 1 & 2 are easy and well documented as of today. Let's go to step 3.

3- After performing some tasks, bundle 'B' needs to notify or send data back to bundle 'A' (I don't want 'A' to poll 'B' to get the results).

I would like to be able to do such a thing using only pure OSGi mechanism (no Camel, no NMR etc...). To do so, I imagine I would have to add to the OSGi Service interface a method accepting a callback object as a parameter (maybe this would involve some Future interface?). This callback object will be implemented in bundle 'A'. Bundle 'B', as it implements the OSGi Service interface, will then be able to send data back to bundle 'A'.

Possible or not?

As for my questions on the NMR, thank you. But it is still not obvious to me whether to use Camel VM or Camel + NMR to exchange data between bundles (if my OSGi Service wish above cannot be realized).

Kind regards,

CM

[gertv]

L.S.,

Once you get hold of the object in the OSGi service registry, you can use any kind of Java code you want to interact with it.  E.g. you could code something like this in the client bundle

service.myServiceMethod("Some business data", new MyCallbackInterface {
  public void callBackMethod(Object response) {
    //TODO: handle the reponse method coming back
  }
});

You service can then, in its myServiceMethod implementation, invoke the callback method on the interface once its work is done.

Another, more OSGi'ish way of dealing with it, would be by creating an API bundle that defines your business service interface as well some event listener interface.  You can then build:

- bundle A to register the OSGI service implementation and track any instances of the listener interface, injecting them back into the service implementation instance (e.g. you can easily do this with blueprint)

- bundle B to create a service client object that implements the event listener interface and register that in the OSGi service registry as well

This way, the service can notify any listeners (including the service client object) that are registered.  This design will also allow you to build additional bundles that register listener interface implementations to follow up on what happens inside the service bundle.

Hope this helps,

Gert

[concombremasqué]

Hi Gert,

Yes it helps a lot

Thank you.

CM

[cmoulliard]

Hi,

I think that we can achieved the result 'event notification of a bundle' using the Event Admin mechanism available in OSGI :

Here is an example using java + spring :

http://java.dzone.com/articles/osgi-event-admin-with-spring-d

or a Distributed Event

http://wiki.eclipse.org/Distributed_EventAdmin_Service

Kind regards,

Charles