QuickFix/J 源代码

三). 客户化FIX解析
基础知识：以下文章内容描述的前提是已经根据自己的业务规则，生成了符合要求的数据字典，并且使用QuickFix/J自带的 ant 的 jar target生成了客户化的协议解析代码。生成协议解析代码的流程和细节，请参考文章QuickFix/J 源代码研究（二）。

1. 在QuickFix/J的设计中，为了解除message factory和相应的协议的解析代码的耦合关系，quickfix.DefaultMessageFactory会在runtime时使用 reflection动态发现解析协议的代码。因此，如果你有自定义的数据字典，并且已经根据该字典生成了解析该协议的代码，请别忘记在 DefaultMessageFactory中加入相应协议的消息工厂discoverFactory(beginString, factoryClassName)。

2. DefaultMessageFactory有两个主要功能，一个是创建Message（根据beginString和msgType），另一个是创建 Group（根据beginString、msgType和correspondingFieldID）。相应的，根据数据字典生成的解析协议的代码中， 当然有MessageFactory了，而且这个MessageFactory当然会创建Message和Group。

3. DefaultMessageFactory创建Message时，首先根据beginString查找相应版本的消息工厂，找到了则create相应的Message，否则new一个默认的quickfix.Message。

4. MessageCracker的用法。当自动生成解析协议的代码之后，肯定会生成对应版本的MessageCracker。仔细阅读这个新生成的 MessageCracker，你会发现其中有很多的onMessage方法内部没有实现，并且加入了默认的throw new UnsupportedMessageType();语句。在实际使用中，用户需要创建自己的Application，并且extends quickfix.MessageCracker implements quickfix.Application。由于Override，这些throw new UnsupportedMessageType自然会被屏蔽。
如果用户需要取到Message中的内容，做相应的业务逻辑，首先在用户的Application.fromApp中 crack(message, sessionId)，crack类似message cracker的工厂，它根据message header选择相应的message cracker，然后回调相应的onMessage。onMessage正好在用户Application中Override实现。

5. 客户化协议的客户端Initiator实现总结
a) 创建处理类，extends MessageCracker implements quickfix.Application implements quickfix.ApplicationExtended
b) 在fromApp中添加crack(message, sessionId);
c) 对需要处理的消息实现相应的onMessage
d) 创建SocketInitiator实例，填入客户化的application，messageStoreFactory，settings，logFactory，messageFactory。
e) start initiator。

6. 如果想把收到的每个消息单独存成一个文件备份，比如dbf之类的，该如何实现？
a) 方案1. 实现自己的MessageStore。QuickFix/J中提供了现成的FileStore，可以将所有的消息存入同一个文件中。
b) 方案2. 在Application的fromApp接口中，获取相应的Message，提取所需要素，存盘。
两个方案的比较：方案2减少了一次从String到Message的解析，效率应该更高。因为MessageStore的输入是StringMessage，需要再次解析才能得到Message。

7. FIX标准协议中规定了消息(Message)应该都至少有一个字段(Field)，如果在客户化自己的FIX协议解析时，发现某些Message没有字段，则需要解除QuickFix/J中对这个条件的限制，具体在quickfix.Dictionary。

private void load(Document document, String msgtype, Node node) throws ConfigError {
...
//        if (fieldNodes.getLength() == 0) {
//            throw new ConfigError("No fields found: msgType=" + msgtype);
//        }
...
}

8. 在QuickFix/J的实现中，关于不同版本的协议都有这样一个假设，就是如果Fix版本号小于等于"FIX.4.4"则是一种逻辑，大于FIX4.4 是一种逻辑。那么就需要注意在客户化时你定义的协议版本（即FIX的beginString）是多少，是不是从字符串比较的角度看小于等 于"FIX.4.4"。如果不是，则需要在诸多的地方更改QuickFix/J的逻辑。比如在quickfix.DataDictionary.load 中：

private void load(InputStream inputStream) throws ConfigError {
...
        if (beginString.startsWith(FIXT_PREFIX) || beginString.compareTo(FixVersions.FIX50) < 0) {
        ...
...
}

9. QuickFix/J在实现中，默认消息(Message)头(Header)中使用的时间都是UtcTimeStamp，如果在客户化中不使用UTC时间，而使用本地时间的化，
a) 添加本地时间的数据类型，比如LocalTimeStampField，可以仿照quickfix.UtcTimeStampField。其他还需要添加 跟本地时间相关的 LocalDateOnlyField，LocalTimeOnlyField，LocalTimeStampConverter，LocalDateOnlyConverter，LocalTimeOnlyConverter
b) 在使用TimeStamp的地方，添加版本判断，根据版本看是使用本地时间还是UTC时间。需要修改地方大概 有：Session.doTargetTooHigh，Session.generateSequenceReset，Session.initializeResendFields，Session.validatePossDup，Session.verify。

10. QuickFix/J在实现中，心跳设置（HeartBtInt）由客户端（Initiator）决定，而STEP协议则规定心跳由服务器端 （Acceptor），这需要修改DefaultSessionFactory.create(sessionID, settings)中关于角色和HeartBtInt的设置。并且还需要修改Session.nextLogon(message)中登陆之后读取 HeartBtInt并设置到state中的逻辑。