The current implementation of QuickFIX/J uses the message representation defined by QuickFIX JNI implementation (no longer supported by the QuickFIX C++ project). The representation is not idiomatic Java and this not only makes it’s more difficult for Java programmers to work with but also increases the challenges when processing QuickFIX/J messages using other Java tools. Since compatibility with previous versions of QuickFIX/J is desirable, the existing message presentation would continue as one of the supported plugins. Another simple, but useful representation would be a java.util.Map where groups are represented as lists of nested maps. This would not be a particularly high performance representation but would be much easier to use than the current representation. For higher performance, it may be possible to pull data directly from the message byte buffer when it’s requested. The point is that plugin support would allow QuickFIX/J to support various ease-of-use versus performance trade offs.

It’s also possible that we could support application-defined POJO’s as the message payload. Instead of the FIX message being parsed into QuickFIX/J objects and then copied into an application object (a common practice), the message would be demarshalled directly into the application object. This could be supported through a combination of external configuration, Java annotations or convention. The application-specific object would then be passed to the application with no further conversion required. A similar approach could be used for message publication where application-specific object data is used to build the output FIX message byte buffer.

A notional example might be:

import static MessageName.*;
import static FieldName.*;
import static GroupName.*;
. . .

@Message(name=NewOrderSingle)
public class Order {

   // Convention
   public void setPrice(BigDecimal price) {
      . . .
   }

   // Automatic conversion between int and BigDecimal for FIX 4.0 ...
   @Field(name=OrderQty)
   public void setQuantity(BigDecimal price) {
      . . .
   }

   @Field(tag=MyUserDefinedTag)
   public void setMyValue(string value) {
      . . .
   }

   @Group(name=NoPartyIds)
   public void setParties(List<tradeparty> parties) {
      . . .
   }
}

One nice side-effect of this approach is that only messages that are interesting to the application are mapped in this way. This eliminates the current need for large message JARs mostly full of messages that are never needed.

The message representation plugins would be packaged as a JAR containing a message demarshaller, a message marshaller, a metadata provider and supporting classes. QuickFIX/J currently performs message framing on incoming data stream and places detected messages in byte buffers. This code would be reused from the existing code base and the byte buffer would be passed to the message demarshaller. At this point, the demarshaller is only required to decode the FIX header and trailer fields since these are required by the FIX session engine. The FIX body fields are only decoded as needed, ideally just before the message is passed to the FIX application. This could be a big performance win for FIX routing application that don’t process the FIX message body.

The message metadata would be used for message validation and, internally, for message parsing and formatting. However, the metadata would not be required to be in any specific format. Although the QuickFIX/J data dictionaries would still be supported, other plugins could use the FIX Repository or a proprietary message metadata format.

This is only one of many areas where I believe we could improve QuickFIX/J usability and performance. The nice thing about this feature is that it would have minimal, if any, impact on existing applications. Comments?

We released the 1.0.0 beta 2 version last month and are about ready to release the 1.0.0 beta 3 within a few weeks. The beta 3 will feature the conversion to the Apache MINA networking library and updates of the functionality to be compatible with the recently released QuickFIX 1.11.0.

Stay tuned…