Spring is in the Air

It’s finally spring and with the “extra hour” courtesy of the DST change you might think the entire Marketcetera team would be out “spring-snowboarding” at Squaw in Tahoe. Well, the snow is slushy, so let’s talk about “the other” Spring instead. Since version 0.2, we are using the Spring Framework to do IoC-based configuration of our server-side components, and we love it. Many transformations of our code become almost trivial when using Spring. As an example, we have recently been working on supporting all versions of the FIX Protocol in our OMS. Until now the OMS only supported FIX.4.2. While that is likely the most common dialect of the protocol, we needed to be able to choose a version of FIX at deploy-time.

Runtime configuration is Spring’s raison d’être. Previously we had a string, “FIX.4.2” somewhere in a .properties file, which we would pass into all kinds of FIX-related objects. However Spring configuration allows us to create version-specific objects directly and inject them into all the classes that need to reference these objects in the code. The flexibility is almost infinite. Want a way to plug your market data feeds into Marketcetera? Change the Spring config file. Want to add another order modifier? Spring config file. Want to modify another fancy feature we haven’t thought up of yet? Spring again. You get the idea. It’s great.

We are also big proponents of some of the more recent Java language features like Java enumerations, and generics. However it’s not immediately obvious how to take advantage of these features in Spring configurations. In becoming FIX-version-agnostic, we wanted a simple way for a system adminstrator to be able to specify the desired FIX version, and the obvious mechanism for this is the Java enumerated type, something like this:

public enum FIXVersion {
FIX40,
FIX41,
FIX42,
FIX43,
FIX44
}

In pure Java code this is great: it means typing errors are caught by the compiler among other things. The first approach we devised to specify one value of this enum from a Spring configuration file was a little convoluted. It involved translating a string to an enum and use the enum later, whereas we wanted to allow the system administrator to specify the enum directly. Unfortunately, Spring’s extensive documentation wasn’t really much help on this particular issue. Enter the Spring community. This thread on the Spring support forum gave us exactly what we needed. Here’s what we ended up with. (Sorry, the ‘…’ are required by our narrow page format)

<bean id="fixVersionEnum" class="org.springf...FieldRetrievingFactoryBean">
<property name="staticField" value="org.marketcet...quickfix.FIXVersion.FIX42"/>
</bean>

In reality the definition of the enumerated type FIXVersion is more complex. Each version specifier looks more like a full-blown Java object that stores references to factories for creating messages and their components. So with these three lines of XML in the Spring configuration we instantiate the entire version managment infrastructure in the OMS.

So that’s (and lovely warm San Francisco weather) is why I like Spring. Look for the simplified and improved configurations, along with order limits in the next release.

Now if only we had time for some snowboarding…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s