EDI file reading is an art perfected by many dedicated tools. So when it came to build an home-grown grounds-up EDI file reading mechanism, i have shamelessly (or wittingly, depends on your viewpoint) copied mix of architecture from BIZTALK and autofac… I think the results are cool.
We have an EDI engine which supports functionality like MAPPING and functionoids just like BIZTALK does. We have DEPENDANCY INJECTION of autofac. Best part is architecture is still very light weight unlike BIZTLAK and autofac. (Not to mention financials in licensing!!) .
But the good part is the reading itself is quite extensible as the EDI engine DOES NOT USES XML,XPATH and XSLT. It uses in-memory representation of EDI file as a CLASS object.
I admit i was initially very scared with this thought, but eventually it paid off interms of performance(inmemory object are faster than XML, XSD validation) and scalability(as object is constructed at runtime, no hard coding xsd and xml are required).
On a new version, type of EDI, ONLY a new mapping is required and functinoid is required, which are XML files. NO compilation or code generation is required as in case of other tools.
what is your take? Do mail in your comments / suggestions.