Gateway for receiving messages

[sudheerk84]

I went through this bog and it was very useful in understanding most of the concepts of spring integration.

http://blog.springsource.com/2009/02...-on-dm-server/

But i was stuck at one point

I tried to follow a similar model for my application with 3 bundles

Bundle A(sender) - unaware of spring integration API

Bundle B(receiver) -unaware of spring integration API

Bundle X(channel exchange) -aware of spring integration API


Now i define a channel in bundle X ,and wrap it using a gateway.

Now i expose this gateway as a service implementing my interface.

Bundle A is able to send messages into the channel using interface on the gateway proxy,and is till unaware of the spring integration API'S

Now how does Bundle B receive this message which is on the channel ?

1. I do not want to publish this channel as OSGi service from bundle X and import in bundle B because it makes bundle B integration aware.

2. The other option I see is

Bundle B registers an OSGi service with Bundle X , and bundle X will call this service whenever message is put into the channel by bundle A.

But this makes my bundle X(channel exchange) more complicated as more recevers may need to listen to this channel and i have to write code to iterate through these services and call method one after the other.

Is there any simpler way to achive this ? can i use teh gateway proxy itself by nay means ?

[oleg.zhurakousky]

You can register ServiceActivator which is a POJO and expose it as an OSGi service. This way your bundle is going to be SI unaware.
We are doing something similar in the osgi-inbound and osgi-outbound samples, so I wold suggest to take a look there.
Cheers

[sudheerk84]

Thanks again for the reply.

Can u point me to the examples(osgi inbound and outbound) u were mentioning about ?

Where can i find those ?


I have gone though towncrier(blog) example and cafe bar(reference guide) example .

Is it different from those ?

[Mark Fisher]

The 'osgi-inbound' and 'osgi-outbound' samples that Oleg is referring to are included in the recent 1.0.3 release. You can find an overview of those samples in the reference manual:
http://static.springsource.org/sprin...l#samples-osgi

Also, Oleg is planning to post a detailed blog about those samples sometime this week. So, keep an eye on http://blog.springsource.com/

[sudheerk84]

Thanks Mark for the quick reply

[sudheerk84]

I did go across the 1.0.3 samples including osgi inbound and outbound examples.


using the following link

http://blog.springsource.com/2009/07...ust-add-maven/

osgi-inbound
-------------
<osgi:service id="inboundService" ref="inboundChannel"
interface="org.springframework.integration.channel .SubscribableChannel"/>


osgi-outbound
---------------
<osgi:reference id="filesIn"
interface="org.springframework.integration.channel .SubscribableChannel"/>


This example again follows the same old style as in other examples

It would be helpful if you can export the service activator instead of channel as a OSgi service.[As suggested by the earlier comment in this same thread]

You can just consider it as a suggestion , which may help lot of people to understand it better

[Mark Fisher]

Thanks for the feedback. Maybe Oleg can include that in his upcoming blog post

[oleg.zhurakousky]

I'll think about it, but one of the benefits of exposing channel as an OSGi service is the ability to start adding subscribers which themselves cold be a whole new bundles without ever restarting the producer bundle

[sudheerk84]

Hi Oleg,

Why cant we achieve the same flexibility by your previous solution of Exposing Service Activator from producer bundle ?

May be we need to have the producer bit more intelligent to iterate over all the services registered with it, and call the event one after the other ?

Now adding a new consumer should not effect any other bundles .

Isnt it right ? Or Am i missing anything ?

[oleg.zhurakousky]

First, let me say that you are correct. . . it is doable, since we are dealing with pub-sub channel. However, having said that this would require producer bundle to know in advance how many consumers there need to be. And even if it was only one SA consumer exposed as an OSGi service you could potentially create a POJO-like event infrastructure to distribute message across multiple self-made consumers.
However, our goal with this particular example was to showcase the beauty of SI while deployed on OSGi platform, where channel is advertised as an OSGi service and you can now start benefiting from OSGi Service Dynamics by developing other bundles which will play a role of consumers. And as you well understand, consumers are dynamic by definition and can come and go at any time without affecting the producer bundle.
One other idea is that such consumers could expose SAs as OSGi services and therefore will play a role of intermediary consumers with one goal in mind and that is exposing POJO SA as an OSGi service, so you can further modularize your application by creating other bundles as true consumers which will subscribe to these SAs services.