Saturday, August 1, 2009

Spring Integration & OSGi

This is the latest addition to the spring portfolio ,and again they have made it look so simple. This is mainly meant for asynchronous messaging between modules.Here when i say modules it could be within the same JVm or outside. Spring Integration does not provide any framework for inter JVM communication instead it provides adapters for all existing frameworks like JMS,Spring Remoting,HTTP calls ,Web Services etc.

Spring Integration mainly deals with channels , which is a pipe where messages can be put , and there can be any number of subscibers listening to it.We can keep our business logic independent of the frameworks used.Here channels can be of different types direct channels,pub-sub-channel,polling channels etc .Also there are provisions to make the channel synchronous.

It also provides number of adapters like jms adapters,rmi adaptors,web service adpaters such that we always deal in terms of channels i .e we talk to channels and it publishes to the required framework.Since we keep our code independent of any framework it will be easy flip any of these using configuratiosn without affecting teh business logic.

Certain examples i came across which are very descriptive

1.Spring Integration Documentaion Examples(

2.Spring Integration Example(dist/org.springframework.integration.samples-1.0.2.SR1.jar)

3.Blog by Oleg(

Certain points to note.

1.Channels can be published as OSGi service and other bundles can import it and publish on the channel or listen to it.

Note :

When more than one pub sub channel is defined and needs to be published, filter attributes have to be used to distinguish one from teh other.

Ref :

Two models for hiding spring integration apis from bundles

1. Have a seperate bundle(call it exchange bundle) with spring integration configurations.

2. Wrap the channel using gateway() and expose this as a service , which will be used from the publishing bundle.This makes it independent of spring integration APIs and the publishing channel needs to know only about the interface.

3a. Let all teh bundles interested in listening to teh event register with the exchange bundle using a interface.

Implement a service activator in the exchange bundle.The service activator will collect all the OSgi services interested in listening to the service and call teh method one after the other for all registered services.

3b. The service activator will have a register /unregister method ,and teh service activator will be exposed a OSgi service.The interested bundles will import this service and call the register method. On calling thr register method it will add to the list in teh activator, which will call the method when teh event is published on teh channel. (oleg's blog uses teh same model)

No comments:

Free Domain Names @!