Dependency Injection - Best Practice for a newbie ?
Im new to the concept of DI and have a question on best practice. I'll try and explain with the temparature sensor exampleSo if I have 3 different temp sensor applications exposed through the same interface, I know that I can deploy the same app to all 3 of these seperate entities and then wire up the correct implementation of that interface via configuration files. All well and good. DI doing what it;s designed too I guess However lets assume that these apps are on 2 servers each and it's decided that all 3 apps should be hosted on one larger cluster for performance/availability/load balancing etc. Now we have a case where the right implemenation has to be chosen from an attribute (lets assume we have an MDB that gets XML off a JMS queue and decides which sensor to invoke). Now in this case to use DI Im guessing we have to wire up the config with some 'rules' to make this decision. Is this viable?In this instance, is it best practice to house this sort of logic in DI or put the logic in code (i.e a service locator or just hardcoded as if statements in the MDB .. does it matter?)I guess im trying to understand how much this concept can be valid? Were building an inbound interface with similar requirements and im wondering whether to suggest we use Spring to inject which impmentation of a common handler to invoke based on an attribute of the inbound service callTIA !
It sounds like what you need is to use Message Driven POJOS using a Spring based JCA Container
- which as well as all of the dependency injection will perform connection & session & thread pooling, exception handling, retry processing and transaction handling.
See Craig's article
for more details. You can then specify the inbound subscriptions (using queues/topics with selectors if need be - which ActiveMQ
supports XPath based selectors too for XML messages - then use DI to configure your message driven POJOs.
If you want to hide all of the JMS APIs but still use the above DI and JCA mechanisms you can layer Lingo
on top to support Spring remoting with JMS and JCA.
Finally if you find that your integration requirements get pretty complicated (e.g. its not just simple selectors but you want to do more sophisticated content based routing or transformations as well as supporting lots of different kinds of transports; you could consider going with an ESB like ServiceMix
which integrates great with JMS and the JCA container mentioned above.