Spring Integration
Sample Implementation
 | This is a slightly modified version of what we've implemented at my company. I haven't tested my modifications, so I apologise if it doesn't work exactly but it should give you an idea of what can be done. It should work with quickfixj 1.0.0/Spring 1.2.5. |
This was all written before MINA 0.9 was being used. MINA 0.9 has its own spring integration classes, and (at least in theory in my head) it would be really nifty if quickfixj just hooked into these as it would open up some extra customisation possibilities such as SSL Filters.
Brad, thanks for adding this information. This is very similar to an approach I've been thinking about. Barry Kaplan also prototyped an somewhat different approach and I've added his example configuration files for discussion purposes. I'd like to create an abstraction for the session settings so an application could either use an existing QF settings file, create the settings directly in a Spring configuration, or plug in an external session configuration provider (possibly supporting dynamic creation and deletion of sessions). I'll look into the Mina 0.9 Spring integration classes and see how those could be incorporated as well. I'm thinking of restructuring the QFJ project to allow a sibling quickfixj-spring subproject that would be released separately from the core quickfixj code. I also want to try using some of the new Spring 2.0 features to make the configuration file easier to manage. I'll add a page soon with ongoing experiments that I'm doing as well. Thanks again. Steve Bate
No worries. I agree that being able to supply other implementations of SessionSettings would be useful. It'd also be nice to have a common interface for initiator/acceptor.
I think in some ways SessionSettings is a bit anti-spring since you're not making use of dependency injection for most of the configuration. Moving away from SessionSettings takes you towards Example - Barry Kaplan which is more flexible at the expensive of a steeper learning curve for quickfix and spring newbies.
I guess it depends whether you want quickfixj powered by Spring internally or just Spring friendly for those who want to use it. Presumably the latter if you're leaning towards an optional subproject, which I think is a good idea.
Brad Harvey
Application Context
Here's the basic application context. You supply an Application implementation and quickfix will start up once the application context is loaded. Aside from your Application you also need sample.QuickFixBean which does most of the work.
We also add in the following to get some basic JMX admin going. It requires an MBean server to be already be running. An easy way to do this is to use java5 and add -Dcom.sun.management.jmxremote to your startup parameters. You can then use jconsole ($JAVA_HOME/bin) to view your MBean.
sample.QuickFixBean
Starting it up
Now you just need to load your application context - put quickfixContext.xml on your classpath and do something like this:
Or, for extra kicks put it in a servlet using a spring ContextLoaderListener in web.xml.
1 Comment
comments.show.hideNov 27, 2006
Colin Crist
Whilst Spring is great for wiring up an application I don't like domain configuration data there and
I'd not want my support guys having to edit XML for each session as its too error prone.
A more natural home for all the session stuff is via a DAO layer with both database and file based implementations - the file one could in fact be other Spring contexts containing stuff like above. The database implplementation could use Hibernate and then both of them share the domain configuration data objects, e.g. SessionConfig objects. Spring would then wire up which DAO implementation you'd have.
Any configuration GUI would then deal with DAO but use the database in a large installation whilst small ones could get manual with XML. The file based DAO would not support editing of the configuration data whilst the database implementation would.
Of course there are also all the nice enterprise features of a database to...