|
|
Preface
|
EDom (EDI Document Object Model) was created out of necessity. Many developers are faced with whether to use existing, "off the shelf" software to solve a problem, or to
write something from scratch. In many cases a packaged software solution is the best approach. In the case of EDI translator software, however, this has not proven
to be the case. Developers are increasingly required to integrate modern Internet applications with legacy EDI processes. EDI translators are
typically used for this purpose. The problem is that most (if not all) of these translators are ill-suited for Internet applications. Futhermore, these
EDI translators are expensive, poorly supported and rigid. One often finds that writing a map for a particular translator is actually
more difficult than writting C++ or Java code. EDom was created to solve this problem.
EDom is meant to be used by developers to solve EDI problems. It is not a full-fleged translator, rather a set of Java classes that allow a developer
to make their applications EDI aware. Maps, in the context of EDom, consist of Java classes that parse a particular EDI document, validate and
format transaction data and convert the results to the appropriate format. EDom behaves much like an XML parser. It provides a set of methods that allow
the developer to manipulate an EDI Document. This EDI Dom approach is well-suited to Internet developers familiar with using the XML Dom.
EDom is not a translator, but EDom could be used to build an EDI Translator.
|
|
Scripts
|
|
|
|