|
From: Alvin W. <AW...@FF...> - 2006-11-16 20:50:43
|
pls see my comments below. thanks.
Oren Miller
<oren@quickfixeng
ine.org> To
Sent by: qui...@li....n
quickfixj-users-b et
ou...@li... cc
ceforge.net
Subject
Re: [Quickfixj-users] repeating
11/09/2006 07:21 group problem
PM
Please respond to
quickfixj-users@l
ists.sourceforge.
net
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
> I believe QFJ is only dependent on generated field definitions. Do you
> manually maintain the C++/Fields.h file? Is that where the C++ Session
> gets it's field definitions rather than the generated field
> definitions?
Yes, the messages are decoupled, the fields are not. It's not really
been much of a problem though since when using non typesafe methods
the messages don't care what the field is as long as the number and
type are correct. I guess it is conceivable future versions of fix
could change the names or types of the core session fields, but I
don't think it's very likely. Theoretically this could be decoupled
as well, though if any of those fields are missing you don't really
have a FIX session anymore. Perhaps that would be a legitimate thing
to do if you plan on using another transport as made possible by FIX
5.0.
> I can't speak for Alvin, but I've been in several situations where
> I've needed to map domain objects to multiple versions of FIX
> and vice versa.
Oh yeah, me too. In those situations there's a choice about whether
to use compile time type safety or use dynamic logic. Using type
safety requires some more coding, but you have the benefits of the
compiler letting you know when something is wrong. Dynamic code
doesn't give you that, but it allows you to create more compact code
by allowing you to share. I'm not really sure how you can get both
those benefits at the same time. Classic case of dynamic vs compile
time type safety.
> My impression was that Alvin didn't want to give up all type safety,
> but wanted a message representation with more abstractions for common
> aspects of the currently generated message classes. Personally, I
> would just use the message objects directly as you've suggested.
Yeah, I think so to, I'm just not sure how that would be
accomplished. Perhaps an example would be helpful. The problem is
of course that messages change pretty significantly between versions
sometimes. Fields get added, removed, their type changes, groups are
added, groups are modified etc. etc.
Yes. This is what I meant. Personally, I like to gain flexibility and
reusability at the cost of some compile time safety, because as I said
sooner or later how easy users can maintain cross-version code base will
become a problem/concern. So it will either be a QF(J) maintainability
issue or client code maintainability issue. We may get rid of version in
package structure. and specify version number in constructor and use
(internal) validation method to guarantee the integrity and consistency
with the FIX spec. So there will still be an NewOrderSingle class but not
bound to version. (We can even put a NewOrder abstract class on the top to
increase reusability).
Out of topic. BTW, it will be very nice to have a
Message.getInstance(String strMessage) method to convert a string msg to
corresponding message object like NewOrderSingle (not just the plain
message object)
Just my 2 cents. I have not got chance to think through everything yet. and
i agree/understand this will easy to say that to do.
Alvin
Groups are actually a case where you can take advantage of some
sharing. If groups have not significantly changed between versions,
their is no reason you cannot call addGroup on a FIX.4.2 messages or
a FIX.4.4 message with the same generated group object. Making
components into objects might be helpful in this regard as well.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
*******************************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and
confidential.
Disclosure to anyone other than the intended recipient is prohibited.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise. Instead,
please notify us immediately by return e-mail(including the original
message with your reply) and then delete and discard all copies of the
message. We have taken precautions to minimize the risk of transmitting
software viruses but nevertheless advise you to carry out your own
virus checks on any attachment to this message. We accept
no liability for any loss or damage caused by software viruses.
*******************************************************************************
|