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. 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. 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 :) James.Strachan wrote: > > > snip > >> Thanks James! > > You're welcome! > > Sounds an interesting project you're working on! > > Incidentally how are you mapping your services/JMS stuff to the > mediation rules required? Its an interesting idea having totally > de-coupled routing & mediation rules to your services and when a > service is deployed, the routing rules are chosen and then deployed > etc. > > You could always just put the routing rules as a spring XML inside the > same bundle as your services I guess; but I can see how sometimes it > might be nice to de-couple them, so the mediation rules can change > independently of a service bundle. > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > > -- View this message in context: http://www.nabble.com/Dynamically-changing-routes-%28OSGi%29-tf4951904s22882.html#a14194475 Sent from the Camel - Users mailing list archive at Nabble.com.
