On 06/12/2007, dlaidlaw <[EMAIL PROTECTED]> wrote: > Form mapping the services/JMS stuff to the mediation rules, we are just > starting that now. Up to now there was really only one mediation done with > the message, and that was always performed, and hard-coded in. As I > mentioned before, we used the Spring DefaultMessageListenerContainer in the > past, this executed our MessageListener POJO which executed our single > mediation, then called the target service. > > This is the part we are trying to extend. One thought was to write a more > complex message listener and build a little mediation engine to plug into > it. Another is to replace the whole MessageListenerContainer with Camel. > That is the part I am looking into right now.
Cool, got it. > I do not want the routing rules in spring xml in the target services. We > want to be able to change/customize the routing rules without redeploying > the service bundle. Yeah, we could do an exploded bundle deploy and edit the > files in place. But that does not work well in a server farm where you have > to connect to each server and update it. > > We instead will build a management component that can update service > configuration (using the OSGi Configuration Admin (cm) component). The cm > configuration is also used to inject values into the spring context that is > created at bundle startup using the new spring-dm property-placeholder > support for OSGi. This works like a charm. Coolio. BTW the ServiceMix Runtime detects changes in the cfg files and redeploys bundles on the fly too... > This means our service coders do not have to have any consideration of the > messaging framework in which their service runs. They can assume they are > receiving the message they want, via the API call they expose (we defined an > interface with 1 method). They do not even have to concern themselves with > starting or configuring the message listeners in their spring contexts, > since that is all part of the framework. We want them concentrating on the > business logic they are so good at, not worrying or fiddling with framework > components. My job is to make their jobs easier :) Sounds good :) Are these services registered into the OSGi registry? If so you could use a listener to detect new services being deployed then go off and fetch the right mediation rules for that service etc? There have been a few discussions on the camel lists before about attaching mediation/routing/remoting rules to services as they are registered in spring or OSGi; it might be nice to come up with a little framework in Camel we can reuse when folks want a more dynamic decoupling of the mediation from the services. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
