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中的逻辑。