Imported from previous forum
We are experimenting with FIXML. We found this is a fairly large XML schema definition and to have our application to support FIXML, there are tons of XML parsing/validation to be done. We are wondering anybody is serious using FIXML in the community and how do they deal with the FIXML parsing/validation?
We are experimenting with FIXML. We found this is a fairly large XML
schema definition and to have our application to support FIXML, there
are tons of XML parsing/validation to be done. We are wondering anybody
is serious using FIXML in the community and how do they deal with the
FIXML parsing/validation?
The right approach is to create a component layer that deals with the XmL to object conversion and validation. This is the design pattern that people use. This layer does two things,
-
XML and object conversions.
It does the XML parsing under the cover and when there is an incoming XML, it will do all the parsing and object constructions for you. You will be given the result, a top level object, like FIXML object. You will then be able to drill down and query this object using assessors and get all the data you need. The object to XML conversion is just a reverse of the information flow. You construct a FIXML object, set all the necessary data using “setters”. This well constructed object will be given to the component layer, which will convert it from an object to XML string. -
XML validation toward the schema definition.
The incoming XML and outgoing XML should follow the FIXML schema definition. A schema validation engine should be part of the component layer. A good validator should be able to pin point any errors with understandable reasons.
I have built a component layer for a very small XML schema (not FIXML) and the result is very impressive. Our application developers never have to deal with the XML parsing any more. It is all taken care by the component layer.
However, FIXML is a fairly large and complicated XML schema. To build such a component layer takes considerable time and efforts. I did a google search and found this company that claims it has already build a complete object model for FIXML, http://www.alotsoft.com.
[ original email was from Paul Sacristan - psacristan@NYMEX.com ]
An additional thing to note is that most FIXML implementations seem to be context specific. For instance, as far as I have heard, it is not being used for order entry anywhere. In the derivatives world, FIXML is being used mostly for the Post-Trade clearing messages (Trade Capture, Position Maintenance, etc.), with some Security Definition thrown in.
Point being, you may not need to build support for all messages in FIXML, just specific portions of the schema.
Also note that in the derivatives world, that schema is undergoing some proposed changes in the FIA Extensions. Check out the FIA Extensions working group for more info.
http://www.fixprotocol.org/working_groups/fiaextwg/
Regards,
Paul
We are experimenting with FIXML. We found this is a fairly large XML
schema definition and to have our application to support FIXML, there
are tons of XML parsing/validation to be done. We are wondering
anybody is serious using FIXML in the community and how do they deal
with the FIXML parsing/validation?The right approach is to create a component layer that deals with the
XmL to object conversion and validation. This is the design pattern that
people use. This layer does two things,
XML and object conversions. It does the XML parsing under the cover
and when there is an incoming XML, it will do all the parsing and
object constructions for you. You will be given the result, a top
level object, like FIXML object. You will then be able to drill down
and query this object using assessors and get all the data you need.
The object to XML conversion is just a reverse of the information
flow. You construct a FIXML object, set all the necessary data using
“setters”. This well constructed object will be given to the
component layer, which will convert it from an object to XML string.XML validation toward the schema definition. The incoming XML and
outgoing XML should follow the FIXML schema definition. A schema
validation engine should be part of the component layer. A good
validator should be able to pin point any errors with
understandable reasons.I have built a component layer for a very small XML schema (not FIXML)
and the result is very impressive. Our application developers never have
to deal with the XML parsing any more. It is all taken care by the
component layer.However, FIXML is a fairly large and complicated XML schema. To build
such a component layer takes considerable time and efforts. I did a
google search and found this company that claims it has already build a
complete object model for FIXML, http://www.alotsoft.com.
With the schema you can do this in an automated fashion using JAXB (for the java class generation and marshalling/unmarshalling class) or XSD.exe for the .NET equivalent.
David Patton
CC Pace
We are experimenting with FIXML. We found this is a fairly large XML
schema definition and to have our application to support FIXML, there
are tons of XML parsing/validation to be done. We are wondering
anybody is serious using FIXML in the community and how do they deal
with the FIXML parsing/validation?The right approach is to create a component layer that deals with the
XmL to object conversion and validation. This is the design pattern that
people use. This layer does two things,
XML and object conversions. It does the XML parsing under the cover
and when there is an incoming XML, it will do all the parsing and
object constructions for you. You will be given the result, a top
level object, like FIXML object. You will then be able to drill down
and query this object using assessors and get all the data you need.
The object to XML conversion is just a reverse of the information
flow. You construct a FIXML object, set all the necessary data using
“setters”. This well constructed object will be given to the
component layer, which will convert it from an object to XML string.XML validation toward the schema definition. The incoming XML and
outgoing XML should follow the FIXML schema definition. A schema
validation engine should be part of the component layer. A good
validator should be able to pin point any errors with
understandable reasons.I have built a component layer for a very small XML schema (not FIXML)
and the result is very impressive. Our application developers never have
to deal with the XML parsing any more. It is all taken care by the
component layer.However, FIXML is a fairly large and complicated XML schema. To build
such a component layer takes considerable time and efforts. I did a
google search and found this company that claims it has already build a
complete object model for FIXML, http://www.alotsoft.com.
Does somebody knows the benefits of using a commercial library from vendor like www.alotsoft.com compared to classes generated from the XML Schema?
(personally, I use another possible approach, based on a native XML processing language from which I can call existing java code, so I don’t need to deal with XML Schema compilation into Java or C# code, and have the advantage of static type checking based on XML Schema constraints, but anyway, I’m curious to understand the benefits and limits of other approaches).
Thanks
Guillaume
Guillaume
-
With something like JAXB, you generate and compile the object model (java classes) once. Then you can marshall/unmarshall XML on the fly and validate either the XML or THE OBJECTS against the FIXML schema. I’d be happy to consult with you if you want further assistance.
-
It looks like the value AlotSoft is providing is that they have a web service based integration platform to which you submit the XML. I have no knowledge of it.
-David Patton
CC Pace
Does somebody knows the benefits of using a commercial library from
vendor like www.alotsoft.com compared to classes generated from the
XML Schema?(personally, I use another possible approach, based on a native XML
processing language from which I can call existing java code, so I don’t
need to deal with XML Schema compilation into Java or C# code, and have
the advantage of static type checking based on XML Schema constraints,
but anyway, I’m curious to understand the benefits and limits of other
approaches).Thanks
Guillaume
How to auto generate java class by JAXB from FIXML file? I use maven-jaxb2-plugin to convert regular xsd to one time java classs. Same plug-in is not helping with this fixml file Securities.xml, which has
…
Guillaume
With something like JAXB, you generate and compile the object model (java classes) once. Then you can marshall/unmarshall XML on the fly and validate either the XML or THE OBJECTS against the FIXML schema. I’d be happy to consult with you if you want further assistance.
It looks like the value AlotSoft is providing is that they have a web service based integration platform to which you submit the XML. I have no knowledge of it.
-David Patton
CC PaceDoes somebody knows the benefits of using a commercial library from
vendor like www.alotsoft.com compared to classes generated from the
XML Schema?(personally, I use another possible approach, based on a native XML
processing language from which I can call existing java code, so I don’t
need to deal with XML Schema compilation into Java or C# code, and have
the advantage of static type checking based on XML Schema constraints,
but anyway, I’m curious to understand the benefits and limits of other
approaches).Thanks
Guillaume
Check out the CAMeditor toolkit on sourceforge - http://www.cameditor.org
Ingest your schema - exclude/optimize as needed - then generate new XSD + JAXB binding for that.
Instructional videos available on Youtube
David Webber
How to auto generate java class by JAXB from FIXML file? I use maven-jaxb2-plugin to convert regular xsd to one time java classs. Same plug-in is not helping with this fixml file Securities.xml, which has
…
Guillaume
With something like JAXB, you generate and compile the object model (java classes) once. Then you can marshall/unmarshall XML on the fly and validate either the XML or THE OBJECTS against the FIXML schema. I’d be happy to consult with you if you want further assistance.
It looks like the value AlotSoft is providing is that they have a web service based integration platform to which you submit the XML. I have no knowledge of it.
-David Patton
CC PaceDoes somebody knows the benefits of using a commercial library from
vendor like www.alotsoft.com compared to classes generated from the
XML Schema?(personally, I use another possible approach, based on a native XML
processing language from which I can call existing java code, so I don’t
need to deal with XML Schema compilation into Java or C# code, and have
the advantage of static type checking based on XML Schema constraints,
but anyway, I’m curious to understand the benefits and limits of other
approaches).Thanks
Guillaume
Great. I am able to do it. Thank you.
Check out the CAMeditor toolkit on sourceforge - http://www.cameditor.org
Ingest your schema - exclude/optimize as needed - then generate new XSD + JAXB binding for that.
Instructional videos available on Youtube
David Webber
How to auto generate java class by JAXB from FIXML file? I use maven-jaxb2-plugin to convert regular xsd to one time java classs. Same plug-in is not helping with this fixml file Securities.xml, which has
…
Guillaume
With something like JAXB, you generate and compile the object model (java classes) once. Then you can marshall/unmarshall XML on the fly and validate either the XML or THE OBJECTS against the FIXML schema. I’d be happy to consult with you if you want further assistance.
It looks like the value AlotSoft is providing is that they have a web service based integration platform to which you submit the XML. I have no knowledge of it.
-David Patton
CC PaceDoes somebody knows the benefits of using a commercial library from
vendor like www.alotsoft.com compared to classes generated from the
XML Schema?(personally, I use another possible approach, based on a native XML
processing language from which I can call existing java code, so I don’t
need to deal with XML Schema compilation into Java or C# code, and have
the advantage of static type checking based on XML Schema constraints,
but anyway, I’m curious to understand the benefits and limits of other
approaches).Thanks
Guillaume
Does somebody knows the benefits of using a commercial library from
vendor like www.alotsoft.com compared to classes generated from the
XML Schema?(personally, I use another possible approach, based on a native XML
processing language from which I can call existing java code, so I don’t
need to deal with XML Schema compilation into Java or C# code, and have
the advantage of static type checking based on XML Schema constraints,
but anyway, I’m curious to understand the benefits and limits of other
approaches).Thanks
Guillaume
Buy vs. build is a decision that every FIXML adopter must make.
In my opinion, to build means that you have the source code. This can come in handy at times. Free code generation tool has disclaimer comes with it and you will bear the burden of supporting an unfamiliar code
base.
Commercial library comes with a price tag. A well written library should be cleanly debugged software that you can depend on. You may want
to do a research of the vendors that provide such library. Does anyone
have a full list of vendors that provide FIXML object model, like alotsoft, in this field?
Buy vs. build is a decision that every FIXML adopter must make. In my
opinion, to build means that you have the source code. This can come in
handy at times. Free code generation tool has disclaimer comes with it
and you will bear the burden of supporting an unfamiliar code base.Commercial library comes with a price tag. A well written library should
be cleanly debugged software that you can depend on.
Are you saying that code generated from tools such as xsd.exe, castor and the likes is not bug-free? what kind of bugs are you referring too for instance?
You may want to do
a research of the vendors that provide such library. Does anyone have a
full list of vendors that provide FIXML object model, like alotsoft, in
this field?
Buy vs. build is a decision that every FIXML adopter must make. In my
opinion, to build means that you have the source code. This can come
in handy at times. Free code generation tool has disclaimer comes with
it and you will bear the burden of supporting an unfamiliar code base.Commercial library comes with a price tag. A well written library
should be cleanly debugged software that you can depend on.Are you saying that code generated from tools such as xsd.exe, castor
and the likes is not bug-free? what kind of bugs are you referring too
for instance?
These public domain free code generation tools are still very green. A tool may be able to cover certain aspect of XML schema. However, it may miss other aspects. It is a hit or miss situation. For example, I know not all tools support substitution groups. Some tools couldn’t deal with inheritance.If you look at the source code of some of the open source tools, you can even see comments like, “Functionality to be implemented in next release” Each tool will generate a lot of code for you. However, are you going to trust them?
It is one thing to do a proof of concept project for a small XML schema. It is a different story if it is a large complicated industry strength schema, like FIXML, and you will put it in your enterprise’s mission critical production environment.
Free public domain tools are good things. However, that doesn’t replace one’s own thorough research and objective judgement.
Are you saying that code generated from tools such as xsd.exe, castor
and the likes is not bug-free? what kind of bugs are you referring too
for instance?
I got a lot of experience with the xsd.exe and the FIXML xsd’s the last 6 month. For simple and quickly launched applications it might work fine, but if you want to integrate the FIXML business model into your application, you soon get very angry about the quality of the source code, generated by the xsd.exe.
Just some points, which drove me crazy:
- No support of interfaces
- No generation of properties and private members, just public variables
- No mark of mandatory properties, no automatic constructor generation with mandatory parameter
- Very poor inheritance support
- No namespace separation. You have to built several DLL’s, if you want to cover the complete model
- No integration of the documentation tags
- No integration of AppInfo tags. It is relevant for all the enumerations, they are added as AppInfos to the schema
- and and and …
JAXB does a much better job, but still not cover all the demands.
As we have chosen .net as the platform for GUI’s, I decided to built an own xsd code translator. This is the only way to get a clear source code and object model out of the FIXML xsd.
We found some fragments in open source projects but still it took us more than 4 month and a deep digging in the System.CodeDom assembly to finish our compiler.
And this makes things much more easier now! Especially integration of the enumerations make the understanding of FIXML much more easier.
So, if anybody is interested about, just write an email to fixml@suft.de
Hi,
I would not entirely agree with listed defects of xsd.exe below. It is possible to design your schema in a way, so that inheritence is available to you when classes are generated from xsd.exe. Please read this article for detailed explanation.
http://www.topxml.com/xmlserializer/xmlincludeattribute.asp
-Anand
An approach I’ve seen used at clients is to generate an object model in
the same way that we, the FPL GTC, generate the schema. EG from the
repository.The repository is available to FIX members on the following URL.
http://www.fixprotocol.org/specifications/repository The is also some
documentation and some sample XSLT that run against the repository.To generate the schema we run XSLT against the XML repository and this
adds the mechanical bulk of the schema to the various files. The
starting section of each file is hand crafted, the main section
generated and a file hand crafted section is appended. (normally just
closing tags)These XSLT, or you own can be modifed to create your own object model in
the language of your choice. I contacted the programmer at the client
who was doing this and he made the following comments on thier approach.No, we don’t generate interfaces for the objects - not really needed -
but we could do so if someone wanted it. Yes, we generate private
members for all properties and have proper get / set accessor methods.
No, we don’t currently mark stuff as mandatory - would be a good thing
to add and very easy. Could then do a validation check before sending
message from the object model - and throw exceptions if mandatory fields
are not set. Yes, others can inherit from our objects - we also have a
base object that all our stuff inherits from so that messages can be
handled generically if required. Yes, we have a namespace
XXXX.FIXObjectModel44 - one single DLL contains all messages in the FIX
spec. No, don’t currently integrate documentation tags - again would be
easy to do and worthwhile. No, don’t currently integrate AppInfo tags.All this code is generated from the repository and a few XSLT
style sheets.The FPL GTC are working on a sample object model generating XSLT that
will be posted as a starter for anyone wishing to take this approach.Cheers Kevin Houstoun Consultant, Citigroup.
Are you saying that code generated from tools such as xsd.exe,
castor and the likes is not bug-free? what kind of bugs are you
referring too for instance?I got a lot of experience with the xsd.exe and the FIXML xsd’s the
last 6 month. For simple and quickly launched applications it might
work fine, but if you want to integrate the FIXML business model into
your application, you soon get very angry about the quality of the
source code, generated by the xsd.exe. Just some points, which drove
me crazy:
- No support of interfaces
- No generation of properties and private members, just public
variables- No mark of mandatory properties, no automatic constructor generation
with mandatory parameter- Very poor inheritance support
- No namespace separation. You have to built several DLL’s, if you
want to cover the complete model- No integration of the documentation tags
- No integration of AppInfo tags. It is relevant for all the
enumerations, they are added as AppInfos to the schema- and and and …
JAXB does a much better job, but still not cover all the demands.
As we have chosen .net as the platform for GUI’s, I decided to built
an own xsd code translator. This is the only way to get a clear source
code and object model out of the FIXML xsd. We found some fragments in
open source projects but still it took us more than 4 month and a deep
digging in the System.CodeDom assembly to finish our compiler.And this makes things much more easier now! Especially integration of
the enumerations make the understanding of FIXML much more easier.So, if anybody is interested about, just write an email to
fixml@suft.de
Hi,
I am facing an issue in converting FIXML V5.0 to java using castor. Source Generation is failing with floowing error.
Kindly help us in resolving this issue. It is quite urgent.
Thanks,
Namitha
Hi,
I would not entirely agree with listed defects of xsd.exe below. It is
possible to design your schema in a way, so that inheritence is
available to you when classes are generated from xsd.exe. Please read
this article for detailed explanation.http://www.topxml.com/xmlserializer/xmlincludeattribute.asp
-Anand
An approach I’ve seen used at clients is to generate an object model
in the same way that we, the FPL GTC, generate the schema. EG from the
repository.The repository is available to FIX members on the following URL.
http://www.fixprotocol.org/specifications/repository The is also some
documentation and some sample XSLT that run against the repository.To generate the schema we run XSLT against the XML repository and this
adds the mechanical bulk of the schema to the various files. The
starting section of each file is hand crafted, the main section
generated and a file hand crafted section is appended. (normally just
closing tags)These XSLT, or you own can be modifed to create your own object model
in the language of your choice. I contacted the programmer at the
client who was doing this and he made the following comments on thier
approach.No, we don’t generate interfaces for the objects - not really needed -
but we could do so if someone wanted it. Yes, we generate private
members for all properties and have proper get / set accessor methods.
No, we don’t currently mark stuff as mandatory - would be a good thing
to add and very easy. Could then do a validation check before sending
message from the object model - and throw exceptions if mandatory
fields are not set. Yes, others can inherit from our objects - we also
have a base object that all our stuff inherits from so that messages
can be handled generically if required. Yes, we have a namespace
XXXX.FIXObjectModel44 - one single DLL contains all messages in the
FIX spec. No, don’t currently integrate documentation tags - again
would be easy to do and worthwhile. No, don’t currently integrate
AppInfo tags.All this code is generated from the repository and a few XSLT
style sheets.The FPL GTC are working on a sample object model generating XSLT that
will be posted as a starter for anyone wishing to take this approach.Cheers Kevin Houstoun Consultant, Citigroup.
Are you saying that code generated from tools such as xsd.exe,
castor and the likes is not bug-free? what kind of bugs are you
referring too for instance?I got a lot of experience with the xsd.exe and the FIXML xsd’s the
last 6 month. For simple and quickly launched applications it might
work fine, but if you want to integrate the FIXML business model
into your application, you soon get very angry about the quality of
the source code, generated by the xsd.exe. Just some points, which
drove me crazy:
- No support of interfaces
- No generation of properties and private members, just public
variables- No mark of mandatory properties, no automatic constructor
generation with mandatory parameter- Very poor inheritance support
- No namespace separation. You have to built several DLL’s, if you
want to cover the complete model- No integration of the documentation tags
- No integration of AppInfo tags. It is relevant for all the
enumerations, they are added as AppInfos to the schema- and and and …
JAXB does a much better job, but still not cover all the demands.
As we have chosen .net as the platform for GUI’s, I decided to built
an own xsd code translator. This is the only way to get a clear
source code and object model out of the FIXML xsd. We found some
fragments in open source projects but still it took us more than 4
month and a deep digging in the System.CodeDom assembly to finish
our compiler.And this makes things much more easier now! Especially integration
of the enumerations make the understanding of FIXML much more
easier.So, if anybody is interested about, just write an email to
fixml@suft.de
We are experimenting with FIXML. We found this is a fairly large XML
schema definition and to have our application to support FIXML, there
are tons of XML parsing/validation to be done. We are wondering anybody
is serious using FIXML in the community and how do they deal with the
FIXML parsing/validation?
I am in mortgage industry. Our applications use castor (http://www.castor.org/) in order to generate java classes from schema as well validate and map xml to java objects.
We process credit reports(240 java classes) as well mortgage applications that have bunch of elements and attributes.
You need to check if castor supports all FIXML schema features!
Aleksandr